動機
Heroku、AWS Beanstalk、Azureに同じPythonのアプリをデプロイしてみて、ここまできたらGoogle Cloud Platformでも同じことをやってみるかと思いやってみた。が、他のサービスに比べて圧倒的にややこしかった。
GitHubと連携させるところで随分悩んだが、最終的にとても簡単にできることがわかったので、その顛末をここに記す。
前提
- ローカル、あるいは他のPaaS, IaaSなどで動くことを確認済みのPythonアプリケーションがあること
- 上記アプリがGitHubのリポジトリに上がっていること
- Google Cloud Platformのアカウントがあること
手動でデプロイ
最初はGitHubとの連携はさせず、ローカルから手動でデプロイしてみようと思った。公式のチュートリアル通り、Google Cloud SDKをインストールし、コマンドラインからgcloud app deployでデプロイ。初めはapp.yamlがなくて動かなかったり、app.yamlを追加した後もentrypointのアプリケーション名がappじゃなくてmainになっていてエラーになったりしたが、そのあたりはわりとすぐに解決できた。（エラーログを見つけるのに少々時間がかかったが。）
GitHub連携〜ハマる
じゃあ次はGitHubと連携させてみるかとやってみるが、まずネットでググるとGoogle Cloud RunとGoogle Cloud Buildを使ってGitHubと連携させる方法が出てくる。これがいけなかった。
とりあえず、Cloud Runのサービス作ってGitHubと連携するCloud Buildのトリガーを作ったら、pushのたびにちゃんとトリガーが動いて、正常にデプロイされるんだけど、App Engineの方でWebページを開いてみても一向に反映されず、？？？となる。Cloud Runが何なのかよくわかっていなかったので、App Engineとは別個のものとして動いていることに気づいていなかったのだ。
Cloud Runのサービス詳細ページを見ていて、URLというリンクがあることに気づき、クリックしたら最新のGitHubリポジトリの内容が反映されたページが表示された。ああ、そういうことかとようやく理解する。
公式ドキュメントを見よ
結論としては公式ドキュメントに全て書いてあった。
Cloud Runなんて最初からいらなかったんだ。
https://cloud.google.com/source-repositories/docs/quickstart-triggering-builds-with-source-repositories?hl=ja
必要なのは
Cloud Buildの設定でGAEとの連携を許可、
Cloud Buildでデプロイするための構成情報を記述したcloudbuild.yamlをプロジェクトに追加、
ビルドトリガーを作成し、[ビルド構成] - [Cloud Build 構成ファイル] に上記で作成したcloudbuid.yamlを指定する。
これであとはGitHubのリポジトリにpushするたびに自動的にApp Engineの方にデプロイされる。
なぜ初めからこのページにたどり着けなかったのか・・・。
残る疑問
GitHubにあるソースを動かすんならCloud RunとCloud Buildだけでよくね？という疑問が湧く。
App Engineは何のためにあるんや？他のPaasと同じイメージで使うんならApp EngineとCloud Buildなのかな？
使い分けがわからんです。