|

2024-09-27

データ関連

Cloud Composer のローカル開発環境を構成するための勘所

Google CloudCloud Composer

composer-local-devを使ってCloud Composerのローカル開発環境を作る

Cloud Composerのローカル開発環境をどう行うか

久々の(?) Cloud Composer ネタです。

Cloud Composer に限った話ではないですが、何事もまず開発を行うにあたってはローカルでどう開発環境を作るかを意識するのではないでしょうか。

Cloud Composerでも例に漏れずちゃんとローカル開発環境を構築するためのツールがありますので、今回はそちらのご紹介です。

 

composer-local-dev とは

Cloud Composerのローカル開発環境の構築を可能にするのが、GitHub上で公開されている composer-local-dev です。

GitHub: GoogleCloudPlatform/composer-local-dev

 

Google Cloudの公式ドキュメントでは「Composer ローカル開発 CLI ツールを使用してローカルの Airflow 環境を実行する」としてページが用意されています。

 

導入方法

pip でのインストールが可能ですので、ローカルにリポジトリをcloneしてから各個人の環境にてリポジトリの README.md の通りインストールを行っていただければと思います。

 

poetry 環境で管理している場合は、 pyproject.toml にて

composer-dev = { git = "https://github.com/GoogleCloudPlatform/composer-local-dev.git", rev = "eacc17c" }

のようにリポジトリのアドレス(と必要に応じてリビジョン)を指定すればOKです

 

実行方法

Python 仮想環境にインストールした場合はその環境に入った上で

composer-dev create \ --from-image-version IMAGE_VERSION \ --project PROJECT_ID \ --port WEB_SERVER_PORT \ --dags-path LOCAL_DAGS_PATH \ LOCAL_ENVIRONMENT_NAME

のようにして環境を作り

composer-dev start LOCAL_ENVIRONMENT_NAME

のように実行します。

 

基本的にはイメージのバージョンやDAGフォルダのPathなどの情報とあわせてshellスクリプトとしてまとめてしまうのが良いかと思います。 (バージョンアップ時も対応が楽です)

 

ちなみに

--from-source-environment ENVIRONMENT_NAME

のようなオプションで、 ENVIRONMENT_NAME にCloud Composer環境名を入れれば同じものにしてくれる設定もありますが、確実性の観点から基本的にはバージョンをそのまま指定する運用としています。

 

composer-local-dev の注意点

接続やシークレット変数の扱い

Airflow の中で Varibales や Connections を使っているケースも多くあるかと思います。

 

「Cloud Composer の運用には Secret Manager を組み合わせるのがオススメ」の記事 で触れた通り、これらはすべて本番環境においてはSecret Managerの変数から読み込むことが出来ます。

 

composer-local-dev では作成された環境内の

./composer/<local_environment_name>/variables.env 内に環境変数を配置することで読み込めますので、この中に

AIRFLOW_CONN_GITHUB_DEFAULT=***** AIRFLOW_VAR_NOTION_INTEGRATION_SECRET=****

のようにして環境変数を定義する形で対応しています。

 

Google Cloud側のものを参照する場合は Secret Manager から取り寄せて作成するスクリプトでも用意しておけばいいわけですが

composer-local-dev のリポジトリ内には下記注意書きがあります。

Caution: As a safety measure, values of environment variables are not copied from your Cloud Composer environment, and the list of variable names is commented. For example, you might want to specify different values so that your DAGs do not interact with your production environments, or to omit setting some of the variables.

つまり、安全性の観点からあえてコピーしていないということですね。

 

とはいえ、必要な場面もあるかと思うので、そのあたりはうまく取捨選択しながら取り込む必要があるかと思います。

 

並列での処理は行えない

2024年9月現在、 composer-local-dev はあくまでローカル開発環境用のものなので、並列での処理は対応していません。

 

よって、あくまで動作確認のみの用途となり、並列での処理自体は本番環境で行う必要があります。

 

ちなみに先ほどのGoogle Cloudの公式ドキュメント内にも

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

という記載があります。

 

起動時 timeout するときがある

composer-local-dev は標準では 300秒=5分 のタイムアウトが設定されており、起動まで5分以上経過するとエラー扱いとなります。

 

しかし、環境によっては300秒以上かかることもあるかと思います。

これは、 constants.py の中で定数化されています。 該当ファイルはこちら

 

なので、 lib/composer_local_dev/constants.py の中の

OPERATION_TIMEOUT_SECONDS = ( 300 # TODO: Check if we need such timeout, or any timeout at all )

3003000 など任意の秒数に伸ばすことによってタイムアウト時間を延長することが可能になります。

 

コメントにもあるとおり、ここの数値については検討されているようなので、そのうちなくなっているかもしれませんね。

 

初回起動時にローカルサーバが立ち上がらないときがある

これは環境固有のものかもしれませんが、複数の環境で初回起動時にローカルサーバが立ち上がらないことがあります。これは

composer-dev restart [環境名]

によって再起動すると直ることが多いです。

 

まとめ

今回はCloud Composerのローカル開発環境 composer-local-dev の話でした。

グンと開発しやすくなりますので、個人的には Cloud Composer を使う上では欠かせないツールだと思います。

また、バージョンアップを行う前の動作確認などにも使えるのでとりあえず一度は試してみることをオススメします。

 


この記事の著者

プロフィール画像

伴 拓也

朝日放送グループホールディングス株式会社 DX・メディアデザイン局 デジタル・メディアチーム

アプリケーションからインフラ、ネットワーク、データエンジニアリングまで幅広い守備範囲が売り。最近はデータ基盤の構築まわりに力を入れて取り組む。 主な実績として、M-1グランプリ敗者復活戦投票システムのマルチクラウド化等。