Seite 2: Schritt für Schritt zu GitOps

Inhaltsverzeichnis

Der Vorbereitungsaufwand für GitOps ist groß und variiert abhängig von den bestehenden Prozessen, der vorhandenen Infrastruktur und dem Wissensstand. Generell ist empfehlenswert, nicht alle Anwendungen gleichzeitig auf GitOps umzustellen. Wer Schritt für Schritt vorgeht, sammelt Erfahrung und kann getroffene Entscheidung validieren und beim nächsten Mal korrigieren.

1. Wissen aufbauen: Die Teams müssen Git als Versionierungstool beherrschen, deklarative Konfigurationen verstehen und das GitOps-Konzept verinnerlicht haben.
2. Werkzeuge auswählen: Aus dem Portfolio der GitOps-Tools gilt es, die geeignete Auswahl zu treffen. Kandidaten sind unter anderem ArgoCD, Flux oder Jenkins X.
3. Repositories einrichten: Sowohl für die Konfigurationsdateien der Anwendung als auch der Infrastruktur müssen die Teams ein oder mehrere Repositories einrichten und die Zugriffsrechte konfigurieren.
4. Konfiguration konvertieren: Die Teams müssen bestehende Konfigurationen und Einstellungen aus GUIs und anderen Quellen zusammentragen und in die jeweiligen Konfigurationsdateien überführen.
5. Automatisierung einrichten: Der gesamte Build- und Bereitstellungsprozess muss Änderungen an den Repositories überwachen. Die Teams legen dazu eine Strategie fest, in welchen Änderungssituationen welche Automatisierungen starten sollen.
6. Umgebung einrichten: Die Teams bauen nun eine separate Umgebung, etwa basierend auf Kubernetes-Clustern, für Entwicklung, Test, Produktion und Ähnliches auf. So lassen sich Konfigurationen schrittweise testen und freischalten.
7. Sicherheit mitdenken: Richtlinien entscheiden darüber, wie einzelne Teams und Teammitglieder in den GitOps-Workflow eingreifen dürfen.
8. Überwachung starten: Tools und Dienste zur Überwachung und Protokollierung verschaffen einen Zustandsüberblick. Daraus resultierende automatisierte Benachrichtigungen und Alarme per Microsoft Teams oder E-Mail sollten so informieren, dass Administratorinnen und Administratoren sofort eingreifen können.
9. Schulungen durchführen: Die Teams und Teammitglieder müssen nun den Umgang mit den Werkzeugen erlernen. Gleichzeitig gilt es, Feedback einzusammeln, um den GitOps-Workflow insgesamt zu verbessern.
10. Monitoring einführen: Je mehr Daten protokolliert sind, desto mehr Details lassen sich ableiten, Informationen gewinnen und Erkenntnisse ziehen. Diese können Build-Zeiten reduzieren, Betriebskosten reduzieren sowie die Stabilität und Sicherheit verbessern.

Nachteile von GitOps

GitOps kommt jedoch nicht ohne Kompromisse aus.

Steile Lernkurve: Für das GitOps-Konzept müssen Teams sich mit neuen Konzepten und Werkzeugen auseinandersetzen. Es gilt also eine Lernkurve zu meistern, die für Plattformteams anfangs besonders steil ist: Vor allem müssen sie die Konzepte zusammensuchen, verstehen und auf den Unternehmenskontext sowie dessen Infrastruktur übertragen. Dann gilt es, die entsprechenden Werkzeuge zusammenzustellen und notfalls anzupassen.

Schließlich müssen sie sehr genau planen, in welcher Form die Entwickler den Betriebszustand und dessen Eigenschaften beeinflussen dürfen. Je vielfältiger die Anwendungslandschaft des Unternehmens ist, desto herausfordernder ist es, einen einheitlichen Bereitstellungsprozess zu entwickeln und umzusetzen. Ist diese Hürde genommen, müssen die Plattformteams wiederum die Entwicklungsteams schulen und sie im Einsatz der Werkzeuge und Infrastruktur trainieren.

Starke Abhängigkeit: GitOps erhöht die Abhängigkeit von Werkzeugen, wodurch potenziell Lizenzkosten entstehen. Auch die Abhängigkeit zu Git steigt: Jedes Problem innerhalb eines Repository und jede Unterbrechung im Betrieb des Servers kann sich unter Umständen auf den gesamten Betriebszustand auswirken. Diese Situationen muss das Plattformteam einplanen und die Softwareagents entsprechend ausgestalten. Der banalste Fehlerfall: Der Agent kann nicht mehr auf das Repository zugreifen, die aktuelle Betriebskonfiguration nicht auslesen, keinen korrekten Ist-Soll-Vergleich durchführen und stellt – weil als Fehlersituation nicht vorgesehen – den Betrieb ein.

Komplexe Verwaltung: Zusätzliche Automatisierung und Autonomie bedeuten immer auch zusätzliche, verlagerte oder gebündelte Komplexität. Je mehr Konfigurationsmöglichkeiten bestehen, je mehr Anwendungen in den Betrieb zu bringen sind, je weiter sich die Anwendungen entwickeln, je mehr Entwicklerinnen und Entwickler involviert sind, desto komplexer wird die Verwaltung. Auch das wirkt sich insbesondere auf die Plattformteams aus, die den Gesamtüberblick haben müssen, während die Entwicklungsteams lediglich die Repositories für ihre Anwendung und ihre Konfigurationen im Blick behalten müssen.

Herausfordernde Integration: Die Integration in den existierenden Entwicklungsprozess ist nicht trivial. In den meisten Fällen sind Anpassungen fachlicher und technischer Prozesse und Werkzeuge unumgänglich. Hier gilt für die Plattformteams wieder die größere Last. Sie müssen womöglich unterschiedliche Hyperscaler einbinden und Private- sowie Public-Cloud-Umgebungen einbeziehen. Sie müssen die Softwareagents so programmieren und konditionieren, dass diese autonom agieren können. Denn jeder manuelle Eingriff bedeutet, dass die Vorteile von GitOps nicht vollständig ausgeschöpft werden. Verweigert ein Softwareagents die Arbeit, müssen die Plattformteams schnell reagieren und eingreifen können.