Вопрос: Должен ли я использовать Vagrant или Docker для создания изолированной среды? [закрыто]


Я использую Ubuntu для разработки и развертывания и нуждаюсь в создании изолированной среды.

Для этой цели я рассматриваю либо Бродягу, либо Докер. Каковы плюсы и минусы, или как эти решения сравниваются?


1870


источник


Ответы:


Если ваша цель - изоляция, я думаю, что Docker - это то, что вы хотите.

Вагрант - менеджер виртуальной машины. Он позволяет вам сценариев конфигурации виртуальной машины, а также обеспечения. Тем не менее, это по-прежнему виртуальная машина в зависимости от VirtualBox (или другие) с огромными накладными расходами. Это требует, чтобы у вас был жесткий диск, который может быть огромным, он занимает много бара, а производительность может быть не очень хорошей.

С другой стороны, Docker использует группу cgroup и namespacing через LXC , Это означает, что вы используете то же ядро, что и хост и одна и та же файловая система. Вы можете использовать Dockerfile с docker buildчтобы обрабатывать подготовку и настройку вашего контейнера. У вас есть пример на docs.docker.com о том, как сделать свой Dockerfile; это очень интуитивно.

Единственная причина, по которой вы можете использовать Vagrant, - это то, что вам нужно сделать BSD, Windows или другую разработку, отличную от Linux, в вашем поле Ubuntu. В противном случае идите к Докеру.


1030



Отказ от ответственности: я написал Vagrant! Но поскольку я написал Vagrant, большую часть своего времени я провожу в мире DevOps, который включает в себя программное обеспечение, такое как Docker. Я работаю с большим количеством компаний, использующих Vagrant, и многие используют Docker, и я вижу, как эти два взаимодействия.

Прежде чем говорить слишком много, прямой ответ: в вашем конкретном сценарии (самостоятельно работая в Linux, используя Docker в производстве), вы можете придерживаться только Docker и упрощать вещи. Во многих других сценариях (я обсуждаю далее) это не так просто.

Неправильно напрямую сравнивать Vagrant с Docker. В некоторых сценариях они накладываются друг на друга, и в подавляющем большинстве они этого не делают. Фактически, более подходящим сравнением будет Vagrant по сравнению с чем-то вроде Boot2Docker (минимальная ОС, которая может запускать Docker). Бродяга - это уровень выше Докера с точки зрения абстракций, поэтому в большинстве случаев это не справедливое сравнение.

Vagrant запускает вещи для запуска приложений / сервисов с целью разработки. Это может быть на VirtualBox, VMware. Он может быть удален как AWS, OpenStack. Внутри них, если вы используете контейнеры, Vagrant не заботится и обнимает это: он может автоматически устанавливать, вытаскивать, строить и запускать контейнеры Docker, например. С Vagrant 1.6, Vagrant имеет среды разработки на уровне докеров , и поддерживает использование Docker с тем же рабочим процессом, что и Vagrant в Linux, Mac и Windows. Вагрант не пытается заменить Докера здесь, он охватывает практику Докера.

Docker специально запускает контейнеры Docker. Если вы сравниваете напрямую с Vagrant: это конкретнее конкретнее (могут работать только контейнеры Docker), менее гибкие (требуется где-то Linux или Linux-хост). Конечно, если вы говорите о производстве или CI, нет никакого сравнения с Vagrant! Бродяга не живет в этих условиях, поэтому Docker следует использовать.

Если ваша организация использует только контейнеры Docker для всех своих проектов, и только разработчики работают на Linux, тогда все в порядке, Docker может определенно работать на вас!

В противном случае я не вижу смысла пытаться использовать Docker в одиночку, поскольку вы теряете много того, что может предложить Vagrant, которые имеют реальные преимущества для бизнеса / производительности:

  • Vagrant может запускать машины VirtualBox, VMware, AWS, OpenStack и т. Д. Неважно, что вам нужно, Бродяга может запустить его. Если вы используете Docker, Vagrant может установить Docker на любом из них, чтобы вы могли использовать их для этой цели.

  • Vagrant - это единый рабочий процесс для всех ваших проектов. Или, по-другому, люди должны научиться запускать проект, будь то в контейнере Docker или нет. Если, например, в будущем, конкурент должен конкурировать непосредственно с Docker, Vagrant также сможет запустить это.

  • Vagrant работает в Windows (обратно в XP), Mac (обратно до 10.5) и Linux (обратно в ядро ​​2.6). Во всех трех случаях рабочий процесс одинаков. Если вы используете Docker, Vagrant может запустить машину (VM или remote), которая может запускать Docker во всех трех этих системах.

  • Вагрант знает, как настроить некоторые продвинутые или нетривиальные вещи, такие как создание сетей и синхронизация папок. Например: Вагрант знает, как подключить статический IP-адрес к машинным или пересылаемым портам, и конфигурация одинакова независимо от того, какую систему вы используете (VirtualBox, VMware и т. Д.). Для синхронизированных папок Vagrant предоставляет несколько механизмов для получения вашего локального файлы на удаленный компьютер (общие папки VirtualBox, NFS, rsync, Samba [плагин] и т. д.). Если вы используете Docker, даже Docker с виртуальной машиной без бродяг, вам придется вручную это сделать, или в этом случае им придется изобретать Vagrant.

  • Vagrant 1.6 имеет первоклассную поддержку для среды разработки на уровне докеров , Это не приведет к запуску виртуальной машины в Linux и автоматически запустит виртуальную машину на Mac и Windows. Конечным результатом является то, что работа с Docker одинакова на всех платформах, а Vagrant по-прежнему обрабатывает утомительные детали таких вещей, как создание сетей, синхронизированные папки и т. Д.

Чтобы обратиться к конкретным аргументам счетчика, которые я слышал в пользу использования Docker вместо Vagrant:

  • «Это менее подвижные части». Да, это может быть, если вы используете Docker исключительно для каждого проекта. Даже тогда это приносит в жертву гибкость для блокировки Docker. Если вы когда-либо решили не использовать Docker для любого проекта, прошлого, настоящего или будущего, тогда у вас будет больше движущихся частей. Если вы использовали Vagrant, у вас есть одна движущаяся часть, которая поддерживает остальных.

  • «Это быстрее!» - После того, как у вас есть хост, который может запускать контейнеры Linux, Docker определенно быстрее работает с контейнером, чем будет запускаться любая виртуальная машина. Но запуск виртуальной машины (или удаленной машины) - это разовая стоимость. В течение дня большинство пользователей Vagrant никогда не уничтожают виртуальную машину. Это странная оптимизация для сред разработки. В производстве, где Docker действительно сияет, я понимаю, что нужно быстро разворачивать вверх / вниз контейнеры.

Надеюсь, теперь ясно, что это очень сложно, и я считаю неверным сравнивать Docker с Vagrant. Для срединных сред бродяга более абстрактная, более общая. Докер (и различные способы, которыми вы можете заставить его вести себя как бродяга) - это конкретный случай использования Vagrant, игнорируя все, что может предложить Vagrant.

В заключение: в особо конкретных случаях использования Docker, безусловно, является возможной заменой Vagrant. В большинстве случаев использования это не так. Vagrant не мешает вам использовать Docker; он действительно делает то, что может сделать этот процесс более плавным. Если вы обнаружите, что это неверно, я рад принять предложения по улучшению ситуации, поскольку цель Vagrant - работать одинаково хорошо с любой системой.

Надеюсь, это очистит все!


2154



Я автор Докера.

Короткий ответ: если вы хотите управлять машинами, вы должны использовать Vagrant. И если вы хотите создавать и запускать среды приложений, вы должны использовать Docker.

Vagrant - это инструмент для управления виртуальными машинами. Docker - это инструмент для создания и развертывания приложений путем их упаковки в легкие контейнеры. Контейнер может содержать практически любой программный компонент вместе с его зависимостями (исполняемые файлы, библиотеки, файлы конфигурации и т. Д.) И выполнять его в гарантированной и повторяемой среде выполнения. Это упрощает сборку приложения и развертывание в любом месте - на вашем ноутбуке для тестирования, а затем на разных серверах для активного развертывания и т. Д.

Это распространенное заблуждение, что вы можете использовать Docker только в Linux. Это неверно; вы также можете установить Docker на Mac, а поддержка Windows уже ведется. При установке на Mac Docker объединяет крошечную Linux VM (25 МБ на диске!), Которая действует как оболочка для вашего контейнера. После установки это полностью прозрачно; вы можете использовать командную строку Docker точно так же. Это дает вам лучшее из обоих миров: вы можете тестировать и разрабатывать свое приложение с помощью контейнеров, которые очень легкие, легко тестируются и легко перемещаются (см., Например, https://hub.docker.com для обмена контейнерами многократного использования с сообществом Docker), и вам не нужно беспокоиться о подробных подробностях управления виртуальными машинами, которые в любом случае являются средством достижения цели.

Теоретически можно использовать Vagrant в качестве слоя абстракции для Docker. Я рекомендую против этого по двум причинам:

  • Во-первых, бродяга не является хорошей абстракцией для Докера. Vagrant был разработан для управления виртуальными машинами. Docker был разработан для управления временем выполнения приложений. Это означает, что Docker по своему дизайну может взаимодействовать с приложением более богатыми способами и имеет больше информации о времени выполнения приложения. Примитивами в Docker являются процессы, потоки журналов, переменные среды и сетевые связи между компонентами. Примитивами в Vagrant являются машины, блокирующие устройства и ключи ssh. Бродяга просто сидит ниже в стеке, и единственный способ, которым он может взаимодействовать с контейнером, заключается в том, что он делает вид, что это просто другой тип машины, который вы можете «загружать» и «входить в систему». Итак, конечно, вы можете ввести «бродячий вверх» с плагином Docker и что-то красивое произойдет. Является ли это заменой полной ширины того, что может сделать Докер? Попробуйте родной Docker на пару дней и убедитесь сами :)

  • Во-вторых, аргумент блокировки. «Если вы используете Vagrant как абстракцию, вы не будете заперты в Докер!». С точки зрения Vagrant, который предназначен для управления машинами, это имеет смысл: не являются ли контейнеры только другим видом машины? Так же, как Amazon EC2 и VMware, мы должны быть осторожны, чтобы не привязывать наши инструменты обеспечения к любому конкретному поставщику! Это создаст блокировку - лучше всего отбросить все это с помощью Vagrant. Кроме того, это полностью не соответствует точке Докера. Докер не предоставляет машины; он переносит ваше приложение в легкую портативную версию, которая может быть удалена в любом месте.

Какое время выполнения, которое вы выбираете для своего приложения, не имеет никакого отношения к тому, как вы предоставляете свои машины! Например, довольно часто развертывать приложения на машинах, которые предоставляются кем-то другим (например, экземпляр EC2, развернутый вашим системным администратором, возможно, с использованием Vagrant), или на голые металлические машины, которые Vagrant не может обеспечить вообще. И наоборот, вы можете использовать Vagrant для предоставления машин, которые не имеют никакого отношения к разработке вашего приложения - например, готового к использованию окна IIS для Windows или чего-то еще. Или вы можете использовать Vagrant для предоставления машин для проектов, которые не используют Docker, - возможно, они используют комбинацию rubygems и rvm для управления зависимостями и песочницей, например.

В итоге: Vagrant предназначен для управления машинами, а Docker предназначен для создания и работы приложений.


1270



Я предисловию к моему ответу, признав, что у меня нет опыта работы с Docker, кроме как как жадный наблюдатель того, что выглядит действительно опрятным решением, которое набирает много сил.

У меня есть приличный опыт работы с Vagrant и могу очень рекомендовать его. Это, безусловно, более тяжелое решение с точки зрения того, что он основан на виртуальной машине вместо LXC. Тем не менее, я нашел достойный ноутбук (8 ГБ оперативной памяти, i5 / i7 CPU) без проблем с использованием виртуальной машины с использованием Vagrant / VirtualBox наряду с инструментами разработки.

Одной из замечательных вещей с Vagrant является интеграция с Кукольный / шеф-повар / shell для автоматизации конфигурации. Если вы используете один из этих параметров для настройки рабочей среды, вы можете создать среду разработки, которая будет близка к идентичной, как вы собираетесь получить, и это именно то, что вы хотите.

Другая замечательная вещь с Vagrant заключается в том, что вы можете переименовать свой Vagrantfile вместе со своим кодом приложения. Это означает, что все остальные члены вашей команды могут поделиться этим файлом, и вам гарантировано, что все работают с той же конфигурацией среды.

Интересно, что бродяга и докер могут быть бесплатными. Vagrant может быть расширен для поддержки различных поставщиков виртуализации, и возможно, что Docker является одним из таких поставщиков, который получит поддержку в ближайшем будущем. Видеть https://github.com/dotcloud/docker/issues/404 для недавней дискуссии по этой теме.


72



They are very much complementary.

I have been using a combination of VirtualBox, Vagrant and Docker for all my projects for several months and have strongly felt the following benefits.

In Vagrant you can completely do away with any Chef solo provisioning and all you need your vagrant file to do is prepare a machine that runs a single small shell script that installs docker. This means that my Vagrantfiles for every project are almost identical and very simple.

Here is a typical 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

The Bootstrap file that installs docker looks like this

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

Now to get all the services I need running I have a docker_start script that looks somthing like this

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

In this example I am running MongoDB, Elastisearch, RabbitMQ and Memcached

A non-docker Chef solo configuration would be considerably more complicated.

A final big plus is gained when you are moving into production, translating the development environment over to an infrastructure of hosts that are all the same in that they just have enough config to run docker means very little work indeed.

If you interested I have a more detailed article on the development environment on my own web site at

Implementing A Vagrant / Docker Development Environment


51



Vagrant-lxc is a plugin for Vagrant that let's you use LXC to provision Vagrant. It does not have all the features that the default vagrant VM (VirtualBox) has but it should allow you more flexibility than docker containers. There is a video in the link showing its capabilities that is worth watching.


45



With Vagrant now you can have Docker as a provider. http://docs.vagrantup.com/v2/docker/. Docker provider can be used instead of VirtualBox or VMware.

Please note that you can also use Docker for provisioning with Vagrant. This is very different than using Docker as a provider. http://docs.vagrantup.com/v2/provisioning/docker.html

This means you can replace Chef or Puppet with Docker. You can use combinations like Docker as provider (VM) with Chef as provisioner. Or you can use VirtualBox as provider and Docker as provisioner.


41



Using both is an important part of application delivery testing. I am only beginning to get involved with Docker and thinking very hard about an application team that has terrible complexity in building and delivering its software. Think of a classic Phoenix Project / Continuous Delivery situation.

The thinking goes something like this:

  • Take a Java/Go application component and build it as a container (note, not sure if the app should be built in the container or built then installed to the container)
  • Deliver the container to a Vagrant VM.
  • Repeat this for all application components.
  • Iterate on the component(s) to code against.
  • Continuously test the delivery mechanism to the VM(s) managed by Vagrant
  • Sleep well knowing when it is time to deploy the container, that integration testing was occurring on a much more continuous basis than it was before Docker.

This seems to be the logical extension of Mitchell's statement that Vagrant is for development combined with Farley/Humbles thinking in Continuous Delivery. If I, as a developer, can shrink the feedback loop on integration testing and application delivery, higher quality and better work environments will follow.

The fact that as a developer I am constantly and consistently delivering containers to the VM and testing the application more holistically means that production releases will be further simplified.

So I see Vagrant evolving as a way of leveraging some of the awesome consequences Docker will have for app deployment.


11



There is a really informative article in the actual Oracle Java magazine about using Docker in combination with Vagrant (and Puppet):

Conclusion

Docker’s lightweight containers are faster compared with classic VMs and have become popular among developers and as part of CD and DevOps initiatives. If your purpose is isolation, Docker is an excellent choice. Vagrant is a VM manager that enables you to script configurations of individual VMs as well as do the provisioning. However, it is sill a VM dependent on VirtualBox (or another VM manager) with relatively large overhead. It requires you to have a hard drive idle that can be huge, it takes a lot of RAM, and performance can be suboptimal. Docker uses kernel cgroups and namespace isolation via LXC. This means that you are using the same kernel as the host and the same ile system. Vagrant is a level above Docker in terms of abstraction, so they are not really comparable. Configuration management tools such as Puppet are widely used for provisioning target environments. Reusing existing Puppet-based solutions is easy with Docker. You can also slice your solution, so the infrastructure is provisioned with Puppet; the middleware, the business application itself, or both are provisioned with Docker; and Docker is wrapped by Vagrant. With this range of tools, you can do what’s best for your scenario.

How to build, use and orchestrate Docker containers in DevOps http://www.javamagazine.mozaicreader.com/JulyAug2015#&pageSet=34&page=0


5