82 lines
5.4 KiB
Markdown
82 lines
5.4 KiB
Markdown
# Course VI - GitOps: ArgoCD, the GitHub linkage, and the one thing git never holds
|
|
|
|
**Series position:** first course of the delivery arc (VI-VIII). The main menu taught the
|
|
machine; this arc teaches how software REACHES it.
|
|
**Safety gate:** public site, real name - technologies only, zero employer/industry framing.
|
|
Claims source from [[argocd-stacks]], [[gitops-iac-rigor]], [[eso-infisical-secrets]]
|
|
(generalised to the Azure Key Vault worked example), [[authentik-oidc]] not needed here.
|
|
|
|
## Title (thesis)
|
|
**Nobody deploys anything. The cluster syncs itself.**
|
|
|
|
## Hook - the uncomfortable default
|
|
The mental model everyone arrives with: a person (or a pipeline) with credentials pushes
|
|
manifests at the cluster. Deploy = an action someone performs, kubectl apply = the verb.
|
|
The inversion: in GitOps nothing is pushed. A repository holds the desired state, an agent
|
|
inside the cluster watches it, and the cluster pulls its own future from git. kubectl is
|
|
for looking, git is for changing.
|
|
|
|
## Move 1 - The loop you already know, one level up
|
|
Course II taught the reconciliation loop: desired vs actual, fix the difference, repeat.
|
|
ArgoCD is the same habit applied to DELIVERY. An Application names a repo + path + revision
|
|
(the GitHub linkage: watch this branch of this repository); the controller renders what it
|
|
finds there, compares it against the live cluster, and shows the diff. Sync = make actual
|
|
match desired. The deploy button is a git commit; the change history is git log; code review IS
|
|
change control. (Accuracy: git records INTENT - the cluster's own audit log + the reconciler's
|
|
sync history still hold what actually happened.)
|
|
Say it like you mean it: **kubectl apply is for archaeology, not for change.**
|
|
|
|
## Move 2 - Pull, not push - the security inversion
|
|
The load-bearing detail everyone misses: the cluster PULLS. No CI system, no laptop, no
|
|
GitHub Action holds a credential that can touch the cluster. The agent inside the cluster
|
|
holds a read-only deploy key to the repo - the trust arrow points OUT. Compromise the build
|
|
system and you can propose a change (a commit, which is visible); you cannot reach into
|
|
production. Drift works the same way: hand-edit a live object and the controller flags it
|
|
OutOfSync - with selfHeal ENABLED it puts it back; with prune ENABLED what leaves git leaves
|
|
the cluster. Both are opt-in (2026-08-17 review): without them the reconciler reports drift and
|
|
waits for a human. Scope the pull-model claims as 'in this architecture' - push-based delivery
|
|
is still GitOps to many. Rollback is `git revert`, which is why commit hygiene is an operational skill.
|
|
FIELD NOTE (amber): fighting the reconciler by SSH/kubectl is arm-wrestling a machine that
|
|
does not get tired (Course II's note, now with a face). The fix is always upstream, in git.
|
|
|
|
## Move 3 - The one thing git never holds
|
|
Git holds everything - manifests, charts, config, the whole desired state - except secrets.
|
|
A plaintext secret committed to git is COMPROMISED from that moment - deleting it later does
|
|
not guarantee it is gone from history, forks, clones, CI caches or backups. So the pattern splits
|
|
the reference from the value: git carries an ExternalSecret manifest naming a LOGICAL key
|
|
("this app needs db-password from the vault"); a vault - Azure Key Vault as the worked
|
|
example, any ESO-supported store works - holds the value; an operator inside the cluster
|
|
exchanges the reference for the value at runtime and keeps it synced. Rotation happens in
|
|
the vault, never as a commit.
|
|
Say it like you mean it: **git holds the shape of the secret, the vault holds the secret.**
|
|
FIELD NOTE: the day a real credential lands in a commit, it is spent - history rewrites do
|
|
not un-publish it. Rotate first, tidy git second.
|
|
|
|
## Close
|
|
Delivery stops being an event and becomes a property: the cluster is always converging on
|
|
what the repository says. The question "who deployed this?" becomes "who merged this?" -
|
|
and that question always has an answer.
|
|
|
|
## Legend terms (DOM layer)
|
|
Application (repo + path + revision) / desired vs actual / sync / drift / selfHeal /
|
|
prune / pull model / deploy key / ExternalSecret / vault reference / rotation
|
|
|
|
## Scene concept (hero + slices, the v3 mechanism)
|
|
Exploded chain, upper-left to lower-right: a faceted crystal SLAB etched with branching
|
|
lattice (the repository) -> a compare-loop ENGINE with two counter-rotating ring motifs
|
|
(ArgoCD: desired vs actual) -> a stack of thin rendered SHEETS (manifests) -> the cluster
|
|
CORE (Course II's command slab, familiar silhouette) -> off-axis, drifting away dimmed: a
|
|
small GHOST SHARD (the hand-edit being reverted). Separate armoured VAULT BOX floating
|
|
above the chain, apart from everything (the secret store - deliberately not in line).
|
|
6 parts, no connectors. Slice plan: collapse packs chain into the engine; vault stays
|
|
apart even collapsed (it is never absorbed into the pipeline - the visual argument).
|
|
|
|
## Page footer - pre-reads + further reading (site convention: every course carries this)
|
|
Pre-reads: Course II (the reconciliation loop - this course is that loop one level up);
|
|
Kubernetes concepts (https://kubernetes.io/docs/concepts/); git + pull requests
|
|
(https://docs.github.com/en/get-started).
|
|
Further reading: Argo CD docs (https://argo-cd.readthedocs.io/); Red Hat OpenShift
|
|
GitOps (via https://docs.redhat.com/en/documentation/openshift_container_platform);
|
|
External Secrets Operator (https://external-secrets.io/); Azure Key Vault
|
|
(https://learn.microsoft.com/azure/key-vault/); Helm docs (https://helm.sh/docs/).
|