Raúl Jiménez

Docker

Durante los últimos años he adquirido la reputación de ser un radical de Docker. Yo creo que es una exageración, aunque sí es cierto que utilizo Docker prácticamente a diario y me resulta muy útil.

Esta reputación se debe en gran medida a que hace unos años tomé una determinación: quería minimizar la cantidad de herramientas y frameworks que tenía instalados en mi ordenador. Estaba harto de, cada vez que quería trabajar o contribuir a un proyecto, pasarme horas instalando herramientas, bases de datos, compiladores, CLIs, que luego a lo mejor no volvería a utilizar nunca jamás. Así que decidí que no instalaba nada más y que todos los proyectos con los que trabajaba sólo podían tener como dependencias Docker y Visual Studio Code.

Estuve trabajando en unos microservicios con Node, pero no había ni node ni npm en mi máquina. También tuve que hacer algunas cosas en Python, y de nuevo me opuse a instalarlo. Otro proyecto requería Redis, Mongo, SQLServer y Neo4j (sí todas esas bases de datos simultáneamente) y por supuesto que tampoco las instalé.

Así pasó que lo primero que tenía que hacer cada vez que utilizaba un proyecto por primera vez era configurar mi entorno para utilizar imágenes de Docker para correr todas las dependencias. Algunas imágenes las podía descargar del registro oficial de Docker, otras las tenía que crear yo mismo. Pero esa determinación de no instalar nada en mi máquina me forzó a pelearme con Docker y a aprender cómo usarlo.

Tras unos años operando de ese modo el balance ha sido tremendamente positivo. Sigo convencido que las dependencias de un proyecto deben poderse instalar automáticamente, y mejor aún de forma aislada, en paquetes que se puedan quitar fácilmente. Por eso Docker es una buena solución. Aporta muchas y poderosas ventajas:

  • Nuevas incorporaciones al equipo de desarrollo pueden comenzar a trabajar rápidamente. Al mismo tiempo si alguien abandona el proyecto puede destruir todos los recursos de un plumazo sin quedarse con restos que se van acumulando y enlenteciendo el ordenador con el tiempo.
  • Todos los miembros del equipo de desarrollo utilizan las mismas versiones y la misma configuración. Esto es fundamental para reducir los errores y agilizar los procesos de depuración.
  • No hay conflictos de versiones de una misma herramienta o framework entre diferentes proyectos.
  • Los desarrolladores son libres de utilizar Linux, Windows, o Mac. La configuración del proyecto es prácticamente igual.

Pero la adopción de Docker a nivel de proyecto tiene ramificaciones mucho más interesantes cuando se utiliza también para los procesos de integración continua y los despliegues. Los desarrolladores pueden ejecutar en su máquina, y por tanto depurar, una versión del código exactamente igual a la que está corriendo en producción. Y al utilizar herramientas de orquestación como Docker Compose, o mejor aún, Kubernetes, también ganamos en escalabilidad y flexibilidad en la utilización de los recursos.

Cuando ahora releo lo que he escrito más arriba, ¡empiezo a comprender que tenga esa fama de radical de Docker! Para ser justos debo confesar que no todo ha sido coser y cantar. También he perdido muchas horas batallando con las idiosincrasias de Docker. Y aunque en su día hice varios cursos online, y leí la documentación, me hubiera ido bien que alguien me guiara y me indicara el mejor camino a seguir.

Ese ha sido uno de los principios fundamentales que hemos utilizado para diseñar el curso de Docker que ofrece Codium. Cada vez que queríamos incluir un cierto tema o concepto en el curso nos preguntábamos, ¿nos hubiera ahorrado tiempo y sufrimiento conocer esa información?

Y es que el camino de la adopción de Docker está plagado de sutilezas que marcan la diferencia entre sacar el máximo beneficio de Docker o perder el tiempo y frustrarse. Nosotros nos hemos peleado con Docker para que tú no tengas que hacerlo. ¿Te animas a adentrarte en el mundo de Docker?