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.yamlThis repo serves as an example of how to apply two-level overlay structure to a GitOps repo.
hello-appis one of our applications.base/hello-app/bumble-overlaycontains a company-specific overlay that:- Updates image of container to
bash:latest - Replaces
DRAGON_NAMEenvironment variable with a placeholder that we're filling in zone overlays
- Updates image of container to
overlays/zone-1/hello-appcontains a zone-specific overlay forhello-appthat replaces theDRAGON_NAMEplaceholder 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.