ArgoCD and GitOps

After this lesson, you will be able to: Explain the GitOps model and use Argo CD to sync a Kubernetes cluster to a Git repo, plus where Infrastructure as Code fits in the pipeline.

Push-based pipelines run kubectl apply from CI, which means your CI system holds cluster credentials and nobody really knows what is running. GitOps inverts this: Git is the single source of truth for the desired state, and an in-cluster agent (Argo CD or Flux) continuously pulls and reconciles. This lesson covers the model, a real Argo CD setup, and how IaC (Terraform) relates.

Prerequisites:Deploy Strategies

Push vs pull: what GitOps actually changes

In a push pipeline, CI builds the image and then runs kubectl apply / helm upgrade against the cluster. The cluster is a passive target and your CI runner must hold powerful cluster credentials. In GitOps (pull), a desired-state manifest lives in a Git repo, and an agent running inside the cluster watches that repo and applies any change. CI's job shrinks to: build the image, then commit the new image tag to the config repo. The agent does the rest. Nobody runs kubectl by hand against production.

Why GitOps reduces deployment risk

Git is the source of truth: every change to production is a commit, so you get review (pull requests), history (git log), and instant rollback (git revert). Drift detection: the agent constantly compares the live cluster to Git and flags or auto-corrects anything that drifted (a hand-edited resource, a deleted pod config). Least privilege: cluster credentials never leave the cluster, so a compromised CI runner cannot touch production directly. Auditability: 'what is running in prod?' is answered by reading one repo, not by interrogating the cluster.

An Argo CD Application

Argo CD watches a Git path and syncs it to a cluster. This manifest points Argo CD at your config repo.

tsx

# install Argo CD into the cluster (once):
#   kubectl create namespace argocd
#   kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# app-of-apps style: an Application tells Argo CD what to sync
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: store-web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/store-config.git  # the CONFIG repo
    targetRevision: main
    path: apps/store-web                                # Helm or plain manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: store
  syncPolicy:
    automated:
      prune: true        # delete resources removed from Git
      selfHeal: true     # revert manual drift back to Git's state
    syncOptions:
      - CreateNamespace=true

The GitOps deploy flow end to end

How a code change reaches production without anyone touching the cluster.

1
Developer merges a feature PR into the app repo.
2
CI builds and pushes a new image, e.g. ghcr.io/acme/store-web:sha-abc123.
3
CI opens (or commits) a one-line change to the CONFIG repo bumping the image tag to sha-abc123.
4
That config change is reviewed and merged (this merge IS the production approval).
5
Argo CD detects the new commit, syncs it, and rolls out the new image.
6
If anything is wrong, git revert the config commit; Argo CD rolls back automatically.

Quick Check

In GitOps, how does a new image version reach the production cluster?

Pick the best description.

CI runs kubectl apply against production with stored cluster credentialsCI commits the new image tag to a config repo, and an in-cluster agent (Argo CD) pulls and reconciles that changeA developer SSHes into a node and restarts the podThe cluster polls Docker Hub for new tags

←Deploy Strategies

Back to CI/CD Pipelines

Observability and Monitoring→