This repo collects some patterns (AKA strategies, models, approaches, best practices, etc.) about GitOps process design (AKA GitOps repository structures, etc.) as well as links to talks, articles and example repos.
It originated in schnatterer's talk about the "perfect" GitOps process, our experience in consulting, and our GitOps trainings for both Flux and ArgoCD.
You can read more about the patterns in this series of articles.
PRs welcome!
- Articles
- Pattern categories
- GitOps Patterns
- Operator deployment
- Repository structure
- Monorepo
- Repo per Team
- Repo per Application (can be implemented via Repo Separation, Config Replication, Repo Pointer or Config Split)
- Repo per Environment
- Promotion
- Wiring
- Bootstrapping
- Linking, includes Nesting (e.g. App of Apps), Templating
- Public GitOps Repo Examples
- Synonyms
- References
Part 1️⃣: GitOps Chasm + categories | |
Part 2️⃣: Deployment patterns | |
Part 3️⃣: Repo patterns | |
Part 4️⃣: Promotion patterns | |
Part 5️⃣: Wiring patterns + conclusion | |
Part 6️⃣: Example Repositories |
Let's group GitOps patterns into separate categories to make them easier to grasp.
See also part 1️⃣ of the article series.
- Operator deployment: GitOps operators ↔ Clusters/Namespaces
- Repository: How many repos?
- Promotion:
- Environments: How to model environments/stages?
- Implementation: How to implement the actual process of promotion?
- Wiring: Bootstrapping operator, linking repos and folders
See also part 2️⃣ of the article series.
- Hub and Spoke 12 1 Operator : n Clusters
Synonyms: Management Cluster 3 - sounds familiar, e.g. from Cluster API, but it requires a cluster. In SaaS/PaaS constellations, the central instance may not even be operated in a cluster. Therefore, the term "Hub and Spoke" seems more fitting to us, especially since it is also well known from computer networks or logistics.
- Instance Per Cluster 3 : 1 Operator : 1 Cluster
Synonyms: Standalone 1 - could apply to both "Instance per Cluster" and "Instance per Namespace"; does not define the relationship to clusters and namespaces precisely enough, as not every operator supports both deployment patterns.
- Instance per Namespace: n Operators : 1 Cluster
Synonyms: Namespaced 4
More Patterns:
- Split-Instance1: 1 Operator : n Clusters; components split between management and target clusters
- Hybrids of Hub and Spoke and Instance per Cluster patterns: "Instance per Logical Group" and "Argo Managing more Argos".3
See also part 3️⃣ of the article series.
- Monorepo 25
Opposite: polyrepo 2 - Repo per Team 5
More generalized: Team ➡️ Tenant5 - Repo per Application 25
Implementations:- Repo separation 6
Keep code in app repo, config in config repo
- Config replication 4
Keep config in app repo and have CI server replicate it to the config repo
- Repo pointer 745
Keep the whole config in app repo and add a pointer from config repo (e.g. Argo CDApplication
or a FluxGitRepository
+Kustomization
), avoiding redundancy
- Config Split 8
Keep parts of the config in app repo (e.g. helm chart or kustomize base), and rest in config repo (e.g.value.yaml
s or overlays for different envs).
Then have the config repo point to the app repo (e.g. via ArgoCDApplication
or FluxKustomization
).
Alternative implementations: have CI server push chart to helm registry
Or use push helm chart to OCI registry
Or use any config management tool (e.g.helm template
,kustomize build
,kubectl kustomize
, jsonnet, cuelang, timoni, etc. ) on the CI server for pushing the final manifests as OCI artifacts9 to the registry (Rendered Manifests Pattern10).
Then have the config repo point to the OCI artifact (e.g. via FluxKustomization
).
This way, the OCI registry functions as a "GitOps Cache"11:
The operator only needs to pull the artifacts instead of rendering/overlaying the config from different sources.
- Repo separation 6
- Repo per environment 5
Synonym: Environment per repository12, Repo per Stage
See also part 4️⃣ of the article series.
We understand the term "promotion" as the process of deploying applications to different environments.
Sometimes, the term "promotion" is prefixed with other words: Release/Application/Environment/Workload/Change.
For promotion, we see different sets of patterns:
- one regarding the modelling of environments and
- one regarding the implementation of the actual process of promotion.
- Folder/Directory per environment
Synonym: Environment per folder 12 - Repo per environment 5
Synonym: Environment per repo 12 - Branch per environment
Synonym: Environment per branch 12
Often discouraged 7 or declared an anti-pattern1314, but can work 15. - Preview environments 16 17 18
Synonyms: ephemeral, dynamic, pull request19, test, temporary16
Beyond the GitOps world also known as "Preview Deployments"20 and "Deploy Previews"21
- Configuration Management
- Synonyms:
- General: Templating, Patching, Overlay, Rendering, Hydrating
- templates = dry; rendered = hydrated 22
- Where to render the manifests?
- On the CI Server (Rendered Manifests Pattern10)
This pattern also fits nicely with Flux's OCI artifacts feature (see Config split). - On the GitOps Operator (GitOps Operator Rendering or GitOps Controller Rendering23)
- On the CI Server (Rendered Manifests Pattern10)
- Tools:
- Kustomize
- Plain
kustomization.yaml
- operator-agnostic (GitOps Operator Rendering on Argo CD and Flux) - ≠ Flux CRD
Kustomization
(GitOps Operator Rendering) kustomize build
/kubectl kustomize
via CI server (Rendered Manifests)
- Plain
- Helm
- CRD such as
HelmRelease
(GitOps Operator Rendering on Flux) orApplication
(GitOps Operator Rendering on ArgoCD) - Umbrella Chart24 (common on Argo CD, possible but unusual on Flux)
helm template
on CI server (Rendered Manifests)
- CRD such as
- Others, e.g. Jsonnet, CueLang, Timoni
- Rendered Manifests Pattern
- Argo CD Config Management Plugins25 (built-in for JSonnet)
- Kustomize
- Synonyms:
- Global Environments vs Environment per App4
- Config update
Who updates image (version) in GitOps repo, creates branch and PR?
See also part 5️⃣ of the article series.
- Bootstrapping ,
e.g. using
kubectl
or operator-specific CLI such asflux
orargocd-autopilot
- Linking
e.g. using Operator-specific CRDs such as
Kustomization
(Flux) orApplication
(ArgoCD)- Nesting, e.g. App of Apps pattern 26 (ArgoCD)
- Templating, e.g. implemented using
ApplicationSets
See also 4.
See also part 6️⃣ of the article series.
The diagrams have been created with tree2svg.
- Repo pattern: Per team mixed with per app (implemented via Config Replication)
- Operator pattern: Instance per Cluster (Hub and Spoke also possible)
- Operator: ArgoCD (Flux)
- Boostrapping:
Helm
,kubectl
- Linking: ArgoCD
Application
- Features:
- Operate ArgoCD with GitOps
- Solution for cross-cutting infra (cluster resources)
- Multi-tenancy: Single operator manages multiple tenants on one cluster using namespace environments (multi-cluster possible)
- Mixed repo patterns
- Config Update and Config Replication via CI server (Rendered Manifest using Helm)
- Env per app Pattern
argoproj-labs/argocd-autopilot
- Repo pattern: Monorepo
- Operator pattern: Instance per Cluster / Hub and Spoke
- Operator: ArgoCD
- Boostrapping:
argocd-autopilot
- Linking:
kustomization.yaml
, ArgoCDApplication
,ApplicationSet
- Features:
- Create structure and YAML via CLI
- Operate ArgoCD with GitOps
- Solution for cross-cutting infra (cluster resources)
- Env per app Pattern
fluxcd/flux2-kustomize-helm-example
- Repo pattern: Monorepo
- Operator pattern: Instance per Cluster
- Operator: Flux
- Boostrapping:
flux
CLI - Linking:
kustomization.yaml
, FluxKustomization
- Features:
- Operate Flux with GitOps
- Solution for cross-cutting infra (cluster resources)
- Repo pattern: Repo per team/tenant
- Operator pattern: Instance per Cluster
- Operator: Flux
- Boostrapping:
flux
CLI - Linking:
kustomization.yaml
, FluxKustomization
- Features:
- Operate Flux with GitOps
- Solution for cross-cutting infra (cluster resources)
- Multi-tenancy: One operator per cluster environment manages multiple tenants
christianh814/example-kubernetes-go-repo
christianh814/example-kubernetes-goflux-repo
christianh814/example-openshift-go-repo
- Repo pattern: Monorepo
- Operator pattern: Instance per Cluster
- Operator: Argo CD, Flux
- Boostrapping: kubectl
- Linking:
kustomization.yaml
,- ArgoCD
Application
,ApplicationSet
/ - Flux
Kustomization
- ArgoCD
- Features:
- Cross-cutting infra and app(s)
- ArgoCD and Flux examples
- Env per app Pattern
kostis-codefresh/gitops-environment-promotion
- Operator: ArgoCD (Flux)
- Linking:
kustomization.yaml
- Features:
- Env variants for single app
- Promotion "via cp"
- Env per app Pattern
kostis-codefresh/many-appsets-demo
- Operator: Argo CD
- Linking:
kustomization.yaml
, Argo CDApplicationSet
, (Application
) - Features:
- Env variants for multiple apps with few appSets
- Promotion "via cp"
- Env per app Pattern
Here are some other examples that we haven't had a chance to look at in more detail:
- Patterns ≈ strategies, models, approaches, best practices, standards
- GitOps process design ≈ GitOps repository structures,
- GitOps Operator ≈ GitOps controller ≈ GitOps agent
- Config Repo = GitOps repo, Infra repo, Payload repo
- App repo = Source code repo, Source repo
- Environment = Stage
- Folder = Directory
- Templating ≈ Patching, Overlay, Rendering, Bundling, Packaging?
Footnotes
-
Article A Comprehensive Overview of Argo CD Architectures – 2023 by Dan Garfield ↩ ↩2 ↩3
-
Article/Book How to set up your GitOps directory structure by Christian Hernandez ↩ ↩2 ↩3 ↩4
-
Talk Control Plane, Service, or Both? – Argo CD Multi-Cluster Architectures - Nicholas Morey, Akuity, Article How many do you need? - Argo CD Architectures Explained by Nicholas Morey ↩ ↩2 ↩3
-
Slides The perfect GitOps process: repos, folders, stages, patterns by Johannes Schnatterer ↩ ↩2 ↩3 ↩4 ↩5
-
Documentation Flux | Ways of structuring your repositories ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Documentation Argo CD: Best Practices ↩
-
Talk GitOps: Core Concepts & Ways of Structuring Your Repos by Pinky Ravi and Scott Rigby ↩ ↩2
-
Discussion on LinkedIn Benjamin Ruland and Johannes Schnatterer ↩
-
Documentation Flux | OCI cheatsheet ↩
-
Talk: GitOpsCon EU 23: The Art of GitOps: Rendered Manifests by Christian Hernandez ↩ ↩2
-
Talk: Mastering GitOps 2023: Keynote: GitOps Emerging Developments and Predictions by Alexis Richardson ↩
-
Lesson GitOps at Scale Lesson series - Git repository strategies by Codefresh (paywalled) ↩ ↩2 ↩3 ↩4
-
Article Stop Using Branches for Deploying to Different GitOps Environments by Kostis Kapelonis ↩
-
Article Git best practices: Workflows for GitOps deployments by Christian Hernandez ↩
-
Article Monitoring and Hardening the GitOps Delivery Pipeline with Flux by Florian Heubeck ↩
-
Article Creating Temporary Preview Environments Based On Pull Requests With Argo CD And Codefresh by Codefresh ↩ ↩2
-
Talk GitOps Con Europe - Implementing Preview Environments with GitOps in Kubernetes by François Le Pape, Remazing ↩
-
Talk Preview Environments with ArgoCD by Brandon Phillips ↩
-
Video Environments Based On Pull Requests (PRs): Using Argo CD To Apply GitOps Principles On Previews by Viktor Farcic ↩
-
Documentation Vercel: Preview Deployments ↩
-
Documentation Netlify: Deploy Previews ↩
-
Discussion on GitHub Michael Crenshaw ↩
-
Discussion on LinkedIn Christian Hernandez, Scott Rigby and Johannes Schnatterer ↩
-
Documentation Helm | Chart Development Tips and Tricks ↩
-
Documentation Argo CD | Config Management Plugins ↩
-
Documentation ArgoCD: Cluster Bootstrapping - App Of Apps Pattern ↩