Pregunta ¿Debo usar Vagrant o Docker para crear un entorno aislado? [cerrado]


Uso Ubuntu para desarrollo e implementación y necesito crear un entorno aislado.

Estoy considerando Vagrant o Docker para este propósito. ¿Cuáles son los pros y los contras, o cómo se comparan estas soluciones?


1886
2018-05-20 10:05


origen


Respuestas:


Si su propósito es el aislamiento, creo que Docker es lo que quiere.

Vagrant es un administrador de máquina virtual. Le permite guiar la configuración de la máquina virtual, así como el aprovisionamiento. Sin embargo, sigue siendo una máquina virtual que depende de VirtualBox (u otros) con una gran sobrecarga. Requiere que tengas un archivo de disco duro que puede ser enorme, requiere mucho RAM y el rendimiento puede no ser muy bueno.

Docker, por otro lado, usa kernel cgroup y namespacing a través de LXC. Significa que está utilizando el mismo kernel que el host y el mismo sistema de archivos. Puede usar Dockerfile con docker build comando para manejar el aprovisionamiento y la configuración de su contenedor. Tienes un ejemplo en docs.docker.com sobre cómo hacer tu archivo Docker; es muy intuitivo

La única razón por la que podría querer usar Vagrant es si necesita hacer BSD, Windows u otro desarrollo que no sea Linux en su caja Ubuntu. De lo contrario, ve por Docker.


1042
2018-05-26 16:46



Descargo de responsabilidad: ¡escribí Vagrant! Pero como escribí Vagrant, paso la mayor parte de mi tiempo viviendo en el mundo de DevOps, que incluye software como Docker. Trabajo con muchas compañías que usan Vagrant y muchas usan Docker, y veo cómo las dos interactúan.

Antes de hablar demasiado, una respuesta directa: en su escenario específico (usted mismo trabajando solo, trabajando en Linux, usando Docker en producción), puede quedarse solo con Docker y simplificar las cosas. En muchos otros escenarios (lo analizo más adelante), no es tan fácil.

No es correcto comparar directamente Vagrant con Docker. En algunos escenarios, se superponen, y en la gran mayoría, no lo hacen. En realidad, la comparación más adecuada sería Vagrant versus algo como Boot2Docker (sistema operativo mínimo que puede ejecutar Docker). Vagrant está un nivel por encima de Docker en términos de abstracciones, por lo que no es una comparación justa en la mayoría de los casos.

Vagrant lanza cosas para ejecutar aplicaciones / servicios con el propósito de desarrollo. Esto puede ser en VirtualBox, VMware. Puede ser remota como AWS, OpenStack. Dentro de esos, si usa contenedores, a Vagrant no le importa, y lo incluye: puede instalar, desplegar, construir y ejecutar contenedores Docker automáticamente, por ejemplo. Con Vagrant 1.6, Vagrant tiene entornos de desarrollo basados ​​en dockery admite el uso de Docker con el mismo flujo de trabajo que Vagrant en Linux, Mac y Windows. Vagrant no intenta reemplazar a Docker aquí, abarca las prácticas de Docker.

Docker ejecuta específicamente contenedores Docker. Si está comparando directamente con Vagrant: es específicamente una solución más específica (solo puede ejecutar contenedores Docker), menos flexible (requiere un host Linux o Linux en alguna parte). Por supuesto, si estás hablando de producción o CI, ¡no hay comparación con Vagrant! Vagrant no vive en estos entornos, por lo que debería usarse Docker.

Si su organización solo ejecuta contenedores Docker para todos sus proyectos y solo tiene desarrolladores que ejecutan en Linux, entonces está bien, Docker definitivamente podría funcionar para usted.

De lo contrario, no veo un beneficio al intentar usar solo Docker, ya que se pierde mucho de lo que Vagrant tiene para ofrecer, que tiene beneficios reales de negocios / productividad:

  • Vagrant puede lanzar máquinas VirtualBox, VMware, AWS, OpenStack, etc. No importa lo que necesites, Vagrant puede lanzarlo. Si está utilizando Docker, Vagrant puede instalar Docker en cualquiera de estos para que pueda usarlos con ese fin.

  • Vagrant es un flujo de trabajo único para todos sus proyectos. O para decirlo de otra manera, es solo una cosa que la gente tiene que aprender a ejecutar un proyecto, ya sea que esté en un contenedor Docker o no. Si, por ejemplo, en el futuro, un competidor surge para competir directamente con Docker, Vagrant podrá ejecutarlo también.

  • Vagrant funciona en Windows (de regreso a XP), Mac (de regreso a 10.5) y Linux (de regreso a Kernel 2.6). En los tres casos, el flujo de trabajo es el mismo. Si usa Docker, Vagrant puede iniciar una máquina (VM o remota) que pueda ejecutar Docker en los tres sistemas.

  • Vagrant sabe cómo configurar algunas cosas avanzadas o no triviales, como redes y carpetas de sincronización. Por ejemplo: Vagrant sabe cómo conectar una dirección IP estática a una máquina o reenviar puertos, y la configuración es la misma sin importar qué sistema use (VirtualBox, VMware, etc.). Para las carpetas sincronizadas, Vagrant proporciona múltiples mecanismos para obtener su información local. archivos a la máquina remota (carpetas compartidas de VirtualBox, NFS, rsync, Samba [plugin], etc.). Si está utilizando Docker, incluso Docker con una VM sin Vagrant, tendría que hacerlo manualmente o tendrían que reinventar Vagrant en este caso.

  • Vagrant 1.6 tiene soporte de primera clase para entornos de desarrollo basados ​​en docker. Esto no lanzará una máquina virtual en Linux, y lanzará automáticamente una máquina virtual en Mac y Windows. El resultado final es que trabajar con Docker es uniforme en todas las plataformas, mientras que Vagrant aún maneja los tediosos detalles de cosas como redes, carpetas sincronizadas, etc.

Para abordar argumentos contrarios específicos que he escuchado a favor de usar Docker en lugar de Vagrant:

  • "Son partes menos móviles". Sí, puede serlo, si usa Docker exclusivamente para cada proyecto. Incluso entonces, está sacrificando la flexibilidad para el bloqueo Docker. Si alguna vez decides no utilizar Docker para ningún proyecto, pasado, presente o futuro, entonces tendrás más partes móviles. Si utilizó Vagrant, tiene esa parte móvil que soporta el resto.

  • "¡Es mas rapido!" - Una vez que tienes el host que puede ejecutar contenedores Linux, Docker es definitivamente más rápido en ejecutar un contenedor de lo que cualquier máquina virtual sería para iniciar. Pero lanzar una máquina virtual (o una máquina remota) es un costo único. En el transcurso del día, la mayoría de los usuarios de Vagrant nunca destruyen su máquina virtual. Es una optimización extraña para entornos de desarrollo. En producción, donde Docker realmente brilla, entiendo la necesidad de girar rápidamente hacia arriba / abajo los contenedores.

Espero que ahora sea claro ver que es muy difícil, y creo que no es correcto, comparar a Docker con Vagrant. Para entornos de desarrollo, Vagrant es más abstracto, más general. Docker (y las diversas formas en que puede hacer que se comporte como Vagrant) es un caso de uso específico de Vagrant, ignorando todo lo demás que Vagrant tiene para ofrecer.

En conclusión: en casos de uso altamente específicos, Docker es ciertamente un posible reemplazo para Vagrant. En la mayoría de los casos de uso, no lo es. Vagrant no impide el uso de Docker; en realidad hace lo que puede para que la experiencia sea más fluida. Si encuentra que esto no es cierto, me complace tomar sugerencias para mejorar las cosas, ya que un objetivo de Vagrant es trabajar igual de bien con cualquier sistema.

¡Espero que esto aclare las cosas!


2172
2018-01-23 16:55



Soy el autor de Docker.

La respuesta corta es que si desea administrar máquinas, debe usar Vagrant. Y si desea construir y ejecutar entornos de aplicaciones, debe usar Docker.

Vagrant es una herramienta para administrar máquinas virtuales. Docker es una herramienta para crear y desplegar aplicaciones empaquetándolas en contenedores livianos. Un contenedor puede contener casi cualquier componente de software junto con sus dependencias (ejecutables, bibliotecas, archivos de configuración, etc.) y ejecutarlo en un entorno de tiempo de ejecución garantizado y repetible. Esto hace que sea muy fácil construir su aplicación una vez e implementarla en cualquier lugar: en su computadora portátil para realizar pruebas, luego en diferentes servidores para la implementación en vivo, etc.

Es un concepto erróneo común que solo puedes usar Docker en Linux. Eso es incorrecto; también puede instalar Docker en Mac, y el soporte de Windows está en marcha. Cuando está instalado en Mac, Docker empaqueta una pequeña máquina virtual Linux (¡25 MB en el disco!) Que actúa como un contenedor para su contenedor. Una vez instalado, esto es completamente transparente; puede usar la línea de comandos de Docker exactamente de la misma manera. Esto le ofrece lo mejor de ambos mundos: puede probar y desarrollar su aplicación utilizando contenedores, que son muy livianos, fáciles de probar y fáciles de mover (consulte, por ejemplo, https://hub.docker.com para compartir contenedores reutilizables con la comunidad Docker), y no tiene que preocuparse por los detalles esenciales de la administración de máquinas virtuales, que de todos modos son solo un medio para un fin.

En teoría, es posible usar Vagrant como una capa de abstracción para Docker. Recomiendo contra esto por dos razones:

  • En primer lugar, Vagrant no es una buena abstracción para Docker. Vagrant fue diseñado para administrar máquinas virtuales. Docker fue diseñado para administrar un tiempo de ejecución de la aplicación. Esto significa que Docker, por diseño, puede interactuar con una aplicación de maneras más ricas, y tiene más información sobre el tiempo de ejecución de la aplicación. Las primitivas en Docker son procesos, flujos de registro, variables de entorno y enlaces de red entre componentes. Las primitivas en Vagrant son máquinas, dispositivos de bloque y claves ssh. Vagrant simplemente se encuentra más abajo en la pila, y la única forma en que puede interactuar con un contenedor es pretendiendo que es simplemente otro tipo de máquina, que puede "iniciar" y "iniciar sesión". Así que, seguro, puedes escribir "vagabundo" con un complemento Docker y algo bonito sucederá. ¿Es un sustituto de todo lo que Docker puede hacer? Prueba Docker nativo por un par de días y compruébalo por ti mismo :)

  • Segundo, el argumento de bloqueo. "¡Si usas Vagrant como abstracción, no estarás bloqueado en Docker!". Desde el punto de vista de Vagrant, que está diseñado para administrar máquinas, esto tiene perfecto sentido: ¿no son los contenedores simplemente otro tipo de máquina? ¡Al igual que Amazon EC2 y VMware, debemos tener cuidado de no vincular nuestras herramientas de aprovisionamiento a ningún proveedor en particular! Esto crearía lock-in, es mejor abstraerlo todo con Vagrant. Salvo que esto no tiene nada que ver con Docker. Docker no aprovisiona máquinas; Envuelve su aplicación en un tiempo de ejecución portátil liviano que se puede colocar en cualquier lugar.

¡Qué tiempo de ejecución eliges para tu aplicación no tiene nada que ver con la forma en que aprovisionas tus máquinas! Por ejemplo, es bastante frecuente implementar aplicaciones en máquinas aprovisionadas por otra persona (por ejemplo, una instancia EC2 implementada por el administrador del sistema, quizás usando Vagrant), o en máquinas bare metal que Vagrant no puede aprovisionar en absoluto. Por el contrario, puede usar Vagrant para aprovisionar máquinas que no tienen nada que ver con el desarrollo de su aplicación, por ejemplo, una caja de Windows IIS lista para usar o algo así. O puede usar Vagrant para aprovisionar máquinas para proyectos que no usan Docker; quizás utilicen una combinación de rubygems y rvm para la administración de dependencias y el sandboxing, por ejemplo.

En resumen: Vagrant es para administrar máquinas, y Docker es para crear y ejecutar entornos de aplicaciones.


1281
2018-03-13 06:16



Prefacio mi respuesta al admitir que no tengo experiencia con Docker, más que como un ávido observador de lo que parece ser una solución realmente ordenada que está ganando mucha tracción.

Tengo una buena cantidad de experiencia con Vagrant y puedo recomendarlo. Sin duda, es una solución más pesada en términos de que se basa en VM en lugar de LXC. Sin embargo, he encontrado una computadora portátil decente (8 GB RAM, CPU i5 / i7) que no tiene problemas para ejecutar una máquina virtual usando Vagrant / VirtualBox junto con herramientas de desarrollo.

Una de las cosas realmente geniales con Vagrant es la integración con Marioneta/Cocinero/ scripts de shell para automatizar la configuración. Si está utilizando una de estas opciones para configurar su entorno de producción, puede crear un entorno de desarrollo que sea lo más cercano a idéntico que obtendrá, y esto es exactamente lo que desea.

La otra gran cosa con Vagrant es que puedes versionar tu Vagrantfile junto con tu código de aplicación. Esto significa que todos los demás miembros de su equipo pueden compartir este archivo y se garantiza que todos trabajen con la misma configuración de entorno.

Curiosamente, Vagrant y Docker pueden ser complementarios. Vagrant puede ampliarse para admitir a diferentes proveedores de virtualización, y es posible que Docker sea uno de esos proveedores que obtenga soporte en el futuro cercano. Ver https://github.com/dotcloud/docker/issues/404 para una discusión reciente sobre el tema.


72
2018-06-25 21:33



Son muy complementarios.

He usado una combinación de VirtualBox, Vagrant y Docker para todos mis proyectos durante varios meses y he sentido los siguientes beneficios.

En Vagrant puede eliminar completamente cualquier aprovisionamiento de Chef solo y todo lo que necesita es que su archivo vagabundo prepare una máquina que ejecute un único script de shell pequeño que instale el acoplador. Esto significa que mis Vagrantfiles para cada proyecto son casi idénticos y muy simples.

Aquí hay un archivo Vagrant típico

# -*- 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

El archivo Bootstrap que instala la ventana acoplable se parece a esto

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

Ahora, para obtener todos los servicios que necesito ejecutar, tengo un script docker_start que se parece a algo así

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

En este ejemplo estoy ejecutando MongoDB, Elastisearch, RabbitMQ y Memcached

Una configuración individual de Cocinero no estibador sería considerablemente más complicada.

Una última gran ventaja se obtiene cuando se está pasando a la producción, traduciendo el entorno de desarrollo a una infraestructura de hosts que son todos iguales ya que solo tienen suficiente configuración para ejecutar Docker significa muy poco trabajo.

Si está interesado, tengo un artículo más detallado sobre el entorno de desarrollo en mi propio sitio web en

Implementación de un entorno de desarrollo de vagabundos / estibadores


51
2017-08-20 20:42



Vagrant-lxc es un complemento para Vagrant que le permite usar LXC para provisionar Vagrant. No tiene todas las características que tiene la máquina virtual vagabundo predeterminada (VirtualBox), pero debería permitirle más flexibilidad que los contenedores acoplables. Hay un video en el enlace que muestra sus capacidades que vale la pena ver.


47
2017-08-01 18:44



Con Vagrant ahora puedes tener a Docker como proveedor. http://docs.vagrantup.com/v2/docker/. El proveedor de Docker se puede usar en lugar de VirtualBox o VMware.

Tenga en cuenta que también puede usar Docker para aprovisionamiento con Vagrant. Esto es muy diferente de usar Docker como proveedor. http://docs.vagrantup.com/v2/provisioning/docker.html

Esto significa que puedes reemplazar Cocinero o Marioneta con Docker. Puede utilizar combinaciones como Docker como proveedor (VM) con Chef como aprovisionador. O puede usar VirtualBox como proveedor y Docker como proveedor.


41
2018-05-30 16:10



El uso de ambos es una parte importante de las pruebas de entrega de aplicaciones. Solo estoy empezando a involucrarme con Docker y estoy pensando mucho en un equipo de aplicaciones que tiene una complejidad terrible en la creación y distribución de su software. Piense en una situación clásica de Phoenix Project / entrega continua.

El pensamiento es algo como esto:

  • Tome un componente de la aplicación Java / Go y compárelo como un contenedor (nota, no estoy seguro de si la aplicación debe ser construida en el contenedor o construida entonces instalado en el contenedor)
  • Entregue el contenedor a una máquina virtual Vagrant.
  • Repita esto para todos los componentes de la aplicación.
  • Itera en los componentes para codificar.
  • Continuamente prueba el mecanismo de entrega a la (s) máquina (s) virtual (es) administrada por Vagrant
  • Dormir bien sabiendo cuándo es el momento de desplegar el contenedor, que las pruebas de integración estaban ocurriendo de forma mucho más continua que antes de Docker.

Esta parece ser la extensión lógica de la afirmación de Mitchell de que Vagrant es para el desarrollo combinado con el pensamiento de Farley / Humbles en Entrega continua. Si yo, como desarrollador, puedo reducir el ciclo de retroalimentación sobre pruebas de integración y entrega de aplicaciones, se logrará una mejor calidad y mejores entornos de trabajo.

El hecho de que como desarrollador esté constantemente y constantemente entregando contenedores a la máquina virtual y probando la aplicación de manera más integral significa que las versiones de producción se simplificarán aún más.

Por lo tanto, veo que Vagrant evoluciona como una forma de aprovechar algunas de las asombrosas consecuencias que Docker tendrá para la implementación de aplicaciones.


11
2018-06-20 00:56



Hay un artículo realmente informativo en la revista real de Oracle Java sobre el uso de Docker en combinación con Vagrant (y Puppet):

Conclusión

Los contenedores livianos de Docker son más rápidos en comparación con los VM clásicos   y se han vuelto populares entre los desarrolladores y como parte de CD y DevOps   iniciativas. Si su propósito es el aislamiento, Docker es una excelente opción.   Vagrant es un administrador de VM que le permite crear configuraciones de script de   máquinas virtuales individuales, así como también el aprovisionamiento. Sin embargo, es al menos una   VM dependiente de VirtualBox (u otro administrador de VM) con relativa   gran sobrecarga Requiere que tengas un disco duro inactivo que puede ser   enorme, requiere mucha RAM y el rendimiento puede ser inferior al óptimo. Estibador   utiliza kernel cgroups y aislamiento del espacio de nombres a través de LXC. Esto significa que   está utilizando el mismo kernel que el host y el mismo sistema ile.   Vagrant está un nivel por encima de Docker en términos de abstracción, por lo que son   no es realmente comparable. Las herramientas de gestión de configuración como Puppet son   ampliamente utilizado para el aprovisionamiento de entornos de destino. Reutilizando existentes   Las soluciones basadas en títeres son fáciles con Docker. También puedes cortar tu   solución, por lo que la infraestructura se aprovisiona con Puppet; el   middleware, la aplicación comercial en sí misma o ambas están aprovisionadas   con Docker; y Docker está envuelto por Vagrant. Con este rango de   herramientas, puede hacer lo mejor para su escenario.

Cómo construir, usar y organizar contenedores Docker en DevOps http://www.javamagazine.mozaicreader.com/JulyAug2015#&pageSet=34&page=0


5
2017-08-20 13:04



Definitivamente Docker para la victoria!

Como sabrá, Vagrant es para administración de máquinas virtuales, mientras que Docker es para administración de contenedores de software. Si no está enterado de la diferencia, aquí está: Un contenedor de software puede compartir la misma máquina y kernel con otros contenedores de software. Al usar contenedores ahorras dinero porque no desperdicias recursos en múltiples sistemas operativos (núcleos), puedes empacar más software por servidor manteniendo un buen grado de aislamiento.

Por supuesto, es una nueva disciplina para cuidar con sus propios obstáculos y desafíos.

Vaya a Docker Swarm si sus requisitos cruzan el límite de recursos de una sola máquina.


5
2018-03-24 14:40