Ressourcen bereitstellen

Auf dieser Seite wird erläutert, wie Sie Ressourcen für Ihre Pipelines bereitstellen.

Ressourcenbereitstellung in Orchestration Pipelines

Orchestration Pipelines verwendet einen Infrastructure-as-Code-Ansatz (IaC) zur Verwaltung Google Cloud von Ressourcen, die von Ihren Datenpipelines verwendet werden. Dies bietet folgende Vorteile:

  • Versionsverwaltung Infrastrukturänderungen werden in Git verfolgt.
  • Wiederholbarkeit Umgebungen können zuverlässig neu erstellt werden.
  • Zusammenarbeit Teammitglieder können Infrastrukturdefinitionen überprüfen und dazu beitragen.
  • Automatisierung Integration in CI/CD-Pipelines
  • Optionalität und Koexistenz Das Framework für die Ressourcenbereitstellung ist optional. Wenn Sie bereits Terraform oder andere etablierte IaC-Methoden für die Ressourcenbereitstellung verwenden, können Sie dies weiterhin tun. Sie können eine Teilmenge von Ressourcen verwalten, die für eine bestimmte Pipeline oder Anwendung relevant sind, und diese möglicherweise zusammen mit Ressourcen verwenden, die von anderen Tools verwaltet werden.

In Orchestration Pipelines kann Ihr Projekt eine oder mehrere Bereitstellungsumgebungen haben. Die Konfiguration jeder Bereitstellungsumgebung definiert, wie Pipelines und Ressourcen, die zu dieser Umgebung gehören, bereitgestellt werden. Sie können beispielsweise eine Bereitstellungsumgebung für die Entwicklung und eine andere für die Produktion haben.

Beispiel für eine Konfiguration der Bereitstellungsumgebung. Bereitgestellte Ressourcen werden in der Zuordnung resources definiert.

environments:
  dev:
    project: example-dev-project
    region: us-central1
    variables:
      dataset_name: marketing_analytics_dev
    secrets:
      dts_api_key: "projects/example-dev-project/secrets/dev-dts-key/versions/latest"
    resources:
      - type: dataproc.cluster
        name: example-static-cluster-resource
        definition:
          clusterName: example-static-cluster

Wenn Sie Ihre Pipeline bereitstellen, verwendet Orchestration Pipelines ein zustandsloses Modell zum Erstellen oder Aktualisieren, um die von Ihnen definierten Ressourcen bereitzustellen:

  • Wenn eine Ressource definiert, aber nicht vorhanden ist, wird sie von Orchestration Pipelines erstellt.

  • Wenn eine Ressource vorhanden ist:

    • (Standard) Aktualisieren Sie die Konfiguration der Ressource, damit sie mit der Definition übereinstimmt.

    • Wenn Sie dieses Verhalten in der Konfiguration der Ressource definieren, kann Orchestration Pipelines Änderungen ignorieren oder eine Ressource neu erstellen.

  • Wenn Sie die Definition einer Ressource aus der Konfiguration löschen, wird die Ressource nicht gelöscht. Dieser Ansatz priorisiert die Sicherheit und verhindert versehentlichen Datenverlust.

  • Wenn Sie eine vorhandene Ressource umbenennen, erstellt Orchestration Pipelines eine neue Ressource mit dem neuen Namen und behält die ursprüngliche Ressource bei.

Bereitgestellte Ressourcen im Vergleich zu Ressourcenprofilen

Ressourcenprofile sind Vorlagendateien, die die Definition einer oder mehrerer Google Cloud Ressourcen enthalten. Sie unterscheiden sich von bereitgestellten Ressourcen und können zusammen mit ihnen verwendet werden:

  • Mit bereitgestellten Ressourcen: Anstatt die gleiche Ressourcenkonfiguration inline in jeder Entwicklungsumgebung in Ihrer deployment.yaml zu definieren, können Sie sie einmal in einem Profil definieren und dann darauf verweisen. Bereitgestellte Ressourcen unterstützen eine Vielzahl von Ressourcentypen, die in Ressourcen profilen definiert werden können.

  • Mit Pipelineaktionen: Sie können Ressourcenprofile in Aktionen verwenden, bei denen Ressourcen für die Dauer einer Aktion bereitgestellt werden. Wenn Sie ein Ressourcenprofil verwenden, anstatt die Konfiguration der Ressource inline anzugeben, können Sie die Ressourcenkonfiguration von der Pipelineaktion trennen und eine Konfiguration für mehrere Pipelineaktionen wiederverwenden. Pipelineaktionen unterstützen Ressourcenprofile nur für Managed Service for Apache Spark-Ressourcen, z. B. bei der Ausführung von Pipelineaktionen in einem kurzlebigen Cluster.

Verfügbare Ressourcentypen ansehen

Weitere Informationen finden Sie unter Ressourcentypen.

Sie können auch alle verfügbaren Ressourcen in der gcloud CLI mit dem folgenden Befehl aufrufen:

gcloud beta orchestration-pipelines resource-types list

Neue Ressource hinzufügen

Wenn Sie der Konfiguration der Bereitstellungsumgebung eine neue bereitgestellte Ressource hinzufügen möchten, fügen Sie die Definition so hinzu:

  1. Fügen Sie in der Konfiguration Ihrer Bereitstellungsumgebung der environments.DEVELOPMENT_ENVIRONMENT.resources Liste ein neues Element hinzu.

  2. Geben Sie die folgenden Schlüssel an:

    • type: Der Typ der Google Cloud bereitzustellenden Ressource. Beispiele: bigquery.dataset, dataform.repository. Sie können verfügbare Ressourcentypen mit einem gcloud CLI-Befehl aufrufen.

    • name: Ein logischer Name für die Ressource in der Datei deployment.yaml.

    • parent: Gibt eine übergeordnete Ressource für Ressourcentypen an, die eine solche erfordern. Geben Sie den name der übergeordneten Ressource als Wert an.

    • updateAction: Gibt an, welche Aktion ausgeführt werden muss, wenn eine Änderung in der Konfiguration der Ressource erkannt wird:

      • (Standard) patch: Aktualisieren Sie die Attribute der Ressource, die sich geändert haben.

        Der Aktualisierungsvorgang ändert nur die in der Konfiguration der Ressource (YAML) angegebenen Attribute. Andere vorhandene Attribute bleiben unverändert. Sie können dieses Verhalten beispielsweise verwenden, um nur Attribute zu verwalten, die für die Pipelineausführung wichtig sind, und andere Attribute manuell zu konfigurieren.

        Wenn Änderungen unveränderliche Felder betreffen oder die Ressource unveränderlich ist, schlägt die Bereitstellung fehl. In solchen Fällen empfehlen wir, die Definition so anzupassen, dass nur veränderliche Felder geändert werden. Wenn dies nicht möglich ist, können Sie die Aktualisierungsaktion in recreate ändern.

      • skip: Änderungen ignorieren und die Konfiguration der Ressource nicht aktualisieren.

        Wir empfehlen, diese Option zu verwenden, wenn Sie die Existenz der Ressource verwalten, die Konfigurationsänderungen und ‑aktualisierungen aber auf andere Weise vornehmen möchten, z. B. manuell.

      • recreate: Wenn Änderungen erkannt werden, löschen Sie die vorhandene Ressource und erstellen Sie dann eine neue Ressource basierend auf der aktuellen Definition der Ressource.

        Wir empfehlen, diese Option für Ressourcen zu verwenden, die vollständig unveränderlich sind oder wenn Änderungen an Feldern vorgenommen werden, die nicht direkt aktualisiert werden können.

    • definition: Spezifikation der Ressource als Zuordnung, die die Konfigurationsstruktur der Ressource in der API der Ressource widerspiegelt.

    • (Optional) metadata: Orchestration Pipelines-spezifische Metadaten. Einige Ressourcentypen verwenden Metadatenfelder, um die Ressource in Google Cloud zu konfigurieren. Mit dem metadata.location Feld können beispielsweise zonale Ressourcen erstellt werden.

  3. Validieren und stellen Sie Ihre Pipeline bereit. Orchestration Pipelines stellt die neue Ressource bereit, wenn die Pipeline bereitgestellt wird.

Beispiel: Ressourcen mit langer Laufzeit

In diesem Beispiel wird gezeigt, wie Sie eine Ressource mit langer Laufzeit hinzufügen, in diesem Fall einen statischen Managed Service for Apache Spark-Cluster. Nach der Bereitstellung kann er in Pipelineaktionen verwendet werden. Wir empfehlen, diesen allgemeinen Ansatz zu verwenden, wenn Ihre Pipelines persistente Ressourcen verwenden.

Im folgenden Beispiel wird der Bereitstellungsumgebung dev ein statischer Managed Service for Apache Spark-Cluster mit dem Namen example-static-cluster hinzugefügt. Die Definition der Ressource basiert auf der Dataproc API.

environments:
  dev:
    project: "example-project"
    region: "us-central1"
    # A runner environment for executing pipeline actions
    composer_environment: "example-runner-environment"

    resources:
      - type: dataproc.cluster
        name: example-static-cluster
        updateAction: patch
        definition:
          config:
            masterConfig:
              numInstances: 1
              machineTypeUri: n1-standard-4
            workerConfig:
              numInstances: 3
              machineTypeUri: n1-standard-4

Dieser Cluster kann wie gewohnt in Pipelineaktionen verwendet werden. Es gibt keinen Unterschied zur Verwendung eines manuell erstellten Clusters.

modelVersion: "1.0"
pipelineId: "example-dataproc-pipeline"
...
actions:
  - pyspark:
      name: "run-pyspark-with-pyfiles-on-existing-cluster"
      engine:
        dataprocOnGce:
          existingCluster:
            clusterName: "example-static-cluster"
            location: {{ region }}
            projectId: {{ project }}
      mainFilePath: "scripts/my_spark_job_with_pyfiles.py"
      pyFiles:
        - "scripts/lib1.py"

Beispiel: Automatisierter Build- und Releaseprozess für Dataform

In diesem Beispiel wird ein automatisierter Build- und Releaseprozess für Dataform veranschaulicht. Im Beispielszenario:

  1. Ein Dataform-Repository ist über Developer Connect mit einem GitHub-Repository verbunden.

  2. Sie übertragen Änderungen per Push an das GitHub-Repository.

  3. Nachdem die Änderungen übertragen wurden, stellen Sie die Pipeline bereit.

  4. Dataform ruft den Code aus dem GitHub-Repository ab, erstellt ein Kompilierungsergebnis und bereitet es für die Ausführung vor.

  5. Anschließend werden mit einer Workflowkonfiguration Workflows mit diesem automatisch kompilierten Release ausgeführt.

Im folgenden Codebeispiel werden ein Dataform-Repository, eine Releasekonfiguration und eine Workflowkonfiguration dafür in der Bereitstellungsumgebung dev definiert:

  • Die gitCommitish: "{{ COMMIT_SHA }}" Zeile verknüpft die Release Konfiguration mit dem spezifischen Git-Commit, der bereitgestellt wird. Die COMMIT_SHA ist eine Variable, die in die Commit-SHA des bereitgestellten Pipelinepakets aufgelöst wird.
  • Der Schlüssel codeCompilationConfig.pipelineConfig.path verweist auf einen Unterordner, der Pipeline-Assets enthält. So können Sie mehrere Dataform-Pipelines in einem einzigen Repository aufbewahren.

  • Wenn Sie releaseCompilationResult in der Definition von releaseConfig auf auto setzen, wird Orchestration Pipelines angewiesen, eine Dataform-Kompilierung auszulösen, nachdem die Ressource releaseConfig mit dem neuen gitCommitish erstellt oder aktualisiert wurde:

    1. Das Framework führt zuerst ein Upsert (Aktualisieren oder Erstellen) der Ressource releaseConfig durch, um auf den angegebenen Commit zu verweisen.
    2. Aufgrund der Einstellung auto wird dann die Dataform API aufgerufen, um ein neues Kompilierungsergebnis basierend auf dem Code in diesem Commit zu erstellen.
    3. Die releaseConfig wird noch einmal aktualisiert, um auf die neu erstellte Kompilierungsergebnis-ID zu verweisen. Diese Version ist dann die "Live"-Version.
environments:
  dev:
    project: example-project
    region: us-central1
    composer_environment: example-runner-environment
    artifact_storage:
      bucket: example-bucket
      path_prefix: initialized-artifact-bucket
    pipelines:
      - source: initialized-pipeline.yaml
      - source: dataform_local_pipeline.yaml
      - source: dataform_service_pipeline.yaml
    resources:
      - name: {{ repository_name }}
        type: dataform.repository
        definition:
          labels:
            bigquery-deployment: preview
      - type: dataform.repository.releaseConfig
        name: subfolder-release
        parent: {{ repository_name }}
        definition:
          gitCommitish: {{ COMMIT_SHA }}
          releaseCompilationResult: auto
          codeCompilationConfig:
            pipelineConfig:
              pipelineType: DATAFORM
              path: weather_dataform
      - type: dataform.repository.workflowConfig
        name: {{ workflow_config_name }}
        parent: {{ repository_name }}
        definition:
          releaseConfig: subfolder-release
          invocationConfig:
            serviceAccount: {{ service_account }}
    variables:
      service_account: example-account@example-project.iam.gserviceaccount.com
      network_uri: projects/example-project/global/networks/default
      subnetwork_uri: projects/example-project/regions/us-central1/subnetworks/default
      region: us-central1
      repository_name: weather-aggregation-repo
      workflow_config_name: updated-subfolder-workflow

Beispiel für eine Pipelineaktion, die einen Workflow mit der erstellten Workflowkonfiguration ausführt:

modelVersion: '1.0'
pipelineId: dataform_service_pipeline
description: Updated run Dataform pipeline via Dataform Service
runner: airflow
owner: data-eng-team

defaults:
  projectId: {{ project }}
  location: {{ region }}
  executionConfig:
    retries: 1

actions:
  - pipeline:
      name: run_dataform_service
      framework:
        dataform:
          dataformService:
            location: {{ region }}
            projectId: {{ project }}
            repositoryId: {{ repository_name }}
            workflowInvocation:
              workflowConfig: projects/{{ project }}/locations/{{ region }}/repositories/{{
                repository_name }}/workflowConfigs/{{ workflow_config_name }}
  - python:
      name: fibonacci_python
      mainFilePath: scripts/fibonacci.py
      pythonCallable: fibonacciTen
      engine:
        local: {}
  - sql:
      name: dummy_bq_query
      engine:
        bigquery:
          location: {{ region }}
      query:
        inline: 'SELECT COUNT(*) FROM `{{ project }}.weather_data.sensor_readings`'
tags:
  - job:datacloud:vscode