Moderne CI/CD mit Anthos: CI/CD-System aufbauen

---

Diese Referenzarchitektur bietet Ihnen eine Methode und anfängliche Infrastruktur, um ein modernes CI/CD-System (Continuous Integration/Continuous Delivery) mithilfe von Tools wie Anthos, Skaffold, kustomize, Artifact Registry und GitLab zu erstellen.

Dieses Dokument ist Teil der folgenden Reihe:

• Moderne CI/CD mit Anthos: Ein Softwarebereitstellungs-Framework
• Moderne CI/CD mit Anthos: CI/CD-System erstellen (dieses Dokument)
• Moderne CI/CD mit Anthos: Entwickler-Workflow anwenden

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.

CI/CD-Workflow

Wenn Sie ein modernes CI/CD-System aufbauen möchten, müssen Sie zuerst Tools und Dienste auswählen, die die Hauptfunktionen des Systems ausführen. Diese Referenzarchitektur konzentriert sich auf die Implementierung der Kernfunktionen eines CI/CD-Systems, die im folgenden Diagramm dargestellt sind:

In dieser Referenzimplementierung werden für jede Komponente die folgenden Tools verwendet:

• Für die Quellcodeverwaltung: GitLab
  • Speichert den Anwendungs- und Konfigurationscode.
  • Hier können Sie Änderungen prüfen.
• Für die Anwendungskonfiguration: kustomize
  • Definiert die gewünschte Konfiguration einer Anwendung.
  • Ermöglicht es Ihnen, Konfigurations Primitive oder Blueprints wiederzuverwenden und zu erweitern.
• Für Continuous Integration: GitLab
  • Testet und validiert den Quellcode.
  • Erstellt Artefakte, die in der Bereitstellungsumgebung verbraucht werden.
• Für Continuous Delivery: GitLab
  • Definiert den Rollout-Prozess des Codes in allen Umgebungen.
  • Bietet einfache Rollbacks für fehlgeschlagene Änderungen.
• Für die Infrastrukturkonfiguration und Richtlinien-Engine: Anthos Config Management
  • Stellt einen Mechanismus bereit, mit dem Sie anhand der Richtlinien der Organisation definieren können, was in einer bestimmten Umgebung ausgeführt werden darf.
• Für die Containerorchestrierung: Anthos-Cluster
  • Führt die in CI erstellten Artefakte aus.
  • Bietet Skalierungs-, Systemdiagnose- und Rollout-Methoden für Arbeitslasten.
• Für Container Registry: Artifact Registry
  • Speichert die Artefakte (Container-Images), die während der CI erstellt wurden.

Architektur

In diesem Abschnitt werden die CI/CD-Komponenten beschrieben, die Sie mithilfe dieser Referenzarchitektur implementieren: Infrastruktur, Code-Repositories und Anwendungs-Landing-Zones.

Allgemeine Informationen zu diesen Aspekten des CI/CD-Systems finden Sie unter Moderne CI/CD mit Anthos: Ein Softwarebereitstellungs-Framework.

Plattforminfrastruktur

Die Infrastruktur für diese Referenzarchitektur besteht aus Kubernetes-Clustern zur Unterstützung der Entwicklung, gemeinsam genutzter Tools und Anwendungsumgebungen. Das folgende Diagramm zeigt das logische Layout der Cluster:

Code-Repositories

Mit dieser Referenzarchitektur richten Sie einzelne Repositories für Operatoren, Entwickler und Sicherheitsentwickler ein.

Das folgende Diagramm zeigt die Implementierung der Referenzarchitektur der verschiedenen Code-Repositories und die Interaktion der Betriebs-, Entwicklungs- und Sicherheitsteams mit den Repositories:

In diesem Workflow können Ihre Operatoren Best Practices für CI/CD und die Anwendungskonfiguration im Operator-Repository verwalten. Wenn Ihre Entwickler Anwendungen im Entwicklungs-Repository einrichten können, erhalten sie automatisch Best Practices, Geschäftslogik für die Anwendung und alle speziellen Konfigurationen, die für den ordnungsgemäßen Betrieb ihrer Anwendung erforderlich sind. Das Betriebs- und Sicherheitsteam kann die Konsistenz und Sicherheit der Plattform in den Konfigurations- und Richtlinien-Repositories verwalten.

Anwendungs-Landing-Zones

Das folgende Diagramm zeigt die wichtigsten Komponenten der in dieser Referenzarchitektur verwendeten Landing-Zones:

Jeder Namespace enthält ein Dienstkonto, mit dem das CI/CD-System Kubernetes-Ressourcen wie Pods und Dienste bereitstellt. Damit Sie dem Prinzip der geringsten Berechtigung folgen können, sollten Sie dem Dienstkonto nur Zugriff auf seinen eigenen Namespace gewähren. Sie können den Zugriff auf Dienstkonten in Anthos Config Management definieren und mithilfe der rollenbasierten Zugriffssteuerungsrollen (RBAC) und Rollenbindungen von Kubernetes implementieren. Mit diesem Modell können Teams alle Ressourcen direkt in den von ihnen verwalteten Namespaces bereitstellen, können jedoch keine Ressourcen aus anderen Namespaces überschreiben oder löschen.

Lernziele

• Infrastruktur für die Referenzarchitektur bereitstellen
• Infrastruktur entdecken
• Code-Repositories und -Pipelines entdecken
• Beispiel für einen Anwendungs-Landing-Zone ansehen

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• Google Kubernetes Engine (GKE)
• Cloud SQL
• Memorystore
• Artifact Registry

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweis

1. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   Zur Projektauswahl

2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist

3. Aktivieren Sie Cloud Shell in der Google Cloud Console.

   Cloud Shell aktivieren

Referenzarchitektur bereitstellen

1. Klonen Sie in Cloud Shell das Git-Repository:

   git clone https://github.com/GoogleCloudPlatform/solutions-modern-cicd-anthos.git
   cd solutions-modern-cicd-anthos
   

2. Legen Sie die Umgebungsvariablen für dieses Projekt fest:

   export PROJECT_ID=PROJECT_ID
   export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format 'value(projectNumber)')
   export REGION="us-central1"
   
   gcloud config set compute/region ${REGION}
   gcloud config set core/project ${PROJECT_ID}
   

   Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.

3. Aktivieren Sie die Cloud Build, Anthos, Service Usage, Cloud Key Management Service (Cloud KMS), Binary Authorization, Secret Manager and Container Analysis APIs:

   gcloud services enable cloudbuild.googleapis.com
   gcloud services enable anthos.googleapis.com
   gcloud services enable serviceusage.googleapis.com
   gcloud services enable cloudkms.googleapis.com
   gcloud services enable binaryauthorization.googleapis.com
   gcloud services enable secretmanager.googleapis.com
   gcloud services enable containeranalysis.googleapis.com
   

4. Aktualisieren Sie die IAM-Rollen und -Berechtigungen (Identity and Access Management) für das Cloud Build-Dienstkonto:

   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
       --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role roles/owner
   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
       --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role roles/containeranalysis.admin
   

5. Führen Sie Cloud Build aus, um die Cluster bereitzustellen:

   gcloud builds submit --substitutions=_PROJECT_ID=${PROJECT_ID}
   

   Dieser Vorgang dauert etwa 30 Minuten. Wenn es abgeschlossen ist, können Sie die Infrastruktur einsehen.

Infrastruktur entdecken

In diesem Abschnitt lernen Sie die Hauptkomponenten des CI/CD-Systems kennen, einschließlich der Infrastruktur, Code-Repositories und einer Beispiel-Landing-Zone.

• Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

  Zur Seite "Kubernetes-Cluster"

  Auf dieser Seite werden die Cluster für die Entwicklung (dev-us-west1), gemeinsame Tools (gitlab ) und Anwendungsumgebungen (staging-us-west2, prod-us-central1, prod-us-east1) aufgelistet:

  

Entwicklungscluster

Der Entwicklungscluster (dev-us-west1) gewährt Entwicklern Zugriff auf einen Namespace, mit dem sie ihre Anwendungen iterieren können. Wir empfehlen Teams, Tools wie Skaffold zu verwenden, die einen iterativen Workflow bieten. Dazu werden der Code in der Entwicklungsphase aktiv überwacht und bei Änderungen wieder auf die Entwicklungsumgebungen angewendet. Diese Iterationsschleife ähnelt dem Hot Reload. Sie ist jedoch nicht so programmiert, dass sie für jede Anwendung entwickelt werden kann, die Sie mit einem Docker-Image erstellen können. Sie können die Schleife in einem Kubernetes-Cluster ausführen.

Im nächsten Dokument der Reihe, Modern CI/CD with Anthos: Wenden Sie den Entwickler-Workflow an, verwenden Sie Skaffold, um die Entwicklungsschleife zu erstellen.

Cluster für freigegebene Tools

Jedes Softwarebereitstellungssystem verwendet eine Mischung aus Tools, um den Lebenszyklus der Softwareentwicklung zu unterstützen. Nach dem Prinzip der geringsten Berechtigung stellt die Referenzimplementierung einen dedizierten Cluster zum Speichern von Tools bereit (gitlab). Es empfiehlt sich, jedes Tool in seinem eigenen Namespace bereitzustellen.

In dieser Referenzimplementierung verwenden Sie GitLab für die Quellcodeverwaltung und für Continuous Integration. Installieren Sie GitLab im Tools-Cluster mithilfe des GitLab on GKE Terraform-Moduls.

Cluster in der Anwendungsumgebung

Die Referenzarchitektur umfasst außerdem Cluster (staging-us-west2, prod-us-central1, prod-us-east1), um Ihre Anwendungen sowohl für die Vorproduktion als auch für die Produktionsbereitstellung auszuführen. Sie sollten Ihre Anwendungen in mindestens einem Cluster in jeder Umgebung bereitstellen. Bei Georedundanz- oder Hochverfügbarkeitssystemen (HA) empfehlen wir, jeder Umgebung mehrere Cluster hinzuzufügen. Für alle Cluster, in denen Anwendungen bereitgestellt werden, empfiehlt es sich, regionale Cluster zu verwenden. Dieser Ansatz schützt Ihre Anwendungen vor Fehlern auf Zonenebene und vor Unterbrechungen, die durch Cluster- oder Knotenpool-Upgrades verursacht werden.

Wir empfehlen die Verwendung von Anthos Config Management, um die Konfiguration von Cluster-Ressourcen wie Namespaces, Kontingenten und RBAC zu synchronisieren. Weitere Informationen zur Verwaltung dieser Ressourcen finden Sie weiter unten in diesem Dokument unter Konfigurations- und Richtlinien-Repositories.

Code-Repositories ansehen

In diesem Abschnitt machen Sie sich mit den Code-Repositories vertraut.

In der GitLab-Instanz anmelden

1. Rufen Sie in Cloud Shell die GitLab-URL ab:

   echo "https://gitlab.endpoints.${PROJECT_ID}.cloud.goog"
   

   Kopieren Sie die URL, da Sie sie in einem späteren Schritt benötigen.

2. Rufen Sie den User und das Password für GitLab ab, die in Secret Manager gespeichert sind:

   export GITLAB_USER=$(gcloud secrets versions access latest --secret="gitlab-user")
   export GITLAB_PASSWORD=$(gcloud secrets versions access latest --secret="gitlab-password")
   
   echo "User: ${GITLAB_USER}"
   echo "Password: ${GITLAB_PASSWORD}"
   

   Kopieren Sie diese Anmeldedaten, da Sie sie in einem späteren Schritt benötigen.

3. Rufen Sie in einem Webbrowser die GitLab-URL auf, die Sie zuvor kopiert haben.

4. Melden Sie sich mit den kopierten Anmeldedaten User und Password bei der GitLab-Instanz an.

   Die Seite Projekte für Ihre GitLab-Instanz wird angezeigt.

Operator-, Starter- und Konfigurations-Repositories entdecken

In den Operator-, Start- und Konfigurations-Repositories definieren Operatoren und Plattformadministratoren die gängigsten Best Practices für das Erstellen und Betreiben der Plattform. Diese Repositories befinden sich alle in der Gruppe „platform-admins“.

1. Klicken Sie in der GitLab-Instanz auf Gruppen und wählen Sie dann Meine Gruppen aus.

2. Klicken Sie auf platform-admins.

   Es wird eine Liste der Repositories angezeigt:

   

Operator-Repositories

Die Referenzarchitektur umfasst die Repositories shared-kustomize-bases und shared-ci-cd operator.

• Das Repository shared-kustomize-bases enthält die grundlegenden Kubernetes-Manifeste für die Anwendungen, die in Kubernetes auf der Plattform ausgeführt werden. Operatoren können die Manifeste nach Bedarf aktualisieren. Diese werden automatisch erfasst, ohne dass Anwendungsteams einzelne Anwendungskonfigurationen aktualisieren.
• Das Repository shared-ci-cd speichert die Best Practices für die Ausführung von CI- und CD-Schritten auf der Plattform. Ähnlich wie die Anwendungskonfigurationen können Operatoren aktualisiert und Phasen zu den Best Practices hinzugefügt werden. Einzelne Anwendungspipelines werden automatisch aktualisiert.

In dieser Referenzimplementierung verwenden Operatoren kustomize, um Basiskonfigurationen im Repository shared-kustomize-bases zu verwalten. Anschließend können Entwickler die Manifeste mit anwendungsspezifischen Änderungen (z. B. Ressourcennamen und Konfigurationsdateien) in ihrem Anwendungs-Repository erweitern. Das kustomize-Tool unterstützt die Konfiguration als Daten. Bei dieser Methode sind kustomize-Eingaben und -Ausgaben Kubernetes-Ressourcen. Sie können die Ausgaben einer Modifikation der Manifeste für eine andere Modifikation verwenden.

Das folgende Diagramm veranschaulicht eine Basiskonfiguration für eine Spring Boot-Anwendung:

Die Konfiguration als Datenmodell in kustomize bietet einen großen Vorteil: Wenn Operatoren die Basiskonfiguration aktualisieren, werden die Aktualisierungen automatisch von der Bereitstellungspipeline des Entwicklers bei der nächsten Ausführung übernommen. Entwickler müssen dabei keine Änderungen vornehmen.

Weitere Informationen zur Verwendung von kustomize für die Verwaltung von Kubernetes-Manifesten finden Sie in der Dokumentation zu kustomize.

Starter-Repositories

In den Starter-Repositories können Ihre Operatoren Best Practices wie CI, Messwerterfassung, Logging und Sicherheit für Anwendungen kodieren und dokumentieren. Die Referenz umfasst Beispiele für Start-Repositories für Go- und Java-Anwendungen.

Die Start-Repositories golang-template und java-template enthalten Boilerplate-Code, mit dem Sie neue Anwendungen erstellen können. Die Repositories golang-template-env und java-template-env enthalten die Basiskonfiguration für CD. Entwickler und Operatoren verwenden diese Start-Repositories beim Erstellen neuer Anwendungen.

Im nächsten Dokument der Reihe Moderne CI/CD mit Anthos: Entwickler-Workflow anwenden verwenden Sie die Repositories golang-template und golang-template-env, um eine neue Anwendung zu erstellen.

Konfigurations- und Richtlinien-Repositories

Die Referenz umfasst eine Implementierung eines Konfigurations- und Richtlinien-Repositorys mithilfe von Anthos Config Management. Das anthos-config-management-Repository enthält die Konfiguration und die Richtlinien, die Sie in den Clustern der Anwendungsumgebung bereitstellen. Die von Plattformadministratoren in diesen Repositories definierte und gespeicherte Konfiguration ist wichtig, damit die Plattform ein konsistentes Erscheinungsbild für die Betriebs- und Entwicklungsteams hat.

In den folgenden Abschnitten wird ausführlicher erläutert, wie Konfigurations- und Richtlinien-Repositories in der Referenzarchitektur implementiert werden.

Konfiguration

In dieser Referenzimplementierung verwenden Sie Anthos Config Management, um die Konfiguration von Clustern auf der Plattform zentral zu verwalten und Richtlinien durchzusetzen. Mit der zentralisierten Verwaltung können Sie Konfigurationsänderungen im gesamten System verteilen.

Mit Anthos Config Management kann Ihre Organisation ihre Cluster registrieren, um ihre Konfiguration aus einem Git-Repository zu synchronisieren. Dieser Vorgang wird als GitOps bezeichnet. Wenn Sie neue Cluster hinzufügen, werden die Cluster automatisch mit der neuesten Konfiguration synchronisiert und der Status des Clusters wird regelmäßig mit der Konfiguration abgeglichen, falls jemand Änderungen außerhalb des Bandes einführt.

Weitere Informationen zu Anthos Config Management finden Sie in der entsprechenden Dokumentation.

Richtlinie

In dieser Referenzimplementierung nutzt Anthos Config Management den Richtlinien-Controller, der auf Open Policy Agent basiert, um jede Anfrage an die Kubernetes-Cluster auf der Plattform zu erfassen und zu validieren. Sie können Richtlinien mithilfe der Rego-Richtliniensprache erstellen, mit der Sie nicht nur die Ressourcentypen, die an den Cluster gesendet werden, sondern auch deren Konfiguration steuern können.

Die Architektur im folgenden Diagramm zeigt einen Anfragefluss zur Erstellung einer Ressource mithilfe von Policy Controller:

Sie erstellen und definieren Regeln im Anthos Config Management-Repository. Diese Änderungen werden auf den Cluster angewendet. Anschließend werden neue Ressourcenanfragen von der Befehlszeile oder von API-Clients anhand der Einschränkungen des Policy Controllers validiert.

Weitere Informationen zum Verwalten von Richtlinien mit Anthos Config Management finden Sie unter Policy Controller – Übersicht.

Anwendungs-Repositories entdecken

1. Klicken Sie in der GitLab-Instanz auf Gruppen und wählen Sie dann Meine Gruppen aus.

2. Klicken Sie auf Petabank.

   Die Anwendungskonfigurations- und Anwendungscode-Repositories für die Petabank-Anwendung werden angezeigt:

   

In dieser Referenzarchitektur hat jede Anwendung zwei Repositories: ein Code-Repository und ein Konfigurations-Repository.

Das Anwendungscode-Repository enthält Folgendes:

• Quellcode der Anwendung
• Ein Dockerfile, das das Erstellen und Ausführen der Anwendung beschreibt
• Die CI/CD-Pipelinedefinition, die von Operatoren erstellte gemeinsam verwendete Aufgaben verwendet
• kustomize-Patches für jede Anwendungsumgebung

Das Anwendungskonfigurations-Repository enthält die vollständig gerenderten Kubernetes-Manifeste, die Sie zur Bereitstellung der Anwendung benötigen. Dieses Repository enthält einen Zweig für jede Umgebung, in der die Anwendung bereitgestellt wird.

Anwendungs-Landingpages entdecken

Die Infrastruktur für Referenzarchitekturen enthält auch Beispiele für Anwendungs-Landing-Zones. In diesem Abschnitt machen Sie sich mit einer Beispie-Landing-Zone vertraut. Weitere Informationen zu Landing-Zones finden Sie unter Moderne CI/CD mit Anthos: Ein Softwarebereitstellungs-Framework.

1. Rufen Sie in der Google Cloud Console die Seite GKE-Arbeitslasten auf.

   Zur Seite „Arbeitslasten“

2. Wählen Sie im Drop-down-Menü Cluster die Option staging-us-west2 aus.

3. Wählen Sie im Drop-down-Menü Namespace die Option Petabank aus.

   Für die Petabank-Anwendung wird eine Liste mit Kubernetes-Ressourcen angezeigt:

   

4. Klicken Sie zum Aufrufen der Kubernetes-Dienstressource für die Petabank-Anwendung auf Dienste und Ingress.

Der Namespace enthält die Ressourcen für die Petabank-Anwendung, einen GitLab-Runner für die CI/CD-Aufgaben und ein Kubernetes-Deployment und einen Kubernetes-Dienst für die Petabank-Anwendung. Nach dem Prinzip der geringsten Berechtigung werden RBAC- und Netzwerkrichtlinien im anthos-config-management-Repository definiert, das in GitLab gespeichert wird. Sie können die Konfiguration und die Richtlinien mit Anthos Config Management anwenden.

Referenzarchitektur anwenden

Nachdem Sie sich mit der Referenzarchitektur vertraut gemacht haben, können Sie sich einen Entwickler-Workflow ansehen, der auf dieser Implementierung basiert. Im nächsten Dokument dieser Reihe, Moderne CI/CD mit Anthos, wenden Sie den Entwickler-Workflow an, erstellen Sie eine neue Anwendung, fügen ein Feature hinzu und stellen die Anwendung dann in den Staging- und Produktionsumgebungen bereit.

Bereinigen

Wenn Sie sich das nächste Dokument dieser Reihe, Moderne CI/CD mit Anthos: Entwickler-Workflow anwenden anwenden möchten, löschen Sie weder das Projekt noch die Ressourcen, die dieser Referenzarchitektur zugeordnet sind. Um zu vermeiden, dass Ihrem Google Cloud-Konto die in der Referenzarchitektur verwendeten Ressourcen in Rechnung gestellt werden, können Sie das Projekt andernfalls löschen oder die Ressourcen manuell entfernen.

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:
• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für diese Anleitung ein bereits bestehendes Projekt verwendet haben, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.
1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Ressourcen manuell entfernen

• Entfernen Sie in Cloud Shell die Infrastruktur:

  gcloud builds submit --substitutions=_PROJECT_ID=${PROJECT_ID} --config cloudbuild-destroy.yaml
  gcloud endpoints services delete gitlab.endpoints.${PROJECT_ID}.cloud.goog
  gcloud endpoints services delete registry.endpoints.${PROJECT_ID}.cloud.goog
  

Nächste Schritte

• Neue Anwendung durch Ausführen der Schritte unter Moderne CI/CD mit Anthos: Entwickler-Workflow anwenden erstellen
• Best Practices zum Einrichten der Identity-Föderation
• Richtlinienverwaltung mit Anthos Config Management und GitLab
• Weitere Informationen zu Kubernetes und den Herausforderungen der kontinuierlichen Softwarebereitstellung
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center