このページでは、環境を新しい Airflow バージョンにアップグレードする方法について説明します。
アップグレード操作について
Managed Airflow(Gen 3)では、環境の Managed Airflow のバージョンを管理しません。
- Managed Airflow は、環境のインフラストラクチャ コンポーネントを自動的にアップグレードします。これらのコンポーネントは Managed Airflow の機能に関連しており、Airflow の動作や Airflow DAG の実行方法を変更するものではありません。
- Managed Airflow は、Airflow のバージョンとビルド、Airflow コンポーネント、Airflow ワークロードに密接に関連するコンポーネントを自動的にアップグレードしません。インフラストラクチャ コンポーネントが自動的にアップグレードされた場合、変更されません。
- 新しい Airflow のバージョンまたはビルドに手動でアップグレードできます。
たとえば、アップグレードを行わずに数か月間、同じバージョンと Airflow ビルドを使用でき、環境には環境のインフラストラクチャ コンポーネントの最新の Managed Airflow の更新、修正、改善が適用されます。後で Airflow の新しいバージョンまたはビルドに移行する場合は、環境内の Airflow バージョンをアップグレードします。
Airflow バージョンのアップグレードについて
環境は、次の方法で Airflow のバージョンまたはビルドを変更します。
環境の Airflow のバージョン(とビルド)を制御できます。環境を別のバージョンの Airflow に切り替えることを選択した場合、Airflow のバージョン アップグレード オペレーションを実行できます。たとえば、Airflow の現在のバージョンとビルドのサポートが終了している場合に、これが発生する可能性があります。
Managed Airflow は、指定された Airflow のバージョンとビルドを使用して、環境の Airflow コンポーネントを再デプロイします。
Managed Airflow は、アップグレード前に環境内で Airflow 構成の変更(カスタム PyPI パッケージや Airflow 構成オプションのオーバーライドなど)が行われている場合にそれを適用します。
Managed Airflow は、新しい Cloud SQL データベースを指定するために Airflow
airflow_db接続を更新します。
Airflow のバージョンを変更しても、環境内のリソース(環境のバケットの URL、Airflow ウェブサーバーなど)への接続方法は変わりません。
インフラストラクチャの自動アップグレード オペレーションについて
Managed Airflow は、インフラストラクチャの自動アップグレード オペレーションを定期的に実行します。
インフラストラクチャの自動アップグレード オペレーションは、環境に指定されたメンテナンスの時間枠で定期的に実行されます。
Managed Airflow(第 3 世代)でインフラストラクチャの自動アップグレードを無効にすることはできません。環境にカスタム メンテナンスの時間枠を指定することで、自動アップグレードを実行できる期間を制御できます。
このオペレーションは、他の長時間実行オペレーションと同様に、 Cloud de Confiance コンソールと環境のログに表示されます。オペレーションの実行中は、環境レベルで他のオペレーションを開始できません(ただし、Airflow DAG は引き続き実行できます)。
場合によっては、インフラストラクチャの自動アップグレードによって Airflow コンポーネントが再起動されることがあります。このような再起動中、Airflow ワーカーは 24 時間の猶予期間で正常に終了します。完了までに 24 時間以上かかるタスクがある場合は、遅延可能な演算子の使用を検討してください。アップグレードにより、環境のモニタリングなど、環境のインフラストラクチャ コンポーネントが短期間利用できなくなることがあります。
アップグレード オペレーションとロールバック オペレーションの制限事項
アップグレード オペレーションには次の制限事項があります。
Managed Airflow リリースは、Managed Airflow でサポートされているすべてのリージョンに数日かけて段階的にロールアウトされます。リリース中の最新バージョンは、お住まいの地域ではまだご利用いただけない場合があります。
Managed Airflow(Gen 3)では、次の制限付きで、以前のバージョンまたはビルドの Airflow にアップグレードをロールバックできます。
- ロールバックは、Airflow 3 バージョンからのアップグレード、または airflow-2.7.3-build.0 ビルド以降の Airflow 2 バージョンからのアップグレードでサポートされています。
- ロールバックは、ターゲット バージョン airflow-2.11.1-build.20 以降、airflow-3.2.2-build.7 以降、airflow-3.3.1-build.3 以降へのアップグレードでサポートされています。
- ロールバック オペレーションは、アップグレードから 30 日以内に開始できます。ターゲット Airflow ビルドがサポート終了日を過ぎている場合でも、ロールバックできます。バージョンをスキップしてロールバックできます。30 日以内に複数回アップグレードした場合は、適格性の制約を満たしている限り、以前に使用したバージョンにロールバックできます。
- ロールバックを開始すると、環境は
RUNNING状態になります。
Airflow データベースに 20 GB を超えるデータが含まれている場合は、環境をアップグレードできません。アップグレード中に Airflow データベースのサイズが 20 GB を超えると、警告が表示されます。その場合、データベースのメンテナンスを実行して、データベースのサイズを減らします。
XCom メカニズムを使用してファイルを転送する場合は、Airflow のガイドラインに従って使用するようにしてください。XCom を使用して大きなファイルや大量のファイルを転送すると、Airflow データベースのパフォーマンスに影響し、スナップショットの読み込みや環境のアップグレード時に障害が発生する可能性があります。大量のデータを転送するには、Cloud Storage などの代替手段の使用を検討してください。
始める前に
必要に応じて環境を再作成できるように、環境の新しいスナップショットを作成することをおすすめします。
アカウントには、環境の更新オペレーションをトリガーできるロールが必要です。また、環境のサービス アカウントには、アップグレード オペレーションを実行するための十分な権限を持つロールが必要です。詳しくは、アクセス制御をご覧ください。
環境が最新であることを確認する
Managed Airflow では、環境の Airflow ビルドがサポート終了日に近づくと、警告が表示されます。これらの警告を利用して、環境のサポートを常に維持することができます。
Managed Airflow は、環境の基盤となる Airflow のバージョンとビルドを追跡しています。サポート終了日に近づくと、環境のリストと [環境の詳細] ページに警告が表示されます。
環境が最新かどうかを確認するには、次のようにします。
コンソール
Cloud de Confiance コンソールで、[環境] ページに移動します。
環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。
[環境の設定] タブに移動します。
[イメージのバージョン] フィールドに、次のいずれかのメッセージが表示されます。
最新の使用可能なバージョン。環境イメージが完全にサポートされます。
新しいバージョンがあります。環境イメージが完全にサポートされ、新しいバージョンにアップグレードできます。
このイメージ バージョンのサポートは(特定の日時)に終了します。環境イメージは、完全なサポート期間の終盤に近づいています。
このバージョンは(特定の日時)現在サポートされていません。環境は完全なサポート期間を超えています。
gcloud
この機能は Google Cloud CLI では使用できません。代わりに、推奨されるアップグレードを表示して、利用可能な新しいバージョンを確認できます。
API
この機能は API では使用できません。代わりに、推奨されるアップグレードを表示して、利用可能な新しいバージョンを確認できます。
推奨されるアップグレードを表示する
Managed Airflow には、環境をアップグレードできる Airflow ビルドのリストが用意されています。
アップグレードに推奨される Managed Airflow のバージョンを表示するには:
コンソール
Cloud de Confiance コンソールで、[環境] ページに移動します。
環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。
[環境の構成] タブに移動し、[イメージ バージョンをアップグレード] をクリックします。
推奨されるバージョンの一覧については、Managed Airflow の [画像モード] プルダウン メニューをクリックしてください。
gcloud
gcloud composer environments list-upgrades \
ENVIRONMENT_NAME \
--location LOCATION
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前に置き換えます。LOCATIONは、環境が配置されているリージョン。
例:
gcloud composer environments list-upgrades example-environment \
--location us-central1
API
ロケーションの利用可能なバージョンを表示できます。これを行うには、imageVersions.list API リクエストを作成します。
次に例を示します。
// GET https://composer.googleapis.com/v1/projects/example-project/
// locations/us-central1/imageVersions
PyPI パッケージの競合を確認する
環境にインストールされている PyPI パッケージが、新しい Airflow バージョンまたはビルドにプリインストールされているパッケージと競合していないか確認できます。
チェックにパスするとは、PyPI パッケージの依存関係が、現在のバージョンと指定したバージョンの間で競合していないことを意味します。ただし、他の理由でアップグレード オペレーションが成功しないこともあります。
コンソール
環境のアップグレード チェックを実行するには、次のようにします。
Cloud de Confiance コンソールで、[環境] ページに移動します。
環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。
[ENVIRONMENT CONFIGURATION] タブに移動して [イメージのバージョン] エントリを見つけ、[アップグレード] をクリックします。
[環境バージョンのアップグレード] ダイアログの [新しいバージョン] プルダウン リストで、アップグレードする Airflow のバージョンまたはビルドを選択します。
[PyPI packages compatibility] セクションで、[Check for conflicts] をクリックします。
チェックが完了するまで待ちます。PyPI パッケージの依存関係の競合がある場合、表示されるエラー メッセージに競合するパッケージとパッケージのバージョンの詳細が表示されます。
gcloud
環境のアップグレードチェックを実行するには、アップグレードする Airflow のバージョンまたはビルドで environments check-upgrade コマンドを実行します。
gcloud composer environments check-upgrade \
ENVIRONMENT_NAME \
--location LOCATION \
--airflow-version VERSION
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前に置き換えます。LOCATIONは、環境が配置されているリージョン。VERSIONは、アップグレード先の新しい Airflow バージョンとビルドに置き換えます。形式はairflow-x.y.z-build.tです。 すべてのバージョンのエイリアスを使用できます。
例:
gcloud composer environments check-upgrade example-environment \
--location us-central1 \
--airflow-version airflow-2.11.1-build.21
出力例:
Waiting for [projects/example-project/locations/us-central1/environments/
example-environment] to be checked for PyPI package conflicts when upgrading
to composer-3-airflow-2.11.1-build.21. Operation [projects/example-project/locations/
us-central1/operations/04d0e8b2-...]...done.
...
Response:
'@type': type.googleapis.com/
google.cloud.orchestration.airflow.service.v1.CheckUpgradeResponse
buildLogUri: ...
containsPypiModulesConflict: CONFLICT
pypiConflictBuildLogExtract: |-
The Cloud Build image build failed: Build failed; check build logs for
details. Full log can be found at ...
Error details: tensorboard 2.2.2 has requirement
setuptools>=41.0.0, but you have setuptools 40.3.0.
別の方法としては、アップグレードの確認を非同期で実行できます。--async 引数を使用して非同期呼び出しを行い、gcloud composer operations describe コマンドで結果を確認します。
API
environments.checkUpgrade API リクエストを作成します。
imageVersion フィールドに、イメージのバージョンを指定します。
{
"imageVersion": "VERSION"
}
VERSION は、アップグレード後の新しいバージョン(composer-3-airflow-x.y.z-build.t 形式)に置き換えます。
Managed Airflow(第 3 世代)との競合を確認する
Managed Airflow(第 3 世代)は、Managed Airflow の最新のメジャー バージョンです。Managed Airflow(第 2 世代)環境を Managed Airflow(第 3 世代)にアップグレードできるかどうかは、アップグレード チェックで確認できます。次の説明は、Managed Airflow(Gen 2)環境に適用されます。
Managed Airflow(Gen 2)から Managed Airflow(Gen 3)に環境をインプレースで移行することはできませんが、アップグレード チェックを使用して互換性の問題を確認できます。Managed Airflow(Gen 3)に移行する前に行うことをおすすめします。
Managed Airflow(第 3 世代)との互換性を確認するには、Managed Airflow(第 2 世代)環境の通常のアップグレード チェックを行い、ターゲットとして Managed Airflow(第 3 世代)バージョンを指定します。
報告された各競合には、次のタイプがあります。
BLOCKINGの競合は、Managed Airflow(Gen 3)でサポートされていない、互換性のない環境構成要素を報告します。Managed Airflow(Gen 3)への移行を開始する前に、これらの競合を解決することをおすすめします。NON_BLOCKINGの競合は、Managed Airflow(Gen 3)で異なる環境構成要素を報告し、予期しない動作を引き起こす可能性があります。たとえば、デフォルトのメンテナンスの時間枠などのデフォルト値の変更は、非ブロッキング競合として報告されます。移行プロセスを開始する前に、これらの競合が問題を引き起こす可能性があるかどうかを確認することをおすすめします。PyPI パッケージの競合も、このチェックの一環として報告されます。これらは、通常の PyPI パッケージの互換性チェックと同じ方法で、構成の競合とは別に報告されます。
コンソール
Managed Airflow(Gen 3)との互換性を確認するには、gcloud CLI または Cloud Composer API を使用します。Cloud de Confiance コンソールでは、PyPI パッケージの互換性の確認のみがサポートされています。
gcloud
Managed Airflow(第 3 世代)との互換性を確認するには、environments check-upgrade コマンドを実行し、ターゲットとして Managed Airflow(第 3 世代)のバージョンを指定します。
gcloud composer environments check-upgrade \
ENVIRONMENT_NAME \
--location LOCATION \
--image-version COMPOSER_3_VERSION
次のように置き換えます。
ENVIRONMENT_NAMEを環境の名前に置き換えます。LOCATIONは、環境が配置されているリージョン。COMPOSER_3_VERSIONは、アップグレード先の Airflow バージョンとビルドに置き換えます。形式はairflow-x.y.z-build.tです。すべてのバージョンのエイリアスを使用できます。
例:
gcloud composer environments check-upgrade example-environment \
--location us-central1 \
--image-version composer-3-airflow-2
競合メッセージの例:
...
- message: Error validating property [core]unit_test_mode. Overriding [core]
unit_test_mode is not permitted.
type: BLOCKING
- message: Environment variables [GOOGLE_CLOUD_PROJECT] may not be overridden.
type: BLOCKING
- message: You have to specify Worker CPUs to be 0.5, 1.0 or multiples of 2.0.
type: BLOCKING
- message: The environment uses a default maintenance window, which is
different in Composer 2 and Composer 3. Unless set to a custom value, the
maintenance window will be changed to a new default after the upgrade.
type: NON_BLOCKING
...
別の方法としては、このチェックを非同期で実行できます。--async 引数を使用して非同期呼び出しを行い、gcloud composer operations describe コマンドで結果を確認します。
API
environments.checkUpgrade API リクエストを作成します。
imageVersion フィールドに、イメージのバージョンを指定します。
{
"imageVersion": "COMPOSER_3_VERSION"
}
COMPOSER_3_VERSION は、アップグレード先の Airflow のバージョンとビルドに置き換えます。形式は airflow-x.y.z-build.t です。すべてのバージョンのエイリアスを使用できます。
環境をアップグレードする
環境を Airflow の新しいバージョンまたはビルドにアップグレードするには:
コンソール
Cloud de Confiance コンソールで、[環境] ページに移動します。
環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。
[環境の設定] タブに移動します。
[イメージのバージョン] 項目を見つけて [アップグレード] をクリックします。
[イメージのバージョン] プルダウン メニューから、アップグレードする Airflow のバージョンまたはビルドを選択します。
[アップグレード] をクリックします。
gcloud
gcloud composer environments update \
ENVIRONMENT_NAME \
--location LOCATION \
--airflow-version VERSION
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前に置き換えます。LOCATIONは、環境が配置されているリージョン。VERSIONは、アップグレード先の新しい Airflow バージョンとビルドに置き換えます。形式はairflow-x.y.z-build.tです。 すべてのバージョンのエイリアスも使用できます。
次に例を示します。
gcloud composer environments update \
example-environment \
--location us-central1 \
--airflow-version airflow-2.11.1-build.21
API
environments.patchAPI リクエストを作成します。このリクエストで次のように操作します。
updateMaskパラメータで、config.softwareConfig.imageVersionマスクを指定します。リクエストの本文の
imageVersionフィールドに、アップグレード後の新しいバージョンを指定します。
次に例を示します。
// PATCH https://composer.googleapis.com/v1/projects/example-project/
// locations/us-central1/environments/example-environment?updateMask=
// config.softwareConfig.imageVersion
{
"config": {
"softwareConfig": {
"imageVersion": "composer-3-airflow-2.11.1-build.21"
}
}
}
Terraform
config.software_config ブロックの image_version フィールドは、環境の Airflow のバージョンとビルドを制御します。このフィールドで、新しい Airflow のバージョンとビルドを指定します。
resource "google_composer_environment" "example" {
provider = google-beta
name = "ENVIRONMENT_NAME"
region = "LOCATION"
config {
software_config {
image_version = "VERSION"
}
}
}
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前にする。LOCATIONは、環境が配置されているリージョン。VERSIONは、アップグレード先の新しい Airflow バージョンとビルドに置き換えます。形式はairflow-x.y.z-build.tです。 すべてのバージョンのエイリアスも使用できます。
例:
resource "google_composer_environment" "example" {
provider = google-beta
name = "example-environment"
region = "us-central1"
config {
software_config {
image_version = "airflow-2.11.1-build.21"
}
}
}
アップグレードをロールバックする
パフォーマンスの低下、Airflow のバグ、DAG、プラグイン、依存関係との互換性の問題が発生した場合は、環境のアップグレードをロールバックできます。
環境が RUNNING 状態の場合、アップグレード オペレーションから 30 日以内であればアップグレードをロールバックできます。サポート終了日を迎えたバージョンにロールバックすることもできます。詳細については、アップグレードとロールバック オペレーションの制限事項をご覧ください。
1 つのアップグレードをロールバックするだけでなく、次のこともできます。
複数のロールバックを連続して実行します。
例: A > B > C > B > A (B と A へのロールバックが制限事項を満たしている場合)。
バージョン スキップ ロールバックを実行します。
例: A > B > C > A(A へのロールバックが制限事項を満たしている場合)。
ロールバック中、指定されたバージョンに環境の Airflow ビルドのみが戻されます。Managed Airflow は、ロールバック中に環境のデータと状態を保持します。
DAG ファイルと実行履歴: すべての DAG 定義、DAG 実行履歴、タスク インスタンスの状態、XCom はメタデータ データベースにそのまま残ります。
環境構成: Airflow 構成のオーバーライド、環境変数、カスタム PyPI パッケージ、スケーリング設定は保持されます。カスタム PyPI パッケージに厳格でない PyPI パッケージ バージョン要件を使用すると、ロールバック後に環境のパッケージ バージョンが異なる場合があります(このバージョンは、指定されたバージョン要件を満たします)。
アップグレード中に環境構成を変更した場合(環境変数の変更や Airflow コンポーネントのリソース上限の調整など)、これらの変更は元に戻りません。必要に応じて、ロールバックの前後に変更を手動で元に戻すことができます。
ログとモニタリング: Cloud Logging に保存されているタスク実行ログと、Cloud Monitoring の指標履歴は保持されます。
Airflow データベース スキーマの更新(Alembic 移行)は、ターゲット Airflow バージョンのスキーマに合わせて自動的にロールバックされます。各 Airflow バージョンに存在するデータベース移行のリストについては、Airflow ドキュメントの Airflow データベース移行をご覧ください。ロールバック オペレーション中に、現在の Airflow バージョンとターゲット Airflow バージョンの間にリストされているすべての移行がロールバックされます。
以前に使用したバージョンを見つける
以前に使用したバージョンを確認するには:
gcloud
以前に使用した画像モードに関する情報は、オペレーションで確認できます。
gcloud composer operations list \
--locations LOCATION \
--filter='metadata.resource ~ "environments/ENVIRONMENT_NAME$" (metadata.operationType=UPDATE OR metadata.operationType=CREATE)'
次のように置き換えます。
ENVIRONMENT_NAMEを環境の名前に置き換えます。LOCATIONは、環境が配置されているリージョン。
出力には、環境オペレーションのログが含まれます。UPDATE タイプの最後のオペレーションは、ロールバックするアップグレードです。その前にある UPDATE オペレーション(アップグレードが 1 つしかない場合は CREATE)を見つけます。通常、これはリストの最後から 2 番目の項目です。
次の例では、71c3d5c9-5b26-4a98-8b19-7f62e9f4ed51 オペレーションはロールバックするアップグレードで、63da3be2-3acf-4fb4-986a-90552a6df8b3 オペレーションは以前に使用したバージョンへのアップグレードです。
┌──────────────────────────────────────┬───────────────┬─────────────┬──────────────────────────────┬───────────┬─────────────────────────────┐
│ UUID │ TYPE │ LOCATION │ TARGET_ENVIRONMENT │ STATE │ CREATE_TIME │
├──────────────────────────────────────┼───────────────┼─────────────┼──────────────────────────────┼───────────┼─────────────────────────────┤
│ 71c3d5c9-5b26-4a98-8b19-7f62e9f4ed51 │ UPDATE │ us-central1 │ example-environment │ SUCCEEDED │ 2026-10-15T11:18:32.084039Z │
│ 63da3be2-3acf-4fb4-986a-90552a6df8b3 │ UPDATE │ us-central1 │ example-environment │ SUCCEEDED │ 2026-08-15T10:56:10.628514Z │
│ 4ebc18a9-25bb-4325-b4c9-0957c67c078b │ UPDATE │ us-central1 │ example-environment │ SUCCEEDED │ 2026-06-09T11:30:50.922080Z │
│ 8618f807-abb4-4fc8-9f5b-9353079f6e79 │ UPDATE │ us-central1 │ example-environment │ SUCCEEDED │ 2026-05-31T06:57:27.816925Z │
│ 22022864-0fa5-4d1b-92c6-c3f382b43a35 │ UPDATE │ us-central1 │ example-environment │ SUCCEEDED │ 2025-11-17T11:52:36.923698Z │
│ ec5bf071-e6c6-4760-b3c9-4a117cb08f7b │ CREATE │ us-central1 │ example-environment │ SUCCEEDED │ 2025-11-17T11:17:58.133979Z │
└──────────────────────────────────────┴───────────────┴─────────────┴──────────────────────────────┴───────────┴─────────────────────────────┘
オペレーションを記述します。
gcloud composer operations describe OPERATION_UUID \
--location LOCATION \
--format="value(response.config.softwareConfig.imageVersion)"
次のように置き換えます。
OPERATION_UUIDは、前のコマンドで取得した前のアップグレード オペレーションの UUID に置き換えます。LOCATIONは、環境が配置されているリージョン。
このコマンドの出力は、以前に使用されたバージョンです。
ロールバック オペレーションを実行する
環境を以前のビルドまたはバージョンの Airflow にロールバックするには:
コンソール
Cloud de Confiance コンソールでは、アップグレードのロールバックはサポートされていません。代わりに gcloud CLI、API、または Terraform を使用してください。
gcloud
gcloud composer environments update \
ENVIRONMENT_NAME \
--location LOCATION \
--airflow-version VERSION
以下のように置き換えます。
ENVIRONMENT_NAMEを環境の名前に置き換えます。LOCATIONは、環境が配置されているリージョン。VERSIONは、ロールバック先の新しい Airflow バージョンとビルドに置き換えます。形式はairflow-x.y.z-build.tです。ロールバック オペレーションにバージョン エイリアスを使用することはできません。
例:
gcloud composer environments update \
example-environment \
--location us-central1 \
--airflow-version airflow-2.11.1-build.21
API
environments.patchAPI リクエストを作成します。このリクエストで次のように操作します。
updateMaskパラメータで、config.softwareConfig.imageVersionマスクを指定します。リクエストの本文の
imageVersionフィールドに、ロールバック先のバージョンを指定します。
次に例を示します。
// PATCH https://composer.googleapis.com/v1/projects/example-project/
// locations/us-central1/environments/example-environment?updateMask=
// config.softwareConfig.imageVersion
{
"config": {
"softwareConfig": {
"imageVersion": "composer-3-airflow-2.11.1-build.21"
}
}
}
Terraform
config.software_config ブロックの image_version フィールドは、環境の Airflow のバージョンとビルドを制御します。このフィールドで、ロールバック先の Airflow のバージョンとビルドを指定します。
resource "google_composer_environment" "example" {
provider = google-beta
name = "ENVIRONMENT_NAME"
region = "LOCATION"
config {
software_config {
image_version = "VERSION"
}
}
}
次のように置き換えます。
ENVIRONMENT_NAMEを環境の名前に置き換えます。LOCATIONは、環境が配置されているリージョン。VERSIONは、ロールバック先の Airflow バージョンとビルドに置き換えます。形式はairflow-x.y.z-build.tです。ロールバック オペレーションにバージョン エイリアスを使用することはできません。
例:
resource "google_composer_environment" "example" {
provider = google-beta
name = "example-environment"
region = "us-central1"
config {
software_config {
image_version = "airflow-2.11.1-build.21"
}
}
}
ロールバック オペレーションが実行中に失敗した場合、Managed Airflow は自動的に環境をオペレーション前の状態(ロールバックの開始前に使用されていた Airflow のバージョンとビルド)に復元しようとします。トラブルシューティングの詳細については、Cloud Logging でオペレーションのエラー メッセージとログを確認してください。