Cloud Composer 環境を作成する

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

このページでは、Cloud Composer 環境を作成する方法について説明します。

準備

ステップ 1. 環境のサービス アカウントを作成または選択する

環境を作成するときに、サービス アカウントを指定します。このサービス アカウントは、環境のサービス アカウントと呼ばれます。環境では、このサービス アカウントを使用してほとんどのオペレーションを実行します。

ご使用の環境のサービス アカウントはユーザー アカウントではありません。サービス アカウントは、ユーザーではなく、アプリケーションや仮想マシン（VM）インスタンスで使用される特別なアカウントです。

ご使用の環境のサービス アカウントは後で変更できません。

プロジェクトに Cloud Composer 環境のサービス アカウントがまだない場合は、作成します。

Terraform で環境のサービス アカウントを作成する詳細な例については、環境の作成（Terraform）をご覧ください。

環境に新しいサービス アカウントを作成するには:

  1. Identity and Access Management のドキュメントの説明に沿って、新しいサービス アカウントを作成します。

  2. Identity and Access Management のドキュメントに記載されているとおりに、ロールを付与します。必要なロールは Composer ワーカー（composer.worker）です。

  3. お使いの環境でリソース ロケーションの制限を使用している場合、または Artifact Registry リポジトリまたは限定公開リポジトリから PyPI パッケージをインストールする場合は、環境を自身で実行するユーザー管理のサービス アカウントにサービス アカウント ユーザー（iam.serviceAccountUser）ロールを付与します（プリンシパルとリソースの両方が同じサービス アカウントです）。

  4. Google Cloud プロジェクト内の他のリソースにアクセスするには、このサービスアカウントにこれらのリソースにアクセスするための追加の権限を付与します。ほとんどの場合、Composer ワーカー（composer.worker）ロールには、この必要な権限セットが含まれています。DAG の運用に必要な場合のみ、このサービス アカウントに追加の権限を追加してください。

ステップ 2. 基本設定

この手順では、指定したロケーションにデフォルト パラメータを持つ Cloud Composer 環境を作成します。

コンソール

  1. Google Cloud コンソールで、[環境の作成] ページに移動します。

    [環境の作成] に移動

  2. [名前] フィールドに、環境の名前を入力します。

    名前は、は先頭を小文字にし、その後を最大 62 文字の小文字、数字、ハイフンで構成する必要があります。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。

  3. [ロケーション] プルダウン リストで、環境のロケーションを選択します。

    ロケーションは、環境が配置されているリージョンです。

  4. [イメージのバージョン] プルダウン リストで、必要なバージョンの Airflow を含む Cloud Composer イメージを選択します。

  5. [サービス アカウント] プルダウン リストで、環境のサービス アカウントを選択します。

    環境のサービス アカウントがまだない場合は、環境のサービス アカウントを作成または選択するをご覧ください。

gcloud

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version IMAGE_VERSION \
    --service-account "SERVICE_ACCOUNT"

以下のように置き換えます。

  • ENVIRONMENT_NAME を環境の名前にする。

    名前は、は先頭を小文字にし、その後を最大 62 文字の小文字、数字、ハイフンで構成する必要があります。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。

  • LOCATION は、環境のリージョンに置き換えます。

    ロケーションは、環境が配置されているリージョンです。

  • SERVICE_ACCOUNT は、環境のサービス アカウントに置き換えます。

  • IMAGE_VERSION は、Cloud Composer イメージの名前に置き換えます。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
"

API

environments.create API リクエストを作成します。構成は、Environment リソースで指定します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "softwareConfig": {
      "imageVersion": "IMAGE_VERSION"
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • PROJECT_ID は、プロジェクト ID に置き換えます。

  • LOCATION は、環境のリージョンに置き換えます。

    ロケーションは、環境が配置されているリージョンです。

  • ENVIRONMENT_NAME は、環境名に置き換えます。

    名前は、は先頭を小文字にし、その後を最大 62 文字の小文字、数字、ハイフンで構成する必要があります。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。

  • IMAGE_VERSION は、Cloud Composer イメージの名前に置き換えます。

  • SERVICE_ACCOUNT は、環境のサービス アカウントに置き換えます。

例:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "imageVersion": "composer-2.11.1-airflow-2.10.2"
    },
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

デフォルトのパラメータを使用して環境を作成するには、指定された場所で Terraform 構成に次のリソース ブロックを追加して terraform apply を実行します。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    software_config {
      image_version = "IMAGE_VERSION"
    }
    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • ENVIRONMENT_NAME を環境の名前にする。

    名前は、は先頭を小文字にし、その後を最大 62 文字の小文字、数字、ハイフンで構成する必要があります。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。

  • LOCATION は、環境のリージョンに置き換えます。

    ロケーションは、環境が配置されているリージョンです。

  • IMAGE_VERSION は、Cloud Composer イメージの名前に置き換えます。

  • SERVICE_ACCOUNT は、環境のサービス アカウントに置き換えます。

例:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    software_config {
      image_version = "composer-2.11.1-airflow-2.10.2"
    }
    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

ステップ 3. Cloud Composer サービス アカウントに必要な権限を付与する

プロジェクトで Cloud Composer API を有効にすると、Composer サービス エージェント アカウントがプロジェクトに作成されます。Cloud Composer は、このアカウントを使用してGoogle Cloud プロジェクトでオペレーションを実行します。

Cloud Composer v2 API サービス エージェント拡張機能のロールは、Cloud Composer サービス エージェント アカウントに追加の権限を提供します。このロールは自動的には付与されません。これは手動で付与する必要があります。

コンソール

プロジェクトに環境を作成するときに、環境のサービス アカウントに必要な権限が Cloud Composer サービス エージェントにない場合、Cloud Composer サービス アカウントに必要な権限を付与する] セクションが表示されます。

環境のサービス アカウントの新しいプリンシパルとして Cloud Composer サービス エージェント アカウントを追加し、Cloud Composer v2 API サービス エージェント拡張機能のロールを付与します。

環境で使用するサービス アカウントを使用していることを確認し、[付与] をクリックします。

gcloud

環境のサービス アカウントの新しいプリンシパルとして Cloud Composer サービス エージェント アカウントを追加し、Cloud Composer v2 API サービス エージェント拡張機能のロールを付与します。

gcloud iam service-accounts add-iam-policy-binding \
    SERVICE_ACCOUNT \
    --member serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

以下のように置き換えます。

  • SERVICE_ACCOUNT は、環境のサービス アカウントに置き換えます。
  • PROJECT_NUMBER は、プロジェクト番号に置き換えます。

例:

gcloud iam service-accounts add-iam-policy-binding \
    example-account@example-project.iam.gserviceaccount.com \
    --member serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

API

ロールを付与するには、読み取り、変更、書き込みのパターンを使用して既存の許可ポリシーを変更する必要があります。

  1. ご使用の環境のサービス アカウントに関する既存の許可ポリシーを読み取ります。
  2. これを変更して、Cloud Composer サービス アカウントの roles/composer.ServiceAgentV2Ext ロールを含めます。
  3. 既存の許可ポリシーを書き換えます。

詳細については、プログラムによるアクセス権の制御をご覧ください。

{
  "role": "roles/composer.ServiceAgentV2Ext",
  "members": [
    "serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com"
  ]
}

以下のように置き換えます。

例:

{
  "role": "roles/composer.ServiceAgentV2Ext",
  "members": [
    "serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com"
  ]
}

Terraform

環境のサービス アカウントの許可ポリシーに新しいロール バインディングを追加します。

環境のサービス アカウントの新しいプリンシパルとして Cloud Composer サービス エージェント アカウントを追加し、Cloud Composer v2 API サービス エージェント拡張機能のロールを付与します。

Terraform を使用して環境のサービス アカウント許可ポリシーを定義していない場合は、次の例を使用しないでください。代わりに、他の方法でこのバインディングを追加します。

resource "google_service_account_iam_member" "custom_service_account" {
  provider = google-beta
  service_account_id = "SERVICE_ACCOUNT"
  role = "roles/composer.ServiceAgentV2Ext"
  member = "serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com"
}

以下のように置き換えます。

  • SERVICE_ACCOUNT は、環境のサービス アカウントに置き換えます。
  • PROJECT_NUMBER は、プロジェクト番号に置き換えます。

例:

resource "google_service_account_iam_member" "custom_service_account" {
  provider = google-beta
  service_account_id = "example-account@example-project.iam.gserviceaccount.com"
  role = "roles/composer.ServiceAgentV2Ext"
  member = "serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com"
}

ステップ 4. （省略可）環境のスケーリングとパフォーマンスのパラメータを構成する

環境のスケーリングとパフォーマンスを構成するには、環境のサイズとワークロードの構成を選択します。

環境を作成した後に、すべてのパフォーマンスとスケーリングのパラメータを変更できます。

スケーリングとパフォーマンスは、次のパラメータで制御します。

  • 環境サイズ。Airflow データベースを含むマネージド Cloud Composer インフラストラクチャのパフォーマンス パラメータを制御します。インフラストラクチャのパフォーマンスを高めながら多数の DAG とタスクを実行する場合は、大きめの環境サイズの選択を検討してください。たとえば、環境のサイズが大きいほど、環境で最小限の遅延で処理できる Airflow タスクログ エントリの量が増えます。

  • ワークロード構成環境の GKE クラスタで実行される Airflow コンポーネントのスケールとパフォーマンスを制御します。

    • Airflow スケジューラ。DAG ファイルを解析し、スケジュール間隔に基づいて DAG の実行をスケジュールし、Airflow ワーカーが実行するタスクをキューに入れます。

      ご利用の環境では、同時に複数の Airflow スケジューラを実行できます。複数のスケジューラを使用して複数のスケジューラ インスタンス間で負荷を分散すると、パフォーマンスと信頼性が向上します。

      スケジューラの数を増やしても、Airflow のパフォーマンスが常に改善されるとは限りません。たとえば、スケジューラが 1 つだけでも、2 つの場合よりも良いパフォーマンスの場合があります。これは、追加のスケジューラが使用されないため、全体的なパフォーマンスに寄与せずに環境のリソースを消費した場合に発生する可能性があります。実際のスケジューラのパフォーマンスは、Airflow ワーカーの数、環境内で実行される DAG とタスクの数、Airflow と環境の両方の構成によって異なります。

      2 つのスケジューラを設定した状態で開始し、環境のパフォーマンスをモニタリングすることをおすすめします。スケジューラの数を変更する場合は、いつでも環境を元のスケジューラ数にスケールダウンできます。

      複数のスケジューラの構成の詳細については、Airflow のドキュメントをご覧ください。

    • Airflow トリガー。環境内のすべての遅延タスクを非同期でモニタリングします。環境内に少なくとも 1 つの triggerer インスタンス（または高復元環境では少なくとも 2 つ）がある場合は、DAG で遅延可能な演算子を使用できます。

    • Airflow ウェブサーバー。Airflow ウェブ インターフェースを実行します。このインターフェースでは、DAG をモニタリング、管理、表示できます。

    • Airflow ワーカー。Airflow スケジューラによってスケジュールされたタスクを実行します。環境内のワーカーの最小数と最大数は、キュー内のタスクの数に応じて動的に変化します。

コンソール

環境のプリセットは、選択できます。プリセットを選択すると、そのプリセットのスケーリングとパフォーマンスのパラメータが自動的に選択されます。カスタム プリセットを選択して、環境のすべてのスケーリングとパフォーマンスのパラメータを指定することもできます。

環境のスケールとパフォーマンス構成を選択するには、[環境の作成] ページで次の操作を行います。

  • 事前定義された値を使用するには、[環境リソース] セクションで [小]、[中]、または [大] をクリックします。

  • スケーリングとパフォーマンスのパラメータにカスタム値を指定するには、次のようにします。

    1. [環境リソース] セクションで [カスタム] をクリックします。

    2. [スケジューラ] セクションで、使用するスケジューラの数と、CPU、メモリ、ストレージのリソース割り当てを設定します。

    3. [triggerer] セクションで、[triggerer の数] フィールドを使用して、環境内の triggerer の数を入力します。DAG で遅延可能な演算子を使用しない場合は、この数を 0 に設定できます。

      環境に少なくとも 1 つの triggerer を設定する場合は、[CPU] フィールドと [メモリ] フィールドを使用して、triggerer のリソース割り当てを構成します。

    4. [DAG プロセッサ] セクションで、環境内の DAG プロセッサの数と、各 DAG プロセッサの CPU、メモリ、ストレージの容量を指定します。

    5. [ウェブサーバー] セクションで、ウェブサーバーの CPU、メモリ、ストレージの量を指定します。

    6. [ワーカー] セクションで、次を指定します。

      • 環境の自動スケーリングの制限で使用されるワーカーの最小数と最大数。
      • ワーカーの CPU、メモリ、ストレージの割り当て

    7. [コア インフラストラクチャ] セクションの [環境サイズ] プルダウン リストで、環境のサイズを選択します。

gcloud

環境を作成する際、環境のスケーリング パラメータとパフォーマンス パラメータは、次の引数により制御されます。

  • --environment-size では、環境のサイズを指定します。
  • --scheduler-count では、スケジューラの数を指定します。
  • --scheduler-cpu では、Airflow スケジューラの CPU の数を指定します。
  • --scheduler-memory では、Airflow スケジューラのメモリ容量を指定します。

  • --scheduler-storage では、Airflow スケジューラのディスク容量を指定します。

  • --triggerer-count は、環境内の Airflow triggerer の数を指定します。このパラメータのデフォルト値は 0 です。DAG で遅延可能な演算子を使用する場合は、triggerer が必要です。

    • 標準復元力の環境では、0～10 の値を使用します。
    • 復元力の高い環境の場合、0 または 2～10 の値を使用します。

  • --triggerer-cpu では、Airflow triggerer の CPU 数を vCPU 単位で指定します。使用できる値: 0.5、0.75、1。デフォルト値は 0.5 です。

  • --triggerer-memory では、Airflow triggerer のメモリ容量を GB 単位で指定します。デフォルト値は 0.5 です。

    必要な最小メモリは、triggerer に割り当てられた CPU 数と同じです。最大許容値は、triggerer CPU 数に 6.5 を掛けた数と同じです。

    たとえば、--triggerer-cpu フラグを 1 に設定した場合、--triggerer-memory の 最小値 は 1 で、最大値 は 6.5 です。

  • --web-server-cpu では、Airflow ウェブサーバーの CPU 数を指定します。

  • --web-server-memory では、Airflow ウェブサーバーのメモリ容量を指定します。

  • --web-server-storage では、Airflow ウェブサーバーのディスク容量を指定します。

  • --worker-cpu では、Airflow ワーカーの CPU 数を指定します。

  • --worker-memory では、Airflow ワーカーのメモリ容量を指定します。

  • --worker-storage では、Airflow ワーカーのディスク容量を指定します。

  • --min-workers では、Airflow ワーカーの最小数を指定します。環境のクラスタでは、少なくともこの数のワーカーが実行されます。

  • --max-workers では Airflow ワーカーの最大数を指定します。環境のクラスタでは、最大この数のワーカーが実行されます。

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --environment-size ENVIRONMENT_SIZE \
    --scheduler-count SCHEDULER_COUNT \
    --scheduler-cpu SCHEDULER_CPU \
    --scheduler-memory SCHEDULER_MEMORY \
    --scheduler-storage SCHEDULER_STORAGE \
    --triggerer-count TRIGGERER_COUNT \
    --triggerer-cpu TRIGGERER_CPU \
    --triggerer-memory TRIGGERER_MEMORY \
    --web-server-cpu WEB_SERVER_CPU \
    --web-server-memory WEB_SERVER_MEMORY \
    --web-server-storage WEB_SERVER_STORAGE \
    --worker-cpu WORKER_CPU \
    --worker-memory WORKER_MEMORY \
    --worker-storage WORKER_STORAGE \
    --min-workers WORKERS_MIN \
    --max-workers WORKERS_MAX

以下のように置き換えます。

  • ENVIRONMENT_SIZE は small、medium、または large に置き換えます。
  • SCHEDULER_COUNT は、スケジューラの数に置き換えます。
  • SCHEDULER_CPU は、スケジューラの CPU 数（vCPU 単位）に置き換えます。
  • SCHEDULER_MEMORY は、スケジューラのメモリ容量に置き換えます。
  • SCHEDULER_STORAGE は、スケジューラのディスクサイズに置き換えます。
  • TRIGGERER_COUNT は、トリガーの数に置き換えます。
  • TRIGGERER_CPU は、スケジューラの CPU 数（vCPU 単位）に置き換えます。

  • TRIGGERER_MEMORY は、ワーカーのメモリ容量（GB）に置き換えます。

  • WEB_SERVER_CPU は、ウェブサーバーの CPU 数（vCPU 単位）に置き換えます。

  • WEB_SERVER_MEMORY は、ウェブサーバーのメモリ容量に置き換えます。

  • WEB_SERVER_STORAGE は、ウェブサーバーのメモリ容量に置き換えます。

  • WORKER_CPU は、ワーカーの CPU 数（vCPU 単位）に置き換えます。

  • WORKER_MEMORY は、ワーカーのメモリ容量に置き換えます。

  • WORKER_STORAGE は、ワーカーのディスクサイズに置き換えます。

  • WORKERS_MIN は、環境で実行できる Airflow ワーカーの最大数に置き換えます。環境内のワーカー数は、より少ないワーカー数で負荷を処理できる場合でもこの数を下回りません。

  • WORKERS_MAX は、環境で実行できる Airflow ワーカーの最大数に置き換えます。環境内のワーカー数は、負荷に対処するためにさらに多くのワーカー数が必要な場合でも、この数を超えることはありません。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --environment-size small \
    --scheduler-count 1 \
    --scheduler-cpu 0.5 \
    --scheduler-memory 2.5GB \
    --scheduler-storage 2GB \
    --triggerer-count 1 \
    --triggerer-cpu 0.5 \
    --triggerer-memory 0.5GB \
    --web-server-cpu 1 \
    --web-server-memory 2.5GB \
    --web-server-storage 2GB \
    --worker-cpu 1 \
    --worker-memory 2GB \
    --worker-storage 2GB \
    --min-workers 2 \
    --max-workers 4

API

環境を作成するときに、[Environment] > [EnvironmentConfig] > [WorkloadsConfig] リソースで、環境のスケーリングとパフォーマンスのパラメータを指定します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "workloadsConfig": {
      "scheduler": {
        "cpu": SCHEDULER_CPU,
        "memoryGb": SCHEDULER_MEMORY,
        "storageGb": SCHEDULER_STORAGE,
        "count": SCHEDULER_COUNT
      },
      "triggerer": {
        "count": TRIGGERER_COUNT,
        "cpu": TRIGGERER_CPU,
        "memoryGb": TRIGGERER_MEMORY
      },
      "webServer": {
        "cpu": WEB_SERVER_CPU,
        "memoryGb": WEB_SERVER_MEMORY,
        "storageGb": WEB_SERVER_STORAGE
      },
      "worker": {
        "cpu": WORKER_CPU,
        "memoryGb": WORKER_MEMORY,
        "storageGb": WORKER_STORAGE,
        "minCount": WORKERS_MIN,
        "maxCount": WORKERS_MAX
      }
    },
    "environmentSize": "ENVIRONMENT_SIZE",
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • SCHEDULER_CPU は、スケジューラの CPU 数（vCPU 単位）に置き換えます。
  • SCHEDULER_MEMORY は、スケジューラのメモリ容量（GB）に置き換えます。
  • SCHEDULER_STORAGE は、スケジューラのディスクサイズ（GB）に置き換えます。

  • SCHEDULER_COUNT は、スケジューラの数に置き換えます。

  • TRIGGERER_COUNT は、トリガーの数に置き換えます。デフォルト値は 0 です。DAG で遅延可能な演算子を使用する場合は、triggerer が必要です。

    • 標準復元力の環境では、0～10 の値を使用します。
    • 復元力の高い環境の場合、0 または 2～10 の値を使用します。

    triggerer を少なくとも 1 つ使用する場合は、TRIGGERER_CPU パラメータと TRIGGERER_MEMORY パラメータも指定する必要があります。

  • TRIGGERER_CPU は、triggerer の CPU 数（vCPU 単位）を指定します。使用できる値: 0.5、0.75、1。

  • TRIGGERER_MEMORY は、triggerer のメモリ容量を構成します。必要な最小メモリは、triggerer に割り当てられた CPU 数と同じです。最大許容値は、triggerer CPU 数に 6.5 を掛けた数と同じです。

    たとえば、TRIGGERER_CPU を 1 に設定した場合、TRIGGERER_MEMORY の 最小値 は 1 で、最大値 は 6.5 です。

  • WEB_SERVER_CPU は、ウェブサーバーの CPU 数（vCPU 単位）に置き換えます。

  • WEB_SERVER_MEMORY は、ウェブサーバーのメモリ容量（GB）に置き換えます。

  • WEB_SERVER_STORAGE は、ウェブサーバーのディスクサイズ（GB）に置き換えます。

  • WORKER_CPU は、ワーカーの CPU 数（vCPU 単位）に置き換えます。

  • WORKER_MEMORY は、ワーカーのメモリ容量（GB）に置き換えます。

  • WORKER_STORAGE は、ワーカーのディスクサイズ（GB）に置き換えます。

  • WORKERS_MIN は、環境で実行できる Airflow ワーカーの最大数に置き換えます。環境内のワーカー数は、より少ないワーカー数で負荷を処理できる場合でもこの数を下回りません。

  • WORKERS_MAX は、環境で実行できる Airflow ワーカーの最大数に置き換えます。環境内のワーカー数は、負荷に対処するためにさらに多くのワーカー数が必要な場合でも、この数を超えることはありません。

  • ENVIRONMENT_SIZE は、環境のサイズ、ENVIRONMENT_SIZE_SMALL、ENVIRONMENT_SIZE_MEDIUM、または ENVIRONMENT_SIZE_LARGE に置き換えます。

例:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "workloadsConfig": {
      "scheduler": {
        "cpu": 2.5,
        "memoryGb": 2.5,
        "storageGb": 2,
        "count": 1
      },
      "triggerer": {
        "cpu": 0.5,
        "memoryGb": 0.5,
        "count": 1
      },
      "webServer": {
        "cpu": 1,
        "memoryGb": 2.5,
        "storageGb": 2
      },
      "worker": {
        "cpu": 1,
        "memoryGb": 2,
        "storageGb": 2,
        "minCount": 2,
        "maxCount": 4
      }
    },
    "environmentSize": "ENVIRONMENT_SIZE_SMALL",
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

環境を作成する際、環境のスケーリング パラメータとパフォーマンス パラメータは、次の引数により制御されます。

  • config ブロックでは:

    • environment_size フィールドでは、環境サイズを制御します。

  • workloads_config ブロックでは:

    • scheduler.cpu フィールドでは、Airflow スケジューラの CPU の数を指定します。
    • scheduler.memory_gb フィールドでは、Airflow スケジューラのメモリ容量を指定します。
    • scheduler.storage_gb フィールドでは、スケジューラのディスク容量を指定します。
    • scheduler.count フィールドでは、環境内のスケジューラの数を指定します。
    • triggerer.cpu フィールドでは、Airflow トリガーの CPU 数を指定します。
    • triggerer.memory_gb フィールドでは、Airflow トリガーのメモリ容量を指定します。

    • triggerer.count フィールドでは、環境内のトリガーの数を指定します。

    • web_server.cpu フィールドでは、Airflow ウェブサーバーの CPU 数を指定します。

    • web_server.memory_gb フィールドでは、Airflow ウェブサーバーのメモリ容量を指定します。

    • web_server.storage_gb フィールドでは、Airflow ウェブサーバーのディスク容量を指定します。

    • worker.cpu フィールドでは、Airflow ワーカーの CPU 数を指定します。

    • worker.memory_gb フィールドでは、Airflow ワーカーのメモリ容量を指定します。

    • worker.storage_gb フィールドでは、Airflow ワーカーのディスク容量を指定します。

    • worker.min_count フィールドでは、環境内のワーカーの最小数を指定します。

    • worker.max_count フィールドでは、環境内のワーカーの最大数を指定します。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    workloads_config {

      scheduler {
        cpu = SCHEDULER_CPU
        memory_gb = SCHEDULER_MEMORY
        storage_gb = SCHEDULER_STORAGE
        count = SCHEDULER_COUNT
      }
      triggerer {
        count = TRIGGERER_COUNT
        cpu = TRIGGERER_CPU
        memory_gb = TRIGGERER_MEMORY
      }
      web_server {
        cpu = WEB_SERVER_CPU
        memory_gb = WEB_SERVER_MEMORY
        storage_gb = WEB_SERVER_STORAGE
      }
      worker {
        cpu = WORKER_CPU
        memory_gb = WORKER_MEMORY
        storage_gb = WORKER_STORAGE
        min_count = WORKERS_MIN
        max_count = WORKERS_MAX
      }
    }

    environment_size = "ENVIRONMENT_SIZE"

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • ENVIRONMENT_NAME を環境の名前に置き換えます。
  • LOCATION は、環境が配置されているリージョン。
  • SERVICE_ACCOUNT は、環境のサービス アカウントに置き換えます。
  • SCHEDULER_CPU は、スケジューラの CPU 数（vCPU 単位）に置き換えます。
  • SCHEDULER_MEMORY は、スケジューラのメモリ容量（GB）に置き換えます。
  • SCHEDULER_STORAGE は、スケジューラのディスクサイズ（GB）に置き換えます。
  • SCHEDULER_COUNT は、スケジューラの数に置き換えます。
  • TRIGGERER_COUNT は、トリガーの数に置き換えます。
  • TRIGGERER_CPU は、スケジューラの CPU 数（vCPU 単位）に置き換えます。
  • TRIGGERER_MEMORY は、ワーカーのメモリ容量（GB）に置き換えます。
  • WEB_SERVER_CPU は、ウェブサーバーの CPU 数（vCPU 単位）に置き換えます。
  • WEB_SERVER_MEMORY は、ウェブサーバーのメモリ容量（GB）に置き換えます。
  • WEB_SERVER_STORAGE は、ウェブサーバーのディスクサイズ（GB）に置き換えます。
  • WORKER_CPU は、ワーカーの CPU 数（vCPU 単位）に置き換えます。
  • WORKER_MEMORY は、ワーカーのメモリ容量（GB）に置き換えます。
  • WORKER_STORAGE は、ワーカーのディスクサイズ（GB）に置き換えます。
  • WORKERS_MIN は、環境で実行できる Airflow ワーカーの最大数に置き換えます。環境内のワーカー数は、より少ないワーカー数で負荷を処理できる場合でもこの数を下回りません。
  • WORKERS_MAX は、環境で実行できる Airflow ワーカーの最大数に置き換えます。環境内のワーカー数は、負荷に対処するためにさらに多くのワーカー数が必要な場合でも、この数を超えることはありません。
  • ENVIRONMENT_SIZE は、環境のサイズ、ENVIRONMENT_SIZE_SMALL、ENVIRONMENT_SIZE_MEDIUM、または ENVIRONMENT_SIZE_LARGE に置き換えます。

例:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    workloads_config {

      scheduler {
        cpu = 2.5
        memory_gb = 2.5
        storage_gb = 2
        count = 1
      }
      triggerer {
        count = 1
        cpu = 0.5
        memory_gb = 0.5
      }
      web_server {
        cpu = 1
        memory_gb = 2.5
        storage_gb = 2
      }
      worker {
        cpu = 1
        memory_gb = 2
        storage_gb = 2
        min_count = 2
        max_count = 4
      }
    }

    environment_size = "ENVIRONMENT_SIZE_SMALL"

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }

  }
}

ステップ 5. （省略可）高復元モードを有効にする

復元性に優れた Cloud Composer 環境は、組み込みの冗長性と、ゾーン障害や単一障害点の停止に対する環境の脆弱性を軽減するフェイルオーバー メカニズムを使用する環境です。

復元性に優れた環境は、選択したリージョンの少なくとも 2 つのゾーンで実行されます。2 つの Airflow スケジューラ、2 つのウェブサーバー、少なくとも 2 つの triggerer（triggerer の数が 0 に設定されていない場合）が別々のゾーンで実行されます。 ワーカーの最小数は 2 に設定され、環境のクラスタはワーカー インスタンスをゾーン間で分散します。ゾーンが停止した場合、影響を受けたワーカー インスタンスが別のゾーンで再スケジュールされます。復元力の高い環境の　Cloud SQL　データベースは、プライマリ インスタンスとスタンバイ インスタンスを持つリージョン インスタンスです。

コンソール

[環境の作成] ページで次の操作を行います。

  1. [復元力モード] セクションで、[高復元性] を選択します。

  2. [環境リソース] セクションで、復元性に優れた環境のスケール パラメータを選択します。復元性に優れた環境では、2 つのスケジューラ、0 または 2～10 個のトリガー、2 個以上のワーカーが必要です。

    1. [Custom] をクリックします。

    2. [スケジューラの数] プルダウン リストで、[2] を選択します。

    3. [トリガラーの数] プルダウン リストで、0 または 2～10 の値を選択します。triggerer の [CPU] と [メモリ] の割り当てを構成します。

    4. [ワーカーの最小数] プルダウン リストで、必要なワーカー数に応じて 2 以上を選択します。

  3. [ネットワークの構成] セクションで、次の操作を行います。

    1. [ネットワークの種類] で、[プライベート IP 環境] を選択します。

    2. 必要に応じて、他のネットワーク パラメータを指定します。

gcloud

環境を作成するときに、--enable-high-resilience 引数によって高復元性モードが有効になります。

次の引数を設定します。

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-high-resilience \
    --enable-private-environment \
    --scheduler-count 2 \
    --triggerer-count 2 \
    --triggerer-cpu 0.5 \
    --triggerer-memory 0.5 \
    --min-workers 2

API

環境を作成するときに、[Environment] > > [EnvironmentConfig] リソースで高い復元力モードを有効にします。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "resilience_mode": "HIGH_RESILIENCE",
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }

  }
}

例:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "resilience_mode": "HIGH_RESILIENCE",
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }

  }
}

Terraform

環境を作成するときに、config　ブロックの resilience_mode フィールドは高復元力モードを有効にします。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    resilience_mode = "HIGH_RESILIENCE"

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }

  }
}

例:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    resilience_mode = "HIGH_RESILIENCE"

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

ステップ 6. （省略可）環境のデータベースのゾーンを指定する

標準レジリエンス環境の作成時に、優先する　Cloud SQL ゾーンを指定することができます。

コンソール

[環境の作成] ページで次の操作を行います。

  1. [詳細設定] セクションで、[詳細設定を表示] 項目を展開します。

  2. [Airflow データベース ゾーン] リストで、優先 Cloud SQL ゾーンを選択します。

gcloud

環境を作成するときに、--cloud-sql-preferred-zone 引数は優先 Cloud SQL ゾーンを指定します。

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --cloud-sql-preferred-zone SQL_ZONE

以下を置き換えます。

  • SQL_ZONE: 優先する Cloud SQL ゾーン。このゾーンは、環境が配置されているリージョン内に配置する必要があります。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --cloud-sql-preferred-zone us-central1-a

API

環境を作成するときに、[Environment] > [DatabaseConfig] リソースで、優先 Cloud SQL ゾーンを指定します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "databaseConfig": {
      "zone": "SQL_ZONE"
    },
      "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

以下を置き換えます。

  • SQL_ZONE: 優先する Cloud SQL ゾーン。このゾーンは、環境が配置されているリージョン内に配置する必要があります。

例:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "databaseConfig": {
      "zone": "us-central1-a"
    },
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

環境を作成するときに、database_config ブロックの zone フィールドは優先 Cloud SQL ゾーンを指定します。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    database_config {
      zone = "SQL_ZONE"
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

以下を置き換えます。

  • SQL_ZONE: 優先する Cloud SQL ゾーン。このゾーンは、環境が配置されているリージョン内に配置する必要があります。

ステップ 7. （省略可）環境のネットワーキングを構成する

ネットワーキング パラメータは、作成する環境の種類によって異なります。

  • パブリック IP 環境。デフォルトのネットワーク パラメータを使用します。

  • プライベート IP 環境（PSC 使用）。この構成では、環境で Private Service Connect を使用して接続します。

    プライベート IP 環境を構成します。

    1. プロジェクトのネットワークをプライベート IP 環境用に構成する。
    2. 環境を作成するときに Private Service Connect を構成します。
    3. プライベート IP 環境の他のパラメータを指定します。詳細については、このセクションをご覧ください。

    PSC を使用するプライベート IP 環境の場合、次の点に注意してください。

    • VPC ネットワーク ID
    • VPC サブネットワーク ID

    • VPC サブネットワーク内の 2 つのセカンダリ IP 範囲:

      • Pod のセカンダリ IP 範囲
      • Service のセカンダリ IP 範囲

    • 環境のコンポーネント用の IP 範囲:

      • GKE コントロール プレーンの IP 範囲。GKE コントロール プレーン用の IP 範囲。
      • Cloud Composer 接続サブネットワーク。Cloud Composer 接続サブネットワークの IP 範囲。

  • プライベート IP 環境（VPC ピアリング）。この構成では、環境で VPC ピアリングを使用して接続を行います。

    プライベート IP 環境を構成します。

    1. プロジェクトのネットワークをプライベート IP 環境用に構成する。
    2. このセクションで詳細に説明するように、プライベート IP 環境用のその他のパラメータを指定します。

    VPC ピアリングを使用するプライベート IP 環境の場合、次のことを確認する必要があります。

    • VPC ネットワーク ID
    • VPC サブネットワーク ID

    • VPC サブネットワーク内の 2 つのセカンダリ IP 範囲:

      • Pod のセカンダリ IP 範囲
      • Service のセカンダリ IP 範囲

    • 環境のコンポーネント用の IP 範囲:

      • GKE コントロール プレーン用の IP 範囲。

      • 内部 Cloud Composer ネットワークから選択したネットワークにエクスポートする VPC ピアリングの IP 範囲。Composer インフラストラクチャ コンポーネントは、この範囲の IP アドレスを使用します。

      • Cloud SQL インスタンス用の IP 範囲。

  • 共有 VPC 環境の場合は、ホスト プロジェクトに対して追加のネットワークを設定してから、サービス プロジェクトにパブリック IP 環境またはプライベート IP 環境を作成する必要があります。共有 VPC の構成ページの手順に沿って行います。

    共有 VPC 環境の場合は、次のことを確認する必要があります。

    • ホスト プロジェクトの VPC ネットワーク ID

    • ホスト プロジェクトの VPC サブネットワーク ID

    • ホスト プロジェクトの VPC サブネットワーク内の 2 つのセカンダリ IP 範囲:

      • Pod のセカンダリ IP 範囲
      • Service のセカンダリ IP 範囲

    パブリック IP 共有 VPC 環境を作成する場合は、引き続き Pod とサービスのホスト プロジェクトの VPC ネットワーク、サブネットワーク、セカンダリ IP 範囲を指定する必要があります。

  • VPC SC 環境を作成するにはサービス境界を作成してから、境界内に環境を作成する必要があります。VPC Service Controls の構成に概要を記載している手順に沿って操作してください。

環境に対する追加のネットワーキング オプションは、次のとおりです。

  • プライベートで利用されるパブリック IP アドレス。より多くの IP アドレスを使用する場合、環境では、Pod と Service の内部サブネット IP アドレス範囲として、特定のパブリック IP アドレス範囲をプライベートで使用できます。
  • 承認済みネットワーク。HTTPS を使用してプライベート IP 環境のコントロール プレーンにアクセスする場合は、使用可能な承認済みネットワークによって CIDR 範囲を指定します。
  • IP マスカレード エージェント。IP マスカレード エージェントで環境を使用することにより、環境のネットワーキング構成で多対一の IP アドレス変換を使用できます。IP マスカレード エージェントを使用した環境の作成に関する詳細は、IP マスカレード エージェントを有効にするをご覧ください。

コンソール

プライベート IP 環境を作成するには、次のようにします。

  1. ネットワーキングは、作成する環境の種類に応じて構成する必要があります。

  2. [ネットワークの構成] セクションで、[ネットワーク構成を表示] 項目を展開します。

  3. [ネットワーク] プルダウン リストで、VPC ネットワーク ID を選択します。

  4. [サブネットワーク] プルダウン リストで、VPC サブネットワーク ID を選択します。

  5. [Pod のセカンダリ IP 範囲] セクションで、Pod のセカンダリ IP 範囲を選択または指定します。VPC ネットワーク内の既存のセカンダリ範囲を使用することも、自動作成範囲を使用することもできます。

  6. [サービスのセカンダリ IP 範囲] セクションで、サービスのセカンダリ IP 範囲を選択します。VPC ネットワーク内の既存のセカンダリ範囲を使用することも、自動作成範囲を使用することもできます。

  7. [ネットワークの種類] セクションで、[Private IP environment] オプションを選択してプライベート IP 環境を作成します。

  8. [Composer の接続] セクションで、環境のネットワーク タイプを選択し、環境コンポーネントの IP 範囲を指定します。

    Private Service Connect を使用する環境の場合:

    1. Private Service Connect を使用する環境の場合は、[Private Service Connect] を選択します。

    2. [Composer 接続のサブネットワーク] セクションで、Cloud Composer 接続サブネットワークの IP 範囲を指定します。PSC エンドポイントのアドレスは、この範囲から選択されます。カスタム範囲を指定するか、デフォルトの範囲を選択できます。

    VPC ピアリングを使用する環境の場合:

    1. VPC ピアリングを使用する環境の場合は、[VPC ピアリング] を選択します。

    2. [Composer テナント ネットワークの IP 範囲] セクションで、Cloud Composer テナント ネットワークの IP 範囲を指定します。このネットワークによって、環境の SQL プロキシ コンポーネントがホストされます。カスタム範囲を指定するか、デフォルトの範囲を選択できます。

    3. [Cloud SQL ネットワークの IP 範囲] で、Cloud SQL インスタンスの IP 範囲を指定します。カスタム範囲を指定するか、デフォルトの範囲を選択できます。

  9. [GKE コントロール プレーン ネットワークの IP 範囲] セクションで、GKE コントロール プレーンの IP 範囲を指定します。

    • 環境が配置されているリージョンにデフォルトの IP 範囲を使用するには、[デフォルトの IP 範囲] を選択します。

    • カスタム IP 範囲を指定するには、[カスタム IP 範囲] を選択して、[GKE クラスタ マスターのプライベート IP] フィールドに CIDR 表記で範囲を入力します。

  10. GKE コントロール プレーンのレベルアクセスを選択します。コントロール プレーンには、エンドポイントが 2 つあります。一方のエンドポイントは限定公開で、クラスタノードと VM が使用します。別のエンドポイントがパブリックである。パブリック エンドポイントのアクセスレベルは、指定できます。

    • 承認済みネットワークからパブリック エンドポイントへのアクセスを有効にするには、[外部 IP アドレスを使用してクラスタ コントロール プレーン エンドポイントにアクセス] のチェックボックスをオンにします。

      このオプションを使用すると、コントロール プレーンのアクセスレベルが「パブリック エンドポイント アクセスが有効、承認済みネットワークが有効」に設定されます。これにより、承認済みネットワークからコントロール プレーンへのアクセスが制限されます。デフォルトでは、送信元 IP アドレスは指定されません。承認済みネットワークをクラスタに追加できます。

    • 承認済みネットワークからパブリック エンドポイントへのアクセスを無効にするには、[外部 IP アドレスを使用してクラスタ コントロール プレーン エンドポイントにアクセス] のチェックボックスをオフにします。

      このオプションを使用すると、コントロール プレーンのアクセスレベルが「パブリック エンドポイント アクセスが無効」に設定されます。これにより、コントロール プレーンへのすべてのインターネット アクセスが阻止されます。

gcloud

ネットワーキングは、作成する環境の種類に応じて構成する必要があります。

環境を作成する際、次の引数によりネットワーク パラメータが制御されます。パラメータを省略すると、デフォルト値が使用されます。

  • --enable-private-environment は、プライベート IP 環境を有効にします。

  • --network は、VPC ネットワーク ID を指定します。

  • --subnetwork は、VPC サブネットワーク ID を指定します。

  • --cluster-secondary-range-name または --cluster-ipv4-cidr は、Pod のセカンダリ範囲を構成します。

  • --services-secondary-range-name または --services-ipv4-cidr を使用して、Service のセカンダリ範囲を構成します。

  • --master-ipv4-cidr は、GKE コントロール プレーンの範囲を指定します。

  • （PSC を使用する環境） --connection-subnetwork では、PSC エンドポイントをホストする Cloud Composer 接続サブネットワークの範囲を指定します。

  • （VPC ピアリングを使用する環境）--composer-network-ipv4-cidr では、Cloud Composer テナント ネットワークの範囲を指定します。このネットワークによって、環境の SQL プロキシ コンポーネントがホストされます。

  • （VPC ピアリングを使用する環境） --cloud-sql-ipv4-cidr では、Cloud SQL インスタンスの範囲を指定します。

  • --enable-private-endpoint は、GKE コントロール プレーンのレベルアクセスを制御します。コントロール プレーンには、エンドポイントが 2 つあります。一方のエンドポイントは限定公開で、クラスタノードと VM が使用します。別のエンドポイントがパブリックである。パブリック エンドポイントのアクセスレベルは、指定できます。

    • 承認済みネットワークからパブリック エンドポイントへのアクセスを有効にするには、--enable-private-endpoint 引数を省略します。

      このオプションを使用すると、コントロール プレーンのアクセスレベルが「パブリック エンドポイント アクセスが有効、承認済みネットワークが有効」に設定されます。これにより、承認済みネットワークからコントロール プレーンへのアクセスが制限されます。デフォルトでは、送信元 IP アドレスは指定されません。承認済みネットワークをクラスタに追加できます。

    • 承認済みネットワークからパブリック エンドポイントへのアクセスを無効にするには、--enable-private-endpoint 引数を指定します。

      このオプションを使用すると、コントロール プレーンのアクセスレベルが「パブリック エンドポイント アクセスが無効」に設定されます。これにより、コントロール プレーンへのすべてのインターネット アクセスが阻止されます。

  • --enable-master-authorized-networks 引数と --master-authorized-networks 引数は、ご使用の環境の承認済みネットワークを構成します。

  • --enable-privately-used-public-ips は、ご使用の環境のプライベートで使用されるパブリック IP アドレスを構成します。

  • --enable-ip-masq-agent は、IP マスカレード エージェントを有効にします。

例（プライベート IP 環境）

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-private-environment \
    --network NETWORK_ID \
    --subnetwork SUBNETWORK_ID \
    --cluster-ipv4-cidr PODS_RANGE \
    --services-ipv4-cidr SERVICES_RANGE \
    --master-ipv4-cidr CONTROL_PLANE_RANGE \
    --connection-subnetwork COMPOSER_PSC_RANGE \

以下のように置き換えます。

  • NETWORK_ID は、VPC ネットワーク ID に置き換えます。

  • SUBNETWORK_ID は、VPC サブネットワーク ID に置き換えます。

  • PODS_RANGE は、Pod のセカンダリ範囲に置き換えます。

  • SERVICES_RANGE は、サービスのセカンダリ範囲に置き換えます。

  • CONTROL_PLANE_RANGE は、GKE コントロール プレーンのセカンダリ範囲に置き換えます。

  • COMPOSER_PSC_RANGE は、Cloud Composer 接続サブネットワークの範囲に置き換えます。

手順 8. （省略可）ネットワーク タグを追加する

ネットワーク タグは、環境のクラスタ内のすべてのノード VM に適用されます。タグは、ネットワーク ファイアウォールの有効なソースやターゲットを識別するために使用されます。リスト内の各タグは、RFC 1035 に準拠している必要があります。

たとえば、ファイアウォール ルールでプライベート IP 環境のトラフィックを制限する予定がある場合は、ネットワーク タグを追加するとよいかもしれません。

コンソール

[環境の作成] ページで次の操作を行います。

  1. [ネットワークの構成] セクションを見つけます。
  2. [ネットワーク タグ] フィールドに、使用中の環境のネットワーク タグを入力します。

gcloud

環境を作成する際は、次の引数を使用してネットワーク タグを制御します。

  • --tags は、すべてのノード VM に適用されるネットワーク タグのカンマ区切りのリストを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --tags TAGS

以下のように置き換えます。

  • TAGS は、ネットワーク タグのカンマ区切りのリストに置き換えます。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --tags group1,production

API

環境を作成するときに、[Environment] > [EnvironmentConfig] リソースで環境のネットワーク タグを指定します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "nodeConfig": {
      "tags": [
        "TAG"
      ],
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • TAG は、ネットワーク タグに置き換えます。

例:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "nodeConfig": {
      "tags": [
        "group1",
        "production"
      ],
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

環境を作成する際は、次のフィールドで環境のネットワーク タグを定義します。

  • node_config ブロックの tags フィールドは、すべてのノード VM に適用されるネットワーク タグのカンマ区切りのリストを指定します。
resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    node_config {
      tags = ["TAGS"]
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • TAGS は、ネットワーク タグのカンマ区切りのリストに置き換えます。

例:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    node_config {
      tags = ["group1","production"]
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

手順 9. （省略可）ウェブサーバーへのネットワーク アクセスを構成する

Airflow ウェブサーバーのアクセス パラメータは、環境の種類に依存しません。代わりに、ウェブサーバーのアクセスを個別に構成できます。たとえば、プライベート IP 環境で、引き続きインターネットから Airflow UI にアクセスできます。

プライベート IP アドレスを使用して許可された IP 範囲を構成することはできません。

コンソール

[環境の作成] ページで次の操作を行います。

  1. [ネットワークの構成] セクションで、[ネットワーク構成を表示] 項目を展開します。

  2. [ウェブサーバーのネットワーク アクセス制御] セクションで、次の操作を行います。

    • すべての IP アドレスから Airflow ウェブサーバーへのアクセスを許可するには、[すべての IP アドレスからのアクセスを許可する] を選択します。

    • アクセスを特定の IP 範囲のみに制限するには、[特定の IP アドレスからのアクセスのみを許可する] を選択します。[IP 範囲] フィールドに、CIDR 表記の IP 範囲を指定します。[説明] フィールドに、この範囲の説明を入力します（省略可）。複数の範囲を指定する場合は、[IP 範囲の追加] をクリックします。

    • すべての IP アドレスのアクセスを禁止するには、[特定の IP アドレスからのアクセスのみを許可する] を選択し、空の範囲エントリの横にある [項目を削除する] をクリックします。

gcloud

ウェブサーバーのアクセスレベルは、環境を作成するとき、次の引数で制御します。

  • --web-server-allow-all を使用すると、すべての IP アドレスから Airflow にアクセスできます。これはデフォルトのオプションです。

  • --web-server-allow-ip は、特定のソース IP 範囲へのアクセスのみを制限します。複数の IP 範囲を指定するには、この引数を複数回使用します。

  • --web-server-deny-all は、すべての IP アドレスに対してアクセスを禁止します。

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --web-server-allow-ip ip_range=WS_IP_RANGE,description=WS_RANGE_DESCRIPTION

以下のように置き換えます。

  • WS_IP_RANGE は、Airflow UI にアクセスできる IP 範囲（CIDR 表記）に置き換えます。
  • WS_RANGE_DESCRIPTION は、IP 範囲の説明に置き換えます。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --web-server-allow-ip ip_range=192.0.2.0/24,description="office net 1" \
    --web-server-allow-ip ip_range=192.0.4.0/24,description="office net 3"

API

環境を作成するときに、[Environment] > [EnvironmentConfig] リソースでウェブサーバー アクセス パラメータを指定します。

  • すべての IP アドレスから Airflow のウェブサーバーにアクセスできるようにするには、webServerNetworkAccessControl を省略します。

  • アクセスを特定の IP 範囲に制限するには、allowedIpRanges で 1 つ以上の範囲を指定します。

  • すべての IP アドレスに対するアクセスを禁止するには、allowedIpRanges を追加して空のリストにします。IP 範囲を指定しないでください。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "webServerNetworkAccessControl": {
      "allowedIpRanges": [
        {
          "value": "WS_IP_RANGE",
          "description": "WS_RANGE_DESCRIPTION"
        }
      ]
    },
      "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • WS_IP_RANGE は、Airflow UI にアクセスできる IP 範囲（CIDR 表記）に置き換えます。
  • WS_RANGE_DESCRIPTION は、IP 範囲の説明に置き換えます。

例:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "webServerNetworkAccessControl": {
      "allowedIpRanges": [
        {
          "value": "192.0.2.0/24",
          "description": "office net 1"
        },
        {
          "value": "192.0.4.0/24",
          "description": "office net 3"
        }
      ]
    },
      "nodeConfig": {
        "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

ウェブサーバーにアクセスできる IP 範囲は、環境を作成するとき、web_server_network_access_control ブロックの allowed_ip_range ブロックに含めます。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    web_server_network_access_control {

      allowed_ip_range {
        value = "WS_IP_RANGE"
        description = "WS_RANGE_DESCRIPTION"
      }
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • WS_IP_RANGE は、Airflow UI にアクセスできる IP 範囲（CIDR 表記）に置き換えます。
  • WS_RANGE_DESCRIPTION は、IP 範囲の説明に置き換えます。

例:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    web_server_network_access_control {
      allowed_ip_range {
        value = "192.0.2.0/24"
        description = "office net 1"
      },
      allowed_ip_range {
        value = "192.0.4.0/24"
        description = "office net 3"
      }
    }

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }

}

手順 10. （省略可）Airflow 構成のオーバーライドと環境変数を指定する

Airflow 構成のオーバーライドと環境変数は、環境を作成するときに設定できます。あるいは、環境を作成した後に行うこともできます。

一部の Airflow 構成オプションはブロックされているため、オーバーライドすることはできません。

使用可能な Airflow 構成オプションの一覧については、Airflow 2 の構成リファレンスと Airflow 1.10.* をご覧ください。

Airflow 構成のオーバーライドと環境変数を指定するには:

コンソール

[環境の作成] ページで次の操作を行います。

  1. [環境変数] セクションで、[環境変数を追加] をクリックします。

  2. 環境変数の [名前] と [値] を入力します。

  3. [Airflow 構成のオーバーライド] セクションで、[AIRFLOW 構成のオーバーライドを追加] をクリックします。

  4. 構成オプションをオーバーライドする [セクション]、[キー]、[値] を入力します。

    次に例を示します。

    セクション キー 値
    webserver dag_orientation TB

gcloud

環境変数と Airflow 構成のオーバーライドは、環境を作成するときに、次の引数によって制御されます。

  • --env-variables は、環境変数のカンマ区切りリストを指定します。

    変数名には大文字と小文字、数字、アンダースコアを使用できますが、先頭に数字を配置することはできません。

  • --airflow-configs は、Airflow 構成のオーバーライドのキーと値のカンマ区切りのリストを指定します。

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --env-variables ENV_VARS \
    --airflow-configs CONFIG_OVERRIDES

以下のように置き換えます。

  • ENV_VARS は、環境変数のカンマ区切り NAME=VALUE ペアのリストに置き換えます。
  • CONFIG_OVERRIDES は、構成のオーバーライドのカンマ区切りの SECTION-KEY=VALUE ペアのリストに置き換えます。構成セクションの名前を - 記号で区切り、その後にキー名を指定します。（例: core-dags_are_paused_at_creation）。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --env-variables SENDGRID_MAIL_FROM=user@example.com,SENDGRID_API_KEY=example-key \
    --airflow-configs core-dags_are_paused_at_creation=True,webserver-dag_orientation=TB

API

環境を作成するときに、[Environment] > [EnvironmentConfig] リソースで環境変数と Airflow 構成のオーバーライドを指定します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "SECTION-KEY": "OVERRIDE_VALUE"
      },
      "envVariables": {
        "VAR_NAME": "VAR_VALUE",
      }
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • SECTION は、Airflow 構成オプションがある構成ファイルのセクションに置き換えます。
  • KEY は、Airflow 構成オプションの名前に置き換えます。
  • OVERRIDE_VALUE は、Airflow 構成オプションの値に置き換えます。
  • VAR_NAME は環境変数の名前に置き換えます。
  • VAR_VALUE は環境変数の値に置き換えます。

例:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "core-dags_are_paused_at_creation": "True",
        "webserver-dag_orientation": "TB"
      },
      "envVariables": {
        "SENDGRID_MAIL_FROM": "user@example.com",
        "SENDGRID_API_KEY": "example-key"
      }
    },
    "nodeConfig": {
        "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

環境変数と Airflow 構成のオーバーライドは、環境を作成するとき、次のブロックによって制御されます。

  • software_config ブロックの env_variables ブロックは、環境変数を指定します。

    変数名には大文字と小文字、数字、アンダースコアを使用できますが、先頭に数字を配置することはできません。

  • software_config ブロックの airflow_config_overrides ブロックは、Airflow 構成のオーバーライドを指定します。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    software_config {

      airflow_config_overrides = {
        SECTION-KEY = "OVERRIDE_VALUE"
      }

      env_variables = {
        VAR_NAME = "VAR_VALUE"
      }
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }

  }
}

以下のように置き換えます。

  • SECTION は、Airflow 構成オプションがある構成ファイルのセクションに置き換えます。
  • KEY は、Airflow 構成オプションの名前に置き換えます。
  • OVERRIDE_VALUE は、Airflow 構成オプションの値に置き換えます。
  • VAR_NAME は環境変数の名前に置き換えます。
  • VAR_VALUE は環境変数の値に置き換えます。

例:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    software_config {

      airflow_config_overrides = {
        core-dags_are_paused_at_creation = "True"
        webserver-dag_orientation = "TB"
      }

      env_variables = {
        SENDGRID_MAIL_FROM = "user@example.com"
        SENDGRID_API_KEY = "example-key"
      }
    }

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

手順 11. （省略可）メンテナンスの時間枠を指定する

Cloud Composer 2 のデフォルトのメンテナンスの時間枠は、毎週金曜日、土曜日、日曜日の 00:00:00～04:00:00（GMT）です。

環境にカスタム メンテナンスの時間枠を指定するには、次のようにします。

コンソール

[環境の作成] ページで次の操作を行います。

  1. [メンテナンスの時間枠] セクションを見つけます。

  2. [タイムゾーン] プルダウン リストで、メンテナンスの時間枠のタイムゾーンを選択します。

  3. [開始時刻]、[日]、[長さ] を設定して、指定したスケジュールの組み合わせ時刻が少なくとも 7 日間 12 時間のローリング ウィンドウになるようにします。たとえば、毎週月曜日、水曜日、金曜日の 4 時間に、必要な時間を指定します。

gcloud

メンテナンスの時間枠のパラメータは、次の引数により定義されます。

  • --maintenance-window-start は、メンテナンスの時間枠の開始時間を設定します。
  • --maintenance-window-end は、メンテナンスの時間枠の終了時間を設定します。
  • --maintenance-window-recurrence は、メンテナンスの時間枠の繰り返しを設定します。
gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --maintenance-window-start 'DATETIME_START' \
    --maintenance-window-end 'DATETIME_END' \
    --maintenance-window-recurrence 'MAINTENANCE_RECURRENCE'

以下のように置き換えます。

  • ENVIRONMENT_NAME を環境の名前にする。
  • DATETIME_START を、日付 / 時刻の入力形式の開始日時にする。指定した時刻のみが使用され、指定した日付は無視されます。
  • DATETIME_END を、終了日付 / 時刻入力形式の日時にする。指定した時刻のみが使用され、指定した日付は無視されます。指定する日付と時刻は開始日より後にする必要があります。

  • MAINTENANCE_RECURRENCE を、繰り返しのメンテナンス時間枠の RFC 5545 RRULE に置き換えます。Cloud Composer では、次の 2 つの形式がサポートされています。

  • FREQ=DAILY 形式は、毎日の繰り返しを指定します。

  • FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA 形式は、選択した曜日の繰り返しを指定します。

次の例は、水曜日、土曜日、日曜日の 01:00～07:00（UTC）の 6 時間を、メンテナンスの時間枠として指定しています。2023 年 1 月 1 日は無視されます。

gcloud composer environments create example-environment \
  --location us-central1 \
  --image-version composer-2.11.1-airflow-2.10.2 \
  --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
  --maintenance-window-start '2023-01-01T01:00:00Z' \
  --maintenance-window-end '2023-01-01T07:00:00Z' \
  --maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=SU,WE,SA'

API

環境を作成するときに、[Environment] > [EnvironmentConfig] リソースでメンテナンスの時間枠のパラメータを指定します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "maintenanceWindow": {
        "startTime": "DATETIME_START",
        "endTime": "DATETIME_END",
        "recurrence": "MAINTENANCE_RECURRENCE"
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • DATETIME_START を、日付 / 時刻の入力形式の開始日時にする。指定した時刻のみが使用され、指定された日付は無視されます。
  • DATETIME_END を、終了日付 / 時刻入力形式の日時にする。指定した時刻のみが使用され、指定した日付は無視されます。指定する日付と時刻は開始日より後にする必要があります。

  • MAINTENANCE_RECURRENCE を、繰り返しのメンテナンス時間枠の RFC 5545 RRULE にする。Cloud Composer では、次の 2 つの形式がサポートされています。

  • FREQ=DAILY 形式は、毎日の繰り返しを指定します。

  • FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA 形式は、選択した曜日の繰り返しを指定します。

次の例は、水曜日、土曜日、日曜日の 01:00～07:00（UTC）の 6 時間を、メンテナンスの時間枠として指定しています。2023 年 1 月 1 日は無視されます。

例:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "maintenanceWindow": {
        "startTime": "2023-01-01T01:00:00Z",
        "endTime": "2023-01-01T07:00:00Z",
        "recurrence": "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Terraform

maintenance_window ブロックでは、環境のメンテナンスの時間枠を指定します。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    maintenance_window {
      start_time = "DATETIME_START"
      end_time = "DATETIME_END"
      recurrence = "MAINTENANCE_RECURRENCE"
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

以下のように置き換えます。

  • DATETIME_START を、日付 / 時刻の入力形式の開始日時にする。指定した時刻のみが使用され、指定された日付は無視されます。
  • DATETIME_END を、終了日付 / 時刻入力形式の日時にする。指定した時刻のみが使用され、指定した日付は無視されます。指定する日付と時刻は開始日より後にする必要があります。

  • MAINTENANCE_RECURRENCE を、繰り返しのメンテナンス時間枠の RFC 5545 RRULE にする。Cloud Composer では、次の 2 つの形式がサポートされています。

    • FREQ=DAILY 形式は、毎日の繰り返しを指定します。
    • FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA 形式は、選択した曜日の繰り返しを指定します。

次の例は、水曜日、土曜日、日曜日の 01:00～07:00（UTC）の 6 時間を、メンテナンスの時間枠として指定しています。2023 年 1 月 1 日は無視されます。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    maintenance_window {
      start_time = "2023-01-01T01:00:00Z"
      end_time = "2023-01-01T07:00:00Z"
      recurrence = "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    }
  }
}

ステップ 12. （省略可）データリネージの統合

データリネージは、データの移動を追跡できる Dataplex の機能です。

データリネージ統合は、Cloud Composer 2 バージョン 2.1.2 以降と Airflow バージョン 2.2.5 以降で使用できます。

次の条件が満たされると、新しい Cloud Composer 環境でデータリネージ統合が自動的に有効になります。

  • プロジェクトで Data Lineage API が有効になっている。詳細については、Dataplex のドキュメントの Data Lineage API の有効化をご覧ください。

  • カスタム リネージ バックエンドが Airflow で構成されていません。

データリネージ統合は、環境を作成する際に無効にできます。たとえば、自動動作をオーバーライドする場合や、環境の作成後にデータリネージを有効にすることを選択する場合などです。

コンソール

データリネージ統合を無効にするには、[環境の作成] ページで次の操作を行います。

  1. [詳細設定] セクションで、[詳細設定を表示] 項目を展開します。

  2. [Dataplex データリネージのインテグレーション] セクションで、Dataplex データリネージとの統合を無効にするを選択します。

gcloud

環境を作成するときに、--disable-cloud-data-lineage-integration 引数はデータリネージ統合を無効にします。

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --disable-cloud-data-lineage-integration

以下のように置き換えます。

  • ENVIRONMENT_NAME を環境の名前に置き換えます。
  • LOCATION は、環境が配置されているリージョン。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --disable-cloud-data-lineage-integration

ステップ 13。（省略可）データ暗号化を構成する（CMEK）

デフォルトでは、環境内のデータは Google が提供する鍵で暗号化されます。

顧客管理の暗号鍵（CMEK）を使用して環境内のデータを暗号化するには、顧客管理の暗号鍵の使用で概説している手順に沿って操作してください。

ステップ 14.（省略可）カスタム環境のバケットを使用する

環境を作成すると、Cloud Composer によって自動的にご使用の環境のバケットが作成されます。

別の方法として、プロジェクトからカスタム Cloud Storage バケットを指定することもできます。ご使用の環境では、自動的に作成されたバケットと同じようにこのバケットが使用されます。

カスタム環境バケットを使用するには、カスタム環境のバケットを使用するで説明されている手順に従ってください。

ステップ 15.（省略可）環境ラベルを指定する

環境にラベルを割り当てると、ラベルに基づいて請求額の内訳を調べることができます。

コンソール

[環境の作成] ページの [ラベル] セクションで、次のようにします。

  1. [ラベルを追加] をクリックします。

  2. [キー] フィールドと [値] フィールドで、環境ラベルのキーと値のペアを指定します。

gcloud

環境を作成するときに、--labels 引数が環境ラベルを含むキーと値のカンマ区切りのリストを指定します。

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "SERVICE_ACCOUNT" \
    --labels LABELS

以下のように置き換えます。

  • LABELS は、環境ラベルのカンマ区切りの KEY=VALUE ペアのリストに置き換えます。

例:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.11.1-airflow-2.10.2 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --labels owner=engineering-team,env=production

API

環境を作成するときに、環境リソースで環境のラベルを指定します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "labels": {
    "LABEL_KEY": "LABEL_VALUE"
  }
}

以下のように置き換えます。

  • LABEL_KEY は、環境ラベルのキーに置き換えます。
  • LABEL_VALUE は、環境ラベルの値に置き換えます。

例:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "labels": {
    "owner": "engineering-team",
    "env": "production"
  }
}

Terraform

config ブロックの外部にある labels ブロックのラベルは、環境を作成するときに指定します。

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  labels = {
    LABEL_KEY = "LABEL_VALUE"
  }

}

以下のように置き換えます。

  • LABEL_KEY は、環境ラベルのキーに置き換えます。
  • LABEL_VALUE は、環境ラベルの値に置き換えます。

例:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  labels = {
    owner = "engineering-team"
    env = "production"
  }

}

次のステップ