Config Sync in mehreren Umgebungen mit Cloud Build verwenden

In dieser Anleitung erfahren Sie, wie Sie Config Sync für Google Kubernetes Engine (GKE) in zwei Umgebungen einrichten, einer für die Entwicklung und einer für die Produktion, indem Sie die Best Practices für Anthos Config Management verwenden.

In diesem Szenario sind Sie Teil eines Plattformadministratorteams bei Foo Corp. Die Foo Corp-Anwendungen werden in GKE bereitgestellt, wobei die Ressourcen auf zwei Projekte verteilt sind: dev und prod. Das Projekt dev enthält einen GKE-Entwicklungscluster und das Projekt prod enthält den GKE-Produktionscluster. Ihr Ziel als Plattformadministrator besteht darin sicherzustellen, dass beide Umgebungen den Richtlinien von Foo Corp entsprechen und dass Ressourcen auf der Basisebene, wie Kubernetes-Namespaces und -Dienstkonten, in beiden Umgebungen konsistent bleiben.

Das folgende Diagramm bietet eine Übersicht über die Umgebungen, die Sie in dieser Anleitung einrichten:

Eine Übersicht über die Umgebungen, die Sie in dieser Anleitung einrichten

Wie im vorherigen Diagramm dargestellt, erstellen Sie in dieser Anleitung die folgenden Ressourcen:

Zwei Google Cloud-Projekte, die die Entwicklungs- und Produktionsumgebungen darstellen.
Zwei GKE-Cluster, dev und prod, in den separaten Projekten.
Drei GitHub-Repositories, foo-config-source, foo-config-dev und foo-config-prod. Dies sind unstrukturierte Config Sync-Repositories, die YAML-Konfigurationen für Foo Corp enthalten.
Config Sync, das auf beiden Clustern installiert ist. Der Cluster dev wird mit dem Repository foo-config-dev synchronisiert, der Cluster prod mit dem Repository foo-config-prod.
Secret Manager-Secrets mit Ihrem Git-Nutzernamen und einem Entwicklertoken. Cloud Build verwendet diese Secrets, um Commits an die GitHub-Repositories durchzuführen.
Eine Cloud Build-Pipeline, die per Push in das Repository foo-config-source übertragen wird. Diese Pipeline verwendet kustomize build, um benutzerdefinierte foo-config-dev- und foo-config-prod-Repositories mit YAML-Konfigurationen zu rendern. Dabei werden die "Basis" und die "Overlays" in foo-config-source verwendet. Diese Kustomize-Overlays wurden im Ordner config-source/ bereitgestellt.

Ziele

Bereiten Sie Ihre Umgebung vor. Führen Sie dazu Skripts aus, um die mit Config Sync verwendeten Cluster und Repositories zu erstellen und zu konfigurieren.
Erstellen Sie mit Kustomize einen Cloud Build-Trigger, um die Konfiguration für zwei verschiedene Umgebungen automatisch zu rendern.
Richten Sie Config Sync ein, um die gerenderte Konfiguration für die beiden separaten Umgebungen zu synchronisieren.

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

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

Bevor Sie mit dieser Anleitung beginnen, müssen Sie die folgenden Schritte ausgeführt haben:

Wählen Sie in der Google Cloud Console auf der Seite zur Projektauswahl zwei Google Cloud-Projekte aus.

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 ihm verknüpften Ressourcen entfernen.

Zur Projektauswahl
Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist.
Ein GitHub-Konto erstellen oder Zugriff darauf haben.
Erstellen Sie in GitHub ein persönliches Zugriffstoken mit den Bereichen repo und delete_repo. Kopieren Sie den Wert des Tokens in die Zwischenablage. Sie benötigen ihn für zukünftige Schritte.

Umgebung vorbereiten

Führen Sie die folgenden Schritte aus, um Ihre Umgebung für diese Anleitung vorzubereiten:

Öffnen Sie Cloud Shell:
1. Öffnen Sie die Google Cloud Console.
  
  Google Cloud Console
2. Klicken Sie in der oberen rechten Ecke der Console auf die Schaltfläche Cloud Shell aktivieren:
Die Tools nomos und kubectl, die Sie für diese Anleitung benötigen, sind in Cloud Shell vorinstalliert.

Klonen Sie das Anthos Config Management-Beispiel-Repository:

git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git

Öffnen Sie den Ordner mit den Ressourcen, die Sie für diese Anleitung benötigen:
```
cd anthos-config-management-samples/multi-environments-kustomize/
```
Legen Sie die folgenden Variablen fest, um die in dieser Anleitung verwendeten Skripts auszuführen:
```
export DEV_PROJECT="DEV_PROJECT_ID"
export PROD_PROJECT="PROD_PROJECT_ID"
export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE"
export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE"
export GITHUB_USERNAME="GITHUB_USERNAME"
export GITHUB_TOKEN="GITHUB_TOKEN"
export GITHUB_EMAIL="GITHUB_EMAIL"
export CM_CONFIG_DIR="cloud-build-rendering"
```
Dabei gilt:
- DEV_PROJECT_ID: die Projekt-ID des Google Cloud-Projekts, das Sie als Entwicklungsprojekt verwenden möchten
- PROD_PROJECT_ID: die Projekt-ID des Google Cloud-Projekts, das Sie als Produktionsprojekt verwenden möchten
- DEV_CLUSTER_ZONE: die Compute Engine-Zone, in der Sie Ihren Entwicklungscluster erstellen möchten. Beispiel: us-central1-c
- PROD_CLUSTER_ZONE: die Compute Engine-Zone, in der Sie den Produktionscluster erstellen möchten
- GITHUB_USERNAME: Ihr GitHub-Nutzername
- GITHUB_TOKEN: das persönliche Zugriffstoken, das Sie im Abschnitt Hinweis erstellt haben.
- GITHUB_EMAIL: Ihre GitHub-E-Mail-Adresse

Konfigurieren Sie Ihre lokale Git-Umgebung so, dass sie Ihren GitHub-Nutzernamen und Ihre E-Mail-Adresse verwendet:

git config --global user.name $GITHUB_USERNAME
git config --global user.email $GITHUB_EMAIL
git config --global credential.helper store
git config --global credential.helper cache

Ressourcen erstellen

Damit Sie sich auf den Workflow konzentrieren können, den Sie beim Konfigurieren von Config Sync für mehrere Umgebungen verwenden müssen, enthält das Verzeichnis multi-environments-kustomize Skripts, die Sie verwenden können, um die Konfiguration von Config Sync zu automatisieren.

Cluster erstellen und registrieren

Führen Sie das Skript ./create-clusters.sh aus, um zwei Cluster zu erstellen:
```
./create-clusters.sh
```
Dieses Skript erstellt einen GKE-Cluster mit dem Namen dev im Entwicklungsprojekt und einen GKE-Cluster mit dem Namen prod im Produktionsprojekt. Dieses Skript aktiviert auch die GKE API und die Anthos API und stellt eine Verbindung zu Ihren Clustern dev und prod her, sodass Sie mit kubectl auf deren APIs zugreifen können.

Beispielausgabe:
```
kubeconfig entry generated for dev.
Fetching cluster endpoint and auth data.
kubeconfig entry generated for prod.
⭐️ Done creating clusters.
```
Führen Sie das Skript register-clusters.sh aus, um Ihre Cluster in zwei separaten Anthos-Flotten zu registrieren:
```
./register-clusters.sh
```
Dieses Skript erstellt ein Google Cloud-Dienstkonto und einen Schlüssel für die Anthos-Clusterregistrierung und registriert dann mit dem Befehl gcloud container hub memberships register die Cluster dev und prod bei Anthos in ihren eigenen Projekten.

Beispielausgabe:
```
Waiting for Feature Config Management to be created...done.
⭐️ Done registering clusters.
```

GitHub-Repositories erstellen

Führen Sie das Skript create-repos.sh aus, um drei GitHub-Repositories zu erstellen:
```
./create-repos.sh
```
Hinweis: Wenn Sie während der Ausführung des Skripts zur Eingabe Ihrer Git-Anmeldedaten aufgefordert werden, verwenden Sie GITHUB_TOKEN als Passwort, nicht Ihr GitHub-Passwort.

Dieses Skript erstellt drei GitHub-Repositories: foo-config-source, foo-config-dev und foo-config-prod. Nutzer übergeben die Konfiguration per Commit an das Quell-Repository und eine in wenigen Schritten erstellte CI-Pipeline rendert Konfigurationen in den anderen beiden Repositories und verwendet dabei für dev und prod spezifische Werte. Von dort aus wird der Cluster dev mit foo-config-dev und der Cluster prod mit foo-config-prod synchronisiert.

Beispielausgabe:
```
# Output omitted
😸 Creating foo-config-prod repo...
{
  "id": 364312792,
  "node_id": "MDEwOlJlcG9zaXRvcnkzNjQzMTI3OTI=",
  "name": "foo-config-prod",
 ...
}
Cloning into 'foo-config-prod'...
warning: You appear to have cloned an empty repository.
[main (root-commit) b681a3d] Initialize
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 211 bytes | 211.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/askmeegs/foo-config-prod.git
* [new branch]      main -> main
```

Secrets erstellen

Um Secret Manager-Secrets im Produktionsprojekt mit Ihren Git-Anmeldedaten zu erstellen, führen Sie das Skript secret-manager-git.sh aus:

./secret-manager-git.sh

Wenn Sie Ihre Secrets auf diese Weise erstellen, kann Cloud Build in Ihrem Namen eine Nachricht per Push an GitHub senden. Die Cloud Build-Pipeline, die Sie als Nächstes einrichten, ruft Ihre GitHub-Authentifizierungsinformationen direkt von Secret Manager ab.

Erwartete Ausgabe:

🔐 Creating secret manager secrets in prod project...
Created secret [github-username].
Created version [1] of the secret [github-username].
Created secret [github-email].
Created version [1] of the secret [github-email].
Created secret [github-token].
Created version [1] of the secret [github-token].
✅ Granting Cloud Build secret manager access...
Project number is: ########
Updated IAM policy for project [project-id].
# Output omitted

Cloud Build-Trigger erstellen

Nachdem Sie Ihre Umgebung konfiguriert haben, können Sie Ihre Cloud Build-Pipeline entdecken.

Führen Sie den folgenden Befehl aus, um die Cloud Build-Pipeline aufzurufen:

cat foo-config-source/cloudbuild.yaml

Diese Pipeline verwendet Kustomize, um Manifeste für die Entwicklungs- und Produktions-Repositories mithilfe der Manifeste im Verzeichnis base/ zu rendern.

Erwartete Ausgabe:

steps:
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-dev
  entrypoint: 'bash'
  args:
  - '-eEuo'
  - 'pipefail'
  - '-c'
  - |-
    git clone https://github.com/$$GITHUB_USERNAME/foo-config-dev && \
    cd foo-config-dev
    git config user.email $$GITHUB_EMAIL
    git config user.name $$GITHUB_USERNAME
    git remote set-url origin https://$$GITHUB_USERNAME:$$GITHUB_TOKEN@github.com/$$GITHUB_USERNAME/foo-config-dev.git
    cd ..

    kustomize build overlays/dev --output foo-config-dev/
    cd foo-config-dev

    rm README.md
    echo "Update: ${SHORT_SHA}" > README.md

    git add . && \
    git commit -m "Rendered: ${SHORT_SHA}
    Built from commit ${COMMIT_SHA} of repository foo-config-source - main branch
    Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
    git push origin main
  secretEnv: ['GITHUB_EMAIL', 'GITHUB_USERNAME', 'GITHUB_TOKEN']
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-prod
...

Wenn Sie Ihr foo-config-source/-Repository in GitHub aufrufen, können Sie die base/-Manifeste und die von dieser Pipeline verwendeten Kustomize-Overlays dev/ und prod/ sehen.

Jedes Verzeichnis in diesem Repository enthält eine kustomization.yaml-Datei, in der die Dateien aufgeführt sind, die Kustomize verwalten und auf den Cluster anwenden soll. In dev/kustomization.yaml und prod/kustomization.yaml ist eine Reihe von Patches definiert. Mit diesen Patches werden die base/-Ressourcen für diese Umgebung bearbeitet.

Beispiel: Das RoleBinding im Repository foo-config-dev ermöglicht allen Foo Corp-Entwicklern, Pods im Entwicklungscluster bereitzustellen, während das RoleBinding im Repository foo- config-prod nur den Continuous Deployment-Agent deploy-bot@foo-corp.com zulässt, um Pods in der Produktion bereitzustellen:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
    kind: ServiceAccount
    name: foo-ksa
  patch: |-
    - op: replace
      path: /metadata/name
      value: foo-ksa-dev
    - op: replace
      path: /metadata/namespace
      value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
    kind: RoleBinding
    name: pod-creators
  patch: |-
    - op: replace
      path: /subjects/0/name
      value: developers-all@foo-corp.com
commonLabels:
  environment: dev

Trigger erstellen

In diesem Abschnitt erstellen Sie einen Cloud Build-Trigger, der automatisch einen Build startet, wenn Sie Änderungen am Quellcode vornehmen:

Rufen Sie in der Google Cloud Console mithilfe des Produktionsprojekts die Cloud Build-Seite "Trigger" auf:

Zur Seite "Trigger"
Klicken Sie auf Repositories verbinden.
Führen Sie im Fenster "Repositories verbinden" folgende Schritte aus:
1. Lassen Sie im Feld Quelle auswählen GitHub ausgewählt und klicken Sie auf Weiter.
2. Achten Sie darauf, dass im Feld GitHub-Konto der zuvor definierte GITHUB_USERNAME ausgewählt ist.
3. Wählen Sie in der Drop-down-Liste Repository das Repository foo-config-source aus und klicken Sie auf OK.
4. Klicken Sie das Kästchen an, um den Nutzungsbedingungen zuzustimmen.
5. Klicken Sie auf Verbinden.
Wenn Ihr Repository verbunden ist, klicken Sie auf Trigger erstellen.
Füllen Sie auf der Seite Trigger erstellen die folgenden Felder aus:
1. Fügen Sie im Feld Name Folgendes hinzu: Foo-Config-Render.
2. Konfigurieren Sie die Felder Beschreibung und Tags nach Bedarf. Sie sind für diese Anleitung nicht erforderlich.
3. Lassen Sie im Feld Ereignis die Option Push zu Zweig ausgewählt.
4. Wählen Sie in der Drop-down-Liste Repository die Option foo-config-source aus.
5. Behalten Sie für das Feld Zweig den Wert ^main$ bei.
6. Lassen Sie im Feld Typ die Option Automatisch ermittelt ausgewählt.
7. Lassen Sie im Feld Speicherort den Wert Repository ausgewählt.
8. Klicken Sie auf Erstellen. Sie werden dann zur Übersichtsseite "Trigger" zurückgeleitet.

Trigger ausführen

Da Sie vor dem Erstellen dieses Triggers bereits per Push in das Repository foo-config-source übertragen haben, können Sie ihn manuell ausführen, um das Rendering der Entwicklungs- und Produktions-Repositories auszulösen:

Klicken Sie in der Triggerliste in der Zeile Foo-Config-Render auf Ausführen. Das Fenster Trigger ausführen wird angezeigt.
Prüfen Sie im Fenster Trigger ausführen, ob das Zweigfeld main ist, und klicken Sie dann auf Trigger ausführen.
Die Meldung Build startete am main-Branch wird angezeigt. Klicken Sie in dieser Meldung auf Anzeigen, um die Seite Build-Details aufzurufen.

Der Build sollte erfolgreich ausgeführt werden und die Ausgabe von Kustomize in die foo-config-dev- bzw. foo-config-prod-Repositories schreiben.
Öffnen Sie nach Abschluss des Builds eines Ihrer Entwicklungs- oder Produktions-Repositories in GitHub. Sie sollten YAML-Dateien sehen, die das Repository füllen, und eine README-Datei, die den Commit-SHA des Repositorys foo-config-source angibt, aus dem dieses Repository zuletzt erstellt wurde.

Config Sync einrichten

Nachdem Sie den Repositories Konfigurationen hinzugefügt haben, können Sie Config Sync installieren und die Installation prüfen.

Config Sync installieren

Führen Sie das Skript install-config-sync.sh aus, um Config Sync im Entwicklungs- und im Produktionscluster zu installieren:

./install-config-sync.sh

Erwartete Ausgabe:

😺 Populating configmangement.yaml with your GitHub repo info...
🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.

Config Sync wird jetzt mit den Konfigurationen in Ihren Repositories synchronisiert.

Konfiguration prüfen

In diesem Abschnitt prüfen Sie, ob Ihre Cluster mit den Konfigurationen in Ihrem Repository synchronisiert werden:

Zum Prüfen des Status Ihrer Config Sync-Installation führen Sie den Befehl nomos status aus:

nomos status

Sowohl die Entwicklungs- als auch die Produktionscluster sollten nun mit den entsprechenden Repositories synchronisiert werden:

gke_DEV_PROJECT_ID_us-central1-c_dev
  --------------------
  <root>   https:/github.com/GITHUB_USERNAME/foo-config-dev@main
  SYNCED   8f2e196f
  Managed resources:
     NAMESPACE   NAME                                                 STATUS
                 clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                 namespace/default                                    Current
                 namespace/foo                                        Current
     default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
     foo         serviceaccount/foo-ksa-dev                           Current

*gke_PROD_PROJECT_ID_us-central1-c_prod
   --------------------
   <root>   https:/github.com/GITHUB_USERNAME/foo-config-prod@main
   SYNCED   c91502ee
   Managed resources:
      NAMESPACE   NAME                                                 STATUS
                  clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                  namespace/default                                    Current
                  namespace/foo                                        Current
      default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
      foo         serviceaccount/foo-ksa-prod                          Current

  ```

Verwenden Sie kubectl, um zum Entwicklungscluster zu wechseln:

kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"

Rufen Sie Namespaces ab, um zu prüfen, ob die Ressourcen synchronisiert wurden. Der Namespace foo sollte angezeigt werden und aus dem foo-config-dev-Repository synchronisiert worden sein.

kubectl get namespace

Beispielausgabe:

NAME                           STATUS   AGE
config-management-monitoring   Active   9m38s
config-management-system       Active   9m38s
default                        Active   47h
foo                            Active   9m5s
kube-node-lease                Active   47h
kube-public                    Active   47h
kube-system                    Active   47h
resource-group-system          Active   9m30s

Sie haben jetzt automatisiertes Rendering von Konfigurationen für eine Entwicklungs- und Produktumgebung in mehreren Google Cloud-Projekten und -Umgebungen eingerichtet.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Alle Ressourcen löschen

Wenn Sie die Ressourcen löschen möchten, die Sie in dieser Anleitung erstellt haben, aber auch die Entwicklungs- und Produktionsprojekte beibehalten möchten, führen Sie das Bereinigungsskript aus:

./cleanup.sh

Projekte 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.

Wenn Sie mehrere Anleitungen und Schnellstarts durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, wenn Sie Projekte wiederverwenden.

Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.
Zur Seite „Ressourcen verwalten“
Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte

Sichere Rollouts mit Anthos Config Management
Anwendungen anhand von Unternehmensrichtlinien in einer CI-Pipeline validieren
Best Practices für die Richtlinienverwaltung mit Anthos Config Management und GitLab
Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center