Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
このページでは、Cloud Composer 環境を作成する方法について説明します。
- 環境について詳しくは、環境のアーキテクチャをご覧ください。
- Terraform を使用した環境の作成について詳しくは、環境の作成(Terraform)をご覧ください。
準備
Cloud Composer API を有効にします。Cloud Composer で使用されるサービスの全一覧については、Cloud Composer に必要なサービスをご覧ください。
環境の作成に要する時間は約 25 分です。
Terraform で環境を作成する場合は、Terraform で使用されるサービス アカウントに
composer.environments.create
権限が有効になっているロールが割り当てられている必要があります。Terraform のサービス アカウントの詳細については、Google プロバイダの構成リファレンスをご覧ください。
Terraform を使用した Cloud Composer 環境の作成について詳しくは、Terraform のドキュメントをご覧ください。
他のパラメータの詳細については、Terraform 引数リファレンスをご覧ください。
VPC SC: セキュリティ境界内に Cloud Composer 環境をデプロイするには、VPC SC の構成をご覧ください。Cloud Composer で使用する場合、VPC Service Controls には既知の制限事項がいくつかあります。
ステップ 1. 環境のサービス アカウントを作成または選択する
環境を作成するときに、サービス アカウントを指定します。このサービス アカウントは、環境のサービス アカウントと呼ばれます。環境では、このサービス アカウントを使用してほとんどのオペレーションを実行します。
ご使用の環境のサービス アカウントはユーザー アカウントではありません。サービス アカウントは、ユーザーではなく、アプリケーションや仮想マシン(VM)インスタンスで使用される特別なアカウントです。
ご使用の環境のサービス アカウントは後で変更できません。
プロジェクトに Cloud Composer 環境のサービス アカウントがまだない場合は、作成します。
Terraform で環境のサービス アカウントを作成する詳細な例については、環境の作成(Terraform)をご覧ください。
環境に新しいサービス アカウントを作成するには:
Identity and Access Management のドキュメントの説明に沿って、新しいサービス アカウントを作成します。
Identity and Access Management のドキュメントに記載されているように、ロールを付与します。必要なロールは Composer ワーカー(
composer.worker
)です。Google Cloud プロジェクト内の他のリソースにアクセスするには、このサービス アカウントに、それらのリソースにアクセスするための追加の権限を付与します。ほとんどの場合、Composer ワーカー(
composer.worker
)ロールには、この必要な権限セットが付与されています。このサービス アカウントに追加の権限を追加するのは、DAG の運用に必要な場合のみです。
ステップ 2. 基本設定
この手順では、指定したロケーションにデフォルト パラメータを持つ Cloud Composer 環境を作成します。
コンソール
Google Cloud コンソールで、[環境の作成] ページに移動します。
[名前] フィールドに、環境の名前を入力します。
名前は先頭を小文字にして、その後に 62 文字以下の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。
[ロケーション] プルダウン リストで、環境のロケーションを選択します。
ロケーションは、環境が配置されているリージョンです。
[イメージのバージョン] プルダウン リストで、必要なバージョンの Airflow を含む Cloud Composer イメージを選択します。
[サービス アカウント] プルダウン リストで、環境のサービス アカウントを選択します。
環境のサービス アカウントがまだない場合は、環境のサービス アカウントを作成または選択するをご覧ください。
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-3-airflow-2.10.2-build.3 \
--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-3-airflow-2.10.2-build.3"
},
"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-3-airflow-2.10.2-build.3"
}
node_config {
service_account = "
example-account@example-project.iam.gserviceaccount.com
"
}
}
}
ステップ 3. (省略可)環境のスケーリングとパフォーマンスのパラメータを構成する
環境のスケーリングとパフォーマンスを構成するには、環境のサイズとワークロードの構成を選択します。
環境を作成した後に、すべてのパフォーマンスとスケーリングのパラメータを変更できます。
スケーリングとパフォーマンスは、次のパラメータで制御します。
環境サイズ。Airflow データベースを含むマネージド Cloud Composer インフラストラクチャのパフォーマンス パラメータを制御します。インフラストラクチャのパフォーマンスを高めながら多数の DAG とタスクを実行する場合は、大きめの環境サイズの選択を検討してください。たとえば、環境のサイズが大きいほど、環境で最小限の遅延で処理できる Airflow タスクログエントリの量が増えます。
ワークロード構成GKE クラスタで実行される環境コンポーネントのスケールとパフォーマンスを制御します(Airflow スケジューラ、Airflow ウェブサーバー、Airflow ワーカー)。
Airflow スケジューラ。DAG ファイルを解析し、スケジュール間隔に基づいて DAG の実行をスケジュールし、Airflow ワーカーが実行するタスクをキューに入れます。
ご利用の環境では、同時に複数の Airflow スケジューラを実行できます。複数のスケジューラを使用して複数のスケジューラ インスタンス間で負荷を分散すると、パフォーマンスと信頼性が向上します。
スケジューラの数を増やしても、Airflow のパフォーマンスが常に改善されるとは限りません。たとえば、スケジューラが 1 つだけでも、2 つの場合よりも良いパフォーマンスの場合があります。これは、追加のスケジューラが使用されないため、全体的なパフォーマンスに寄与せずに環境のリソースを消費した場合に発生する可能性があります。実際のスケジューラのパフォーマンスは、Airflow ワーカーの数、環境内で実行される DAG とタスクの数、Airflow と環境の両方の構成によって異なります。
2 つのスケジューラを設定した状態で開始し、環境のパフォーマンスをモニタリングすることをおすすめします。スケジューラの数を変更する場合は、いつでも環境を元のスケジューラ数にスケールダウンできます。
複数のスケジューラの構成の詳細については、Airflow のドキュメントをご覧ください。
Airflow トリガー。環境内のすべての遅延タスクを非同期でモニタリングします。環境内に少なくとも 1 つの triggerer インスタンス(または高復元環境では少なくとも 2 つ)がある場合は、DAG で遅延可能な演算子を使用できます。
Airflow DAG プロセッサ。DAG ファイルを処理して DAG オブジェクトに変換します。Cloud Composer 3 では、スケジューラのこの部分は個別の環境コンポーネントとして実行されます。
Airflow ウェブサーバー。Airflow ウェブ インターフェースを実行します。このインターフェースでは、DAG をモニタリング、管理、表示できます。
Airflow ワーカー。Airflow スケジューラによってスケジュールされたタスクを実行します。環境内のワーカーの最小数と最大数は、キュー内のタスクの数に応じて動的に変化します。
コンソール
環境のプリセットは、選択できます。プリセットを選択すると、そのプリセットのスケーリングとパフォーマンスのパラメータが自動的に選択されます。カスタム プリセットを選択して、環境のすべてのスケーリングとパフォーマンスのパラメータを指定することもできます。
環境のスケールとパフォーマンス構成を選択するには、[環境の作成] ページで次の操作を行います。
事前定義された値を使用するには、[環境リソース] セクションで [小]、[中]、または [大] をクリックします。
スケーリングとパフォーマンスのパラメータにカスタム値を指定するには、次のようにします。
[環境リソース] セクションで [カスタム] をクリックします。
[スケジューラ] セクションで、使用するスケジューラの数と、CPU、メモリ、ストレージのリソース割り当てを設定します。
[triggerer] セクションで、[triggerer の数] フィールドを使用して、環境内の triggerer の数を入力します。DAG で遅延可能な演算子を使用しない場合は、この数を 0 に設定できます。
環境に少なくとも 1 つの triggerer を設定する場合は、[CPU] フィールドと [メモリ] フィールドを使用して、triggerer のリソース割り当てを構成します。
[DAG プロセッサ] セクションで、環境内の DAG プロセッサの数と、各 DAG プロセッサの CPU、メモリ、ストレージの容量を指定します。
[ウェブサーバー] セクションで、ウェブサーバーの CPU、メモリ、ストレージの量を指定します。
[ワーカー] セクションで、次を指定します。
- 環境の自動スケーリングの制限で使用されるワーカーの最小数と最大数。
- ワーカーの CPU、メモリ、ストレージの割り当て
[コア インフラストラクチャ] セクションの [環境サイズ] プルダウン リストで、環境のサイズを選択します。
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
です。--dag-processor-cpu
では、DAG プロセッサの CPU 数を指定します。--dag-processor-memory
では、DAG プロセッサのメモリ容量を指定します。--dag-processor-storage
では、DAG プロセッサのディスク容量を指定します。--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-3-airflow-2.10.2-build.3 \
--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 \
--dag-processor-cpu DAG_PROCESSOR_CPU \
--dag-processor-memory DAG_PROCESSOR_MEMORY \
--dag-processor-storage DAG_PROCESSOR_STORAGE \
--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)に置き換えます。DAG_PROCESSOR_CPU
は、DAG プロセッサの CPU 数に置き換えます。DAG_PROCESSOR_MEMORY
は、DAG プロセッサのメモリ容量に置き換えます。DAG_PROCESSOR_STORAGE
は、DAG プロセッサのディスク容量に置き換えます。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-3-airflow-2.10.2-build.3 \
--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 \
--dag-processor-cpu 0.5 \
--dag-processor-memory 2GB \
--dag-processor-storage 1GB \
--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
},
"dagProcessor": {
"count": 1,
"cpu": DAG_PROCESSOR_CPU,
"memoryGb": DAG_PROCESSOR_MEMORY,
"storageGb": DAG_PROCESSOR_STORAGE
},
"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
です。DAG_PROCESSOR_CPU
は、DAG プロセッサの CPU 数(vCPU 単位)に置き換えます。DAG_PROCESSOR_MEMORY
は、DAG プロセッサのメモリ容量(GB)に置き換えます。DAG_PROCESSOR_STORAGE
は、DAG プロセッサのディスク容量(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
に置き換えます。
例:
// 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
},
"dagProcessor": {
"count": 1,
"cpu": 0.5,
"memoryGb": 2,
"storageGb": 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
フィールドでは、環境内のトリガーの数を指定します。dag_processor.cpu
フィールドでは、DAG プロセッサの CPU 数を指定します。dag_processor.memory_gb
フィールドでは、DAG プロセッサのメモリ容量を指定します。dag_processor.storage_gb
フィールドでは、DAG プロセッサのディスク容量を指定します。dag_processor.count
フィールドでは、DAG プロセッサの数を指定します。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
"
}
}
}
ステップ 4. (省略可)環境のデータベースのゾーンを指定する
環境の優先 Cloud SQL ゾーンを指定できます。
コンソール
[環境の作成] ページで次の操作を行います。
[詳細設定] セクションで、[詳細設定を表示] 項目を展開します。
[Airflow データベース ゾーン] リストで、優先 Cloud SQL ゾーンを選択します。
gcloud
環境を作成するときに、--cloud-sql-preferred-zone
引数は優先 Cloud SQL ゾーンを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-3-airflow-2.10.2-build.3 \
--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-3-airflow-2.10.2-build.3 \
--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 ゾーン。このゾーンは、環境が配置されているリージョンに配置する必要があります。
ステップ 5. (省略可)環境のネットワーキングを構成する
Cloud Composer 3 ネットワーキングは、次の方法で構成できます。
- パブリック IP 環境では、環境の Airflow コンポーネントがインターネットにアクセスできます。
- プライベート IP 環境では、環境の Airflow コンポーネントがインターネットにアクセスできません。
- プライベート IP 環境とパブリック IP 環境は、個別のオプションとして VPC ネットワークに接続できます。
- 環境の内部 IP 範囲を指定できます。この範囲は後で変更できません。
PyPI パッケージのインストール時にインターネットへのアクセスを有効にすることができます。たとえば、このオプションを有効にすると、プライベート IP 環境で Python パッケージ インデックスから PyPI パッケージをインストールできます。
共有 VPC 環境の場合は、ホスト プロジェクトに対して追加のネットワークを設定してから、サービス プロジェクトにパブリック IP 環境またはプライベート IP 環境を作成する必要があります。共有 VPC の構成ページの手順に沿って行います。
コンソール
ネットワーキングは、作成する環境の種類に応じて構成する必要があります。
[ネットワークの構成] セクションで、[ネットワーク構成を表示] 項目を展開します。
環境を VPC ネットワークに接続する場合は、[ネットワーク アタッチメント] フィールドで、ネットワーク アタッチメントを選択します。新しいネットワーク アタッチメントを作成することもできます。詳細については、環境を VPC ネットワークに接続するをご覧ください。
プライベート IP 環境を作成する場合は、[ネットワークの種類] セクションで [プライベート IP 環境] オプションを選択します。
ネットワーク タグを追加する場合は、ネットワーク タグを追加するで詳細をご覧ください。
gcloud
ネットワーキングは、作成する環境の種類に応じて構成する必要があります。
環境を作成する際、次の引数によりネットワーク パラメータが制御されます。パラメータを省略すると、デフォルト値が使用されます。
--enable-private-environment
は、プライベート IP 環境を有効にします。--network
は、VPC ネットワーク ID を指定します。--subnetwork
は、VPC サブネットワーク ID を指定します。
--composer-internal-ipv4-cidr-block
は、環境の内部 IP 範囲を指定します。この範囲は、環境のテナント プロジェクトの Cloud Composer で使用されます。
例(VPC ネットワークが接続されたプライベート IP 環境)
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-3-airflow-2.10.2-build.3 \
--service-account "SERVICE_ACCOUNT" \
--enable-private-environment \
--network NETWORK_ID \
--subnetwork SUBNETWORK_ID \
以下のように置き換えます。
NETWORK_ID
は、VPC ネットワーク ID に置き換えます。SUBNETWORK_ID
は、VPC サブネットワーク ID に置き換えます。
ステップ 6. (省略可)ネットワーク タグを追加する
ネットワーク タグは、環境のクラスタ内のすべてのノード VM に適用されます。タグは、ネットワーク ファイアウォールの有効なソースやターゲットを識別するために使用されます。リスト内の各タグは、RFC 1035 に準拠している必要があります。
たとえば、ファイアウォール ルールでプライベート IP 環境のトラフィックを制限する予定がある場合は、ネットワーク タグを追加するとよいかもしれません。
コンソール
[環境の作成] ページで次の操作を行います。
- [ネットワークの構成] セクションを見つけます。
- [ネットワーク タグ] フィールドに、使用中の環境のネットワーク タグを入力します。
gcloud
環境を作成する際は、次の引数を使用してネットワーク タグを制御します。
--tags
は、すべてのノード VM に適用されるネットワーク タグのカンマ区切りのリストを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-3-airflow-2.10.2-build.3 \
--service-account "SERVICE_ACCOUNT" \
--tags TAGS
以下のように置き換えます。
TAGS
は、ネットワーク タグのカンマ区切りのリストに置き換えます。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-3-airflow-2.10.2-build.3 \
--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
"
}
}
}
ステップ 7. (省略可)ウェブサーバーへのネットワーク アクセスを構成する
Airflow ウェブサーバーのアクセス パラメータは、環境の種類に依存しません。代わりに、ウェブサーバーのアクセスを個別に構成できます。たとえば、プライベート IP 環境で、引き続きインターネットから Airflow UI にアクセスできます。
プライベート IP アドレスを使用して許可された IP 範囲を構成することはできません。
コンソール
[環境の作成] ページで次の操作を行います。
[ネットワークの構成] セクションで、[ネットワーク構成を表示] 項目を展開します。
[ウェブサーバーのネットワーク アクセス制御] セクションで、次の操作を行います。
すべての 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-3-airflow-2.10.2-build.3 \
--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-3-airflow-2.10.2-build.3 \
--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
"
}
}
手順 8. (省略可)Airflow 構成のオーバーライドと環境変数を指定する
Airflow 構成のオーバーライドと環境変数は、環境を作成するときに設定できます。あるいは、環境を作成した後に行うこともできます。
一部の Airflow 構成オプションはブロックされているため、オーバーライドすることはできません。
使用可能な Airflow 構成オプションの一覧については、Airflow 2 の構成リファレンスと Airflow 1.10.* をご覧ください。
Airflow 構成のオーバーライドと環境変数を指定するには:
コンソール
[環境の作成] ページで次の操作を行います。
[環境変数] セクションで、[環境変数を追加] をクリックします。
環境変数の [名前] と [値] を入力します。
[Airflow 構成のオーバーライド] セクションで、[AIRFLOW 構成のオーバーライドを追加] をクリックします。
構成オプションをオーバーライドする [セクション]、[キー]、[値] を入力します。
例:
セクション キー 値 webserver
dag_orientation
TB
gcloud
環境変数と Airflow 構成のオーバーライドは、環境を作成するときに、次の引数によって制御されます。
--env-variables
は、環境変数のカンマ区切りリストを指定します。変数名には大文字と小文字、数字、アンダースコアを使用できますが、先頭に数字を配置することはできません。
--airflow-configs
は、Airflow 構成のオーバーライドのキーと値のカンマ区切りのリストを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-3-airflow-2.10.2-build.3 \
--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-3-airflow-2.10.2-build.3 \
--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
"
}
}
}
手順 9. (省略可)メンテナンスの時間枠を指定する
Cloud Composer 3 のデフォルトのメンテナンスの時間枠は、次のように定義されます。
- 時刻はすべて、環境が配置されているリージョンのローカル タイムゾーンの時刻ですが、夏時間は無視されます。
- 火曜日、水曜日、木曜日、金曜日のメンテナンスの時間枠は、00:00:00~02:00:00 です。
- 土曜日、日曜日、月曜日のメンテナンスの時間枠は、00:00:00~04:00:00 です。
環境にカスタム メンテナンスの時間枠を指定するには、次のようにします。
コンソール
[環境の作成] ページで次の操作を行います。
[メンテナンスの時間枠] セクションを見つけます。
[タイムゾーン] プルダウン リストで、メンテナンスの時間枠のタイムゾーンを選択します。
[開始時刻]、[日]、[長さ] を設定して、指定したスケジュールの組み合わせ時刻が少なくとも 7 日間 12 時間のローリング ウィンドウになるようにします。たとえば、毎週月曜日、水曜日、金曜日の 4 時間に、必要な時間を指定します。
gcloud
メンテナンスの時間枠のパラメータは、次の引数により定義されます。
--maintenance-window-start
は、メンテナンスの時間枠の開始時間を設定します。--maintenance-window-end
は、メンテナンスの時間枠の終了時間を設定します。--maintenance-window-recurrence
は、メンテナンスの時間枠の繰り返しを設定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-3-airflow-2.10.2-build.3 \
--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-3-airflow-2.10.2-build.3 \
--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"
}
}
}
手順 10. (省略可)データリネージの統合
データリネージは、データの移動を追跡できる Dataplex の機能です。
データリネージ統合は、Cloud Composer 3 のすべてのバージョンで使用できます。次の条件が満たされると、新しい Cloud Composer 環境でデータリネージ統合が自動的に有効になります。
プロジェクトで Data Lineage API が有効になっている。詳細については、Dataplex のドキュメントの Data Lineage API の有効化をご覧ください。
カスタム リネージ バックエンドが Airflow で構成されていません。
データリネージ統合は、環境を作成する際に無効にできます。たとえば、自動動作をオーバーライドする場合や、環境の作成後にデータリネージを有効にすることを選択する場合などです。
コンソール
データリネージ統合を無効にするには、[環境の作成] ページで次の操作を行います。
[詳細設定] セクションで、[詳細設定を表示] 項目を展開します。
[Dataplex データリネージのインテグレーション] セクションで、Dataplex データリネージとの統合を無効にするを選択します。
gcloud
環境を作成するときに、--disable-cloud-data-lineage-integration
引数はデータリネージ統合を無効にします。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-3-airflow-2.10.2-build.3 \
--service-account "SERVICE_ACCOUNT" \
--disable-cloud-data-lineage-integration
以下のように置き換えます。
ENVIRONMENT_NAME
を環境の名前にする。LOCATION
は、環境が配置されているリージョン。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-3-airflow-2.10.2-build.3 \
--service-account "
example-account@example-project.iam.gserviceaccount.com
" \
--disable-cloud-data-lineage-integration
手順 11. (省略可)データ暗号化を構成する(CMEK)
デフォルトでは、環境内のデータは Google が提供する鍵で暗号化されます。
顧客管理の暗号鍵(CMEK)を使用して環境内のデータを暗号化するには、顧客管理の暗号鍵の使用で概説している手順に沿って操作してください。
ステップ 12. (省略可)カスタム環境のバケットを使用する
環境を作成すると、Cloud Composer によって自動的にご使用の環境のバケットが作成されます。
別の方法として、プロジェクトからカスタム Cloud Storage バケットを指定することもできます。ご使用の環境では、自動的に作成されたバケットと同じようにこのバケットが使用されます。
カスタム環境バケットを使用するには、カスタム環境のバケットを使用するで説明されている手順に従ってください。
ステップ 13。(省略可)環境ラベルを指定する
環境にラベルを割り当てると、ラベルに基づいて請求額の内訳を調べることができます。
コンソール
[環境の作成] ページの [ラベル] セクションで、次のようにします。
[ラベルを追加] をクリックします。
[キー] フィールドと [値] フィールドで、環境ラベルのキーと値のペアを指定します。
gcloud
環境を作成するときに、--labels
引数が環境ラベルを含むキーと値のカンマ区切りのリストを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-3-airflow-2.10.2-build.3 \
--service-account "SERVICE_ACCOUNT" \
--labels LABELS
以下のように置き換えます。
LABELS
は、環境ラベルのカンマ区切りのKEY=VALUE
ペアのリストに置き換えます。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-3-airflow-2.10.2-build.3 \
--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"
}
}
次のステップ
- 環境作成のトラブルシューティング
- 共有 VPC の構成
- VPC Service Controls の構成
- DAG の追加と更新
- Airflow UI へのアクセス
- 環境の更新と削除
- Cloud Composer のバージョンについて