In diesem Dokument wird ein Framework für die Implementierung moderner Prozesse für Continuous Integration/Continuous Delivery (CI/CD) auf einer Plattform mit mehreren Teams beschrieben, die Google Kubernetes Engine verwendet.
Sie können anschließend auf der Plattform iterieren, um die Leistung für Entwicklung und Betrieb weiter zu verbessern, einschließlich Release-Geschwindigkeit, Zuverlässigkeit der Plattform und Wiederherstellungsdauer von Fehlern.
Dieses Dokument ist Teil der folgenden Reihe:
Moderne CI/CD mit GKE: Ein Softwarebereitstellungs-Framework (dieses Dokument)
Moderne CI/CD mit GKE: CI/CD-System erstellen (Referenzarchitektur)
Dieses Dokument richtet sich an Unternehmensarchitekten und Anwendungsentwickler sowie für IT-, DevOps- und Site Reliability Engineering-Teams. Erfahrung mit automatisierten Bereitstellungstools und -prozessen ist hilfreich, um die Konzepte in diesem Dokument zu verstehen.
Ein Fall für die moderne CI/CD
CI/CD ist ein Ansatz zur Softwareentwicklung, mit dem Sie die Build-, Test- und Bereitstellungsphasen der Softwareentwicklung automatisieren können. Hierfür stehen eine Reihe von Tools und wiederholbaren Prozessen zur Verfügung.
Neben der CI/CD-Automatisierung haben Kubernetes und Container es Unternehmen ermöglicht, die Geschwindigkeit der Entwicklung und der Bereitstellung in beispielloser Weise zu verbessern. Aber trotz der zunehmenden Nutzung von Kubernetes und Container-Nutzung können viele Organisationen die Vorteile der Release-Geschwindigkeit, Stabilität und operativen Effizienz nicht vollständig nutzen, weil ihre CI/CD-Praktiken die Vorteile von Kubernetes nicht voll ausschöpfen oder Betriebs- und Sicherheitsbedenken nicht berücksichtigen.
Ein wirklich moderner CI/CD-Ansatz muss mehr als nur die Automatisierung umfassen. Wenn Sie die Geschwindigkeit und Sicherheit deutlich verbessern und die Vorteile von Kubernetes und Containern nutzen möchten, müssen Sie die Einrichtung der Anwendung, die CI/CD-Praktiken und die operativen Prozesse optimieren.
Durch die Verwendung der konsistenten Infrastruktur der GKE-Plattform, der einheitlichen CI-/CD-Methoden und den Best Practices für die Implementierung kann Ihr Unternehmen folgende Vorteile für die Entwicklung und die operativen Abläufe erzielen:
Vorlaufzeit für Änderungen verkürzen
Betriebs- und Sicherheitsteams können Best Practices für die Bereitstellung von Anwendungen und die Bereitstellungsrichtlinie auf der gesamten Plattform erstellen und aktualisieren
Onboarding von Anwendungen vereinfachen, indem Sie Teams voll funktionsfähige Starterprojekte bereitstellen, die die Best Practices Ihrer Organisation enthalten
Zeit verkürzten, die für die Wiederherstellung des Dienstes benötigt wird
Alle Konfigurationen deklarativ mit GitOps verwalten, um Audits, Rollbacks und Prüfungen zu vereinfachen
Methoden zur Bereitstellung und Monitoring im gesamten Unternehmen standardisieren, um die Zeit zu verkürzen, die benötigt wird, um die beitragenden Faktoren eines dienstrelevanten Problems zu identifizieren.
Bereitstellungshäufigkeit erhöhen
Dafür sorgen, dass Anwendungsentwickler unabhängig voneinander ihre eigenen Sandboxes (oder Zielzonen) iterieren können, ohne sich gegenseitig zu beeinträchtigen.
GitOps für die Bereitstellung, verbesserte Versionsverwaltung und Änderungsverfolgung verwenden
„Leitplanken“ implementieren, damit die Diensteteams häufig Bereitstellungen machen können
Progressiven Rollout-Prozess für die konsistente Bereitstellung in verschiedenen Vorproduktionsumgebungen erstellen und den Entwicklern das nötige Vertrauen geben, um Änderungen in der Produktion zu implementieren.
In den anderen Dokumenten dieser Reihe wird beschrieben, wie diese Vorteile und Konzepte mit GKE und CI/CD umgesetzt werden:
Bereitschaft für einen modernen Ansatz prüfen
Bevor Sie moderne CI/CD-Tools und -Prozesse mit GKE implementieren, müssen Sie prüfen, ob Ihre Organisation und Ihre Teams bereit sind, eine neue Plattform zu übernehmen.
Organisationsmerkmale
Die Nutzung einer modernen Plattform erfordert die Unterstützung Ihres Unternehmensleiters und der Technikteams:
Unterstützung durch die Führungskräfte: Die Nutzung einer Plattform zur Softwarebereitstellung ist in der Regel ein großer Aufwand für mehrere funktionsübergreifende Teams. Der Prozess führt normalerweise zu Änderungen an Rollen und Verantwortlichkeiten sowie bei der Softwareentwicklung. Um diese Tools und Techniken erfolgreich einsetzen zu können, benötigen Sie starke Unterstützung von einem oder mehreren Mitgliedern des Führungsteams. Die effektivsten Unterstützer sind diejenigen, die diese Veränderungen als einen kontinuierlichen Verbesserungsprozess betrachten und ihre Teams eigenverantwortlich arbeiten lassen zu wollen, anstatt sie zu managen.
Ausrichtung auf technische und geschäftliche Strategie: Wir empfehlen, dass Ihre Geschäftsteams und technischen Teams auf die vier wichtigsten Maßnahmen zur Softwarebereitstellung reagieren, die von DevOps Research and Assessment (DORA) definiert wurden: Vorlaufzeit für Änderungen, Bereitstellungshäufigkeit, Zeit zur Wiederherstellung des Dienstes und Änderungsfehlerquote. Wenn Sie diese Maßnahmen aufeinander abstimmen, erhalten Ihre Geschäftsteams und Ihre technischen Teams ein gemeinsames Ziel, wodurch sie den Return on Investment gemeinsam berechnen, die Änderungsrate anpassen und das Investitionsniveau ändern können.
Resources: Um erfolgreich zu sein, brauchen Teams, die moderne CI/CD-Praktiken entwickeln und Tool-Ketten aufbauen, die notwendigen Ressourcen: Zeit, Menschen und Infrastruktur. Diese Teams haben Zeit, die besten Prozesse und Tools auszuprobieren und auszuwählen. Idealerweise stehen diese Teams für viele verschiedene Funktionen im Rahmen der Softwarebereitstellung und können weitere Ressourcen aus der gesamten Organisation übernehmen. Schließlich benötigen die Teams die Möglichkeit, Infrastruktur bereitzustellen, einschließlich Cloud-Ressourcen und Softwaretools.
Offenheit für die Einführung neuer Tools: Moderne CI/CD-Tools und -Techniken greifen häufig auf neue Tools und Prozesse zurück. Teams müssen mit diesen Prozessen und Tools experimentieren und offen sein, sie zu übernehmen. Eine Feedbackschleife ist erforderlich, damit Plattformteams von den Anwendungs-, Betriebs- und Sicherheitsteams, die die Plattform verwenden, profitieren können.
Kulturelle Bereitschaft: Für die erfolgreiche Bereitstellung und Einführung eines modernen CI/CD-Systems mit GKE müssen die Organisation und die technischen Teams, die das System entwickeln, die Art und Weise, wie sie arbeiten und zusammenarbeiten, ändern. Beispielsweise sollten die Entwicklungs- und Betriebsteams bereit sein, mehr Verantwortung für Sicherheit zu übernehmen, während die Sicherheits- und Betriebsteams der Optimierung von Prozessen für Änderungsgenehmigungen gegenüber offen sein sollten.
Technische Fähigkeiten
Wenn Sie einen modernen CI/CD-Ansatz verwenden möchten, müssen Ihre Teams technisch so vorbereitet werden:
Erfahrung mit Containern: Teams, die moderne CI/CD-Ansätze verwenden, müssen etwas Erfahrung mit Containern haben. Im Idealfall umfasst diese Lösung Entwicklungstechniken zum Erstellen von Container-Images und zum Kombinieren von Containern, um größere Systeme zu erstellen.
Strategie für Continuous Integration: Die Teams benötigen einige Erfahrung im Umgang mit CI-Tools (wie Jenkins, TeamCity, Bamboo und CircleCI) und in der Durchführung von kontinuierlicher Integration und automatisierten Tests. Wir empfehlen Organisationen, diese Maßnahmen entsprechend zu planen.
Automatisierung der Bereitstellung: Teams brauchen Kenntnisse mit der Automatisierung von Bereitstellungen. Beispiele für automatisierte Bereitstellungstools sind einfache Shell-Skripts, Terraform, Terraform oder Puppet. Grundkenntnisse zu automatisierten Bereitstellungstools und -prozessen sind für die Optimierung und Automatisierung von Bereitstellungen unverzichtbar.
Dienstorientierte Architekturen: Es ist keine Voraussetzung für das Einführen moderner CI/CD-Prozesse, die Einführung von modularen und dienstorientierten Architekturen ist jedoch ein langfristiges Ziel von Organisationen, die moderne CI/CD-Tools und -Techniken mit GKE einführen möchten. Es wurden dienstbasierte Architekturen gezeigt, um die Geschwindigkeit und Zuverlässigkeit zu verbessern.
Moderne Versionsverwaltung: Mit modernen Quellcodekontrolltools wie Git können Teams Workflows wie die Entwicklung nach Baumschema, Feature-Zweige und Zusammenführungsanfragen erstellen.
Moderne CI/CD mit GKE entwerfen
In diesem Abschnitt werden eine Plattform zur Softwarebereitstellung und ihre Komponenten beschrieben. Zur Verbesserung der Leistung bei der Softwarebereitstellung müssen Sie CI/CD und andere Best Practices implementieren, mit denen Teams schnell veröffentlichen und effizient arbeiten können.
In diesem Abschnitt wird auch auf die Infrastruktur eingegangen, die für den Lebenszyklus der Softwarebereitstellung benötigt wird, und wie Sie diese Infrastruktur mit GKE einheitlich verwalten. Schließlich enthält dieser Abschnitt einen Beispiel-Workflow für die Softwarebereitstellung und zeigt, wie Starter-Repositories die Einrichtung und Implementierung von Best Practices vereinfachen. Dabei werden die folgenden Designaspekte geprüft:
Softwarebereitstellungsplattform: Das Framework und die technischen Funktionen, die die Grundlagen eines zuverlässigen und zuverlässigen Anwendungsfreigabeprozesses bilden.
Plattforminfrastruktur: Die Infrastrukturkomponenten und Verwaltungsentscheidungen, die Sie benötigen, um die Plattform zu erstellen und Ihre Anwendungen auszuführen.
Workflow zur Softwarebereitstellung: Wie Teams gemeinsam Code entwickeln, testen und bereitstellen können.
Code-Repositories: Repositories, die mehrere Funktionen ausführen, darunter das Speichern der tatsächlichen Geschäftslogik, die anwendungsspezifische Konfiguration und den Code zum Erstellen der Infrastruktur. Dies können auch Starter-Repositories sein, die die Einführung von Best Practices erleichtern und dazu beitragen, die Konsistenz über automatisierte Prozesse hinweg zu wahren.
Anwendungs-Landing-Zones: Logische Entität, die Entwicklern die automatische Bereitstellung und Iteration ihrer Anwendungen mit den von Ihnen platzierten "Leitplanken" ermöglicht.
Betriebsmodell: Technische Tools, Prozesse und Methoden zum Verwalten der Infrastruktur und Anwendungen, aus denen die Plattform besteht.
Governance: Prozesse und Überlegungen zur Pflege und Verwaltung der Plattformen für die Softwarebereitstellung.
Plattformen für die Softwarebereitstellung
Eine Softwarebereitstellungsplattform vereinheitlicht die Tools und optimiert die Prozesse zum Erstellen, Liefern, Bereitstellen und Ausführen von Anwendungen.
Die Verantwortung für die Aufrechterhaltung der Konfiguration, Stabilität, Verfügbarkeit und Skalierung einer Anwendung variiert je nach Betreiber und Sicherheits- und Entwicklerteams, aber alle Komponenten und Teams müssen zusammenarbeiten, um Releases zu beschleunigen. Obwohl in diesem Dokument Methoden zur Verbesserung der Versionsverwaltung und der Beobachtbarkeit von Anwendungen beschrieben werden, liegt der Fokus insbesondere auf Continuous Integration (CI), Continuous Delivery (CD) und Konfigurationsverwaltung.
Zum Erstellen einer vollständigen Softwarebereitstellungsplattform benötigen Sie jede Komponente im folgenden Diagramm:
Jede dieser Komponenten bietet Funktionen für das System und die Anwendungen, die auf der Plattform ausgeführt werden:
Monitoring von Infrastruktur: Die Monitoring-Grundebene, die bei der Bereitstellung erforderlich ist, um das korrekte Funktionieren von Google Kubernetes Engine-Clustern (GKE), VM-Instanzen (Virtual Machine) und anderer Infrastruktur, die für das Funktionieren von Anwendungen erforderlich ist, zu prüfen.
Containerorchestrierung: Die Plattform, die die Bereitstellung und den Betrieb von containerbasierten Anwendungen koordiniert. Beispiele für Plattformen zur Containerorchestrierung sind Kubernetes, GKE oder GKE Enterprise.
Container Registry: Die Speicher- und Zugriffssteuerung für Container-Images.
CI. Die Anwendung automatisierter Aufgaben vor der Bereitstellung auf eine Anwendung. CI-Aufgaben umfassen in der Regel das Erstellen, Packen und Testen. Die Aufgabentypen variieren je nach Anwendung und Organisation.
CD. Bereitstellungsprozesse, die sehr automatisiert sind und mit hoher Häufigkeit angewendet werden. Beispielmethoden sind manuelle Genehmigungen, Canary-Bereitstellungen, Blau/Grün-Bereitstellungen oder rollierende Bereitstellungen.
Richtlinie: Sicherheits- und Infrastrukturkonfigurationsrichtlinien, die von den Betriebs- und Sicherheitsteams festgelegt und von der Plattform kontinuierlich angewendet und erzwungen werden.
Quellcodeverwaltung: Beispiel: Versionsgesteuerte Speicherung für Code, Konfigurationsdateien und Richtliniendefinitionen. In einem modernen CI/CD-System ist die Quellcodeverwaltung normalerweise Git.
Konfigurationsverwaltung: Das System, das zum Speichern und Anwenden der Anwendungskonfiguration für verschiedene Umgebungen verwendet wird.
Beobachtbarkeit der Anwendung: Logging, Monitoring, Benachrichtigungen und Tracing für Entwickler, Bediener und Sicherheitsteams auf Anwendungsebene für die Fehlerbehebung und das ordnungsgemäße Funktionieren der Anwendungen.
Plattforminfrastruktur
Für die Erstellung einer skalierbaren Softwarebereitstellungsplattform benötigen Sie Kubernetes-Cluster für Entwicklungen, Vorproduktionsumgebungen und mehrere Produktionscluster. Cluster können viele verschiedene Funktionen bieten:
Entwicklung: In diesen Clustern führen Entwickler Ad-hoc-Bereitstellungen ihrer Anwendungen zu Test- und Experimentzwecken durch.
Die Anwendungsumgebung:
Vorproduktion: Für jede Vorproduktionsumgebung in Ihrem Workflow sollte ein Kubernetes-Cluster zum Hosten Ihrer Anwendungen vorhanden sein. Diese Cluster sollten den Produktionsclustern ähneln, damit Sie Unterschiede zwischen den Umgebungen reduzieren oder beseitigen und damit die Erfolgsquote der Bereitstellung verbessern können.
Produktion: In diesen Clustern werden Ihre Produktionsarbeitslasten ausgeführt. Sie sollten mehrere, geografisch verteilte Cluster verwenden. Dies verbessert die Zuverlässigkeit von Infrastrukturausfällen und vereinfacht Tag-2-Vorgänge wie Bedenken in Bezug auf Clusterupgrades und Skalierung.
Im folgenden Diagramm ist die allgemeine Architektur dargestellt:
In dieser Architektur verwalten Sie die Cluster für jede Umgebung über Config Sync. Eine konsistente Clusterkonfiguration ist äußerst wichtig, da die Entwickler-, Betreiber- und Sicherheitsteams sich darauf verlassen, dass Vorproduktions- und Produktionsumgebungen auf ähnliche Weise funktionieren. Sie können Config Sync zum Speichern und Anwenden gängiger Konfigurationen auf Ihrer gesamten Cluster-Flotte verwenden. Nachdem Ihre Clusterkonfiguration standardisiert wurde, prüfbar und skalierbar ist, können Sie sich auf den Workflow der Softwarebereitstellung, die Einrichtung und das Deployment von Anwendungen konzentrieren.
Sie verwalten Ihre Bereitstellungen für Entwicklungs-, Staging- und Produktionscluster über die CI/CD-Pipelines der Anwendung. Die Versionsverwaltung verwaltet als Koordinationspunkt für Anwendungscode und -konfiguration. Die CI/CD-Pipelines und die Container-Images für eine Anwendung sind in der Umgebung dieser Anwendung isoliert. Initialisieren Sie Anwendungs- und Konfigurations-Repositories mit Starter-Repositories und automatisierten Tools. Sie können beispielsweise Cloud Build zum Ausführen von Terraform verwenden, um neue Anwendungen automatisch einzurichten und zu initialisieren.
Sie stellen Anwendungen in ihren jeweiligen Zonen in jedem Cluster bereit, damit Anwendungen über Netzwerk und Identität verfügen. Mithilfe von Anthos Config Sync initialisieren Sie Anwendungszonen in verschiedenen Umgebungen. Mit Cloud Service Mesh oder Multi Cluster Ingress lassen sie die Produktionscluster wie ein einzelnes Cluster erscheinen, indem Sie ein Netzwerk-Mesh erstellen, das sich über viele Cluster erstreckt.
Workflow zur Softwarebereitstellung
Eine Kernkomponente der Plattform für die Softwarebereitstellung ist das CI/CD-System. Wenn Plattform-Builder mit der Definition des CI-/CD-Prozesses beginnen, muss sichergestellt werden, dass jede Komponente Artefakte erstellt oder verwendet, die einer standardisierten Schnittstelle entsprechen. Die Verwendung einer standardisierten Oberfläche erleichtert das Ersetzen der Komponenten, wenn eine bessere Implementierung auf den Markt kommt.
Wenn Sie eine Plattform für containerisierte Anwendungen erstellen, können Sie die drei standardisierten Schnittstellen zwischen den Komponenten verwenden: Git-Repositories, Docker-Images und Kubernetes-Manifeste. Mit diesen Oberflächen können Sie eine wiederverwendbare und flexible CI/CD-Pipeline mit einem Entwicklungs-, Build- und Release-Workflow erstellen, wie das folgende Diagramm zeigt:
Dieser Workflow funktioniert so:
Entwickler übergeben ihren Anwendungscode in die Code-Repositories.
Das CI-System testet den Code, erstellt ein Docker-Image-Artefakt und speichert das Artefakt in einer Registry.
Sobald das Artefakt bereit für die Bereitstellung ist, wird der Anwendungskonfiguration ein Verweis darauf hinzugefügt.
Diese Anwendungskonfiguration wird in einem für Kubernetes lesbaren Format gerendert und in einem Code-Repository gespeichert. Aktualisierungen dieses Repositories lösen eine Bereitstellungspipeline aus, die die Artefakte in einer integrierten Entwicklungsumgebung bereitstellt.
Nach Abschluss der Tests in der integrierten Entwicklungsumgebung führen Operatoren die Bereitstellung in der Vorproduktionsumgebung durch.
Nachdem die Anwendung in der Vorproduktionsumgebung erwartungsgemäß funktioniert, erhalten die Operatoren in der Bereitstellungspipeline die Genehmigungen und stufen die Version in die Produktionsumgebung hoch.
Wenn Operatoren Änderungen an den Basiskonfigurationen vornehmen, werden diese auf die gesamte Organisation angewendet. Wenn Operatoren Änderungen an ihren Repositories vornehmen, werden automatisch Anwendungsaktualisierungen (und nachfolgende Bereitstellungen) ausgelöst. Oder die Änderungen der Operatoren werden übernommen, wenn die Entwickler ihre Änderungen das nächste Mal bereitstellen.
Parallel dazu können Sicherheitstechniker Richtlinien implementieren und optimieren, die festlegen, was bereitgestellt werden kann, und die Richtlinien dann an ihr Richtlinien-Repository übergeben.
Mit einer GitOps-Methode können Sie für alle Änderungen an Anwendungen und Clustern einen deklarativen Ansatz festlegen. Bei diesem Ansatz müssen alle Änderungen vor der Erzwingung geprüft werden. In diesem deklarativen Modell speichern Sie Ihre Konfigurationsdateien in einem Git-Repository, mit dem Sie ein Log von Änderungen verwalten, fehlgeschlagene Bereitstellungen rückgängig machen und sich die möglichen Auswirkungen der vorgeschlagenen Änderungen ansehen können.
In der zugehörigen Referenzarchitektur verwenden Sie kustomize, um die Anwendungskonfigurationen in Ihrer Organisation zu steuern. Mit dem kustomize-Tool können Operatoren sogenannte Basisversionen von Anwendungskonfigurationen erstellen, die von Ihren Entwicklungsteams angepasst werden können, ohne dass Code in der Basisversion hinzugefügt oder geändert werden muss. Durch das Definieren von Basiskonfigurationen können Plattformteams Best Practices für das Unternehmen erstellen und iterieren. Operatoren und Entwickler können ihre Bereitstellungen unabhängig voneinander durchlaufen, wobei Entwickler die von den Operatoren eingerichteten Best Practices anwenden. Wenn Operatoren eine neue Best Practice für die Organisation implementieren müssen, nehmen Sie die Änderung in der Basis vor und die Änderung wird automatisch bei der nächsten Bereitstellung der Entwickler übernommen.
Code-Repositories
Quellcode-Repositories sind das Herz des CI/CD-Systems. Operatoren, Entwickler und Sicherheitsentwickler haben jeweils eigene Repositories, um Änderungen an die Plattform zu übertragen. Die Verwendung eines Git-Repositories als Grundlage für alle Änderungen im System bietet verschiedene Vorteile:
Integrierte Prüfbarkeit: Commits enthalten Informationen darüber, wer was wann am System geändert hat.
Ein vereinfachter Rollback-Prozess: Mit der Git-Funktion zur Wiederherstellung können Sie einen früheren Zustand des Systems wiederherstellen.
Versionsverwaltung: Sie können Git-Commits mit Tags versehen, um eine Version des Systemstatus anzugeben.
Transaktionen: Sie müssen Statuskonflikte explizit beheben und prüfen, bevor Sie die Änderungen in den Status einbinden können.
Das folgende Diagramm zeigt, wie verschiedene Teams mit einem zentralisierten Repository für alle Änderungen interagieren:
In den folgenden Abschnitten wird erläutert, wie Operatoren, Entwickler und Sicherheitstechniker das Git-Repository in einem modernen CI/CD-System verwenden.
Operator-Repositories
Von Operatoren verwaltete Repositories enthalten Best Practices für die CI/CD und die Anwendungskonfiguration, mit denen Ihre Teams Anwendungen einrichten können, während sie die Best Practices für Unternehmen von Anfang an übernehmen. Wenn Sie Repositories verwalten, können Entwickler alle Updates der Best Practices der Organisation mit möglichst geringen Unterbrechungen des Workflows nutzen.
Operatoren können die Best Practices ihrer Organisation in zwei Repositories codieren. Im ersten Repository werden die Best Practices der CI/CD-Pipeline von Operatoren verwaltet. In diesem Repository bieten Operatoren Entwickler eine Bibliothek mit vordefinierten Aufgaben, mit denen sie ihre Pipelines erstellen können. Die Anwendungs-Repositories der Entwickler übernehmen diese Aufgaben und die darin enthaltene Logik automatisch. Die Aufgaben müssen nicht manuell kopiert werden. Beispiele für Aufgaben, die Sie in der gesamten Organisation standardisieren können:
Artefakterstellung und -speicher
Testmethoden für verschiedene Sprachen
Deployment
Richtlinienprüfungen
Sicherheitsscans
Das zweite Repository, in dem Operatoren gespeichert werden, speichert Best Practices für die Konfiguration einer Anwendung. Im Zusammenhang mit GKE erfordern die Best Practices eine Methode zur Verwaltung deklarativer Manifeste im Kubernetes-Ressourcenmodell. Diese Manifeste beschreiben den beabsichtigten Status der Anwendung. Operatoren können Basiskonfigurationen für verschiedene Arten von Anwendungen erstellen, wodurch Entwicklern ein rationalisierter Pfad für die Bereitstellung ihrer Anwendungen gemäß den Best Practices des Unternehmens zur Verfügung steht.
Anwendungs-Repositories
Anwendungs-Repositories speichern die Geschäftslogik der Anwendung und eine spezielle Konfiguration, die zum ordnungsgemäßen Betrieb der Anwendung erforderlich ist.
Wenn Operatoren Best Practices aufeinander aufbauen und pflegen, können Entwickler diese Best Practices umsetzen. Dazu verweisen die Entwickler auf die Aufgaben für CI/CD und die Anwendungsbasis, die die Operatoren in ihren eigenen Repositories erstellt haben. Nachdem Entwickler ihre Änderungen vorgenommen haben, können Operatoren die Bereitstellung der Anwendung weiter anpassen. Dazu fügen sie umgebungsspezifische Konfigurationen wie Datenbank-URLs, Ressourcenlabels und Annotationen hinzu.
Zu den Artefakten, die Sie in Anwendungs-Repositories speichern können, gehören zum Beispiel:
Quellcode der Anwendung
Ein
Dockerfile, das das Erstellen und Ausführen der Anwendung beschreibtCI/CD-Pipelinedefinition
Erweiterungen oder Änderungen an der Basis der Anwendungskonfiguration, die von Operatoren erstellt werden
Infrastruktur als Code-Repositories
Infrastruktur als Code-Repositories speichert den Code, um die für die Ausführung der Anwendungen erforderliche Infrastruktur zu erstellen. Die Infrastruktur kann Plattformen für die Netzwerk- und Containerorchestrierung wie GKE enthalten. Normalerweise gehören Infrastrukturadministratoren diese Repositories. Operatoren können sie aktualisieren, um Best Practices zu implementieren.
Zu den Artefakten, die Sie in Anwendungs-Repositories speichern können, gehören zum Beispiel:
- Deklarativer Sprachcode (Terraform, Pulumi), der Infrastrukturobjekte darstellt.
Shell- oder Python-Skripts, die die deklarativen API-Definitionen ergänzen.
Erweiterungen oder Änderungen an den grundlegenden Infrastrukturvorlagen, die vom Infrastrukturteam erstellt wurden.
Konfigurations- und Richtlinien-Repositories
Eine sichere und konsistente Plattform, die sowohl bei Betreibern als auch Sicherheitstechnikern höchste Priorität hat.
Konfiguration
Mit der zentralisierten Konfiguration können Sie Konfigurationsänderungen im gesamten System verteilen. Einige häufig verwendete Konfigurationselemente, die Sie zentral verwalten können, umfassen Folgendes:
Kubernetes-Namespaces
Kontingente
Rollenbasierte Zugriffssteuerung
Netzwerkrichtlinien
Sie sollten diese Konfigurationstypen immer in Ihren Clustern durchsetzen, damit die Anwendungsteams die Infrastruktur nicht fälschlicherweise oder missbräuchlich verwenden. Die Verwendung eines Git-Repositories zum Speichern von Konfigurationen kann Prozesse wie das Prüfen und Bereitstellen von Konfigurationen mit Methoden wie GitOps optimieren. Tools wie Config Sync können den Prozess der einheitlichen Anwendung von Konfigurationen in Ihrer Infrastruktur vereinfachen.
Richtlinie
Entwickler können die von Administratoren erstellten Basiskonfigurationen erweitern. Daher müssen Sie die Möglichkeit haben, die in den Clustern erstellten Ressourcen einzuschränken. In einigen Fällen können Sie eine Richtlinie erstellen, mit der Entwickler Ressourcen nur erstellen können, wenn diese Ressourcen bestimmte Anforderungen erfüllen. Beispielsweise lassen sich Kubernetes-Dienstobjekte erstellen, die nicht für das externe Load-Balancing konfiguriert werden können.
In der zugehörigen Referenzarchitektur verwenden Sie Policy Controller, um Richtlinien zu erzwingen.
Starter-Repositories
Starter-Repositories unterstützen die Akzeptanz von CI/CD, Infrastruktur und Best Practices für die Entwicklung auf der gesamten Plattform. Starter-Repositories können die Kosten im Zusammenhang mit der Anwendung von Best Practices erheblich reduzieren. Die Best Practices wiederum verbessern die Verfügbarkeit und Zuverlässigkeit von Funktionen sowie die Teamproduktivität. In der zugehörigen Referenzarchitektur gibt es mehrere Starter-Repositories für CI, CD, Kubernetes-Konfigurationen, Go, Java und Python-Starter-Anwendungen und -Infrastruktur.
Continuous Integration
Organisationen haben in der Regel eine Reihe von Standardaufgaben, die während der CI auf Anwendungen angewendet werden. In der Referenzimplementierung umfasst beispielsweise der Basissatz von CI-Phasen Folgendes: Code kompilieren und ein Container-Image erstellen. Da diese Phasen im Starter-Repository definiert sind, werden sie auf der gesamten Plattform einheitlich angewendet. Einzelne Anwendungsteams können zusätzliche Schritte hinzufügen.
Continuous Delivery
Ähnlich wie CI hat der Prozess für CD in der Regel eine Reihe von Standardschritten für die Bereitstellung von Anwendungen in den Entwickler-, Vorproduktions- und Produktionsumgebungen. Unabhängig von den eingesetzten Bereitstellungsmethoden ermöglicht das Starter-Repository Plattformteams die einheitliche Anwendung dieser Methoden über Anwendungen und Umgebungen hinweg. In der Referenzimplementierung umfasst der Bereitstellungsprozess Rollouts für Entwicklungen, Vorproduktions-Bereitstellungen, ein Produktionsbereitstellung in mehreren Clustern sowie manuelle Genehmigungen für die Produktionsbereitstellung mithilfe von Cloud Deploy.
Anwendungskonfiguration
Damit eine Softwarebereitstellungsplattform effektiv sein kann, benötigen Sie eine einheitliche und konsistente Methode zum Anwenden der Anwendungskonfiguration. Mit Tools wie kustomize und Starter-Repositories für Kubernetes-Konfigurationen können Plattformen eine einheitliche Grundlage für die Anwendungskonfiguration bieten. Beispielsweise initialisiert in der Referenzimplementierung die kustomize-Basiskonfiguration die Anwendungsumgebungs-Repositories mit einem bekannten Basissatz von Konfigurationen. Einzelne Anwendungsteams können die Konfigurationen anschließend an ihre Anforderungen anpassen.
Starter-Anwendungen
Mit Starter-Anwendungen können Sie den Aufwand für die Anwendung von Best Practices reduzieren, z. B. Beobachtbarkeit und Best Practices für Container.
Beobachtbarkeit: Um eine Anwendung effizient zu betreiben und ihre Zuverlässigkeit zu gewährleisten, müssen Anwendungen Logging, Messwerte und Tracings berücksichtigen. Mit Starter-Anwendungen können Teams Frameworks und Strategien entwickeln, die die Beobachtbarkeit ermöglichen.
Best Practices für Container: Wenn Sie containerisierte Anwendungen erstellen, sollten Sie kleine und saubere Container-Images erstellen. Zu den Best Practices für Container gehören das Verpacken einer einzelnen Anwendung in einem Image, das Entfernen unnötiger Tools aus dem Image und der Versuch, kleine Images aus minimalen Basis-Images zu erstellen. Weitere Informationen finden Sie unter Best Practices für das Erstellen von Containern.
Die Referenzarchitektur stellt eine einfache Go-Anwendung, eine einfache Java-Anwendung und eine einfache Python-Anwendung als Ausgangspunkt bereit. Sie sollten Starter-Anwendungen hinzufügen, die auf die Sprachen, Technologie-Stacks und Arten von Anwendungen zugeschnitten sind, die Ihre Teams entwickeln.
Infrastruktur-Starter-Repositories
Infrastruktur-Starter-Repositories enthalten den vordefinierten Code, der zum Erstellen verschiedener Infrastrukturkomponenten erforderlich ist. Diese Repositories verwenden Standardvorlagen und -module, die vom Infrastrukturteam festgelegt wurden.
Beispielsweise enthält in der Referenzimplementierung die Plattformvorlage den Startcode, um ein Google Cloud-Projekt, eine Virtual Private Cloud und einen GKE-Cluster zu erstellen. Diese Vorlage wird in der Regel von Infrastrukturteams verwendet, um die Infrastruktur von mehreren Anwendungsteams als gemeinsam genutzte Ressource zu verwalten. Entsprechend enthält die infra-Vorlage grundlegenden Startinfrastrukturcode, den eine Anwendung möglicherweise benötigt, z. B. eine Cloud Storage- oder eine Cloud Spanner-Datenbank. Diese Vorlage wird normalerweise von den Anwendungsteams verwendet, um die Infrastruktur für ihre Anwendungen zu verwalten.
Freigegebene Vorlagen-Repositories
Freigegebene Vorlagen-Repositories bieten Standardaufgabenvorlagen, die jeder in einer Organisation wiederverwenden kann. Beispielsweise Infrastruktur als Codemodule wie Terraform-Module, die zum Erstellen von Infrastrukturressourcen wie Netzwerken und Computing verwendet werden können.
Anwendungs-Landing-Zones
Wenn Sie eine gemeinsam genutzte CI/CD, eine gemeinsam genutzte Anwendungskonfiguration und eine konsistente Richtlinie und Konfiguration für mehrere Cluster verwenden, können Sie diese Funktionen miteinander kombinieren, um Anwendungs-Landing-Zonen zu erstellen.
Eine Landing-Zone ist eine abgeschlossene logische Einheit, die es Entwicklern ermöglicht, ihre Anwendungen bereitzustellen und zu iterieren. Anwendungs-Landing-Zonen nutzen die von Ihnen platzierten Leitplanken, damit Entwickler autonom arbeiten können. Sie erstellen für jede Anwendung einen Kubernetes-Namespace in jedem Cluster jeder Umgebung, z. B. für Produktion, Entwicklung oder Staging). Diese Konsistenz hilft Operatoren, Fehler zu beheben und die Umgebungen im Laufe der Zeit zu verwalten.
Das folgende Diagramm veranschaulicht das Konzept der Landing-Zonen:
Betriebsmodell
Wenn Sie eine Softwarebereitstellungsplattform mit moderner CI/CD betreiben, ist es wichtig, dass die Umgebungen, Infrastruktur und Prozesse konsistent und auf dem neuesten Stand sind. Sie müssen deshalb sorgfältig vorgehen und das Betriebssystem für die Plattform auswählen. Sie haben die Wahl zwischen verschiedenen Modellen, z. B. Clustern als Dienst, Entwürfe oder einer mehrmandantenfähigen Infrastruktur.
Da es wichtig ist, eine konsistente Infrastruktur aufrechtzuerhalten, Wildwuchs zu begrenzen und es den Teams zu ermöglichen, sich auf die Bereitstellung von Anwendungen zu konzentrieren, empfehlen wir Ihnen, eine mandantenfähige Infrastruktur zu implementieren. Durch die Bereitstellung von Anwendungen in einer mehrmandantenfähigen Infrastruktur ist es für die Anwendungsteams nicht mehr erforderlich, die Infrastruktur zu verwalten. Außerdem können sich Betreiber- und Sicherheitsteams darauf konzentrieren, die Infrastruktur konsistent zu halten.
Überlegungen zur mehrmandantenfähigen Infrastruktur
Wenn Sie eine mehrmandantenfähige Softwarebereitstellungsplattform erstellen, können Sie einige Dinge in die Plattform einbinden:
Arbeitlastisolation: Das Konzept der Anwendungs-Landing-Zonen bietet ein Framework zum Isolieren von Arbeitslasten. Landing-Zonen sind eine Kombination aus Namespaces, Netzwerkrichtlinien und RBAC. Alle diese Richtlinien sollten zentral verwaltet und über Config Sync angewendet werden.
Monitoring der Mandantennutzung: Kostenaufschlüsselungen für einzelne Namespaces und Labels in einem Cluster erhalten Sie mit der GKE-Nutzungsmessung. Die GKE-Nutzungsmessung erfasst Informationen zu Ressourcenanforderungen und Ressourcennutzung für die Arbeitslasten eines Clusters, die Sie weiter nach Namespaces und Labels filtern können. Wenn Sie die GKE-Nutzungsmessung für den mehrmandantenfähigen Cluster aktivieren, werden Datensätze der Ressourcennutzung in eine BigQuery geschrieben. Sie können mandantenspezifische Messwerte nach BigQuery-Datasets im entsprechenden Mandantenprojekt exportieren. Auditoren haben dann die Möglichkeit, diese Messwerte zu analysieren und Kostenaufschlüsselungen zu ermitteln.
Ressourcenkontingente: Damit alle Mandanten, die einen Cluster teilen, faire Zugriffe auf die Clusterressourcen haben, müssen Sie Ressourcenkontingente erzwingen. Erstellen Sie ein Ressourcenkontingent für jeden Namespace basierend auf der Anzahl der Pods, die jeder Mandant bereitstellt, sowie der Größe des Arbeitsspeichers und der CPU, die jeder Pod benötigt.
Mehrere Cluster für jede Umgebung: Zur Verbesserung der Anwendungs- und Plattformzuverlässigkeit sollten Sie mehrere Cluster für jede Vorproduktions- und Produktionsumgebung verwenden. Wenn mehrere Cluster verfügbar sind, können Sie Anwendungen für zusätzliche Canary-Validierungen in Clustern einzeln bereitstellen. Darüber hinaus verringert das Vorhandensein mehrerer Cluster die Risiken, die mit dem Lebenszyklus von Cluster-Management und Upgrades verbunden sind.
Tenant-Logging und -Monitoring Zum Untersuchen der Vorgänge ihrer Anwendungen benötigen Mandanten Zugriff auf Logs und Messwerte. In einer Umgebung mit mehreren Mandanten sollten Logging und Monitoring anwendungsspezifisch sein. Für Messwerte und Monitoring können Sie für jeden Namespace Google Cloud Managed Service for Prometheus und Grafana verwenden. Für Logs müssen Sie eine Senke für den Export von Logeinträgen in BigQuery-Datasets erstellen und die Datasets dann nach dem Mandanten-Namespace filtern. Mandanten können dann auf die exportierten Daten in BigQuery zugreifen.
Weitere Informationen zu einer mehrmandantenfähigen Infrastruktur finden Sie unter Best Practices für Mehrmandantenfähigkeit in Unternehmen.
Isolationsgrenzen
Eine Softwarebereitstellungsplattform wird von mehreren Teams erstellt und verwendet. Daher ist es wichtig, geeignete Isolationsgrenzen zwischen verschiedenen Komponenten der Plattform zu haben. Die Isolationsgrenzen helfen bei der Erstellung einer robusten Plattform:
Verantwortlichkeiten entkoppeln. Jedes Team verwaltet die Ressourcen in seinen Isolationsgrenzen, ohne sich um den Rest Gedanken machen zu müssen. Beispielsweise ist das Infrastrukturteam nur für die Verwaltung von GKE-Clustern verantwortlich. Operatoren oder Entwickler sind nur für die Verwaltung der CI/CD-Pipelines und des Anwendungscodes verantwortlich.
Detaillierte Zugriffssteuerung. Wenn die Ressourcen durch Isolationsgrenzen getrennt sind, verwenden Sie eine detaillierte Zugriffssteuerung, um den Zugriff einzuschränken.
Reduziert die betroffenen Bereiche. Sie können Änderungen an einer Komponente unabhängig vornehmen, ohne andere Komponenten zu beeinträchtigen.
Weniger manuelle Fehler. Da die Zugriffssteuerung detailliert ist, können Sie manuelle Fehler wie das versehentliche Bereitstellen in einem Produktionscluster aus einer Entwicklungsumgebung vermeiden.
Diese Isolationsgrenzen können zwischen verschiedenen Anwendungen, Infrastruktur und Anwendungen oder sogar zwischen den verschiedenen Umgebungen einer Anwendung bestehen.
Governance
Das Hauptziel von Softwarebereitstellungsplattformen und modernen CI-/CD-Systemen ist die Verbesserung der Effizienz des gesamten Softwarebereitstellungsprozesses. In Bezug auf die Verwaltung der Plattform gibt es zwei Hauptüberlegungen: das „Onboarding von Anwendungen”, das im Allgemeinen unter die Kategorie „Governance” fällt, und die laufende Entwicklung und Wartung der Plattform (d. h. die Plattform wie ein Produkt zu behandeln).
Onboarding und Verwaltung von Anwendungen
Das Ziel der modernen CI/CD-Methodologie und -Tools ist die Vereinfachung des Veröffentlichungsprozesses und der Einrichtung neuer Dienste. Das Onboarding neuer Anwendungen sollte ein einfacher Prozess sein, den Sie mit minimale Eingaben von Betriebs- und Sicherheitsteams durchführen können. Dies bedeutet nicht, dass Betriebs- und Sicherheitsteams nicht beteiligt sind, aber ihre erste Eingabe aus der Bereitstellungs- und Sicherheitsperspektive wird automatisch über den Bereitstellungsprozess abgewickelt. Nach der Einführung werden Betriebs- und Sicherheitsteams natürlich in den Releaseprozess über Zusammenführungsanfragen, Richtlinienaktualisierungen und die Durchsetzung von Best Practices aufgenommen.
Es wird empfohlen, eine Automatisierung zur Einrichtung einer neuen Anwendung zu erstellen. Dazu können das Erstellen von Code-Repositories, CI/CD-Pipelines, Landing-Zonen und jeder für die Anwendung erforderlichen Infrastruktur gehören. Die Automatisierung entkoppelt die komplexen Abhängigkeiten von Entwicklungsteams in anderen Teams der Organisation und bietet Entwicklern Autonomie, um eine Anwendung selbst zu verwalten. Auf diese Weise können die Entwickler den Code der Anwendung sehr schnell iterieren und keine Zeit für die Ausführung der anderen Aufgaben außer dem Schreiben des Codes verschwenden. Die Automatisierung sollte Entwicklern die Möglichkeit geben, die Anwendung in einer Entwicklungsumgebung auszuführen. Wenn die Anwendung in höheren Umgebungen ausgeliefert werden soll, sollten andere Teams beteiligt sein und der Überprüfungsprozess sollte befolgt werden.
In der zugehörigen Referenzarchitektur wird diese Automatisierung als Application Factory bezeichnet.
Plattform als Produkt
Der CI/CD-Workflow ist ein Softwareprodukt, außer dass die Nutzer des Produkts Entwicklungs-, Betriebs- und Sicherheitsteams sind. Vor diesem Hintergrund sind für die Plattform dieselben Rollen und Prozesse für die Softwareentwicklung erforderlich, z. B. für Produkteigentümer, Marketing (intern) und Feedback-Loops und Funktionsentwicklungszyklen.
CI/CD mit GKE bereitstellen
Wenn Sie moderne CI/CD mit GKE im Unternehmen bereitstellen, ist die Auswahl der besten Pilotanwendungen entscheidend. Entwicklungs-, Einsatz- und Sicherheitsteams müssen bei ihrer Arbeit auch andere Faktoren berücksichtigen, die in diesem Abschnitt beschrieben werden.
Pilotanwendung auswählen
Es kann schwierig sein, die ersten Anwendungen zum Verschieben auf die Plattform auszuwählen. Gute Kandidaten für Piloten sind Dienste, die Daten verarbeiten oder Anfragen verarbeiten, aber keine Daten speichern, z. B. Caching-Schichten, Web-Front-Ends oder ereignisbasierte Verarbeitungsanwendungen. In der Regel sind diese Anwendungen weniger anfällig für kleine Ausfallzeiten und Bereitstellungsfehler, die auftreten können, wenn Sie mit neuen Techniken zur Bereitstellungs- und Konfigurationsverwaltung arbeiten. Wenn die Teams mehr Erfahrung mit CI/CD bekommen und den Vorteil von Zuverlässigkeit und Geschwindigkeit sehen, können Sie die Hauptdienste auf die Plattform für die Softwarebereitstellung verschieben.
Überlegungen für Entwickler
Wenn Sie in einem modernen CI/CD-Entwicklungsprozess arbeiten, können Funktionen, Änderungen und Bereitstellungen sowohl mit erhöhter Frequenz als auch asynchron erfolgen. Entwicklungsteams müssen nachvollziehen können, wie sich Änderungen auf nachgelagerte oder abhängige Systeme auswirken und wie diese Änderungen getestet werden. Kommunikationswege zwischen Entwicklungs-, Betriebs- und Sicherheitsteams müssen fließend sein. Es empfiehlt sich, sowohl für Anwendungen als auch für die Datenverträge, mit denen die verschiedenen Dienste kommunizieren, bessere Maßnahmen in Bezug auf die Versionsverwaltung vorzunehmen. Neben der Verbesserung der Kommunikationsmethoden und der Versionierung kann die Implementierung von Features in kleinen Teilen und die Verwendung von Feature-Zweigen und Flags die Test- und Freigabeverfahren von Features verbessern.
Überlegungen zu Operatoren
Mit einer Softwarebereitstellungsplattform müssen Betriebsteams mehr wie Entwicklerteams arbeiten. Statt externe Features zu entwickeln, erstellen sie interne Tools und Prozesse, die die Entwicklung, Bereitstellung und den Betrieb externer Anwendungen erleichtern. Plattformtools werden von ihrem eigenen Team sowie den Entwicklungs- und Sicherheitsteams verwendet. Operatoren sollten Tools zur Unterstützung bei der Einführung neuer Anwendungsversionen erstellen und diese im Fall von Anwendungsfehlern oder Bereitstellungsfehlern wiederherstellen. Operatoren sollten auch darauf achten, Monitoring- und Benachrichtigungssysteme verstärkt zu erstellen, um Fehler proaktiv zu erkennen und entsprechend anzupassen.
Überlegungen für Sicherheitsteams
Die Sicherheitsteams sollten darauf hinarbeiten, die Sicherheit mehr zu einer gemeinsamen Verantwortung zwischen ihnen und den Operations- und Entwicklungsteams zu machen. Dieses Muster wird allgemein als Verschiebung nach links bei der Sicherheit bezeichnet, bei dem die Informationssicherheit (InfoSec) früh in den Entwicklungsprozess einbezogen wird, Entwickler mit vorab genehmigten Tools arbeiten und Sicherheitstests automatisiert werden. Zusätzlich zu diesen Verfahren können Sie programmatisch Sicherheitsrichtlinien mit Policy Controller definieren und durchsetzen. Durch die Kombination von Techniken und Tools wird die Sicherheitsdurchsetzung noch proaktiver.
Nächste Schritte
Implementieren von Aspekten dieser modernen CI-/CD-Architektur
Kubernetes und die Herausforderungen der kontinuierlichen Softwarebereitstellung