CubicLouve

Spring_MTの技術ブログ

Google Cloud Buildでkanikoを使ったときにハマったこと

先日のリリースを見て、早速自分の環境でもkanikoを使ってみることにしました。

cloud.google.com

結果、Railsのプロジェクトで、Docker imageのビルド時間はキャッシュが効いている場合はそうでない場合に比べて半分くらいになりました。

まあ、ビルド時間はプロジェクトの規模に左右されかと思います。

今回はkanikoを使うにあたって幾つかハマった点があったのでメモしておきます。

Dockerfileを指定したトリガー経由のビルドだとkanikoが使われない

言われてみれば当たり前なんですが、

$ gcloud config set builds/use_kaniko True

としたら、トリガー経由でも自動的に使われると勘違いしていました。

トリガー経由のビルドの場合はビルド構成ファイル(主にcloudbuild.yaml)で明示的にkanikoを使うように指定するしかないです。

Dockerfileを Dockerfile 以外のファイル名を指定したい場合は、 -f or --dockerfile で指定できます。

ビルド通知で、imagesとartifactsのフィールドが返って来ない

kanikoを使っていると、kanikoの中でDocker imageのpushが走り、 --destination で指定した先にpushされます。

なので、ビルド構成ファイルで images を指定する必要はないです。

ビルド構成ファイルの images を使わずにpushしているせいか、ビルド通知の中のメッセージから、 imagesartifacts のフィールドがなくなっています。

cloud.google.com

cloud.google.com

kanikoで --destination でpush先を指定しつつ、 --repo-cache を指定し、 --no-push をつけてpushしないようにして、
ビルド構成ファイルに images を指定してみたらビルドがコケました。

今まで出来上がったDocker imageのリンクをビルド通知経由でslackに通知していたのですが、それをやめて適当に $PROJECT_ID などを組み合わせて、Cloud Buildの中のビルドの中で通知を飛ばすようにしました。

ざっくりこんな感じにしています。

steps:
- name: gcr.io/kaniko-project/executor
  id: server
  args:
  - --destination=gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA
  - --cache=true
  - --cache-ttl=6h
  waitFor: ['-']

- name: gcr.io/cloud-builders/curl
  id: curl
  args: ["--data-urlencode", "payload={\"text\":\"Images $COMMIT_SHA\",\"attachments\":[{\"title\":\"url\",\"value\":\"gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA\"}]}]}", "-X", "POST", "slackのincomming webhook url"]
  waitFor:
  - server