GitOps ist eine Art und Weise DevOps zu praktizieren. GitOps ermöglicht über versionierte Sets von deklarativen Spezifikationen eine Kontinuität in den ganzen Entwicklung- und Inbetriebssetzungsprozess zu bringen. Dadurch hat das ganze Entwicklungsteam ein besseren Durchblick bei der Integration und dem Ausrollen ihrer Applikation(en).
Komponenten von GitOps
Bei GitOps gibt es folgende etablierte Komponenten, die man sicherlich vor dem Aufsetzen einer GitOps-Infrastruktur verstehen muss:
-
Infrastructure-as-Code (IaC) GitOps nutzt Git Repositories als die einzige Instanz von Wahrheitsanspruch, auf Englisch ‘single source of truth’. Das heisst das alles was über eine Repository versioniert ist, entspricht auch dem, was tatsächlich genutzt wird. Im Umkehrsatz heisst, dass das alle relevante Informationen und Konfigurationen in einer Repository abgelegt sein müssen. Nicht nur Quellcode von Applikationen, sondern eben auch von ganzen Infrastrukturen und Applikationsumgebungen soll somit auf eine deklaritive Weise festgemacht werden.
-
Merge Requests (MRs) GitOps macht starken Nutzen von sogenannten Merge Requests. Ein Merge Request ist ein Git-Mechanismus der Entwicklungsverzweigungen (Branches) zusammenführt (merged). Somit ist eine Kontroll- und Verwaltungsinstanz vorhanden welche nativ per Git prüft wann und wie sich ein Entiwcklungszustand ändern darf. Jede Veränderung an den Bestandteilen einer Infrastruktur kann somit getracked und entsprechend effizienter verwaltet werden.
-
Continuous Integration & Continuous Delivery (CI/CD) Schliesslich nutzt GitOps die Automatisierungsmechanismen von klassischem CI/CD. Sobald neuer deklarativer Code per Merge Request akzeptiert und gemerged wurde, kann ein automatisierter Vorgang den beschreibenden Zustand eine Pipeline anstossen, die die Infrastruktur entsprechend anpasst. Manuelle Anpassungen werden somit stets durch den GitOps-Automatismus überschrieben und haben minimal möglichsten Effekt.
Tools zur Umsetzung von GitOps
GitOps macht bei Infrastrukturen in der Cloud besonders Sinn, da dort viele maschinennahe Operationen bereits auf eine Art und Weise abstrahiert oder gar automatisiert sind. Somit ist bereits ein gewisse Awareness von CI/CD vorhanden. Trotzdem möchten wir kurz aufzeigen, worauf es bei optimal gelebtem GitOps ankommt.
Pipeline
Neben der Nutzung von Git Repositories braucht es eine dedizierte Pipeline. Dies kann beispielsweise Jenkins, CircleCi oder Tekton sein. Die Pipeline sorgt für den Gap zwischen dem Git-basierten Pull Request und der Orchestrierung der Infrastruktur. Über sogenannte Hooks werden, sobald ein Merge Request akzeptiert werden sogleich die entsprechende Pipeline angestossen welchen den Zustand baut und direkt auf die Infrastruktur ausrollt.
Best Practices
- Deklarative Beschreibung der Infrastruktur (IaC)
- Immutable Ausrollen
- Versionierung und Kontrolle von Code und Konfiguration
- Funktionalität für Rollback
- Operationale Veränderung nur durch Pull Requests
- Jedes Build-Artefakt soll es nur einmal geben, Update-Mechanismus am besten deklarativ und automatisiert
- Monitoring des ganzen Prozesses sowie der Infrastruktur
- Komplett automatisierte Delivery Pipeline
Fazit
GitOps ist nicht nur ein Hype-Wort der letzten Jahre, sondern ein solides Konzept wie man DevOps in einem Unternehmen leben kann. Als Entwickler ist es problemlos möglich, yaml-Files in ein Git-Repository zu pushen und diese an einer Pipeline wie Jenkins oder Tekton anzufügen. Diese nimmt anschliessend jegliche Änderungen an einem Container-Cluster wie Kubernetes vor. So einfach die Logik. Wir bei b-nova sind von dem Konzept überzeugt und werden die Spur die an ein erprobtes Verstädnis von GitOps führen dran bleiben und hoffen auch bei Ihnen die ersten GitOps-fähigen Konzepte einführen zu dürfen.