Docker, ¿qué me estás container?

A no ser que hayas estado viviendo debajo de una piedra los últimos años has tenido que escuchar las palabras Docker, Kubernetes y container. Posiblemente incluso ya estés empleando alguna de sus tecnologías. ¿Qué son? ¿Para qué y cuando se utilizan? ¿Realmente todo el hype es merecido? Vamos a comentar cada tecnología en una serie de entradas así que empezamos por el principio.

 

Solicita una propuesta personalizada

 

Para empezar a hablar de Docker tenemos que entender el flujo de desarrollo de software hasta hace no mucho. Cojamos como ejemplo el desarrollo web: como normal general existía un equipo que se dedicaba, según las especificaciones que recibía, a programar la web en el lenguaje que conocían. Este desarrollo se «ponía en producción»; habitualmente subiendo el contenido mediante FTP a un servidor.

 

Pues, ¡en mi ordenador funciona!

 

Cada vez aparecen más novedades en el desarrollo web (frameworks JS, desarrollo backend/frontend, etc.) y se va complicando todo mucho más. Hay muchas más piezas en el puzzle y cada vez que se pide una nueva funcionalidad hay que desarmarlo todo, o sólo una parte, o quizá hay que hacer que las piezas sean redondas en vez de cuadradas… pero siempre manteniendo el dibujo. Como el equipo de desarrollo no puede encargarse de programar, probar y desplegar los desarrollos, se incluyen nuevos departamentos de Quality Assurance, Operations, Front y Back van separados, etc.

El hecho de existir equipos diferenciados complicaba cada vez más que todos los entornos tuviesen la misma versión de software. Así, era muy común que un cambio realizado por un desarrollador le funcionase en su ordenador o en su servidor de pruebas, pero una vez en el servidor del proveedor, que tiene una versión anterior o con otra configuración, no funcionase. De ahí el clásico, «pues en mi ordenador funciona».

 

Un viejo conocido

 

La problemática de tener que compaginar diferentes versiones o configuraciones es tan vieja como el propio desarrollo de software. Me imagino que antes, con el papel perforado de casa y el del centro de datos, sería distinto. 😀

Algunos sistemas operativos han desarrollado a lo largo de su historia capacidades para «compartimentar» la ejecución de distintas aplicaciones sin que unas afectasen a otras: de esta manera se podrían tener diferentes entornos con otras tantas versiones funcionando a la vez. En Solaris teníamos las zones y en FreeBSD las jails. Sin embargo, debido a la poca implantación de estos sistemas operativos, su utilización ha sido bastante baja.

Podemos verlo fácilmente con la consola de Google Trends:

   

En cuanto el sistema operativo por excelencia para servidores, es decir, cualquier variante con el kernel de Linux, ha tenido un buen soporte para aislar procesos utilizando Cgroups, el uso de Docker y sistemas similares ha tenido una expansión tremenda.

   

 

Solicita asesoramiento sin compromiso

   

Máquinas virtuales al rescate

 

Con la llegada de los sistemas de virtualización el Cloud nos dio la opción de poder probar distintas versiones de software y separar cargas de trabajo de una forma mucho más ágil que con servidores físicos como hasta ahora. ¿Que al actualizar a la última versión deja de funcionar todo? No pasa nada, revierto el snapshot y listo.

El problema de las máquinas virtuales viene cuando necesitas montar la misma infraestructura en tu ordenador para hacer pruebas y en que los proveedores cobramos por cada servidor virtual. 😉 Además, hay que gestionar cada una de ellas, lo cual puede llegar a ser una carga de trabajo importante para los administradores de sistemas (y aquí podríamos hablar largo y tendido de sistemas de orquestación tipo Ansible o Puppet).

Con las máquina virtuales siempre se pierde algo de rendimiento y recursos, ya que por cada aplicación que tengamos, tenemos que reservar recursos para el sistema operativo. En Docker eso se reduce ya que las distintas aplicaciones corren en el mismo sistema operativo.

   

Docker sigue el paradigma de los contenedores de transporte de mercancías. Desde que se estandarizaron, cualquier camión, barco, tren, grúa, almacén, etc. están preparados para poder mover, transportar o almacenar cualquier contenedor de cualquier parte del mundo.

 

Pero… ¿cómo funciona?

 

Docker es un «demonio» que corre en el sistema operativo (da igual Linux, MacOS o Windows) y que interactúa a través de una serie de APIs. Por lo general se utiliza la herramienta de línea de comandos directamente o integraciones en el entorno de desarrollo. Una vez que tenemos Docker instalado, lo que se hace es definir un archivo que se llama Dockerfile y que básicamente son los comandos que vamos a ejecutar para «construir» nuestra imagen.

Esta imagen que vamos a construir va a ser inmutable. Esto significa que cualquier cambio que se guarde dentro del mismo se perderá la próxima vez que se arranque el contenedor, ya que el contenedor tiene que ser exactamente igual, se arranque donde se arranque y se arranque cuando se arranque.

Un ejemplo de archivo Dockerfile sería este, en el que partimos de una imagen de Python 3:

# My Site
# Version: 1.0
FROM python:3
# Upgrade Libraries
RUN apt-get update && apt-get upgrade -y && apt-get autoremove && apt-get autoclean
ARG ENTORNO
# Project Files and Settings
COPY ./requeriments.txt .
# Install dependencies and site
RUN pip install --upgrade pip
RUN pip install -r requeriments.txt
RUN mkdir -p /var/www/proyecto
COPY ./proyecto /var/www/proyecto/
WORKDIR /var/www/proyecto/
# Run server
EXPOSE 8000
STOPSIGNAL SIGINT
ENTRYPOINT ["python", "manage.py"]
CMD ["runserver", "0.0.0.0:8000"]

Con este archivo ya podemos generar nuestra imagen de Docker, ejecutarla en local, subirla a un repositorio, mandarla a un servidor… Además, podemos apoyarnos en otras herramientas como Docker Compose para ayudarnos en la ejecución y olvidarnos de largos comandos cada vez que arranquemos el contenedor.

 

Docker ha llegado para quedarse

 

Si bien al principio el uso de Docker era un tanto residual y estaba bastante limitado, ha tenido un crecimiento exponencial y ya hemos pasado del «¿Pero usáis docker en producción? ¡Qué atrevidos!» al «¿Aún no usáis Docker?» siendo ya una herramienta tanto estable como necesaria.

Bien sea por actualizaciones de entornos y tener que seguir manteniendo código legacy en servidores modernos para que entre una persona nueva a hacer un desarrollo o por seguir buenas prácticas en el desarrollo de software, Docker es una herramienta que ya está bastante madura, con una buena documentación, una gran comunidad de usuarios y que no parece vaya a ser una moda pasajera.

Déjame un comentario o escríbeme un tuit a @sarenet si te ha gustado este artículo; en próximas entradas hablaré de Kubernetes y de cómo es la forma natural de desplegar proyectos con Docker en producción.

 

PD:

 

• Conseguir escribir un post sobre Docker sin poner una imagen de contenedores de transporte: ❌
• No poner el logo de la ballena: ✔️
• «Pues en mi equipo me funciona»: ✔️
• Tener el mejor título de post del blog hasta ahora: ✔️
• Colar el vídeo de cierto personaje usando Docker: 😉

 

 

 

Solicita una propuesta personalizada