Konfigurationen validieren

In dieser Anleitung wird beschrieben, wie Sie bei Verwendung von Clustern der GKE Enterprise-Version (Google Kubernetes Engine) Konfigurationen mit Cloud Build validieren. Die gleiche Einrichtung funktioniert mit minimalen Änderungen auch mit jedem anderen containerbasierten CI/CD-System, z. B. CircleCI.

Wir empfehlen, zusätzlich zur Gültigkeit der Konfigurationen alle Konfigurationsänderungen in der CI/CD-Pipeline mit dem Befehl nomos vet zu validieren.

Lernziele

• Erstellen Sie eine Cloud Build-Konfigurationsdatei, die Config Sync anweist, nomos vet für die Konfigurationen in Ihrem Repository zu verwenden.
• Erstellen Sie einen Cloud Build-Trigger, damit Ihre Konfigurationen bei jeder Änderung am Entwicklungszweig geprüft werden.

Kosten

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

• Config Sync (Teil von GKE Enterprise)
• Cloud Build

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

1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

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

3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

4. Cloud Build API aktivieren.

   Aktivieren Sie die API

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

6. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

7. Cloud Build API aktivieren.

   Aktivieren Sie die API

8. Erstellen Sie einen GKE Enterprise-Cluster, der die Anforderungen für Config Sync erfüllt, oder haben Sie Zugriff darauf. Weitere Informationen zum Erstellen eines solchen Clusters finden Sie unter Erste Schritte mit Config Sync.

Berechtigung für Cloud Build-Dienstkonto gewähren

Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung für den Zugriff auf Ihren GKE Enterprise-Cluster.

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:$[e-mail] \
    --role=roles/container.developer

Console

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

   Zur Seite „IAM“

2. In der Spalte Mitglied finden Sie die Zeile mit dem Cloud Build-Dienstkonto:

   [e-mail]
   

3. Klicken Sie in dieser Zeile auf 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 sie 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 innerhalb des Git-Repositorys, 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 /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 im Master-Branch eines Cloud Source Repositories-Repositorys ausgeführt wird.

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

   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 dann 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
   Zweig	^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 in der Google Cloud Console die Seite „Trigger“.

   Zur Seite „Trigger“

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

   Die Meldung „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 die Cloud Build-Konfiguration in Ihrem Repository mit der folgenden Datei, um dies zu testen. 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 Grundlegende Cloud Build-Konfiguration erstellen.

Bereinigen

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, 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 Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Google Cloud-Projekt löschen:

gcloud projects delete PROJECT_ID

Einzelne Ressourcen löschen

So löschen Sie die einzelnen Ressourcen:

1. Löschen Sie die Cloud Build-Konfigurationsdatei.
2. Löschen Sie den von Ihnen erstellten Cloud Build-Trigger.
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