Diese Seite wurde von der Cloud Translation API übersetzt.

Workflows mit Cloud Build aus einem Git-Repository bereitstellen

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

So können Sie den Bereitstellungslebenszyklus besser verwalten. Sie können beispielsweise Änderungen an einem Workflow in einer Staging-Umgebung bereitstellen, Tests für diese Umgebung ausführen und die Änderungen dann schrittweise in der Produktionsumgebung einführen.

Hinweise

Bei 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 und Workflows APIs.

Aktivieren Sie die APIs
Weisen Sie dem Cloud Build-Dienstkonto die Rolle „Workflows-Administrator“ (roles/workflows.admin) zu:
1. Rufen Sie in der Google Cloud Console die Seite IAM auf.
  
  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 Admin 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, ist das Compute Engine-Standarddienstkonto PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Achtung :Wenn Sie die Rolle „Dienstkontonutzer“ zuweisen, wird dem Nutzer indirekt die Rolle gewährt, die dem Standarddienstkonto zugeordnet ist. Wenn das Standarddienstkonto beispielsweise die Rolle „Bearbeiter“ hat, kann der Nutzer als „Bearbeiter“ agieren. Um die Auswirkungen dieser Rollenzuweisungen zu minimieren, empfehlen wir, das Standarddienstkonto gemäß dem Grundsatz der geringsten Berechtigung zu konfigurieren. Weitere Informationen finden Sie unter Standarddienstberechtigungen 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. Wenn Sie ein neues Hauptkonto hinzufügen möchten, geben Sie die E-Mail-Adresse Ihres Dienstkontos ein (SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com).
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 und Workflows APIs.

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 Projekts. Google Cloud

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, ist das Compute Engine-Standarddienstkonto PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Achtung :Wenn Sie die Rolle „Dienstkontonutzer“ zuweisen, wird dem Nutzer indirekt die Rolle gewährt, die dem Standarddienstkonto zugeordnet ist. Wenn das Standarddienstkonto beispielsweise die Rolle „Bearbeiter“ hat, kann der Nutzer als „Bearbeiter“ agieren. Um die Auswirkungen dieser Rollenzuweisungen zu minimieren, empfehlen wir, das Standarddienstkonto gemäß dem Grundsatz der geringsten Berechtigung zu konfigurieren. Weitere Informationen finden Sie unter Standarddienstberechtigungen 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
```

Mit dem Quell-Repository verbinden

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 Seite Cloud Build-Trigger auf:

Zur Seite "Triggers" (Triggers)
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 verwendet, um Ihren Build auszuführen. Andernfalls wird ein privater Pool in der Region Ihres Triggers verwendet. Sie müssen den privaten Pool in Ihrer Build-Konfigurationsdatei oder über Build-Argumente angeben.
Klicken Sie auf Repository verbinden.
Wählen Sie das Quell-Repository aus, in dem Sie den Quellcode gespeichert haben.

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

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

Bei externen Repositories wie GitHub und Bitbucket benötigen Sie für das Google Cloud -Projekt, an dem Sie arbeiten, Berechtigungen auf Inhaberebene.
Lesen Sie den Haftungsausschluss und klicken Sie anschließend das Kästchen daneben an, um die Nutzungsbedingungen zu akzeptieren.
Klicken Sie auf Verbinden.
Klicken Sie auf Trigger erstellen, um weiterhin einen Build-Trigger zu erstellen, mit dem Builds für den Quellcode im Repository automatisiert werden. Klicken Sie andernfalls auf Fertig.

Cloud Build-Konfigurationsdatei erstellen

Eine Build-Konfigurationsdatei definiert die Felder, die erforderlich sind, wenn Sie einen Build mit einem Build-Trigger starten. Erstellen Sie die Konfigurationsdatei im Stammverzeichnis Ihres Projekts und schreiben Sie sie entweder in YAML oder JSON.

Mit der folgenden Konfigurationsdatei wird beispielsweise ein Test-Workflow bereitgestellt und ausgeführt. Anschließend wird mit einem Skript die Ausgabe geprüft. Wenn der Test erfolgreich ist, 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 $BRANCH_NAME- und $SHORT_SHA-Ersetzungsvariablen werden von Cloud Build ersetzt, wenn ein Build über ein 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 Substitutionsvariablen $_WORKFLOW_NAME können Sie eine Konfigurationsdatei mit verschiedenen Variablenwerten wiederverwenden. Sie können den 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 einen Build-Trigger für die Konfigurationsdatei im vorherigen Abschnitt:

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

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

Beispiel: Per Push-Befehl an Zweig übertragen
Wählen Sie unter Quelle Ihr Repository und den Branch- oder Tag-Namen aus, der den Trigger auslöst. Sie können einen regulären Ausdruck verwenden, um eine Übereinstimmung für einen Branch oder ein Tag anzugeben.

Beispiel: GoogleCloudPlatform/workflows-demos (Repository) und ^main$|^staging$ (entspricht den Branches main und staging)
Maximieren Sie den Bereich Filter für enthaltene und ignorierte Dateien anzeigen und geben Sie Ihren Workflow als enthaltene Datei an, damit bei Änderungen daran ein Build ausgelöst wird.

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

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

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

Wenn Änderungen per Push-Befehl an einen Workflow im angegebenen Zweig des Git-Repository übertragen werden, wird Cloud Build automatisch ausgelöst, um den Workflow bereitzustellen.

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 staging-Branch des Git-Repositorys die Datei 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 an den staging-Zweig.
```
git add workflow.yaml
git commit -m "Update workflow.yaml in staging"
git push
```
Der Cloud Build-Trigger wird ausgeführt und startet einen Build.
Rufen Sie in der Google Cloud Console die Seite Build-Verlauf auf, um zu prüfen, ob der Build erfolgreich war:

Zur Seite „Build-Verlauf“

Sobald ein Build abgeschlossen ist, stellt Cloud Build einen allgemeinen Status für den Build und für jeden einzelnen Build-Schritt bereit. Weitere Informationen finden Sie unter Build-Ergebnisse ansehen.
So prüfen Sie, ob ein Staging-Workflow bereitgestellt wurde: Rufen Sie in der Google Cloud -Konsole die Seite Workflows auf:

Zur Seite "Workflows"

Es sollte ein Workflow mit dem Namen workflows-gitops-staging angezeigt werden.

Wenn Sie den Staging-Workflow in der Produktionsumgebung bereitstellen möchten, führen Sie den Zweig staging mit dem Zweig main zusammen:

git checkout main
git merge staging
git push

Da test-main.sh Hello World in der Ausgabe des Workflows 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

Damit Sie einen Produktionsworkflow erfolgreich bereitstellen können, bearbeiten Sie im staging-Zweig noch einmal workflow.yaml und ändern Sie den String wieder in Hello World.
Führen Sie ein Commit der Änderung für den staging-Zweig durch und übertragen Sie die Änderung per Push an den staging-Zweig. Führen Sie dann den staging-Zweig mit dem main-Zweig zusammen.
So prüfen Sie, ob ein Produktionsworkflow bereitgestellt wurde: Rufen Sie in der Google Cloud -Konsole die Seite Workflows auf:

Zur Seite "Workflows"

Es sollte ein Workflow mit dem Namen workflows-gitops-main angezeigt werden.

Nächste Schritte

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