GitOps Repository Structures and Patterns Part 5: Wiring Patterns

In this series of articles, I am introducing you to different structures and patterns that you can use to design your GitOps process. This part is about wiring patterns. You can get an overview of GitOps repository patterns and structures in the first part of this series, in the second part I introduce operator deployment patterns and in the third part repository patterns and in the fourth part promotion patterns. In the sixth part I show different implementations of the structures and patterns using example repositories. This part of the series is about how the GitOps operator is wired to the repositories, folders, environments, etc.

The first step in this is to bootstrap the GitOps operator. This involves installing the GitOps operator in the cluster and setting it up to point to an initial GitOps repo. Ideally, the configuration of the GitOps operator is also stored in Git, so that updates and changes to the configuration of the GitOps operator can be made via GitOps in the future. Bootstrapping can be implemented via kubectl, but usually there are special command line tools for the respective GitOps operators that are easier to use.

Bootstrapping is followed by linking, i.e. connecting further repositories, folders or branches. This is often accompanied by grouping, i.e. the grouping of certain resources, for example everything that belongs to an application or an environment. Both linking and grouping are typically done using specific CRDs, for example, the Kustomization in Flux and the Application in Argo CD.

Linking is often done in a nested manner (nesting). Argo CD has its own designation for this pattern: "App Of Apps". The first Application created during bootstrapping is used to deploy further Applications, each of which can contain further Applications. In Flux, the same procedure is common with Kustomizations, but there is no separate name for it.

The use of templating for linking and grouping is new. This is the same principle as for preview environments. In Argo CD, for example, there are other generators in addition to the PR generator. Thus, for example, environments can be modeled as folders and the generator then creates an Application for each folder. Further options are the generation on the basis of lists in the ApplicationSet or even config files in the GitOps Repo.

Conclusion and Outlook

On the basis of recurring elements of existing GitOps tools, this series of articles describes GitOps patterns and classifies them into the four categories of operator deployment, repository, promotion and wiring. The patterns provide an overview and offer aspects to consider for the different options when making design decisions for the GitOps process and the structure of the associated repositories. Secondly, they can help to find terminology for the respective patterns, to standardize them and to help with communication.

Many of the things described here can be easily tried out with the GitOps Playground.

In the sixth part of this series, I will give practical examples of the patterns. These provide templates, ideas and tips for your own projects and show practical examples for the patterns described here.