From 43346455666b34ab2008703ae5d14b2cdfc434ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= Date: Mon, 4 May 2026 18:28:39 +0200 Subject: [PATCH] =?UTF-8?q?=E2=9E=95=EF=B8=8F=20Add=20ArgoCD=20advanced=20?= =?UTF-8?q?content?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit App of Apps; AppSets --- slides/k8s/argocd-advanced.md | 162 ++++++++++++++++++++++++++++++++++ slides/k8s/argocd.md | 2 +- slides/kube-selfpaced.yml | 1 + 3 files changed, 164 insertions(+), 1 deletion(-) create mode 100644 slides/k8s/argocd-advanced.md diff --git a/slides/k8s/argocd-advanced.md b/slides/k8s/argocd-advanced.md new file mode 100644 index 00000000..a7f0b75b --- /dev/null +++ b/slides/k8s/argocd-advanced.md @@ -0,0 +1,162 @@ +# ArgoCD advanced patterns + +- It's very common to deploy multiple apps or components following the same pattern + +- Example: same app deployed to different namespaces (prod, preprod, staging) + +- Example: same app deployed to different clusters (same; or regional clusters) + +- Example: multiple apps using different Helm charts, each to its own namespace + +- Example: multiple apps using the same Helm charts, different values YAML files + +- Example: multiple apps deployed to multiple clusters (MxN) + +- How should we deal with that? + +--- + +## App of Apps + +- ArgoCD Application that contains *more Applications* + +- Typical use-case: deploy a bunch of standard cluster components + + (example: Ingress controller, Prometheus exporters, log collectors, cert-manager...) + +- That "App of Apps" can be a Helm chart ([example][argocd-app-of-apps-helm-example]) + +- It can leverage Helm advanced templating features + + (e.g. iterators, `range`, manipulating files...) + +[argocd-app-of-apps-helm-example]: https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/#helm-example + +--- + +## Generated Apps, committed to repo + +- Write scripts to generate ArgoCD Application manifests from some source of truth + + (scripts, more YAML files, database...) + +- Commit the generated manifests + +- Apply these manifests individually; or with an App of Apps + +- Downsides: + + - each new app = need to run scripts, commit new files... + + - lots of potential repetitions in generated manifests + + - changes in the generator = big commit that is harder to analyze and review + +--- + +## Generated Apps, not committed to repo + +- What if we generated the ArgoCD Application manifests on the fly? + +- This would avoid the downsides mentioned earlier + +- But it would require to either: + + - do that in a custom CI/CD pipeline (Jenkins, GitHub Actions...), without ArgoCD + + - or integrate a custom "tool" (YAML generator) into ArgoCD + +- *Doable, but quite complex!* + +--- + +## Application Sets + +- ArgoCD's native way to generate multiple Apps + +- Application Set = ArgoCD Custom Resource containing a `template` and `generators` + +- `template` = Application template evaluated with Go templating engine + +- `generators` = iterators generating a list of environments + +--- + +## Example + +.small[ +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: ApplicationSet +metadata: + name: my-appset +spec: + goTemplate: true + goTemplateOptions: ["missingkey=error"] + generators: + - list: + elements: + - repo: frontend + - repo: backend + template: + metadata: + name: "{{.repo}}" + spec: + project: default + source: + repoURL: "https://github.com/my-org/{{.repo}}.git" + targetRevision: main + path: deploy/manifests + destination: + server: "https://kubernetes.default.svc" + namespace: "{{.repo}}" +``` +] + +--- + +## Some generators + +- `list` = iterate over a pre-defined list of key/value maps + +- `cluster` = deploy app on a list of clusters known to ArgoCD + +- `git` = create one app for each file or directory found in a git repo + +- `scm` = create one app for each repo detected on GitHub, Gitlab, Gitea, Bitbucket... + +- `pullrequest` = ditto, but for pull requests + +- `matrix` = combine multiple generators (MxN) + +- `merge` = override some parameters + +(See [ArgoCD documentation][argocd-generators] for detailed list.) + +[argocd-generators]: https://argo-cd.readthedocs.io/en/latest/operator-manual/applicationset/Generators/ + +--- + +## Discussion + +- Separation of concerns: + + - someone writes code + - someone "containerizes" it (e.g. Dockerfiles) + - someone writes e.g. Kubernetes manifests or Helm charts + - someone deploys Kubernetes clusters + - someone installs essential components (observability...) + - (maybe someone deploys physical machines, or manages hypervisors) + - someone applies Kubernetes manifests to clusters ⭐️ + - someone is on call on all that + +⭐️ That's a part that can be automated with Application Sets. + +But it requires someone to define how we organize code, repos, charts... + +And some of these tasks will overlap multiple individuals / teams / orgs. + +??? + +:EN:- ArgoCD advanced patterns +:FR:- Utilisation avancée d'ArgoCD diff --git a/slides/k8s/argocd.md b/slides/k8s/argocd.md index 41c8213d..81ea1c1b 100644 --- a/slides/k8s/argocd.md +++ b/slides/k8s/argocd.md @@ -206,7 +206,7 @@ It is responsible for invoking any user-defined hooks for lifecycle events (*Pre - Let's use the CLI to add an Application: ```bash - argocd app create kubercoins \ + argocd app create kubercoins \ --repo https://github.com/`/`.git \ --path . --revision `` \ --dest-server https://kubernetes.default.svc \ diff --git a/slides/kube-selfpaced.yml b/slides/kube-selfpaced.yml index 0507498f..e640f153 100644 --- a/slides/kube-selfpaced.yml +++ b/slides/kube-selfpaced.yml @@ -133,6 +133,7 @@ content: - k8s/gitworkflows.md - k8s/flux.md - k8s/argocd.md + - k8s/argocd-advanced.md - - k8s/logs-centralized.md - k8s/prometheus.md