Internal Developer Platform (IDP) Part 4 - Up and Running
Implementation Objectives
The bootstrapping design prioritizes automation, isolation, and minimal host dependencies.
These objectives guide the implementation:
the IDP can be tested and verified quickly
setup and teardown are fully automated
the health of the IDP can be monitored
successful deployment can be verified
dependencies on the host system used to deploy the IDP are documented, verified, and minimal
prerequisites are known, verified, and minimal
stable development environment with the necessary tooling is part of the setup
deployment is safe and isolated and does not interfere with other environments
tidying up leaves as few traces on the host system as possible
modular design facilitates swapping out components
Overall Flow
Prerequisites | A linux based host system that supports Nix. |
|---|---|
Development environment | The development environment is managed using Nix flakes. The script bootstrap.sh checks whether Nix is present on the machine and installs it if not. |
Activate environment | Use |
Bring up the IDP | The script up.sh deploys the IDP in phases. Each phase typically calls other scripts, that check their prerequisites and success. The phases are described below. This implementation uses a local k3s-cluster. |
Tear down the IDP | The script k3d-teardown.sh deletes the local k3s-cluster. |
Deployment Phases
The deployment script up.sh runs these phases:
Verify environment | Verify that the script is running inside the Nix development environment. |
|---|---|
Build portal | Build the terminal based portal used to display the health and state of the various components. Start the portal manually. |
Create k3s cluster | Using k3d, spin up a k3s-cluster. Deploy |
Deploy GitOps component | All components in the IDP are managed using GitOps, and the GitOps engine of choice here is Flux. It has a smaller footprint than ArgoCD. |
Deploy platform components | Triggered by installing Flux, all platform components - like Tekton -, and sample applications are deployed to the cluster. |
Deploy CI-secrets | The platform bootstrapping includes a platform probe application and the portal application exposing useful metrics. CI-pipelines are deployed, and these required secrets to access the code repository (Codeberg in this case). This phase deploys the secrets to the corresponding namespaces. The secrets must be available on the local filesystem, but are not version controlled. |
Bootstrap IDP probe build | In order to speed up the process, an initial build of the IDP probe application is initiated. No image exists at startup because the registry is part of the IDP itself — an initial build seeds it. Eventually, an image would be built and deployed, though. |
Run smoke tests | Smoke tests verify that the cluster and important endpoints, e.g. Grafana, are up and running. The smoke tests are repeated until all are successful or a timeout is reached. |
Summary
The IDP deploys reproducibly and quickly. This makes it possible to verify its functioning over time, easily detect unexpected failures and breaking dependency changes. Further, it facilitates testing to other host systems and target clusters.
As always, consult the source for details and up-to-date documentation.
The next post covers developer-facing services.
This post and the underlying code was written and developed in collaboration with several AIs.