Suchen

GitOps-Tools in der Übersicht

| Autor / Redakteur: Mirco Lang / Stephan Augsten

GitOps beschäftigt Entwickler, Medien und IT-Manager – aber was bedeutet das überhaupt in der Kategorie der Tools und Lösungen? Ein Überblick über die wichtigsten Werkzeuge rund um den Pull-Request-Ansatz.

Firma zum Thema

Argo beim Synchronisieren.
Argo beim Synchronisieren.
(Bild: Argo CD)

Wir haben bereits den theoretischen Einstieg in die GitOps-Welt sowie die GitOps-Praxis mit dem Tool ArgoCD aufgezeigt. Ein gänzlich anderer Ansatz ist der Einblick über das Tooling.

Welche Tools gibt es also? Und welche Aufgaben erledigen sie? Wer viel Erfahrung mit unterschiedlichen Software-Produkten hat, entwickelt so vielleicht am schnellsten Verständnis und ein Gespür für GitOps.

ArgoCD

Argo beim Synchronisieren.
Argo beim Synchronisieren.
(Bild: Argo CD)

Continuous Delivery für Kubernetes: ArgoCD wird führend von Intuit entwickelt und synchronisiert Änderungen im Code von Anwendungen, Images und Cluster-Definitionen, also das Git-Repository, mit dem Cluster. Die Lösung ist Open-Source-Software, relativ einfach gehalten und gehört zu den wichtigsten und ältesten Tools am Markt.

Flux

Einbindung von Flux CD in den Workflow.
Einbindung von Flux CD in den Workflow.
(Bild: Weaveworks)

Flux erledigt grundsätzlich dieselbe Arbeit wie ArgoCD, synchronisiert also im Zuge des Continuous Delivery das Repository und Cluster. Auch Flux ist quelloffen und einfach gehalten – das Besondere: Es stammt vom GitOps-Erfinder Weaveworks.

GitOps Engine

Ende 2019 hat Weaveworks den Zusammenschluss von ArgoCD und Flux angekündigt. An dem neuen Projekt arbeiten neben Weaveworks und Intuit auch Entwickler von AWS und mit BlackRock als erstem Enterprise-Kunden ist ein weiteres Dickschiff mit an Bord.

Argo und Flux werden als Produkte bestehen bleiben und sich unter dem Namen GitOps Engine Quellcode teilen, der für folgende Aufgaben zuständig sein soll: Zugriff auf Git-Repositories, Cache für Kubernetes-Ressourcen, Erstellung von Manifesten, Ressourcenausgleich und Synchronisierungsplanung.

Atlantis

Atlantis ist ein Spezialist für das ebenfalls quelloffene Virtual-Datacenter-Tool Terraform: Änderungen werden auch hier freilich über Pull Requests initialisiert und Atlantis automatisiert den angehängten Workflow. Im Detail: Atlantis selbst führt die nötigen Terraform-Befehle aus, um die Umsetzung der Änderungen aus dem Repo zu planen und später anzuwenden. Nutzer interagieren hier also nur mit Git, um Pull Requests zu starten, zu verifizieren und letztlich zu mergen.

autoapply

Autoapply-Einordnung in GitOps.
Autoapply-Einordnung in GitOps.
(Bild: Autoapply)

Bei autoapply handelt sich um eine interessante Argo/Flux-Alternative für kleinere Projekte: Auch hier werden Repos und Cluster synchronisiert, allerdings ist die Software schlanker und einfacher gehalten. Die Konfiguration besteht im einfachsten Fall aus einer Handvoll Zeilen. Standardmäßig unterstützt autoapply aber schon Kubernetes-Secrets, wahlweise über das eigene yaml-crypt oder Mozilla SOPS (Secret Operations).

Flagger

GitOps-Workflow mit Flagger.
GitOps-Workflow mit Flagger.
(Bild: Flagger)

Und noch einmal Weaveworks: Von den GitOps-Vordenkern kommen diverse Tools und Flagger ist besonders interessant. Nach eigener Beschreibung ein „Progressive delivery Kubernetes operator“, hilft Flagger in mehrerer Hinsicht beim Deployment neuer Programmversionen.

Flagger unterstützt, je nach Zielplattform (Kubernetes, Istio, NGINX etc.), die Release-Strategien Canary, A/B Testing und Blue/Green, analysiert und lenkt dabei den Traffic der jeweiligen Versionen und alarmiert via Slack, Microsoft Teams, Discord oder Rocket. Flagger ist im Gegensatz zu den vorigen Tools lediglich ein Baustein, der sich gut in eine grundsätzliche GitOps-Kette einfügt.

Faros

Faros stammt vom britischen Anbieter Pusher und ist wie autoapply ein „simpler“ Syncer für Kubernetes-Cluster und die zugehörigen Repos – beziehungsweise will einer werden: Das Projekt befindet sich offiziell in einer frühen Alpha-Phase, derzeit also noch ein Proof of Concept ohne allzuviel Aktivität. Da Faros letztlich aber nur die Repo-Zugangsdaten und das Cluster benötigt, könnte es einen Blick wert sein.

Gitkube

Gitkube ermöglicht es Nutzern, Docker-Images zu erstellen und in einem Kubernetes-Cluster zu deployen – über ein simples „git push“. Automatische Synchronisation gibt es hier nicht, Gitkube bietet gewissermaßen manuelles GitOps. Empfohlen wird Gitkube zum Beispiel zum Testen von Work-in-Progress-Branches.

Kubestack

Bei Kubestack wird es nun deutlich komplexer: Das freie GitOps-Framework ermöglicht vollautomatische GitOps-Workflows in den Managed-Kubernetes-Umgebungen von AWS, Azure und Google Cloud über wiederverwendbare Terraform-Module und Kustomize-Konfigurationen.

Kurz gesagt übernimmt Kubestack die Verwaltung getrennter Umgebungen für App-Entwicklung und deklarativer Infrastruktur-Komponenten – gesteuert über GitOps-Workflows. Es hält also die Deklarationen gewünschter Zustände bereit und gibt sie an die APIs des jeweiligen Kubernetes-Betreibers weiter. Mit Kubestack lassen sich so über die verschiedenen Anbieter hinweg uniforme Cluster für zum Beispiel CI/CD mit ArgoCD aufbauen.

werf

Werfs eigene Darstellung zeigt, wie einfach GitOps sein kann.
Werfs eigene Darstellung zeigt, wie einfach GitOps sein kann.
(Bild: werf)

Mit werf, entwickelt vom DevOps-Outsourcer Flant, geht es wieder Richtung CI/CD und es wird auch wieder übersichtlicher. Untergebracht in einer einzelnen Binary unterstützt das CLI-Werkzeug den kompletten Lebenszyklus bei der App-Entwicklung: Erstellen und Veröffentlichen von Images, Deployment der Anwendungen und Bereinigung der Image-Registry.

Intern hat werf nichtsdestoweniger allerhand technischer Features zu bieten, etwa Entwicklung von Multi-Image-Apps oder GitLab-CI/CD-Integration. Das Projekt wird sehr aktiv entwickelt, ist aber durchaus noch in einer frühen Phase. Daher gibt es bislang auch noch keine CI/CD-Integrationen abseits von GitLab (die Top 10 sollen folgen), hier und da Verweise auf rein russische Dokumentation und ähnliche Kinderkrankheiten.

Jenkins X

Bei dem Namen Jenkins dürften viele Entwickler hellhörig werden, die Automatisierung für CI/CD ist schließlich äußerst populär. Jenkins X ist kurz gesagt die auf Kubernetes spezialisierte Variante (mit integriertem Jenkins). Jenkins X vereint Image-Registry, Helm-Charts, Docker, Kubernetes-API-Server, Verwaltung von Webhooks, das Building der Apps und natürlich die Verwaltung unterschiedlicher Umgebungen und dem Austausch zwischen diesen. Dazu gehören auch Vorschau-Umgebungen, um Pull Requests schnell und einfach prüfen zu können.

Der Zugriff erfolgt bei all dem über das Kommandozeilenwerkzeug „jx“, das viele übliche Kubernetes-Operationen vereinfacht anbietet. Darüber lassen sich zum Beispiel ganz konkret Webhooks, CD-Pipelines oder Cluster erstellen. Jenkins X sieht sich nicht explizit als GitOps-, sondern als DevOps-Plattform, die Standardisierung und Automatisierung auf Basis von Best Practices anbietet. Und da Weaveworks GitOps wiederum als genau solch ein DevOps-Best-Practice inklusive ein paar neuer Gimmicks beschreibt, wirkt das durchaus rund.

Apropos, ein besonders vielversprechendes Statement von Jenkins X: „Jenkins X wird standardmäßig großartige Pipelines für Ihre Projekte bereitstellen, die CI und CD vollständig implementieren.“ Jenkins X ist also nicht nur ein extrem umfangreiches Tool, das als zentrales GitOps-Organ agieren kann, sondern versucht dem Nutzer auch noch einen großen Teil der initialen Arbeit abzunehmen. Jedenfalls sollten Sie Jenkins X definitiv ins Auge fassen, wenn Sie sich ernsthaft mit dem Thema GitOps in einem größeren professionellen Umfeld beschäftigen.

Fazit

Explizite GitOps-Tools gibt es noch nicht allzu viele auf dem Markt, doch letztlich meint GitOps nicht viel mehr, als dass der Quellcode der App-Entwicklung und die für das Deployment nötigen deklarativen Dateien in ein und demselben Repo gepflegt werden und so eine mehr oder weniger automatische und aufwändige CI/CD ermöglichen.

Dieses Vorhaben lässt sich freilich auch mit bereits bekannten und etablierten Tools umsetzen. Im Grunde ist der Betrieb einer Website GitHub Pages und Jekyll bereits Entwicklung nach dem GitOps-Prinzip.

Dieser Beitrag erschien zuerst auf unserem Partnerportal Dev-Insider.de.

(ID:46726601)

Über den Autor

 Mirco Lang

Mirco Lang

Freier Journalist & BSIler