Czy powinienem używać Vagrant lub Docker do tworzenia izolowanego środowiska? [Zamknięte]

Używam Ubuntu do programowania i wdrażania i potrzebuję stworzyć izolowane środowisko.

W tym celu rozważam Vagrant lub Docker. Jakie są zalety i wady lub jak się różnią te rozwiązania?

Jeśli twoim celem jest izolacja, myślę, że Docker jest tym, czego chcesz.

Vagrant to menedżer maszyn wirtualnych. Pozwala na skryptowanie konfiguracji maszyny wirtualnej, a także obsługi administracyjnej. Jednak nadal jest to maszyna wirtualna, w zależności od VirtualBox (lub innych), z ogromnym narzutem. Wymaga pliku dysku twardego, który może być ogromny, zajmuje dużo pamięci RAM, a wydajność może nie być bardzo dobra.

Z drugiej strony Docker używa cgroup jądra i przestrzeni nazw przez LXC . Oznacza to, że używasz tego samego jądra co host i ten sam system plików. Możesz użyć Dockerfile z docker buildpoleceniem, aby obsłużyć obsługę administracyjną i konfigurację swojego kontenera. Na stronie docs.docker.com masz przykład, jak utworzyć plik Docker; to jest bardzo intuicyjne.

Jedynym powodem, dla którego możesz chcieć użyć Vagrant, jest to, że musisz wykonać BSD, Windows lub inne niż Linuksowe prace rozwojowe na swoim Ubuntu. W przeciwnym razie wybierz Docker.

Uwaga: Napisałem Vagrant! Ale ponieważ napisałem Vagrant, większość czasu spędzam żyjąc w świecie DevOps, który zawiera oprogramowanie takie jak Docker. Pracuję z wieloma firmami używającymi Vagrant, a wiele używa Dockera i widzę, jak te dwie rzeczy się ze sobą łączą.

Zanim zacznę za dużo mówić, bezpośrednia odpowiedź: w twoim konkretnym scenariuszu (sam pracujesz, pracujesz na Linuksie, używasz Dockera w produkcji), możesz trzymać się samego Dockera i uprościć sprawy. W wielu innych scenariuszach (omawiam dalej) nie jest to takie łatwe.

Niepoprawne jest bezpośrednie porównywanie Vagrant do Dockera. W niektórych scenariuszach pokrywają się, aw zdecydowanej większości nie. W rzeczywistości bardziej trafnym porównaniem byłoby Vagrant kontra coś takiego jak Boot2Docker (minimalny system operacyjny, który może obsługiwać Docker). Vagrant to poziom powyżej Dockera pod względem abstrakcji, więc w większości przypadków nie jest to uczciwe porównanie.

Vagrant wprowadza rzeczy do uruchamiania aplikacji / usług w celu rozwoju. Może to być na VirtualBox, VMware. Może być zdalny jak AWS, OpenStack. Jeśli używasz kontenerów, Vagrant nie dba o to i obejmuje to: może na przykład automatycznie instalować, rozkładać, budować i uruchamiać kontenery Docker. W Vagrant 1.6 Vagrant ma środowiska programistyczne oparte na dokerze i obsługuje Docker z takim samym obiegiem pracy jak Vagrant w systemach Linux, Mac i Windows. Vagrant nie próbuje tutaj zastąpić Dockera, obejmuje praktyki Dockera.

Docker w szczególności obsługuje kontenery Docker. Jeśli porównujesz bezpośrednio do Vagrant: jest to w szczególności bardziej szczegółowe (można uruchomić tylko kontenery Docker), mniej elastyczne (wymaga Linuxa lub hosta Linuxa). Oczywiście, jeśli mówisz o produkcji lub CI, nie ma porównania do Vagrant! Vagrant nie mieszka w tych środowiskach, dlatego należy użyć Dockera.

Jeśli Twoja organizacja obsługuje tylko kontenery Docker dla wszystkich swoich projektów i ma tylko programistów działających w systemie Linux, to dobrze, Docker może na pewno działać dla Ciebie!

W przeciwnym razie nie widzę korzyści z próby korzystania z Dockera w pojedynkę, ponieważ tracisz wiele z tego, co Vagrant ma do zaoferowania, które mają realne korzyści biznesowe / produkcyjne:

• Vagrant może uruchamiać maszyny VirtualBox, VMware, AWS, OpenStack itp. Nie ma znaczenia, czego potrzebujesz, Vagrant może go uruchomić. Jeśli używasz Dockera, Vagrant może zainstalować Docker na dowolnym z nich, abyś mógł z nich korzystać w tym celu.

• Vagrant to pojedynczy przepływ pracy dla wszystkich twoich projektów. Innymi słowy, ludzie muszą się uczyć prowadzenia projektu, niezależnie od tego, czy znajduje się on w kontenerze Docker, czy nie. Jeśli, na przykład, w przyszłości powstanie konkurent, aby konkurować bezpośrednio z Dockerem, Vagrant będzie mógł go uruchomić.

• Vagrant działa w systemach Windows (powrót do XP), Mac (powrót do 10.5) i Linux (powrót do jądra 2.6). We wszystkich trzech przypadkach przepływ pracy jest taki sam. Jeśli korzystasz z Dockera, Vagrant może uruchomić maszynę (VM lub zdalną), która może uruchomić Docker na wszystkich trzech tych systemach.

• Vagrant wie, jak skonfigurować niektóre zaawansowane lub nietrywialne rzeczy, takie jak tworzenie sieci i synchronizowanie folderów. Na przykład: Vagrant wie, jak dołączyć statyczny adres IP do komputera lub portów przesyłania dalej, a konfiguracja jest taka sama bez względu na używany system (VirtualBox, VMware itp.). W przypadku zsynchronizowanych folderów Vagrant zapewnia wiele mechanizmów uzyskiwania lokalnych pliki do zdalnego komputera (foldery współdzielone VirtualBox, NFS, rsync, Samba [wtyczka] itp.). Jeśli używasz Dockera, nawet Dockera z maszyną wirtualną bez Vagranta, musisz to zrobić ręcznie lub w takim przypadku musielibyście wynaleźć Vagrant.

• Vagrant 1.6 ma doskonałą obsługę środowisk programistycznych opartych na dokerach . To nie uruchomi maszyny wirtualnej w systemie Linux i automatycznie uruchomi maszynę wirtualną na komputerach Mac i Windows. Efektem końcowym jest to, że praca z Dockerem jest jednolita na wszystkich platformach, podczas gdy Vagrant nadal obsługuje żmudne szczegóły takich rzeczy, jak sieć, synchronizowane foldery itp.

Aby odnieść się do konkretnych kontrargumentów, które słyszałem na korzyść używania Dockera zamiast Vagrant:

• „Jest mniej ruchomych części” - Tak, może być, jeśli używasz Dockera wyłącznie do każdego projektu. Nawet wtedy poświęcenie elastyczności dla blokady Docker. Jeśli kiedykolwiek zdecydujesz się nie używać Dockera w żadnym projekcie, przeszłości, teraźniejszości lub przyszłości, będziesz mieć więcej ruchomych części. Jeśli używałeś Vagrant, masz tę jedną ruchomą część, która wspiera resztę.

• "To jest szybsze!" - Gdy masz hosta, który może obsługiwać kontenery Linux, Docker jest zdecydowanie szybszy w uruchamianiu kontenera niż uruchomienie jakiejkolwiek maszyny wirtualnej. Ale uruchomienie maszyny wirtualnej (lub maszyny zdalnej) to jednorazowy koszt. W ciągu dnia większość użytkowników Vagrant nigdy nie niszczy swoich maszyn wirtualnych. Jest to dziwna optymalizacja dla środowisk programistycznych. W produkcji, w której Docker naprawdę błyszczy, rozumiem potrzebę szybkiego obracania kontenerów w górę / w dół.

Mam nadzieję, że teraz wyraźnie widać, że porównanie Dockera z Vagrantem jest bardzo trudne i uważam, że to nieprawda. W środowiskach programistycznych Vagrant jest bardziej abstrakcyjny, bardziej ogólny. Docker (i różne sposoby, dzięki którym zachowuje się jak Vagrant) jest szczególnym przypadkiem użycia Vagrant, ignorując wszystko, co Vagrant ma do zaoferowania.

Podsumowując: w bardzo specyficznych przypadkach użycia Docker jest z pewnością możliwym zamiennikiem Vagrant. W większości przypadków tak nie jest. Vagrant nie utrudnia korzystania z Dockera; robi to, co w jego mocy, aby to doświadczenie było płynniejsze. Jeśli okaże się, że to nieprawda, chętnie przyjmę sugestie dotyczące ulepszeń, ponieważ celem Vagrant jest równa praca z dowolnym systemem.

Mam nadzieję, że to wszystko wyjaśni!

Jestem autorem Dockera.

Krótka odpowiedź brzmi: jeśli chcesz zarządzać maszynami, powinieneś użyć Vagrant. A jeśli chcesz budować i uruchamiać środowiska aplikacji, powinieneś użyć Dockera.

Vagrant to narzędzie do zarządzania maszynami wirtualnymi. Docker to narzędzie do budowania i wdrażania aplikacji poprzez pakowanie ich w lekkie pojemniki. Kontener może pomieścić prawie każdy komponent oprogramowania wraz z jego zależnościami (pliki wykonywalne, biblioteki, pliki konfiguracyjne itp.) I wykonywać go w gwarantowanym i powtarzalnym środowisku wykonawczym. Dzięki temu bardzo łatwo można zbudować aplikację raz i wdrożyć ją w dowolnym miejscu - na laptopie w celu przetestowania, a następnie na różnych serwerach w celu wdrożenia na żywo itp.

To powszechne błędne przekonanie, że Docker można używać tylko w systemie Linux. To jest niepoprawne; możesz także zainstalować Docker na Macu i Windowsie. Po zainstalowaniu na komputerze Mac Docker dołącza małą maszynę wirtualną z systemem Linux (25 MB na dysku!), Która działa jak opakowanie dla twojego kontenera. Po zainstalowaniu jest całkowicie przezroczysty; możesz użyć wiersza polecenia Docker w dokładnie taki sam sposób. To daje najlepsze z obu światów: możesz testować i rozwijać swoją aplikację za pomocą kontenerów, które są bardzo lekkie, łatwe do przetestowania i łatwe do przenoszenia (patrz na przykład https://hub.docker.com na temat udostępniania pojemników wielokrotnego użytku z społeczność Dockerów) i nie musisz martwić się drobiazgowymi szczegółami zarządzania maszynami wirtualnymi, które i tak są tylko środkiem do celu.

Teoretycznie można użyć Vagrant jako warstwy abstrakcji dla Dockera. Odradzam to z dwóch powodów:

• Po pierwsze, Vagrant nie jest dobrą abstrakcją dla Dockera. Vagrant został zaprojektowany do zarządzania maszynami wirtualnymi. Docker został zaprojektowany do zarządzania środowiskiem wykonawczym aplikacji. Oznacza to, że Docker z założenia może współdziałać z aplikacją w bogatszy sposób i ma więcej informacji na temat środowiska wykonawczego aplikacji. Prymitywami w Dockerze są procesy, strumienie dziennika, zmienne środowiskowe i połączenia sieciowe między komponentami. Prymitywami w Vagrant są maszyny, urządzenia blokowe i klucze ssh. Vagrant po prostu siedzi niżej na stosie, a jedynym sposobem, w jaki może wchodzić w interakcję z kontenerem, jest udawanie, że jest to inny rodzaj maszyny, którą można „uruchomić” i „zalogować się”. Oczywiście możesz wpisać „włóczęgostwo” za pomocą wtyczki Docker, a wydarzy się coś ładnego. Czy jest to substytut pełnego zakresu możliwości Dockera? Spróbuj natywnego Dockera przez kilka dni i przekonaj się sam :)

• Po drugie, argument blokujący. „Jeśli użyjesz Vagrant jako abstrakcji, nie zostaniesz zamknięty w Dockerze!”. Z punktu widzenia Vagrant, który jest przeznaczony do zarządzania maszynami, ma to doskonały sens: czy kontenery nie są po prostu innym rodzajem maszyny? Podobnie jak Amazon EC2 i VMware, musimy uważać, aby nie wiązać naszych narzędzi do udostępniania z żadnym konkretnym dostawcą! To stworzy blokadę - lepiej wyodrębnić to wszystko za pomocą Vagrant. Tyle że całkowicie pomija sens Dockera. Docker nie udostępnia maszyn; otacza twoją aplikację lekkim przenośnym środowiskiem uruchomieniowym, które można upuścić w dowolnym miejscu.

Jakie środowisko wykonawcze wybierzesz dla swojej aplikacji, nie ma nic wspólnego z tym, jak udostępniasz swoje maszyny! Na przykład dość często wdraża się aplikacje na komputerach, które są udostępniane przez kogoś innego (na przykład instancja EC2 wdrożona przez administratora systemu, być może za pomocą Vagrant), lub na komputerach bez systemu operacyjnego, których Vagrant nie może w ogóle udostępnić. I odwrotnie, możesz używać Vagrant do udostępniania maszyn, które nie mają nic wspólnego z tworzeniem aplikacji - na przykład gotowym do użycia pudełkiem Windows IIS lub czymś podobnym. Lub możesz użyć Vagrant do udostępniania maszyn dla projektów, które nie używają Dockera - być może używają kombinacji rubygemów i rvm na przykład do zarządzania zależnościami i piaskownicy.

Podsumowując: Vagrant służy do zarządzania komputerami, a Docker służy do budowania i uruchamiania środowisk aplikacji.

Przedkładam moją odpowiedź, przyznając, że nie mam doświadczenia z Dockerem, poza tym, że jestem zapalonym obserwatorem tego, co wydaje się być naprawdę schludnym rozwiązaniem, które zyskuje dużą przyczepność.

Mam spore doświadczenie z Vagrant i mogę go bardzo polecić. Z pewnością jest to rozwiązanie o większej wadze, ponieważ oparte jest na VM zamiast na LXC. Jednak znalazłem przyzwoity laptop (8 GB pamięci RAM, procesor i5 / i7) nie ma problemów z uruchomieniem maszyny wirtualnej za pomocą Vagrant / VirtualBox wraz z narzędziami programistycznymi.

Jedną z naprawdę świetnych rzeczy w Vagrant jest integracja ze skryptami Puppet / Chef / shell do automatyzacji konfiguracji. Jeśli używasz jednej z tych opcji, aby skonfigurować środowisko produkcyjne, możesz utworzyć środowisko programistyczne, które będzie tak samo identyczne, jak to tylko możliwe, i właśnie tego chcesz.

Inną wspaniałą rzeczą w Vagrant jest to, że możesz wersjonować swój plik Vagrant wraz z kodem aplikacji. Oznacza to, że wszyscy inni w zespole mogą udostępniać ten plik i masz gwarancję, że wszyscy pracują z tą samą konfiguracją środowiska.

Co ciekawe, Vagrant i Docker mogą faktycznie być komplementarne. Vagrant może zostać rozszerzony o obsługę różnych dostawców wirtualizacji i możliwe, że Docker jest jednym z takich dostawców, który otrzyma wsparcie w najbliższej przyszłości. Najnowsze dyskusje na ten temat można znaleźć na stronie https://github.com/dotcloud/docker/issues/404 .

Są bardzo komplementarne.

Używam kombinacji VirtualBox, Vagrant i Docker do wszystkich moich projektów od kilku miesięcy i mocno odczuwam następujące korzyści.

W Vagrant możesz całkowicie zrezygnować z samodzielnej obsługi administracyjnej Chef, a wszystko, czego potrzebujesz, aby zrobić swój błędny plik, to przygotować maszynę, która uruchomi pojedynczy mały skrypt powłoki, który zainstaluje dokera. Oznacza to, że moje pliki Vagrant dla każdego projektu są prawie identyczne i bardzo proste.

Oto typowy plik 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

Plik Bootstrap, który instaluje okno dokowane, wygląda następująco

#!/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

Teraz, aby uzyskać wszystkie usługi, których potrzebuję, mam skrypt docker_start, który wygląda mniej więcej tak

#!/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"

W tym przykładzie używam MongoDB, Elastisearch, RabbitMQ i Memcached

Konfiguracja pojedynczego szefa kuchni bez dokera byłaby znacznie bardziej skomplikowana.

Ostatni duży plus jest uzyskiwany, gdy przenosisz się do produkcji, przekładając środowisko programistyczne na infrastrukturę hostów, które są takie same, ponieważ mają wystarczającą konfigurację, aby uruchomić dokera, co naprawdę oznacza bardzo niewiele pracy.

Jeśli jesteś zainteresowany, mam bardziej szczegółowy artykuł na temat środowiska programistycznego na mojej własnej stronie internetowej

Wdrażanie środowiska programistycznego Vagrant / Docker

Vagrant-lxc to wtyczka do Vagrant, która pozwala używać LXC do udostępniania Vagrant. Nie ma wszystkich funkcji, które ma domyślna wirtualna maszyna wirtualna (VirtualBox), ale powinna zapewnić większą elastyczność niż kontenery dokerów. W linku znajduje się film pokazujący jego możliwości, które warto obejrzeć.

Dzięki Vagrant możesz teraz mieć Dockera jako dostawcę. http://docs.vagrantup.com/v2/docker/ . Zamiast VirtualBox lub VMware można użyć dostawcy Docker.

Pamiętaj, że możesz także użyć Dockera do obsługi Vagrant. To bardzo różni się od używania Dockera jako dostawcy. http://docs.vagrantup.com/v2/provisioning/docker.html

Oznacza to, że możesz zastąpić szefa kuchni lub marionetkę dokerem. Możesz używać kombinacji takich jak Docker jako dostawca (VM) z Chef jako dostawca. Lub możesz użyć VirtualBox jako dostawcy i Docker jako dostawcy.

Korzystanie z obu jest ważną częścią testowania dostarczania aplikacji. Zaczynam dopiero angażować się w Docker i bardzo intensywnie zastanawiam się nad zespołem aplikacji, który ma straszną złożoność w tworzeniu i dostarczaniu oprogramowania. Pomyśl o klasycznej sytuacji Phoenix Project / Continuous Delivery.

Myślenie wygląda mniej więcej tak:

• Weź komponent aplikacji Java / Go i zbuduj go jako kontener (pamiętaj, nie jestem pewien, czy aplikacja powinna zostać wbudowana w kontener, czy zbudowana, a następnie zainstalowana w kontenerze)
• Dostarcz pojemnik do Wirtualnej maszyny wirtualnej.
• Powtórz to dla wszystkich składników aplikacji.
• Iteruj na komponentach, które mają być kodowane.
• Ciągle testuj mechanizm dostarczania do maszyn wirtualnych zarządzanych przez Vagrant
• Śpij dobrze wiedząc, kiedy nadszedł czas na wdrożenie kontenera, że ​​testy integracyjne odbywały się o wiele bardziej nieprzerwanie niż przed Dockerem.

Wydaje się to logicznym rozszerzeniem stwierdzenia Mitchella, że ​​Vagrant jest przeznaczony do rozwoju w połączeniu z myśleniem Farleya / Humblesa w Continuous Delivery. Jeśli jako deweloper mogę zmniejszyć pętlę sprzężenia zwrotnego na temat testów integracji i dostarczania aplikacji, nastąpi poprawa jakości i lepszych środowisk pracy.

Fakt, że jako programista stale i konsekwentnie dostarczam kontenery do maszyny wirtualnej i bardziej całościowo testuję aplikację, oznacza, że ​​wydania produkcyjne zostaną jeszcze bardziej uproszczone.

Widzę więc, że Vagrant ewoluuje jako sposób na wykorzystanie niektórych niesamowitych konsekwencji, jakie Docker będzie miał dla wdrożenia aplikacji.

Zdecydowanie Docker na zwycięstwo!

Jak zapewne wiesz, Vagrant służy do zarządzania maszynami wirtualnymi, natomiast Docker do zarządzania kontenerami oprogramowania. Jeśli nie zdajesz sobie sprawy z różnicy, oto: Kontener oprogramowania może współdzielić tę samą maszynę i jądro z innymi kontenerami oprogramowania. Używając kontenerów oszczędzasz pieniądze, ponieważ nie marnujesz zasobów na wiele systemów operacyjnych (jądra), możesz spakować więcej oprogramowania na serwer, zachowując dobry stopień izolacji.

Oczywiście jest to nowa dyscyplina, w której trzeba dbać o własne pułapki i wyzwania.

Wybierz Docker Swarm, jeśli twoje wymagania przekroczą limit zasobów pojedynczej maszyny.

W magazynie Oracle Java znajduje się bardzo pouczający artykuł na temat używania Dockera w połączeniu z Vagrant (i Puppet):

Wniosek

Lekkie kontenery Dockera są szybsze w porównaniu z klasycznymi maszynami wirtualnymi i stały się popularne wśród programistów oraz w ramach inicjatyw CD i DevOps. Jeśli Twoim celem jest izolacja, Docker jest doskonałym wyborem. Vagrant to menedżer maszyn wirtualnych, który umożliwia tworzenie skryptów konfiguracji poszczególnych maszyn wirtualnych, a także przeprowadzanie obsługi administracyjnej. Jest to jednak maszyna wirtualna zależna od VirtualBox (lub innego menedżera VM) ze stosunkowo dużym obciążeniem. Wymaga to bezczynności dysku twardego, która może być ogromna, zajmuje dużo pamięci RAM, a wydajność może być nieoptymalna. Docker używa grup grup jądra i izolacji przestrzeni nazw przez LXC. Oznacza to, że używasz tego samego jądra co host i tego samego systemu Ile. Vagrant jest poziomem powyżej Dockera pod względem abstrakcji, więc nie są tak naprawdę porównywalne. Narzędzia do zarządzania konfiguracją, takie jak Puppet, są szeroko stosowane do udostępniania środowisk docelowych. Ponowne wykorzystanie istniejących rozwiązań opartych na marionetkach jest łatwe dzięki Docker. Możesz także podzielić swoje rozwiązanie, aby infrastruktura została zaopatrzona w Puppet; oprogramowanie pośrednie, sama aplikacja biznesowa lub oba są dostarczane z Docker; a Docker jest owinięty przez Vagrant. Dzięki tej gamie narzędzi możesz robić to, co najlepsze w twoim scenariuszu.

Jak budować, używać i koordynować kontenery Docker w DevOps http://www.javamagazine.mozaicreader.com/JulyAug2015#&pageSet=34&page=0