Google Cloud Buildでkanikoを使ったときにハマったこと
先日のリリースを見て、早速自分の環境でもkanikoを使ってみることにしました。
結果、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しているせいか、ビルド通知の中のメッセージから、 images
と artifacts
のフィールドがなくなっています。
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