Cubukcuoglu / Scheytt / Schnatterer GitOps

Grundlagen und Best Practices
1. Auflage 2024
ISBN: 978-3-98890-012-8
Verlag: dpunkt.verlag
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 373 Seiten

GitOps optimal einsetzen - Praktischer Einstieg für Entwicklungs- und Plattformteams - tiefgründige Fokussierung auf GitOps (ohne Grundlagen für K8s oder CI/CD) - Klarer Einblick in die Konsequenzen von GitOps und den Unterschied im Entwicklungsalltag - Umfassende Hilfestellung zu relevanten Herausforderungen wie Secrets, Repo-Strukturen und Asynchronität GitOps ist die aktuell vielversprechendste Methodik, um Continuous Deployment auf Cloud-native Art und Weise umzusetzen. Im Gegensatz zu punktuell getriggerten Deployments werden deklarative Beschreibungen der Softwaresysteme genutzt, um diese kontinuierlich im Hintergrund anzuwenden. Mit diesem Buch kannst du schnell und einfach in GitOps einsteigen und erfährst seine Vorteile für den Entwicklungsalltag. Nicht nur vergleichen wir hierfür die Tools Argo CD und Flux, sondern zeigen auch konkrete Implementierungen von GitOps mit und ohne Kubernetes, die du anhand öffentlicher Repositories direkt nachstellen kannst. Überdies gehen wir ausführlich auf fortgeschrittene Themen wie Secrets Management, Repo-Strukturen, Asynchronität und Alerting ein, um dich für den Ein- bzw. Umstieg optimal vorzubereiten. Unter https://gitops-book.dev findest du weitere Informationen zum Thema.

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.

Cubukcuoglu, Baris

Scheytt, Josia

Schnatterer, Johannes

Fachgebiete

• Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Software Engineering

Inhaltsverzeichnis

1;Vorwort;5
2;Inhaltsverzeichnis;9
3;Teil I Grundlagen;15
3.1;Was ist GitOps?;17
3.1.1;CIOps vs. GitOps;18
3.1.2;Der Weg zu GitOps;23
3.1.2.1;Traditionelle Silos;23
3.1.2.2;DevOps;24
3.1.2.3;Infrastructure as Code;25
3.1.2.4;Kubernetes;28
3.1.2.5;OpenGitOps;28
3.1.3;Die vier Prinzipien;30
3.1.3.1;Prinzip 1: Deklarativ;30
3.1.3.2;Prinzip 2: Versioniert und unveränderlich;32
3.1.3.3;Prinzip 3: Automatisch bezogen;34
3.1.3.4;Prinzip 4: Kontinuierlich angeglichen;34
3.1.4;Fragen und Missverständnisse;37
3.2;Welchen Unterschied macht GitOps?;39
3.2.1;Indizien aus den DORA-Studien;39
3.2.2;Der Unterschied im Alltag: Geschichten einesEntwicklungsteams;42
3.2.3;Szenario;43
3.2.3.1;Repositories;43
3.2.3.2;Deployment-Fluss;45
3.2.3.3;Vergleichsszenario „Mit GitOps“;45
3.2.4;Kontinuierlich nach Dev deployen;48
3.2.5;Ressourcen aufräumen;49
3.2.6;Grenzfälle in CI vermeiden;50
3.2.7;Ressourcen wiederherstellen;53
3.2.8;Konfigurationsänderungen ausrollen;55
3.2.9;Incidents navigieren;57
3.2.10;Zielsysteme besser absichern;59
3.3;Wie fange ich mit GitOps an?;61
3.3.1;Agile Empfehlung: zügiger Durchstich;61
3.3.2;Fragen zur Orientierung;63
3.3.3;Eine Beispielimplementierung mit Argo CD;65
3.3.3.1;Zielsetzung;65
3.3.3.2;Voraussetzungen;68
3.3.4;Schritt 1: Einen Cluster starten;68
3.3.5;Schritt 2: Argo CD installieren;68
3.3.5.1;Ressourcentypen von Argo CD verstehen;70
3.3.6;Schritt 3: Eine eigene Application erzeugen;75
3.3.7;Schritt 4: Eine Änderung deployen;78
3.3.8;Fazit;79
4;Teil II Praxis;81
4.1;Argo CD oder Flux auswählen;83
4.1.1;Zahlen und Fakten;83
4.1.2;Bootstrapping;85
4.1.3;Linking;86
4.1.4;CLI und GUI;87
4.1.5;Komponenten und Ressourcenbedarf;89
4.1.6;Authentifizierung und Autorisierung;93
4.1.7;Templating;93
4.1.8;Configuration Management;94
4.1.9;Monitoring und Alerting;96
4.1.10;Ökosystem;99
4.1.11;Mandantentrennung;102
4.1.12;Multi-Cluster-Management;104
4.1.13;OCI statt Git;104
4.1.14;Hochverfügbarkeit und Lastverteilung;107
4.1.15;Reifegrad;107
4.1.16;Kommerzielle Angebote;108
4.1.17;Fazit und Tipps zur Entscheidungsfindung;109
4.2;Secrets sicher verwalten;111
4.2.1;Secrets lagern und verwalten;112
4.2.1.1;Secrets verschlüsselt im Repo speichern;112
4.2.1.2;Secrets extern verwalten;116
4.2.2;Secrets konsumieren;121
4.2.2.1;Secrets als native Kubernetes-Secrets konsumieren;122
4.2.2.2;Secrets über Sidecar-Container injizieren;125
4.2.2.3;Secrets über ein CSI-Volume konsumieren;127
4.2.3;Wir erweitern die Beispielimplementierung;129
4.2.3.1;Ziele;130
4.2.3.2;Datenfluss von HashiCorp Vault über ESO in denCluster;131
4.2.3.3;Schritt 1: Das Config-Repo bootstrappen;133
4.2.3.4;Schritt 2: Anwendungen in neuen Namespacedeployen;134
4.2.3.5;Schritt 3: ESO mit HashiCorp Vault verbinden;138
4.2.3.6;Schritt 4: Beispiel-Secret erstellen;140
4.2.3.7;Schritt 5: Das Secret integrieren;143
4.2.3.8;Schritt 6: Das Secret ändern;144
4.2.4;Fazit;145
4.3;Repositories und Ordner strukturieren;147
4.3.1;Design des GitOps-Prozesses;147
4.3.2;Kategorien von GitOps-Patterns;150
4.3.3;Operator Deployment Patterns;151
4.3.3.1;Instance per Cluster;152
4.3.3.2;Hub and Spoke;152
4.3.3.3;Instance per Namespace;153
4.3.4;Repository Patterns;153
4.3.4.1;Monorepo;154
4.3.4.2;Repo per Team;154
4.3.4.3;Repo per Application;155
4.3.4.4;Repo per Environment;163
4.3.5;Promotion Patterns;164
4.3.5.1;Branch oder Folder per Environment;165
4.3.5.2;Preview Environments;171
4.3.5.3;Global Environments oder Environment perApplication;173
4.3.5.4;Configuration Management;174
4.3.5.5;Config Update;177
4.3.6;Verdrahtungs-Patterns;182
4.3.6.1;Bootstrapping;182
4.3.6.2;Linking;182
4.3.7;Beispiele für Config-Repos;183
4.3.7.1;Beispiel 1: Argo CD Autopilot;184
4.3.7.2;Beispiel 2: GitOps Playground;189
4.3.7.3;Beispiel 3: Flux Monorepo;194
4.3.7.4;Beispiel 4: Flux Repo per Team;197
4.3.7.5;Beispiel 5: The Path to GitOps;199
4.3.7.6;Beispiel 6: Environment-Varianten;201
4.3.8;Mandantentrennung;203
4.3.8.1;Rolle der GitOps-Operatoren;203
4.3.8.2;Rolle der Repo-Struktur;204
4.3.8.3;Rolle der Cluster;205
4.3.8.4;Teams und Environments trennen;206
4.3.9;Fazit;208
4.4;Asynchron deployen;211
4.4.1;Deployment-Flüsse;211
4.4.1.1;Schritte;211
4.4.1.2;Kombinationen von Zuständigkeiten;213
4.4.1.3;Deployment-Fluss 1: CIOps;214
4.4.1.4;Deployment-Fluss 2: Schmal-GitOps;215
4.4.1.5;Deployment-Fluss 3: CI-Klammer;216
4.4.1.6;Deployment-Fluss 4: Übergabe;217
4.4.1.7;Deployment-Fluss 5: GitOps-geführt;218
4.4.2;Rollout durch den GitOps-Operator;219
4.4.2.1;Rollout-Schritte im GitOps-Operator;219
4.4.2.2;Timing und Koordination der Rollout-Schritte;222
4.4.2.3;Intervalle der Rollout-Schritte;225
4.4.2.4;Rollout im GitOps-Operator aktiv triggern;226
4.4.3;Config Update;229
4.4.3.1;Argo CD Image Updater;230
4.4.3.2;Flux Image Automation;230
4.4.3.3;Dependency-Bot;231
4.4.4;Prüfen;232
4.4.4.1;Prüfen via CI-Server;232
4.4.4.2;Prüfen via GitOps-Operator;233
4.4.4.3;Progressive Delivery;235
4.4.5;CI-Server mit GitOps verwalten;238
4.4.6;Fazit;240
4.5;Alerting integrieren;243
4.5.1;Gesundheitszustand feststellen;244
4.5.1.1;Kubernetes-nativ mit kstatus;244
4.5.1.2;Helm-Hooks;249
4.5.1.3;Flux;249
4.5.1.4;Argo CD;252
4.5.2;Benachrichtigungen verschicken;253
4.5.2.1;Flux;254
4.5.2.2;Argo CD;256
4.5.3;Ganzheitliche Herangehensweise;259
4.6;Imperativ eingreifen;261
4.6.1;Eindeutig ausgeschlossene Aktionen;261
4.6.2;Risiken und Chancen;262
4.6.3;Einen Debug-Pod starten;264
4.6.4;Ein Backup wiederherstellen;265
4.6.5;Ein Deployment neu starten;269
4.6.6;Ressourcen neu erzeugen;270
4.6.7;Ein Deployment skalieren;272
4.6.8;Fazit;274
5;Teil III Weiterführendes;275
5.1;Mehrere Cluster verwalten;277
5.1.1;Single-Cluster vs. Multi-Cluster;278
5.1.2;Cluster API;279
5.1.3;Konzept von Cluster API;280
5.1.4;Definition der Cluster API-Ressourcen;280
5.1.5;Installation des Management-Clusters;283
5.1.5.1;Provider konfigurieren und temporärenManagement-Cluster bauen;284
5.1.5.2;Worker Cluster anlegen;286
5.1.5.3;Installation des Cluster API Operators;289
5.1.5.4;Deklarative Installation des Management-Clusters;290
5.1.6;Verwaltung von Workload-Clustern mit Argo CD;298
5.1.7;Fazit;303
5.2;Infrastruktur verwalten;305
5.2.1;Terraform;306
5.2.1.1;Ein kurzes Tutorial zum Einstieg;306
5.2.1.2;Grundbausteine von Terraform;309
5.2.1.3;Terraform vs. OpenTofu;312
5.2.1.4;Terraform und GitOps;313
5.2.1.5;Eine EC2-Instanz verwalten mit TF-Controller undFlamingo;315
5.2.2;Pulumi;323
5.2.2.1;Grundbausteine von Pulumi;324
5.2.2.2;Eine EC2-Instanz verwalten mit Pulumi Kubernetes Operator;328
5.2.3;Crossplane;335
5.2.3.1;Grundbausteine von Crossplane;335
5.2.3.2;Eine EC2-Instanz verwalten mit Crossplane;337
5.3;GitOps außerhalb von Kubernetes;347
5.3.1;Aus den GitOps-Prinzipien folgende Verantwortlichkeiten;348
5.3.2;Infrastructure-as-Code-Formate;349
5.3.3;Weitere GitOps-Operatoren;351
5.3.4;Features von GitOps-Operatoren;352
5.3.5;Einen eigenen GitOps-Operator bauen;354
5.3.6;Eigene GitOps-Operatoren aus der Praxis;355
5.3.6.1;Docker Swarm und Ansible;355
5.3.6.2;Helmfile;362
5.3.6.3;Lektionen;364
6;Teil IV Anhang;365
6.1;Nachwort;367
6.2;Index;371

Über Autor(innen)

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.

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.