BLOGサブスレッドの日常
2020.04.09
DockerとVagrantの使い分け
kodani
最近、DockerやVagrantといった仮想化プラットフォームを頻繁に触る機会がありました。
正直なところ仮想化とは縁遠い生活をしていたので、今更ですが入門することに。
これまで、DockerとVagrantはVirtualBoxやVMWareのように一部の違いはあれどどっちも似たようなもので、好きな方を使えばいいでしょ程度に考えていました。
まずここの認識が違いました。
Dockerは何もかも全部仮想化されているわけではなく、カーネルはホストと共通だったんですね・・・。(仮想化する内容を絞っている)
Vagrantの方は完全にVMを管理しているので本当に仮想化していますが。
ひとまず、現在は次のような理解をしております。
Vagrant
- ホストの違いを吸収するために利用する
- ホスト環境を共有しやすくするために利用する
- VMを管理するものである
- VM自体を管理するのでDockerと違って状態(新しく作ったファイルなど)は揮発しない
Docker
- アプリのプロセスを分離するために利用する
- 各アプリが依存するものを、アプリごとに用意できて競合しない
- ローカル環境と各ステージングのサーバで、アプリ実行環境を統一するために利用する
- コンテナを管理するものである
- コンテナの状態(新しく作ったファイルなど)は揮発するので、別途永続化の手立てを考える必要がある
なるほど、こうしてみるとたしかに用途が違うものです。
開発環境を用意する時、なるべく実際の運用環境に近づけたいですよね。
そのために色々なライブラリを入れたり、ビルド環境を整えていると思います。
しかし作業者同士で開発環境に微妙な差異が発生していることもあり、それが製品の動作に影響を与えることもあります。
そこで、vagrantとdockerを組み合わせて開発環境を作成し共有することで環境構築の手間を減らすことができます。製品がより安定した動作を行えるようにもなります。
例として、プロダクション環境で
- Webサーバを1台
- DBサーバを1台
の構成にしているとします。
その環境を開発環境として再現するために
- vagrant(各dockerのホストの役割)
- vagrant上のdocker(Webサーバの役割)
- vagrant上のdocker(DBサーバの役割)
という構成にすることが考えられます。
ところで、Vagrantで動かしたVM上でさらにVagrantを導入しておけば、上記の例に出したVagrantとDockerの組み合わせに近い運用はできそうです。
リソースが無駄になるので現実的ではないですし、わざわざそうする意味もないのでやる必要は無いと思いますが。
ともかくちょっとだけコンテナ周りを理解出来たような気がしました。
参考資料
Docker
Vagrant
この記事を書いた人
kodani
