Der Unternehmensanwendungs-Blueprint wird über eine Reihe automatisierter Systeme und Pipelines bereitgestellt. Jede Pipeline stellt einen bestimmten Aspekt des Blueprints bereit. Pipelines bieten einen steuerbaren, überprüfbaren und wiederholbaren Mechanismus zum Erstellen des Blueprints. Das folgende Diagramm zeigt die Interaktion der verschiedenen Pipelines, Repositories und Personas.
Der Blueprint verwendet die folgenden Pipelines:
- Die Pipeline für die Grundlageninfrastruktur (Teil des Grundlagen-Blueprints für Unternehmen) stellt die Anwendungs-Factory, die mehrmandantenfähige Infrastrukturpipeline und die Pipeline des Fleet-Bereichs bereit.
- Die mehrmandantenfähige Infrastrukturpipeline stellt die GKE-Cluster und die anderen verwalteten Dienste bereit, auf die sich der Blueprint der Unternehmensanwendung stützt.
- Die Flotten-Pipeline konfiguriert Flottenbereiche, Namespaces sowie RBAC-Rollen und -Bindungen.
- Die Application Factory bietet einen Mechanismus zum Bereitstellen neuer Anwendungspipelines über einen Vorlagenprozess.
- Die CI-/CD-Pipeline der Anwendung bietet eine CI/CD-Pipeline zum Bereitstellen von Diensten in GKE-Clustern.
- Config Sync stellt zusätzliche Kubernetes-Konfigurationen bereit und verwaltet diese, einschließlich Einschränkungen des Policy Controllers.
Repositories, Repository-Beitragende und Repository-Änderungsgenehmiger
Die Blueprint-Pipelines werden durch Änderungen an Git-Repositories ausgelöst. Die folgende Tabelle beschreibt die Repositories, die im gesamten Blueprint verwendet werden, wer zum Repository beiträgt, wer Änderungen am Repository genehmigt, welche Pipeline das Repository verwendet und die Beschreibung des Inhalts des Repositorys.
| Repository | Repository-Mitwirkender | Genehmiger von Repository-Änderungen | Pipeline | Beschreibung |
|---|---|---|---|---|
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Grundlageninfrastruktur-Pipeline |
Repository, das den Code zum Bereitstellen der mehrmandantenfähigen Infrastrukturpipeline, der Anwendung und der Pipeline im Flottenbereich enthält |
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Mehrmandantenfähige Infrastruktur |
Die Terraform-Module, die von Entwicklerplattformteams beim Erstellen der Infrastruktur verwendet werden |
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Flottenbereich |
Das Repository, das die Bereiche und Namespaces des Flottenteams in der Flotte definiert |
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Application Factory |
Der Code, der das Anwendungs-Repository definiert und auf die Module im Repository |
|
Symbol: Anwendungsentwickler |
Anwendungsoperator |
Application Factory |
Der Basiscode, der im |
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Application Factory Mehrmandantenfähige Infrastruktur |
Die Terraform-Module, die die Anwendung und die Infrastruktur definieren |
|
Symbol: Anwendungsentwickler |
Anwendungsoperator |
Anwendungs-CI/CD |
Der Anwendungscode, der in den GKE-Clustern bereitgestellt wird |
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Config Sync |
Die Richtlinien, die von den GKE-Clustern zur Verwaltung ihrer Konfigurationen verwendet werden |
Automatisierte Pipelines helfen bei der Bereitstellung von Sicherheit, Prüfbarkeit, Rückverfolgbarkeit, Wiederholbarkeit, Kontrollierbarkeit und Compliance im Bereitstellungsprozess. Indem Sie verschiedene Systeme mit unterschiedlichen Berechtigungen verwenden und verschiedene Personen in verschiedene Arbeitsgruppen einteilen, schaffen Sie eine Trennung der Verantwortlichkeiten und folgen dem Prinzip der geringsten Berechtigung.
Grundlageninfrastruktur-Pipeline
Die Pipeline für die Grundlageninfrastruktur wird im Grundlagen-Blueprint für Unternehmen beschrieben und als generischer Einstiegspunkt für weitere Ressourcenbereitstellungen verwendet. In der folgenden Tabelle werden die Komponenten beschrieben, die die Pipeline erstellt.
| Komponente | Beschreibung |
|---|---|
Erstellt die gemeinsam genutzte Infrastruktur, die von allen Mandanten der Entwicklerplattform verwendet wird. |
|
Erstellt Namespaces und RBAC-Rollenbindungen. |
|
Erstellt die CI/CD-Pipelines der Anwendung, die zum Bereitstellen der Dienste verwendet werden. |
Infrastruktur-Pipeline für mehrere Mandanten
Die mehrmandantenfähige Infrastrukturinfrastrukturpipeline stellt Flotten, GKE-Cluster und zugehörige freigegebene Ressourcen bereit. Das folgende Diagramm zeigt die Komponenten der mehrmandantenfähigen Infrastrukturpipeline.
In der folgenden Tabelle werden die Komponenten beschrieben, die die mehrmandantenfähige Infrastrukturpipeline erstellt.
| Komponente | Beschreibung |
|---|---|
GKE-Cluster |
Bietet Hosting für die Dienste der containerisierten Anwendung. |
Policy Controller |
Stellt Richtlinien bereit, die für die ordnungsgemäße Konfiguration der GKE-Cluster und -Dienste sorgen. |
Config Sync |
Wendet die Policy Controller-Richtlinien auf Cluster an und verwaltet die konsistente Anwendung der Richtlinien. |
Erstellt den Verschlüsselungsschlüssel, der auf dem vom Kunden verwalteten Verschlüsselungsschlüssel (CMEK) für GKE, AlloyDB für PostgreSQL und Secret Manager basiert. |
|
Secret Manager-Secret |
Bietet einen Secret-Speicher für das RSA-Schlüsselpaar, das für die Nutzerauthentifizierung mit JSON-Web-Tokens (JWT) verwendet wird. |
Stellt die Richtlinie bereit, die von der Firewall-Webanwendung von Google Cloud Armor verwendet wird. |
Flottenbereich-Pipeline
Die Pipeline für den Flottenbereich ist für die Konfiguration der Namespaces und RBAC-Bindungen in den GKE-Clustern der Flotte verantwortlich. In der folgenden Tabelle werden die Komponenten beschrieben, die von der Pipeline für den Flottenbereich erstellt werden.
| Komponente | Beschreibung |
|---|---|
Definiert die logischen Cluster innerhalb des physischen Clusters. |
|
Definiert die Autorisierung, die ein Kubernetes-Dienstkonto auf Cluster- oder Namespace-Ebene hat. |
Application Factory
Die Anwendungs-Factory wird von der Grundlagen-Infrastrukturpipeline bereitgestellt und zum Erstellen der Infrastruktur für jede neue Anwendung verwendet. Diese Infrastruktur umfasst ein Google Cloud-Projekt, das die CI/CD-Pipeline der Anwendung enthält.
Wenn Entwicklungsorganisationen skalieren, kann das Anwendungsteam neue Anwendungen mithilfe der Anwendungs-Factory einrichten. Die Skalierung ermöglicht Wachstum, indem diskrete CI-/CD-Pipelines der Anwendung hinzugefügt werden und die Infrastruktur für die Bereitstellung neuer Anwendungen innerhalb der mehrmandantenfähigen Architektur unterstützt wird. Das folgende Diagramm zeigt die Application Factory.
Die Application Factory besteht aus den folgenden Komponenten:
- Application Factory-Repository: Ein Git-Repository, in dem die deklarative Anwendungsdefinition gespeichert wird.
- Pipelines zum Erstellen von Anwendungen: Pipelines, die Cloud Build benötigen, um Folgendes auszuführen:
- Erstellen Sie eine deklarative Anwendungsdefinition und speichern Sie sie im Anwendungskatalog.
- Wenden Sie die deklarative Anwendungsdefinition an, um die Anwendungsressourcen zu erstellen.
- Starter-Vorlagen-Repository: Vorlagen zum Erstellen einer einfachen Anwendung (z. B. eines Python-, Golang- oder Java-Mikrodiensts).
- Freigegebene Module: Terraform-Module, die mit Standardpraktiken erstellt und für mehrere Zwecke verwendet werden, einschließlich des Onboardings und der Bereitstellung von Anwendungen.
In der folgenden Tabelle sind die Komponenten aufgeführt, die die Anwendungs-Factory für jede Anwendung erstellt.
| Komponente | Beschreibung |
|---|---|
Quellcode-Repository der Anwendung |
Enthält Quellcode und zugehörige Konfiguration, die zum Erstellen und Bereitstellen einer bestimmten Anwendung verwendet werden. |
Anwendungs-CI-/CD-Pipeline |
Eine Cloud Build-basierte Pipeline, die zum Herstellen einer Verbindung zum Quellcode-Repository verwendet wird und eine CI/CD-Pipeline zum Bereitstellen von Anwendungsdiensten bereitstellt. |
Anwendungs-CI-/CD-Pipeline
Die CI/CD-Pipeline der Anwendung ermöglicht die automatische Erstellung und Bereitstellung von containerbasierten Anwendungen. Die Pipeline besteht aus den Schritten der kontinuierlichen Integration (CI) und der kontinuierlichen Bereitstellung (CD). Die Pipelinearchitektur basiert auf dem Sicheren CI/CD-Blueprint.
Die CI/CD-Pipeline der Anwendung verwendet in Ihren Umgebungen unveränderliche Container-Images. Bei unveränderlichen Container-Images wird dasselbe Image in allen Umgebungen bereitgestellt und während der Ausführung des Containers nicht geändert. Wenn Sie den Anwendungscode aktualisieren oder einen Patch anwenden müssen, erstellen Sie ein neues Image und stellen es neu bereit. Bei unveränderlichen Container-Images müssen Sie Ihre Containerkonfiguration externalisieren, damit Konfigurationsinformationen während der Laufzeit gelesen werden.
Um GKE-Cluster über einen privaten Netzwerkpfad zu erreichen und die kubeconfig-Authentifizierung zu verwalten, interagiert die CI/CD-Pipeline der Anwendung über das Connect-Gateway mit den GKE-Clustern. Die Pipeline verwendet auch private Pools für die CI/CD-Umgebung.
Jedes Quellcode-Repository der Anwendung enthält Kubernetes-Konfigurationen. Mit diesen Konfigurationen können Anwendungen erfolgreich als Kubernetes-Dienste in GKE ausgeführt werden. In der folgenden Tabelle sind die Kubernetes-Konfigurationstypen aufgeführt, die die CI/CD-Pipeline der Anwendung anwendet.
| Komponente | Beschreibung |
|---|---|
Definiert einen skalierten Satz von Pods (Containern). |
|
Macht ein Deployment über das Clusternetzwerk erreichbar. |
|
Macht einen Dienst Teil des Service Mesh. |
|
Definiert, wie Peers im Service Mesh einen virtuellen Dienst erreichen müssen. Wird im Blueprint verwendet, um das Ort-Load-Balancing für Ost-West-Traffic zu konfigurieren. |
|
Legt die Zugriffssteuerung zwischen Arbeitslasten im Service Mesh fest. |
|
Definiert eine Identität, die von einem Kubernetes-Dienst verwendet wird. Workload Identity definiert das Google Cloud-Dienstkonto, das für den Zugriff auf Google Cloud-Ressourcen verwendet wird. |
|
Lässt externen eingehenden Traffic zu einem Dienst zu. Das Gateway ist nur für Bereitstellungen erforderlich, die externen Traffic empfangen. |
|
SSL, Google Cloud Armor, Sitzungsaffinität und Verbindungsausgleich für Bereitstellungen konfigurieren, die externen Traffic empfangen. Die GCPBackendPolicy wird nur von Bereitstellungen verwendet, die externen Traffic empfangen. |
|
Konfiguriert die Sammlung von Prometheus-Messwerten, die von einer Anwendung exportiert werden. |
Continuous Integration
Das folgende Diagramm zeigt den Prozess von Continuous Integration.
Der Prozess läuft so ab:
- Ein Entwickler übergibt den Anwendungscode an das Anwendungsquell-Repository. Dieser Vorgang löst Cloud Build aus, um mit der Integrations-Pipeline zu beginnen.
- Cloud Build erstellt ein Container-Image, überträgt das Container-Image per Push an Artifact Registry und erstellt einen Image-Digest.
- Cloud Build führt automatisierte Tests für die Anwendung durch. Je nach Anwendungssprache werden möglicherweise verschiedene Testpakete ausgeführt.
- Cloud Build führt die folgenden Scans für das Container-Image aus:
- Cloud Build analysiert den Container mithilfe des Frameworks Containerstrukturtests. Dieses Framework führt Befehlstests, Dateiexistenztests, Dateiinhaltstests und Metadatentests aus.
- Cloud Build verwendet Scans auf Sicherheitslücken, um Sicherheitslücken im Container-Image anhand einer Sicherheitslückendatenbank zu identifizieren, die von Google Cloud verwaltet wird.
- Cloud Build genehmigt das Image, damit es in der Pipeline fortgeführt werden kann, nachdem der Scan erfolgreich abgeschlossen wurde.
- Bei der Binärautorisierung wird das Image signiert. Die Binärautorisierung ist ein Dienst in Google Cloud, der Software-Lieferkettensicherheit für containerbasierte Anwendungen mithilfe von Richtlinien, Regeln, Hinweisen, Attestierungen, Attestierern und Signaturgebern bietet. Zum Zeitpunkt der Bereitstellung prüft der Erzwinger der Richtlinien der Binärautorisierungen die Herkunft des Containers, bevor er bereitgestellt werden kann.
- Cloud Build erstellt in Cloud Deploy einen Release, um den Bereitstellungsprozess zu starten.
Die Sicherheitsinformationen für einen Build finden Sie im Bereich "Sicherheitsstatistiken". Zu diesen Informationen gehören Sicherheitslücken, die mit Artifact Analysis erkannt wurden, sowie der Sicherheitsgrad des Builds, der in den SLSA-Richtlinien angegeben ist.
Beim Erstellen Ihrer Anwendung sollten Sie sich an die Best Practices zum Erstellen von Containern halten.
Kontinuierliche Bereitstellung
Das folgende Diagramm zeigt den Prozess der kontinuierlichen Bereitstellung.
Der Prozess läuft so ab:
- Am Ende des Build-Prozesses erstellt die Anwendungs-CI/CD-Pipeline einen neuen Cloud Deploy-Release, um die neu erstellten Container-Images schrittweise in jeder Umgebung zu starten.
- Cloud Deploy initiiert einen Rollout in der ersten Umgebung der Bereitstellungspipeline, die sich in der Regel in der Entwicklung befindet. Jede Bereitstellungsphase ist so konfiguriert, dass eine manuelle Genehmigung erforderlich ist.
- Die Cloud Deploy-Pipelines verwenden sequenzielle Deployment, um Images in jedem Cluster in einer Umgebung der Reihe nach bereitzustellen.
- Am Ende jeder Bereitstellungsphase überprüft Cloud Deploy die Funktionalität der bereitgestellten Container. Diese Schritte können in der Skaffold-Konfiguration für die Anwendungen konfiguriert werden.
Neue Anwendung bereitstellen
Das folgende Diagramm zeigt, wie die Anwendungs-Factory und die CI-/CD-Pipeline der Anwendung gemeinsam eine neue Anwendung erstellen und bereitstellen.
So definieren Sie eine neue Anwendung:
- Ein Anwendungsoperator definiert eine neue Anwendung innerhalb seines Mandanten, indem er einen Cloud Build-Trigger ausführt, um die Anwendungsdefinition zu generieren.
- Der Trigger fügt der Terraform-Datei einen neuen Eintrag hinzu und übergibt die Änderung per Commit an das Anwendungs-Factory-Repository.
- Die feste Änderung löst die Erstellung anwendungsspezifischer Repositories und Projekte aus.
- Cloud Build führt Folgendes aus:
- Erstellt zwei neue Git-Repositories zum Hosten des Quellcodes der Anwendung und von IaC.
- Sendet die Kubernetes-Manifeste für Netzwerkrichtlinien und Workload Identity an das Konfigurationsverwaltungs-Repository.
- Erstellt das CI/CD-Projekt und den Cloud Build-IaC-Trigger der Anwendung.
- Der Cloud Build IaC-Trigger für die Anwendung erstellt die CI/CD-Pipeline der Anwendung und das Artifact Registry-Repository im CI/CD-Projekt der Anwendung.
- Config Sync stellt die Netzwerkrichtlinien und Workload Identity-Konfigurationen für die mehrmandantenfähigen GKE-Cluster bereit.
- Die Pipeline zur Erstellung von Flottenbereichen erstellt den Flottenbereich und den Namespace für die Anwendung in mehrmandantenfähigen GKE-Clustern.
- Die CI/CD-Pipeline der Anwendung führt die erste Bereitstellung der Anwendung in den GKE-Clustern durch.
- Optional verwendet das Anwendungsteam den Cloud Build IaC-Trigger, um Projekte und zusätzliche Ressourcen (z. B. Datenbanken und andere verwaltete Dienste) für dedizierte Einzelmandantenprojekte bereitzustellen, eines für jede Umgebung.
GKE Enterprise-Konfiguration und Richtlinienverwaltung
Im Blueprint verwenden Administratoren der Entwicklerplattform Config Sync, um in jeder Umgebung Konfigurationen auf Clusterebene zu erstellen. Config Sync stellt eine Verbindung zu einem Git-Repository her, das als „Source of Truth“ für den ausgewählten Status der Clusterkonfiguration dient. Config Sync überwacht kontinuierlich den tatsächlichen Status der Konfiguration in den Clustern und gleicht etwaige Diskrepanzen aus. Dabei werden Aktualisierungen angewendet, um die Einhaltung des ausgewählten Status zu gewährleisten, trotz manueller Änderungen. Die Konfigurationen werden auf die Umgebungen (Entwicklung, Nicht-Produktion und Produktion) angewendet, indem eine Verzweigungsstrategie für das Repository verwendet wird.
In diesem Blueprint wendet Config Sync Einschränkungen für Richtliniencontroller an. Diese Konfigurationen definieren Sicherheits- und Compliancekontrollen, die von Entwicklerplattformadministratoren für die Organisation definiert werden. Dieser Entwurf basiert auf anderen Pipelines, um andere Konfigurationen anzuwenden: Die CI/CD-Pipelines der Anwendung wenden eine anwendungsspezifische Konfiguration an und die Pipeline für den Flottenbereich erstellt Namespaces und zugehörige Rollenbindungen.
Nächste Schritte
- Erfahren Sie mehr über die Cymbal Bank-Anwendungsarchitektur (nächstes Dokument in dieser Reihe).