tools - ¿Debo usar Vagrant o Docker para crear un entorno aislado?

vagrant windows (10)

Uso Ubuntu para el desarrollo y la implementación y tengo la necesidad de 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?

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

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

Esto significa que puedes reemplazar a 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.

El uso de ambos es una parte importante de las pruebas de entrega de aplicaciones. 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 entrega de su software. Piense en una situación clásica de Proyecto de Phoenix / Entrega continua.

El pensamiento va algo así:

Tome un componente de la aplicación Java / Go y créelo como un contenedor (tenga en cuenta, no está seguro si la aplicación debe estar integrada en el contenedor o construirse luego en el contenedor)
Entregar el contenedor a una máquina virtual Vagrant.
Repita esto para todos los componentes de la aplicación.
Iterar en el (los) componente (s) para codificar.
Pruebe continuamente el mecanismo de entrega a las máquinas virtuales administradas por Vagrant
Duerma bien sabiendo que es hora de implementar el contenedor, que las pruebas de integración se estaban realizando 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 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, se aplicará una mejor calidad y mejores entornos de trabajo.

El hecho de que, como desarrollador, ofrezco contenedores de forma constante y constante a la máquina virtual y que la prueba sea más holística significa que las versiones de producción se simplificarán aún más.

Así que veo a Vagrant evolucionar como una forma de aprovechar algunas de las increíbles consecuencias que Docker tendrá para el despliegue de aplicaciones.

Hay un artículo realmente informativo en la revista 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 hecho 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 máquinas virtuales que le permite crear configuraciones de secuencias de comandos individuales de las secuencias de comandos y realizar el aprovisionamiento. Sin embargo, es una máquina virtual dependiente de VirtualBox (u otro administrador de VM) con una sobrecarga relativamente grande. Requiere que tengas un disco duro inactivo que puede ser enorme, requiere una gran cantidad de RAM y el rendimiento puede ser subóptimo. Docker utiliza cgroups del kernel y el aislamiento del 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 es un nivel por encima de Docker en términos de abstracción, por lo que no son realmente comparables. Las herramientas de administració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 empresarial en sí misma o ambos están provistos de Docker; y Docker es envuelto por Vagrant. Con esta gama de herramientas, puede hacer lo que sea mejor para su escenario.

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

Prólogo 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 clara que está ganando mucha tracción.

Tengo una buena 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 LXC. Sin embargo, he encontrado que una computadora portátil decente (8 GB de RAM, CPU i5 / i7) no tiene problemas para ejecutar una máquina virtual utilizando Vagrant / VirtualBox junto con las herramientas de desarrollo.

Una de las cosas realmente grandes con Vagrant es la integración con Puppet / Chef / shell scripts 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 casi idéntico al que va a obtener, y esto es exactamente lo que desea.

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

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

Si tu propósito es el aislamiento, creo que Docker es lo que quieres.

Vagrant es un gestor de máquinas virtuales. Le permite hacer 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 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, utiliza kgroup cgroup y namespacing a través de LXC . Esto significa que está utilizando el mismo kernel que el host y el mismo sistema de archivos. Puede usar Dockerfile con el comando de docker build ventana docker build 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 realizar BSD, Windows u otro desarrollo que no sea Linux en su caja de Ubuntu. De lo contrario, ve por Docker.

Son muy complementarios.

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

En Vagrant puede eliminar por completo cualquier aprovisionamiento solo 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 la ventana acoplable. Esto significa que mis archivos Vagrant para cada proyecto son casi idénticos y muy simples.

Aquí hay un Vagrantfile 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 en ejecución, tengo un script docker_start que se ve 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 solo de Chef que no sea docker sería considerablemente más complicada.

Se obtiene una gran ventaja final cuando se está moviendo a producción, traducir el entorno de desarrollo a una infraestructura de hosts que son todos iguales, ya que solo tienen la configuración suficiente para ejecutar la ventana acoplable, 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

Implementando un entorno de desarrollo Vagrant / Docker

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 utilizar Docker.

Vagrant es una herramienta para gestionar máquinas virtuales. Docker es una herramienta para crear y desplegar aplicaciones empaquetándolas en contenedores ligeros. 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 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 probarla, luego en diferentes servidores para la implementación en vivo, etc.

Es un error común que solo se pueda 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 el disco!) Que actúa como un contenedor para su contenedor. Una vez instalado esto es completamente transparente; Puede utilizar 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 ligeros, 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 en contra de esto por dos razones:

Primero, Vagrant no es una buena abstracción para Docker. Vagrant fue diseñado para gestionar máquinas virtuales. Docker fue diseñado para administrar una aplicación en tiempo de ejecució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, secuencias de registro, variables de entorno y enlaces de red entre componentes. Los primitivos en Vagrant son máquinas, dispositivos de bloque y teclas ssh. Vagrant simplemente se sienta más abajo en la pila, y la única forma en que puede interactuar con un contenedor es fingir que es simplemente otro tipo de máquina, que puede "iniciar" e "iniciar sesión". Entonces, seguro, puedes escribir "vagrant up" con un complemento de Docker y algo bonito sucederá. ¿Es un sustituto de toda la amplitud de lo que Docker puede hacer? Prueba Docker nativo por un par de días y compruébalo por ti mismo :)
En segundo lugar, el argumento de bloqueo. "Si usas Vagrant como una abstracción, ¡no estarás atrapado 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 bloqueo, mejor abstraerlo todo con Vagrant. Excepto que esto pierde el punto de Docker por completo. Docker no aprovisiona máquinas; envuelve su aplicación en un tiempo de ejecución portátil ligero que se puede colocar 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 que son aprovisionadas por otra persona (por ejemplo, una instancia de EC2 implementada por el administrador de su sistema, tal vez usando Vagrant), o en máquinas de metal que Vagrant no puede aprovisionar en absoluto. A la inversa, 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 IIS de Windows 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 crear y ejecutar entornos de aplicaciones.

Vagrant-lxc es un complemento para Vagrant que te permite usar LXC para aprovisionar Vagrant. No tiene todas las características que tiene la VM virtual predeterminada (VirtualBox) pero debería permitirle una mayor flexibilidad que los contenedores docker. Hay un video en el enlace que muestra sus capacidades que vale la pena ver.

Descargo de responsabilidad: escribí Vagrant! Pero como escribí Vagrant, pasé la mayor parte del 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 interactúan las dos.

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 discuto más a fondo), 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 frente a algo como Boot2Docker (sistema operativo mínimo que puede ejecutar Docker). Vagrant es 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 remoto como AWS, OpenStack. Dentro de ellos, si usa contenedores, a Vagrant no le importa, y acepta que: puede instalar, desplegar, construir y ejecutar contenedores de Docker automáticamente, por ejemplo. Con Vagrant 1.6, Vagrant tiene entornos de desarrollo basados en ventana acoplable 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 host en algún lugar). 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 de Docker para todos sus proyectos y solo tiene desarrolladores que se ejecutan en Linux, entonces, ¡Docker definitivamente podría trabajar 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, que tiene beneficios reales de negocio / 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 para ese propósito.
Vagrant es un flujo de trabajo único para todos tus proyectos. O para decirlo de otra manera, es solo una cosa que las personas deben 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á correr eso.
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 los tres sistemas.
Vagrant sabe cómo configurar algunas cosas avanzadas o no triviales como las redes y las carpetas de sincronización. Por ejemplo: Vagrant sabe cómo adjuntar una 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 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 ventana acoplable . Esto no iniciará una máquina virtual en Linux, y automáticamente lanzará 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 detalles tediosos de cosas como redes, carpetas sincronizadas, etc.

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

"Es menos partes móviles": sí, puede serlo, si usa Docker exclusivamente para cada proyecto. Incluso entonces, está sacrificando la flexibilidad para el bloqueo de Docker. Si alguna vez decide no usar Docker para cualquier proyecto, pasado, presente o futuro, tendrá más partes móviles. Si ha 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 en la ejecución de un contenedor que cualquier máquina virtual que se inicie. Pero lanzar una máquina virtual (o una 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 extraña optimización 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 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 comportarse como Vagrant) es un caso de uso específico de Vagrant, ignorando todo lo que Vagrant tiene para ofrecer.

En conclusión: en casos de uso altamente específicos, Docker es sin duda 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 hacer que la experiencia sea más suave. Si encuentra que esto no es cierto, me complace recibir sugerencias para mejorar las cosas, ya que el objetivo de Vagrant es trabajar igualmente bien con cualquier sistema.

¡Espero que esto aclare las cosas!

Definitivamente Docker para la victoria!

Como sabrá, Vagrant es para la gestión de máquinas virtuales, mientras que Docker es para la gestión de contenedores de software. Si no está al tanto de la diferencia, aquí está: Un contenedor de software puede compartir la misma máquina y núcleo con otros contenedores de software. Al usar contenedores, ahorra dinero porque no desperdicia recursos en varios sistemas operativos (kernels), puede empaquetar más software por servidor manteniendo un buen grado de aislamiento.

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

Elija Docker Swarm si sus requisitos superan el límite de recursos de una sola máquina.