隔離された環境を作るにはVagrantとDockerのどちらを使うべきか

vagrant docker


私は開発やデプロイにUbuntuを使用していますが、隔離された環境を作りたいというニーズがあります。

そのためにVagrantかDockerのどちらかを検討しています。長所と短所、あるいはこれらのソリューションの比較を教えてください。




Answer 1 creack


隔離が目的ならDockerでいいと思います。

Vagrantは仮想マシンマネージャーです。仮想マシンの構成とプロビジョニングをスクリプト化できます。ただし、VirtualBox(またはその他)に依存する仮想マシンであり、オーバーヘッドが非常に大きくなります。巨大になる可能性のあるハードドライブファイルが必要であり、RAMを大量に消費し、パフォーマンスがあまり良くない場合があります。

一方、DockerはLXCを介してカーネルcgroupとネームスペースを使用します。これは、ホストと同じカーネルお​​よび同じファイルシステムを使用していることを意味します。コンテナーのプロビジョニングと構成を処理するために、Dockerfileをdocker docker build コマンドで使用できます。docs.docker.comに、Dockerfileを作成する方法の例があります。とても直感的です。

Vagrantを使いたいと思う唯一の理由は、BSDやWindowsなどLinux以外の開発をUbuntuで行う必要がある場合です。それ以外の場合はDockerを使いましょう。




Answer 2 Mitchell


免責事項:私はヴァグラントを書いた!しかし、私はVagrantを作成したため、ほとんどの時間をDockerなどのソフトウェアを含むDevOpsの世界に住んでいます。私はVagrantを使用している多くの企業と協力しており、多くの企業がDockerを使用しており、2つがどのように相互作用するかを理解しています。

話をする前に、直接的な答えを述べます。特定のシナリオ(自分で作業している、Linuxで作業している、本番環境でDockerを使用している)では、Dockerだけに固執して単純化できます。他の多くのシナリオ(後で説明します)では、それほど簡単ではありません。

VagrantとDockerを直接比較するのは正しくない。いくつかのシナリオでは重なることもありますが、大多数のシナリオでは重ならないこともあります。実際には、VagrantとBoot2Dockerのようなもの(Dockerを動かすことができる最小限のOS)との比較がより適切でしょう。Vagrantは抽象度の点でDockerの上のレベルなので、ほとんどの場合は公平な比較ではありません。

Vagrantは、開発を目的としてアプリやサービスを実行するための機能を起動します。これは、VirtualBox、VMwareにあります。 AWSやOpenStackのようにリモートにすることもできます。その中で、コンテナーを使用する場合、Vagrantは気にせず、それを受け入れます。たとえば、Dockerコンテナーを自動的にインストール、プルダウン、ビルド、および実行できます。 Vagrant 1.6では、VagrantはDocker ベースの開発環境を備えており、Linux、Mac、Windows全体でVagrantと同じワークフローでDockerの使用をサポートしています。 Vagrantは、ここでDockerを置き換えることを試みていません。Dockerプラクティスを採用しています。

Dockerは特にDockerコンテナを実行します。Vagrantと直接比較するのであれば、Vagrantの方が具体的には(Dockerコンテナしか動かせない)、柔軟性が低い(どこかでLinuxかLinuxホストが必要)ソリューションです。もちろん、本番環境やCIの話をしているのであれば、Vagrantと比較することはできません。Vagrantはこれらの環境では生きていないので、Dockerを使うべきです。

もしあなたの組織がすべてのプロジェクトでDockerコンテナだけを運用していて、開発者がLinux上でしか動いていないのであれば、Dockerは間違いなくあなたのために機能するでしょう。

そうでなければ、Dockerを単独で使おうとするメリットはないと思います。

  • VagrantはVirtualBox、VMware、AWS、OpenStackなどのマシンを起動することができます。何が必要かは関係ありませんが、Vagrantは起動することができます。Dockerを使っているのであれば、VagrantはこれらのどれかにDockerをインストールすることができるので、その目的で使うことができます。

  • Vagrantはすべてのプロジェクトのための単一のワークフローです。別の言い方をすれば、Dockerコンテナに入っていようがいまいが、プロジェクトを動かすために人々が身につけなければならないことの一つに過ぎません。将来、例えばDockerと直接競合するような競合が出てきた場合、Vagrantはそれも実行できるようになります。

  • VagrantはWindows (XPまで)、Mac (10.5まで)、Linux (kernel 2.6まで)で動作します。この3つのケースでは、ワークフローは同じです。Dockerを使っている場合、Vagrantはこれら3つのシステム全てでDockerを実行できるマシン(VMやリモート)を起動することができます。

  • Vagrantはネットワーキングやフォルダの同期など、高度な設定や、他愛のない設定をする方法を知っています。例えば 同期フォルダについては、Vagrantはローカルのファイルをリモートマシンに転送するための複数のメカニズムを提供しています(VirtualBoxの共有フォルダ、NFS、rsync、Samba [プラグイン]など)。もしあなたがDockerを使っている場合、Vagrantを使っていないVMでもDockerを使っている場合は、手動でこれをしなければならないか、この場合はVagrantを再発明しなければならないでしょう。

  • Vagrant 1.6は、Dockerベースの開発環境をファーストクラスでサポートしています。これはLinuxでは仮想マシンを起動せず、MacおよびWindowsで仮想マシンを自動的に起動します。最終的な結果として、Dockerでの作業はすべてのプラットフォームで統一されていますが、Vagrantはネットワーキング、同期フォルダーなどの面倒な詳細を処理します。

VagrantではなくDockerを使うことに賛成していると聞いた具体的な反論に対処するために。

  • "動く部分が少なくて済む"-すべてのプロジェクトでDockerを独占的に使用しているのであれば、そうなる可能性があります。そうであっても、Dockerのロックインのために柔軟性を犠牲にしていることになります。過去、現在、未来を問わず、どんなプロジェクトにもDockerを使わないと決めた場合、可動部分が増えることになります。もしあなたがVagrantを使っていたとしたら、他の部分をサポートしている可動部分が1つあることになります。

  • "速い!"-Linuxコンテナを実行できるホストを用意してしまえば、どんな仮想マシンを起動するよりもDockerの方がコンテナの実行速度は間違いなく速いです。しかし、仮想マシン(またはリモートマシン)の起動には1回限りのコストがかかります。一日のうちに、ほとんどのVagrantユーザーは実際にVMを破壊することはありません。開発環境では妙に最適化されています。Dockerが本当に輝く本番環境では、アップダウンコンテナを素早く回転させる必要性を理解しています。

DockerとVagrantを比較するのは非常に難しく、正しくないと思います。開発環境としては、Vagrantの方がより抽象的で一般的です。Docker(とVagrantのように動作させるための様々な方法)はVagrantの特定のユースケースであり、Vagrantが提供している他の全てを無視しています。

結論から言うと、非常に特殊なユースケースでは、Dockerは確かにVagrantの代わりになる可能性があります。しかし、ほとんどのユースケースではそうではありません。VagrantはDockerの利用を妨げるものではなく、実際にはその経験をよりスムーズにするためにできることをしてくれます。もしこれが真実ではないと分かったら、私は物事を改善するための提案を喜んで受け止めます。

これでスッキリするといいですね!




Answer 3 Solomon Hykes


Dockerの作者です。

簡単に言うと、マシンを管理したいならVagrantを使うべきだということです。そして、アプリケーション環境を構築して実行したいのであれば、Dockerを使うべきだということです。

Vagrantは仮想マシンを管理するツールです。Dockerはアプリケーションを軽量コンテナにパッケージングして構築し、デプロイするためのツールです。コンテナは、依存関係(実行ファイル、ライブラリ、設定ファイルなど)と一緒に、ほぼすべてのソフトウェアコンポーネントを保持し、保証された再現性のあるランタイム環境で実行することができます。これにより、アプリを一度ビルドして、テスト用にラップトップにデプロイし、次にライブデプロイ用に別のサーバーにデプロイするなど、どこでも簡単にデプロイすることができます。

LinuxではDockerしか使用できないというのは、よくある誤解です。それは不正解です。 MacおよびWindowsにDockerをインストールすることもできます。 DockerをMacにインストールすると、コンテナーのラッパーとして機能する小さなLinux VM(ディスク上で25 MB!)がバンドルされます。インストールすると、これは完全に透過的です。 Dockerコマンドラインをまったく同じ方法で使用できます。これにより、両方の長所が得られます。非常に軽量で、テストが簡単で、移動が容易なコンテナを使用して、アプリケーションをテストおよび開発できます(再利用可能なコンテナを共有するためのhttps://hub.docker.comを参照してください)。 Dockerコミュニティ)、そして仮想マシンの管理の詳細について心配する必要はありません。

理論的にはDockerの抽象化レイヤーとしてVagrantを使うことは可能です。私は2つの理由でこれに反対することをお勧めします。

  • まず、VagrantはDockerの抽象化には向いていません。Vagrantは仮想マシンを管理するために設計されていました。Dockerはアプリケーションのランタイムを管理するように設計されていました。つまり、Dockerは設計上、よりリッチな方法でアプリケーションと対話することができ、アプリケーションランタイムに関するより多くの情報を持っています。Dockerのプリミティブは、プロセス、ログストリーム、環境変数、コンポーネント間のネットワークリンクです。Vagrantのプリミティブはマシン、ブロックデバイス、ssh鍵です。Vagrantは単にスタックの下に座っているだけで、コンテナと対話する唯一の方法は、コンテナを「起動」して「ログイン」することができる別の種類のマシンであるかのように装うことです。だから、確かに、Dockerプラグインで "vagrant up "と入力すれば、何かきれいなことが起こるでしょう。Dockerができることの幅の広さの代用になるのでしょうか?ネイティブなDockerを数日試してみて、自分の目で確かめてみてください。)

  • 2つ目は、ロックイン論。"Vagrantを抽象化して使えば、Dockerにロックインされることはない!" マシンを管理するために設計されたVagrantの観点から見れば、これは完全に理にかなっています:コンテナはただの別の種類のマシンではないでしょうか?Amazon EC2やVMwareのように、プロビジョニングツールを特定のベンダーに縛られないように注意しなければなりません。これではロックインが発生してしまいます-Vagrantで全てを抽象化した方が良いでしょう。しかし、これはDockerのポイントを完全に見逃している。Dockerはマシンをプロビジョニングするのではなく、アプリケーションを軽量なポータブルランタイムで包み込み、どこにでも落とせるようにします。

アプリケーションにどのようなランタイムを選択するかは、マシンのプロビジョニング方法とは関係ありません!例えば、アプリケーションを他の誰かがプロビジョニングしたマシンにデプロイすることはよくあります。例えば、他の誰かがプロビジョニングしたマシン(例えば、システム管理者がデプロイしたEC2のインスタンス、Vagrantを使っているかもしれません)にアプリケーションをデプロイしたり、Vagrantがプロビジョニングできないベアメタルマシンにアプリケーションをデプロイすることはよくあります。逆に、アプリケーションの開発とは関係のないマシンのプロビジョニングにVagrantを使うこともできます。あるいは、Dockerを使っていないプロジェクトのためにVagrantを使ってマシンをプロビジョニングすることもできます-依存関係管理やサンドボックス化のためにrubygemsとrvmを組み合わせて使っているかもしれません。

まとめ:Vagrantはマシンを管理するためのもので、Dockerはアプリケーション環境を構築して実行するためのものです。




Answer 4 Chris Bushell


私はDockerを使った経験がないことを認めて返事を前置きしますが、それは、多くの牽引力を得ている本当にきちんとしたソリューションに見えるものを熱心に観察しているからです。

私はVagrantでかなりの量の経験があり、強くお勧めできます。LXCベースではなくVMベースであるという点で、それは確かにより重いソリューションです。ただし、適切なラップトップ(8 GB RAM、i5 / i7 CPU)では、開発ツールと一緒にVagrant / VirtualBoxを使用してVMを実行しても問題はないことがわかりました。

Vagrantのすばらしい点の1つは、構成を自動化するためのPuppet / Chef / shellスクリプトとの統合です。これらのオプションのいずれかを使用して本番環境を構成している場合は、取得しようとしているものとほぼ同じ開発環境を作成できます。これはまさに必要なことです。

Vagrantのもう一つの素晴らしい点は、アプリケーションコードと一緒にVagrantfileもバージョン管理できることです。つまり、チーム内の他の誰もがこのファイルを共有することができ、全員が同じ環境設定で作業できることが保証されています。

興味深いことに、VagrantとDockerは実際には補完的である場合があります。Vagrantは、さまざまな仮想化プロバイダーをサポートするように拡張できます。Dockerは、近い将来サポートされるプロバイダーの1つである可能性があります。このトピックに関する最近の議論については、https://github.com/dotcloud/docker/issues/404を参照してください。




Answer 5 Mark Stratmann


それらは非常に補完的なものです。

数ヶ月前からVirtualBox、Vagrant、Dockerを組み合わせて全てのプロジェクトで使用していますが、以下のようなメリットを強く感じています。

VagrantではChefのソロプロビジョニングを完全に省くことができ、vagrantファイルが必要なのはdockerをインストールする小さなシェルスクリプトを実行するマシンを用意するだけです。つまり、どのプロジェクトでも私のVagrantfileはほとんど同じで、とてもシンプルなものになっています。

ここに代表的なVagrantfileがあります。

# -*- mode: ruby -*-
# vi: set ft=ruby :
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "mark2"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
  [3000, 5000, 2345, 15672, 5672, 15674, 27017, 28017, 9200, 9300, 11211, 55674, 61614, 55672, 5671, 61613].each do |p|
    config.vm.network :forwarded_port, guest: p, host: p
  end
  config.vm.network :private_network, ip: "192.168.56.20"
  config.vm.synced_folder ".", "/vagrant", :type => "nfs"
  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "2048"]
    vb.customize ["modifyvm", :id, "--cpus", "2"]
  end
  # Bootstrap to Docker
  config.vm.provision :shell, path: "script/vagrant/bootstrap", :privileged => true
  # Build docker containers
  config.vm.provision :shell, path: "script/vagrant/docker_build", :privileged => true
  # Start containers
  # config.vm.provision :shell, path: "script/vagrant/docker_start", :privileged => true
end

dockerをインストールするBootstrapファイルは以下のようになります。

#!/usr/bin/env bash
echo 'vagrant  ALL= (ALL:ALL) NOPASSWD: ALL' >> /etc/sudoers
apt-get update -y
apt-get install htop -y
apt-get install linux-image-extra-`uname -r` -y
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list
apt-get update -y
apt-get install lxc-docker -y
apt-get install curl -y

これで、必要なサービスをすべて実行するために、以下のようなdocker_startスクリプトを作成しました。

#!/bin/bash
cd /vagrant
echo Starting required service containers
export HOST_NAME=192.168.56.20
# Start MongoDB
docker run --name=mongodb --detach=true --publish=27017:27017 --publish=28017:28017 dockerfile/mongodb
read -t5 -n1 -r -p "Waiting for mongodb to start..." key
# Start rabbitmq
docker run --name=rabbitmq --detach=true --publish=5671:5671 --publish=5672:5672 --publish=55672:55672 --publish=15672:15672 --publish=15674:15674 --publish=61613:61613 --env RABBITMQ_USER=guest --env RABBITMQ_PASS=guest rabbitmq
read -t5 -n1 -r -p "Waiting for rabbitmq to start..." key
# Start cache
docker run --name=memcached --detach=true --publish=11211:11211  ehazlett/memcached
read -t5 -n1 -r -p "Waiting for cache to start..." key
# Start elasticsearch
docker run --name=elasticsearch --detach=true --publish=9200:9200 --publish=9300:9300 dockerfile/elasticsearch
read -t5 -n1 -r -p "Waiting for elasticsearch to start..." key
echo "All services started"

この例では、MongoDB、Elastisearch、RabbitMQ、Memcached を実行しています。

ドッカーではないChefのソロ設定はかなり複雑になります。

最後の大きなプラスは、本番環境に移行したときに得られるもので、開発環境をdockerを実行するのに十分な設定を持っているという点ですべて同じホストのインフラストラクチャに変換することで、実際にはほとんど作業をしないことを意味します。

もし興味があれば、私は自分のウェブサイトで開発環境についてのより詳細な記事を持っています。

Vagrant Docker開発環境の実装