Google CloudのComposerをアップグレードした時のメモ
とあるデータ処理システムでGoogle Cloud Composer + Airflow な環境があり、それを引き継いだのだがAirflowとComposerのイメージバージョンがサポート終了になっており、バージョンアップすることにした（あといくつかのバグフィックス目的）
インフラの管理としてはTerraformを使っており、丁寧に main.tf の中に composer_image_version と言う変数があったのでそれを対応しているバージョンに変更することにした
ある程度ドキュメントを参考にしつつやってみたらいろいろ躓いたのでメモも含めて残しておく。誰かの参考または将来の自分の参考になりそうなので
環境
記述的にこれで全部でいいのかよくわかってない（Airflow/Composer初心者
- Composer 2
- 2.4.5 -> 2.9.10
- Airflow
- 2.5.3 -> 2.9.3
とりあえずComposerもAirflowも環境としてはサポート終了だったっぽいのは確認している
事前準備
公式ドキュメント曰く、アップグレード前にPyPlの対応、DAGのプロバイダパッケージの互換性確認をちゃんとしておく必要がある。あとAirflowの機能の変更等もあるらしい
とりあえずコンソールからPyPlパッケージの互換性確認は済ませた。問題ない様子
Composerのバージョン関係も一応ドキュメントのリスト等で確認した
もっとも、Airflowの知識がほぼないのでもっとチェックすべきところがあったかもしれない。現状は特に問題が出てきていないので多分大丈夫である
そこまで複雑・高機能なことをしていないのと、処理そのものはデータパイプラインでしかなくデータが完全に切り離されているので処理さえ動いてしまえば問題ない。その処理自体も一つのものをバッチのように起動させているだけなので、Airflowの採用自体が割と謎
アップグレード作業
CIでデプロイしようとして失敗
まず Terraform で定義されているバージョンを書き換える
module "composer"{
# ...
#composer_image_version = "composer-2.4.5-airflow-2.5.3" # before
composer_image_version = "composer-2.9.10-airflow-2.9.3"
# ...
}
で、terraform plan を（CIで）実行。すると
Error: Get "http://localhost/api/v1/namespaces/hoge": dial tcp [::1]:80: connect: connection refused
with module.composer.kubernetes_namespace.execute_task_namespace,
on ../../modules/composer/gke_cluster.tf line 27, in resource "kubernetes_namespace" "execute_task_namespace":
27: resource "kubernetes_namespace" "execute_task_namespace" {
（いくつかのパラメータをマスクしています
これはComposerが起動するKubeneters環境が置き換えられることでエンドポイントがデプロイされるまでわからない状態になるためplan時はエラーが発生する（と言う認識であっているのだろうか？）のが原因っぽい
仕方ないので手元で terraform plan -target="module.composer.google_composer_environment.composer_name" コマンドを叩き、同じく target を指定した状態でapplyを叩いて更新することにしました
手元で更新作業が完了後、CIで追ってapplyをかければ最終的に辻褄が合うので完了
手動でapply
……と思ったのですが、terraformのapplyを実行したらまずcomposerの環境削除に30分かかりタイムアウトで止まりました
そもそも更新を行う場合、composerは削除され作り直されるのではないはずなのですがどこかしらの指定があってなかったようです。まあどこかしらと言うかバージョン情報だと思われますが
とにかく更新ではなく削除が行われてそれが途中で止まった以上とりあえずそれを消す必要があります。ただしコンソールは削除中ステータスで動かせないので
$ gcloud composer environments delete composer_name
コマンドを叩くとしばらくしたら消えました
改めて terraform apply --target="~~~" で無事デプロイ完了。追ってCIでもデプロイしたら上手く処理できました
DAGのデプロイ
新規作成になってしまったのでDAGのフォルダが移動してしまっているのを対応する必要があった
幸いDAGのデプロイはCIがgcloudコマンドでDAGフォルダを取得して、そこにアップロードすると言う処理になっており、composerの名前はterraformに記載されている通りと変更されてなかったので手動でCIを動かしてあげれば完了
バージョン変更に伴うのか、一部変数に渡す処理がmoduleだとダメだぞって怒られたのでそこは修正しました。前任者のコードが悪かったようです（人のせいにしていくスタイル。と言うかそんなことできるPythonが一番悪い気がしてる
副作用
バグフィックスしました。やったね
kuberneters の pod operator がログ出力の段階で謎のエラー吐いてたのが治ったのが嬉しい。warningやerrorのログは出来る限り消すべき（前任者はなんで放置したんだ
エラーが起きないアップグレード方法は？
今回のアップグレードはstg環境で起きたので対策として本番環境のアップグレード方法も考えないと同じ対応するのは骨が折れる
ってことで stg の方で Composer バージョンが 2.9.10 から 2.9.11 にアップグレードできそうなので別の方法でやってみることにした
事前準備
同じなので省略。まあComposer側のマイナーバージョンアップなので問題ない
余談だが、2.9.10のアップグレードをTerraformによって行ったわけだが、コンソール上のアップグレード対象に2.9.10はもうなくなっていた。上記手順で一旦Composerが削除されたのはそれが原因かもしれない
コンソール上で先にアップグレードする
コンソール上の環境構成でイメージのバージョン→アップグレードを選択し、対象のComposerのイメージバージョンを選択して更新をかける
ちなみにこの更新処理結構長い。Composer周りはアップグレードしようとするとそこそこ時間がかかるのを想定してた方が良さそう
コンソール上のバージョンをTerraformに記述する
そのまま。当然だが、この変更で terraform plan を実行しても変更はない はず。実際なかった
変更はないのでそのままデプロイしてしまって問題ない
ただし変更後のDAGの動作は確認しておいた方がいい。本番環境デプロイ時はその後のチェックも合わせて行う
結果
ステージングで上記方法を使ってみたところうまく行ったので本番環境も同様にやった
結論から言うと本番環境は特に壊れることもなく変更が完了した
お詫び
前任者への恨み節が多めに出てしまって申し訳ない
Discussion