Konfigurationen validieren

In dieser Anleitung wird gezeigt, wie Sie Konfigurationen mit Cloud Build validieren, wenn Sie GKE Enterprise-Cluster verwenden. Die gleiche Einrichtung funktioniert mit minimalen Änderungen auch mit jedem anderen containerbasierten CI/CD-System, z. B. CircleCI.

Wir empfehlen, alle Konfigurationsänderungen in Ihrer CI-/CD-Pipeline zu validieren und die Gültigkeit Ihrer Konfigurationen mit dem Befehl nomos vet zu prüfen.

Ziele

• Erstellen Sie eine Cloud Build-Konfigurationsdatei, in der Config Sync angewiesen wird, nomos vet für die Konfigurationen in Ihrem Repository zu verwenden.
• Erstellen Sie einen Cloud Build-Trigger, damit Ihre Konfigurationen immer dann geprüft werden, wenn es eine Änderung am Entwicklungszweig gibt.

Kosten

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

• Config Sync (part of GKE Enterprise)
• Cloud Build

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Cloud Build API.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Cloud Build API.

Enable the API

1. Sie müssen einen GKE Enterprise-Cluster erstellen oder Zugriff auf einen haben, der den Anforderungen für Config Sync entspricht. Weitere Informationen zum Erstellen eines solchen Clusters finden Sie unter Erste Schritte mit Config Sync.

Berechtigung für Cloud Build-Dienstkonto erteilen

Gewähren Sie die Berechtigung für das Cloud Build-Dienstkonto für GKE Enterprise-Cluster-Zugriff.

gcloud

Führen Sie den folgenden Befehl aus, um dem Cloud Build-Dienstkonto die Rolle Kubernetes Engine Developer hinzuzufügen:

PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUM=$(gcloud projects list --filter="$PROJECT_ID" --format="value(PROJECT_NUMBER)")
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

Console

1. Öffnen Sie die Seite „IAM“ in der Google Cloud Console.

   Zur IAM-Seite

2. Suchen Sie in der Spalte Mitglied nach der Zeile mit dem Cloud Build-Dienstkonto:

   PROJECT_NUMBER@cloudbuild.gserviceaccount.com
   

3. Klicken Sie in dieser Zeile auf edit Hauptkonto bearbeiten.

4. Klicken Sie auf Weitere Rolle hinzufügen.

5. Wählen Sie in der Liste Rolle auswählen die Option Kubernetes Engine Developer aus und klicken Sie dann auf Speichern.

Cloud Build-Konfiguration erstellen

Erstellen Sie eine Cloud Build-Konfigurationsdatei und speichern Sie diese im Stammverzeichnis des Repositorys, das Ihre Konfigurationsdateien enthält (z. B. my-repo/cloudbuild.yaml):

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/config-management-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

Ersetzen Sie Folgendes:

• ZONE: Die Zone, in der Ihr Cluster ausgeführt wird
• CLUSTER_NAME: der Name Ihres Clusters
• POLICY_DIR: Der Pfad im Git-Repository, der die oberste Ebene des zu synchronisierenden Repositorys darstellt

Diese Konfiguration umfasst drei Schritte:

1. Führen Sie kubectl config current-context aus, um die Datei "kubeconfig" zu generieren, die für die Authentifizierung beim GKE-Cluster my-cluster erforderlich ist. Der Root-Nutzer erstellt diese Datei mit eingeschränkten Berechtigungen.
2. Führen Sie im nächsten Schritt chmod 444 /kube/config aus, um diese Datei lesbar zu machen.
3. Führen Sie nomos vet in dem Git-Repository aus, das automatisch in das Verzeichnis /workspace geklont wird. Wenn Sie ein unstrukturiertes Repository verwenden, führen Sie stattdessen nomos vet --source-format=unstructured aus.

Build-Trigger erstellen

Im folgenden Beispiel wird ein Trigger erstellt, der für jeden Commit für den Master-Branch eines Cloud Source Repositories-Repositorys ausgeführt wird.

1. Öffnen Sie die Seite „Trigger“ in der Google Cloud Console.

   Zur Seite "Trigger"

2. Klicken Sie auf Repository verbinden.

3. Wählen Sie GitHub (gespiegelt) aus und klicken Sie auf Weiter.

4. Wählen Sie Ihr Repository aus und klicken Sie auf Repository verbinden.

5. Klicken Sie auf Trigger hinzufügen.

6. Geben Sie für jedes in folgender Tabelle aufgeführte Feld den entsprechenden Eintrag ein oder wählen Sie ihn aus:

   Feld	Eintrag
   Ereignis	Push zu Zweig
   Branch	^master$
   Konfiguration	Cloud Build-Konfigurationsdatei (YAML oder JSON)
   Speicherort der Cloud Build-Konfigurationsdatei	/cloudbuild.yaml

7. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

Build-Trigger testen

Testen Sie die Einrichtung manuell, indem Sie den Trigger ausführen:

1. Öffnen Sie die Seite „Trigger“ in der Google Cloud Console.

   Zur Seite "Trigger"

2. Suchen Sie den Trigger, den Sie erstellt haben, und klicken Sie dann auf Trigger ausführen.

   Die Nachricht "Build auf Master-Branch gestartet" wird angezeigt.

3. Klicken Sie auf ANZEIGEN.

   Die Cloud Build-Schritte werden grün angezeigt, wenn die Einrichtung richtig ablief.

Ungültige Cloud Build-Konfigurationen

Ein Trigger kann nicht ausgeführt werden, wenn die Cloud Build-Konfigurationsdatei ungültig ist.

Aktualisieren Sie zum Testen die Cloud Build-Konfiguration in Ihrem Repository mit der folgenden Datei. Beachten Sie den ungültigen Einzug in Zeile 6:

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
  path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/nomos-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

Wenn Sie den Trigger noch einmal manuell ausführen, erhalten Sie die folgende Fehlermeldung, da path: in Zeile 6 nicht korrekt eingerückt ist:

Failed to trigger build: failed unmarshalling build config cloudbuild.yaml:
unknown field "path" in cloudbuild_go_proto.BuildStep.

Um diese Konfiguration zu korrigieren, rücken Sie path: in Zeile 6 auf dieselbe Ebene wie name: in Zeile 5 ein. Weitere Informationen zur Struktur einer Cloud Build-Konfigurationsdatei finden Sie unter Einfache Build-Konfigurationsdatei erstellen.

Bereinigen

Projekt löschen

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Einzelne Ressourcen löschen

Führen Sie die folgenden Schritte aus, um die einzelnen Ressourcen zu löschen:

1. Löschen Sie die Cloud Build-Konfigurationsdatei.
2. Löschen Sie den Cloud Build-Trigger, den Sie erstellt haben.
3. Löschen Sie den Cluster, den Sie für diese Anleitung verwendet haben.

Nächste Schritte

• Mehr zu Cloud Build
• Synchronisierung von Konfigurationen vorübergehend beenden