2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

.dockerignoreの書き忘れで起きるビルド激遅事件!?

2
Posted at

.dockerignoreの書き忘れで起きるビルド激遅事件!?

docker build を実行するたびに、ターミナルの前でコーヒーを淹れに行く時間ができていませんか?

そのdocker build待ち時間、.dockerignoreを1個置くだけで消えるかもしれません。

原因を調べてみると、ロジックの複雑さではなく、.dockerignore を置いていないだけだった、というのはよくある話です。

Dockerは docker build を実行すると、指定したディレクトリ(ビルドコンテキスト)の中身をまるごとビルダーに送信します。

ここに node_modules.git のような巨大なディレクトリが含まれていると、Dockerfileの中身を1行も変えていなくても、送信作業だけで時間がかかってしまいます。

この記事では、.dockerignore を書き忘れたことで起きがちな「ビルド激遅事件」の仕組みと、最小構成のテンプレートをまとめます。

本記事はDocker公式ドキュメント(Build context | Docker Docs)をもとに、2026年9月時点の情報で確認しています。

なぜ.dockerignoreが無いとビルドが遅くなるのか

docker build を実行したビルドクライアントは、コンテキストのルートディレクトリにある .dockerignore というファイルを探しにいきます。

このファイルが存在する場合、そこに書かれたパターンに一致するファイルやディレクトリは、ビルダーに送信される前のビルドコンテキストから取り除かれます。

逆に言うと、.dockerignore が無い状態では、node_modules.git の履歴も、ビルドに一切使わないログファイルも、すべて律儀に送信対象になってしまうということです。

Dockerfileの中で COPY . . のように書いている場合はなおさらで、意図せず巨大なディレクトリを丸ごとコピーしてしまいます。

依存パッケージが数百MBになりがちな node_modules や、コミット履歴を含む .git は特に影響が大きく、これらを除外するだけでビルドコンテキストのサイズが大きく変わるケースは珍しくありません。

最小構成のテンプレート

まずはこれだけ書いておけば大きな事故は防げる、という最小構成を用意しました。

プロジェクトの種類に応じて必要な行を足していく形で使ってください。

# バージョン管理
.git
.gitignore

# 依存関係(コンテナ内で入れ直す)
node_modules

# 環境変数・シークレット
.env
.env.*

# ローカル開発用の設定・キャッシュ
.vscode
.idea
.DS_Store

# Docker自身のファイル
Dockerfile
docker-compose.yml
.dockerignore

Node.js以外のプロジェクトであれば、node_modules の代わりに以下のような依存ディレクトリを足してください。

# Python
__pycache__
.venv
*.pyc

# Ruby
vendor/bundle

# Go
vendor

.gitignoreとは役割も書き方も別物

.gitignore があるからそれで十分、と思ってしまいがちですが、両者は目的が異なります。

ファイル 何から除外するか
.gitignore Gitのコミット対象から除外する
.dockerignore dockerビルドコンテキストへの送信対象から除外する

たとえば .env は多くの場合 .gitignore に含まれていますが、Gitの管理外であっても手元のディレクトリには存在するため、.dockerignore に書いておかないとビルドコンテキストには含まれてしまいます。

書き方の記法自体は似ていますが、ファイルとしては完全に別物として管理する必要があります。

.env のような秘密情報を含むファイルは、.dockerignore で除外していないとビルドコンテキスト経由でイメージに混入するリスクがあります。特にマルチステージビルドを使わずに COPY . . だけで済ませている場合は注意してください。

効果を自分の目で確認する方法

.dockerignore を書いた前後でどれくらい変わったかは、docker build のログに出力されるビルドコンテキストの転送量で確認できます。

docker build -t sample-app .

実行時のログの先頭付近に、コンテキストの転送に関する情報が表示されます。

ここで表示されるサイズが極端に大きい場合は、.dockerignore の見直しでまだ改善の余地がある、というサインです。

まとめ

  • docker build はビルドコンテキストをまるごとビルダーに送信するため、不要なファイルが多いほど遅くなる
  • .dockerignore を置くだけで、node_modules.git のような巨大なディレクトリを送信対象から除外できる
  • .gitignore とは役割が別物なので、どちらか一方だけで済ませない
  • .env のような秘密情報も、Gitの管理外だからといって油断せず .dockerignore に書いておく

.dockerignore はたった数行のテキストファイルですが、置いてあるかどうかで日々の開発体験がかなり変わります。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?