Overview In the previous post, I set up Harbor container registry, Argo Events, and Argo Workflows as the foundation of the IDP. This post covers integrating those components with ArgoCD and designing Helm chart-based project templates to turn them into an Internal Developer Platform (IDP) that can deploy projects from a single YAML file. What Is an Internal Developer Platform? What is an Internal Developer Platform (IDP)? ...
Overview In the previous post, we installed HashiCorp Vault to build a secure secrets management system. This post covers the foundational pieces I set up before the internal developer platform itself: Harbor container registry, Argo Events, and Argo Workflows. Foundation Components for the IDP For the IDP I had in mind, I first needed the following core components: Container Registry: A central repository for storing and distributing built container images, enabling self-management of images without depending on public registries like Docker Hub. Event Processing System: Responsible for detecting various events such as code changes in Git repositories and webhook receipts, and triggering subsequent tasks in response. Workflow Engine: An engine for defining and executing actual CI/CD tasks such as code building, test execution, and container image creation. GitOps Deployment System: A system that automatically synchronizes the desired state defined in Git repositories to the cluster. ArgoCD, which was installed in an earlier post in this series, handles this role. In this post, I set up the container registry, event processing system, and workflow engine using Harbor, Argo Events, and Argo Workflows. In the next post, I connect these pieces to ArgoCD and the project template structure so they start to behave like an actual IDP. ...
Running a web app, a DB, and a cache each with docker run means memorizing long commands per container and wiring up networks by hand. The more common problem is that the app comes up before the DB is ready and dies on a connection error. Docker Compose declares the whole stack in one YAML file and brings it up with a single command. The thing that actually trips you up with multiple containers is service startup order. The stack below starts the app only after the DB is ready. Running docker compose up confirms the order holds in the log. The output comes from a run on Docker Compose v5.1.1. ...