sqldefとcloud runを用いたprivate cloud sqlへのマイグレーション戦略
ハトすけsqldefはコンセプト上マイグレーションファイルが残らない
以下のニーズがでてくる
- マイグレーションファイルの記録をどこかしらに残したい
- チェック後マイグレーションしたい
それをみたしつつどうcloud runにサービスをデプロイするか
ハトすけGitOpsとして
prodブランチ(モノレポの場合prod-serverブランチ)へマージするとデプロイが走るように設定するとする
prodブランチ(モノレポの場合prod-serverブランチ)へプルリクを作成すると以下のCIを走らせる
- イメージの作成
- 必要であればイメージに対して統合テスト
- cloud run jobによるマイグレーション dry-runの結果確認
OKであればマージ
マージすると
- cloud run jobによるマイグレーション実行
- cloud run serviceへのデプロイ
を実行する
ハトすけcloud run jobはcloud run serviceとおなじ環境設定でほぼ利用可能。
つまりcloud run serviceように作ったイメージをマイグレーションように再利用できる。
cloud sqlをプライベートネットワークにおいているといろいろと設定が面倒なので、cloud run serviceで一度設定した環境をコピーできるのは神。
逆に、共通のイメージのなかにschema.sqlとpsql-clientとpsqldefなどをいれておかないと行けない点は注意
ハトすけプライベートなcloud sqlにマイグレーションを実行する方法は他にもある。
cloud buildのprivate poolをcloud sqlとおなじVPC環境下に作成し、cloud buildからそのprivate poolを用いてマイグレーションをする方法。
事前にpsqldefやpsql-clientをインストールしたイメージを利用する。
一番シンプルかもしれない。
自分が選択しなかった理由は、cloud run serviceとおなじ概念を使えるから気に入った
現状の管理方法
- terraformで最初に環境変数を設定したcloud runを作成
- イメージをビルドするcloudbuild.yamlをコードベースに直接置く
- cloud runのリビジョンは設定されていない値は既存のものを受け継ぐので、cloudbuild.yamlに環境変数を欠かなくて良くなる
- prodブランチへのpushでcloud buildが発火し、cloud runのイメージを置き換えたリビジョンを作成
こうするとcloudbuild.yamlにsecret envの設定をしなくてよくなり、コードベースがスッキリする。
これを、マイグレーションにも似たような概念を適用できるのが気に入って cloud run jobを選択。
ハトすけまた cloud run jobにしておけば、
部分的にイメージを選択して再実行をGUIから行うことも可能