Ressourcen bereitstellen

Auf dieser Seite wird beschrieben, wie Sie Ressourcen für Ihre Pipelines bereitstellen.

Ressourcenbereitstellung in Orchestration Pipelines

Orchestration Pipelines verwendet einen Infrastructure-as-Code-Ansatz (IaC), umGoogle Cloud -Ressourcen zu verwalten, die von Ihren Datenpipelines verwendet werden. Das bietet folgende Vorteile:

  • Versionsverwaltung Infrastrukturänderungen werden in Git nachverfolgt.
  • Wiederholbarkeit: Umgebungen lassen sich zuverlässig neu erstellen.
  • Zusammenarbeit Teammitglieder können Infrastrukturdefinitionen prüfen und dazu beitragen.
  • Automation. Lässt sich in CI/CD-Pipelines einbinden.
  • 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. Diese können möglicherweise mit Ressourcen koexistieren, 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 Deployment-Umgebung. Bereitgestellte Ressourcen werden in der resources-Zuordnung 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 „Erstellen oder aktualisieren“-Modell, 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) Die Konfiguration der Ressource wird so aktualisiert, dass sie der Definition entspricht.

    • Wenn Sie dieses Verhalten in der Konfiguration der Ressource definieren, können 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. Bei diesem Ansatz wird die Sicherheit priorisiert und versehentlicher Datenverlust verhindert.

  • Wenn Sie eine vorhandene Ressource umbenennen, wird in Orchestration Pipelines eine neue Ressource mit dem neuen Namen erstellt und die ursprüngliche Ressource beibehalten.

Bereitgestellte Ressourcen im Vergleich zu Ressourcenprofilen

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

  • Mit bereitgestellten Ressourcen: Anstatt dieselbe 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 Ressourcenprofilen definiert werden können.

  • Mit Pipelineaktionen: Sie können Ressourcenprofile in Aktionen verwenden, in denen Ressourcen für die Dauer einer Aktion bereitgestellt werden. Wenn Sie ein Ressourcenprofil verwenden, anstatt die Ressourcenkonfiguration 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. beim Ausführen von Pipelineaktionen in einem kurzlebigen Cluster.

Verfügbare Ressourcentypen ansehen

Weitere Informationen finden Sie unter Ressourcentypen.

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

gcloud beta orchestration-pipelines resource-types list

Neue Ressource hinzufügen

So fügen Sie der Konfiguration der Bereitstellungsumgebung eine neue bereitgestellte Ressource hinzu:

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

  2. Geben Sie die folgenden Schlüssel an:

    • type: Der Typ der Google Cloud Ressource, die bereitgestellt werden soll. 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.

        Beim Aktualisieren werden nur die Eigenschaften geändert, die in der Konfiguration (YAML) der Ressource angegeben sind. Andere vorhandene Eigenschaften bleiben unverändert. Sie können dieses Verhalten beispielsweise nutzen, um nur die für die Pipelineausführung wichtigen Eigenschaften zu verwalten und andere Eigenschaften 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 änderbare Felder geändert werden. Wenn das 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 jedoch 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 Definition der aktuellen 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: Metadaten speziell für Orchestration Pipelines. Bei einigen Ressourcentypen werden Metadatenfelder verwendet, um die Ressource inGoogle Cloud zu konfigurieren. Mit dem Feld metadata.location lassen sich beispielsweise zonale Ressourcen erstellen.

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

Beispiel: Lang andauernde Ressourcen

In diesem Beispiel wird gezeigt, wie Sie eine lang andauernde Ressource hinzufügen, in diesem Fall einen statischen Managed Service for Apache Spark-Cluster. Nach der Bereitstellung kann sie in Pipeline-Aktionen verwendet werden. Wir empfehlen, diesen allgemeinen Ansatz zu verwenden, wenn in Ihren Pipelines nichtflüchtige Ressourcen verwendet werden.

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. Die Verwendung unterscheidet sich nicht von der 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 gilt Folgendes:

  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 per Push ü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. Mit einer Workflowkonfiguration werden dann Workflows mit diesem automatisch kompilierten Release ausgeführt.

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

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

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

    1. Das Framework führt zuerst ein Upsert (Aktualisieren oder Erstellen) der releaseConfig-Ressource aus, 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, sodass sie auf die neu erstellte Compilation Result-ID verweist. Diese Version ist dann die „aktive“ 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, mit der ein Workflow mit der erstellten Workflowkonfiguration ausgeführt wird:

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