先日のリリースを見て、早速自分の環境でも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
