github/container.training
1
0
Fork 0
mirror of https://github.com/jpetazzo/container.training.git synced 2026-07-28 01:01:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

🔥 Updates after @soulshake's reviews

Browse Source
This commit is contained in:
Jérôme Petazzoni
2024-06-09 18:55:59 +02:00
parent c550ea6553
commit 86d4dfa775
2 changed files with 24 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
slides/k8s/flux.md
View File

@@ -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
<br/>
(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`)
---

20
slides/k8s/gitworkflows.md
View File

@@ -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)