Cheat notes · Module 01 · Foundations

Install Argo CD the reviewable way

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

Install Argo CD the way you will run it: a pinned Helm chart, its settings in a values file in Git, nothing changed by hand. Argo CD is a few controllers plus new object types (CRDs) in your cluster.

Remember

Components: argocd-server (UI and API), argocd-repo-server (clones Git, renders Helm and Kustomize), argocd-application-controller (compares and syncs), Redis (cache), plus the ApplicationSet and notifications controllers.
CRDs: Application (what to deploy, from where, to where), AppProject (the fence around Applications), ApplicationSet (generates Applications).
Values file in Git: argocd/values.yaml holds Argo CD's settings. The chart renders them into ConfigMaps such as argocd-cm.
Pinned chart version: the version is part of the command (later of a manifest), so installs repeat exactly and upgrades are deliberate.
admin: the install creates it with a random password in argocd-initial-admin-secret. Fine to start; module 06 replaces it with personal accounts.
The port-forward: until module 06 the UI and the CLI only work while kubectl -n argocd port-forward svc/argocd-server 8080:443 runs. The CLI login lasts 24 hours.

Pitfalls

+ New App in the UI creates an Application that exists nowhere in Git. Use the UI to watch; change things through Git.
A hand edit of Argo CD's ConfigMap makes the next helm upgrade fail with conflict ... with "kubectl-patch": Kubernetes records each field's manager. Put the value in values.yaml, then take the field back once with --force-conflicts.
connection refused from argocd means the port-forward stopped. Unauthenticated means the login expired: log in again.

Commands

`helm install argocd argo/argo-cd --version 10.10.5 -n argocd --create-namespace -f argocd/values.yaml --wait`	Install Argo CD: this chart, this version, your values
`kubectl get crd \| grep argoproj.io`	The three object types Argo CD adds
`kubectl -n argocd get deployments,statefulsets`	The components. First list to check when Argo CD misbehaves
`kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' \| base64 -d`	The initial `admin` password
`kubectl -n argocd port-forward svc/argocd-server 8080:443`	Reach the UI and API. Keep it running in its own terminal
`argocd login localhost:8080 --insecure --username admin --password ...`	Log the CLI in
`argocd cluster list`	Clusters Argo CD can deploy to (`in-cluster`)
`argocd proj get default`	The `default` project: any repo, any destination

The values file

global:
  domain: argocd.localtest.me
configs:
  cm:
    timeout.reconciliation: 60s   # check Git every minute
dex:
  enabled: false                  # no SSO on a laptop

Test yourself

Answer in your head first, then open the answer.

Which component clones Git and renders Helm charts?

argocd-repo-server. The application controller compares and syncs; the server serves the UI and API.

Why install chart 10.10.5 instead of the latest?

A repeatable, reviewable install: the version is in Git, and upgrades become deliberate changes.

Where does the admin password come from?

The install generates it into the argocd-initial-admin-secret Secret.

helm upgrade fails with a conflict on .data.timeout.reconciliation. What happened?

Someone changed that field by hand. Server-side apply refuses to overwrite another field manager silently.

Where module 01 leaves you: A running cluster with Argo CD installed from your values file, a platform repo with that file committed, and you logged in as admin in both the UI and the CLI. No applications yet.