なぜ
- 推薦のアプリをGKE上で動かしているが、手元からdocker imageをbuildしてpushして、deployして...とやっていた
- さすがにダルい...
- AWS関連のCI/CDはGitHub Actionsでやっているが、同じことをやっても面白くない
- 例: 最近の砂場活動その15: CI/CDのパイプラインを整備する - yasuhisa's blog
- 趣味プロジェクトなので、面白さが必要なのかは割と大事
- 仕事でもCloud Buildを使うので、雑に壊して遊べる環境を持っておきたい
どうやって
- Cloud Buildでは
Cloud Build GitHubアプリ
を通じてGitHubにpushがある毎にコードをビルドすることができる- GitHub でのビルドの実行 | Cloud Build のドキュメント | Google Cloud
- 認証してやればprivateリポジトリでもいける
- GitHub Actionsからアレコレやるにはcredentialsをsecretsに渡して...という一手間が必要だったが、GCP内なのでその辺は大部楽になってる
- GCRへのpush、Secret Managerへのアクセス、Kubernetes Engineとの連携など
- GitHub Actionsと同じく、yamlにステップを書いていく
具体的なやり方
こういう感じで簡単にやれる。
- githubのpushを元に、docker imageをbuild
- GCRにimageをpush
- GKEクラスタへの接続を確認
- helmを使ってdeploy
steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', 'gcr.io/$PROJECT_ID/gke_batch_monitor', '.' ] dir: 'gke_batch_monitor' - name: 'gcr.io/cloud-builders/docker' args: [ 'push', 'gcr.io/$PROJECT_ID/gke_batch_monitor' ] - name: gcr.io/cloud-builders/kubectl args: [ cluster-info ] env: - CLOUDSDK_COMPUTE_ZONE=$_CUSTOM_ZONE - CLOUDSDK_CONTAINER_CLUSTER=$_CUSTOM_CLUSTER - KUBECONFIG=/workspace/.kube/config - name: 'gcr.io/$PROJECT_ID/helm' args: - 'upgrade' - 'gke-batch-monitor' - 'helm' - '--install' - '--values=./helm/values.yaml' - '--namespace=gke-batch-monitor-ns' dir: 'gke_batch_monitor' env: - CLOUDSDK_COMPUTE_ZONE=$_CUSTOM_ZONE - CLOUDSDK_CONTAINER_CLUSTER=$_CUSTOM_CLUSTER timeout: 1200s substitutions: _CUSTOM_ZONE: us-west1-a _CUSTOM_CLUSTER: ml-news
Cloud Build自体の設定はもちろんWebからもできるけど、同じような設定をあちこちに書くことになるので、Terraformで管理しておくと安心。
resource "google_cloudbuild_trigger" "gke_batch_monitor" { name = "gke-batch-monitor" description = "XXXのGCRへのpushとGKEへのdeployを行なうトリガーです" filename = "gke_batch_monitor/cloudbuild.yaml" github { name = "my-private-repository" owner = "syou6162" push { branch = "master" invert_regex = false } } }