E-Book, Deutsch, 373 Seiten
Cubukcuoglu / Scheytt / Schnatterer GitOps
1. Auflage 2024
ISBN: 978-3-98890-123-1
Verlag: dpunkt.verlag
Format: EPUB
Kopierschutz: 6 - ePub Watermark
Grundlagen und Best Practices
E-Book, Deutsch, 373 Seiten
ISBN: 978-3-98890-123-1
Verlag: dpunkt.verlag
Format: EPUB
Kopierschutz: 6 - ePub Watermark
Baris Cubukcuoglu ist Cloud Solution Engineer bei Mimacom und verfügt über mehr als 10 Jahre Erfahrung in der Entwicklung und Architektur von Anwendungen. Seine Passion ist es, Dinge umzusetzen, die einen Mehrwert schaffen. Dabei berät und unterstützt er Kunden bei Cloud- und Infrastruktur-Technologien, Kubernetes sowie bei der automatisierten Auslieferung von Software mit CI/CD. Josia Scheytt befähigt Entwicklungsteams dazu, zügig und mit Zuversicht nach Produktion zu deployen. Mit Fokus auf Public Cloud, Kubernetes und CI hilft er verschiedenen Kunden in seiner Tätigkeit als Cloud Automation Engineer bei Mimacom (www.mimacom.com). Johannes Schnatterer war bereits jahrelang in der Softwareentwicklung tätig bevor sein Fokus mit dem Aufkommen der Containertechnologie in Richtung Infra-Themen zu wandern begann. Als Technical Lead der Infra- und Consulting Teams bei Cloudogu entwickelt und betreibt er eine Internal Developer Platform auf Basis von Kubernetes und GitOps und gibt dabei Gelerntes als Consultant, Trainer und Autor weiter.
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
1Was ist GitOps?
Hand aufs Herz: Wo schaust du nach, wenn du wissen möchtest, welche Anwendungen konkret in einem Environment deployt sind? Vielleicht findest du dich in einer der folgenden Antworten wieder:
- »Im Cluster selbst – wir deployen nur manuell … «
- »In den letzten Deploy-Pipelines vom CI-Server.«
- »In einem Git-Repo.«
GitOps kann dich in die Lage versetzen, die letzte der drei Antworten zu geben – und zwar mit sehr großer Zuversicht. Diese psychologische Sicherheit ist nur eines der Resultate von einem Deployment-Workflow auf GitOps-Basis.
In diesem Kapitel stellen wir GitOps ganz grundlegend vor. Dabei starten wir mit einer vagen Gegenüberstellung, um eine grundsätzliche Vorstellung von GitOps zu haben. Dann wollen wir die Hintergründe und Herausforderungen verstehen, aus denen GitOps entstand. Anschließend wenden wir uns den vier Prinzipien von OpenGitOps zu, die GitOps im Kern definieren.
1.1CIOps vs. GitOps
Begriffe und Synonyme
- »GitOps-Operator« und »GitOps-Controller« werden fast synonym eingesetzt. Darüber hinaus gibt es noch den Begriff »GitOps-Agent« im Sinne von GitOps-Prinzip 4 (siehe Abschnitt 1.3.4 auf Seite 20). In diesem Buch verwenden wir aus Gründen der Einheitlichkeit den Begriff »GitOps-Operator«, auch wenn der von Kubernetes abstrahierte Begriff »GitOps-Agent« an vielen Stellen passender wäre. In der Praxis wird »GitOps-Operator« unserer Erfahrung nach auch am häufigsten verwendet. Allerdings wird auch im Kontext von GitOps gelegentlich der Begriff »Controller« benutzt. Unser Verständnis ist, dass »Controller« der allgemeinere Begriff ist. Unter »Operator« verstehen wir einen speziellen »Controller« samt seiner Erweiterungen der Kubernetes-API (CRDs). GitOps-Operatoren wie Flux und ArgoCD bieten umfangreiche CRDs an, insofern wirkt dieser Begriff für uns am besten passend. Sowohl Argo CD als auch Flux bestehen aus mehreren Komponenten, die teilweise als »Controller« bezeichnet werden. Unter GitOps-Operator verstehen wir in diesem Kontext die Gesamtheit dieser »Controllers«. Flux ist also ein GitOps-Operator, der aus Kustomize-Controller, Helm-Controller, Notification-Controller etc. besteht.
- Mit »Config« meinen wir beispielsweise Kubernetes-Ressourcen. Manche verwenden auch den Begriff »Infrastructure as Code« synonym. Andere sehen zwischen Config und Infrastruktur (beispielsweise virtuelle Maschinen) klare Unterschiede.
.
Bei einer »klassisch« umgesetzten Pipeline für Continuous Deployment (CD) führt der CI-Server aktiv das Deployment in die Zielumgebung durch (Push-Prinzip). In Abb. 1–1 sehen wir ein Beispiel davon: Der CI-Server, in diesem Fall GitLab CI, verbindet sich mit einem Source Code Management (SCM), zum Beispiel GitHub. GitLab CI lädt ein Git-Repository herunter, das beispielsweise Kubernetes-Manifeste enthält. Anschließend verbindet es sich mit einem Kubernetes-Cluster (beispielsweise über eine Kubeconfig-Datei) und rollt diese Manifeste aus (beispielsweise mit einem kubectl apply). Dieses Verfahren bezeichnen wir als »CIOps1«, weil ausschließlich der CI-Server operativ tätig ist.
.
CIOps hat sich jahrelang in der Praxis bewährt – aber es weist an kritischen Stellen entscheidende Mängel auf: Der Rollout wird ausgeführt. Dadurch entsteht ab der ersten Sekunde nach dem CI-geführten Rollout etwas, das alle Infrastruktur-Menschen fürchten: Drift – die Realität entfernt sich mit jedem Moment mehr vom ursprünglich definierten Wunschzustand. Danach manuell ausgeführte Änderungen bleiben intransparent bestehen. Solche Änderungen können aus Versehen passieren oder absichtlich, etwa durch Angreifende. Und genau dadurch entsteht das Problem, das wir am Anfang des Kapitels angerissen haben: Wer eine Woche lang keinen Commit auf das Repo macht, von dem aus die Pipeline getriggert wird, kann eine Woche lang manuelle Änderungen im Cluster machen, und es wird keinerlei automatisches Zurücksetzen auf den in Git definierten Zustand (Reconciliation) geschehen.
.
Außerdem haben wir gravierende Sicherheitsrisiken: Der CI-Server braucht privilegierten Zugriff auf die Zielumgebung. Meistens bekommt der CI-Server direkt administrativen Zugriff und kann dadurch in den falschen Händen viel Schaden anrichten. Das öffnet sehr gefährliche Einfallstore für Angreifer.
.
Ebenso ist ein Rollout nur dann möglich, wenn eine Netzwerkverbindung vom CI-Server zum Zielsystem besteht. Selbst wenn wir die Rollout-Pipeline im CI-Server automatisch alle 5 Minuten ausführen lassen, wird die Angleichung nur dann passieren, wenn der CI-Server den Cluster erreichen kann.
Außerdem ist in Enterprise-Umgebungen diese Verbindung zwischen Entwicklungsumgebung (CI-Server) und Betriebsumgebung (Kubernetes) aufgrund unterschiedlicher Sicherheitszonen oft eine Herausforderung. Dies kann die Verbindung unmöglich machen oder durch die Notwendigkeit von Firewall-Freischaltungen deutlich erschweren. Zwar unterliegen die umgekehrten Netzwerkverbindungen von der Betriebsumgebung auf die Entwicklungsumgebung (SCM) gegebenenfalls ähnlichen Problematiken. Unserer Erfahrung nach ist es aber meist einfacher, aus der produktiven Betriebsumgebung heraus, als in sie hineinzukommen. Mit GitOps ließe sich selbst dieses Problem lösen: Der GitOps-Operator könnte die Manifeste auch aus einer Open Container Initiative (OCI) Registry lesen, auf die Kubernetes aufgrund der Images ohnehin Zugriff braucht (siehe Abschnitt 4.13 auf Seite 90).
Weiterhin sind wir ziemlich eingeschränkt, weil wir über das Git-Repo, von dem aus der CI-Server deployt, nur bestehende Ressourcen aktualisieren oder neue Ressourcen deployen können. Das Löschen von Ressourcen hingegen ist nicht von Haus aus über Commits möglich (beispielsweise durch das Löschen einer Manifest-Datei), nur über manuelles Eingreifen oder zusätzliche Pipelines.
Die Pipelines des CI-Servers ermöglichen imperative Änderungen an der Config. Typischerweise schreibt man hier den Tag des aktuellen Images in die Config. Gängig ist aber auch das Einfügen von Secrets aus dem Credentials-Store des CI-Servers, das Spezifizieren von Helm-Charts oder das Setzen von umgebungsspezifischen Parametern. Dies führt dazu, dass die tatsächlich an den Cluster übertragene Config nur transient auf dem CI-Server besteht. Damit sind Änderungen nicht einfach nachvollziehbar und Fehler schwerer zu finden.
.
Wie können wir diesen Problematiken begegnen? Kann es überhaupt einen anderen Weg geben? Mit GitOps können wir ganz anders vorgehen (siehe Abb. 1–2): Der CI-Server verschwindet bei einem Rollout grundsätzlich komplett aus dem Bild. Stattdessen gibt es einen Prozess innerhalb des Zielsystems, der ununterbrochen das relevante Git-Repository pullt und auf Änderungen überprüft (Pull-Prinzip). Dieser Prozess wird »GitOps-Operator« genannt; im Diagramm ist es Argo CD.
Damit können wir den eben genannten Schwierigkeiten bei CIOps sehr gut begegnen:
- : Wir verringern den Zeitraum drastisch, in dem Drift auftreten kann, weil die Manifeste im Git-Repository beständig gelesen und angewandt werden. Bei manuellen Änderungen sorgt der GitOps-Operator also für . Prinzipiell implementiert GitOps das Deployment, insofern kann man es als (oder Cloud-Native Continuous Delivery) verstehen. Als Fortführung des Gedankens von Continuous Deployment können wir an dieser Stelle auch von sprechen.
- : Da der GitOps-Operator im Cluster läuft, muss netzwerktechnisch gesehen kein administrativer Zugriff von außerhalb des Clusters mehr erfolgen.
Außerdem zwingt uns die deklarative Natur von GitOps dazu dedizierte Werkzeuge zum Secrets Management zu verwenden, statt diese im CI-Server zu verwalten (siehe Kapitel 5 auf Seite 97). Dies reduziert das...
