Container-Optimized OS で起動した GCE上のコンテナに Cloud Build でCI/CDする

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

https://qiita.com/hirosait/items/ef8bec6c36c3eb79adeb

# 構成
![cicd.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/dbffdc6c-82fa-26ed-3b29-6726a3ba3e8a.png)

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

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

- 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
参考
設定内容の各項目の意味の参考

https://cloud.google.com/build/docs/automating-builds/create-manage-triggers?&_ga=2.233288728.-783207234.1658373906&_gac=1.262634110.1668151089.Cj0KCQiA37KbBhDgARIsAIzce15N_Fxi4QVq2iZRt8qVdDISnky0p9SwOngEl8kOoQTXVrIl6SqvOncaAvO9EALw_wcB#build_trigger
### Cloud Buildのトリガー設定
以下のような形でmasterへpushされた際に動作するようになっています。

![スクリーンショット 2022-12-17 3.03.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/09a1e631-cb25-4b65-41c2-8c2bb3b957ca.png)

### 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
```
これらを分解すると、以下のような処理になります。
- stepsの1つ目：Build処理になります
- stepsの2つ目：push処理になります
- stepsの3つ目：GCE内のコンテナをアップデートする処理になります
    - 参考1 gcloud compute instances update-container の CLIコマンドマニュアル
        - https://cloud.google.com/sdk/gcloud/reference/compute/instances/update-container
    - 参考2 VM インスタンス上のコンテナの更新
        - https://cloud.google.com/compute/docs/containers/deploying-containers#updating_a_container_on_a_vm_instance
- options箇所の記載しないと失敗します(CloudRunへのデプロイとかだと失敗しないですが、GCE更新処理で失敗します、、理由は詳細に追えていないです)

### Cloud Build自体の Build処理くらいからの内容
![スクリーンショット 2022-12-17 3.10.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/3717fdc2-7ba0-cf99-245a-bb6de45609a0.png)
※詳細には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更新部分のログを掲載します。
![スクリーンショット 2022-12-17 3.18.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/52c51e5a-8841-5f2b-815c-7d5cfbb1fdcd.png)
見て分かる通り、container部分が更新され、インスタンスが止まって、起動していることがわかると思います。

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

https://qiita.com/hirosait/items/ef8bec6c36c3eb79adeb