イメージ は、Docker で コンテナ を作るための元になるテンプレートです。
初心者向けにかなりざっくり言うと、実行環境の設計図 や 完成前のひな型 に近いです。
Docker Docs でも、イメージはコンテナを実行するために必要なファイル、ライブラリ、設定を含んだ標準化パッケージとして説明されています。
そのため、実際に動いているものがコンテナ、そこから作る前提のまとまりがイメージです。
まず押さえたいポイント
- イメージはコンテナを作る元になる
- イメージ自体は実行中の本体ではない
- 同じイメージから複数のコンテナを作れる
- Dockerfile はイメージの作り方を書く
どんな場面で使うか
イメージは、アプリを配る、CI で同じ環境を再現する、開発チーム全体で同じ実行環境を共有する、といった場面で使われます。
たとえば node:22-alpine や mysql:8.4 のようなイメージを使うと、必要なランタイムやDBをすぐ用意しやすいです。
コンテナとの違い
ここがいちばん大事です。
- イメージ: ひな型、設計図、読み取り専用の元データ
- コンテナ: そのイメージから実際に起動した実体
同じイメージから複数のコンテナを作れるので、イメージ = コンテナ本体 ではありません。
Docker Docs でも、コンテナは a runnable instance of an image と説明されています。
実務で見るポイント
イメージが大事なのは、単に起動できるかだけではありません。
どのベースイメージを使うか、サイズが大きすぎないか、古いパッケージが残っていないか、という観点で保守性やセキュリティにも影響します。
また、イメージは immutable とされていて、作ったあとに中身を書き換えるというより、新しく作り直して差し替える考え方が基本です。
よくある誤解
イメージを pull したらそのまま動いている？
まだ動いていません。
docker pull はイメージを持ってくる操作で、実際に起動して実行単位になるのはコンテナです。
コンテナの中で変えた内容はイメージに戻る？
基本的には戻りません。
コンテナで加えた変更をそのまま元イメージへ自動反映するわけではないので、再現性を保ちたいなら Dockerfile 側に変更を寄せる方が実務的です。