Docker Vs Vagrant + VirtualBox para entornos de desarrollo

Cuando tenemos un entorno de desarrollo mínimamente complejo, necesitamos un sistema fácil, simple y fiable para gestionarlo.

Muchos habréis empezado a usar stacks LAMPP, XAMPP o el equivalente en otros lenguajes como Python o Ruby. Aún así, estos entornos se acaban quedando cortos a nivel de configuración y portabilidad.

Cuando el equipo crece, o si te cambias el PC tienes que reinstalar todo y configurar de nuevo. Suele llevar mucho tiempo.

Si vas a trabajar en diferentes proyectos que necesitan diferentes versiones de un lenguaje (Python 2.x Vs Python 3.x, o PHP5.X Vs PHP7.x), es un poco un infierno.

La solución siempre es la misma: virtualización.

Vagrant + VirtualBox

VirtualBox es un sistema de virtualización que te permite instalar un sistema operativo dentro de otro. Independientemente si tienes MacOS, Windows o Linux, puedes virtualizar varias máquinas distintas: Por ejemplo un Ubuntu 14.04 y otro Ubuntu 18.04. En cada una de ellas instalarás sus proyectos y con sus dependencias.

El proceso de instalación de una máquina de VirtualBox consiste en descargarte la ISO, pasar por todo el proceso de instalación, y después instalar individualmente las dependencias de sistema que tengas. Un coñazo, vamos.

Vagrant te permite, mediante un fichero de configuración bastante simple, definir qué máquina quieres (en este caso el sistema operativo) y se descarga de Internet una versión ya pre-instalada con lo básico. Después, le puedes indicar cómo quieres que te provisione la máquina.

La provisión no es mas que un conjunto de pasos automáticos que se seguirán para dejar tu máquina en el estado deseado: instalar dependencias de sistema, configurarlas, iniciar servicios, etc, etc…

El proceso de provisión puede ser un simple script de BASH en caso de Linux. El problema es que, si tu entorno se va complicando, el script de Bash se complicará también, haciéndolo inmantenible. Hay herramientas que facilitan el mantenimiento de dichos scripts, que pueden llegar a hacerse muy complejos. Léase Ansible, Salt, Puppet, etc…

Entonces, cómo queda el tinglado:

  1. Tu portátil, con el SO que tengas/quieras
  2. VirtualBox, herramienta de virtualización. Tendremos todas las máquinas virtuales que necesitemos, una por proyecto
  3. Vagrant, nos ayuda a crear la máquina virtual sin procesos manuales
  4. Ansible: Nos provisiona (instala) todos los programas dentro de la máquina virtual sin intervención manual

Docker

Docker es un sistema similar, pero muy diferente. Nos ayuda a aislar nuestros entornos de desarrollo, y que sean portables, pero haciendo uso de una tecnología llamada Containers.

Un Container es una Máquina Virtual en miniatura. Normalmente dentro de ésta máquina virtual solo se ejecuta un único proceso.

Ejemplos de “procesos”:

  • Un proceso Apache ( servidor web )
  • Un proceso de PHP-FPM (servidor de PHP)
  • Un proceso de MySQL (base de datos)
  • Un proceso RabbitMq (cache y sistema básico de colas)

Cada contenedor es una entidad única, y lo que haremos será definir la relación entre containers, para que puedan “hablar” entre ellos. 

Crearemos tantos Containers como procesos y servicios necesitemos, y éstos serán gestionados por Docker.

Hay una herramienta llamada Docker Compose que nos permite orquestrar estos containers. Como bien decíamos es importante definir la relación entre ellos a nivel de red, definir atributos por container, etc…

Para cada servicio, pongamos por ejemplo el servidor web Apache, hay ya imágenes pre-creadas en internet donde podemos descargar cualquier versión de Apache. De modo que nosotros usaremos estas imágenes básicas para descargar el servicio, y después, mediante un fichero Dockerfile, configuraremos cada una de ellas (creando virtual hosts, por ejemplo).

A nivel de arquitectura quedaría algo así:

  1. Tu máquina física
  2. Docker: El servicio que gestiona los containers
  3. Docker Compose: Fichero de configuración en el que le dice al Servicio de Docker qué containers crear: un mysql, un apache, etc… y la relación entre ellos, además de otras características como la red en la que están, el disco que tiene cada container, así como el número de cores que tiene cada container.
  4. El Dockerfile: Fichero de configuración, que le dice a DockerCompose cómo tiene que ser exactamente el Container. No basta con decir que quieres un container de Apache, tienes que configurar los VirtualHosts.
  5. Esto quiere representar un “proyecto” de DockerCompose, con red privada y la relación entre containers
  6. Containers individuales, que hacen una única cosa, y nada mas. Procesos muy pequeños, que “pesan muy poco”, una pequeña fracción que la máquina virutual de VirtualBox, pero pudiendo definir limites como tamaño de disco, uso de CPU, o accesos entre containers, entre otros…

Docker Vs VirtualBox + Vagrant

Vale, todo esto está muy bien. Yo he venido a ver una comparativa entre ambos sistemas.

tú, hoy y ahora.

Nota: Llamaré VirtualBox + Vagrant + Ansible = VVA (nombre inventado, no lo he visto en ningún lado)

Facilidad de setup

VVA: Tienes que aprender 3 tecnologías separadas para tener un proceso completamente automático. Cada tecnología son proyectos separados, sin relación alguna.

Docker: Tienes que aprender 3 proyectos separados: Docker, Docker Compose, y Dockerfile. Peeeero todos estos proyectos forman parte de los mismos creadores, y se integran muy bien entre ellos

Tiempo de provisión

Cuando se tarda en provisionar un entorno desde 0, y cuando se tarda en aplicar un cambio puntual.

VVA: Digamos que Ansible, el encargado de provisionar ejecuta siempre todo los pasos, cada vez, para cada cambio. En mi caso implicaba varias horas para la puesta apunto completa, y unos 20 minutos para cada cambio puntual.

Docker: La primera vez tarda un tiempo similar a VVA, pero al actualizar los cambios van por cada container, lo que es asombrosamente rápido.

Curva de aprendizaje

Diría que el tiempo es similar en ambos proyectos, pero en el caso de Docker te puede servir para utilizarlo en entornos productivos ya que se usa para mas cosas que Vagrant o VirtualBox

Portabilidad

Similar, soportado en todas las plataformas, aunque Windows+Ansible creo que no funciona por tanto necesitas usar otro sistema de provisión. Aún así Docker tiene algunas limitaciones en Windows, por lo que lo dejaremos como empate.

Facilidad de crear un proyecto nuevo

VAA: Mi experiencia ha sido bastante mala, ya que cada vez provisionas una máquina de 0. No puedes reaprovechar nada entre setups, y a veces tienes que crear una máquina virtual solo para un proyecto muy chiquitito, ocupando mucho espacio en disco, y gastando ciclos de CPU inútilmente

Docker: Super simple. A mas proyectos tengas, mas setups individuales tendrás y será muy fácil astillar la parte común de algún otro proyecto, y crear sólo lo nuevo. Up&Running en un par de minutos.

Documentación y soporte

VAA: Los proyectos de VirtualBox, Vagrand (de Hashicorp) y Ansible son usados por mucha gente. Aún así la combinación de los tres, aunque muy útil no está tan bien documentada como Docker

Docker: Al ser todo del proyecto Docker, hay miles de cursos y ejemplos online de hacer éste setup ya que es “el modo de hacer el Docker”. Todo standart. 

Interconexión entre proyectos

VAA: Como tienes una máquina virtual, la tienes que tratar como tal; tendrá una única IP, tiene que tener los puertos expuestos y otros proyectos se podrán comunicar con ella. Es mas “tradicional”, menos flexibilidad. Menos amigo con microservicios.

Docker: Cada container tiene su IP. Un conjunto de containers tiene su propia red, puedes definir fácilmente los vínculos entre Containers. Ideal para microservicios.

Conclusión

Para nosotros en la empresa, cuando hemos hecho el cambio de VAA a Docker nos ha supuesto una gran mejora, tanto en mantenibilidad, como en lenvantar un entorno de 0 en fración del tiempo que tardábamos en hacerlo con VAA. Docker, al ser una tecnología bastante extendida y en la que te centras en Containers (unidades lógicas individuales), es mucho mas fácil que cada equipo cree los suyos a voluntad (front-end, backend, QA, …)

No desrecomiendo VAA, puesto que durante dos años nos ha solucionado la papeleta, pero cuando el proyecto crece mucho, las máquinas virtuales de cada uno van “divergiendo” con pequeños cambios, y debuguear errores es mucho mas difícil. Puesto que borrar y volver a crear lleva mucho mas tiempo, intenábamos evitarlo. Con Docker, es mas difícil hacer estos cambios “custom” en cada Container y, de haberlo, es mínimo puesto que tiene una responsabilidad muy definida, y es muy fácil incluirlo en el proceso normal como a todos los demás.

Compartir cambios con Docker ha resultado ser mucho mas fácil entre equipos, y en definitiva hemos estado muy contentos con la experiencia con Docker.


Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *