Cloud Run (Jobs)を活用した マルチプルなプレビュー開発環境の構築

Transcript

1. Cloud Run (Jobs)を活用した マルチプルなプレビュー開発環境の構築
2. © 2022 3-shake Inc. 2 自己紹介 株式会社スリーシェイク / Sreake 事業部 (2021年10月〜)
 事業会社のインフラエンジニア、株式会社ユーザベースのSREとして従事後、 
 株式会社スリーシェイクに入社。日々、クライアントのSRE支援を行っている。 
 過去にGoogle Cloud Anthos DayやKubernetesイベント等に登壇。 
 
 趣味
 ・ボディメイク 
 ・健康
 ・インテリア
 
 生賀一輝
 Shoka Ikki
3. 今日話すこと
4. © 2022 3-shake Inc. 4 既存の開発環境 (1) 開発者がローカルではなく開発ブランチ毎に Google Cloud環境にデプロイしたいというニーズ ※ それぞれのローカル端末で開発
 Kubernetes Cluster GKE Multiple Instances project:dev

5. © 2022 3-shake Inc. 5 既存の開発環境 (2) 開発者がローカルではなく開発ブランチ毎に Google Cloud環境にデプロイしたいというニーズ ※ それぞれのローカル端末で開発
 Kubernetes Cluster GKE Multiple Instances project:dev

6. © 2022 3-shake Inc. 6 既存の開発環境 (3) 開発者がローカルではなく開発ブランチ毎に Google Cloud環境にデプロイしたいというニーズ ※ それぞれのローカル端末で開発
 Kubernetes Cluster GKE Multiple Instances project:dev
 同一環境にデプロイできない 

7. © 2022 3-shake Inc. 7 既存の開発環境 (4) 開発者がローカルではなく開発ブランチ毎に Google Cloud環境にデプロイしたいというニーズ ※ それぞれのローカル端末で開発
 ・開発環境の共有ができない 
 ・develop用の環境が一つしかない 
 ・インフラも含め統合的に確認したい 
 ・バックエンドのみ既存のstaging 
 　環境を使いたい
 
 といったモチベーション 
 Kubernetes Cluster GKE Multiple Instances 同一環境にデプロイできない 
 project:dev

8. © 2022 3-shake Inc. 8 PR stagingを適応した環境 (1) Cloud Runにfeature/**ブランチ（PR）毎に用意する方法 feature/A-add 
 feature/B-add 
 feature/C-modify 
 feature/D-improve 
 Cloud Run Cloud Run Cloud Run Cloud Run project: dev
 Cloud Run Cloud Run
9. © 2022 3-shake Inc. 9 PR stagingを適応した環境 (2) Cloud Runにfeature/**ブランチ（PR）毎に用意する方法 feature/A-add 
 feature/B-add 
 feature/C-modify 
 feature/D-improve 
 Cloud Run Cloud Run Cloud Run Cloud Run project: dev
 Cloud Run Cloud Run 必要無分だけ 環境が作成される PR毎にCloud Runに必要とする環境とエンドポイントが作成され、 開発者はPR毎の環境を必要な分だけ作成できるようになる
10. © 2022 3-shake Inc. 10 次に具体的な方法を説明します
11. 実現方法
12. © 2022 3-shake Inc. 12 PR stagingの実現方法 (1) Cloud Runにfeature/**ブランチ (PR)毎に用意する方法 project: dev
 ①ラベル付きのPR作成 
 PRPreview ②Github Actionsがトリガー
 ③tagが付与されたものが
 　デプロイされる
 service-A
 service-B

13. © 2022 3-shake Inc. 13 PR stagingの実現方法 (2) Cloud Runにfeature/**ブランチ (PR)毎に用意する方法 project: dev
 ①ラベル付きのPR作成
 PR number #541 
 ②Github Actionsがトリガー
 pr-541-service-A-XXXXXXXXXXX-an.a.run.app 
 service-A
 service-B
 service-A-XXXXXXXXXXX-an.a.run.app 
 service-B-XXXXXXXXXXX-an.a.run.app 
 pr-541 PRPreview
14. © 2022 3-shake Inc. 14 PR stagingの実現方法 - ラベル付与時にのみトリガーする Cloud Runにfeature/**ブランチ毎に用意する方法 project: dev
 ①ラベル付きのPR作成
 PR number #541 
 ②Github Actionsがトリガー
 pr-541-service-A-XXXXXXXXXXX-an.a.run.app 
 service-A
 service-B
 service-A-XXXXXXXXXXX-an.a.run.app 
 service-B-XXXXXXXXXXX-an.a.run.app 
 pr-541 PRPreview まずはココ
15. © 2022 3-shake Inc. 15 PR stagingの実現方法 - ラベル付与時にのみトリガーする ② PReviewタグが付与されている 
 ものだけがトリガーされる 
 ① PRのmainブランチにラベル付与時、 
 変更時にトリガーされる 
 pr-staging.yaml PRが出されるたびに必要な環境が作成されないように、 Github Actionsのif(expresions)でLabelが含まれているか評価するようにしている
16. © 2022 3-shake Inc. 16 PR stagingの実現方法 - PR毎に環境をCloud Runに用意する Cloud Runにfeature/**ブランチ毎に用意する方法 project: dev
 ①ラベル付きのPR作成
 PR number #541 
 ②Github Actionsがトリガー
 pr-541-service-A-XXXXXXXXXXX-an.a.run.app 
 service-A
 service-B
 service-A-XXXXXXXXXXX-an.a.run.app 
 service-B-XXXXXXXXXXX-an.a.run.app 
 pr-541 PRPreview つぎはココ
17. © 2022 3-shake Inc. 17 PR stagingの実現方法 - PR毎に環境をCloud Runに用意する pr-staging.yaml Github ActionsのContextsを使用して動いている PRのnumberを取り出し、それを Cloud Runのtagを付与して、エンドポイントを作成するようにしている
18. © 2022 3-shake Inc. 18 pr-staging.yaml PR stagingの実現方法 - PR毎に環境をCloud Runに用意する 既存のstaging環境のトラフィックに 
 PR stagingが向かないようにno_trafficを設定している 
 PR numberを元に 
 Cloud Runのタグを付与する 
 
 ここでは既成のActionsを使用 
 ※Cloud SDKを直接使用しても可能 
 
 Github ActionsのContextsを使用して動いている PRのnumberを取り出し、それを Cloud Runのtagを付与して、エンドポイントを作成するようにしている
19. © 2022 3-shake Inc. 19 PR stagingの実現方法 - 適応後のConsole mainで動いているstaging環境のCloud Run 
 それぞれ、
 ・pr-130-service-A-XXXXXXXXXXX-an.a.run.app 
 ・pr-141-service-A-XXXXXXXXXXX-an.a.run.app 
 というエンドポイントが作成される 
 適応後は、リビジョンタグとそれに紐づくエンドポイントが作成され、 一つのService上で複数の環境が使用できるようになります
20. © 2022 3-shake Inc. 20 PR stagingの実現方法 - 検討事項 Q. マイクロサービスが複数あり、エンドポイントの向き先を変更するには Q. Google Cloud Load Balancerを経由する場合はどうするのか Q. PR毎にDBを分けたい場合はどうするのか Q. 作成された環境のURLをすぐに確認できるようにしたい Q. PRがCloseした後は？ ここまで基本的な作成方法を見てきましたが、運用にあたっては 以下の質問に答える必要があります 次の章で、以下の内容に関して話します
21. 運用時の検討事項
22. © 2022 3-shake Inc. 22 フロントエンドの環境変数を変更してバックエンドを変える方法 デフォルトの設定、下記の場合 BACKEND_HOST を変えたい場合、PR作成時に backend:の後に作成したtag名を入れることによりバックエンドの向き先を変更している ①backend:の値を取り出す 
 ②環境変数の上書き 
 pr-staging.yaml
23. © 2022 3-shake Inc. 23 GCLBの設定でtag毎にエンドポイントを変更する方法 ・*.api.sample.service を LBのfonrtendに追加する ・httpsの場合ワイルドカード証明書の発行（ Certificate Manager）を行う ・Serverless NEG の url_mask を <tag>.api.sample.service で設定する Google Cloud Load Balancer経由でアクセスする必要がある場合、 tag名をドメインに含めて向き先を変更したいと思う <tag>.api.sample.serviceのアクセスがくると、 <tag>-service-A-XXXXXXXXXXX-an.a.run.appに ルーティングされるようになる 詳細: https://cloud.google.com/load-balancing/docs/l7-internal/setting-up-l7-internal-serverless?hl=ja#using-url-mask
24. © 2022 3-shake Inc. 24 DATABASEのコピー DATABASEのコピーは元のstagingのDBを論理コピーし、 名前はpr<PR number>_dbという名前に、後程、環境変数を上書きすることで向き先を変更 pr-staging.yaml
25. © 2022 3-shake Inc. 25 AlloyDBの場合 Cloud Run Jobs AlloyDB VPC Connector AlloyDBではGithub Actions上から接続ができないため、 Cloud Run Jobs内でDATABASEをコ ピー、そしてmigrationを行っています その際はVPC Connector経由で接続しています (ここではDATABASEのコピーのみコード例を挙げています ) pr-staging.yaml
26. © 2022 3-shake Inc. 26 作成されたエンドポイントをPRにコメントして残す (1) peter-evans/find-commentとpeter-evans/create-or-update-commentを 使用することで、コメントがなければ新規作成し、存在すれば更新する設定を追加しています 参考- Ken Matsui氏の Post:https://zenn.dev/matken/articles/chromatic-preview-comment#3.-%E3%82%B3%E3%83%A1%E3%83%B3%E3%83%88%E3%82%92%E 4%BD%9C%E6%88%90%E3%81%99%E3%82%8B
27. © 2022 3-shake Inc. 27 作成されたエンドポイントをPRにコメントして残す (1) PR上にエンドポイントがコメントに作成され、確認できるようになります
28. © 2022 3-shake Inc. 28 PR Close後 削除時は基本的にtagを外すだけで対応が完了するので、 tagを外すコマンドをCLIで実行している また、DBの削除、コメントの取り消し線の追加等を Workflowとして実行しています pr-staging-delete.yaml
29. © 2022 3-shake Inc. 29 おわりに ▪ Github Actionsの微妙な点 ・Reusable Workflow (terraformでいうmodule)自体は使用されないにも 　関わらず、UI上にWorkflowの一覧として出てしまうのに伴う視認性の低下 ・UI上でのログがリアルタイムで出ないので、ログをリアルタイムで追いたいときに少し不便 ・ifで評価したものが実行履歴として表示されてしまう ▪ 運用上の問題、差分 ・Serviceのインフラ自体をCloud Runで用意すると、例えば、 　CIで環境変数を変更する場合、変更箇所が毎度差分として出てしまう ▪ 注意点 ・CLIで設定する際に(gcloud run services update)、既存の環境変数の設定を別にしている場合 (上記のようにterraform管理している)、--set-env-varsで設定すると、 全環境変数が飛んでしまうので部分的に上書きするので、 --update-env-varsで設定する必要がある
30. © 2022 3-shake Inc. 30 まとめ ・CIでお手軽Cloud Runに環境を作成する方法を紹介させていただいた ・PR stagingだけサービスをわけるという方法もあるので、 　要件に合わせて、柔軟に応用していただければと思います