inductor's blog

nothing but self note :)

2015年頃のWeb開発者がやりがちだった、DockerをVMと同じように使うのは便利だけど辞めたほうが良いという話

Dockerが普及し始めて、Docker Composeによって開発環境が簡単につくれるようになった2015年頃から、DockerはVagrantの置き換えツールとして使われることが増えてきました。

Vagrantを使うことでサーバープロビジョニングのときに発生する初期構築を全てスクリプト化し、プロジェクトメンバーの開発環境構築のコストを削減することができますし、設定がGitに残るのでメンテナンスも比較的容易です。そのため、自分の認識ではVagrantの一番の特徴はVMのパッケージングにあると思っています。

一方、Dockerはアプリケーションを動かす環境を配布するための仕組みとして普及しました。どちらもベースのイメージから必要な処理を流す点は同じですが、DockerとVagrantでは開発者が利用する上では体験の面で見ても以下のような違いがあると思います。

  • Vagrantは仮想マシンをVirtualboxで動かすため、マシンリソースの消費や構築・起動におけるオーバーヘッドが大きい
  • Dockerは原則1コンテナ1プロセスで動かすべきで、cronなどのサブプロセスはサーバーアプリケーションでは無理に動かさず外部の仕組みを使うべき
    • Web + App + DB + Queueみたいなシステムを全部入にするのはVagrantならアリ、Dockerでは複数コンテナに分割すべき
  • コンテナイメージには極力余計なものを入れずシンプルに保つべき
    • 開発環境含め余計なものを入れるとイメージサイズが大きくなるし、実行用コンテナには入れず、やるとしても開発用コンテナを用意してボリュームマウントなどを利用する

Dockerというツール自体は非常に自由度も高く、なんでもできてしまうのですが、複数人で開発するに当たってはできるだけ不要なものを入れず、必要なものは各自自分の環境に用意して使うのが懸命でしょう。

この手の話は極論に達すると全てのものがマイクロサービスで動くべきみたいな誤った理解をされかねないのですが、そういう極端な理解ではなく、必要なものを必要なときに合わせて組み合わせられる仕組みが整っていればなんでもいいと思います。

たまーに「公式イメージ」でも様々な理由によりsupervisordみたいな複数プロセスをまとめて管理する系のやーつをコンテナで動かしているのを観測するので、ふと忘れないうちに、と思ってつらつら書きました。