目次
カスタムイメージを採用する理由
CI/CD パイプラインを初めて組むときは、まずはプラットフォームが用意しているプレビルドイメージに頼ることが多いと思います。
GitHub Actions や GitLab、そして私が使っている Google Cloud Build には、.NET や git、npm などの基本的なツールがひと通りそろった 公式ビルダーイメージ が用意されています。
しかし、プロジェクトでよりモダンなツールや専門的なツールが必要になった場合はどうでしょうか?
まさに、私もそこでつまずきました。
私のプロジェクトは、標準の Cloud Build イメージにはどれも「両方まとめて」は入っていない、次の 2 つのツールに依存していました。
- uv — a blazing-fast Python package manager
- Pulumi CLI — for managing infrastructure as code
そこで、取りうる選択肢は次の 2 つになりました。
- The Slow Way: パイプラインが実行されるたびに、ゼロから
uvとPulumiをインストールする。 - The Smart Way: すべてがプリインストールされたカスタムイメージを構築する。
Cloud Build がコミュニティビルダーだけでなく、フルカスタムのビルダーイメージもサポートしているとわかった時点で、答えは決まりました。私は迷わず 2 番目の方法を選びました。
この記事は、そのときの自分が「こういうのが欲しかった」と思うガイドを形にしたものです。uv と Pulumi の両方を含む カスタム Cloud Build イメージ を使って、高速で信頼性の高い CI/CD パイプラインを作るまでの手順をまとめました。
Custom “Tools-Included” イメージのビルド
カスタムイメージを使うメリットが見えてきたところで、ここからは実際に作っていきます。
目標はシンプルで、CI/CD パイプラインで使うツール、とくに uv と Pulumi が最初から入っていて、そのまま使える Docker イメージを用意することです。
uv の大きな利点の 1 つは、静的バイナリとして配布されていることです。つまり pip install もコンパイルも、追加の依存関係も不要です。マルチステージの COPY を使用して、公式の uv コンテナから実行可能ファイルを直接取得できます。その結果、パイプライン実行のたびにツールをインストールするよりも、よりシンプルで高速、しかも安定したビルド環境を用意できます。
以下は、私が最終的に使用した Dockerfile です。

ここまでできれば準備完了です。
これらのステップだけで、 Python、uv、Pulumi、そして重要なビルドツールを含むカスタムイメージが完成しました。
次のステップ:このイメージを CI/CD で使用する
Dockerfile が用意できたら、次はそれを実際に使えるコンテナイメージとしてビルドし、CI/CD パイプラインから参照できるようにします。
Google Cloud Build の場合は、そのイメージを Artifact Registry にプッシュしておけば OK です。
一度 Artifact Registry に入れば、どの Cloud Build パイプラインでも即座にそれをプルできます。毎回のセットアップやツールの再インストールがほとんど不要になり、起動時間もかなり短くなります。
Step 1 — Build and Push the Image
これらのコマンドを打つ前に、次の 2 点を確認しておきましょう。
- Artifact Registry のリポジトリがすでに存在していること
gcloud auth configure-dockerで認証済みであること
その上で、次のコマンドを実行します。
# Set a variable for your image tag to make it reusable
IMAGE_TAG="[LOCATION]-docker.pkg.dev/[YOUR-PROJECT-ID]/[YOUR-REPO-NAME]/[YOUR-IMAGE-NAME]"
# Build the image
# --platform is crucial for ensuring the image works in Cloud Build
docker buildx build . --platform linux/amd64 \
-t $IMAGE_TAG \
--load
# Push the image
docker push $IMAGE_TAG
このプッシュが完了すると、カスタムイメージは正式に Artifact Registry で公開され、CI/CD パイプラインを強化する準備が整います。
Step 2 — Use the Image in cloudbuild.yaml
ここがすべてを結びつける部分です。
Cloud Build では、任意のコンテナイメージを使用して任意のステップを実行できます。そのため、イメージが Artifact Registry に保存された今、パイプラインへの追加は次のように簡単に行えます。

name: に先ほどのイメージ名を書くだけで、Cloud Build はそのカスタム uv+Pulumi イメージをプルし、その内部でこのステップを実行します。
実行のたびにツールをインストールする必要はもうありません。
依存関係のインストールを待つ時間もなくなります。
高速で、挙動の予測もしやすいビルド環境を作りやすくなります。
最後に、今回は Cloud Build トリガー用のカスタムベースイメージを作成しました。次回は、 CI/CD パイプラインをさらに高速化する工夫をまとめてみる予定です。
※本記事の Dockerfile はあくまでサンプルです。実際のプロダクション環境では、社内のセキュリティポリシーに合わせてインストール方法やバージョン管理方法を調整してください。




