「自分の環境では動くのに」問題から出発して、コンテナという箱、ランタイム、イメージ(ひな型)とコンテナ(実体)の関係、docker run のオプション、ボリュームまで。Docker の土台になる言葉を順に押さえます。
アプリを動かすには、書いたコードだけでは足りません。コードを実行するランタイム、頼っているライブラリ、設定ファイルや環境変数がそろって初めて動きます。ところがそれらは PC ごと、サーバーごとに微妙に違います。手元では Node 22 と新しいライブラリで動いていたものが、本番では Node 18 と古いライブラリで落ちる。これが昔から開発者を悩ませてきた「自分の環境では動くのに」問題です。
Docker はこの問題への答えとして生まれました。このアニメモは3部構成の1つ目で、まず「箱(コンテナ)とは何か」「イメージとは何か」「docker run で何が起きるか」を順に追います。2つ目でイメージの作り方と配り方(Dockerfile・ビルド・レジストリ)、3つ目で複数の箱をまとめる docker compose を扱います。
Docker の発想は単純です。アプリのコードと、それが動くのに必要なランタイム・ライブラリ・設定を、まとめて1つの箱に閉じ込める。そして箱ごと運んで、どのマシンでも同じ箱を開ける。箱の中身は作った時点で固まっているので、手元でも本番でも同じ状態で動きます。この箱が「コンテナ」です。
箱の中にあるのは、ふだん「環境」と呼んでいるもの全部です。だから Docker を理解するには、「アプリのコード」と「それを動かす環境」を分けて考える癖が要ります。この先ずっと、この区別が効いてきます。
箱の中身でいちばん分かりにくいのが「ランタイム」です。あなたが書いた JavaScript や Python のファイルは、それ自体はただのテキストで、CPU は直接読めません。それを読み込んで解釈し、CPU に分かる命令に変えて実行するプログラムがランタイムです。JavaScript なら node、Python なら python、Java なら JVM がそれにあたります。
もう少し広く取ると、ランタイムには言語本体だけでなく、標準ライブラリや、OS が提供する基本ライブラリ(libc など)も含まれます。「コードを動かすための土台一式」と考えてください。Go や Rust のようにコンパイル時に必要なものを実行ファイルへ埋め込む言語では、ランタイムはほとんど要りません。
node:22 のようなイメージに入っているのは、まさにこの土台です。あなたのコードはまだ入っていません。
「環境ごと箱に詰める」なら仮想マシン(VM)でもできます。違いは箱の重さです。VM はハードウェアを丸ごと模倣して、その上にゲスト OS をもう1つ起動します。OS が二重に動くので、起動に分単位かかり、メモリも GB 単位で食います。
コンテナは OS を起動しません。ホストの Linux カーネルをそのまま使い、「このプロセスからは自分のファイルとネットワークしか見えない」という隔離をカーネルの機能で作ります。中から見ると独立した小さな Linux に見えますが、実体はホスト上の普通のプロセスです。だから起動は一瞬で、何十個も並べられます。
Windows や Mac で Docker を使うときは、裏で小さな Linux VM が1つだけ動いていて、その中で全コンテナが動いています。
箱の中身を、起動前の状態で固めてファイルにしたものが「イメージ」です。中身は、ファイルシステムの丸ごとのスナップショットと、「起動したら何を実行するか」の指定。たとえば postgres:16 というイメージには、Debian の最小限のファイル群と PostgreSQL 16 のバイナリ、起動スクリプトが入っていて、「インストール済みで、あとは電源を入れるだけの小さな Linux のディスク」と考えるのが近いです。
イメージは読み取り専用で、層(レイヤー)の積み重ねでできています。土台の OS、その上にランタイム、その上にライブラリ、その上にアプリのコード、最後に起動コマンド。同じ土台を使うイメージが複数あっても、土台のレイヤーは1回だけダウンロードされて共有されます。
「イメージを取ってくる」とは、ソフトの本体だけでなく、ソフトが動く環境ごと取ってくることです。インストーラーが「あなたの環境にソフトを組み込む手順」なのに対して、イメージは「組み込み終わった状態そのもの」です。
イメージを元に起動した、動いている箱がコンテナです。プログラミングの言葉で言えば、イメージがクラスでコンテナがインスタンス。1つのイメージから何個でもコンテナを作れますし、それぞれは独立しています。
コンテナを起動すると、読み取り専用のイメージの上に、薄い「書き込み可能な層」が1枚乗ります。コンテナの中で作ったファイルや書き換えた設定は、すべてこの薄い層に入ります。イメージ本体は変わりません。
ここに落とし穴があります。コンテナを消すと、この書き込み層も一緒に消えます。データベースをコンテナで動かして、コンテナを作り直したらデータが全部消えていた、というのは初心者が必ず一度は踏む罠です。解決策が次に出てくる「ボリューム」です。
図のコマンドは PostgreSQL を1つ起動しています。長く見えますが、構造は「docker run + オプション + イメージ名」だけです。
最後の postgres:16 が使うイメージで、手元に無ければ自動で取ってきます。-d は画面を占有せず裏で動かす指定。--name は人間が呼ぶための名前。-p 5432:5432 はポートの公開で、コンテナは隔離されているため何もしなければ外から繋げません。「ホストの 5432 番に来た通信をコンテナの 5432 番へ流す」と穴を開けるのがこの指定で、左がホスト側、右がコンテナ側です。-e は環境変数で、イメージを作った人が「この変数で初期パスワードを受け取る」と決めているので、それに従って渡します。-v がボリュームで、コンテナ内のデータ置き場を、Docker が管理する外部の保存領域に結びつけます。
つまり docker run は、固まったイメージに「口・設定・保存先」を外から与えて、動く箱にする操作です。
ボリュームは Docker が管理する保存領域で、コンテナとは別に生きています。-v pgdata:/var/lib/postgresql/data と指定すると、コンテナの中のそのディレクトリへの読み書きが、すべて pgdata というボリュームに向かいます。コンテナの書き込み層には入りません。
だからコンテナを消しても pgdata は残り、同じイメージから新しいコンテナを起動して同じ -v を付ければ、前のデータがそのまま見えます。データベースのデータ、アップロードされたファイル、ログなど「消えたら困るもの」は必ずボリュームへ逃がす、というのが鉄則です。
ここまでで「箱(コンテナ)」「ひな型(イメージ)」「起動(run)」「保存(ボリューム)」がそろいました。次のアニメモでは、そのイメージがどこから来るのか、つまり Dockerfile でのビルドと、レジストリからの取得を追います。
