Dockerfile とは - Dockerfile

Dockerfile は「イメージをどう組み立てるか」をテキストで宣言するファイル。

ベースイメージの選択、依存のインストール、ソースのコピー、実行時の設定、起動コマンドまでを上から順に書き下ろし、docker build がそれを読み取ってイメージ化する。

手作業で docker exec しながら作ったコンテナを docker commit でイメージ化することもできるが、再現性がなく履歴も残らない。

Dockerfile は「誰が、いつ、どのマシンで叩いても同じイメージが出来上がる」ことを保証するための基本パーツ。

開発環境の構築手順を README に書く方式だと、OS 差・手順の抜け・時間経過による齟齬が必ず出る。

Dockerfile ならその手順がコードとして Git に載り、CI でビルド検証でき、レジストリで配布できる。

主な利点は以下。

• 再現性: 同じ Dockerfile + 同じコンテキストから同じイメージが作られる
• 可搬性: macOS / Windows / Linux / CI / 本番すべてで同じ結果
• 履歴: git blame で「いつ誰が何を入れたか」が追える
• キャッシュ: 変わっていない部分はビルドを省略できる
• 配布: できたイメージをレジストリに push すれば他環境で pull して即起動

docker build は Dockerfile と「ビルドコンテキスト」（コンテキストディレクトリ配下のファイル群）を Docker デーモンに渡し、命令ごとに中間コンテナを作って次の命令を実行する。

各命令の実行結果はレイヤー（差分）として保存され、最終的に重なったレイヤーの集合がイメージになる。

イメージを docker run で起動するとプロセスとしてのコンテナが立ち上がる。

docker build はイメージを作るだけで実行はしない。

ビルド時と実行時は別の工程として切り分けられている点がポイント。

# 最小の例
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

# ビルド
docker build -t myapp:1.0 .

# 実行
docker run --rm -p 3000:3000 myapp:1.0

Dockerfile の各命令は 1 レイヤーとなり、入力（命令文 + 取り込むファイル）に変化がなければ次回ビルドでキャッシュが再利用される。

ビルド時間に直結するため、書き順が大きな差になる。

王道パターンは「変わりにくいもの → 変わりやすいもの」の順で書くこと。

たとえば Node.js なら、先に package*.json だけを COPY して RUN npm ci を走らせ、その後でソースを COPY . . する。

こうするとソースだけ変わったときに依存の再インストールを省略できる。

詳細は後続の Dockerfile の基本命令 と ビルドキャッシュを再利用する を参照。