From 86d4dfa775d458a217ec4184999fe085fe96f51e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= Date: Sun, 9 Jun 2024 18:55:59 +0200 Subject: [PATCH] =?UTF-8?q?=F0=9F=94=A5=20Updates=20after=20@soulshake's?= =?UTF-8?q?=20reviews?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- slides/k8s/flux.md | 16 ++++++++++------ slides/k8s/gitworkflows.md | 20 ++++++++++++++------ 2 files changed, 24 insertions(+), 12 deletions(-) diff --git a/slides/k8s/flux.md b/slides/k8s/flux.md index 83b719b1..e6944cf9 100644 --- a/slides/k8s/flux.md +++ b/slides/k8s/flux.md @@ -163,7 +163,7 @@ class: extra-details - Create a manifest; for instance `clusters/dev/flux-system/blue.yaml` -- Add that manifest to `cluseters/dev/kustomization.yaml` +- Add that manifest to `clusters/dev/kustomization.yaml` - Commit and push both changes to the repository @@ -173,7 +173,7 @@ class: extra-details ## Waiting for reconciliation -- Compare the git hash that we pushed and the one show with `kubectl get ` +- Compare the git hash that we pushed and the one shown with `kubectl get ` - Option 1: wait for Flux to pick up the changes in the repository @@ -183,6 +183,10 @@ class: extra-details (this puts an annotation on the appropriate resource, triggering an immediate check) +- Option 3: set up receiver webhooks + + (so that git updates trigger immediate reconciliation) + --- ## Checking progress @@ -225,7 +229,7 @@ class: extra-details (with multiple resource manifets) -- We want that to be reusable +- We want to minimize code repetition (i.e. easy to add on multiple clusters with minimal changes) @@ -324,7 +328,7 @@ class: extra-details - installing one of our own charts
- (e.g. a chart with authored ourselves) + (e.g. a chart we authored ourselves) - The procedures are very similar @@ -403,7 +407,7 @@ class: extra-details --export > apps/myapp/flux.yaml ``` -- Add that manifest to the top-level kustomization +- Add a reference to that manifest to the top-level kustomization - `git add` / `git commit` / `git push` the chart, manifest, and kustomization @@ -439,7 +443,7 @@ class: extra-details - Artifacts are updated only when the Helm chart version changes -- Unless `reoncileStrategy` is set to `Revision` (instead of the default `ChartVersion`) +- Unless `reconcileStrategy` is set to `Revision` (instead of the default `ChartVersion`) --- diff --git a/slides/k8s/gitworkflows.md b/slides/k8s/gitworkflows.md index 6b7f4465..943614ff 100644 --- a/slides/k8s/gitworkflows.md +++ b/slides/k8s/gitworkflows.md @@ -22,7 +22,7 @@ - These resources have a perfect YAML representation -- All we do is manipulating these YAML representations +- All we do is manipulate these YAML representations (`kubectl run` generates a YAML file that gets applied) @@ -34,19 +34,25 @@ - control who can push to which branches - - have formal review processes, pull requests ... + - have formal review processes, pull requests, test gates... --- ## Enabling git-based workflows -- There are a many tools out there to help us do that +- There are a many tools out there to help us do that; with different approaches - (examples: [ArgoCD], [FluxCD]...) +- "Git host centric" approach: GitHub Actions, GitLab... -- There are also *many* integrations with popular CI/CD systems + *the workflows/action are directly initiated by the git platform* - (e.g.: GitHub Actions, GitLab, Jenkins...) +- "Kubernetes cluster centric" approach: [ArgoCD], [FluxCD].. + + *controllers run on our clusters and trigger on repo updates* + +- This is not an exhaustive list (see also: Jenkins) + +- We're going to talk mostly about "Kubernetes cluster centric" approaches here [ArgoCD]: https://argoproj.github.io/cd/ [Flux]: https://fluxcd.io/ @@ -173,6 +179,8 @@ So many different possibilities! (e.g. Kustomization, HelmRelease with Flux; Application with ArgoCD) +- We will call these resources "GitOps resources" + - These resources need to be managed like any other Kubernetes resource (YAML manifests, Kustomizations, Helm charts)