Konfigurationen validieren

In dieser Anleitung erfahren Sie, wie Sie Konfigurationen mit Cloud Build validieren, wenn Sie Google Kubernetes Engine-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, die Config Sync anweist, 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 Cloud de Confiance by S3NS:

• Config Sync
• Cloud Build

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.

Hinweis

1. In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

   Go to project selector

2. Verify that billing is enabled for your Cloud de Confiance project.

3. Enable the Cloud Build API.

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the API

4. Sie müssen einen GKE-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

Erteilen Sie dem Cloud Build-Dienstkonto die Berechtigung für den Zugriff auf Ihren GKE-Cluster.

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.s3ns-system.iam.gserviceaccount.com \
    --role=roles/container.developer

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 Cloud de Confiance 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 Cloud de Confiance 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

So löschen Sie ein Cloud de Confiance Projekt:

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