隔離された環境を作成するためにVagrantとDockerのどちらを使うべきですか？
私はUbuntuを開発と配備に使用しており、孤立した環境を作る必要があります。
私はこの目的のためにVagrantかDockerを検討しています。長所と短所は何ですか、またはこれらのソリューションはどのように比較しますか？
あなたの目的が孤立であるならば、私はDockerがあなたが望むものであると思います。
Vagrantは仮想マシンマネージャです。これにより、仮想マシンの構成とプロビジョニングをスクリプト化できます。ただし、 VirtualBox （またはその他）に依存する仮想マシンであり、大きなオーバーヘッドがあります。それはあなたが巨大になることができるハードドライブファイルを持っていることを必要とします、それはたくさんのramを取ります、そしてパフォーマンスはあまり良くないかもしれません。
一方、Dockerはカーネルcgroupと名前空間を _ lxc _ で使います。つまり、ホストと同じファイルシステムで同じカーネルを使っているということです。 Dockerfileをdocker buildコマンドと共に使用して、コンテナーのプロビジョニングと構成を処理することができます。 Dockerfileの作成方法については、 docs.docker.com に例があります。とても直感的です。
あなたがVagrantを使用したいと思うかもしれない唯一の理由はあなたがあなたのUbuntuボックスでBSD、Windowsまたは他の非Linux開発をする必要があるかどうかです。そうでなければ、Dockerに行きます。
免責事項：私はVagrantを書きました！しかし私はVagrantを書いたので、私はDockerのようなソフトウェアを含むDevOpsの世界に住んでいます。私はVagrantを使う多くの会社と仕事をし、Dockerを使っています。二つの相互作用。
お話しする前に、直接答えてください： あなたの特定のシナリオ（自分で一人で仕事をし、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と直接比較しているのなら、具体的には（Dockerコンテナーしか実行できませんが）柔軟性が低い（どこかにLinuxまたはLinux Hostが必要です）ソリューションです。もちろん、プロダクションやCIについて話しているのであれば、Vagrantとの比較はありません。 Vagrantはこれらの環境には住んでいないので、Dockerを使うべきです。
組織ですべてのプロジェクトに対してDockerコンテナーのみを実行し、開発者だけをLinux上で実行している場合は、Dockerが確実に機能する可能性があります。
そうでなければ、Vagrantが提供しなければならない多くのものを失うので、Dockerを単独で使用しようとすることに利点はありません。これは、実際のビジネス/生産性の利点をもたらします。
VagrantはVirtualBox、VMware、AWS、OpenStackなどのマシンを起動できます。必要なものは関係ありません、Vagrantがそれを起動できます。 Dockerを使用している場合、VagrantはこれらのいずれにもDockerをインストールすることができるので、それらをその目的のために使用できます。
Vagrantは、すべてのプロジェクトに対する単一のワークフローです。言い換えれば、Dockerコンテナに入っているかどうかにかかわらず、プロジェクトの実行方法を学ぶために必要なことは1つだけです。たとえば、将来、競合他社がDockerと直接競合するようになった場合、Vagrantもそれを実行できます。
VagrantはWindows（XPに戻る）、Mac（10.5に戻る）、およびLinux（カーネル2.6に戻る）で動作します。 3つの場合すべてで、ワークフローは同じです。 Dockerを使用している場合、Vagrantはこれら3つのシステムすべてでDockerを実行できるマシン（VMまたはリモート）を起動できます。
Vagrantは、ネットワーキングフォルダや同期フォルダなど、高度なものや重要ではないものを構成する方法を知っています。例：Vagrantは静的IPをマシンに接続する方法やポートを転送する方法を知っています、そしてどのようなシステム（VirtualBox、VMwareなど）を使用しても設定は同じです。リモートマシンにファイルを転送します（VirtualBox共有フォルダ、NFS、rsync、Samba [plugin]など）。 Dockerを使用している場合、VagrantなしでVMを使用しているDockerであっても、手動でこれを行う必要があるか、この場合はVagrantを再発明する必要があります。
Vagrant 1.6は dockerベースの開発環境 のファーストクラスサポートをしています。これはLinuxでは仮想マシンを起動せず、MacとWindowsでは自動的に仮想マシンを起動します。最終的には、Dockerを使った作業はすべてのプラットフォーム間で統一されますが、Vagrantはまだネットワーク、同期フォルダなどの面倒な詳細を処理します。
Vagrantの代わりにDockerを使用することを支持して私が聞いたことのある具体的な反論に対処するには：
「動く部分が少ない」 - はい、すべてのプロジェクトでDockerを排他的に使用すれば可能です。それでも、Dockerのロックインの柔軟性が犠牲になっています。過去、現在、または未来のプロジェクトにDockerを使用しないことを決定した場合は、より動く部分があります。 Vagrantを使用したことがあれば、残りの部分を支える可動部分が1つあります。
「早い」 - Linuxコンテナーを実行できるホストを入手すると、Dockerは、どの仮想マシンを起動するよりも確実にコンテナーの実行が速くなります。しかし、仮想マシン（またはリモートマシン）を起動するのは一回限りのコストです。その日のうちに、ほとんどのVagrantユーザーは実際に彼らのVMを決して破壊しません。開発環境にとっては奇妙な最適化です。 Dockerが本当に輝くプロダクションでは、コンテナを素早くスピンアップ/ダウンする必要性を理解しています。
DockerとVagrantを比較することが非常に困難であることを確認できることが今や明らかになっていることを望みます。開発環境では、Vagrantはより抽象的で、より一般的です。 Docker（およびVagrantのように動作させるためのさまざまな方法）は、Vagrantの特別な使用例であり、Vagrantが提供する他のすべてを無視しています。
結論として、非常に特殊なユースケースでは、Dockerは確かにVagrantに代わる可能性があります。ほとんどの場合、そうではありません。 VagrantはDockerの使用を妨げません。それは実際にその経験をより滑らかにするためにそれができることをします。これが真実ではないと思うなら、Vagrantの目標はどのシステムでも同じようにうまく働くことであるので、私は物事を改善するために提案をすることがうれしいです。
これが物事を解決することを願っています！
私はDockerの作者です。
簡単に言えば、マシンを管理したい場合はVagrantを使用するべきです。アプリケーション環境を構築して実行したい場合は、Dockerを使用してください。
Vagrantは仮想マシンを管理するためのツールです。 Dockerは、アプリケーションを軽量コンテナにパッケージ化することによってアプリケーションを構築およびデプロイするためのツールです。コンテナは、依存関係（実行ファイル、ライブラリ、設定ファイルなど）とともにほとんどすべてのソフトウェアコンポーネントを保持し、それを保証された繰り返し可能なランタイム環境で実行することができます。これにより、アプリケーションを一度構築してどこにでもデプロイすることが非常に簡単になります。テストのためにラップトップに、次にライブデプロイのために別のサーバーに配置するなどです。
LinuxではDockerしか使えないというのはよくある誤解です。それは間違っています。 Mac、WindowsにDockerをインストールすることもできます。 Macにインストールすると、Dockerはあなたのコンテナのラッパーとして機能する小さな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を試してみて、自分の目で確かめてください:)
次に、ロックイン引数です。 msgstr "あなたが抽象としてVagrantを使用するなら、あなたはDockerに閉じ込められないでしょう！"マシンを管理するように設計されているVagrantの観点からすると、これは完全に理にかなっています。コンテナは単なる別の種類のマシンではないのですか？ Amazon EC2やVMwareと同じように、私たちはプロビジョニングツールを特定のベンダーに結び付けないように注意しなければなりません！これはロックインを作成するでしょう - Vagrantでそれをすべて抽象化したほうが良いです。これ以外はDockerのポイントを完全に見逃しています。 Dockerはマシンをプロビジョニングしません。それはあなたのアプリケーションをどこにでも落とすことができる軽量のポータブルランタイムにラップします。
アプリケーションにどのランタイムを選択しても、マシンのプロビジョニング方法とは関係ありません。たとえば、他の誰かによってプロビジョニングされたマシン（たとえば、システム管理者によって、おそらくVagrantを使用してデプロイされたEC2インスタンス）にアプリケーションをデプロイしたり、Vagrantがまったくプロビジョニングできないベアメタルマシンにデプロイすることは非常に頻繁です。逆に、Vagrantを使用して、アプリケーションの開発とは無関係のマシン、たとえばすぐに使えるWindows IISボックスなどをプロビジョニングすることができます。あるいは、Dockerを使用しないプロジェクト用にVagrantを使用してマシンをプロビジョニングすることもできます。たとえば、依存関係管理やサンドボックス化のためにrubygemsとrvmを組み合わせて使用することがあります。
要約すると、Vagrantはマシンの管理用、Dockerはアプリケーション環境の構築と実行用です。
私は、Dockerを使った経験がないことを認めることによって、私の返事の前に書いています。
私はVagrantについてかなりの経験がありますし、それを強くお勧めします。 LXCベースではなくVMベースであるという点で、これは確かにより重い解決策です。しかし、私はまともなラップトップ（8 GB RAM、i5/i7 CPU）が開発ツールと一緒にVagrant/VirtualBoxを使ってVMを実行するのに問題がないことを見つけました。
Vagrantで本当に素晴らしいことの1つは、設定を自動化するための Puppet / Chef /シェルスクリプトとの統合です。実稼働環境を構成するためにこれらのオプションのいずれかを使用している場合、あなたが手に入れようとしているのとほぼ同じである開発環境を作成することができ、これはまさにあなたが望むものです。
Vagrantのもう1つの優れた点は、Vagrantfileをアプリケーションコードと一緒にバージョン管理できることです。これは、あなたのチームの他の誰もがこのファイルを共有できることを意味し、あなたは誰もが同じ環境設定で作業していることが保証されます。
興味深いことに、VagrantとDockerは実際には無料であるかもしれません。 Vagrantは、さまざまな仮想化プロバイダーをサポートするように拡張することができ、Dockerは近い将来サポートを受けるプロバイダーの1つである可能性があります。このトピックに関する最近の議論は https://github.com/dotcloud/docker/issues/404 を参照してください。
それらは非常に補完的です。
私はすべてのプロジェクトでVirtualBox、Vagrant、Dockerの組み合わせを数ヶ月間使用しており、次のような利点を強く感じています。
Vagrantでは、Chefのソロプロビジョニングを完全に廃止することができ、vagrantファイルを作成するために必要なのは、dockerをインストールする単一の小さなシェルスクリプトを実行するマシンを準備することだけです。これは、すべてのプロジェクトに対する私のVagrantfilesがほぼ同一で非常に単純であることを意味します。
これは典型的な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をインストールするブートストラップファイルは次のようになります。
#!/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を実行しています。
Docker以外のChefのソロ設定はかなり複雑です。
本番環境に移行すると、最終的に大きなメリットが得られます。開発環境を、dockerを実行するのに十分な設定があるという点でまったく同じであるホストのインフラストラクチャに変換すると、実際にはほとんど作業が行われません。
あなたが興味を持っているならば、私は私自身のウェブサイトで開発環境に関するより詳細な記事を持っています。
Vagrant-lxc はVagrantのプラグインで、VagrantをプロビジョニングするためにLXCを使用しましょう。デフォルトのvagrant VM（VirtualBox）が持っているすべての機能を持っているわけではありませんが、dockerコンテナよりも柔軟性があるはずです。リンクには見る価値のある機能を示すビデオがあります。
Vagrantを使用すると、Dockerをプロバイダとして使用できます。 http://docs.vagrantup.com/v2/docker/ 。 VirtualBoxまたはVMwareの代わりにDockerプロバイダを使用できます。
VagrantによるプロビジョニングにDockerを使用することもできます。これは、Dockerをプロバイダーとして使用するのとは大きく異なります。 http://docs.vagrantup.com/v2/provisioning/docker.html
つまり、 Chef または Puppet をDockerに置き換えることができます。プロビジョニング担当者としてChefを使用して、プロバイダー（VM）としてのDockerのような組み合わせを使用できます。または、VirtualBoxをプロバイダとして使用し、Dockerをプロビジョニングプロバイダとして使用することもできます。
両方を使用することは、アプリケーション配信テストの重要な部分です。私はDockerに参加し始めたばかりで、そのソフトウェアの構築と提供が非常に複雑なアプリケーションチームについて非常に懸命に考えています。古典的なフェニックスプロジェクト/連続配達の状況を考えてください。
考え方は次のようになります。
- Java/Goアプリケーションコンポーネントを取り、それをコンテナとして構築します（アプリをコンテナ内に構築するのか、それともコンテナにインストールしてからインストールするのかはわかりません）。
- コンテナをVagrant VMに渡します。
- すべてのアプリケーションコンポーネントに対してこれを繰り返します。
- コーディング対象のコンポーネントについて繰り返します。
- Vagrantが管理するVMへの配信メカニズムを継続的にテストする
- 統合テストは、Docker以前よりもずっと継続的に行われていたので、いつコンテナーをデプロイするかをよく知って寝てください。
これは、VagrantがContinuous Deliveryで考えるFarley/Humblesと組み合わされた開発のためのMitchellのステートメントの論理的拡張であるように思われます。私が開発者として、統合テストとアプリケーションデリバリーに関するフィードバックループを縮小することができれば、より高品質でより良い作業環境が続くでしょう。
開発者として私はコンテナを常に一貫してVMに配信し、アプリケーションをより総合的にテストしているということは、本番リリースがさらに単純化されることを意味します。
だから私はVagrantがDockerがアプリのデプロイにもたらすであろう素晴らしい結果のいくつかを利用する方法として進化するのを見ます。
間違いなく勝利のためにドッカー！
ご存じのとおり、Vagrantは仮想マシン管理用で、Dockerはソフトウェアコンテナ管理用です。違いがわからない場合は、次のようにします。ソフトウェアコンテナは、同じマシンとカーネルを他のソフトウェアコンテナと共有できます。コンテナーを使用すると、複数のオペレーティングシステム（カーネル）のリソースを無駄にすることがないので、コストを節約できます。サーバーごとにより多くのソフトウェアをパックできるため、十分な分離を維持できます。
もちろん、それ自体の落とし穴や課題に気を配るための新しい分野です。
要件が単一マシンのリソース制限を超える場合は、Docker Swarmを選択してください。
実際のOracle Javaマガジンには、DockerをVagrant（およびPuppet）と組み合わせて使用する方法についての非常に有益な記事があります。
結論
Dockerの軽量コンテナは、従来のVMと比べて高速であり、開発者の間でも、CDやDevOpsの取り組みの一環としても普及しています。あなたの目的が孤立であるならば、Dockerは素晴らしい選択です。 VagrantはVMマネージャで、これを使って個々のVMの設定をスクリプト化したり、プロビジョニングを行うことができます。ただし、VirtualBox（または別のVMマネージャ）に依存するVMは、比較的大きなオーバーヘッドがあります。ハードドライブをアイドル状態にする必要がありますが、これは巨大になる可能性があり、大量のRAMを消費し、パフォーマンスは最適とは言えません。 Dockerは、LXCを介したカーネルcgroupと名前空間の分離を使用します。これは、ホストと同じIileシステムで同じカーネルを使用していることを意味します。 Vagrantは抽象化の点でDockerより上のレベルなので、実際には比較できません。 Puppetなどの構成管理ツールは、ターゲット環境のプロビジョニングに広く使用されています。 Dockerを使えば、既存のPuppetベースのソリューションを再利用するのは簡単です。ソリューションをスライスしてインフラストラクチャをPuppetでプロビジョニングすることもできます。ミドルウェア、ビジネスアプリケーション、またはその両方がDockerでプロビジョニングされている。そしてDockerはVagrantに包まれています。このようなさまざまなツールを使用して、自分のシナリオに最適なものを作成できます。
DevOpsでDockerコンテナーを作成、使用、および編成する方法 http://www.javamagazine.mozaicreader.com/JulyAug2015#&pageSet=34&page=0