Dockerは2013年に登場したコンテナ仮想化のプラットフォームで、「アプリと依存ライブラリを一緒に箱詰めして、どこでも同じように動かす」というアイデアを一気に普及させました。Linuxカーネルの cgroups / namespace を活用した軽量な隔離技術を、開発者にとって扱いやすいCLIとイメージ配布の仕組み（Docker Hub）にまとめあげたのが、Dockerの最大の貢献です。本記事ではDockerの基本概念、仮想マシンとの違い、Kubernetesとの関係を整理します。
この記事の目次
- Dockerの中核概念
- 仮想マシンとの違い
- Dockerが解決した「私の環境では動く」問題
- DockerとKubernetesの関係
- まとめ
Dockerの中核概念
Dockerを理解する鍵は「イメージ」「コンテナ」「Dockerfile」の三層関係です。Dockerfileに「ベースOS、入れるライブラリ、起動コマンド」を記述すると、それをビルドして得られるのがイメージ（読み取り専用のスナップショット）。イメージを起動した実行体がコンテナです。イメージを設計図、コンテナを建物に例えるとイメージしやすくなります。
イメージはレイヤ構造で、共通の下回りは複数のイメージで使い回されます。「OSイメージ＋言語ランタイム＋アプリ」のように積み上がるため、差分だけ転送・保存される効率の良さがDockerの普及を支えました。
仮想マシンとの違い
コンテナとVM（仮想マシン）の最大の違いは、カーネルを共有するかどうかです。VMはゲストOSのカーネルを丸ごと起動するため重く、起動に分単位かかりがちでメモリも数百MB単位で消費します。一方Dockerコンテナはホストのカーネルを借りて動くため、起動は秒、メモリ消費もずっと小さくて済みます。
ただしカーネルを共有するということは、Linuxホストの上ではLinuxバイナリしか動かないということでもあります。WindowsやmacOSでDockerが「動いている」ように見えるのは、実際には軽量なLinux VM（WSL2 や Docker Desktop の仮想マシン）の中でコンテナが動いているからです。
Dockerが解決した「私の環境では動く」問題
Docker普及前のソフトウェア開発で頻発していたのが、いわゆる「私の環境では動く」問題です。開発者のPCではきちんと動くのに、テストや本番ではライブラリのバージョン違いで失敗する——という事故が日常的に起きていました。
Dockerはアプリと依存ライブラリ・設定をひとつのイメージに固めて配るため、「ビルド成果物そのものを各環境にデプロイする」モデルが成立し、環境差分による事故が激減しました。CI/CDパイプライン、本番運用、ローカル開発のすべてが同じイメージで動くという統一感は、それまでのインフラ運用とは一線を画す体験だったのです。
DockerとKubernetesの関係
Dockerが普及した結果、コンテナ自体は業界標準（OCI: Open Container Initiative）として規格化されました。「コンテナを動かすランタイム」と「Docker社のツール群」は別物として整理されており、Kubernetesの実行系も、現在ではDockerエンジンではなくcontainerd（軽量なコンテナランタイム）を直接使うのが主流です。
Docker自体は1台のサーバ上でコンテナを動かすには十分ですが、「数十台・数百台のサーバに散らばるコンテナを協調させる」となるとKubernetesの出番です。Docker→Compose→Kubernetes、と規模に応じて道具を使い分けるのが現代の定番構成です。
まとめ
Dockerは「アプリを箱に詰めて持ち運ぶ」という直感的な比喩を技術として実現し、ソフトウェアのデリバリーと運用を根本から変えました。Kubernetesと組み合わせるクラウドネイティブの時代においても、コンテナを自分の手で扱う第一歩としてDockerは依然として最良の入り口です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント