仮想化という文脈ではイマイチDockerを理解できませんでしたが、（魔法の）コマンドと考えるとすんなり理解できましたので、今更ですが紹介したいと思います。

ざっくりと説明

• Docker | Wikipedia

Dockerはこのコンテナ仮想化を核としたアプリケーションのためのオープンプラットフォームである。環境およびアプリケーションをDockerイメージとしてバンドルし、DockerエンジンによりDockerコンテナとして配備・実行できる。Linux・Windows・Macすべてに対応したDockerエンジンは開発・テスト・本番・デバッグなど様々な状況で容易かつ高速なアプリケーション配備・実行を可能にする。

コンテナという概念を一般化したのはDockerの功績ですが、コンテナ技術が他の仮想化を圧倒したわけではないと思います。 （コンテナの考え方はDocker以前にも存在しました）

それよりも以下の2点が優れていたのだと思います。

• コードで管理できる環境
• サービスではなくコマンド実行

コードで管理できる環境

DockerコンテナはDockerfileとdocker-composeという2種類のテキストファイルで定義します。 これはつまり、イマドキのGitによる開発フローに乗っかれる、ということです。

どんなに便利なツールでも、Git開発フローに載せられないものは途端に開発効率が落ちてしまいます。 要は、Gitの中でバージョン管理を機械に任せることができなくなります。 人手を介する作業はスピードが落ちるのはもちろん、ミスの元にもなるので敬遠されます。

サービスではなくコマンド

今までの仮想環境はホストOSの上に仮想OSが乗っかって常駐する方式でしたが、Dockerの場合は常駐するかどうかもユーザの意思で選択できます。

例えばWebサーバをコンテナで作った場合、-dオプションでコンテナを動かし続ける（常駐させる）ことができます。 一方-dオプションを指定しなかった場合、ENTRYPOINTで指定したコマンドの実行が終われば、当該のコンテナも終了します。

• Dockerfile リファレンス

例えば、環境を作るのが大変なコマンドをコンテナで作っておけば、環境構築から実行までDockerがやってくれます。

AIではPythonを良く使いますが、Pythonはバージョン管理が煩雑になりがちです。 まさにDockerで環境を固める恩恵をモロに受けることができます。

docker-composeとKubernetes

Dockerコンテナを使っていくと、早い段階で複数のコンテナを制御したくなります。 そんな時に使うのがdocker-composeです。 複数のDockerfileを束ねて1つのアプリケーションにする場合に、その依存関係なども含めてdocker-composeファイルに記述できるので、Webサーバ、DBサーバをセットで管理する、といった用途に威力を発揮します。

Kubernetesは仮想コンテナの運用を強くサポートするシステムですが、ワタシはいい思い出がありません。。 docker-composeファイルがあればKubernetes上で運用することは可能ですので、知らなくても開発上問題はありません。

謝辞

画像は Unsplash 様より使わせていただきました。