はじめに

前回記載したContainer-Optimized OS の起動に続いて、そのGCE上のコンテナに楽にデプロイしたいため、CI/CDを組み込んでみました。

構成

みての通り全く大したことはしないのですが、それぞれの矢印で何をしているか、補足します。

各ステップの内容について

Cloud Source Repository
- リポジトリ作成
Cloud Build
- Cloud Source Repository へコミットすると Cloud Buildがトリガーされます
- Cloud Build 上で Dockerfile を Build し、Container Registry へ push します
- Cloud Build で GCE 上のコンテナ情報を更新し、GCE を再起動します

特段何か難しいこともせずに必要最低限なことをしている、という感じです。

実際の内容

Source Repository

Source Repository はリポジトリというだけで、説明することもないので割愛します。

Cloud Build

参考
設定内容の各項目の意味の参考

Cloud Buildのトリガー設定

以下のような形でmasterへpushされた際に動作するようになっています。

Build 内容

steps:
  - name: gcr.io/cloud-builders/docker
    args:
      - build
      - '-t'
      - 'gcr.io/$PROJECT_ID/xxxx-test:$COMMIT_SHA'
      - .
  - name: gcr.io/cloud-builders/docker
    args:
      - push
      - 'gcr.io/$PROJECT_ID/xxxxx-test:$COMMIT_SHA'
  - name: gcr.io/google.com/cloudsdktool/cloud-sdk
    args:
      - gcloud
      - compute
      - instances
      - update-container
      - xxxxx-test-container
      - '--zone'
      - asia-northeast1-b
      - '--container-image'
      - 'gcr.io/$PROJECT_ID/xxxxx-test:$COMMIT_SHA'
images:
  - 'gcr.io/$PROJECT_ID/xxxxxx-test:$COMMIT_SHA'
options:
  logging: CLOUD_LOGGING_ONLY

これらを分解すると、以下のような処理になります。

Cloud Build自体の Build処理くらいからの内容

※詳細にはCloud Build の下に(上部)にあるリンクを参照ください

Configurationの部分は先にBuild内容を説明してしまいましたが、Cloud Build の内容記述する以外に、
Dockerfileを指定したり、Buildpacks をすることも可能です。
Approval機能をこの記事記載中に気付きました、、承認フェーズを挟むことが可能なようです。Cloud Deployにも最近できましたが、Cloud Buildにはもっと前からあるかもですね。Cloud Deploy の Approval はこちらにも記載しています。https://qiita.com/hirosait/items/cbae0b9bf493e518aa80
Service Account は今回GCEの再起動処理が伴うため、デフォルトの Cloud Build の権限では不十分のため、Compute Engine の権限を追加しています。

処理を流す

Repositoryトリガーやpushするところは割愛しまして、GCE更新部分のログを掲載します。

見て分かる通り、container部分が更新され、インスタンスが止まって、起動していることがわかると思います。

所感

前回の以下で記載した通り、scpしたりgit cloneなどCloud Buildでごにょごにょせずとも、あっさりコンテナイメージの更新をすることができました。
Cloud Run で CI/CDを検討することはありましたが、GCEに対する(といっていいか微妙ですが、)ものは初めてで、勉強になりました。
今後、似たようなケースがあれば必要に応じて実施を検討してみたいと思います。