Der Blueprint für die Unternehmensanwendung wird über eine Reihe automatisierter Systeme und Pipelines bereitgestellt. Jede Pipeline implementiert einen bestimmten Aspekt des Blueprints. 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 Blueprints für Unternehmensgrundlagen) stellt die Anwendungs-Factory, die mehrmandantenfähige Infrastrukturpipeline und die Pipeline des Flottenbereichs bereit.
- Über die mehrmandantenfähige Infrastrukturpipeline werden die GKE-Cluster und die anderen verwalteten Dienste bereitgestellt, auf die der Blueprint der Unternehmensanwendung angewiesen ist.
- Mit der Pipeline auf Flottenebene werden Flottenbereiche, Namespaces sowie RBAC-Rollen und ‑Bindungen konfiguriert.
- Die Application Factory bietet einen Mechanismus zum Bereitstellen neuer Anwendungspipelines über einen vordefinierten Prozess.
- Die Anwendungs-CI/CD-Pipeline bietet eine CI/CD-Pipeline zum Bereitstellen von Diensten in GKE-Clustern.
- Config Sync implementiert und verwaltet zusätzliche Kubernetes-Konfigurationen, einschließlich Richtliniencontroller-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 | Repository-Änderungsgenehmiger | Pipeline | Beschreibung |
|---|---|---|---|---|
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Grundlageninfrastruktur-Pipeline |
Repository mit dem Code zum Bereitstellen der Pipeline für die mehrmandantenfähige Infrastruktur, der Anwendung und der Pipeline für den Flottenbereich |
|
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, in dem die Teambereiche und Namespaces der Flotte definiert werden |
|
Entwicklerplattformentwickler |
Administrator der Entwicklerplattform |
Application Factory |
Der Code, der das Anwendungs-Repository definiert und auf die Module im |
|
Symbol: Anwendungsentwickler |
Anwendungsoperator |
Application Factory |
Der Basiscode, der beim ersten Erstellen des Repositorys in das |
|
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 Pflege ihrer Konfigurationen verwendet werden |
Mit automatisierten Pipelines können Sie Sicherheit, Prüf- und Rückverfolgbarkeit, Wiederholbarkeit, Kontrollierbarkeit und Compliance in den Bereitstellungsprozess einbinden. 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 |
|---|---|
Erstellt die gemeinsame Infrastruktur, die von allen Nutzern 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
Mit der mehrmandantenfähigen Infrastrukturpipeline werden Flotten, GKE-Cluster und zugehörige freigegebene Ressourcen bereitgestellt. Das folgende Diagramm zeigt die Komponenten der Pipeline für die mehrmandantenfähige Infrastruktur.
In der folgenden Tabelle werden die Komponenten beschrieben, die mit der Multi-Tenant-Infrastrukturpipeline erstellt werden.
| Komponente | Beschreibung |
|---|---|
GKE-Cluster |
Bietet Hosting für die Dienste der containerisierten Anwendung. |
Policy Controller |
Bietet Richtlinien, die für die ordnungsgemäße Konfiguration der GKE-Cluster und ‑Dienste sorgen. |
Config Sync |
Wendet die Policy Controller-Richtlinien auf Cluster an und sorgt für eine konsistente Anwendung der Richtlinien. |
Cloud Key Management Service (Cloud KMS)-Schlüssel |
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. |
Die Richtlinie, die von der Google Cloud Armor-Webanwendungs-Firewall verwendet wird. |
Flottenbereich-Pipeline
Die Pipeline auf Flottenebene ist für die Konfiguration der Namespaces und RBAC-Bindungen in den GKE-Clustern der Flotte verantwortlich. In der folgenden Tabelle sind die Komponenten aufgeführt, die in der Pipeline für die Flottenebene erstellt werden.
| Komponente | Beschreibung |
|---|---|
Definiert die logischen Cluster innerhalb des physischen Clusters. |
|
Definiert die Autorisierung, die ein Kubernetes-Dienstkonto auf Cluster- oder Namespaceebene hat. |
Application Factory
Die Application Factory wird von der Grundlage der Infrastruktur-Pipeline bereitgestellt und verwendet, um die Infrastruktur für jede neue Anwendung zu erstellen. Diese Infrastruktur umfasst ein Google Cloud -Projekt, das die CI/CD-Pipeline der Anwendung enthält.
Wenn die Entwicklungsorganisationen wachsen, kann das Anwendungsteam mithilfe der Application Factory neue Anwendungen 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 mehrmandantenfähigen Architektur unterstützt wird. Das folgende Diagramm zeigt die Anwendungsfabrik.
Die Anwendungsfabrik besteht aus den folgenden Komponenten:
- Application Factory-Repository: Ein Git-Repository, in dem die deklarative Anwendungsdefinition gespeichert wird.
- Pipelines zum Erstellen von Anwendungen: Pipelines, für die Cloud Build für Folgendes erforderlich ist:
- 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. ein Python-, Golang- oder Java-Mikrodienst).
- Gemeinsam genutzte Module:Terraform-Module, die gemäß Standardpraktiken erstellt und für verschiedene Zwecke verwendet werden, einschließlich Anwendungs-Onboarding und -Bereitstellung.
In der folgenden Tabelle sind die Komponenten aufgeführt, die die Anwendungsfabrik für jede Anwendung erstellt.
| Komponente | Beschreibung |
|---|---|
Repository für den Quellcode 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 Verbinden mit dem Quellcode-Repository verwendet wird und eine CI/CD-Pipeline für die Bereitstellung von Anwendungsdiensten bereitstellt. |
Anwendungs-CI-/CD-Pipeline
Die CI/CD-Pipeline der Anwendung ermöglicht den automatisierten Build und die Bereitstellung containerbasierter Anwendungen. Die Pipeline besteht aus den Schritten Continuous Integration (CI) und Continuous Deployment (CD). Die Pipelinearchitektur basiert auf dem Secure CI/CD-Blueprint.
Die CI/CD-Pipeline der Anwendung verwendet in Ihren Umgebungen unveränderliche Container-Images. Unveränderliche Container-Images tragen dazu bei, 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 Repository mit Anwendungsquellcode enthält Kubernetes-Konfigurationen. Mit diesen Konfigurationen können Anwendungen als Kubernetes-Dienste in GKE ausgeführt werden. In der folgenden Tabelle werden die Arten von Kubernetes-Konfigurationen beschrieben, die für die CI/CD-Pipeline der Anwendung gelten.
| Komponente | Beschreibung |
|---|---|
Definiert eine skalierte Gruppe von Pods (Containern). |
|
Ermöglicht die Erreichbarkeit einer Bereitstellung über das Clusternetzwerk. |
|
Ermöglicht es, einen Dienst als Teil des Service Mesh zu verwenden. |
|
Definiert, wie Peers im Service Mesh einen virtuellen Dienst erreichen sollen. Wird im Blueprint verwendet, um das Load Balancing für Ortsbereiche für den East-West-Traffic zu konfigurieren. |
|
Legt die Zugriffssteuerung zwischen Arbeitslasten im Service Mesh fest. |
|
Definiert eine Identität, die von einem Kubernetes-Dienst verwendet wird. Mit der Workload Identity-Föderation für GKE wird das Google Cloud -Dienstkonto definiert, das für den Zugriff aufGoogle 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. |
|
Konfigurieren Sie SSL, Google Cloud Armor, Sitzungsaffinität und Verbindungsausgleich für Bereitstellungen, die externen Traffic erhalten. GCPBackendPolicy wird nur von Bereitstellungen verwendet, die externen Traffic erhalten. |
|
Konfiguriert die Erfassung von Prometheus-Messwerten, die von einer Anwendung exportiert werden. |
Continuous Integration
Das folgende Diagramm zeigt den Prozess von Continuous Integration.
So funktioniert es:
- Ein Entwickler übergibt den Anwendungscode an das Anwendungs-Quellcode-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 an Artifact Registry und erstellt einen Image-Digest.
- Cloud Build führt automatisierte Tests für die Anwendung durch. Je nach Anwendungssprache können unterschiedliche Testpakete ausgeführt werden.
- Cloud Build führt die folgenden Scans für das Container-Image durch:
- Cloud Build analysiert den Container mit dem Containerstruktur-Test-Framework. Dieses Framework führt Befehlstests, Dateiexistenztests, Dateiinhaltstests und Metadatentests aus.
- Cloud Build verwendet das Scannen auf Sicherheitslücken, um Sicherheitslücken im Container-Image anhand einer Datenbank zu erkennen, die von Google Cloudverwaltet wird.
- Cloud Build genehmigt das Image, um nach erfolgreichen Scanergebnissen in der Pipeline fortzufahren.
- Das Image wird von der Binärautorisierung signiert. Die Binärautorisierung ist ein Dienst in Google Cloud , der Software-Lieferkettensicherheit für containerbasierte Anwendungen mithilfe von Richtlinien, Regeln, Hinweisen, Attestierungen, Attestatoren 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 einen Release in Cloud Deploy, um den Bereitstellungsprozess zu starten.
Die Sicherheitsinformationen für einen Build finden Sie im Bereich Sicherheitsinformationen. Zu diesen Informationen gehören Sicherheitslücken, die mithilfe der Artefaktanalyse erkannt wurden, und das Sicherheitsniveau des Builds, das gemäß den SLSA-Richtlinien angegeben ist.
Kontinuierliche Bereitstellung
Das folgende Diagramm zeigt den Prozess der kontinuierlichen Bereitstellung.
So funktionierts:
- Am Ende des Build-Prozesses erstellt die CI/CD-Pipeline der Anwendung einen neuen Cloud Deploy-Release, um die neu erstellten Container-Images nach und nach in jeder Umgebung zu starten.
- Cloud Deploy startet ein Roll-out in der ersten Umgebung der Bereitstellungspipeline, in der Regel der Entwicklungsumgebung. Für jede Bereitstellungsphase ist eine manuelle Genehmigung erforderlich.
- Bei den Cloud Deploy-Pipelines werden Bilder nacheinander in jedem Cluster einer Umgebung bereitgestellt.
- Am Ende jeder Bereitstellungsphase prü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 Anwendungsfabrik und die CI/CD-Pipeline der Anwendung zusammenarbeiten, um eine neue Anwendung zu erstellen und bereitzustellen.
So definieren Sie eine neue Anwendung:
- Ein Anwendungsoperator definiert eine neue Anwendung in seinem Mandanten, indem er einen Cloud Build-Trigger ausführt, um die Anwendungsdefinition zu generieren.
- Der Trigger fügt in Terraform einen neuen Eintrag für die Anwendung hinzu und übernimmt die Änderung in das Repository der Anwendungs-Factory.
- Die übernommene Änderung löst die Erstellung von anwendungsspezifischen Repositories und Projekten aus.
- Cloud Build führt Folgendes aus:
- Erstellt zwei neue Git-Repositories zum Hosten des Quellcodes und der IaC der Anwendung.
- Die Kubernetes-Manifeste für Netzwerkrichtlinien und die Identitätsföderation von Arbeitslasten für GKE werden in das Repository für die Konfigurationsverwaltung gepusht.
- Erstellt das CI/CD-Projekt der Anwendung und den Cloud Build-IaC-Trigger.
- 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 Konfigurationen der Identitätsföderation von Arbeitslasten für GKE in den mehrmandantenfähigen GKE-Clustern bereit.
- Mit der Pipeline zum Erstellen des Flottenbereichs werden der Flottenbereich und der Namespace für die Anwendung in mandantenfähigen GKE-Clustern erstellt.
- Die CI/CD-Pipeline der Anwendung führt die Erstbereitstellung der Anwendung in den GKE-Clustern durch.
- Optional kann das Anwendungsteam den Cloud Build-IaC-Trigger verwenden, um Projekte und zusätzliche Ressourcen (z. B. Datenbanken und andere verwaltete Dienste) in speziellen Mandantenprojekten bereitzustellen, jeweils 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 Zustand der Clusterkonfiguration dient. Config Sync überwacht kontinuierlich den tatsächlichen Status der Konfiguration in den Clustern und gleicht Abweichungen durch Anwenden von Updates aus, um trotz manueller Änderungen den gewünschten Status beizubehalten. 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 Compliance-Kontrollen, die von den Administratoren der Entwicklerplattform für die Organisation festgelegt wurden. Dieser Blueprint verwendet andere Pipelines, um andere Konfigurationen anzuwenden: Die CI/CD-Pipelines der Anwendung wenden eine anwendungsspezifische Konfiguration an und die Pipeline auf Flottenebene erstellt Namespaces und zugehörige Rollenbindungen.
Nächste Schritte
- Weitere Informationen zur Anwendungsarchitektur von Cymbal Bank (nächstes Dokument in dieser Reihe)