GitOps repository with a dummy application for demonstration purposes. Related to article: https://medium.com/bumble-tech/gitops-for-multi-cluster-k8s-environments-d305431ba6d6
βββ base
βΒ Β βββ hello-app
βΒ Β βββ base
βΒ Β βΒ Β βββ kustomization.yaml
βΒ Β βΒ Β βββ manifest.yaml
βΒ Β βββ bumble-overlay
βΒ Β βββ kustomization.yaml
βΒ Β βββ patches
βΒ Β βββ bumble_patch.yaml
βββ overlays
βββ zone-1
βΒ Β βββ argocd-applications
βΒ Β βΒ Β βββ hello-app.yaml
βΒ Β βββ hello-app
βΒ Β βΒ Β βββ kustomization.yaml
βΒ Β βΒ Β βββ params.env
βΒ Β βΒ Β βββ params.yaml
βΒ Β βββ kustomization.yaml
βββ zone-2
βββ argocd-applications
βΒ Β βββ hello-app.yaml
βββ hello-app
βΒ Β βββ kustomization.yaml
βΒ Β βββ params.env
βΒ Β βββ params.yaml
βββ kustomization.yaml
This repo serves as an example of how to apply two-level overlay structure to a GitOps repo.
hello-app
is one of our applications.base/hello-app/bumble-overlay
contains a company-specific overlay that:- Updates image of container to
bash:latest
- Replaces
DRAGON_NAME
environment variable with a placeholder that we're filling in zone overlays
- Updates image of container to
overlays/zone-1/hello-app
contains a zone-specific overlay forhello-app
that replaces theDRAGON_NAME
placeholder with a name of the dragon specified inoverlays/zone-1/hello-app/params.env
By following these simple steps, we've introduced two changes to the base resource:
- company-specific but zone-agnostic change
- zone-specific change
Leaving the resource itself as is.
So, with this structure, both company-specific and zone-specific changes are transparent and clear, and next time we need hello-app
upgraded, we're just replacing base/manifest.yaml
with the one provided by developer. Same applies to more complex resources.
You may need to disable load restrictor by passing --load-restrictor none
or --load-restrictor LoadRestrictionsNone
to kustomize.