Docker para humanos

Hablando un día con un amigo al que hacía mil que no veía, en una cola de un teatro, poniéndonos al día sobre en qué andaba cada uno, la vida y esas cosas, surgieron las palabras Docker y Kubernetes, en la conversación. Mi amigo no es del mundillo friki, pero le sonaban un poco los términos, aunque en seguida empezó a patinar un poco y me di cuenta de que le faltaba entender bien la base. De ahí este artículo :)

No es este un artículo sobre cómo empezar a usar Docker y voy a intentar que no haya prácticamente nada técnico, mi objetivo es que si has oído hablar de Docker en algún momento pero no tienes ni idea de qué va la vaina, salgas de aquí sabiendo qué es y por qué se utiliza.

Docker es una tecnología para usar contenedores de software. Un contenedor es una forma estándar de agrupar todo lo que tu software necesita para funcionar en un solo paquete, el contenedor, y que se sepa que va a funcionar en cualquier entorno en el que se ejecute.

En el mundo del software, cuando trabajas con muchos proyectos, suele ser habitual que cada proyecto tenga unas necesidades distintas, a nivel de lenguajes de programación, librerías, plataformas base sobre las que se trabaja, si las hubiera, frameworks, etc. Por ejemplo, nosotros desarrollamos muchos proyectos a medida basados en Symfony pero nuestra web está hecha en Vue.js. Incluso dentro de los proyectos basados en Symfony, algunos clientes ya tenían algo hecho en versiones más antiguas de las que usamos en otros, etc.

Nosotros queremos que, cuando estamos trabajando en un proyecto concreto, en local, para programar y probarlo, tengamos un entorno lo más fiel posible a la realidad, a lo que tendrá luego el cliente en Producción. También queremos poder cambiar de un proyecto a otro sin dolor (sin largas esperas, sin tener que reiniciar la máquina, etc). Si no trabajas así, empiezan los dolores de cabeza de hacer algo que te funciona cuando lo pruebas en tu ordenador, o en el servidor de pruebas, y luego no funciona a la hora de entregarlo. Aparte de la pérdida de tiempo, la imagen que se da es de menos profesionalidad.

Docker utiliza lo que se llaman contenedores de software para simular un entorno completo, con su memoria asignada, su procesador, sus librerías, versiones de programas, etc, para ser exactamente fiel a lo mismo que hay en Producción. Muchas veces verás pintados los contenedores de software como contenedores de barco, es una abstracción parecida, en un mismo barco (máquina física), podemos tener muchos contenedores de software ejecutándose a la vez, podemos pararlos (bajarlos del barco), ejecutarlos de nuevo y cambiar entre unos y otros de forma fácil.

Todos los contenedores que se ejecutan en la misma máquina comparten el sistema operativo que hay por debajo y muchas librerías y programas, pero trabajan de forma aislada, no pueden escribirse los unos en los otros, lo que da cierta seguridad.

Como expliqué en el artículo sobre desplegar con artefactos, existe otro motivo para usar Docker que facilitarnos la vida en local (que ya es), y es el de garantizar que todos los entornos en los que programamos y ejecutamos nuestro código, son equivalentes. La única manera de hacer esto, usando Docker, es utilizando también en Producción contenedores basados en Docker. Teniendo un servidor al que tengamos acceso podemos ejecutar contenedores en Producción con Docker Engine, pero con los proveedores de servicios de plataformas en la nube, como AWS de Amazon, Google Cloud, Microsoft Azure, o DigitalOcean, es todavía más sencillo. En el caso de Google Cloud hay multitud de formas de hacerlo, la más nueva y rápida para probar, Google Cloud Run.

Lo anterior es verdad, con una máquina virtual solucionas el probar las cosas en máquinas equivalentes, pero son muuuuuuuy lentas para trabajar con ellas a diario. Levantar una máquina virtual son minutos, varios minutos, tiene que ejecutarse luego todo el arranque del sistema operativo, etc, aparte de que al contener el sistema operativo como tal, las imágenes de máquinas virtuales son del orden del giga por lo menos.

Ya estoy entrando en demasiado detalle técnico... 😅, en posteriores artículos trataremos sobre buenas prácticas en el trabajo con contenedores. Si te interesa algún tema en particular o quieres darnos tu opinión, comentario, sugerencia o crítica, dejanos un correíllo en hola@softspring.es o en nuestras redes sociales. Gracias!