Workflow aus einem Git-Repository mit Cloud Build bereitstellen

Sie können einen Cloud Build-Trigger verwenden, um automatisch einen Build zu starten und einen Workflow aus einem Git-Repository bereitzustellen. Sie können den Trigger so konfigurieren, dass Ihr Workflow bei jeder Änderung am Quell-Repository bereitgestellt wird, oder den Workflow nur bereitstellen, wenn die Änderung bestimmten Kriterien entspricht.

Dieser Ansatz kann Ihnen bei der Verwaltung des Bereitstellungslebenszyklus helfen. Sie können beispielsweise Änderungen an einem Workflow in einer Staging-Umgebung bereitstellen, Tests für diese Umgebung ausführen und diese Änderungen dann schrittweise in der Produktionsumgebung einführen.

Hinweise

In dieser Anleitung wird davon ausgegangen, dass Sie die Rolle „Cloud-Build-Bearbeiter“ (roles/cloudbuild.builds.editor) in Ihrem Google Cloud-Projekt haben, damit Sie Trigger erstellen können. Außerdem benötigen Sie einen Workflow in einem Quell-Repository wie GitHub oder Bitbucket.

Console

Aktivieren Sie die Cloud Build API und die Workflows API.

Aktivieren Sie die APIs
Weisen Sie dem Cloud Build-Dienstkonto die Rolle „Workflows-Administrator“ (roles/workflows.admin) zu:
1. Öffnen Sie in der Google Cloud Console die Seite IAM.
  
  IAM aufrufen
2. Wählen Sie Ihr Projekt aus.
3. Klicken Sie in der Zeile für das Cloud Build-Dienstkonto (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) auf Hauptkonto bearbeiten.
4. Klicken Sie auf Weitere Rolle hinzufügen.
5. Wählen Sie in der Liste Rolle die Rolle Workflows-Administrator aus.
6. Klicken Sie auf Speichern.
Weisen Sie dem Cloud Build-Dienstkonto die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) für das Compute Engine-Standarddienstkonto zu. Wenn Sie die Compute Engine API aktiviert haben, lautet das Compute Engine-Standarddienstkonto PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Achtung: Wenn Sie die Rolle Dienstkontonutzer zuweisen, wird dem Nutzer indirekt die Rolle zugewiesen, die mit dem Standarddienstkonto verknüpft ist. Wenn das Standarddienstkonto beispielsweise die Rolle „Bearbeiter“ hat, kann der Nutzer dann als Bearbeiter „fungieren“. Wir empfehlen, das Standarddienstkonto nach dem Prinzip der geringsten Berechtigung zu konfigurieren, um die Auswirkungen dieser Rollenzuweisungen zu minimieren. Weitere Informationen finden Sie unter Automatische Rollenzuweisungen für Standarddienstkonten deaktivieren.
1. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.
  
  Zur Seite „Dienstkonten“
2. Wählen Sie Ihr Projekt aus.
3. Klicken Sie auf die E-Mail-Adresse des Compute Engine-Standarddienstkontos (PROJECT_NUMBER-compute@developer.gserviceaccount.com).
4. Klicken Sie auf den Tab Berechtigungen.
5. Klicken Sie auf die Schaltfläche Zugriff gewähren.
6. Geben Sie die E-Mail-Adresse Ihres Dienstkontos ein (SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com), um ein neues Hauptkonto hinzuzufügen.
7. Wählen Sie in der Liste Rolle auswählen die Rolle Dienstkonten > Dienstkontonutzer aus.
8. Klicken Sie auf Speichern.

gcloud

Aktivieren Sie die Cloud Build API und die Workflows API.

gcloud services enable cloudbuild.googleapis.com \
  workflows.googleapis.com

Weisen Sie dem Cloud Build-Dienstkonto die Rolle „Workflows-Administrator“ (roles/workflows.admin) zu:

PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/workflows.admin

Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

Weisen Sie dem Cloud Build-Dienstkonto die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) für das Compute Engine-Standarddienstkonto zu. Wenn Sie die Compute Engine API aktiviert haben, lautet das Compute Engine-Standarddienstkonto PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Achtung: Wenn Sie die Rolle Dienstkontonutzer zuweisen, wird dem Nutzer indirekt die Rolle zugewiesen, die mit dem Standarddienstkonto verknüpft ist. Wenn das Standarddienstkonto beispielsweise die Rolle „Bearbeiter“ hat, kann der Nutzer dann als Bearbeiter „fungieren“. Wir empfehlen, das Standarddienstkonto nach dem Prinzip der geringsten Berechtigung zu konfigurieren, um die Auswirkungen dieser Rollenzuweisungen zu minimieren. Weitere Informationen finden Sie unter Automatische Rollenzuweisungen für Standarddienstkonten deaktivieren.
```
gcloud iam service-accounts add-iam-policy-binding \
  $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/iam.serviceAccountUser
```

Verbindung zum Quell-Repository herstellen

Sie müssen Cloud Build mit Ihrem Quell-Repository verbinden, damit Cloud Build Builds als Reaktion auf Ereignisse im Repository automatisieren kann.

Gehen Sie so vor, um eine Verbindung zu GitHub oder Bitbucket herzustellen:

Rufen Sie in der Google Cloud Console die Cloud Build-Seite Trigger auf:

Zur Seite „Trigger“
Wählen Sie bei Bedarf Ihr Projekt aus und klicken Sie auf Öffnen.
Wählen Sie in der Liste Region die Region aus, in der Sie den Trigger erstellen möchten.

Hinweis: Wenn Sie global als Region auswählen, werden Standardpools zum Ausführen des Builds verwendet. Andernfalls wird ein privater Pool in der Region Ihres Triggers verwendet. Sie müssen den privaten Pool in der Build-Konfigurationsdatei oder über Build-Argumente angeben.
Klicken Sie auf Repository verbinden.
Wählen Sie das Quell-Repository aus, in dem Sie Ihren Quellcode gespeichert haben.

Beispiel: GitHub (Cloud Build GitHub-Anwendung)
Klicken Sie auf Weiter.
Authentifizieren Sie sich mit Ihrem Nutzernamen und Passwort in Ihrem Quell-Repository.

Wenn Sie sich bei GitHub anmelden, werden Sie aufgefordert, der Google Cloud Build GitHub-Anwendung Zugriff auf Ihr GitHub-Konto zu gewähren, damit Sie fortfahren können.
Wählen Sie aus der Liste der verfügbaren Repositories das gewünschte Repository aus und klicken Sie dann auf OK.

Für externe Repositories wie GitHub und Bitbucket benötigen Sie Berechtigungen auf Inhaberebene für das Google Cloud-Projekt, in dem Sie arbeiten.
Lesen Sie den Haftungsausschluss und klicken Sie daneben auf das Kästchen, um zu bestätigen, dass Sie den Bedingungen zustimmen.
Klicken Sie auf Verbinden.
Klicken Sie auf Trigger erstellen, um mit dem Erstellen eines Build-Triggers zur Automatisierung von Builds für den Quellcode im Repository fortzufahren. Klicken Sie andernfalls auf Fertig.

Cloud Build-Konfigurationsdatei erstellen

In einer Build-Konfigurationsdatei werden die Felder definiert, die erforderlich sind, wenn ein Build-Trigger mit einem Build-Trigger gestartet wird. Erstellen Sie die Konfigurationsdatei im Stammverzeichnis des Projekts und schreiben Sie sie entweder in YAML oder JSON.

Mit der folgenden Konfigurationsdatei wird beispielsweise ein Testworkflow bereitgestellt und ausgeführt. Anschließend wird die Ausgabe mithilfe eines Skripts geprüft. Wenn der Test bestanden wird, wird der Workflow bereitgestellt:

steps:
# Deploy the test workflow with the commit sha
- id: 'deploy-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--source', 'gitops/workflow.yaml']

# Run the test workflow and capture the output
- id: 'run-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['-c', 'gcloud workflows run $_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA > /workspace/testoutput.log']

# Delete the test workflow
- id: 'delete-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'delete', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--quiet']

# Check the test output
- id: 'check-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['gitops/test-$BRANCH_NAME.sh']

# Deploy the workflow
- id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME', '--source', 'gitops/workflow.yaml']

Die Substitutionsvariablen $BRANCH_NAME und $SHORT_SHA werden von Cloud Build ausgefüllt, wenn ein Build aus einem Git-Repository ausgelöst wird. Sie stehen für den Namen Ihres Branch und die ersten sieben Zeichen der Commit-ID, die Ihrem Build zugeordnet ist.

Mit der Substitutionsvariable $_WORKFLOW_NAME können Sie eine Konfigurationsdatei mit anderen Variablenwerten wiederverwenden. Sie können dessen Wert beim Erstellen des Build-Triggers angeben.

Weitere Informationen finden Sie unter Build-Konfigurationsdatei erstellen.

Build-Trigger erstellen

Sie können die Bereitstellung Ihres Workflows automatisieren, indem Sie einen Cloud Build-Trigger erstellen.

So erstellen Sie im vorherigen Abschnitt einen Build-Trigger für die Konfigurationsdatei:

Rufen Sie in der Google Cloud Console die Cloud Build-Seite Trigger auf:

Zur Seite „Trigger“
Klicken Sie auf Trigger erstellen.
Geben Sie im Feld Name einen Namen für den Trigger ein.
Wählen Sie unter Ereignis das Ereignis aus, das den Trigger aufrufen soll.

Beispiel: Push zu Zweig
Wählen Sie für Quelle Ihr Repository und den Zweig- oder Tag-Namen aus, mit dem der Trigger gestartet wird. Sie können einen regulären Ausdruck verwenden, um eine Übereinstimmung mit einem Zweig oder Tag anzugeben.

Beispiel: GoogleCloudPlatform/workflows-demos (Repository) und ^main$|^staging$ (entspricht den Zweigen main und staging)
Maximieren Sie den Abschnitt Filter für enthaltene und ignorierte Dateien anzeigen und geben Sie Ihren Workflow als enthaltene Datei an, sodass bei Änderung ein Build aufgerufen wird.

Beispiel: gitops/workflow.yaml
Wählen Sie unter Konfiguration den Typ Cloud Build-Konfigurationsdatei (YAML oder JSON) und als Speicherort Repository aus.
Geben Sie im Feld Speicherort der Cloud Build-Konfigurationsdatei den Speicherort der Datei an.

Beispiel: gitops/cloudbuild.yaml
Wenn Sie eine Ersatzvariable hinzufügen möchten, klicken Sie optional auf Variable hinzufügen und geben Sie eine Schlüssel/Wert-Kombination an.

Beispiel: _WORKFLOW_NAME (variable) und workflows-gitops (Wert)
Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

Wenn Änderungen an einen Workflow im angegebenen Zweig des Git-Repositorys übertragen werden, wird automatisch Cloud Build zur Bereitstellung des Workflows ausgelöst.

Weitere Informationen finden Sie unter Build-Trigger erstellen und verwalten.

Build-Trigger testen

Sie können den Build-Trigger und die Konfigurationsdatei aus den vorherigen Abschnitten testen.

Bearbeiten Sie im Zweig staging des Git-Repositorys workflow.yaml und ändern Sie Hello World in Bye World:

main:
  steps:
    - init:
        assign:
          - message: "Hello World"
    - returnResult:
        return: ${message}

Führen Sie einen Commit durch und übertragen Sie die Änderung per Push an den Zweig staging.
```
git add workflow.yaml
git commit -m "Update workflow.yaml in staging"
git push
```
Der Cloud Build-Trigger wird ausgeführt und initiiert einen Build.
Wenn Sie den Erfolg des Builds prüfen möchten, rufen Sie in der Google Cloud Console die Seite Build-Verlauf auf:

Zum Build-Verlauf

Wenn ein Build abgeschlossen ist, liefert Cloud Build einen Gesamtstatus für den Build und für jeden einzelnen Build-Schritt. Weitere Informationen finden Sie unter Build-Ergebnisse ansehen.
Wenn Sie prüfen möchten, ob ein Staging-Workflow bereitgestellt wurde, rufen Sie in der Google Cloud Console die Seite Workflows auf:

Zur Seite "Workflows"

Hier sollte ein Workflow mit dem Namen workflows-gitops-staging aufgeführt sein.

Führen Sie den staging-Zweig mit dem main-Zweig zusammen, um den Staging-Workflow für die Produktion bereitzustellen:

git checkout main
git merge staging
git push

Da test-main.sh in der Ausgabe des Workflows Hello World erwartet, schlägt der Build fehl:

RESULT_EXPECTED="result: '\"Hello World\"'"
RESULT_ACTUAL=$(grep "result: " $FILE)
if [[ $RESULT_EXPECTED == $RESULT_ACTUAL ]]; then
  echo "Result test passed"
else
  echo "Result test failed. Expected: $RESULT_EXPECTED Actual: $RESULT_ACTUAL"; exit 1;
fi

Bearbeiten Sie workflow.yaml im Zweig staging noch einmal und ändern Sie den String wieder in Hello World, um einen Produktionsworkflow erfolgreich bereitzustellen.
Führen Sie einen Commit durch und übertragen Sie die Änderung per Push in den Zweig staging. Führen Sie dann den Zweig staging mit dem Zweig main zusammen.
Wenn Sie prüfen möchten, ob ein Produktionsworkflow bereitgestellt wurde, rufen Sie in der Google Cloud Console die Seite Workflows auf:

Zur Seite "Workflows"

Hier sollte ein Workflow mit dem Namen workflows-gitops-main aufgeführt sein.

Nächste Schritte

Weitere Informationen zu Cloud Build
Build-Fehler beheben
Informationen zur Fehlerbehebung bei Workflows