Command Palette

Search for a command to run...

Hectal
  1. 0
  2. 1
  3. 2

Mission 1.1 · Stage 1 — GitOps with Argo CD

GitOps Principles and Installing Argo CD

Goal: A local Kubernetes cluster running Argo CD, and a clear picture of why pull-based delivery beats kubectl apply from CI.

35 min Free — local kind cluster 4 steps 1 break-it drills

By the end of this mission

  • State the four GitOps principles and what each buys you
  • Compare push-based CI/CD with pull-based GitOps
  • Install Argo CD and log in with the CLI and UI
  • Name Argo CD's components and what each does

Part 1

Understand it first

The four GitOps principles (OpenGitOps)

1. DECLARATIVE: the whole system is described as desired state (Kubernetes YAML, Helm values), not scripts. 2. VERSIONED AND IMMUTABLE: that desired state lives in Git, so every change has an author, a review, and a history. 3. PULLED AUTOMATICALLY: software agents fetch the desired state themselves. 4. CONTINUOUSLY RECONCILED: agents keep comparing actual with desired and correct any difference.

You already know principle 4 from the Kubernetes course: every controller (Deployment, ReplicaSet) runs a reconcile loop. Argo CD applies the same loop one level up, with Git as the source instead of the API server.

Push vs pull delivery

PUSH (the CI/CD course's pipeline ending in kubectl apply or helm upgrade): CI holds cluster-admin credentials, deploys happen only when a pipeline runs, and if someone edits the cluster by hand nobody notices. PULL (GitOps): CI only builds, tests, and pushes images, then commits a new tag to the config repo. The in-cluster agent pulls. Credentials never leave the cluster, drift is detected and corrected, and the cluster's state can be rebuilt from Git after a disaster.

Argo CD's components

API SERVER: serves the UI, CLI, and API, and handles SSO and RBAC. REPO SERVER: clones Git repos and renders manifests (plain YAML, Kustomize, Helm, Jsonnet) into final YAML. APPLICATION CONTROLLER: compares rendered manifests with live cluster state, reports Sync and Health status, and applies changes. Optional: ApplicationSet controller (Stage 2), notifications controller, Dex for SSO, and Redis as a cache.

Push vs pulldiagram
Rendering diagram…

Part 2

Your project after this mission · 1 file change

shoplite-gitops/
  • shoplite-gitops/
    • README.mdnew

Part 3

Build it, step by step

  1. 1

    Create a local cluster

    kind runs Kubernetes inside Docker, as in the Kubernetes course. Two clusters would be closer to real dev/prod; one is enough until Stage 2.

    terminal
    $ kind create cluster --name shoplite
    kubectl get nodes
    ── expected output ──
    NAME STATUS ROLES AGE VERSION
    shoplite-control-plane Ready control-plane 40s v1.34.0
  2. 2

    Install Argo CD

    The upstream install manifest creates the argocd namespace's deployments, CRDs (Application, AppProject, ApplicationSet), and RBAC. In production you'd install with the Helm chart and pin a version (and later, have Argo CD manage its own installation).

    terminal
    $ kubectl create namespace argocd
    kubectl apply -n argocd --server-side -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
    kubectl -n argocd rollout status deploy/argocd-server
    kubectl -n argocd get pods
    ── expected output ──
    deployment "argocd-server" successfully rolled out
    NAME READY STATUS
    argocd-application-controller-0 1/1 Running
    argocd-applicationset-controller-6b9c7d8f4-x2k8p 1/1 Running
    argocd-dex-server-7d4f5c9b8-q9w7n 1/1 Running
    argocd-notifications-controller-5c8d7b6f9-m4v2h 1/1 Running
    argocd-redis-6f9d8c7b5-p3j6k 1/1 Running
    argocd-repo-server-8c7b6d5f4-h8t2r 1/1 Running
    argocd-server-5b8c9d7f6-l7n4s 1/1 Running
  3. 3

    Log in with the CLI and UI

    The initial admin password is generated into a Secret. Use it once, then set up SSO (or at least change it) and delete the initial secret. Port-forwarding avoids exposing the UI; in a real cluster it sits behind an Ingress with TLS.

    terminal
    $ kubectl -n argocd port-forward svc/argocd-server 8080:443 &
    argocd admin initial-password -n argocd
    argocd login localhost:8080 --username admin --insecure
    argocd version --short
    ── expected output ──
    Xk2m9QpL7vRtY3wZ
    This password must be only used for first time login. We strongly recommend you update the password using `argocd account update-password`.
    'admin:login' logged in successfully
    argocd: v3.1.5+...
    argocd-server: v3.1.5+...
  4. 4

    Create the config repo

    GitOps usually separates two repos: the APP repo (source code, Dockerfile, CI) and the CONFIG repo (what runs where). Separate repos keep deploy history clean, let CI write tags without triggering its own build, and give different access rules (every developer writes code; fewer people approve prod config). Create an empty shoplite-gitops repository on GitHub and clone it.

    terminal
    $ git clone git@github.com:<you>/shoplite-gitops.git && cd shoplite-gitops
    echo '# ShopLite desired state — merged = deployed' > README.md
    git add . && git commit -m 'init' && git push

Checkpoint — you should now have

  • ✓All seven Argo CD pods are Running.
  • ✓argocd login works and the UI loads at https://localhost:8080.
  • ✓An empty shoplite-gitops repo exists and is cloned locally.

Part 4

Break it on purpose

Make each change, run the command, and read the error before revealing the diagnosis. Recognising these messages on sight is what makes you fast on a real team. Undo the change afterwards.

Break #1

Forget the CRDs

Apply an Application manifest to a cluster where Argo CD isn't installed (for example a second, fresh kind cluster).

terminal
$ kubectl apply -f app.yaml
── what you'll see ──
error: resource mapping not found for name: "shoplite" namespace: "argocd" from "app.yaml": no matches for kind "Application" in version "argoproj.io/v1alpha1"
ensure CRDs are installed first

Part 5

Interview questions from this mission

01

What is GitOps, and how is it different from CI/CD with kubectl apply?

02

Why keep application code and deployment config in separate repositories?

0/4 · 0%