Bedeutung
Der Begriff «GitOps» gehört zu DevOps, ist jedoch deutlich konkreter gefasst und zeigt den Einsatz von Git-Repositories bei der Entwicklung von cloudnativen Anwendungen und beim IT-Betrieb an. Entwicklerteams nutzen solche Speicherorte für Code, Dateien und Revisionen zur Verwaltung des Sollzustands einer Infrastruktur. Git-Repositories für die Infrastruktur bilden «die einzige Quelle der Wahrheit». Die GitOps-Methodik erlaubt das automatisierte Überwachen, Testen und Ausrollen von Änderungen und den laufenden Vergleich mit dem Ist-Zustand.
Ausgangslage
Die Geschwindigkeit der Softwareentwicklung hat im Zuge der digitalen Transformation vieler Bereiche des Lebens und Arbeitens stark zugenommen. Man kann sogar feststellen, dass wir in einer softwaredefinierten Welt leben, in der Erfolg oder Misserfolg von Qualität und Tempo der Entwicklung abhängig sind. Das setzt die Entwickler unter Druck, immer neue Konzepte und Tools für mehr Effizienz zu finden. GitOps ist nun ein relativ neues Konzept, bei dem der IT-Betrieb weiter als bisher automatisiert wird. Bei Abraxas spielt GitOps seit mehreren Jahren eine zentrale Rolle bei der Bereitstellung von Applikationen und Infrastruktur – heute basieren die meisten Neuentwicklungen auf der GitOps-Methodik. Die entsprechenden Vorgaben haben sich im ganzen Unternehmen etabliert.
Geschichte
«Git» ist ein 2005 von Linux-Vater Linus Torvalds entwickeltes Werkzeug zur Versionsverwaltung von Dateien, das ohne zentrale Server auskommt und «Pull Requests» ins Zentrum des Workflows stellt. Den Begriff «GitOps» hat schliesslich die Firma Weaveworks 2017 geprägt. Ursprünglich im Kubernetes-Umfeld entstanden, lässt sich GitOps heute auch mit anderen Betriebsumgebungen nutzen.
How did GitOps get started? An interview with Alexis Richardson
Deep Dive
GitOps umfasst Tools und ein Framework, um mithilfe von Git-Pull-Anfragen Änderungen an der Systeminfrastruktur zu überprüfen und automatisch bereitzustellen. Mit einem «Pull Request» bittet ein Entwickler darum, einen seiner Codes in einen anderen Zweig der Codebasis zu integrieren.
GitOps ist konkreter als DevOps. Es handelt sich um Workflows und Abläufe, den IT-Betrieb zu automatisieren. GitOps kann auch für sich allein umgesetzt werden, setzt mehrere Praktiken wie Infrastructure as Code (IaC), Configuration as Code und Konfigurationsmanagement konsequent durch. Im Unterschied zu anderen Ansätzen holt sich die Betriebsumgebung ihren Zustand direkt aus dem Git-Repository; Abweichungen zum Zielzustand werden automatisch korrigiert.
Zur Implementierung stehen viele Werkzeuge zur Verfügung. Auch kann eine andere Versionskontrollsoftware als Git eingesetzt werden.
Die wichtigsten Merkmale von GitOps sind:
- Git dient als zentrale Quelle für die Definition von Infrastruktur und Anwendungen. Alle gewünschten Zustände sind in Git-Repositories gespeichert.
- Anstatt prozeduraler Skripte mit Schritt-für-Schritt-Vorgaben werden deklarative Konfigurationen verwendet. Diese beschreiben nur den Sollzustand. Anders gesagt: Ein Grossteil der GitOps-Kern-Codebasis besteht aus deklarativen Konfigurationsdateien und nicht aus ausführbarem Code.
- Automatisierung und Synchronisation zwischen aktuellem und gewünschtem Zustand mittels pullbasierter Mechanismen – die Infrastruktur aktualisiert sich selbst.
- Versionskontrolle und Transparenz: Jede Änderung an der Infrastruktur wird dokumentiert. Das erleichtert Debugging, Audits und das Zurücksetzen auf frühere Zustände.
Ein Beispiel für einen GitOps-Ablauf:
Ein Team bemerkt Performance-Probleme beim Load Balancer. Nach Überprüfung der Konfiguration im GitOps-Repository ist klar: Die Werte für die CPU-Ressourcenlimiten müssen angepasst werden.
Ein Teammitglied erstellt einen Pull Request («Pull-Anfrage») mit den verbesserten Werten. Nach Genehmigung und Merge löst dies die GitOps-Pipeline aus. Der Operator erkennt die Änderung und veranlasst das Update über das Orchestrierungssystem.
Beschliesst nun das Team, einen komplett neuen Load-Balancer-Typ zu implementieren, wird derselbe Workflow genutzt: Pull Request, Review, Merge. Würde der neue Typ Probleme verursachen, kann das Team dank GitOps rasch zum vorherigen funktionierenden Stand zurückkehren.
Was sind die grössten Hindernisse bei der Einführung von GitOps? Die wichtigste Herausforderung ist die Schulung der DevOps-Engineers in der deklarativen Konfigurationsweise. Diese Methodik erfordert ein grundlegendes Umdenken im Vergleich zu klassischen manuellen oder skriptbasierten Deployment-Methoden. Mit GitOps erweitern sich auch die Verantwortlichkeiten der DevOps-Engineers: Sie übernehmen Aufgaben, die früher dedizierte Betriebsteams ausführten, und definieren diese zentral auf deklarativer Basis – stets unter Beachtung des Least-Privilege-Prinzips bei den Zugriffsberechtigungen.
Wirkung
Entwicklungsteams sind bereits vertraut mit Git-basierten Workflows. Somit können die bestehenden Prozesse bis zur Infrastrukturkonfiguration durchgezogen werden. Die mehrjährige Erfahrung von Abraxas bestätigt die Wirkung der GitOps-Methodik: Dank Standardisierung steigert sich die Effizienz der Entwicklung, harmonisierte Methoden ermöglichen eine zentrale Problemlösung und nachhaltige Implementierung. Die teamübergreifende Zusammenarbeit verbessert sich. Treten Fehler auf, lassen sich diese effizient finden. Das Umgebungsmanagement stellt sich durch die deklarative Konfiguration einfacher dar.
Weitere Vorteile des GitOps-Ansatzes:
- Auditierungen und Reproduzierbarkeit sind stark verbessert. Probleme lassen sich präzise lokalisieren.
- Mehr Sicherheit, da keine direkten Eingriffe von aussen nötig sind.
- Einfacher organisatorischer Zugriff auf Git
- Ops-Teams erkennen dank transparenten Änderungen Probleme rasch, was die Sicherheit erhöht.
- Entwicklungs- und Operations-Team können im jeweils eigenen Tempo arbeiten und müssen nicht aufeinander warten.
- Unternehmen erhalten mehr Agilität bei der Umsetzung von Markt- und Kundenanforderungen.
- Die einheitliche Methode erlaubt die Verwaltung grosser, komplexer Infrastrukturen (Skalierbarkeit)
- Stärkung der transparenten Kollaboration zwischen Entwickler- und Operationsteams im Sinne von DevOps.
- Konsistenz über verschiedene Umgebungen hinweg (Entwicklung, Staging, Produktion)
- Schnellere und qualitativ hochwertige Bereitstellung
Alle bisher erschienenen Buchstaben im digitalen ABC
-
A
wie Artificial Intelligence
Artificial Intelligence; abgek. AI,
engl. für dt. künstliche Intelligenz, abgek. KI -
B
wie Big Data
Big Data (von englisch big = gross und data = Daten)
-
B
wie Bug Bounty
Bug-Bounty-Programm (engl. sinng. Kopfgeld-Programm für Programmierfehler)
-
C
wie Cloud
Cloud, w.
-
C
wie CERT
CERT, Akronym für engl. Computer Emergency Response Team
-
D
wie Digitale Schweiz
1. Digitale Schweiz, w. (die digitale Transformation der Schweiz betreffend)
2. Nebenbedeutung: Teil des Markenversprechens von Abraxas. «Für die digitale Schweiz. Mit Sicherheit» -
D
wie DevOps
DevOps, Kofferwort für Development und Operations
-
E
wie E-ID
E-ID, w. (staatlich anerkannte, nationale elektronische Identität)
-
E
wie Entra ID
Entra ID, cloudbasierter Identitäts- und Zugriffsverwaltungsdienst von Microsoft; neue Bezeichnung für Azure AD.
-
F
wie Firewall
Firewall, w.
engl. für Brandmauer -
F
wie Federated Machine Learning
Federated Machine Learning,
abgekürzt FML, engl. für föderiertes Lernen. -
G
wie Graphical User Interface
GUI, s. (Abk. für engl. Graphical User Interface)
-
G
wie GitOps
GitOps,
Kofferwort für Git (Versionskontrollsoftware) und Operations -
H
wie Hermes
Hermes, m.
1. Götterbote aus der griech. Mythologie, u. a. Gott des Handels, Begleiter der Toten in den Hades
2. frz. Familienunternehmen mit Sitz in Paris für Luxus-Modeartikel
3. Abk. für «Handbuch der Elektronischen Rechenzentren des Bundes, eine Methode zur Entwicklung von Systemen», offener Standard zur Führung und Abwicklung von IT-Systemen -
I
wie IoT
IoT, s.
Abk. für engl. Internet of Things -
J
wie Java
Java, s.
1. kleinste der Grossen Sundainseln (Indonesien)
2. systemunabhängige Programmiertechnologie, besonders für Anwendungen im Internet -
K
wie Kubernetes
Kubernetes, m.
1. Steuermann (altgriechisch)
2. Container-Orchestrierungssystem (Software) -
L
wie Latenz
Latenz, f.
1. Vorhandensein einer noch nicht sichtbaren Sache
2. Zeit zwischen Reiz und Reaktion (Physiologie)
3. symptomfreie Zeit zwischen Ansteckung und Ausbruch einer Krankheit (Medizin)
4. Zeit zwischen Anfrage und Antwort (IT) -
M
wie Malware
Malware, f.
Software, die in Computersysteme eindringen und dort Störungen oder Schäden verursachen kann -
N
wie New Work
New Work, n. od. f.
engl. für Neue Arbeit
Gesamtheit der modernen und flexiblen Formen der Arbeit bzw. der Arbeitsorganisation -
O
wie Outsourcing
Outsourcing, n.
engl. für Auslagerung
Übergabe von Aufgaben und / oder Strukturen eines Unternehmens an externe Dienstleister -
P
wie Proxy
Proxy, m.
engl. für Stellvertreter
ein Vermittler von Anfragen in Computernetzwerken -
Q
wie Quantencomputer
Quantencomputer, m.
Aus Qubits und Quantengattern aufgebauter Computer, der die Gesetze der Quantenmechanik ausnutzt. -
R
wie Redundanz
Redundanz, f.
Zusätzliche technische Ressourcen als Reserve (Technik) -
S
wie Software-as-a-Service
SaaS, (ohne Artikel)
Kurzwort für englisch Software-as-a-Service = Software als Dienstleistung -
T
wie Transport Layer Security
TLS, m.,
Kurzwort für englisch Transport Layer Security (= Transportschicht-Sicherheit) -
U
wie USV
USV, w.,
Abk. für Unterbrechungsfreie Stromversorgung -
V
wie VPN
VPN, n.,
Abk. für engl. virtual private network = virtuelles privates Netzwerk -
W
wie White-Hat-Hacker
White-Hat-Hacker, m.
Ein White-Hat-Hacker (Oder White Hat, engl. für Weisser Hut) ist ein ethischer Hacker für Computersicherheit. -
X
wie XSS (Cross-Site-Scripting)
XSS, s.
Abk. für engl. Cross-Site-Scripting; dieses webseitenübergreifendes Scripting ist eine Angriffsmethode von Cyberkriminellen. -
Y
wie Y2K
Y2K,
Numeronym für das Jahr-2000-Problem, engl. Year und 2K für 2 Kilo = 2000 -
Z
wie z/OS
z/OS,
seit 2001 im Einsatz stehendes Betriebssystem für IBM-Grossrechner
Über Bruno Habegger
Bruno Habegger ist Abraxas-Magazin-Autor und Senior Communication Manager. Er verfügt über eine langjährige Erfahrung im ICT- und Energie-Bereich als Journalist, Contentproduzent und Berater. Er war Präsident einer Regionalpartei und an seinem damaligen Wohnort acht Jahre Mitglied der Sicherheitskommission.
