Argo CD architecture setup options
- Namespace scoped: One Argo CD per namespace
- In enterprise: Dev’s manage their own Argo CD in their namespace. HA not required
- Workload clusters: One Argo CD per cluster
- Most popular. Mgmt overhead grows with # of clusters. HA not required
- Control plane cluster: One Argo CD for multiple clusters
- Inevitable without tight IaC control. Reduces overhead, but SPOF . HA highly encouraged
- Hybrid: Argo of Argo’s. Central Argo CD deploys Argo CD to each cluster
- Akuity SaaS: Argo of Argo’s with more automation and easier management
PSA: Web UI in the real world
Editing in the UI is not declarative
Make it read-only for your users (dev/ops). Only use for deployment monitoring
All changes should be through YAML in Git
Let’s do a quick demo of Argo CD web UI
Argo CD GitOps repo design options
- Argo CD is flexible about how you organize your Git repos
- Assume YAML is in a different repo from app code (a 12-Factor principle) and many other reasons
- Repo design often/should reflect org structure (Conway’s Law)
Minimal: Shared ownership
- 1
ringrepo to rule them all: Kustomize + Helm + Argo CD App + Argo CD Config
Scalable: Split app configs from Argo CD configs 👈 my favorite
- 1 Kustomize/Helm repo per solution: (Dev and DevOps share ownership)
- 1 Argo CD repo: Argo CD App + Argo CD Config (DevOps or Ops team owns)
- Optional: involves DevOps/Ops PR approval when first adding an app to Argo CD (since they own repo)
ApplicationSetnow enables Ops cluster control while Devs add/remove apps at will- Day to day, Devs can PR to their own Kustomize/Helm repos w/o Ops involvement