女性向けエンジニアスクール
3秒でわかる
コンテナを起動するための読み取り専用のひな型。アプリと依存物と設定を層状に固めてあり、どのマシンでも同じ環境を再現できます。
もう少し詳しく
どういうものか
コンテナイメージは、アプリケーションと、その実行に必要なライブラリ・実行環境・設定をひとまとめに固めた読み取り専用のファイル群です。これを起動したものがコンテナで、イメージ1つから同じ環境のコンテナを何個でも立ち上げられます。
イメージは層 (レイヤー) の積み重ねでできています。Dockerfile の命令1つごとに層が1枚増え、各層は変更されません。同じ層を共有できるため、5つのイメージが同じ土台を使っていても、その土台はディスク上に1つだけ置かれます。
なぜ必要か
「手元では動くのにサーバーでは動かない」の大半は、入っているライブラリの版や設定の差から生まれます。イメージは実行環境ごと丸めて運ぶため、この差が持ち込まれません。
配布と切り戻しも簡単になります。イメージにはタグが付き、レジストリに保管されます。新しい版で問題が出たら、1つ前のタグのイメージを起動し直すだけで元に戻せます。サーバーの中身を直接いじる運用では、この巻き戻しが難しくなります。
具体例
FROM node:22-slim
WORKDIR /app
# 依存だけ先に入れる キャッシュを効かせるための順番
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]docker build -t myapp:1.2.0 . # イメージを作る
docker run -p 3000:3000 myapp:1.2.0 # コンテナとして起動する
docker image ls # 手元のイメージ一覧つまずきやすいところ
latest タグを本番で使うのは避けます。中身が指すものが黙って変わるため、いつの版が動いているのか分からなくなり、切り戻し先も特定できません。版番号やコミットハッシュをタグにします。
命令の順番でビルド時間が大きく変わります。COPY . . を先に書くと、ソースを1文字直すだけで以降の層のキャッシュがすべて無効になり、依存のインストールが毎回走ります。変わりにくいものを先に、変わりやすいものを後に置きます。
CPU アーキテクチャの違いも見落とされがちです。Apple Silicon の手元で作ったイメージは arm64 で、amd64 のサーバーでは起動に失敗します。--platform の指定か、複数アーキテクチャ対応のビルドが要ります。
似た用語との違い
| 用語 | 実体 | 状態 |
|---|---|---|
| イメージ | ひな型となるファイル群 | 読み取り専用で変わらない |
| コンテナ | イメージを起動したプロセス | 書き込み層を持ち、消せる |
| レジストリ | イメージの保管場所 | Docker Hub, ECR など |
クラスとインスタンスの関係に近く、イメージが設計図、コンテナが実際に動いているものにあたります。
