CloudBuildでcloud-buildersのimageを使うとキャッシュが効くのでpull時間を短縮できる
こんにちは、3-shakeのhuuyaです
私が所属するチームではCloudRunやCloudRun Jobsへのデプロイにおいて主にCloudBuildを利用しています。
今年の9月に入社してから機能開発の傍らでCI・CD周りのチューニングを行ってきました。
その中でタイトルの通り、cloud-buildersのimageとそれ以外のimageを利用するケースにおいて、
CIの実行時間に関わる違い を見つけたので備忘録として記事に残すことにしました。
cloud-buildersのimageがCloudBuild上でキャッシュされていた
cloud-builders（ gcr.io/cloud-builders/... ）のimageはGoogle Cloudの公式imageとなっています。
ある時、dockerを利用するために使っていた gcr.io/cloud-builders/docker のimageがCloudBuild上でキャッシュされていることに気づきました。
pullしなくてもキャッシュから利用されていることが分かります。
Already have image (with digest): gcr.io/cloud-builders/docker
ただ、gcloud CLIを利用するために使っていた gcr.io/google.com/cloudsdktool/cloud-sdk のimageはキャッシュされておらず、
毎回40s〜50sほどのpullが走っていました。
Pulling image: gcr.io/google.com/cloudsdktool/cloud-sdk
Using default tag: latest
latest: Pulling from google.com/cloudsdktool/cloud-sdk
...
これが1日に何百回も走ると月間コストからすると目に見えるものにもなってきますよね。
そこで、dockerコマンドを利用するためのimageと同様にCloudBuild上でキャッシュされたimageが無いか調査を行ったところ、
gcr.io/cloud-builders/gcloud を利用することでキャッシュされたimageが利用されることが分かりました。
Already have image (with digest): gcr.io/cloud-builders/gcloud
改善結果
gcloudコマンドを利用する際のimageを以下のように差し替えることで、
既存のdeployステップが40s〜50s速くなりました。
gcr.io/google.com/cloudsdktool/cloud-sdk
=> gcr.io/cloud-builders/gcloud
| before | after |
|---|---|
 |
 |
まとめ
gcr.io/cloud-builders/* のimageがCloudBuild上にキャッシュされている旨のドキュメントは公式を漁ってみましたが見つけることは出来ませんでした。
唯、今後CloudBuild上でgcloudやdockerコマンド以外のツールを利用する際はまず、cloud-buildersのイメージがないか確認し、検証しようと思いました。
- gcloud
- docker
以外にも
- go
- npm
- yarn
- git
- bazel
などのimageも提供されているようなので、
私と同じようにCI・CDのコスト削減に取り組まれている方はぜひ参考にしていただければと思います。
Discussion