Cloud-nativ: GitOps Working Group als Community-Projekt bei der CNCF gestartet

Zum Fördern des GitOps-Paradigmas haben Amazon und Microsoft zusammen mit GitHub und den GitOps-Veteranen Weaveworks und Codefresh eine Arbeitsgruppe gestartet.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen

(Bild: Blackboard/Shutterstock.com)

Lesezeit: 3 Min.
Von
  • Rainald Menge-Sonnentag
Inhaltsverzeichnis

Die auf GitOps spezialisierten Unternehmen Weaveworks und Codefresh haben zusammen mit den Cloud-Anbieter Amazon und Microsoft sowie den Betreibern der Versionsverwaltungsplattform GitHub die GitOps Working Group gestartet. Die Arbeitsgruppe ist ein offenes Community-Projekt bei der Cloud Native Computing Foundation (CNCF).

Weaveworks hat den Begriff GitOps 2017 unter dem Schlagwort "Operations by Pull Requests" geprägt. Das GitOps-Paradigma kombiniert Continuous Delivery mit dem Ansatz, Infrastruktur über Code zu definieren (Infrastructure as Code, IaC). Dabei kommt der Versionsverwaltungssoftware Git eine tragende Rolle zu: Alle Informationen zur Konfiguration und zum Verteilen liegen in einem Git-Repository. Letzteres ist dabei der Single Point of Truth (SPoT).

GitOps spielt vor allem im Cloud-nativen Umfeld im Zusammenspiel mit Kubernetes eine Rolle. Zu den wichtigen Anbieter in dem Bereich gehören mit Weaveworks und Codefresh zwei Gründungsmitglieder der GitOps Working Group. Nennenswert ist daneben vor allem CloudBees mit Jenkins X.

Als Basis der Arbeitsgruppe dient die Flux Community aus dem der CNCF unterstellten Projekt Flux. Der Name ist das lateinische Wort für Fluss, und das Kernstück des Projekts ist ein Tool, das sicherstellen soll, dass der Zustand eines Kubernetes-Clusters der Beschreibung in einem Git-Repository entspricht. Ein eigener Operator im Cluster kümmert sich um das Verteilen der Software und Konfigurationen innerhalb von Kubernetes.

Die Arbeitsweise von Flux mit einem Opeartor, der die Synchronisation der Inhalte aus dem Git-Repository mit dem Kubernetes-Cluster ist ein Musterbeispiel für das GitOps-Paradigma.

(Bild: Fluxcd auf GitHub)

Die Cloud Native Computing Foundation hat im Rahmen ihres Technology Radar zu Continuous Delivery im Juni Flux neben Helm in der Kategorie "Adopt" einsortiert, was einer Empfehlung zum Anwenden der Technik entspricht.

Zu den kurzfristigen Zielen der Arbeitsgruppe gehört das Erstellen eines "GitOps Manifesto". Seit dem legendären Agile Manifesto gehören entsprechende Manifeste zum guten Ton: 2020 sind unter anderem das Low Code und das BizOps Manifesto entstanden.

Die Gruppe möchte mit dem GitOps Manifesto klare Prinzipien und die technischen Aspekte des Ansatzes niederschreiben. Es soll herstellerneutral sein und sich allgemein geteilten Grundsätzen statt individuellen Ansichten widmen. Auf technischer Seite soll es nicht individuellen Code, Tools oder Tests vorschreiben, sondern die zu erstrebenswerten Ergebnisse erläutern.

Der Blogbeitrag zum Start der GitOps Working Group definiert fünf Prinzipien für das Paradigma:

  • Deklarative Konfiguration: Alle Ressourcen müssen vollständig deklariert sein.
  • Versionskontrolle und unveränderlicher Storage: Die Beschreibungen sind in einem Repository abgelegt, das unveränderbare Speicherung und Versionierung bietet.
  • Automatisierte Verteilung: Die Umsetzung der Beschreibungen aus dem Repository in die Laufzeitumgebung muss vollständig automatisiert erfolgen.
  • Softwareagenten: Sie gleichen den Zustand des Systems ab und stellen die in der Deklaration beschriebenen Ressourcen bereit.
  • Geschlossener Kreislauf: Sobald Abweichungen zwischen der deklarativen Konfiguration und dem Ist-Zustand des Systems auftreten, werden passende Aktionen ausgelöst.

Weitere Details zu der neu gegründeten Arbeitsgruppe lassen sich dem Blogbeitrag von Weaveworks entnehmen. Das Schlagwort GitOps 2.0, das Codefresh Mitte November ins Spiel gebracht hat, findet darin allerdings zunächst keine Erwähnung.

(rme)