Cloud Composer 1 | Cloud Composer 2
このページでは、Cloud Composer 2 環境を作成する方法について説明します。
Cloud Composer 環境は、マネージド Google Kubernetes Engine クラスタにデプロイされる自己完結型の Apache Airflow インストールです。単一の Google Cloud プロジェクトに 1 つ以上の環境を作成できます。
- 環境について詳しくは、環境のアーキテクチャをご覧ください。
- Terraform を使用した環境の作成について詳しくは、環境の作成（Terraform）をご覧ください。
準備
Cloud Composer API を有効にします。Cloud Composer で使用されるサービスの全一覧については、Cloud Composer に必要なサービスをご覧ください。
環境の作成に要する時間は約 25 分です。
環境の作成では、サービス アカウントを指定します。Cloud Composer は、環境のクラスタの Kubernetes サービス アカウントにこのアカウントをバインドします。
デフォルトでは、Cloud Composer 環境により Google が管理するデフォルトの Compute Engine サービス アカウントが使用されます。Cloud Composer に固有のロールを持つユーザー管理のサービス アカウントを作成し、環境として使用することをおすすめします。
Terraform で環境を作成する場合は、Terraform で使用されるサービス アカウントに
composer.environments.create権限が有効になっているロールが割り当てられている必要があります。Terraform のサービス アカウントの詳細については、Google プロバイダの構成リファレンスをご覧ください。
Terraform を使用した Cloud Composer 環境の作成について詳しくは、Terraform のドキュメントをご覧ください。
他のパラメータの詳細については、Terraform 引数リファレンスをご覧ください。
プライベート IP: プライベート IP 環境を作成するための特定のネットワーク要件とピアリング要件が存在します。詳細については、プライベート IP の構成をご覧ください。
共有 VPC: Cloud Composer で共有 VPC を使用するための特定のネットワーク要件が存在します。詳細については、共有 VPC の構成をご覧ください。
VPC SC: セキュリティ境界内に Cloud Composer 環境をデプロイするには、VPC SC の構成をご覧ください。Cloud Composer で使用する場合、VPC Service Controls には既知の制限事項がいくつかあります。
手順 1. 基本設定
この手順では、指定したロケーションにデフォルト パラメータを持つ Cloud Composer 環境を作成します。
Console
Google Cloud Console で、Cloud Composer 2 の [環境の作成] ページに移動します。
[名前] フィールドに、環境の名前を入力します。
名前は先頭を小文字にして、その後に 62 文字以下の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。
[ロケーション] プルダウン リストで、環境のロケーションを選択します。
ロケーションは、環境の GKE クラスタが配置されるリージョンです。
[イメージのバージョン] プルダウン リストで、必要なバージョンの Airflow を含む Cloud Composer イメージを選択します。
gcloud
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version IMAGE_VERSION
次のように置き換えます。
ENVIRONMENT_NAMEを環境の名前にする。名前は先頭を小文字にして、その後に 62 文字以下の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。
LOCATIONは、環境のリージョンに置き換えます。ロケーションは、環境の GKE クラスタが配置されるリージョンです。
IMAGE_VERSIONは、Cloud Composer イメージの名前に置き換えます。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-2.6.6-airflow-2.6.3
API
environments.create API リクエストを作成します。構成は、Environment リソースで指定します。
{
"name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
"config": {
"softwareConfig": {
"imageVersion": "IMAGE_VERSION"
}
}
}
以下のように置き換えます。
PROJECT_IDは、プロジェクト ID に置き換えます。LOCATIONは、環境のリージョンに置き換えます。ロケーションは、環境の GKE クラスタが配置されるリージョンです。
ENVIRONMENT_NAMEは、環境名に置き換えます。名前は先頭を小文字にして、その後に 62 文字以下の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。
IMAGE_VERSIONは、Cloud Composer イメージの名前に置き換えます。
例:
// 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.6.6-airflow-2.6.3"
}
}
}
Terraform
デフォルトのパラメータを使用して環境を作成するには、指定された場所で Terraform 構成に次のリソース ブロックを追加して terraform apply を実行します。
resource "google_composer_environment" "example" {
provider = google-beta
name = "ENVIRONMENT_NAME"
region = "LOCATION"
config {
software_config {
image_version = "IMAGE_VERSION"
}
}
}
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前にする。名前は先頭を小文字にして、その後に 62 文字以下の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。
LOCATIONは、環境のリージョンに置き換えます。ロケーションは、環境の GKE クラスタが配置されるリージョンです。
IMAGE_VERSIONは、Cloud Composer イメージの名前に置き換えます。
例:
resource "google_composer_environment" "example" {
provider = google-beta
name = "example-environment"
region = "us-central1"
config {
software_config {
image_version = "composer-2.6.6-airflow-2.6.3"
}
}
}
ステップ 2. （省略可）環境のサービス アカウントを選択する
Cloud Composer は、このサービス アカウントを環境の Kubernetes サービス アカウントにバインドします。環境のクラスタ内のノードは Kubernetes サービス アカウントとして実行され、バインディングを使用して、環境バケット内の DAG 定義ファイルなどの Google Cloud プロジェクト内のリソースにアクセスします。
デフォルトでは、Cloud Composer 環境は、デフォルトの Compute Engine サービス アカウントを使用します。Cloud Composer 環境に対しては、ユーザーが管理するサービス アカウントを設定することをおすすめします。
ご使用の環境のサービス アカウントは後で変更できません。
Console
[環境の作成] ページの [サービス アカウント] プルダウン リストで、環境のサービス アカウントを選択します。
gcloud
環境のサービス アカウントは、環境を作成するときに --service-account で指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--service-account "SERVICE_ACCOUNT"
以下のように置き換えます。
SERVICE_ACCOUNTは、環境のサービス アカウントに置き換えます。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-2.6.6-airflow-2.6.3 \
--service-account "example-account@example-project.iam.gserviceaccount.com"
API
環境を作成するときに、[Environment] > [EnvironmentConfig] リソースで環境のサービス アカウントを指定します。
{
"name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
"config": {
"nodeConfig": {
"serviceAccount": "SERVICE_ACCOUNT"
}
}
以下のように置き換えます。
SERVICE_ACCOUNTは、環境のサービス アカウントに置き換えます。
例:
// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments
{
"name": "projects/example-project/locations/us-central1/environments/example-environment",
"config": {
"nodeConfig": {
"serviceAccount": "example-account@example-project.iam.gserviceaccount.com"
}
}
}
Terraform
環境を作成する際は、node_config ブロックの service_account フィールドを使用します。
resource "google_composer_environment" "example" {
provider = google-beta
name = "ENVIRONMENT_NAME"
region = "LOCATION"
config {
node_config {
service_account = "SERVICE_ACCOUNT"
}
}
}
以下のように置き換えます。
SERVICE_ACCOUNTは、環境のサービス アカウントに置き換えます。
例:
resource "google_composer_environment" "example" {
provider = google-beta
name = "example-environment"
region = "us-central1"
config {
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 サービス エージェント アカウントに追加の権限を提供します。このロールは自動的には付与されません。これは手動で付与する必要があります。
Console
プロジェクトに環境を作成するときに、環境のサービス アカウントに必要な権限が 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
ロールを付与するには、読み取り、変更、書き込みのパターンを使用して既存の許可ポリシーを変更する必要があります。
- ご使用の環境のサービス アカウントに関する既存の許可ポリシーを読み取ります。
- これを変更して、Cloud Composer サービス アカウントの
roles/composer.ServiceAgentV2Extロールを含めます。 - 既存の許可ポリシーを書き換えます。
詳細については、プログラムによるアクセス権の制御をご覧ください。
{
"role": "roles/composer.ServiceAgentV2Ext",
"members": [
"serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com"
]
}
以下のように置き換えます。
PROJECT_NUMBERは、プロジェクト番号に置き換えます。
例:
{
"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. （省略可）環境のスケーリングとパフォーマンスのパラメータを構成する
環境のスケーリングとパフォーマンスを構成するには、環境のサイズとワークロードの構成を選択します。
Cloud Composer 2 では、環境を作成した後に、すべてのパフォーマンスとスケーリングのパラメータを変更できます。
スケーリングとパフォーマンスは、次のパラメータで制御します。
環境サイズ。Airflow データベースを含むマネージド Cloud Composer インフラストラクチャのパフォーマンス パラメータを制御します。多数の DAG とタスクを実行する場合は、大きめの環境サイズの選択を検討してください。
ワークロード構成GKE クラスタで実行される環境コンポーネントのスケールとパフォーマンスを制御します（Airflow スケジューラ、Airflow ウェブサーバー、Airflow ワーカー）。
Airflow スケジューラ。DAG ファイルを解析し、スケジュール間隔に基づいて DAG の実行をスケジュールし、Airflow ワーカーが実行するタスクをキューに入れます。
ご利用の環境では、同時に複数の Airflow スケジューラを実行できます。複数のスケジューラを使用して複数のスケジューラ インスタンス間で負荷を分散すると、パフォーマンスと信頼性が向上します。
環境には、最大 10 個のスケジューラを設定できます。スケジューラの数を増やしても、Airflow のパフォーマンスが常に改善されるとは限りません。たとえば、スケジューラが 1 つだけでも、2 つの場合よりも良いパフォーマンスの場合があります。これは、追加のスケジューラが使用されないため、全体的なパフォーマンスに寄与せずに環境のリソースを消費した場合に発生する可能性があります。実際のスケジューラのパフォーマンスは、Airflow ワーカーの数、環境内で実行される DAG とタスクの数、Airflow と環境の両方の構成によって異なります。
2 つのスケジューラを設定した状態で開始し、環境のパフォーマンスをモニタリングすることをおすすめします。スケジューラの数を変更する場合は、いつでも環境を元のスケジューラ数にスケールダウンできます。
複数のスケジューラの構成の詳細については、Airflow のドキュメントをご覧ください。
Airflow トリガー。環境内のすべての遅延タスクを非同期でモニタリングします。環境内に少なくとも 1 つの triggerer インスタンス（または高復元環境では少なくとも 2 つ）がある場合は、DAG で遅延可能な演算子を使用できます。
Airflow ウェブサーバー。Airflow ウェブ インターフェースを実行します。このインターフェースでは、DAG をモニタリング、管理、表示できます。
Airflow ワーカー。Airflow スケジューラによってスケジュールされたタスクを実行します。環境内のワーカーの最小数と最大数は、キュー内のタスクの数に応じて動的に変化します。
Console
環境のプリセットは、選択できます。プリセットを選択すると、そのプリセットのスケーリングとパフォーマンスのパラメータが自動的に選択されます。カスタム プリセットを選択して、環境のすべてのスケーリングとパフォーマンスのパラメータを指定することもできます。
環境のスケールとパフォーマンス構成を選択するには、[環境の作成] ページで次の操作を行います。
事前定義された値を使用するには、[環境リソース] セクションで [小]、[中]、または [大] をクリックします。
スケーリングとパフォーマンスのパラメータにカスタム値を指定するには、次のようにします。
[環境リソース] セクションで [カスタム] をクリックします。
[スケジューラ] セクションで、使用するスケジューラの数と CPU、メモリ、ストレージのリソース割り当てを設定します。
[トリガラー] セクションで、[トリガラーの数] フィールドを使用して、環境内の triggerer の数を入力します。DAG で遅延可能な演算子を使用しない場合は、この数を 0 に設定できます。
環境に少なくとも 1 つの triggerer を設定する場合は、[CPU] フィールドと [メモリ] フィールドを使用して、triggerer のリソース割り当てを構成します。
[ワーカー] セクションで、次を指定します。
- 環境の自動スケーリング上限のワーカーの最小数と最大数
- ワーカーの 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 はデフォルトの
0.5vCPU と0.5GB のメモリ割り当てで作成されます。--triggerer-cpuフラグと--triggerer-memoryフラグを使用して、triggerer ごとに異なるリソース割り当てを指定します。--triggerer-cpuでは、Airflow triggerer の CPU 数を vCPU 単位で指定します。使用できる値:0.5、0.75、1。--triggerer-memoryでは、Airflow ワーカーのメモリ容量を指定します。必要な最小メモリは、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.6.6-airflow-2.6.3 \
--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.6.6-airflow-2.6.3 \
--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"
}
}
以下のように置き換えます。
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"
}
}
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"
}
}
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前にする。LOCATIONは、環境が配置されているリージョン。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"
}
}
ステップ 5. （省略可）高復元モードを有効にする
復元性の高い Cloud Composer 環境は、組み込みの冗長性とフェイルオーバー メカニズムを使用する Cloud Composer 2 環境で、ゾーン障害や単一障害点停止に対する環境の影響を軽減します。
復元性に優れた環境では、選択したリージョンの少なくとも 2 つのゾーンで実行されます。2 つの Airflow スケジューラ、2 つのウェブサーバー、少なくとも 2 つの triggerer（triggerer の数が 0 に設定されていない場合）が別々のゾーンで実行されます。
ワーカーの最小数は 2 に設定されており、環境のクラスタはゾーン間でワーカー インスタンスを分散します。ゾーンが停止した場合、影響を受けるワーカー インスタンスは別のゾーンで再スケジュールされます。復元性に優れた環境の Cloud SQL データベースは、プライマリ インスタンスとスタンバイ インスタンスを持つリージョン インスタンスです。
コンソール
[環境の作成] ページで次の操作を行います。
[レジリエンス モード] セクションで、[高レジリエンス] を選択します。
[環境リソース] セクションで、復元性に優れた環境のスケール パラメータを選択します。復元性に優れた環境では、2 つのスケジューラ、0 または 2～10 個のトリガー、2 個以上のワーカーが必要です。
[Custom] をクリックします。
[スケジューラの数] プルダウン リストで、
2を選択します。[トリガラーの数] プルダウン リストで、
0または2～10の値を選択します。triggerer の [CPU] と [メモリ] の割り当てを構成します。[ワーカーの最小数] プルダウン リストで、必要なワーカー数に応じて
2以上を選択します。
[Network configuration] セクションで、次のようにします。
[ネットワークの種類] で、[プライベート IP 環境] を選択します。
必要に応じて、その他のネットワーキング パラメータを指定します。
gcloud
環境を作成する際、--enable-high-resilience 引数により高復元モードが有効になります。
次の引数を設定します。
--enable-high-resilience--enable-private-environmentと、プライベート IP 環境のその他のネットワーク パラメータ（必要な場合）--scheduler-countが2さんに付与されました--triggerer-countから0、または2～10の数値
triggerer を使用する場合は、環境の作成に --triggerer-cpu フラグと --triggerer-memory フラグも必要です。
- `--triggerer-cpu` specifies the number of CPUs for an Airflow triggerer.
Allowed values: `0.5`, `0.75`, `1`.
- `--triggerer-memory` specifies the amount of memory for an Airflow
triggerer. The minimum required memory is equal to the number of
CPUs allocated for the triggerers. The maximum allowed value is
equal to the number of triggerer CPUs multiplied by 6.5.
For example, if you set the `--triggerer-cpu` flag to `1`, the
**minimum value** for `--triggerer-memory` is `1` and the
**maximum value** is `6.5`.
--min-workers～2以上
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--enable-high-resilience \
--enable-private-environment \
--scheduler-count 2 \
--triggerer-count 2 \
--triggerer-cpu 0.5 \
--triggerer-memory 0.5 \
--min-workers 2
API
環境を作成するときに、[環境] > [EnvironmentConfig] リソースで高い復元力モードを有効にします。
{
"name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
"config": {
"resilience_mode": "HIGH_RESILIENCE"
}
}
例:
// 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"
}
}
Terraform
環境の作成時に、config ブロックの resilience_mode フィールドで高復元モードが有効になります。
resource "google_composer_environment" "example" {
provider = google-beta
name = "ENVIRONMENT_NAME"
region = "LOCATION"
config {
resilience_mode = "HIGH_RESILIENCE"
}
}
例:
resource "google_composer_environment" "example" {
provider = google-beta
name = "example-environment"
region = "us-central1"
config {
resilience_mode = "HIGH_RESILIENCE"
}
ステップ 6. （省略可）環境のデータベースのゾーンを指定する
スタンダード レジリエンス環境を作成するときに、優先 Cloud SQL ゾーンを指定できます。
コンソール
[環境の作成] ページで次の操作を行います。
[詳細設定] セクションで、[詳細設定を表示] 項目を展開します。
[Airflow データベース ゾーン] リストで、優先 Cloud SQL ゾーンを選択します。
gcloud
環境を作成するときに、--cloud-sql-preferred-zone 引数は優先 Cloud SQL ゾーンを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--cloud-sql-preferred-zone SQL_ZONE
次のように置き換えます。
SQL_ZONE: 優先 Cloud SQL ゾーン。このゾーンは、環境が配置されているリージョンに配置する必要があります。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-2.6.6-airflow-2.6.3 \
--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"
}
}
}
次のように置き換えます。
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"
}
}
}
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"
}
}
}
次のように置き換えます。
SQL_ZONE: 優先 Cloud SQL ゾーン。このゾーンは、環境が配置されているリージョンに配置する必要があります。
ステップ 7. （省略可）環境のネットワーキングを構成する
ネットワーキング パラメータは、作成する環境の種類によって異なります。
パブリック IP 環境。デフォルトのネットワーク パラメータを使用します。
プライベート IP 環境（PSC 使用）。この構成では、環境で Private Service Connect を使用して接続します。
プライベート IP 環境を構成します。
- プロジェクトのネットワークをプライベート IP 環境用に構成する。
- 環境を作成するときに Private Service Connect を構成します。
- プライベート 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 環境を構成します。
- プロジェクトのネットワークをプライベート IP 環境用に構成する。
- このセクションで詳細に説明するように、プライベート 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 マスカレード エージェントを有効にするをご覧ください。
Console
プライベート IP 環境を作成するには、次のようにします。
ネットワーキングは、作成する環境の種類に応じて構成する必要があります。
[ネットワークの構成] セクションで、[ネットワーク構成を表示] 項目を展開します。
[ネットワーク] プルダウン リストで、VPC ネットワーク ID を選択します。
[サブネットワーク] プルダウン リストで、VPC サブネットワーク ID を選択します。
[Pod のセカンダリ IP 範囲] セクションで、Pod のセカンダリ IP 範囲を選択または指定します。VPC ネットワーク内の既存のセカンダリ範囲を使用することも、自動作成範囲を使用することもできます。
[サービスのセカンダリ IP 範囲] セクションで、サービスのセカンダリ IP 範囲を選択します。VPC ネットワーク内の既存のセカンダリ範囲を使用することも、自動作成範囲を使用することもできます。
[ネットワークの種類] セクションで、[Private IP environment] オプションを選択してプライベート IP 環境を作成します。
[Composer の接続] セクションで、環境のネットワーク タイプを選択し、環境コンポーネントの IP 範囲を指定します。
Private Service Connect を使用する環境の場合:
Private Service Connect を使用する環境の場合は、[Private Service Connect] を選択します。
[Composer 接続のサブネットワーク] セクションで、Cloud Composer 接続サブネットワークの IP 範囲を指定します。PSC エンドポイントのアドレスは、この範囲から選択されます。カスタム範囲を指定するか、デフォルトの範囲を選択できます。
VPC ピアリングを使用する環境の場合:
VPC ピアリングを使用する環境の場合は、[VPC ピアリング] を選択します。
[Composer テナント ネットワークの IP 範囲] セクションで、Cloud Composer テナント ネットワークの IP 範囲を指定します。このネットワークによって、環境の SQL プロキシ コンポーネントがホストされます。カスタム範囲を指定するか、デフォルトの範囲を選択できます。
[Cloud SQL ネットワークの IP 範囲] で、Cloud SQL インスタンスの IP 範囲を指定します。カスタム範囲を指定するか、デフォルトの範囲を選択できます。
[GKE コントロール プレーン ネットワークの IP 範囲] セクションで、GKE コントロール プレーンの IP 範囲を指定します。
環境が配置されているリージョンにデフォルトの IP 範囲を使用するには、[デフォルトの IP 範囲] を選択します。
カスタム IP 範囲を指定するには、[カスタム IP 範囲] を選択して、[GKE クラスタ マスターのプライベート IP] フィールドに CIDR 表記で範囲を入力します。
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-ip-masq-agentは、IP マスカレード エージェントを有効にします。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--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 環境のトラフィックを制限する予定がある場合は、ネットワーク タグを追加するとよいかもしれません。
Console
[環境の作成] ページで次の操作を行います。
- [ネットワークの構成] セクションを見つけます。
- [ネットワーク タグ] フィールドに、使用中の環境のネットワーク タグを入力します。
gcloud
環境を作成する際は、次の引数を使用してネットワーク タグを制御します。
--tagsは、すべてのノード VM に適用されるネットワーク タグのカンマ区切りのリストを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--tags TAGS
以下のように置き換えます。
TAGSは、ネットワーク タグのカンマ区切りのリストに置き換えます。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-2.6.6-airflow-2.6.3 \
--tags group1,production
API
環境を作成するときに、[環境] > [EnvironmentConfig] リソースで環境のネットワーク タグを指定します。
{
"name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
"config": {
"nodeConfig": {
"tags": [
"TAG"
]
}
}
}
以下のように置き換えます。
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"
]
}
}
}
Terraform
環境を作成する際は、次のフィールドで環境のネットワーク タグを定義します。
node_configブロックのtagsフィールドは、すべてのノード VM に適用されるネットワーク タグのカンマ区切りのリストを指定します。
resource "google_composer_environment" "example" {
provider = google-beta
name = "ENVIRONMENT_NAME"
region = "LOCATION"
config {
node_config {
tags = ["TAGS"]
}
}
}
以下のように置き換えます。
TAGSは、ネットワーク タグのカンマ区切りのリストに置き換えます。
例:
resource "google_composer_environment" "example" {
provider = google-beta
name = "example-environment"
region = "us-central1"
config {
node_config {
tags = ["group1","production"]
}
}
}
手順 9. （省略可）ウェブサーバーへのネットワーク アクセスを構成する
Airflow ウェブサーバーのアクセス パラメータは、環境の種類に依存しません。代わりに、ウェブサーバーのアクセスを個別に構成できます。たとえば、プライベート IP 環境で、引き続きインターネットから Airflow UI にアクセスできます。
現時点では、プライベート IP アドレスを使用しての許可された IP 範囲を構成することはできません。
Console
[環境の作成] ページで次の操作を行います。
[ネットワークの構成] セクションで、[ネットワーク構成を表示] 項目を展開します。
[ウェブサーバーのネットワーク アクセス制御] セクションで、次の操作を行います。
すべての 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.6.6-airflow-2.6.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-2.6.6-airflow-2.6.3 \
--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"
}
]
}
}
}
以下のように置き換えます。
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"
}
]
}
}
}
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"
}
}
}
}
以下のように置き換えます。
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"
}
}
}
手順 10. （省略可）Airflow 構成のオーバーライドと環境変数を指定する
Airflow 構成のオーバーライドと環境変数は、環境を作成するときに設定できます。あるいは、環境を作成した後に行うこともできます。
一部の Airflow 構成オプションはブロックされているため、オーバーライドすることはできません。
使用可能な Airflow 構成オプションの一覧については、Airflow 2 の構成リファレンスと Airflow 1.10.* をご覧ください。
Airflow 構成のオーバーライドと環境変数を指定するには:
Console
[環境の作成] ページで次の操作を行います。
[環境変数] セクションで、[環境変数を追加] をクリックします。
環境変数の [名前] と [値] を入力します。
[Airflow 構成のオーバーライド] セクションで、[AIRFLOW 構成のオーバーライドを追加] をクリックします。
構成オプションをオーバーライドする [セクション]、[キー]、[値] を入力します。
次に例を示します。
セクション キー 値 webserverdag_orientationTB
gcloud
環境変数と Airflow 構成のオーバーライドは、環境を作成するときに、次の引数によって制御されます。
--env-variablesは、環境変数のカンマ区切りリストを指定します。変数名には大文字と小文字、数字、アンダースコアを使用できますが、先頭に数字を配置することはできません。
--airflow-configsは、Airflow 構成のオーバーライドのキーと値のカンマ区切りのリストを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--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.6.6-airflow-2.6.3 \
--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",
}
}
}
}
以下のように置き換えます。
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"
}
}
}
}
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"
}
}
}
}
以下のように置き換えます。
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"
}
}
}
}
手順 11. （省略可）メンテナンスの時間枠を指定する
デフォルトでは、メンテナンスの時間枠は、毎週金曜日、土曜日、日曜日の 00:00:00～04:00:00（GMT）です。
環境のメンテナンスの時間枠を定義するには、次のようにします。
Console
[環境の作成] ページで次の操作を行います。
[タイムゾーン] プルダウン リストで、メンテナンスの時間枠のタイムゾーンを選択します。
[開始時刻]、[日]、[長さ] を設定して、指定したスケジュールの組み合わせ時刻が少なくとも 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.6.6-airflow-2.6.3 \
--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.6.6-airflow-2.6.3 \
--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"
}
}
}
以下のように置き換えます。
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"
}
}
}
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"
}
}
}
以下のように置き換えます。
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 で構成されていません。
顧客管理の暗号鍵（CMEK）が環境で有効になっていません。データリネージでは、取り込まれたメタデータの CMEK はサポートされていません。CMEK を使用する Cloud Composer 環境では、データリネージ統合を有効にできません。詳細とその他の制限については、データリネージの考慮事項をご覧ください。
データリネージ統合は、環境を作成する際に無効にできます。たとえば、自動動作をオーバーライドする場合や、環境の作成後にデータリネージを有効にすることを選択する場合などです。
コンソール
データリネージ統合を無効にするには、[環境の作成] ページで次の操作を行います。
[詳細設定] セクションで、[詳細設定を表示] 項目を展開します。
[Dataplex データリネージ統合] セクションで、[Dataplex データリネージとの統合を無効にする] を選択します。
gcloud
環境を作成するときに、--disable-cloud-data-lineage-integration 引数はデータリネージ統合を無効にします。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--disable-cloud-data-lineage-integration
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前にする。名前は先頭を小文字にして、その後に 62 文字以下の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。環境名は環境のサブコンポーネントの作成に使用されるため、Cloud Storage バケット名としても有効な名前を指定する必要があります。制限事項の一覧については、バケットの命名ガイドラインをご覧ください。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-2.6.6-airflow-2.6.3 \
--disable-cloud-data-lineage-integration
ステップ 13。（省略可）データ暗号化を構成する（CMEK）
デフォルトでは、環境内のデータは Google が提供する鍵で暗号化されます。
顧客管理の暗号鍵（CMEK）を使用して環境内のデータを暗号化するには、顧客管理の暗号鍵の使用で概説している手順に沿って操作してください。
ステップ 14.（省略可）カスタム環境のバケットを使用する
環境を作成すると、Cloud Composer によってその環境のバケットが自動的に作成されます。
代わりに、プロジェクトからカスタム Cloud Storage バケットを指定することもできます。環境では、自動的に作成されたバケットと同じ方法でこのバケットが使用されます。
カスタム環境バケットを使用するには、カスタム環境のバケットを使用するで説明されている手順に従ってください。
ステップ 15.（省略可）環境ラベルを指定する
環境にラベルを割り当てると、ラベルに基づいて請求額の内訳を調べることができます。
Console
[環境の作成] ページの [ラベル] セクションで、次のようにします。
[ラベルを追加] をクリックします。
[キー] フィールドと [値] フィールドで、環境ラベルのキーと値のペアを指定します。
gcloud
環境を作成するときに、--labels 引数が環境ラベルを含むキーと値のカンマ区切りのリストを指定します。
gcloud composer environments create ENVIRONMENT_NAME \
--location LOCATION \
--image-version composer-2.6.6-airflow-2.6.3 \
--labels LABELS
以下のように置き換えます。
LABELSは、環境ラベルのカンマ区切りのKEY=VALUEペアのリストに置き換えます。
例:
gcloud composer environments create example-environment \
--location us-central1 \
--image-version composer-2.6.6-airflow-2.6.3 \
--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"
}
}
次のステップ
- 環境作成のトラブルシューティング
- プライベート IP Cloud Composer 環境の構成
- 共有 VPC の構成
- VPC Service Controls の構成
- DAG の追加と更新
- Airflow UI へのアクセス
- 環境の更新と削除
- Cloud Composer のバージョンについて