Einrichtungsverfahren

Der Blueprint für Unternehmensanwendungen wird über eine Reihe automatisierter Systeme und Pipelines bereitgestellt. Jede Pipeline stellt einen bestimmten Aspekt des Blueprints bereit. Pipelines bieten einen steuerbaren, prüfbaren und wiederholbaren Mechanismus zum Erstellen des Blueprints. Das folgende Diagramm zeigt die Interaktion der verschiedenen Pipelines, Repositories und Identitäten.

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 Pipeline für die mehrmandantenfähige Infrastruktur stellt die GKE-Cluster und die anderen verwalteten Dienste bereit, auf die der Blueprint für Unternehmensanwendungen angewiesen ist.
• Die Pipeline für Flottenbereiche konfiguriert Flottenbereiche, Namespaces sowie RBAC-Rollen und ‑Bindungen.
• Die Application Factory bietet einen Mechanismus zum Bereitstellen neuer Anwendungspipelines über einen auf Vorlagen basierenden Prozess.
• Die Anwendungs-CI-/CD-Pipeline bietet eine CI/CD-Pipeline zum Bereitstellen von Diensten in GKE-Clustern.
• Mit Config Sync werden zusätzliche Kubernetes-Konfigurationen bereitgestellt und verwaltet, einschließlich Policy Controller-Einschränkungen.

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-Beitragender	Genehmiger von Repository-Änderungen	Pipeline	Beschreibung
infra	Entwicklerplattformentwickler	Administrator der Entwicklerplattform	Grundlageninfrastruktur-Pipeline	Repository mit dem Code zum Bereitstellen der mehrmandantenfähigen Infrastrukturpipeline, der Anwendung und der Pipeline des Flottenbereichs
eab-infra	Entwicklerplattformentwickler	Administrator der Entwicklerplattform	Infrastruktur für mehrere Mandanten	Die Terraform-Module, die von den Teams der Entwicklerplattform beim Erstellen der Infrastruktur verwendet werden
fleet-scope	Entwicklerplattformentwickler	Administrator der Entwicklerplattform	Flottenbereich	Das Repository, in dem die Teambereiche und Namespaces der Flotte definiert sind.
app-factory	Entwicklerplattformentwickler	Administrator der Entwicklerplattform	Application Factory	Der Code, der das Anwendungs-Repository definiert und auf die Module im terraform-modules-Repository verweist
app-template	Symbol: Anwendungsentwickler	Anwendungsoperator	Application Factory	Der Basiscode, der beim ersten Erstellen des Repositorys im Repository app-code platziert wird
terraform-modules	Entwicklerplattformentwickler	Administrator der Entwicklerplattform	Application Factory Infrastruktur für mehrere Mandanten	Die Terraform-Module, die die Anwendung und die Infrastruktur definieren
app-code	Symbol: Anwendungsentwickler	Anwendungsoperator	Anwendungs-CI/CD	Der Anwendungscode, der in den GKE-Clustern bereitgestellt wird
config-policy	Entwicklerplattformentwickler	Administrator der Entwicklerplattform	Config Sync	Die Richtlinien, die von den GKE-Clustern verwendet werden, um ihre Konfigurationen beizubehalten

Automatisierte Pipelines helfen dabei, Sicherheits-, Prüf- und Rückverfolgbarkeit, Wiederholbarkeit, Kontrollierbarkeit und Compliance in den Bereitstellungsprozess zu integrieren. 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 von der Pipeline erstellt werden.

Komponente	Beschreibung
Pipeline für die Infrastruktur für mehrere Mandanten	Erstellt die gemeinsam genutzte Infrastruktur, die von allen Mandanten der Entwicklerplattform verwendet wird.
Flottenbereich-Pipeline	Erstellt Namespaces und RBAC-Rollenbindungen.
Application Factory	Erstellt die CI/CD-Pipelines der Anwendung, die zum Bereitstellen der Dienste verwendet werden.

Infrastruktur-Pipeline für mehrere Mandanten

Die mehrmandantenfähige Infrastrukturpipeline stellt Flotten, GKE-Cluster und zugehörige freigegebene Ressourcen bereit. Das folgende Diagramm zeigt die Komponenten der Pipeline für die mehrmandantenfähige Infrastruktur.

In der folgenden Tabelle werden die Komponenten beschrieben, die von der Multi-Tenant-Infrastrukturpipeline erstellt werden.

Komponente	Beschreibung
GKE-Cluster	Bietet Hosting für die Dienste der containerisierten Anwendung.
Policy Controller	Bietet Richtlinien, die die richtige Konfiguration der GKE-Cluster und -Dienste gewährleisten.
Config Sync	Wendet die Policy Controller-Richtlinien auf Cluster an und sorgt für eine konsistente Anwendung der Richtlinien.
Cloud Key Management Service-Schlüssel (Cloud KMS)	Erstellt den Verschlüsselungsschlüssel, der auf dem vom Kunden verwalteten Verschlüsselungsschlüssel (CMEK) für GKE, AlloyDB for 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.
Cloud Armor-Sicherheitsrichtlinie	Gibt die Richtlinie an, die von der Cloud Armor-Webanwendungsfirewall verwendet wird.

Flottenbereich-Pipeline

Die Pipeline im 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
Namespace	Definiert die logischen Cluster innerhalb des physischen Clusters.
RBAC (Rollen und Bindungen)	Definiert die Autorisierung, die ein Kubernetes-Dienstkonto auf Cluster- oder Namespace-Ebene hat.

Application Factory

Die Application Factory wird von der Grundlage der Infrastruktur-Pipeline 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 Engineering-Organisationen wachsen, kann das Anwendungsteam neue Anwendungen mithilfe der Application Factory einrichten. Durch die Skalierung wird Wachstum ermöglicht, indem separate CI/CD-Pipelines für Anwendungen hinzugefügt und die Infrastruktur für die Bereitstellung neuer Anwendungen in der Mehrmandantenarchitektur unterstützt wird. Das folgende Diagramm zeigt die Anwendungsfactory.

Die Anwendungsfactory hat die folgenden Komponenten:

• Repository für die Anwendungsfactory:Ein Git-Repository, in dem die deklarative Anwendungsdefinition gespeichert ist.
• Pipelines zum Erstellen von Anwendungen:Pipelines, für die Cloud Build Folgendes ausführen muss:
  • Erstellen Sie eine deklarative Anwendungsdefinition und speichern Sie sie im Anwendungskatalog.
  • Wenden Sie die deklarative Anwendungsdefinition an, um die Anwendungsressourcen zu erstellen.
• Repository mit Vorlagen für Starteranwendungen:Vorlagen zum Erstellen einer einfachen Anwendung (z. B. eines Python-, Golang- oder Java-Mikrodienstes).
• Gemeinsam genutzte Module:Terraform-Module, die nach Standardverfahren erstellt werden und für mehrere Zwecke verwendet werden, einschließlich der Einbindung und Bereitstellung von Anwendungen.

In der folgenden Tabelle sind die Komponenten aufgeführt, die von der Anwendungsfactory für jede Anwendung erstellt werden.

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 auf Cloud Build basierende Pipeline, die zum Herstellen einer Verbindung zum Quellcode-Repository verwendet wird und eine CI/CD-Pipeline für die Bereitstellung von Anwendungsdiensten bereitstellt.

Anwendungs-CI-/CD-Pipeline

Die CI/CD-Pipeline für Anwendungen ermöglicht das automatisierte Erstellen und Bereitstellen containerbasierter Anwendungen. Die Pipeline besteht aus Schritten für Continuous Integration (CI) und Continuous Deployment (CD). Die Pipeline-Architektur basiert auf dem Blueprint für sichere CI/CD.

Die CI/CD-Pipeline der Anwendung verwendet in Ihren Umgebungen unveränderliche Container-Images. Unveränderliche Container-Images sorgen dafür, dass dasselbe Image in allen Umgebungen bereitgestellt wird und während der Ausführung des Containers nicht geändert wird. 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 Anwendungsquellcode-Repository enthält Kubernetes-Konfigurationen. Diese Konfigurationen ermöglichen es, dass Anwendungen als Kubernetes-Dienste in GKE ausgeführt werden können. In der folgenden Tabelle werden die Arten von Kubernetes-Konfigurationen beschrieben, die von der CI/CD-Pipeline der Anwendung angewendet werden.

Komponente	Beschreibung
Deployment	Definiert eine skalierte Gruppe von Pods (Containern).
Dienst	Macht ein Deployment über das Clusternetzwerk erreichbar.
Virtueller Dienst	Macht einen Dienst zum Teil des Service Mesh.
Zielregel	Definiert, wie Peers im Service Mesh einen virtuellen Dienst erreichen sollen. Wird im Blueprint verwendet, um das Load-Balancing für den Ost-West-Traffic zu konfigurieren.
Autorisierungsrichtlinie	Legt die Zugriffssteuerung zwischen Arbeitslasten im Service Mesh fest.
Kubernetes-Dienstkonto	Definiert eine Identität, die von einem Kubernetes-Dienst verwendet wird. Die Workload Identity-Föderation für GKE definiert das Google Cloud Dienstkonto, das für den Zugriff aufGoogle Cloud -Ressourcen verwendet wird.
Gateway	Lässt externen eingehenden Traffic zu einem Dienst zu. Das Gateway ist nur für Bereitstellungen erforderlich, die externen Traffic empfangen.
GCPBackendPolicy	Konfigurieren Sie SSL, Cloud Armor, die Sitzungsaffinität und die Verbindungsunterbrechung für Bereitstellungen, die externen Traffic empfangen. GCPBackendPolicy wird nur für Bereitstellungen verwendet, die externen Traffic empfangen.
PodMonitoring	Konfiguriert die Erfassung von Prometheus-Messwerten, die von einer Anwendung exportiert werden.

Continuous Integration

Das folgende Diagramm zeigt den Prozess von Continuous Integration.

So läuft der Prozess ab:

1. Ein Entwickler übergibt Anwendungscode an das Anwendungsquellcode-Repository. Dieser Vorgang löst Cloud Build aus, um mit der Integrations-Pipeline zu beginnen.
2. Cloud Build erstellt ein Container-Image, überträgt das Container-Image per Push an Artifact Registry und erstellt einen Image-Digest.
3. Cloud Build führt automatisierte Tests für die Anwendung aus. Je nach Sprache der Anwendung werden möglicherweise unterschiedliche Testpakete ausgeführt.
4. Cloud Build führt die folgenden Scans für das Container-Image aus:
   1. Cloud Build analysiert den Container mit dem Containerstrukturtest-Framework. Dieses Framework führt Befehlstests, Dateiexistenztests, Dateiinhaltstests und Metadatentests aus.
   2. Cloud Build verwendet das Scannen auf Sicherheitslücken, um Sicherheitslücken im Container-Image anhand einer Datenbank zu erkennen, die von Google Cloudverwaltet wird.
5. Cloud Build genehmigt das Image für die Fortsetzung in der Pipeline, nachdem die Scanergebnisse erfolgreich waren.
6. Binärautorisierung signiert das Image. Die Binärautorisierung ist ein Dienst auf 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.
7. Cloud Build erstellt einen Release in Cloud Deploy, um den Bereitstellungsprozess zu starten.

Wenn Sie die Sicherheitsinformationen für einen Build aufrufen möchten, rufen Sie das Panel „Sicherheitsinformationen“ auf. Diese Statistiken umfassen Sicherheitslücken, die mit der Artefaktanalyse erkannt wurden, und das Sicherheitsniveau des Builds, das durch SLSA-Richtlinien angegeben wird.

Kontinuierliche Bereitstellung

Das folgende Diagramm zeigt den Prozess von Continuous Deployment.

So läuft der Prozess ab:

1. Am Ende des Build-Prozesses erstellt die CI/CD-Pipeline der Anwendung einen neuen Cloud Deploy-Release, um die neu erstellten Container-Images schrittweise in jeder Umgebung bereitzustellen.
2. Cloud Deploy initiiert ein Roll-out in der ersten Umgebung der Bereitstellungspipeline, in der Regel die Entwicklungsumgebung. Für jede Bereitstellungsphase ist eine manuelle Genehmigung erforderlich.
3. Die Cloud Deploy-Pipelines verwenden die sequenzielle Bereitstellung, um Images in der richtigen Reihenfolge in jedem Cluster in einer Umgebung bereitzustellen.
4. 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 Anwendungsfactory und die CI/CD-Pipeline der Anwendung zusammenarbeiten, um eine neue Anwendung zu erstellen und bereitzustellen.

So definieren Sie eine neue Anwendung:

1. Ein Anwendungsoperator definiert eine neue Anwendung in seinem Mandanten, indem er einen Cloud Build-Trigger ausführt, um die Anwendungsdefinition zu generieren.
2. Der Trigger fügt einen neuen Eintrag für die Anwendung in Terraform hinzu und übernimmt die Änderung im Anwendungs-Factory-Repository.
3. Die übernommene Änderung löst die Erstellung anwendungsspezifischer Repositories und Projekte aus.
4. Cloud Build führt die folgenden Schritte aus:
   1. Erstellt zwei neue Git-Repositories zum Hosten des Quellcodes und der IaC der Anwendung.
   2. Pusht die Kubernetes-Manifeste für Netzwerkrichtlinien und die Identitätsföderation von Arbeitslasten für GKE in das Repository für die Konfigurationsverwaltung.
   3. Erstellt das CI/CD-Projekt der Anwendung und den Cloud Build-IaC-Trigger.
5. 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.
6. Config Sync stellt die Netzwerkrichtlinien und die Konfigurationen für die Identitätsföderation von Arbeitslasten für GKE in den mehrmandantenfähigen GKE-Clustern bereit.
7. Mit der Pipeline zum Erstellen des Flottenbereichs werden der Flottenbereich und der Namespace für die Anwendung in mehrmandantenfähigen GKE-Clustern erstellt.
8. Die CI/CD-Pipeline der Anwendung führt die erste Bereitstellung der Anwendung in den GKE-Clustern durch.
9. Optional kann das Anwendungsteam den Cloud Build-IaC-Trigger verwenden, um Projekte und zusätzliche Ressourcen (z. B. Datenbanken und andere verwaltete Dienste) in dedizierten Projekten mit einem einzelnen Mandanten bereitzustellen, eines für jede Umgebung.

GKE Enterprise-Konfigurations- und ‑Richtlinienverwaltung

Im Blueprint verwenden Administratoren der Entwicklerplattform Config Sync, um Konfigurationen auf Clusterebene in jeder Umgebung 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 alle Abweichungen ab, indem es Aktualisierungen anwendet, um die Einhaltung des ausgewählten Status trotz manueller Änderungen zu gewährleisten. 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 Policy Controller-Einschränkungen an. Diese Konfigurationen definieren Sicherheits- und Compliancekontrollen, die von Administratoren der Entwicklerplattform für die Organisation festgelegt werden. Für diesen Blueprint sind andere Pipelines erforderlich, um andere Konfigurationen anzuwenden: Die CI/CD-Pipelines für Anwendungen wenden anwendungsspezifische Konfigurationen an und die Pipeline für den Flottenbereich erstellt Namespaces und zugehörige Rollenbindungen.

Nächste Schritte

• Anwendungsarchitektur der Cymbal Bank (nächstes Dokument in dieser Reihe)