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

Uso Ubuntu para el desarrollo y la 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?

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

Vagrant es un administrador de máquinas virtuales. Le permite realizar un script de 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 tenga un archivo de disco duro que puede ser enorme, requiere mucha memoria 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 núcleo que el host y el mismo sistema de archivos. Puede usar Dockerfile con el docker buildcomando para manejar el aprovisionamiento y la configuración de su contenedor. Tiene un ejemplo en docs.docker.com sobre cómo hacer su Dockerfile; 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 de Ubuntu. De lo contrario, ve por Docker.

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

Antes de hablar demasiado, una respuesta directa: en su escenario específico (trabajando solo, trabajando en Linux, usando Docker en producción), puede quedarse solo con Docker y simplificar las cosas. En muchos otros escenarios (lo discuto 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 fines de desarrollo. Esto puede estar en VirtualBox, VMware. Puede ser remoto como AWS, OpenStack. Dentro de esos, si usa contenedores, a Vagrant no le importa, y lo acepta: puede instalar, desplegar, construir y ejecutar automáticamente contenedores Docker, por ejemplo. Con Vagrant 1.6, Vagrant tiene entornos de desarrollo basados ​​en Docker y 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 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 se debe usar Docker.

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

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

• Vagrant puede lanzar máquinas VirtualBox, VMware, AWS, OpenStack, etc. No importa lo que necesite, Vagrant puede lanzarlo. Si está usando Docker, Vagrant puede instalar Docker en cualquiera de estos para que pueda usarlos para ese propósito.

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

• Vagrant funciona en Windows (de vuelta a XP), Mac (de vuelta a 10.5) y Linux (de vuelta al 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 puede ejecutar Docker en estos tres sistemas.

• Vagrant sabe cómo configurar algunas cosas avanzadas o no triviales como la creación de redes y la sincronización de carpetas. Por ejemplo: Vagrant sabe cómo conectar una IP estática a una máquina o puertos de reenvío, y la configuración es la misma sin importar el sistema que use (VirtualBox, VMware, etc.) Para carpetas sincronizadas, Vagrant proporciona múltiples mecanismos para obtener su local archivos a la máquina remota (carpetas compartidas de VirtualBox, NFS, rsync, Samba [plugin], etc.). Si está usando Docker, incluso Docker con una VM sin Vagrant, tendría que hacer esto 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 menos partes móviles" - Sí, puede serlo si usas Docker exclusivamente para cada proyecto. Incluso entonces, está sacrificando la flexibilidad para el bloqueo de Docker. Si alguna vez decide no usar Docker para ningún proyecto, pasado, presente o futuro, tendrá más partes móviles. Si había usado Vagrant, tiene esa parte móvil que soporta el resto.

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

Espero que ahora esté claro ver que es muy difícil, y creo que no es correcto, comparar 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. Vagabundo no obstaculiza su uso de Docker; en realidad hace lo que puede para que esa 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 igualmente bien con cualquier sistema.

¡Espero que esto aclare las cosas!

Soy el autor de Docker.

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

Vagrant es una herramienta para administrar máquinas virtuales. Docker es una herramienta para construir e implementar aplicaciones empaquetándolas en contenedores livianos. Un contenedor puede contener prácticamente 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 una implementación en vivo, etc.

Es un error común pensar que solo puedes usar Docker en Linux. Eso es incorrecto; También puede instalar Docker en Mac y Windows. Cuando se instala en Mac, Docker incluye una pequeña máquina virtual Linux (¡25 MB en disco!) Que actúa como envoltorio 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 brinda 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 necesita 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:

• Primero, Vagrant no es una buena abstracción para Docker. Vagrant fue diseñado para administrar máquinas virtuales. Docker fue diseñado para administrar el tiempo de ejecución de una aplicación. Esto significa que Docker, por diseño, puede interactuar con una aplicación de formas más completas y tiene más información sobre el tiempo de ejecución de la aplicación. Las primitivas en Docker son procesos, secuencias 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 sienta más abajo en la pila, y la única forma en que puede interactuar con un contenedor es fingiendo que es solo otro tipo de máquina, que puede "arrancar" e "iniciar sesión". Entonces, seguro, puede escribir "vagabundo" con un complemento Docker y sucederá algo bonito. ¿Es un sustituto de la amplitud total de lo que Docker puede hacer? Pruebe Docker nativo por un par de días y compruébelo usted mismo :)

• En segundo lugar, el argumento de bloqueo. "Si usas Vagrant como una abstracción, ¡no estarás encerrado en Docker!". Desde el punto de vista de Vagrant, que está diseñado para administrar máquinas, esto tiene mucho 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 un bloqueo, mejor abstraerlo todo con Vagrant. Excepto que esto pierde completamente el punto de Docker. Docker no aprovisiona máquinas; envuelve su aplicación en un tiempo de ejecución portátil ligero que se puede soltar en cualquier lugar.

¡El tiempo de ejecución que elija para su aplicación no tiene nada que ver con cómo aprovisiona sus 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, tal vez usando Vagrant), o en máquinas de metal desnudo 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; tal vez usen 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 construir y ejecutar entornos de aplicaciones.

Prefacio mi respuesta admitiendo que no tengo experiencia con Docker, aparte de ser 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 estar basada en VM en lugar de estar basada en LXC. Sin embargo, he encontrado que una computadora portátil decente (8 GB de RAM, CPU i5 / i7) no tiene problemas para ejecutar una VM usando Vagrant / VirtualBox junto con herramientas de desarrollo.

Una de las cosas realmente geniales con Vagrant es la integración con scripts Puppet / Chef / 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 idéntico posible y esto es exactamente lo que desea.

La otra gran cosa con Vagrant es que puede versionar su Vagrantfile junto con su código de aplicación. Esto significa que todos los demás miembros de su equipo pueden compartir este archivo y tiene la garantía de que todos trabajan con la misma configuración de entorno.

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

Son muy complementarios.

He estado usando 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 por completo cualquier aprovisionamiento individual de Chef y todo lo que necesita para hacer su archivo vagabundo es preparar una máquina que ejecute un único script de shell pequeño que instale docker. 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 ve así

#!/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 ve 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 Chef no acoplado sería considerablemente más complicada.

Se obtiene una gran ventaja final 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, lo que 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 vagabundo / acoplable

Vagrant-lxc es un complemento para Vagrant que le permite usar LXC para aprovisionar Vagrant. No tiene todas las características que tiene la VM vagabunda 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.

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

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

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

Usar ambos es una parte importante de las pruebas de entrega de aplicaciones. Estoy empezando a involucrarme con Docker y a pensar mucho en un equipo de aplicaciones que tiene una complejidad terrible en la construcción y entrega de su software. Piense en una situación clásica de Proyecto Phoenix / Entrega continua.

El pensamiento es algo como esto:

• Tome un componente de la aplicación Java / Go y compílelo como un contenedor (tenga en cuenta que no está seguro si la aplicación se debe compilar en el contenedor o compilar y luego instalar en el contenedor)
• Entregue el contenedor a una máquina virtual Vagrant.
• Repita esto para todos los componentes de la aplicación.
• Iterar en los componentes a codificar.
• Pruebe continuamente el mecanismo de entrega a las máquinas virtuales gestionadas por Vagrant
• Duerma bien sabiendo que es hora de implementar el contenedor, que las pruebas de integración se realizaban de manera 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 la entrega continua. Si yo, como desarrollador, puedo reducir el ciclo de retroalimentación sobre las pruebas de integración y la entrega de aplicaciones, seguirán una mayor calidad y mejores entornos de trabajo.

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

Entonces veo que Vagrant evoluciona como una forma de aprovechar algunas de las impresionantes consecuencias que Docker tendrá para la implementación de la aplicación.

¡Definitivamente Docker por la victoria!

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

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

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

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 las máquinas virtuales clásicas y se han vuelto populares entre los desarrolladores y como parte de las iniciativas de CD y DevOps. 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 realizar el aprovisionamiento. Sin embargo, todavía es una VM que depende de VirtualBox (u otro administrador de VM) con una sobrecarga relativamente grande. Requiere que tenga un disco duro inactivo que puede ser enorme, requiere mucha RAM y el rendimiento puede ser subóptimo. Docker utiliza cgroups de kernel y aislamiento de espacio de nombres a través de LXC. Esto significa que está utilizando el mismo núcleo que el host y el mismo sistema de archivos. Vagrant está un nivel por encima de Docker en términos de abstracción, por lo que no son realmente comparables. Las herramientas de gestión de la configuración, como Puppet, se utilizan ampliamente para aprovisionar entornos de destino. Reutilizar las soluciones existentes basadas en Puppet es fácil con Docker. También puede dividir su solución, por lo que la infraestructura se aprovisiona con Puppet; el middleware, la aplicación comercial en sí misma o ambos están aprovisionados con Docker; y Docker está envuelto por Vagrant. Con esta gama de herramientas, puede hacer lo mejor para su escenario.

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