Pytanie Czy należy używać programu Vagrant lub Docker do tworzenia izolowanego środowiska? [Zamknięte]


Używam Ubuntu do programowania i wdrażania i potrzebuję stworzenia izolowanego środowiska.

W tym celu rozważam Vagrant lub Docker. Jakie są plusy i minusy lub jak te rozwiązania się porównują?


1888
2018-05-20 10:05


pochodzenie


Oba można teraz łączyć: docs.vagrantup.com/v2/provisioning/docker.html - Alp
Czy możemy nie usuwaj tego, ludzie? Być może jest to poza tematem i może być Zamknięte, ale z długimi odpowiedziami autorów obu narzędzi (i 90k odsłon), jest to cenne i nie zasługuje na skasowanie. - Jeremy
Twoje pytanie jest na tyle szczęścia, że ​​uzyskają odpowiedzi obu pisarzy na dwie usługi: Mitchella i Solomona Hykesa - itsazzad


Odpowiedzi:


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

Vagrant jest menedżerem maszyny wirtualnej. Pozwala na skryptowanie konfiguracji maszyny wirtualnej, a także obsługi administracyjnej. Wciąż jednak jest to maszyna wirtualna VirtualBox (lub inne) z ogromnym obciążeniem. Wymaga to posiadania twardego dysku, który może być ogromny, wymaga dużej ilości pamięci RAM, a wydajność może nie być zbyt dobra.

Z drugiej strony, Docker wykorzystuje cgrupę jądra i wywoływanie nazw za pośrednictwem 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 build polecenie w celu obsłużenia obsługi i konfiguracji Twojego kontenera. Masz przykład na docs.docker.com o tym, jak zrobić plik Docker; jest bardzo intuicyjny.

Jedynym powodem, dla którego możesz chcieć użyć Vagrant jest, jeśli chcesz zrobić BSD, Windows lub inny rozwój nie-Linuxowy na twoim Ubuntu. W przeciwnym razie przejdź do Docker.


1044
2018-05-26 16:46



Niestety jeszcze nie. Jeśli jesteś w systemie 32-bitowym, będziesz potrzebował maszyny wirtualnej z 64-bitowym systemem gościa, aby uruchomić okno dokowane. Jednak w wersji go1.1 obsługa 32-bitowa jest lepsza i możliwe jest, że docker wkrótce będzie obsługiwał archiwa 32-bitowe - creack
"Mac, Windows i niektóre dystrybucje Linuksa nie mogą natywnie uruchomić Dockera, więc pomagamy skonfigurować maszynę wirtualną Ubuntu i uruchomić Docker w tym". Więc jeśli nie jesteś w głównym nurcie dystrybucji Linuksa, twoja aplikacja uruchomi się wewnątrz okna dokowanego, które samo będzie działać w maszynie wirtualnej. - aleemb
Dotyczy to komputerów Mac i Windows, ale od wersji docker 0.7 każda dystrybucja Linuksa działa dobrze. Jeśli znasz niedziałającą, daj mi znać. Ponadto, jeśli nie masz stosu Mac lub Windows (co jest mało prawdopodobne, ale może się zdarzyć), nie chcesz uruchamiać Dockera w dowolnym miejscu, ale na Linuksie. Klient Docker działa dobrze na Macu, powinien działać niedługo na BSD, a demon w końcu obsłuży BSD, Solaris i Mac. - creack
Na wypadek, gdyby ktoś przeczytał te komentarze, powinieneś wiedzieć, że Docker trafił ver1.0 zaledwie 12 dni temu (blog.docker.com/2014/06/its-here-docker-1-0) i wiele różnych platform jest stabilnych i obsługiwanych teraz (docs.docker.com/installation) - JorgeArtware
vagrant ma LXC i narzędzia dokowania. Jednak - Vagrant i docker są zasadniczo różnymi rzeczami. Vagrant jest przeznaczony wyłącznie dla środowisk programistycznych, doker jest przeznaczony raczej do produkcji i tylko do systemu Linux. - Dannyboy


Disclaimer: 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 i wielu używa Dockera, i widzę, jak te dwie interakcje.

Zanim mówię za dużo, bezpośrednia odpowiedź: w konkretnym scenariuszu (samemu pracującemu samemu, pracującemu na Linuksie, używając Dockera w produkcji), możesz trzymać się samego Dockera i upraszczać rzeczy. W wielu innych scenariuszach (omówię dalej), nie jest to takie łatwe.

Nie jest właściwe, aby bezpośrednio porównać Vagrant z Dockerem. W niektórych scenariuszach nakładają się one na siebie, a w ogromnej większości nie. W rzeczywistości, bardziej trafnym porównaniem będzie Vagrant kontra coś takiego jak Boot2Docker (minimalny system operacyjny, w którym można uruchomić Docker). Vagrant to poziom wyższy niż Docker pod względem abstrakcji, więc w większości przypadków nie jest to uczciwe porównanie.

Vagrant uruchamia narzędzia do uruchamiania aplikacji / usług w celu ich rozwoju. Może to być na VirtualBox, VMware. Może być zdalny jak AWS, OpenStack. Wewnątrz tych, jeśli używasz kontenerów, Vagrant nie dba o to, i obejmuje to: może automatycznie instalować, ściągać, budować i uruchamiać kontenery Docker, na przykład. Z Vagrantem 1.6, Vagrant ma środowiska programistyczne oparte na dockui obsługuje używanie Docker z tym samym przepływem pracy, co Vagrant w systemach Linux, Mac i Windows. Vagrant nie próbuje tutaj zastąpić Dockera, obejmuje praktyki Docker.

Docker specjalnie uruchamia kontenery Docker. Jeśli porównujesz bezpośrednio do Vagrant: jest to bardziej specyficzne (można uruchamiać tylko kontenery Docker), mniej elastyczne (wymaga rozwiązania Linux gdzieś na hoście). Oczywiście jeśli mówisz o produkcji lub CI, nie ma porównania do Vagrant! Vagrant nie żyje w tych środowiskach i dlatego należy używać Dockera.

Jeśli Twoja organizacja uruchamia tylko kontenery Docker dla wszystkich swoich projektów i ma tylko programistów działających na Linuksie, to w porządku, Docker na pewno może dla ciebie pracować!

W przeciwnym razie nie widzę korzyści z próby użycia samego Dockera, ponieważ tracisz dużo tego, co Vagrant ma do zaoferowania, co ma realne korzyści biznesowe / wydajnościowe:

  • Vagrant może uruchamiać maszyny VirtualBox, VMware, AWS, OpenStack itp. Nie ma znaczenia, czego potrzebujesz, Vagrant może go uruchomić. Jeśli używasz Docker, 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ą nauczyć się obsługiwać projekt, niezależnie od tego, czy znajduje się on w pojemniku Docker, czy nie. Jeśli, na przykład, w przyszłości pojawi się konkurent, który będzie konkurować bezpośrednio z Dockerem, Vagrant będzie mógł to również uruchomić.

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

  • Vagrant wie, jak skonfigurować zaawansowane lub nietrywialne funkcje, takie jak tworzenie sieci i synchronizowanie folderów. Na przykład: Vagrant wie, jak podłączyć statyczny adres IP do komputera lub przekazać porty, a konfiguracja jest taka sama, bez względu na używany system (VirtualBox, VMware itp.). W przypadku synchronizowanych folderów Vagrant udostępnia wiele mechanizmów do uzyskania lokalnych pliki do zdalnego komputera (VirtualBox udostępnione foldery, NFS, rsync, Samba [plugin], itp.). Jeśli używasz Docker, nawet Docker z VM bez Vagrant, musiałbyś to zrobić ręcznie lub musiałby w tym przypadku ponownie odkryć Vagrant.

  • Vagrant 1.6 ma pierwszorzędne wsparcie dla środowiska programistyczne oparte na docku. To nie uruchomi maszyny wirtualnej w systemie Linux i automatycznie uruchomi maszynę wirtualną na Macu i Windows. Rezultatem jest to, że praca z Dockerem jest jednolita na wszystkich platformach, podczas gdy Vagrant nadal radzi sobie z nudnymi szczegółami takimi jak sieci, synchronizowane foldery itp.

Aby odnieść się do konkretnych argumentów przeciwnych, które słyszałem o korzystaniu z Dockera zamiast Vagrant:

  • "To mniej ruchomych części" - Tak, może tak być, jeśli używasz Dockera wyłącznie do każdego projektu. Nawet wtedy rezygnuje z elastyczności blokady Dockera. Jeśli kiedykolwiek zdecydujesz się nie używać Dockera do żadnego projektu, przeszłego, teraźniejszego lub przyszłego, będziesz miał więcej ruchomych części. Jeśli używałeś Vagrant, masz jedną ruchomą część, która wspiera resztę.

  • "To jest szybsze!" - Gdy masz hosta, który może uruchamiać kontenery Linux, Docker zdecydowanie szybciej uruchamia kontener niż jakakolwiek maszyna wirtualna. Ale uruchomienie maszyny wirtualnej (lub maszyny zdalnej) jest jednorazowym kosztem. W ciągu dnia większość użytkowników Vagrant nigdy nie niszczy swojej maszyny wirtualnej. To dziwna optymalizacja dla środowisk programistycznych. W produkcji, gdzie Docker naprawdę świeci, rozumiem potrzebę szybkiego obracania pojemników.

Mam nadzieję, że teraz jest jasne, że bardzo trudno jest porównać Dockera z włóczęgą. W środowiskach deweloperów Vagrant jest bardziej abstrakcyjny, bardziej ogólny. Docker (i różne sposoby, w jakie możesz sprawić, że zachowuje się jak włóczęga) jest specyficznym przypadkiem użycia Vagrant, ignorując wszystko, co Vagrant ma do zaoferowania.

Podsumowując: w bardzo konkretnych przypadkach użycia, Docker jest z pewnością możliwym zamiennikiem Vagrant. W większości przypadków nie jest. Vagrant nie utrudnia korzystania z Docker; faktycznie robi to, co może, aby to doświadczenie było bardziej płynne. Jeśli okaże się, że to nieprawda, z przyjemnością przyjmuję sugestie, aby poprawić sytuację, ponieważ celem Vagrant jest równe działanie z każdym systemem.

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


2173
2018-01-23 16:55



@JaredMarkell Myślę, że może szuka usługi internetowej, która pozwala mu zarządzać maszynami Vagrant, takimi jak Protobox. - Ryan Kennedy
@Mitchell Chciałem tylko podziękować za tak szczegółowe wyjaśnienie. Oczywiście niemożliwe jest, abyś był całkowicie obiektywny, dlatego doceniam, że poświęciłeś czas na wyjaśnienie niuansów i różnych sytuacji, w których można je wykorzystać. Myślę, że wiele zamieszania wokół wielu dzisiejszych narzędzi polega na tym, że nakładają się one bardzo często, a wiele osób chce uniwersalnego rozwiązania, w którym ktoś po prostu mówi im, co ma robić, i może je wdrożyć. Piękno twojej odpowiedzi jest takie, że odpowiada na podstawowe pytanie: jak stworzyć izolowane środowisko? (niezależnie od narzędzi). - Jordan
@JaredMarkell Docker ma interfejs REST API docs.docker.com/reference/api/docker_remote_api - Tarnay Kálmán
@ OğuzÇelikdemir Vagrant może zrobić znacznie więcej. Oczywiście, jeśli przygotujesz konkretną maszynę wirtualną dla każdego projektu, będzie to trwało. Ale w trakcie rozwoju często kończę na dodawaniu kolejnych usług / demonów / ustawień (np. Kiedy decyduję się używać RabbitMQ do projektu podczas tworzenia). Podejście czysto VM będzie wymagało przygotowania nowego obrazu z zainstalowanym i skonfigurowanym RabbitMQ i zmuszenia programistów do zmiany ich VM na nową. Dla Vagrant - dodaję odpowiednie linie w konfrontacji włóczęgów i wszyscy programiści mogą łatwo uaktualnić swoje maszyny wirtualne (używając vagrant provision). - Tomasz Struczyński
(Masz na myśli "ujawnienie", ujawniając coś ważnego, a nie "zrzeczenie się", odmawiając odpowiedzialności: english.stackexchange.com/q/115850) - Jerry101


Jestem autorem Dockera.

Krótka odpowiedź brzmi, że 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 wirtualnymi maszynami. Docker to narzędzie do budowania i wdrażania aplikacji poprzez pakowanie ich do lekkich pojemników. Kontener może pomieścić prawie każdy składnik oprogramowania wraz z jego zależnościami (pliki wykonywalne, biblioteki, pliki konfiguracyjne itp.) I wykonywać go w gwarantowanym i powtarzalnym środowisku uruchomieniowym. Dzięki temu można bardzo łatwo zbudować aplikację i wdrożyć ją w dowolnym miejscu - na laptopie do testowania, a następnie na różnych serwerach do wdrożenia na żywo itp.

Powszechnie uważa się, że Docker można używać tylko w systemie Linux. To jest nieprawidłowe; możesz także zainstalować Docker na Macu, a obsługa Windows jest w toku. Po zainstalowaniu na komputerze Mac, Docker łączy niewielką maszynę VM Linux (25 MB na dysku!), Która działa jak opakowanie dla twojego kontenera. Po zainstalowaniu jest to całkowicie przezroczyste; możesz użyć wiersza poleceń Docker dokładnie w ten sam sposób. Daje to najlepsze z obu światów: możesz testować i rozwijać swoją aplikację za pomocą pojemników, które są bardzo lekkie, łatwe do przetestowania i łatwe w przemieszczaniu (patrz na przykład https://hub.docker.com do dzielenia pojemników wielokrotnego użytku ze społecznością Docker) i nie musisz się martwić o drobiazgowe szczegóły zarządzania maszynami wirtualnymi, które i tak są jedynie środkiem do zakończenia.

Teoretycznie możliwe jest użycie Vagrant jako warstwy abstrakcji dla Docker. Polecam przeciw temu z dwóch powodów:

  • Po pierwsze, Vagrant nie jest dobrą abstrakcją dla Dockera. Vagrant został zaprojektowany do zarządzania wirtualnymi maszynami. Docker został zaprojektowany do zarządzania czasem uruchamiania aplikacji. Oznacza to, że z założenia Docker może współdziałać z aplikacją w znacznie bogatszy sposób i ma więcej informacji na temat środowiska wykonawczego aplikacji. Prymitywy w Dockerze to procesy, strumienie dziennika, zmienne środowiskowe i połączenia sieciowe między komponentami. Prymitywy w Vagrant to maszyny, urządzenia blokowe i klucze ssh. Włóczęga po prostu siedzi niżej w stosie, a jedynym sposobem, w jaki może wchodzić w interakcję z pojemnikiem, jest udawanie, że jest to po prostu inny rodzaj maszyny, którą można "uruchomić" i "zalogować się". Na pewno możesz wpisać "vagrant up" za pomocą wtyczki Docker i stanie się coś ładnego. Czy jest substytutem pełnego zakresu tego, co potrafi Docker? Wypróbuj rodzimy Docker na kilka dni i przekonaj się sam :)

  • Po drugie, argument blokady. "Jeśli użyjesz Vagrant jako abstrakcji, nie zostaniesz zablokowany w Dockerze!". Z punktu widzenia Vagrant, który jest przeznaczony do zarządzania maszynami, ma to sens: czy pojemniki nie są tylko innym rodzajem maszyny? Podobnie jak Amazon EC2 i VMware, musimy uważać, aby nie powiązać naszych narzędzi do obsługi z konkretnym dostawcą! To utworzyłoby blokadę - lepiej byłoby ją rozdzielić z Vagrantem. Tyle tylko, że całkowicie pomija punkt Dockera. Docker nie udostępnia maszyn; otacza aplikację w lekkim przenośnym środowisku uruchomieniowym, które można upuścić w dowolnym miejscu.

To, który program wybierzesz dla swojej aplikacji, nie ma nic wspólnego z tym, jak zapewniasz swoje urządzenia! Na przykład dość często wdraża się aplikacje na komputerach obsługiwanych przez kogoś innego (na przykład instancję EC2 wdrożoną przez administratora systemu, np. Przy użyciu Vagrant) lub na maszyny wirtualne, których Vagrant w ogóle nie może zapewnić. I odwrotnie, możesz użyć Vagrant do dostarczania maszyn, które nie mają nic wspólnego z tworzeniem twojej aplikacji - na przykład gotowego do użycia pudełka Windows IIS lub czegoś podobnego. Lub możesz użyć Vagrant do dostarczania maszyn dla projektów, które nie używają Dockera - może używają kombinacji rubygemów i rvm do zarządzania zależnościami i piaskownicami na przykład.

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


1282
2018-03-13 06:16



Chciałem tylko zauważyć, że aspekty Vagrant tej odpowiedzi są nieprawidłowe. Vagrant nie jest przeznaczony do zarządzania maszynami, Vagrant służy do zarządzania środowiskami programistycznymi. Fakt, że Vagrant obraca maszyny, jest w większości historyczny. Następna wersja Vagrant ma wsparcie pierwszej klasy, aby uruchomić środowisko dev przy użyciu Docker jako dostawca bezpośrednio na hoście lub dowolnej maszynie wirtualnej (Mac, Win). Może także rozprowadzić surowe LXC, jeśli tego chce ktoś (znowu, na hoście lub maszynie wirtualnej). Vagrant jest zainteresowany zrobieniem tego, co jest najlepsze, aby stworzyć przenośne środowisko programistyczne, bez względu na to, czy oznacza to tworzenie VM, czy nie. - Mitchell
@Mitchell - czy możesz wskazać kilka dokumentów o betach, które zawierają więcej informacji na temat tego stwierdzenia? Bardzo mnie to interesuje. - Davide
"Powszechnym błędem jest to, że możesz używać Dockera tylko w Linuksie". Prawdą jest, że można używać Linuksa tylko w Dockerze. Jeśli chcę skonfigurować testera, który będzie wykonywał moją aplikację w różnych konfiguracjach środowiska (różne bazy danych, wersje PHP, buforowanie baz danych itp.), To z łatwością mogę to zrobić za pomocą kontenerów dokerów. Ale nie mogę zobaczyć, czy moja aplikacja będzie działała poprawnie w środowisku Windows IIS, lub w BSD lub OSX. - Mixologic
Twój pierwszy punkt jest nieaktualny, ponieważ Vagrant ma wbudowaną obsługę dostawcy dla docker: docs.vagrantup.com/v2/provisioning/docker.html - Alp
Post jest nieaktualny. Vagrant wspiera teraz Dockera jako dostawcę. Są też filmy wideo pokazujące, jak możesz używać Vagrant i Docker zgodnie z ich wersją blog. - sargas


Napisałem swoją odpowiedź, przyznając, że nie mam doświadczenia z Dockerem, poza tym, że jest zagorzałym obserwatorem tego, co wygląda na naprawdę schludne rozwiązanie, które zyskuje dużo trakcji.

Mam sporą ilość doświadczenia z Vagrantem i mogę go bardzo polecić. Z pewnością jest to rozwiązanie o większej wadze, ponieważ bazuje na VM zamiast LXC. Jednak znalazłem przyzwoitego laptopa (8 GB RAM, procesor i5 / i7) nie ma problemu z uruchomieniem maszyny wirtualnej przy użyciu Vagrant / VirtualBox wraz z narzędziami programistycznymi.

Jedną z naprawdę świetnych rzeczy w Vagrant jest integracja z Marionetka/Szef kuchni/ Skrypty powłoki do zautomatyzowania konfiguracji. Jeśli używasz jednej z tych opcji do skonfigurowania środowiska produkcyjnego, możesz utworzyć środowisko programistyczne, które jest identyczne z każdym, jakie chcesz uzyskać, i to jest dokładnie to, czego potrzebujesz.

Inną wspaniałą rzeczą w Vagrant jest to, że możesz wyposażyć swój Vagrantfile razem z kodem aplikacji. Oznacza to, że wszyscy członkowie Twojego zespołu mogą udostępniać ten plik i masz gwarancję, że wszyscy pracują w tej samej konfiguracji środowiska.

Co ciekawe, Vagrant i Docker mogą rzeczywiście być bezpłatne. Program Vagrant można rozszerzyć, aby obsługiwać różnych dostawców wirtualizacji. Być może Docker jest jednym z takich dostawców, który uzyska wsparcie w najbliższej przyszłości. Widzieć https://github.com/dotcloud/docker/issues/404 do niedawnej dyskusji na ten temat.


73
2018-06-25 21:33



Chłopaki, wypuściłem eksperymentalny dostawca vagrant dla docker: github.com/fgrehm/docker-provider. - fgrehm
Docker nie jest wirtualizacją, ale uruchamia system operacyjny w swoim własnym kontenerze, używając tego samego jądra hosta, którego nie jest dostawcą, tak jak inne maszyny wirtualne, więc dokowanie jest już obsługiwane przez Vagrant. - Aftab Naveed
Docker to wirtualizacja samego systemu operacyjnego, polegająca na niejawnym ponownym wykorzystaniu podstawowego sprzętu. Jest wirtualizacją, ponieważ zawiera i izoluje system plików, sieci i procesy działające w kontenerze. - jose.angel.jimenez


Są bardzo komplementarne.

Przez kilka miesięcy używałem kombinacji VirtualBox, Vagrant i Docker do wszystkich moich projektów i odczuwałem następujące korzyści.

W Vagrant można całkowicie zrezygnować z samodzielnego zaopatrywania szefa kuchni i wszystko, czego potrzebujesz, to zrobić plik vagranta, aby przygotować maszynę, która uruchamia jeden mały skrypt powłoki, który instaluje docker. Oznacza to, że moje pliki Vagrant dla każdego projektu są niemal identyczne i bardzo proste.

Oto typowy 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 potrzebne usługi, mam skrypt docker_start, który wygląda w ten sposób

#!/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 non-dockera byłaby znacznie bardziej skomplikowana.

Ostatnim dużym plusem jest to, że przechodzisz do produkcji, tłumacząc środowisko programistyczne na infrastrukturę hostów, które są takie same, ponieważ mają wystarczającą konfigurację, aby uruchomić dokowanie, oznacza bardzo mało pracy.

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

Implementacja środowiska programistycznego Vagrant / Docker


52
2017-08-20 20:42



Zrobiłeś całą tą docked_start orchestration, ale nie zawracałeś sobie głowy łączeniem kontenerów. Czy po prostu używasz zakodowanych numerów portów, ponieważ używasz go w Vagrant? - WineSoaked
Cześć WineSoaked, powyższy przykład nie pokazuje kontenera, który faktycznie używa wszystkich tych usług. Jeśli spojrzysz na wspomniany wpis na blogu, pojawi się inny skrypt skryptowy / vagrant / docker_web, który uruchamia kontener projektu. To rzeczywiście używa polecenia --link w poleceniu uruchomienia dockera, a projekt Rails wykorzystuje zmienne środowiskowe wstrzykiwanego środowiska do podłączania się do usług. - Mark Stratmann
Widzę potencjał łączenia obu produktów. Vagrant jako testowanie środowiska i okno dokowane dla aplikacji. Łącząc oba możesz przetestować pojedynczą aplikację lub test jednostkowy na wielu escenariach. Myślę, że wiele "usług platform testowych" używa Vagrant + Docker na czas. - erm3nda
"Są bardzo bezpłatne." - Oba są rzeczywiście w użyciu. - Underyx
Hi @koppor Ostatnio użyłem maszyny dokuj ącej około trzech miesięcy temu i jeszcze do niej nie wróciłem. Problem polegał na tym, że ma błąd w udostępnianiu folderów z hosta hosta MAC do okna dokowanego do pracy z maszyną wirtualną podczas korzystania ze sterownika VMWare. Oznaczało to, że nie mogłem edytować kodu lokalnie na komputerze Mac i mieć zmiany odzwierciedlone w kontenerze dokowania. Nie wiem, czy już to naprawili, a kiedy to zrobią, naprawdę to zmienię. Jednak od napisania tej odpowiedzi zmieniłem całą moją orkiestrację kontenerową na dokowanie - Mark Stratmann


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


48
2017-08-01 18:44



I tutaj jest bezpośredni link do projektu github.com/fgrehm/vagrant-lxc - gertas


Dzięki Vagrant możesz teraz mieć Dockera jako dostawcę. http://docs.vagrantup.com/v2/docker/. Dostawcy Docker mogą być używane zamiast VirtualBox lub VMware.

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 wymienić Szef kuchni lub Marionetka z Dockerem. Możesz użyć kombinacji takich jak Docker jako dostawca (VM) z Chef jako komponentem. Lub możesz użyć VirtualBox jako dostawca i Docker jako komponent.


41
2018-05-30 16:10



świat po prostu oszalał;) możemy uruchomić włóczęgę za pomocą dostawcy dokera, aby uruchomić pojemniki dokerów wewnątrz włóczęgi - Hoto
@Zainengineer, czy dostawca Docker dla Vagrant na Windows nadal używa boot2docker, czy używa jakiegoś wariantu Docker Toolbox? - Derek Mahar
@Zainengineer Czy masz kilka linków do przykładowych przykładów (a nie vagrantów)? - Tset Noitamotua


Używanie obu jest ważną częścią testowania dostarczania aplikacji. Zaczynam dopiero angażować się w Docker i bardzo mocno zastanawiam się nad zespołem aplikacji, który ma ogromną złożoność w budowaniu i dostarczaniu swojego oprogramowania. Pomyśl o klasycznej sytuacji w projekcie Phoenix / ciągłej dostawie.

Myślenie przebiega mniej więcej tak:

  • Zrób komponent aplikacji Java / Go i zbuduj go jako kontener (uwaga, nie jestem pewien, czy aplikacja powinna być wbudowana w kontener, czy też zbudowana zainstalowane do kontenera)
  • Dostarcz kontener do maszyny wirtualnej Vagrant.
  • Powtórz to dla wszystkich składników aplikacji.
  • Iteruj na komponencie (ach), aby kodować.
  • Stale testuj mechanizm dostarczania do VM zarządzanych przez Vagrant
  • Śpij dobrze wiedząc, kiedy nadszedł czas wdrożenia pojemnika, że ​​testowanie integracyjne odbywało się w dużo bardziej ciągły sposób niż przed Dockerem.

Wydaje się, że jest to logiczne rozwinięcie stwierdzenia Mitchella, że ​​Vagrant jest przeznaczony na rozwój w połączeniu z Farley / Humbles myślącymi w Continuous Delivery. Jeśli ja, jako programista, mogę zmniejszyć pętlę sprzężenia zwrotnego w testach integracyjnych i dostarczaniu aplikacji, nastąpi lepsza jakość i lepsze środowisko pracy.

Fakt, że jako deweloper nieustannie i konsekwentnie dostarczam pojemniki do maszyny wirtualnej i testuję aplikację bardziej holistycznie oznacza, że ​​premiery produkcyjne będą jeszcze bardziej uproszczone.

Widzę więc, że Vagrant rozwija się, aby wykorzystać niektóre z niesamowitych konsekwencji, jakie Docker będzie miał dla wdrożenia aplikacji.


11
2018-06-20 00:56



Czy przypadkiem masz wpis na blogu na ten temat? już prawie dwa lata, jak idzie? nadal używasz vagrant z docker lub po prostu docker i docker-fleat / machine? - Hoto
Firma, dla której pracowałem, została przejęta i usunęła całą moją zawartość @Hoto. Krótka odpowiedź brzmi: używam maszyny do dokowania w domu do moich domowych projektów. W pracy jestem <gulp> managerem </ gulp> i nie robię zbyt wielu technik. Nie mamy planów używania Dockera, więc nasze narzędzie jest generalnie Vagrant. - Boyd Hemphill


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

Wniosek

Lekkie pojemniki Docker są szybsze w porównaniu z klasycznymi maszynami wirtualnymi   i stały się popularne wśród programistów oraz jako część CD i DevOps   inicjatywy. Jeśli twoim celem jest izolacja, Docker to doskonały wybór.   Vagrant to menedżer VM, który umożliwia konfigurowanie skryptów   poszczególne maszyny wirtualne, a także tworzenie rezerw. Jednak jest to parapet   VM zależna od VirtualBox (lub innego menedżera VM) ze względną   duży nadmiar. Wymaga, aby dysk twardy był bezczynny   ogromne, zajmuje dużo pamięci RAM, a wydajność może być suboptymalna. Doker   wykorzystuje cgrupy jądra i izolację przestrzeni nazw za pośrednictwem LXC. To znaczy że   używasz tego samego jądra co host i ten sam system ile.   Vagrant to poziom wyższy niż Docker pod względem abstrakcji, więc są   nie do końca porównywalne. Narzędzia do zarządzania konfiguracją, takie jak Puppet   szeroko stosowane do obsługi środowisk docelowych. Ponowne użycie istniejącego   Rozwiązania oparte na lalkach są łatwe dzięki Docker. Możesz również pokroić   rozwiązanie, więc infrastruktura jest zaopatrzona w Puppet;   oprogramowanie pośrednie, sama aplikacja biznesowa lub obie te aplikacje są obsługiwane   z Dockerem; a Docker jest opakowany przez Vagrant. Z tym zakresem   narzędzia, możesz zrobić to, co najlepsze dla swojego scenariusza.

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


5
2017-08-20 13:04



Jeśli nie chcesz wypełniać głupich i długich formularzy, a masz urządzenie z systemem iOS, pobierz aplikację i problem za pomocą zaledwie kilku kliknięć: itunes.apple.com/app/java-magazine/id530494326?mt=8 - Rafael Bugajewski
Tyle brakowało - Paul Verest


Zdecydowanie Docker za wygraną!

Jak być może wiesz, Vagrant służy do zarządzania maszyną wirtualną, podczas gdy Docker służy do zarządzania kontenerami oprogramowania. Jeśli nie jesteś świadomy różnicy, oto: Kontener oprogramowania może współdzielić ten sam komputer i jądro z innymi kontenerami oprogramowania. Korzystając z 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, utrzymując dobry poziom izolacji.

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

Przejdź do Docker Swarm, jeśli Twoje wymagania przekroczą limit pojedynczych zasobów maszyny.


5
2018-03-24 14:40