Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

リソースのプロビジョニング

このページでは、パイプラインのリソースをプロビジョニングする方法について説明します。

Orchestration Pipelines でのリソースプロビジョニングについて

オーケストレーションパイプラインは、Infrastructure as Code（IaC）アプローチを使用して、 Google Cloud データパイプラインで使用されるリソースを管理します。これにより、次のメリットが得られます。

バージョン管理。インフラストラクチャの変更は Git で追跡されます。
反復性。環境を確実に再作成できます。
コラボレーション。チームメンバーはインフラストラクチャ定義を確認して貢献できます。
自動化。CI/CD パイプラインに統合されます。
オプションと共存。リソースプロビジョニングフレームワークは省略可能です。リソースプロビジョニングに Terraform や他の確立された IaC プラクティスをすでに使用している場合は、引き続き使用できます。特定のパイプラインまたはアプリケーションに関連するリソースのサブセットを管理できます。他のツールで管理されているリソースと共存することもできます。

Orchestration Pipelines では、プロジェクトに 1 つ以上のデプロイ環境を設定できます。各デプロイ環境の構成では、この環境に属するパイプラインとリソースのデプロイ方法を定義します。たとえば、開発用のデプロイ環境と本番環境用のデプロイ環境を設定できます。

デプロイ環境の構成の例。プロビジョニングされたリソースは、resources マッピングで定義されます。

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

パイプラインをデプロイすると、Orchestration Pipelines はステートレスの「作成または更新」モデルを使用して、定義したリソースをプロビジョニングします。

リソースが定義されているが存在しない場合、Orchestration Pipelines はリソースを作成します。
リソースが存在する場合:
- （デフォルト）定義に合わせてリソースの構成を更新します。
- リソースの構成でこの動作を定義すると、Orchestration Pipelines は変更を無視するか、リソースを再作成できます。
構成からリソースの定義を削除しても、 リソースは削除されません。このアプローチでは安全性が優先され、誤ってデータを損失することを防ぎます。
既存のリソースの名前を変更すると、Orchestration Pipelines は新しい名前で新しいリソースを作成し、元のリソースを保持します。

プロビジョニングされたリソースとリソースプロファイルの違い

リソースプロファイルは、1 つ以上の Google Cloud リソースの定義を含むテンプレートファイルです。プロビジョニングされたリソースとは異なり、プロビジョニングされたリソースと一緒に使用できます。

プロビジョニングされたリソースの場合: deployment.yaml の各開発環境内で同じリソース構成をインラインで定義するのではなく、プロファイルで一度定義して参照できます。プロビジョニングされたリソースは、リソースプロファイルで定義できる幅広いリソースタイプをサポートしています。
パイプラインアクションの場合: リソースがアクションの期間中にプロビジョニングされるアクションでリソースプロファイルを使用できます。リソースの構成をインラインで指定する代わりにリソースプロファイルを使用すると、リソース構成をパイプラインアクションから分離し、複数のパイプラインアクションで 1 つの構成を再利用できます。パイプラインアクションは、Managed Service for Apache Spark リソースのリソースプロファイルのみをサポートします。たとえば、エフェメラルクラスタでパイプラインアクションを実行する場合などです。

使用可能なリソースタイプを表示する

リソースタイプをご覧ください。

次のコマンドを使用して、gcloud CLI で使用可能なすべてのリソースを表示することもできます。

gcloud beta orchestration-pipelines resource-types list

新しいリソースを追加する

新しいプロビジョニングされたリソースをデプロイ環境の構成に追加するには、次のように定義を追加します。

デプロイ環境の構成で、 environments.DEVELOPMENT_ENVIRONMENT.resources リストに新しい項目を追加します。
次のキーを指定します。
- type: プロビジョニングするリソースのタイプ。 Google Cloud 例: bigquery.dataset、dataform.repository。使用可能なリソースタイプは、gcloud CLI コマンドで確認できます。
- name: deployment.yaml ファイル内のリソースの論理名。
  
  重要: プロビジョニングされたリソースには、リソースの論理名に加えて、 definition の一部として独自の名前（通常は definition.name キー）を設定できます。 Google Cloud マッピングで definition キーを省略 することをおすすめします。nameこの場合、プロビジョニングされたリソースの名前はリソースの論理名に設定されます。リソースの定義で名前を明示的に指定する場合は、リソースの論理名と同じにしてください。
- parent: 親リソースを必要とするリソースタイプに親リソースを指定します。親リソースの name を値として指定します。
- updateAction: リソースの構成で変更が検出されたときに実行する必要があるアクションを指定します。
  - （デフォルト）patch: 変更されたリソースのプロパティを更新します。
    
    更新オペレーションでは、リソースの構成（YAML）で指定されたプロパティのみが変更され、他の既存のプロパティは変更されません。この動作を使用すると、たとえば、パイプラインの実行に重要なプロパティのみを管理し、他のプロパティを手動で構成したままにできます。
    
    変更が不変フィールドに影響する場合や、リソースが不変の場合、デプロイは失敗します。このような場合は、可変フィールドのみを変更するように定義を調整することをおすすめします。これが不可能な場合は、更新アクションを recreate に変更できます。
  - skip: 変更を無視し、リソースの構成を更新しません。
    
    リソースの存在を管理するが、構成の変更と更新を他の方法（手動など）で行う場合は、このオプションを使用することをおすすめします。
  - recreate: 変更が検出された場合は、既存のリソースを削除し、現在のリソースの定義に基づいて新しいリソースを作成します。
    
    注意: このオペレーションは破壊的 であり、データ損失につながる可能性があります。このオペレーションには 2 つのステップがあります。まず、リソースが削除され、次に新しいリソースが作成されます。リソースの作成に失敗した場合、削除オペレーションはロールバックされません。
    
    完全に不変のリソースの場合や、インプレースで更新できないフィールドが変更された場合は、このオプションを使用することをおすすめします。
- definition: リソースの API でリソースの構成構造を反映するマッピングとして、リソースの仕様。
- （省略可）metadata: オーケストレーションパイプライン固有のメタデータ。一部のリソースタイプでは、メタデータフィールドを使用してリソースを構成します。たとえば、metadata.location フィールドを使用してゾーンリソースを作成できます。Google Cloud
パイプラインを検証してデプロイします。Orchestration Pipelines は、パイプラインがデプロイされると新しいリソースをプロビジョニングします。

例: 長時間実行されるリソース

この例では、長時間実行されるリソース（この場合は静的な Managed Service for Apache Spark クラスタ）を追加する方法を示します。プロビジョニングが完了すると、パイプラインアクションで使用できます。パイプラインで永続リソースを使用する場合は、この一般的なアプローチを使用することをおすすめします。

次の例では、example-static-cluster という名前の静的な Managed Service for Apache Spark クラスタを dev デプロイ環境に追加します。リソースの定義は、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

このクラスタは、通常どおりパイプラインアクションで使用できます。たとえば、手動で作成したクラスタと比較して、使用方法に違いはありません。

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"

例: Dataform のビルドとリリースプロセスの自動化

この例では、Dataform のビルドとリリースプロセスの自動化を示します。シナリオ例:

Dataform リポジトリは、Developer Connect を介して GitHub リポジトリに接続されます。
変更を GitHub リポジトリに push します。
変更が push されたら、パイプラインをデプロイします。
Dataform は GitHub リポジトリからコードを pull し、コンパイル結果を作成して、実行の準備をします。
ワークフロー構成を使用して、この自動コンパイルされたリリースでワークフローを実行します。

次のコード例では、dev デプロイ環境で Dataform リポジトリ、リリース構成、ワークフロー構成を定義します。

gitCommitish: "{{ COMMIT_SHA }}" 行は、リリース構成をデプロイされる特定の Git commit に関連付けます。COMMIT_SHA は、デプロイされたパイプラインバンドルの commit SHA に解決される変数です。
codeCompilationConfig.pipelineConfig.path キーは、パイプラインアセットを含むサブフォルダを指します。これにより、複数の Dataform パイプラインを 1 つのリポジトリに保持できます。
releaseConfig の定義で releaseCompilationResult を auto に設定すると、新しい gitCommitish で releaseConfig リソースが作成または更新された後に、Orchestration Pipelines が Dataform コンパイルをトリガーします。
1. フレームワークは、まず releaseConfig リソースを upsert（更新または作成）して、指定された commit を指すようにします。
2. 次に、auto 設定により、Dataform API を呼び出して、その commit のコードに基づいて新しいコンパイル結果を作成します。
3. releaseConfig は、新しく作成されたコンパイル結果 ID を指すように再度更新され、そのバージョンが「ライブ」になります。

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

作成されたワークフロー構成でワークフローを実行するパイプラインアクションの例:

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

リソースのプロビジョニング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Orchestration Pipelines でのリソース プロビジョニングについて

プロビジョニングされたリソースとリソース プロファイルの違い