Konfigurationen validieren

In dieser Anleitung wird gezeigt, wie Sie Konfigurationen bei Verwendung von Google Kubernetes Engine (GKE) Enterprise Edition-Clustern mit Cloud Build validieren. 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.

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 einer Änderung am Entwicklungszweig überprüft werden.

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

Console

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

   Zur IAM-Seite

2. Suchen Sie in der Spalte Mitglied 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 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 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 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 mit dem Trigger:

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

Um dies zu testen, aktualisieren Sie 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

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

Um die einzelnen Ressourcen zu löschen, führen Sie die folgenden Schritte aus:

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