gitops
Reconciling a cluster toward a repository instead of deploying at it.
-
Realm-as-Code: Reconciling Clients and Roles But Never Users or Signing Keys
Reconciling a Keycloak realm from a file is safe for clients, roles and role mappings, but the same "make live state match this JSON" instinct applied to users or signing keys deletes real accounts and invalidates every outstanding token. This article draws that boundary precisely, and works through a Python script against the Admin REST API that reconciles clients and realm roles idempotently against a local Keycloak container, while proving a second run changes nothing and a user created out-of-band survives every run.
-
Breaking the Circular Dependency in GitOps Secret Delivery
A secrets operator deployed through GitOps is the natural way to get credentials onto a cluster without committing them to git, but that operator needs its own credential to reach the secret store, and nothing has delivered that one yet. This works through where the circularity actually breaks, and gives a complete, reproducible bootstrap using a Vault dev server and the External Secrets Operator on a local kind cluster.
-
Pinning Image Tags to Git SHAs Because GitOps Diffs Manifests, Not Registries
A Deployment manifest that references an image by a floating tag such as latest never changes as text, so a GitOps controller comparing git to the cluster sees no diff and triggers no rollout even after CI pushes a new image. This shows why, and how baking the git SHA into the tag at build time, with a reproducible local-registry demo proving both the failure and the fix.
-
Sync Waves and the CRD-Before-Consumer Ordering Problem
Applying a CustomResourceDefinition and a custom resource that depends on it in the same Argo CD sync can fail intermittently, and removing the CRD from git can prune it in a way that deletes every instance of that resource cluster-wide, not just the ones this Application owns. This works through sync waves and a prune guard that make both failures impossible, with a reproducible kind cluster test proving it.
-
ApplicationSets: Onboarding a Workload With a Directory and a Pull Request
Hand-writing a new Argo CD Application object for every microservice is repetitive, and the step is easy to forget entirely when a new service is added. This shows how an ApplicationSet's git directory generator turns onboarding a workload into adding a directory and merging a pull request, with a complete, reproducible setup on a local kind cluster.
-
Argo CD App-of-Apps: Bootstrapping a Bare Cluster from One Root Application
A fresh Kubernetes cluster has nothing on it, and a runbook of kubectl apply commands run in the right order does not survive being handed to someone else or run against a rebuilt cluster months later. This works through the app-of-apps pattern, where one root Argo CD Application manages every other Application, and gives a complete, reproducible setup on a local kind cluster.
-
Docker Compose or Kubernetes: What the Control Loop Actually Buys You
Kubernetes is usually sold as the next step up from Docker Compose, which makes it sound like a bigger version of what you already have. It is a trade: you hand over control of where things run in exchange for a system that keeps working when a machine dies. This works through what that trade actually costs, with a runnable example showing the control loop doing its job and a Compose stack that cannot do the same thing.