Practice: Reproducible environments: GitOps with Argo CD and infrastructure as code with Terraform

Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.

Main tool: Argo CD · Argo CD makes the GitOps loop visible on a laptop, because every application shows its Git target state, its live state and the difference between them, which is exactly what this lesson asks you to reason about. · Alternatives: Flux reconciles Git to the cluster with a set of composable controllers and no built-in UI, Terraform with its Kubernetes and Helm providers applies manifests on demand from a state file but does not reconcile continuously, and plain Helm or Kustomize run from a CI pipeline push changes without detecting drift afterwards.

Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1

Setup (one time)

• 1. Start a local Kubernetes cluster with kind or minikube and confirm that kubectl can reach it.

  Argo CD runs inside Kubernetes, so a small local cluster replaces the managed cloud cluster that Terraform would normally provision. No paid cloud and no GPU are needed.

  Explained in: Getting Started - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: kubectl lists the nodes of your local cluster as Ready.

• 2. Install Argo CD into a namespace named argocd on the local cluster.

  The install creates the API server, the repository server and the application controller that performs the reconciliation you will practise.

  Explained in: Getting Started - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: All pods in the argocd namespace report Running.

• 3. Download the argocd command line client for your operating system.

  Most of this path uses the client, because the same commands are what you later script in automation.

  Explained in: Getting Started - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: The argocd version command prints a client version.

• 4. Expose the Argo CD API server with port forwarding, read the initial admin password and log in with the client.

  Port forwarding is the simplest laptop access path and avoids setting up a load balancer or an ingress. Logging in stores a session that every later command reuses.

  Explained in: Getting Started - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: The client reports a successful login and the web UI opens on the forwarded local port.

• 5. Check that the ApplicationSet controller was installed together with Argo CD.

  Later steps generate many applications from one template, and that needs this controller to be running.

  Explained in: Installations - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: A pod for the applicationset controller is Running in the argocd namespace.

Steps

• 1. Create your first Application with the client, pointing it at a fork of the example guestbook repository and at the local cluster.

  An Application is the link between a Git path and a cluster namespace. Using your own fork lets you commit changes in later steps.

  Explained in: Getting Started - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: The application appears in the app list with sync status OutOfSync and health Missing.

• 2. Run a manual sync of the guestbook application and watch the resources get created.

  A manual sync shows the basic GitOps action in isolation: the controller applies what Git declares, and nothing else.

  Explained in: Getting Started - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: The application shows Synced and Healthy, and the guestbook pods are Running in the cluster.

• 3. Run the app get command on guestbook and match each field of its output to a term from the core concepts list: application, target state, live state, sync status, health and refresh.

  The GitOps model is this small vocabulary. Being able to point at each term in real output is what makes the rest of the tool predictable.

  Explained in: Core Concepts - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: You have a short note that names the Git revision acting as target state and the cluster objects acting as live state for guestbook.

• 4. Create drift by scaling the guestbook Deployment by hand with kubectl, run the app diff command, and write down how target state, live state and sync map onto the Terraform plan, state file and apply workflow.

  Terraform records what it created in a state file and compares only when you run a plan, while Argo CD compares Git with the live cluster continuously. Seeing drift reported here makes that difference in workflow and state concrete.

  Explained in: Core Concepts - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: The application shows OutOfSync, the diff shows the replica count change, and your note has three rows mapping plan to diff, apply to sync and state file to live state.

• 5. Write an ApplicationSet with a list generator that produces a staging and a production copy of guestbook from one template.

  The ApplicationSet resource is how many applications are managed without copying manifests. Parameters from the generator fill in the template.

  Explained in: Introduction - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: Two generated applications appear in the app list, one per list element, each in its own namespace.

• 6. Write an Application manifest for a Helm chart in your fork, commit it to Git, and promote a new version by changing the image tag in the values and merging the commit.

  Declaring the application itself in Git makes a release a reviewed line change with history and revert. This is how a deployed model version becomes a line in a repository.

  Explained in: Helm - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: After the commit and a sync, the running pod uses the new image tag, and reverting the commit brings the old tag back.

• 7. Read the section on controls for ApplicationSet sources of truth, then protect the main branch of your fork so that changes need a pull request.

  Whoever can change the Git source can change what is deployed. Promotion is therefore only as safe as the review rules on the repository.

  Explained in: Security - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: A direct push to the main branch of your fork is rejected and a merged pull request is the only way to change a deployment.

• 8. Enable the automated sync policy with pruning and self-healing on guestbook, then repeat the manual scaling from the drift step and also delete one manifest from Git.

  Automated sync removes the human sync step, self-healing reverts drift, and pruning deletes what Git no longer declares. Together they are what keeps an environment reproducible.

  Explained in: Automated Sync Policy - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: The manual replica change is reverted without any action from you, and the resource whose manifest you deleted disappears from the cluster.

• 9. Create a Kustomize base with a staging and a production overlay that patch the replica count, and point one Application at each overlay.

  Overlays keep environments identical except for explicit, reviewed differences. That is the pinned-environment side of reproducibility.

  Explained in: Kustomize - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: Both applications are Synced and the two Deployments differ only in the replica count set by their patch.

• 10. Configure the ApplicationSet to use the Git directory generator so that each folder under an apps path in your fork becomes an application.

  With this generator, adding an environment or a service is a new folder in a commit, so the set of applications is itself driven by Git.

  Explained in: Git Generator - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: Committing a new folder creates a new application after the next poll, and removing the folder removes it.

• 11. Configure a deny sync window on the project that covers the current time, then commit a change and try to sync.

  Sync windows give teams change freezes without turning automation off. They block automated and manual syncs for a schedule you control.

  Explained in: Sync Windows - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: The application stays OutOfSync during the window with the sync blocked, and it syncs once the window is removed or ends.

• 12. Create a second local cluster as a stand-in for a managed cloud cluster that Terraform would provision, register it with Argo CD, label its cluster secret, and deploy to it with a Cluster generator that uses a label selector.

  This is the handover point of a production setup. Terraform stops once the cluster exists and is registered with labels, and from that label onward Argo CD decides what runs on it. No paid cloud is needed, because a second kind or minikube cluster behaves the same for this purpose.

  Explained in: Cluster Generator - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io), checked 2026-10-11

  Done when: Adding the label to the second cluster's secret makes its applications appear and sync, and removing the label removes them.

Back to Reproducible environments: GitOps with Argo CD and infrastructure as code with Terraform