3秒でわかる
アプリと必要な環境をひとつのイメージにまとめ、どのマシンでも同じ状態で動かす仕組み。開発と本番の食い違いをなくす目的で使います。
30秒図解
もう少し詳しく
どういうものか
Docker はアプリ本体と、それが動くために必要な OS のファイル一式、ライブラリ、設定をひとまとめにして持ち運べるようにする仕組みです。まとめたものをイメージと呼び、イメージを実際に起動した状態をコンテナと呼びます。イメージは読み取り専用で、何度起動しても同じ中身から始まります。
仮想マシンのように OS まるごとを動かすわけではなく、ホストの Linux カーネルを共有したまま、プロセスから見えるファイル、ネットワーク、プロセス一覧だけを隔離します。そのため起動が秒単位で終わり、一台のマシンで何十個も並べられます。
なぜ必要か
環境差による事故をなくすためです。手元では動いたのにサーバーで落ちる原因は、たいてい言語のバージョン違い、入っていないライブラリ、設定ファイルの置き場所です。Dockerfile に手順を書いておけば、その手順を実行した結果がイメージとして固定され、新しいメンバーの初期構築も本番への配置も同じ一行で済みます。
具体例
Node.js アプリを動かす最小構成です。
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 .
docker run --rm -p 8080:3000 myapppackage.json を先にコピーしているのは、依存が変わっていない限り npm ci の層をキャッシュから再利用させるためです。ソースだけ書き換えたビルドが数秒で終わります。
つまずきやすいところ
コンテナの中で書いたファイルは、コンテナを消すと一緒に消えます。データベースやアップロード画像を扱うなら、ボリュームを割り当ててホスト側に残す必要があります。
ポートも間違えやすい点です。コンテナ内の 3000 番は、公開指定をしない限り外から見えません。さらにコンテナ内から見た localhost はそのコンテナ自身を指すので、別コンテナの MySQL につなぐときはホスト名にサービス名を書きます。Apple シリコンで作ったイメージをそのまま Intel のサーバーへ持っていくと動かないこともあり、その場合はビルド時に対象アーキテクチャを指定します。
似た用語との違い
| 用語 | 実体 | 起動 |
|---|---|---|
| イメージ | 固定された設計図 | 起動しない |
| コンテナ | イメージを動かした実行体 | 秒単位 |
| 仮想マシン | OS まるごと | 分単位 |
覚え方
イメージは弁当の型、コンテナは型から出した実際の弁当。型が同じなら、どの机の上でも同じ弁当が出てきます。