1. 導入: なぜBuild Mountsが必要なのか
Dockerでアプリケーションのビルドを行う際、毎回 `npm install` や `go build` を実行していませんか？標準的なDockerfileの書き方では、ビルドのたびにインターネットからパッケージを再ダウンロードするため、ビルド時間が長くなりがちです。これを解決するのが「Build Mounts (type=cache)」です。この機能を使うことで、ビルド間でキャッシュを再利用し、開発体験（DX）を劇的に向上させることができます。
2. 基礎知識: type=cacheとは？
通常、Dockerのビルド環境は「使い捨て」です。ビルドが終わると、インストールしたライブラリなどは破棄されます。しかし、`–mount=type=cache` を使うと、ホストマシンの特定のディレクトリをコンテナのビルドプロセス内に一時的にマウントできます。これにより、次回のビルド時に前回ダウンロードしたキャッシュが残っているため、ネットワーク通信を最小限に抑え、ビルドを高速化できるという仕組みです。
3. 実装/解決策
実装には、Dockerfileの `RUN` 命令内で `–mount=type=cache` オプションを使用します。ポイントは、対象のキャッシュディレクトリ（例: npmなら `~/.npm`）を正しく指定することです。これにより、Docker側が自動的にキャッシュ領域を管理してくれます。
4. サンプルプログラム: Node.jsプロジェクトの例
以下は、Node.js環境で `npm install` を高速化するためのDockerfile例です。
syntax=docker/dockerfile:1
FROM node:18-slim
WORKDIR /app
package.jsonだけ先にコピーして依存関係をインストール
COPY package.json package-lock.json ./
--mount=type=cache を指定してnpmのキャッシュディレクトリをマウント
target=/root/.npm はnpmがキャッシュを保存する標準的な場所です
RUN --mount=type=cache,target=/root/.npm \
npm install
ソースコードをコピーしてビルド
COPY . .
CMD ["node", "index.js"]
5. 応用・注意点
現場で活用する際の重要な注意点がいくつかあります。
キャッシュの共有範囲に注意: このキャッシュは、同じビルドパイプラインや同じホストマシン上で実行されるビルド間で共有されます。CI環境（GitHub Actionsなど）で利用する場合は、CI側のキャッシュ機能と組み合わせることで、より高い効果が得られます。
不要なデータを含めない: `target` に指定するパスは、使用するパッケージマネージャが実際にキャッシュを作成するディレクトリと一致させる必要があります。間違ったパスを指定してもキャッシュが効かないため、公式ドキュメント等で各言語のキャッシュディレクトリを確認してください。
クリーンなビルドとの使い分け: まれにキャッシュが破損してビルドが失敗することがあります。その場合は、`docker build –no-cache` を実行してキャッシュを無視してビルドし直すことで解決可能です。
このTipsを活用して、毎日の開発サイクルを少しでも快適なものにしていきましょう！
コメント