Best Practices für Workflows

Mit Workflows können Sie Dienste inGoogle Cloudkoordinieren und automatisieren. Durch die Anwendung empfohlener Architekturpraktiken können Sie die Zuverlässigkeit verbessern, die Ausführungskosten optimieren und robuste, wartbare Orchestrierungen erstellen.

Dies ist keine vollständige Liste von Empfehlungen und vermittelt nicht die Grundlagen der Verwendung von Workflows. In diesem Dokument wird davon ausgegangen, dass Sie bereits ein allgemeines Verständnis der gesamten Google Cloud -Landschaft und von Workflows haben. Weitere Informationen finden Sie im Google Cloud Well-Architected Framework und in der Übersicht über Workflows.

Optimales Kommunikationsmuster auswählen

Wenn Sie eine Mikrodienstarchitektur für die Bereitstellung mehrerer Dienste entwerfen, können Sie aus den folgenden Kommunikationsmustern auswählen:

  • Direkte Dienst-zu-Dienst-Kommunikation

  • Indirekte ereignisgesteuerte Kommunikation (auch als Choreografie bezeichnet)

  • Automatisierte Konfiguration, Koordination und Verwaltung (auch als Orchestrierung bezeichnet)

Berücksichtigen Sie die Vor- und Nachteile der einzelnen Optionen und wählen Sie ein optimales Muster für Ihren Anwendungsfall aus. Beispielsweise ist die direkte Kommunikation zwischen Diensten möglicherweise einfacher zu implementieren als andere Optionen, aber sie koppelt Ihre Dienste eng. Im Gegensatz dazu können Sie mit einer ereignisgesteuerten Architektur Ihre Dienste lose koppeln. Monitoring und Fehlerbehebung können jedoch komplizierter sein. Ein zentraler Orchestrator wie Workflows ist zwar weniger flexibel, ermöglicht Ihnen aber, die Kommunikation zwischen Diensten zu koordinieren, ohne die enge Kopplung der direkten Dienst-zu-Dienst-Kommunikation oder die Komplexität choreografierter Ereignisse.

Sie können auch Kommunikationsmuster kombinieren. Bei der ereignisgesteuerten Orchestrierung werden beispielsweise eng verwandte Dienste in einer Orchestrierung verwaltet, die durch ein Ereignis ausgelöst wird. Ebenso können Sie ein System entwerfen, bei dem eine Orchestrierung zu einer Pub/Sub-Nachricht an ein anderes orchestriertes System führt.

Allgemeine Tipps

Wenn Sie sich für Workflows als Dienstorchestrierung entschieden haben, beachten Sie die folgenden hilfreichen Tipps.

URLs nicht hartcodieren

Sie können Workflows unterstützen, die über mehrere Umgebungen hinweg portierbar und einfacher zu verwalten sind, indem Sie hartcodierte URLs vermeiden. Dazu haben Sie folgende Möglichkeiten:

  • URLs als Laufzeitargumente definieren.

    Das kann hilfreich sein, wenn Ihr Workflow über eine Clientbibliothek oder die API aufgerufen wird. (Dies funktioniert jedoch nicht, wenn Ihr Workflow durch ein Ereignis von Eventarc ausgelöst wird und das einzige Argument, das übergeben werden kann, die Ereignisnutzlast ist.)

    Beispiel

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Wenn Sie den Workflow ausführen, können Sie die URLs angeben. Beispiel:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Verwenden Sie Umgebungsvariablen und erstellen Sie einen Workflow, der je nach Umgebung, in der er bereitgestellt wird, dynamisch konfiguriert wird. Oder Sie erstellen einen Workflow, der als Vorlage wiederverwendet und gemäß separat verwalteten Umgebungsvariablen konfiguriert werden kann.

  • Verwenden Sie eine Ersetzungstechnik, mit der Sie eine einzelne Workflow-Definitionsdatei erstellen, aber Varianten mithilfe eines Tools bereitstellen können, das Platzhalter in Ihrem Workflow ersetzt. Sie können beispielsweise Cloud Build verwenden, um einen Workflow bereitzustellen, und in der Cloud Build-Konfigurationsdatei einen Schritt hinzufügen, um Platzhalter-URLs im Workflow zu ersetzen.

    Beispiel

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Anschließend können Sie Variablenwerte beim Build ersetzen. Beispiel:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Weitere Informationen finden Sie unter Build über die Befehlszeile und die API senden.

    Sie können auch Terraform verwenden, um Ihre Infrastruktur bereitzustellen und eine Konfigurationsdatei zu definieren, die mithilfe von Eingabevariablen Workflows für jede Umgebung erstellt.

    Beispiel

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Wenn Variablen im Stammmodul Ihrer Konfiguration deklariert werden, können ihnen auf verschiedene Weise Werte zugewiesen werden. Beispiel:

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Verwenden Sie den Secret Manager-Connector, um URLs sicher in Secret Manager zu speichern und abzurufen.

Verschachtelte Schritte verwenden

Jeder Workflow muss mindestens einen Schritt haben. Standardmäßig behandelt Workflows Schritte so, als wären sie in einer sortierten Liste, und führt sie nacheinander aus, bis alle Schritte ausgeführt wurden. Logischerweise sollten einige Schritte gruppiert werden. Sie können einen steps-Block verwenden, um eine Reihe von Schritten zu verschachteln. Das ist praktisch, da Sie so auf den richtigen atomaren Schritt verweisen können, um eine Reihe von Schritten zu verarbeiten.

Beispiel

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Ausdrücke umbrechen

Alle Ausdrücke müssen mit einem $ beginnen und in geschweifte Klammern gesetzt werden:

${EXPRESSION}

Um Probleme beim YAML-Parsing zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Beispielsweise können Ausdrücke, die Doppelpunkte enthalten, zu unerwartetem Verhalten führen, wenn der Doppelpunkt als Definition einer Zuordnung interpretiert wird. Sie können dieses Problem beheben, indem Sie den YAML-Ausdruck in einfache Anführungszeichen setzen:

'${"Name: " + myVar}'

Sie können auch Ausdrücke verwenden, die sich über mehrere Zeilen erstrecken. Beispielsweise müssen Sie eine SQL-Abfrage möglicherweise in Anführungszeichen setzen, wenn Sie den Workflows-BigQuery-Connector verwenden.

Beispiel

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Die vollständige Workflowdefinition finden Sie unter Mehrere BigQuery-Jobs parallel ausführen.

Deklarative Aufrufe verwenden

Mit Workflows können Sie Dienste aus dem Workflow selbst aufrufen, die Ergebnisse verarbeiten und einfache Aufgaben wie das Ausführen eines HTTP-Aufrufs ausführen. Workflows können Dienste aufrufen, Antworten parsen und Eingaben für andere verbundene Dienste erstellen. Wenn Sie einen Dienst aufrufen, können Sie die Komplikationen zusätzlicher Aufrufe, zusätzlicher Abhängigkeiten und Dienste, die Dienste aufrufen, vermeiden. Erwägen Sie, Dienste ohne Geschäftslogik durch deklarative API-Aufrufe zu ersetzen und Workflows zu verwenden, um die Komplexität zu abstrahieren.

Sie sollten jedoch Dienste für alle Aufgaben erstellen, die für Workflows zu komplex sind, z. B. die Implementierung wiederverwendbarer Geschäftslogik, komplexer Berechnungen oder Transformationen, die von Workflow-Ausdrücken und der Standardbibliothek nicht unterstützt werden. Ein komplizierter Fall lässt sich in der Regel einfacher im Code implementieren, anstatt YAML oder JSON und die Workflows-Syntax zu verwenden.

Nur das speichern, was Sie benötigen

Behalten Sie den Arbeitsspeicherverbrauch im Blick, damit Sie nicht an Ressourcenlimits stoßen oder einen Fehler erhalten, der darauf hinweist, z. B. ResourceLimitError, MemoryLimitExceededError oder ResultSizeLimitExceededError.

Seien Sie wählerisch bei dem, was Sie in Variablen speichern. Filtern Sie nur nach dem, was Sie benötigen, und speichern Sie nur das. Wenn ein Dienst eine zu große Nutzlast zurückgibt, verwenden Sie eine separate Funktion, um den Aufruf für Sie auszuführen und nur das Erforderliche zurückzugeben.

Sie können Arbeitsspeicher freigeben, indem Sie Variablen löschen. Beispielsweise möchten Sie möglicherweise Arbeitsspeicher freigeben, der für nachfolgende Schritte benötigt wird. Oder Sie haben Aufrufe mit Ergebnissen, die Sie nicht interessieren, und können diese Ergebnisse ganz weglassen.

Sie können eine Variable löschen, indem Sie null zuweisen. In YAML können Sie einer Variablen auch einen leeren Wert oder ~ zuweisen. Dadurch wird Speicher identifiziert, der sicher zurückgefordert werden kann.

Beispiel

  - step:
      assign:
        - bigVar:

Untergeordnete und externe Workflows verwenden

Mit untergeordneten Workflows können Sie einen Logikabschnitt oder eine Reihe von Schritten definieren, die Sie mehrmals aufrufen möchten. Dadurch wird die Workflowdefinition vereinfacht. Subworkflows ähneln einer Funktion oder Routine in einer Programmiersprache. Sie können Parameter akzeptieren und Werte zurückgeben, sodass Sie komplexere Workflows mit einer größeren Bandbreite an Anwendungen erstellen können.

Beachten Sie, dass Subworkflows lokal für Ihre Workflowdefinition sind und nicht in anderen Workflows wiederverwendet werden können. Sie können jedoch Workflows aus anderen Workflows aufrufen. Die Workflows-Connectors können Ihnen dabei helfen. Weitere Informationen finden Sie in den Connector-Übersichten für die Workflow Executions API und die Workflows API.

Workflows-Connectors verwenden

Workflows bietet eine Reihe von Connectors, die den Zugriff auf andere Google Cloud -Produkte innerhalb eines Workflows erleichtern. Connectors vereinfachen den Aufruf von Diensten, da sie die Formatierung von Anfragen für Sie übernehmen und Methoden und Argumente bereitstellen, sodass Sie die Details einerGoogle Cloud -API nicht kennen müssen. Connectors bieten auch ein integriertes Verhalten für die Verarbeitung von Wiederholungen und Vorgängen mit langer Ausführungszeit, sodass Sie nicht iterieren und auf den Abschluss von Aufrufen warten müssen. Connectors übernehmen das für Sie.

Wenn Sie eine Google Cloud API aufrufen müssen, prüfen Sie zuerst, ob ein Workflows-Connector dafür vorhanden ist. Wenn Sie keinen Connector für ein Google Cloud Produkt finden, können Sie einen anfordern.

Informationen zur Verwendung eines Connectors und eine detaillierte Referenz der verfügbaren Connectors finden Sie in der Connector-Referenz.

Workflowschritte parallel ausführen

Workflows können Schritte nacheinander ausführen, aber Sie können auch unabhängige Schritte parallel ausführen. In einigen Fällen kann dies die Ausführung des Workflows erheblich beschleunigen. Weitere Informationen finden Sie unter Workflowschritte parallel ausführen.

Wiederholungsversuche und das Saga-Muster anwenden

Entwerfen Sie robuste Workflows, die sowohl vorübergehende als auch dauerhafte Dienstausfälle bewältigen können. Fehler für Workflows können beispielsweise durch fehlgeschlagene HTTP-Anfragen, Funktionen, Connectors oder durch Ihren eigenen Workflowcode generiert werden. Fügen Sie Fehlerbehandlung und Wiederholungsversuche hinzu, damit ein Fehler in einem Schritt nicht dazu führt, dass der gesamte Workflow fehlschlägt.

  • Mit der Syntax raise können Sie benutzerdefinierte Fehler auslösen.
  • Sie können Fehler mit einem try/except-Block abfangen.
  • Sie können Schritte mit einem try/retry-Block wiederholen und die maximale Anzahl von Wiederholungsversuchen festlegen.

Einige Geschäftstransaktionen erstrecken sich über mehrere Dienste. Sie benötigen daher einen Mechanismus, um dienstübergreifende Transaktionen zu implementieren. Das Saga-Designmuster ist eine Möglichkeit, die Datenkonsistenz über Mikrodienste hinweg in verteilten Transaktionsszenarien zu verwalten. Eine Saga ist eine Abfolge von Transaktionen, die für jede Transaktion ein Ereignis veröffentlicht und die nächste Transaktion auslöst. Wenn eine Transaktion fehlschlägt, führt die Saga Ausgleichstransaktionen aus, die den vorherigen Fehlern in der Sequenz entgegenwirken. Probieren Sie die Anleitung zu Wiederholungsversuchen und zum Saga-Muster in Workflows auf GitHub aus.

Callbacks zum Warten verwenden

Mit Callbacks können Workflowausführungen darauf warten, dass ein anderer Dienst eine Anfrage an den Callback-Endpunkt sendet. Mit dieser Anfrage wird die Ausführung des Workflows fortgesetzt.

Mit Callbacks können Sie Ihrem Workflow signalisieren, dass ein bestimmtes Ereignis eingetreten ist, und auf dieses Ereignis warten, ohne Abfragen durchzuführen. Sie können beispielsweise einen Workflow erstellen, der Sie benachrichtigt, wenn ein Produkt wieder auf Lager ist oder ein Artikel versendet wurde, oder der auf eine menschliche Interaktion wartet, z. B. auf die Überprüfung einer Bestellung oder die Validierung einer Übersetzung. Sie können auch mit Callbacks und Eventarc-Triggern auf Ereignisse warten.

Jobs mit langer Ausführungszeit orchestrieren

Wenn Sie langlebige Arbeitslasten für die Batchverarbeitung ausführen müssen, können Sie Batch oder Cloud Run-Jobs verwenden. Außerdem können Sie Workflows zum Verwalten der Dienste verwenden. So können Sie Vorteile kombinieren und den gesamten Prozess effizient bereitstellen und orchestrieren.

Batch ist ein vollständig verwalteter Dienst, mit dem Sie Batcharbeitslasten auf Compute Engine-VM-Instanzen planen, in die Warteschlange verschieben und ausführen können. Sie können den Workflows-Connector für Batch verwenden, um einen Batchjob zu planen und auszuführen. Weitere Informationen finden Sie in der Anleitung.

Cloud Run-Jobs werden verwendet, um Code auszuführen, der eine Arbeit ausführt (einen Job) und nach Abschluss der Arbeit beendet wird. Mit Workflows können Sie Cloud Run-Jobs als Teil eines Workflows ausführen, um eine komplexere Datenverarbeitung durchzuführen oder ein System vorhandener Jobs zu orchestrieren. Probieren Sie die Anleitung aus, in der gezeigt wird, wie Sie mit Workflows einen Cloud Run-Job ausführen.

Zeitlimits und Nutzlastgrößen für alle Dienste angleichen

Wenn Workflows nachgelagerte Google Cloud -Dienste aufruft, können Unterschiede bei Zeitlimits für Anfragen, HTTP-Antwortlimits und Arbeitsspeicherlimits zu TimeoutError-, ValueError- oder MemoryLimitExceededError-Fehlern führen. Vergleichen Sie die Ressourcenlimits von Workflows mit den Limits des Zieldienstes und wählen Sie ein Integrationsmuster aus, das der Dauer und Nutzlastgröße Ihrer Arbeitslast entspricht. Beispiel:

Integrationsszenario Limits für Workflows Limits für Zieldienste Empfohlenes Muster
Synchrone HTTP-Aufrufe (http.get, http.post, http.request) an Cloud Run-Dienste oder Cloud Run-Funktionen
  • Maximale Zeitüberschreitung für HTTP-Anfragen von 30 Minuten (1.800 Sekunden), mit einem Standardwert von 300 Sekunden für http.*-Aufrufe und 1.800 Sekunden für HTTP-Anfragen des Connectors
  • Maximale HTTP-Antwortgröße von 2 MB vor dem Auslösen von ValueError
  • 512 KB kumulativer Variablenspeicher vor dem Auslösen von MemoryLimitExceededError
  • Maximales Zeitlimit für Anfragen von 60 Minuten (3.600 Sekunden) für Cloud Run-Dienste und Cloud Run Functions (2. Generation) oder maximal 9 Minuten (540 Sekunden) für Funktionen der 1. Generation
  • Maximale Größe von HTTP/1.1-Antworten: 32 MB

Weitere Informationen finden Sie unter Zeitlimit bei Anfrage für Dienste konfigurieren und Ressourcenlimits für Cloud Run.

Verwenden Sie für Arbeitslasten, die länger als 30 Minuten ausgeführt werden, keine synchronen http.*-Aufrufe an einen Cloud Run-Dienst.

Führen Sie stattdessen Cloud Run-Jobs mit dem Cloud Run Admin API-Connector aus oder verwenden Sie einen asynchronen Callback-Endpunkt von Workflows.

Der Cloud Run Admin API-Connector unterstützt die Abfrage von Vorgängen mit langer Ausführungszeit (LRO), die standardmäßig nach 30 Minuten (1.800 Sekunden) ein Zeitlimit erreicht. Konfigurieren Sie für Jobs, die länger als 30 Minuten dauern, sowohl das Aufgabenzeitlimit des Cloud Run-Jobs (standardmäßig 10 Minuten, konfigurierbar bis zu 168 Stunden oder 7 Tage) als auch connector_params.timeout für den Connector-Aufruf (bis zu 1 Jahr oder 31536000 Sekunden).
BigQuery-Abfragen und große API-Nutzlasten (googleapis.bigquery.v2.jobs.query und REST-Antworten)
  • 512 KB kumulativer Variablenspeicher vor dem Auslösen von MemoryLimitExceededError
  • Maximale UTF-8-Stringlänge von 256 KB
  • Maximale HTTP-Antwortgröße von 2 MB vor dem Auslösen von ValueError

BigQuery-Abfrageergebnisse und REST API-Nutzlasten können mehrere Megabyte oder Gigabyte groß sein.

Weitere Informationen finden Sie unter Kontingente und Limits für BigQuery-Abfragejobs.

Vermeiden Sie es, große Ergebnismengen in Workflow-Variablen zu ziehen.

Verwenden Sie die maxResults-Seitenaufteilung, schreiben Sie große Abfrageausgaben mit EXPORT DATA in eine Zieltabelle oder einen Cloud Storage-Bucket oder lagern Sie die Nutzlasttransformation und -filterung in einen Cloud Run-Dienst oder eine Cloud Run-Funktion aus, bevor Sie eine kompakte Zusammenfassung an Workflows zurückgeben.

Lang andauernde Aufgaben containerisieren

Sie können die Ausführung eines Containers mit langer Laufzeit mithilfe von Workflows und Compute Engine automatisieren. Sie können beispielsweise eine lang andauernde Aufgabe containerisieren, damit sie überall ausgeführt werden kann, und den Container dann auf einer Compute Engine-VM für die maximale Dauer einer Workflowausführung (ein Jahr) ausführen.

Mit Workflows können Sie die Erstellung der VM, die Ausführung des Containers auf der VM und das Löschen der VM automatisieren. So können Sie einen Server verwenden und einen Container ausführen, aber die Komplexität der Verwaltung beider wird abstrahiert. Das kann hilfreich sein, wenn Sie bei der Verwendung eines Dienstes wie Cloud Run-Funktionen oder Cloud Run auf Zeitbeschränkungen stoßen. Probieren Sie die Anleitung Container mit langer Ausführungszeit mit Workflows und Compute Engine auf GitHub aus.

Befehlszeilentools über Workflows ausführen

Cloud Build ist ein Dienst, der Ihre Builds in Google Cloud als eine Reihe von Build-Schritten ausführt, wobei jeder Build-Schritt in einem Docker-Container ausgeführt wird. Das Ausführen von Build-Schritten entspricht dem Ausführen von Befehlen in einem Skript.

Die Google Cloud CLI enthält die Befehlszeilentools gcloud, bq und kubectl. Es gibt jedoch keine direkte Möglichkeit, gcloud CLI-Befehle über Workflows auszuführen. Cloud Build stellt jedoch Container-Images bereit, die die gcloud CLI enthalten. Sie können gcloud CLI-Befehle in diesen Containern über einen Cloud Build-Schritt ausführen und diesen Schritt in Workflows mit dem Cloud Build-Connector erstellen.

Beispiel

Führen Sie gcloud in einem Workflow aus:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Workflow mit Terraform erstellen

Terraform ist ein Infrastruktur-als-Code-Tool, mit dem Sie Ihre Cloud-Infrastruktur mithilfe von Code vorhersehbar erstellen, ändern und verbessern können.

Sie können einen Workflow mit der Terraform-Ressource google_workflows_workflow definieren und bereitstellen. Weitere Informationen finden Sie unter Workflow mit Terraform erstellen.

Damit Sie große Workflows besser verwalten und pflegen können, können Sie Ihren Workflow in einer separaten YAML-Datei erstellen und diese Datei mit der Funktion templatefile in Terraform importieren. Diese Funktion liest eine Datei in einem bestimmten Pfad und rendert ihren Inhalt als Vorlage.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Wenn Sie einen Hauptworkflow haben, der mehrere Subworkflows aufruft, können Sie den Hauptworkflow und die Subworkflows in separaten Dateien definieren und mit der Funktion templatefile importieren.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Wenn Sie beim Debuggen eines Workflows auf Zeilennummern verweisen, werden alle über die Terraform-Konfigurationsdatei importierten YAML-Dateien zusammengeführt und als einzelner Workflow bereitgestellt.

Workflow aus einem Git-Repository bereitstellen

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu ermöglichen. Sie können Trigger so konfigurieren, dass sie auf eingehende Ereignisse warten, z. B. wenn ein neuer Commit an ein Repository übertragen oder ein Pull-Request initiiert wird, und dann automatisch einen Build ausführen, wenn neue Ereignisse eingehen.

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 nur dann, wenn die Änderung bestimmte Kriterien erfüllt.

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. Weitere Informationen finden Sie unter Workflow mit Cloud Build aus einem Git-Repository bereitstellen.

Nutzung optimieren

Die Kosten für die Ausführung eines Workflows sind minimal. Bei einer hohen Nutzung sollten Sie jedoch die folgenden Richtlinien beachten, um die Nutzung zu optimieren und die Kosten zu senken:

  • Anstatt benutzerdefinierte Domains zu verwenden, sollten Sie dafür sorgen, dass alle Aufrufe von Google Cloud-Diensten *.appspot.com, *.cloud.goog, *.cloudfunctions.net oder *.run.app verwenden, damit Ihnen interne und nicht externe Schritte in Rechnung gestellt werden.

  • Wenden Sie eine benutzerdefinierte Wiederholungsrichtlinie an, die Ihre Latenz- und Zuverlässigkeitsanforderungen mit den Kosten in Einklang bringt. Häufigere Wiederholungsversuche verringern die Latenz und erhöhen die Zuverlässigkeit, können aber auch die Kosten erhöhen.

  • Wenn Sie Connectors verwenden, die auf Vorgänge mit langer Ausführungszeit warten, legen Sie eine benutzerdefinierte Abfragerichtlinie fest, die die Latenz für die Kosten optimiert. Wenn Sie beispielsweise davon ausgehen, dass ein Vorgang länger als eine Stunde dauert, sollten Sie eine Richtlinie verwenden, die bei einem sofortigen Fehler nach einer Minute und danach alle 15 Minuten eine Abfrage durchführt.

  • Zuweisungen in einem Schritt kombinieren.

  • Vermeiden Sie die übermäßige Verwendung von sys.log-Schritten. Verwenden Sie stattdessen die Anrufprotokollierung.

  • Verstehen, welche Vorgänge als Schritt gelten. Vorgänge, die nicht als eigenständige Schritte zählen, werden gezählt, wenn sie innerhalb eines entsprechenden Schritts verwendet werden. Beispiel für einen Schritt:

    - type_check:
    return: if(get_type((int("6"))) == integer, 1, 2)

    In der folgenden Tabelle sind die wichtigsten Vorgänge aufgeführt, die auf das Limit für die maximale Anzahl von Schritten angerechnet werden und die nicht angerechnet werden:

    Kategorie Vorgang
    Zählt als Schritt
    • Datenvorgänge: Werte zuweisen, Werte zurückgeben
    • Ablaufsteuerung: Sprünge (next), Switches, Starten einer for-Schleife und jede Iteration einer for-Schleife
    • Aufrufe: Aufrufen von sys.get_env oder einer anderen Standardbibliotheksfunktion, eines anderen Workflows oder eines Connectors
    • Nebenläufigkeit: Threads erstellen und parallele Ausführung
    • Fehlerbehandlung: Jeder raise-, try-, retry- und except-Block zählt als separater Schritt, auch wenn andere Vorgänge Teil desselben größeren Schritts sind.

      Beispiel: Ein Schritt, der einen try-Block mit einem Aufrufvorgang enthält, zählt als drei Schritte: einer für den primären Schritt, einer für den Versuch und einer für den Aufruf. Wenn Sie einen retry-Block hinzufügen, werden drei weitere Schritte hinzugefügt (jeweils einer für die Wiederholung, den Versuch und den Aufruf), sodass insgesamt sechs Schritte ausgeführt werden.
    Zählt nicht als Schritt

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die in diesem Dokument empfohlenen allgemeinen Tipps und Best Practices zusammengefasst.

Allgemeine Tipps
Best Practices

Nächste Schritte