GitOps-Repository-Strukturen und -Patterns Teil 5: Verdrahtungs-Patterns
In dieser Artikelserie stelle ich Ihnen unterschiedliche Strukturen und Patterns vor, die Sie nutzen können, um Ihren GitOps-Prozess zu designen. In diesem Teil geht es um Verdrahtungs-Patterns. Eine Einführung in die Thematik der GitOps-Repository-Patterns und -Strukturen bekommen Sie im ersten Teil dieser Serie, im zweiten Teil stelle ich Operator-Deployment-Patterns vor, im dritten Teil Repository Patterns und im vierten Teil Promotion Patterns. Im sechsten Teil zeige ich unterschiedliche Umsetzungen der Strukturen und Patterns anhand von Beispiel-Repositories.
Dieser Teil der Serie beschäftigt sich damit, wie der GitOps-Operator mit den Repositories, Ordnern, Environments, etc. verdrahtet wird.
Der erste Schritt dabei ist das „Bootstrapping“ des GitOps-Operators. Dabei wird der GitOps-Operator in den Cluster installiert und so eingerichtet, dass er auf ein erstes GitOps-Repo zeigt. Idealerweise wird auch die Konfiguration des GitOps-Operators in Git abgebildet, sodass zukünftig auch Updates und Änderungen an der Konfiguration des GitOps-Operators per GitOps erfolgen können. Das Bootstrapping kann per kubectl realisiert werden, meist gibt es aber spezielle Kommandozeilen-Tools für die jeweiligen GitOps-Operatoren, die einfacher zu benutzen sind.
Nach dem Bootstrapping erfolgt das „Linking“, also das Anbinden weiterer Repositories, Ordner oder Branches. Damit einhergehend ist oft das „Grouping“, die Gruppierung bestimmter Ressourcen, beispielsweise alles, was einer Anwendung oder einem Environment zugehörig ist. Sowohl Linking als auch Grouping erfolgen typischerweise mittels spezifischer CRDs, beispielsweise der Kustomization bei Flux und der Application bei Argo CD.
Das Linking erfolgt oft geschachtelt („Nesting“). Bei Argo CD gibt es für dieses Pattern eine eigene Bezeichnung: „App Of Apps“. Mit der ersten Application, die man beim Bootstrapping angelegt hat, deployt man weitere Applications, die jeweils noch weitere Applications beinhalten können.
Bei Flux ist das gleiche Vorgehen mit Kustomizations gängig, allerdings gibt es dafür keine eigene Bezeichnung.
Neu ist die Verwendung von „Templating“ beim Linking und Grouping. Hier handelt es sich um dasselbe Prinzip wie bei Preview Environments. Bei Argo CD gibt es beispielsweise neben dem PR-Generator noch weitere Generatoren.
Dadurch können beispielsweise Environments als Ordern modelliert werden und der Generator erzeugt dann für jeden Ordner eine Application. Weitere Optionen sind die Generierung auf Basis von Listen im ApplicationSet oder sogar Config Files im GitOps-Repo.
Fazit und Ausblick
Anhand wiederkehrender Elemente bestehender GitOps-Tools beschreibt diese Artikelserie GitOps-Patterns und ordnet sie in die vier Kategorien Operator Deployment, Repository, Promotion und Verdrahtung ein. Die Patterns geben nicht nur einen Überblick über die Möglichkeiten bei Design-Entscheidungen für den GitOps-Prozess, für die Struktur der zugehörigen Repositories und was dabei zu beachten ist. Sie können auch dazu beitragen, Begriffe für die jeweiligen Patterns zu finden, diese zu vereinheitlichen und die Kommunikation zu erleichtern.
Vieles von dem hier beschriebenen lässt sich mit dem GitOps Playground einfach ausprobieren.
In [einem weiteren Teil dieser Serie]("Beispiel Repositories für GitOps-Repository-Strukturen und -Patterns | Cloudogu Blog" /de/blog/gitops-repository-patterns-teil-6-beispiele) werde ich noch Beispiele aus der Praxis für die Patterns beschreiben. Diese liefern Vorlagen, Ideen und Tipps für eigene Projekte und zeigen Praxis-Beispiele für die hier beschriebenen Patterns.