背景
去年触っていた時は
Key Management Serviceについて勘違いしていたこと - あーありがち(2018-10-21)
こんな感じで、
- GCPの中にコードを送り込むことを自動化する際にサービスアカウントを使うので、そのアカウントの鍵が必要
- pkgcloud が keyFilename がないと激おこ
という理由で鍵をどう管理するかを考えていたのだけど、事情が変わって鍵の管理を全部不要にできたので、これをまとめておく。
まとめ
- pkgcloud が 2019-04 時点で依存 npm を gcloud から @google-cloud に乗り換えたおかげで client library の挙動が正しくなった
- 動作時のサービスアカウントの default credentials と permissions を取得できる
- Cloud Source Repositories & Cloud Build を使うことで Google Cloud の外から中へ入れる必要がなくなった
結果、サービスアカウントの鍵を Google Cloud 外に持ち出す必要はなくなった。
なくせたこと
これまでサービスアカウントの鍵を外に持ち出しつつリポジトリの中に鍵を納めないようにするため、
- あちこちの環境変数に鍵の中身をぶちまける
- 必要に応じてこの環境変数の中身を鍵ファイルとして書き出し、その鍵ファイルのありかをコードに教える
- 例えば deploy 時、例えば実行時
という作業とコードの準備をしていたのだが、これらが一切不要になった。めでたい。
ではこれを可能にしたサービスを紹介する。
Cloud Source Repositories
Cloud Source Repositories | Google Cloud
- Cloud Source Repositories は GitHub と Bitbucket に対して同期する機能を持っている
- 同期の際の認証は OAuth
この時点で Google Cloud の外から中へ持ち込むという課題はクリアしている。外から中へ持ち込むのではなく中から外へ取得しにいく形になる。
なお、次の Cloud Build の関係で、リポジトリはプロジェクト単位で作ることになる。Google Cloud は staging 環境用にもう一つプロジェクトを作ることを推奨しているので、production 用と staging 用のプロジェクト別にリポジトリを持つ形になる。
※ 2020 のいつ頃からか、Cloud Build の方で直接 Cloud Build GitHub アプリを使って GitHub に接続できるようになったので、ミラーが目的でないならそちらを利用する方がよいと思います。ビルドステータスを GitHub に返すことができるので。
Cloud Build
Cloud Build - 継続的インテグレーションのためのビルドの自動化 | Cloud Build | Google Cloud
- 設定は cloudbuild.yaml か Dockerfile で行う
- 各ステップ用に Docker コンテナが用意してあってそれらに YAML ファイルから指示を出す
これだけ読むと最近よく見るクソ面倒くさい CI/CD のように見えるが、少なくとも deploy に限ってはかなり簡単。理由は以下の通り。
- Cloud Build が動き始めている段階で「目的のプロジェクトに属している状態で、かつその Project ID は環境変数として持っている
- gcloud コマンドのインストールは不要（それ用のコンテナがある）
- サービスアカウントの activation も不要（そもそもコンテナが Cloud Build 用のアカウントで動いている）
- build の動く条件は cloudbuild.yaml 内ではなく trigger の方に指定する。cloudbuild.yaml 内に面倒な分岐は書く必要がない
- 1 の関係で deploy 先のプロジェクトは分かっているのでこれの切り替えも不要
少なくとも Google Cloud 外の CI から deploy するのに比べるとマジで何倍も楽。マジ。
Cloud Build もうちょっと早く出会いたかったぜ…。