DockerとVagrantの優位性について

Question

VagrantからDockerに移行を考えています。

実際に現場で使用してみてVagrantに勝るDockerのメリットを教えていただけますか？
例えば、コンテナ単位でCIができる、デプロイができる それをやってみてどうだったかなど。

逆にデメリットがあったのであれば教えて下さい。

Answer 1

VagrantからDockerに移行を考えています。

DockerはVagrantの移行先ではありません。
Vagrant+VirtualBOX(もしくはそれに値する仮想マシン)の中にインストールするApacheやMySQL等のデーモンの移行先がDockerになるだけです。
（Vagrant+VirtualBOXをラッピングしたdocker-machineとかありますけどね)

結局はVagrant+VirtualBOX+Apache→Vagrant+VirtualBOX+Dockerになるだけなので、
ローカルの開発環境を構築するという目でみれば何も変わりません。

むしろこれからDockerを覚えるということを考えると、
yum install -y httpdがdockerコマンドに置き換わりますので手間としてはかなり増えるでしょう。

---

実際に現場で使用してみてVagrantに勝るDockerのメリットを教えていただけますか？

本番環境を立ち上げた際の初期のサーバーの状態に左右されないというところがでかいですね。
実際うちのチームは縁あってAWSからAzureに乗り換えましたが、移行コストをかなり抑える事ができました。
やはりサーバーの状態によらず全てDockerfileに全て書いてあるというのが勝因でしょう。

他には現状Apacheで動いているサービスにNode.jsサーバーを付け足すような要件でパワーを発揮しました。
こういうケースだと80番に設定したNginxのリバースプロキシを立てて、8080番に設定したApacheと、8081番に設定したNode.jsサーバに割り振るみたいな運用になるでしょう。
そして8080と8081は外部から接続されると困るのでファイアウォールでがっちりガードすると…

Dockerならlinkという概念をうまく使って、80番はリバースプロキシでホストに接続し、
ApacheとNode.jsはホストには繋がず80番で待ち受けるという事も簡単に出来ます。
これが地味に良くて派生開発がすっごく楽です。

---

逆にデメリットがあったのであれば教えて下さい。

docker buildやdocker pullの時間が意外と重く、自動的にデプロイされる仕組みを構築しないと結構辛いです。
CIやCDが楽になるのではなく、辛いので自動的に行われる仕組みを頑張って作るので結果として楽になるだけです。

また、Dockerの問題やデメリットになるわけではなく、上記の使い方をする場合共通の課題となりますが・・・
例えばApacheに徹するマシンはMySQLに徹するマシンがどこにいるかなんて関係ないので知りません。
なので、中で走っているプログラム側としてはMySQLがどこにあるかわからず困る訳です。

Dockerにはportやlinkというオプションが用意されているので、ある程度は解消出来ますが、
コンテナ数が増えてくるとそれだけでの解決は難しく、Dockerの深い理解や知識が必要になってきます。
うちのチームではdocker-composeやfleetを使って試行錯誤中です。