Composer ローカル開発 CLI ツールを使用してローカルの Airflow 環境を実行する

Managed Airflow（第 3 世代） | Managed Airflow（第 2 世代） | Managed Airflow（以前の第 1 世代）

ここでは、Composer ローカル開発 CLI ツールを使用して、ローカルの Airflow 環境を作成、構成、実行する方法について説明します。

Composer ローカル開発 CLI ツールの概要

Composer ローカル開発 CLI ツールは、Airflow 環境をローカルで実行することにより、Managed Airflow 向けの Apache Airflow DAG 開発を合理化します。このローカルの Airflow 環境では、特定の Managed Airflow バージョンで使用される Managed Airflow イメージが使用されます。

既存の Managed Airflow 環境に基づいてローカルの Airflow 環境を作成できます。この場合、ローカルの Airflow 環境はインストールされている PyPI パッケージと環境変数名のリストを Managed Airflow 環境から取得します。

このローカルの Airflow 環境は、テストや開発を目的として使用できます。たとえば、新しい DAG コード、PyPI パッケージ、Airflow 構成オプションをテストするなどです。

警告: ローカルの Airflow 環境は、テストと開発の目的でのみ使用してください。Managed Airflow では、ローカルでデプロイされた Managed Airflow イメージの本番環境目的での使用はサポートされていません。

始める前に

• Composer ローカル開発 CLI ツールは、composer-dev create コマンドを実行するディレクトリにローカルの Airflow 環境を作成します。後でローカルの Airflow 環境にアクセスするには、最初にローカル環境を作成したパスでツールコマンドを実行します。ローカル環境用のデータはすべて、ローカル環境を作成したパスのサブディレクトリ ./composer/<local_environment_name> に保存されます。

• パソコンに、Managed Airflow イメージを保存するのに十分なディスク容量が必要です。Composer ローカル開発 CLI ツールは、Managed Airflow のバージョンごとに 1 つのイメージ ファイルを保存します。たとえば、Managed Airflow のバージョンが異なる 2 つのローカル Airflow 環境がある場合、Composer ローカル開発 CLI ツールは 2 つの Managed Airflow イメージを保存します。

• Composer ローカル開発 CLI ツールの出力は色付きです。NO_COLOR=1 の変数 NO_COLOR=1 composer-dev <other commands> を使用することで、色付きの出力を無効にできます。

• ローカル環境が 1 つしかない場合は、run-airflow-cmd を除くすべての composer-dev コマンドでローカル環境の名前を省略できます。

• Composer ローカル開発 CLI ツールの依存関係をインストールします。

  • Python バージョン 3.8 ～ 3.11（pip を使用）
  • Google Cloud CLI

• Docker（Linux/macOS/Windows）または Podman（Linux または Windows）がパソコンにインストールされ、実行されている必要があります。

  Docker または Podman が実行されていることを確認するには、docker ps や podman ps などの Docker CLI または Podman CLI コマンドを実行します。特に指定がない限り、すべての手順は Docker と Podman の両方に適用されます。また、Docker コマンドは同等の Podman コマンドに置き換えることができます。

認証情報の構成

まだ取得していない場合は、アプリケーションのデフォルト認証情報に使用する新しいユーザー認証情報を取得します。

gcloud auth application-default login

Google アカウントを使用して gcloud CLI にログインします。

gcloud auth login

Composer ローカル開発 CLI ツールと DAG によって行われる API 呼び出しはすべて、gcloud CLI で使用するアカウントから実行されます。たとえば、ローカル Airflow 環境の DAG が Cloud Storage バケットの内容を読み取る場合、このアカウントにはバケットにアクセスするための権限が必要です。この点は、環境のサービス アカウントが呼び出しを行う Managed Airflow 環境とは異なります。

Composer ローカル開発 CLI ツールをインストールする

Composer ローカル開発 CLI リポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/composer-local-dev.git

クローン作製されたリポジトリの最上位ディレクトリで、次のコマンドを実行します。

pip install .

pip の構成によっては、ツールのインストール パスが PATH 変数に含まれていない場合があります。その場合は、pip によって警告メッセージが表示されます。この警告メッセージの情報をもとに、このディレクトリをオペレーティング システムの PATH 変数に追加できます。

（Podman）Podman を構成する

Podman を使用している場合は、次の手順で構成します。

Linux

1. Podman ユーザー サービス ソケットを有効にします。

   composer-dev CLI は、標準の Docker API 呼び出しを介して通信します。Docker デーモンを模倣するには、ユーザーレベルで Podman のバックグラウンド サービス ソケット ラッパーを有効にする必要があります。

   まず、ユーザーレベルのソケットがすでにアクティブかどうかを確認します。

   systemctl --user is-active podman.socket
   

   コマンドが inactive または failed を返す場合は、ソケットを有効にして起動します。

   # Enable and start Podman's user-level systemd socket
   systemctl --user enable --now podman.socket
   

2. Podman の環境変数を構成します。

   シェル構成ファイル（.bashrc や .zshrc など）に次のコマンドを追加します。

   export DOCKER_HOST="unix:///run/user/$UID/podman/podman.sock"
   

Windows

1. WSL 2 構成を設定します（.wslconfig）。Podman マシンを初期化する前に、WSL 2 にメモリとスワップの境界が定義されていることを確認します。これがないと、マルチコンテナ デプロイでイメージ抽出中にメモリが急増する可能性があります。同時ダウンロード数の上限を設定することも重要です。

   %USERPROFILE%\.wslconfig ファイルを変更または作成します。

   [wsl2]
   memory=4GB
   swap=2GB
   
   [registry]
   max_concurrent_downloads = 2
   

2. PowerShell で Podman マシンを初期化します。

   podman machine init
   

3. マシンを起動します。

   podman machine start
   

これらの手順を完了すると、composer-dev CLI コマンドを使用できるようになります。このツールは、Windows で Podman 環境を自動的に検出し、アーキテクチャ マッピングを調整します。

Managed Airflow イメージを使用してローカルの Airflow 環境を作成する

使用可能な Managed Airflow イメージを一覧表示するには、次のコマンドを実行します。

composer-dev list-available-versions --include-past-releases --limit 10

デフォルトのパラメータでローカルの Airflow 環境を作成するには、次のコマンドを実行します。

composer-dev create \
  --from-image-version IMAGE_VERSION \
  LOCAL_ENVIRONMENT_NAME

他のパラメータ:

composer-dev create LOCAL_ENVIRONMENT_NAME \
  --from-image-version IMAGE_VERSION \
  --project PROJECT_ID \
  --port WEB_SERVER_PORT \
  --dags-path LOCAL_DAGS_PATH \
  --plugins-path LOCAL_PLUGINS_PATH \
  --database DATABASE_ENGINE \
  --editable-dependencies EDITABLE_DEPENDENCY_PATH

次のように置き換えます。

• LOCAL_ENVIRONMENT_NAME は、このローカル Airflow 環境の名前に置き換えます。
• IMAGE_VERSION は、Managed Airflow イメージの名前に置き換えます。
• PROJECT_ID は、プロジェクト ID に置き換えます。
• WEB_SERVER_PORT は、Airflow ウェブサーバーがリッスンするポートに置き換えます。
• LOCAL_DAGS_PATH は、DAG ファイルが配置されているローカル ディレクトリのパスに置き換えます。
• LOCAL_PLUGINS_PATH は、プラグイン ファイルが配置されているローカル ディレクトリのパスに置き換えます。

• DATABASE_ENGINE: 使用するデータベース エンジン。有効な値は postgresql（デフォルト）と sqlite です。

  注: LocalExecutor を Airflow の Core Executor として使用する場合は、DATABASE_ENGINE を postgresql に設定します。これは LocalExecutor が正しく動作するために必要です。

• （Linux/macOS のみ）編集可能モードでインストールする Python パッケージを含むローカル ディレクトリへのパスを含む EDITABLE_DEPENDENCY_PATH。この引数は Windows ではサポートされていません。

  パスは絶対パスまたは相対パスにできます（相対パスは現在の作業ディレクトリに対して解決されます）。このディレクトリには、コンテナ エンジンからアクセスできる必要があります。

  複数の編集可能なパッケージを指定するには、このオプションを繰り返します。例: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2。

  pip install -e を使用してパッケージをインストールすると、プロジェクト内のこれらのパッケージに変更が直ちに適用されます。

例:

composer-dev create \
  --from-image-version composer-2.17.11-airflow-2.11.1 \
  example-local-environment

Managed Airflow 環境からローカルの Airflow 環境を作成する

注意: Composer ローカル開発 CLI ツールは、Managed Airflow 環境のローカルコピーを生成しません。

Managed Airflow 環境から次の情報のみが取得されます。

• 環境で使用されている Managed Airflow と Airflow のバージョン。

• 使用する環境にインストールされているカスタム PyPI パッケージのリスト。

• 使用する環境に設定された環境変数の名前のコメント化されたリスト。

  重要: Managed Airflow では、環境変数の値はコピーされません。必要に応じて手動で構成ファイルの環境変数のコメント化を解除し、値を設定してください。

環境からのその他の情報や構成パラメータ（DAG ファイル、DAG 実行履歴、Airflow 変数、接続など）は Managed Airflow 環境からコピーされません。

既存の Managed Airflow 環境からローカルの Airflow 環境を作成するには:

composer-dev create LOCAL_ENVIRONMENT_NAME \
    --from-source-environment ENVIRONMENT_NAME \
    --location LOCATION \
    --project PROJECT_ID \
    --port WEB_SERVER_PORT \
    --dags-path LOCAL_DAGS_PATH \
    --plugins-path LOCAL_PLUGINS_PATH \
    --database DATABASE_ENGINE \
    --editable-dependencies EDITABLE_DEPENDENCY_PATH

次のように置き換えます。

• LOCAL_ENVIRONMENT_NAME は、ローカル Airflow 環境の名前に置き換えます。
• ENVIRONMENT_NAME は、Managed Airflow 環境の名前に置き換えます。
• LOCATION は、Managed Airflow 環境が配置されているリージョンに置き換えます。
• PROJECT_ID は、プロジェクト ID に置き換えます。
• WEB_SERVER_PORT は、ローカル Airflow ウェブサーバー用のポートに置き換えます。
• LOCAL_DAGS_PATH は、DAG が配置されているローカル ディレクトリのパスに置き換えます。
• LOCAL_PLUGINS_PATH は、プラグイン ファイルが配置されているローカル ディレクトリへのパスに置き換えます。

• DATABASE_ENGINE: 使用するデータベース エンジン。有効な値は postgresql（デフォルト）と sqlite です。

  注: LocalExecutor を Airflow の Core Executor として使用する場合は、DATABASE_ENGINE を postgresql に設定します。これは LocalExecutor が正しく動作するために必要です。

• （Linux/macOS のみ）編集可能モードでインストールする Python パッケージを含むローカル ディレクトリへのパスを含む EDITABLE_DEPENDENCY_PATH。この引数は Windows ではサポートされていません。

  パスは絶対パスまたは相対パスにできます（相対パスは現在の作業ディレクトリに対して解決されます）。このディレクトリには、コンテナ エンジンからアクセスできる必要があります。

  複数の編集可能なパッケージを指定するには、このオプションを繰り返します。例: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2。

  pip install -e を使用してパッケージをインストールすると、プロジェクト内のこれらのパッケージに変更が直ちに適用されます。

例:

composer-dev create example-local-environment \
  --from-source-environment example-environment \
  --location us-central1 \
  --project example-project \
  --port 8081 \
  --dags-path ./example_directory/dags \
  --plugins-path ./example_directory/plugins \
  --database postgresql \
  --editable-dependencies ./pkg1

ローカルの Airflow 環境を起動する

ローカルの Airflow 環境を起動するには、次のコマンドを実行します。

composer-dev start LOCAL_ENVIRONMENT_NAME

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

• LOCAL_ENVIRONMENT_NAME は、ローカル Airflow 環境の名前に置き換えます。

ローカルの Airflow 環境を停止または再起動する

ローカルの Airflow 環境を再起動すると、Composer ローカル開発 CLI ツールは、環境が実行されている Docker コンテナを再起動します。Airflow コンポーネントはすべて停止され、再起動されます。その結果、再起動中に実行されたすべての DAG 実行が失敗としてマークされます。

停止したローカルの Airflow 環境を再起動または起動するには、次のコマンドを実行します。

composer-dev restart LOCAL_ENVIRONMENT_NAME

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

• LOCAL_ENVIRONMENT_NAME は、ローカル Airflow 環境の名前に置き換えます。

ローカルの Airflow 環境を停止するには、次のコマンドを実行します。

composer-dev stop LOCAL_ENVIRONMENT_NAME

注: stop コマンドによってローカルの Airflow 環境が削除されることはありません。

DAG を追加および更新する

DAG は、ローカルの Airflow 環境を作成したときに --dags-path パラメータで指定したディレクトリに保存されます。デフォルトでは、このディレクトリは ./composer/<local_environment_name>/dags です。環境で使用されるディレクトリは、describe コマンドで取得できます。

DAG を追加および更新するには、このディレクトリ内のファイルを変更します。ローカルの Airflow 環境を再起動する必要はありません。

ローカル Airflow 環境のログを表示する

ローカルの Airflow 環境を実行している Docker コンテナの最近のログを表示できます。そうすることで、コンテナ関連のイベントをモニタリングし、PyPI パッケージのインストールに起因する依存関係の競合などのエラーを Airflow ログで確認できます。

注: Composer ローカル開発 CLI ツールによって、DAG 実行ログとタスクログがファイルに書き込まれることはありません。これらのログは、ローカル Airflow 環境の Airflow UI で確認できます。

ローカル Airflow 環境を実行している Docker コンテナのログを表示するには、次のコマンドを実行します。

composer-dev logs LOCAL_ENVIRONMENT_NAME --max-lines 10

ログストリームをフォローするには、--max-lines 引数を省略します。

composer-dev logs LOCAL_ENVIRONMENT_NAME

Airflow CLI コマンドを実行する

ローカル Airflow 環境で Airflow CLI コマンドを実行できます。

注: このコマンドの構文は、Airflow CLI コマンド用の Google Cloud CLI 構文とは異なります。

Airflow CLI コマンドは次のように実行します。

composer-dev run-airflow-cmd LOCAL_ENVIRONMENT_NAME \
  SUBCOMMAND SUBCOMMAND_ARGUMENTS

例:

composer-dev run-airflow-cmd example-local-environment dags list -o table

ローカルの Airflow 環境を構成する

Composer ローカル開発 CLI ツールは、ローカル Airflow 環境用の構成パラメータ（環境変数や PyPI パッケージの要件など）をローカル環境のディレクトリ（./composer/<local_environment_name>）に保存します。

構成はローカル Airflow 環境の起動時に適用されます。たとえば、競合する PyPI パッケージ要件を追加した場合、ローカル環境を起動したときに Composer ローカル開発 CLI ツールからエラーが報告されます。

重要: Composer ローカル開発 CLI ツールによって、このディレクトリに airflow.cfg ファイルが格納されることはありません。このファイルは、環境の Docker イメージにあります。Airflow 構成オプションは、環境変数を構成することで変更できます。

Airflow 接続は、ローカル Airflow 環境のデータベースに格納されます。構成を行うには、Airflow CLI コマンドを実行するか、接続パラメータを環境変数に格納します。接続を作成して構成する方法の詳細については、Airflow ドキュメントの接続の管理をご覧ください。

ローカルの Airflow 環境のリストとステータスを取得する

利用可能なすべてのローカル Airflow 環境を一覧表示してステータスを表示するには:

composer-dev list

特定の環境を記述し、環境のイメージのバージョン、DAG パス、ウェブサーバー URL などの詳細を取得するには、次のコマンドを実行します。

composer-dev describe LOCAL_ENVIRONMENT_NAME

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

• LOCAL_ENVIRONMENT_NAME は、ローカル Airflow 環境の名前に置き換えます。

ローカル Airflow 環境で使用されるイメージを一覧表示する

Composer ローカル開発 CLI ツールで使用されるすべてのイメージを一覧表示するには、次のコマンドを実行します。

docker images --filter=reference='*/cloud-airflow-releaser/*/*'

プラグインをインストールしてデータを変更する

ローカルの Airflow 環境のプラグインとデータは、ローカル環境のディレクトリ（./composer/<local_environment_name>/data と ./composer/<local_environment_name>/plugins）から取得されます。

/data ディレクトリと /plugins ディレクトリの内容を変更するには、これらのディレクトリでファイルを追加または削除します。Docker により、ファイルの変更内容がローカルの Airflow 環境に自動的に伝播されます。

Composer ローカル開発 CLI ツールを使って、データとプラグインに別個のディレクトリを指定することはできません。

環境変数を構成する

環境変数を構成するには、環境ディレクトリ ./composer/<local_environment_name>/variables.env にある variables.env ファイルを編集します。

注意: 安全策として、Managed Airflow 環境から環境変数の値はコピーされず、変数名のリストはコメント化されます。たとえば、DAG が本番環境で機能しないように異なる値を指定したり、一部の変数の設定を省略したりできます。

variables.env ファイルには、環境変数ごとに 1 行の Key-Value 定義を配置する必要があります。Airflow 構成オプションを変更するには、AIRFLOW__SECTION__KEY 形式を使用します。使用可能な環境変数の詳細については、Airflow 構成リファレンスをご覧ください。

EXAMPLE_VARIABLE=True
ANOTHER_VARIABLE=test
AIRFLOW__WEBSERVER__DAG_DEFAULT_VIEW=graph

変更を適用するには、ローカルの Airflow 環境を再起動します。

PyPI パッケージをインストールまたは削除する

PyPI パッケージをインストールまたは削除するには、環境ディレクトリ ./composer/<local_environment_name>/requirements.txt にある requirements.txt ファイルを変更します。

要件は PEP-508 で指定された形式に従う必要があります。各要件は、小文字で指定され、オプションの追加情報とバージョン指定子とともにパッケージ名で構成されます。

変更を適用するには、ローカルの Airflow 環境を再起動します。

別の Managed Airflow イメージに切り替える

Composer ローカル開発 CLI ツールで任意の Managed Airflow イメージを使用し、イメージを切り替えることができます。このアプローチは Managed Airflow 環境のアップグレードとは異なり、起動時にローカルの Airflow 環境の構成パラメータが適用されます。

たとえば、新しい Managed Airflow バージョンがリリースされたら、環境を切り替えて新しいバージョンを使用し、既存のローカルの Airflow 環境構成を維持できます。別の例として、特定の Managed Airflow バージョン内の別の Airflow バージョンに切り替えることもできます。

ローカルの Airflow 環境で使用される環境のイメージを変更するには:

1. ローカル環境の構成ファイル ./composer/<local_environment_name>/config.json を編集します。

2. composer_image_version パラメータの値を変更します。使用可能な値を表示するには、使用可能なイメージを一覧表示します。

3. 変更を適用するには、ローカルの Airflow 環境を再起動します。

ローカルの Airflow 環境を削除する

注意: ログや構成など、環境から取得した必要なデータはすべて保存しておいてください。

ローカルの Airflow 環境を削除するには、次のコマンドを実行します。

composer-dev remove LOCAL_ENVIRONMENT_NAME

環境が実行中の場合は、--force フラグを追加して強制的に削除します。

Docker イメージを削除する

Composer ローカル開発 CLI ツールによってダウンロードされたすべてのイメージを削除するには、次のコマンドを実行します。

docker rmi $(docker images --filter=reference='*/cloud-airflow-releaser/*/*' -q)

追加の構成とトラブルシューティング

このセクションでは、Composer ローカル開発 CLI ツールと他のツールやサービスとの連携を構成する際の一般的な問題の解決策と追加の構成手順について説明します。

シェル タブ補完

composer-dev CLI は、Bash、Zsh、Fish シェルのタブ補完をサポートしています。タブ補完を使用すると、ヘルプテキストを参照しなくても、使用可能なサブコマンドとオプションを見つけることができます。

Zsh

補完スクリプトを生成し、~/.zshrc でソースコードを取得します。

_COMPOSER_DEV_COMPLETE=zsh_source composer-dev > ~/.composer-dev-complete.zsh

次に、~/.zshrc に追加します。

echo 'source ~/.composer-dev-complete.zsh' >> ~/.zshrc

Bash

補完スクリプトを生成し、~/.bashrc でソースコードを取得します。

_COMPOSER_DEV_COMPLETE=bash_source composer-dev > ~/.composer-dev-complete.bash

次に、~/.bashrc に追加します。

echo 'source ~/.composer-dev-complete.bash' >> ~/.bashrc

魚

補完スクリプトを生成して、Fish 補完ディレクトリに保存します。

_COMPOSER_DEV_COMPLETE=fish_source composer-dev > ~/.config/fish/completions/composer-dev.fish

Kubernetes クラスタとのやり取り

デフォルトでは、ファイル ~/.kube/config はマウントされません。環境を起動する前に KUBECONFIG 環境変数をエクスポートすることで、Kubernetes 構成ファイルのパスを指定できます。

export KUBECONFIG=~/.kube/config

ホストマシン上の他のサービスとのインタラクション

Managed Airflow 環境の localhost は、Docker または Podman コンテナでのネットワークの仕組みにより、ホストマシンではなくコンテナ自体を指しています。便宜上、composer-dev CLI ツールは、host.docker.internal ドメイン エイリアスを介してマシンにアクセスするようにコンテナのネットワークを構成します。例:

• Redis: Redis がポート 6379 で実行されている場合は、localhost:6379 ではなく host.docker.internal:6379 を使用します。
• PostgreSQL: PostgreSQL がポート 25432 で実行されている場合は、localhost:25432 ではなく host.docker.internal:25432 を使用します。
• その他のサービス: 次のパターンに従います: host.docker.internal:<PORT>

注: ターゲット サービスを別の Docker コンテナ内で実行している場合は、ポートがホストマシンにも公開されていることを確認してください。

macOS でローカル環境を起動できない

Docker がアクセスできないディレクトリに composer-dev パッケージをインストールした場合、ローカル環境が起動しないことがあります。

たとえば、Python が /opt ディレクトリにインストールされている場合（macOS で Homebrew のデフォルト構成を使用してインストールする場合など）、composer-dev パッケージも /opt ディレクトリにインストールされます。Docker は Apple のサンドボックス ルールに準拠しているため、/opt ディレクトリはデフォルトでは使用できません。また、UI（[設定] > [リソース] > [ファイル共有]）から追加することもできません。

この場合、Composer ローカル開発 CLI ツールは、次の例のようなエラー メッセージを生成します。

Failed to create container with an error: 400 Client Error for ...
Bad Request ("invalid mount config for type "bind": bind source path does not exist:
/opt/homebrew/lib/python3.9/site-packages/composer_local_dev/docker_files/entrypoint.sh

Possible reason is that composer-dev was installed in the path that is
not available to Docker. See...")

次のいずれかの解決策を使用できます。

• Python または composer-dev パッケージを別のディレクトリにインストールして、Docker がパッケージにアクセスできるようにします。
• ~/Library/Group\ Containers/group.com.docker/settings.json ファイルを手動で編集し、filesharingDirectories に /opt を追加します。

ホストからマウントされたファイルとディレクトリへのコンテナ ユーザー アクセス

デフォルトでは、Managed Airflow 環境のコンテナは UID 999 の airflow ユーザーとして実行されます。ユーザーには、ホストからマウントされたファイルとディレクトリ（~/.config/gcloud/application_default_credentials.json など）へのアクセス権が必要です。

報告されている問題:

• google.auth.exceptions.DefaultCredentialsError: Your default credentials were not found: デフォルト ユーザー airflow (999) でコンテナを実行しているときに生成されることがあります。ホスト ディレクトリ ~/.config/gcloud/ に、ユーザーの実行権限がありません。
• [Errno 13] Permission denied: '/home/airflow/.config/gcloud/application_default_credentials.json': デフォルト ユーザー airflow (999) でコンテナを実行しているときに、ホストファイル ~/.config/gcloud/application_default_credentials.json にユーザーの読み取り権限がない場合に生成されることがあります。

Linux または macOS では、composer/<LOCAL_ENVIRONMENT_NAME>/variables.env に COMPOSER_CONTAINER_RUN_AS_HOST_USER=True を追加して、現在のホストユーザーとしてコンテナを実行することをおすすめします。この機能は Windows では使用できないため、コンテナ内のユーザーがアクセスできるように、ホスト上のマウントされたファイルとディレクトリの権限を更新する必要がある場合があります。

（Podman）企業ユーザーの権限エラーまたは lchown エラーを修正

rootless Podman がプライマリの企業ユーザー ID と重複するユーザー Namespace を自動的に割り当てて（lchown: invalid argument エラーや権限エラーが発生する）、しまうのを防ぐには、下位範囲を 400 万ブロックより上に手動でプッシュする必要があります。

1. root 権限で /etc/subuid と /etc/subgid を開きます（例: sudo nano /etc/subuid）。

2. ユーザー名のエントリを次のように更新または追加します。

   YOUR_USERNAME:4000000:3000000
   

3. 両方のファイルを保存し、次のコマンドを実行して、新しい名前空間マッピング ルールを Podman に適用します。

   podman system migrate
   

（Podman）スタックしたファイルと権限拒否エラーを削除

古いコンテナが存在する間に subuid 範囲を更新すると、現在の Namespace は独自のデータ キャッシュにアクセスできなくなります。

警告: 次のコマンドを実行すると、すべてのボリュームが削除されます。他の作業が保存されている場合は、慎重に進めてください。

ホストレベルの root 権限を使用してローカル ストレージ グラフを強制的にクリアします。

podman rm -fa
podman volume rm --all --force
podman system migrate

（Podman）DNS エラー（「Name or service not known」）を修正

Airflow コンテナが、データベース コンテナ（your-environment-name）のホスト名を変換または解決できないことを示す psycopg2.OperationalError を生成する場合、Podman の内部仮想ブリッジ ネットワークが同期していません。

ランタイム状態をフラッシュし、netavark と aardvark-dns にクリーンなルーティング テーブルを強制的に再生成させます。

警告: 次のコマンドを実行すると、すべてのネットワークが削除されます。他の作業が保存されている場合は、慎重に進めてください。

podman rm -fa
podman network prune --force

rm -rf /run/user/$UID/containers/*
rm -rf /run/user/$UID/netavark/*
rm -rf COMPOSER_LOCAL_DEV_PATH/composer/*

podman system migrate

（Podman）エンジンのステータスを確認する

Podman がワークフローをルートレスで管理し、構成をシステム Docker にバイパスしていないことを確認するには:

1. ネットワーク DNS バックエンドを確認します。

   podman info | grep -A 3 -i "dns"
   

   出力には、backend: netavark と aardvark-dns への有効な実行可能パスが含まれている必要があります。

2. プロセス オーナーシップのマッピングを確認します。環境が実行されたら、ホスト プロセスの所有者を確認します。

   ps -ef | grep -i "postgres"
   

   左端の列に、subuid マップ範囲に対応する大きな UID 番号（4000069 など）が表示され、完全に rootless で実行されていることが証明されます。

（Podman、Windows）デプロイ中のパイプエラーを修正

デプロイ中にデータベースまたは Airflow コンテナがパイプエラーで直ちに終了する場合は、Podman がメモリ上限に達している可能性があります。この問題を解決するには、.wslconfig ファイルでメモリとスワップの制限を増やすことを試してください。

1. PowerShell で次のコマンドを実行して、Podman マシンと WSL 2 仮想マシンを停止します。

   podman machine stop
   wsl --shutdown
   

2. %USERPROFILE%\.wslconfig ファイルを変更して、スワップとメモリの上限を調整します。リファレンスについては、WSL 構成リファレンスをご覧ください。

3. 次のコマンドを実行して、Podman マシンを起動します。

   podman machine start
   

エラーが発生した場合は、Windows の仮想化とネットワーキング スタックのハードリセットを試すことができます。これを行うには、管理者として PowerShell を開き、次のコマンドを実行します。

Restart-Service -Name vmms -Force
Restart-Service -Name hns -Force
wsl --shutdown

次のステップ

• DAG を書き込む
• GitHub から DAG をテスト、同期、デプロイする