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 バージョンで使用される Airflow ビルドイメージが使用されます。
既存の Managed Airflow 環境に基づいてローカルの Airflow 環境を作成できます。この場合、ローカルの Airflow 環境はインストールされている PyPI パッケージと環境変数名のリストを Managed Airflow 環境から取得します。
このローカルの Airflow 環境は、テストや開発を目的として使用できます。たとえば、新しい DAG コード、PyPI パッケージ、Airflow 構成オプションをテストするなどです。
始める前に
Composer ローカル開発 CLI ツールは、次のように Airflow 3 ビルドをサポートしています。
- Airflow 3.3.1 以降のバージョンは、composer-3-airflow-3.3.1-build.0 以降でサポートされています。
- Airflow 3.2.2 は、composer-3-airflow-3.2.2-build.3 以降でサポートされています。
- Airflow 3.1.8 はサポートされていません。
- 以前の Airflow 3 ビルドは、composer-3-airflow-3.1.0-build.8 以降でサポートされています。
Composer ローカル開発 CLI ツールは、
composer-dev createコマンドを実行するディレクトリにローカルの Airflow 環境を作成します。後でローカルの Airflow 環境にアクセスするには、最初にローカル環境を作成したパスでツールコマンドを実行します。ローカル環境用のデータはすべて、ローカル環境を作成したパスのサブディレクトリ./composer/<local_environment_name>に保存されます。パソコンに、Airflow ビルドイメージを保存するのに十分なディスク容量が必要です。Composer ローカル開発 CLI ツールは、Airflow ビルドごとに 1 つのイメージ ファイルを保存します。たとえば、Airflow ビルドが異なる 2 つのローカル Airflow 環境がある場合、Composer ローカル開発 CLI ツールは 2 つの 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
- Python バージョン 3.8 ～ 3.11（
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
Podman ユーザー サービス ソケットを有効にします。
composer-devCLI は、標準の 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.socketPodman の環境変数を構成します。
シェル構成ファイル（
.bashrcや.zshrcなど）に次のコマンドを追加します。export DOCKER_HOST="unix:///run/user/$UID/podman/podman.sock"
Windows
WSL 2 構成を設定します（
.wslconfig）。Podman マシンを初期化する前に、WSL 2 にメモリとスワップの境界が定義されていることを確認します。これがないと、マルチコンテナ デプロイでイメージ抽出中にメモリが急増する可能性があります。同時ダウンロード数の上限を設定することも重要です。%USERPROFILE%\.wslconfigファイルを変更または作成します。[wsl2] memory=4GB swap=2GB [registry] max_concurrent_downloads = 2PowerShell で Podman マシンを初期化します。
podman machine initマシンを起動します。
podman machine start
これらの手順を完了すると、composer-dev CLI コマンドを使用できるようになります。このツールは、Windows で Podman 環境を自動的に検出し、アーキテクチャ マッピングを調整します。
Airflow ビルドイメージを使用してローカルの Airflow 環境を作成する
使用可能な 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は、Airflow ビルドイメージの名前に置き換えます。PROJECT_IDは、プロジェクト ID に置き換えます。WEB_SERVER_PORTは、Airflow ウェブサーバーがリッスンするポートに置き換えます。LOCAL_DAGS_PATHは、DAG ファイルが配置されているローカル ディレクトリのパスに置き換えます。LOCAL_PLUGINS_PATHは、プラグイン ファイルが配置されているローカル ディレクトリのパスに置き換えます。DATABASE_ENGINE: 使用するデータベース エンジン。有効な値はpostgresql（デフォルト）とsqliteです。（Linux/macOS のみ）編集可能モードでインストールする Python パッケージを含むローカル ディレクトリへのパスを含む
EDITABLE_DEPENDENCY_PATH。この引数は Windows ではサポートされていません。パスは絶対パスまたは相対パスにできます（相対パスは現在の作業ディレクトリに対して解決されます）。このディレクトリには、コンテナ エンジンからアクセスできる必要があります。
複数の編集可能なパッケージを指定するには、このオプションを繰り返します。例:
--editable-dependencies ./pkg1 --editable-dependencies ./pkg2。pip install -eを使用してパッケージをインストールすると、プロジェクト内のこれらのパッケージに変更が直ちに適用されます。
例:
composer-dev create \
--from-image-version composer-3-airflow-2.11.1-build.18 \
example-local-environment
Managed Airflow 環境からローカルの Airflow 環境を作成する
Managed Airflow 環境から次の情報のみが取得されます。
環境で使用される特定の Airflow ビルド。
使用する環境にインストールされているカスタム PyPI パッケージのリスト。
使用する環境に設定された環境変数の名前のコメント化されたリスト。
環境からのその他の情報や構成パラメータ（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です。（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
DAG を追加および更新する
DAG は、ローカルの Airflow 環境を作成したときに --dags-path パラメータで指定したディレクトリに保存されます。デフォルトでは、このディレクトリは ./composer/<local_environment_name>/dags です。環境で使用されるディレクトリは、describe コマンドで取得できます。
DAG を追加および更新するには、このディレクトリ内のファイルを変更します。ローカルの Airflow 環境を再起動する必要はありません。
ローカル Airflow 環境のログを表示する
ローカルの Airflow 環境を実行している Docker コンテナの最近のログを表示できます。そうすることで、コンテナ関連のイベントをモニタリングし、PyPI パッケージのインストールに起因する依存関係の競合などのエラーを Airflow ログで確認できます。
ローカル 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 コマンドは次のように実行します。
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 ツールからエラーが報告されます。
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 ファイルを編集します。
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 環境を再起動します。
別の Airflow ビルドイメージに切り替える
Composer ローカル開発 CLI ツールで任意の Airflow ビルドイメージを使用し、イメージを切り替えることができます。このアプローチは Managed Airflow 環境のアップグレードとは異なり、起動時にローカルの Airflow 環境の構成パラメータが適用されます。
たとえば、新しい Airflow ビルドがリリースされたら、環境を切り替えて新しいビルドを使用し、既存のローカルの Airflow 環境構成を維持できます。
ローカルの Airflow 環境で使用される環境のイメージを変更するには:
ローカル環境の構成ファイル
./composer/<local_environment_name>/config.jsonを編集します。composer_image_versionパラメータの値を変更します。使用可能な値を表示するには、使用可能なイメージを一覧表示します。変更を適用するには、ローカルの 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>
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 万ブロックより上に手動でプッシュする必要があります。
root 権限で
/etc/subuidと/etc/subgidを開きます（例:sudo nano /etc/subuid）。ユーザー名のエントリを次のように更新または追加します。
YOUR_USERNAME:4000000:3000000両方のファイルを保存し、次のコマンドを実行して、新しい名前空間マッピング ルールを 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 にバイパスしていないことを確認するには:
ネットワーク DNS バックエンドを確認します。
podman info | grep -A 3 -i "dns"出力には、
backend: netavarkとaardvark-dnsへの有効な実行可能パスが含まれている必要があります。プロセス オーナーシップのマッピングを確認します。環境が実行されたら、ホスト プロセスの所有者を確認します。
ps -ef | grep -i "postgres"左端の列に、subuid マップ範囲に対応する大きな UID 番号（
4000069など）が表示され、完全に rootless で実行されていることが証明されます。
（Podman、Windows）デプロイ中のパイプエラーを修正
デプロイ中にデータベースまたは Airflow コンテナがパイプエラーで直ちに終了する場合は、Podman がメモリ上限に達している可能性があります。この問題を解決するには、.wslconfig ファイルでメモリとスワップの制限を増やすことを試してください。
PowerShell で次のコマンドを実行して、Podman マシンと WSL 2 仮想マシンを停止します。
podman machine stop wsl --shutdown%USERPROFILE%\.wslconfigファイルを変更して、スワップとメモリの上限を調整します。リファレンスについては、WSL 構成リファレンスをご覧ください。次のコマンドを実行して、Podman マシンを起動します。
podman machine start
エラーが発生した場合は、Windows の仮想化とネットワーキング スタックのハードリセットを試すことができます。これを行うには、管理者として PowerShell を開き、次のコマンドを実行します。
Restart-Service -Name vmms -Force
Restart-Service -Name hns -Force
wsl --shutdown