Cada mes salen al mercado nuevas herramientas, frameworks, metodologías y cosas maravillosas. Pero estar al día es una auténtica locura y lleva demasiado tiempo. A mí me gusta estar al tanto pero no hay horas en el día para investigar y probar todo lo que sale.
Pero de vez en cuando aparece alguna herramienta que sí que merece la pena. Y una de esas es Docker.
Docker te vale tanto si eres un mega-empresón con miles de empleados como si eres un modesto autónomo trabajando desde casa.
Recibimos muchas consultas relacionadas con Docker, sobre todo preguntando qué porras es. En este artículo voy a intentar explicarlo desde el punto de vista de un desarrollador.
¿Cómo trabajábamos antes?
Hace años, los desarrolladores solíamos tener una estructura parecida a ésta:
- un servidor de producción (el servidor “real”),
- luego (con mucha suerte) había un servidor de pre-producción que solía ser un servidor igualito al de producción y donde podíamos hacer pruebas antes de pasar a producción,
- también había un servidor de test y/o uno de desarrollo donde hacíamos nuestras chapucillas. En muchos casos estos servidores solían estar nuestros propios ordenadores… y aquí era donde surgía el auténtico caos.
La idea era que al llegar a producción la aplicación estuviera bien probada. Esto era muy bonito pero había muchos problemas:
- Los servidores de producción y pre-producción solían ser iguales… casi siempre. No era raro que tuvieran diferentes versiones del sistema operativo, o que alguna librería fuese diferente, o que determinada configuración cambiase. El resultado… lo que funcionaba en pre-producción podía no funcionar en producción.
- Los ordenadores de los desarrolladores ¡eso sí era un caos! Cada uno podía tener versiones totalmente diferentes del sistema operativo (¡o podía incluso tener un sistema operativo totalmente incompatible!). Cada uno de los desarrolladores tenía su propia configuración y sus preferencias.
¡En mi ordenador funciona!
Esta es una frase que todos hemos usado. Seguramente muchas veces era una mentirijilla que se usa como excusa. Pero era una excusa “con fundamento” porque podía pasar. Al tener cada entorno tan diferente era muy habitual que las cosas funcionasen en un equipo pero no en otro.
Claro, usar un servidor de desarrollo estaba muy bien pero éstos muchas veces eran lentos y en ellos tenías que cargar no solo con tus chapuzas sino con las de los demás. No era raro el día que no funcionaba. Por eso cada uno solía tener su servidor de desarrollo local.
Un parche
Como parche, en algunas empresas se obligaba a todos los desarrolladores a tener el mismo entorno de trabajo. De esta forma se conseguía homogeneizar las cosas y pasar a test o pre-producción era un engorro algo menor.
Dar de alta un nuevo desarrollador era un auténtico calvario. Había que replicar el entorno. ¿Y qué sucedía cuando se modificaba el entorno? Había que actualizar todos los ordenadores.
Más problemas
Con mayor o menor dificultad lo podías conseguir pero ¿qué hacías cuando un desarrollador trabajaba en dos proyectos a la vez? Si los dos entornos eran diferentes y tú eras el administrador de sistemas mejor ibas buscando un nuevo trabajo.
Llegaron las máquinas virtuales
En este momento de gran dolor ¡llegaron las máquinas virtuales! ¡Qué maravilla! Eso si que era fantástico. Bastaba con crear una máquina virtual y enviar una copia a cada desarrollador. No estaba nada mal la solución.
Esta máquina virtual era igual que el servidor así que todo debía funcionar a la perfección. La vida era fantástica.
Limitaciones de las máquinas virtuales
Peeero, también tenía sus problemas. Para empezar, las máquinas virtuales eran muy grandes. Una máquina virtual podía ocupar más de un GB (las había mucho más grandes). Cuando tocaba actualizar había que enviar estos monstruos a cada persona implicada en el desarrollo. Había veces que no se hacían las actualizaciones por la pereza que esto daba.
Por supuesto salieron herramientas estilo Vagrant que, partiendo de una imagen básica, permitía simplemente compartir un fichero que era el que se encargaba de la actualización. Una gran idea.
Sin embargo las máquinas virtuales seguían siendo muy pesadas y, si tenías dos proyectos o alguna aplicación era distribuída ya necesitabas dos máquinas virtuales. Eso consumía muchos recursos y ocupaba mucho espacio en el disco duro.
Llega Docker
Hará unos cuatro años apareció Docker. Yo personalmente me he resistido mucho a usarlo porque estaba un poco cansado de tanta herramienta nueva. Pero fue probarlo y ya no querer nada más. Ahora tan solo tengo Vagrant y Homestead en unos pocos proyectos que ya estaban funcionando y en los que hay otros desarrolladores involucrados que no quieren cambiar.
En el próximo capítulo veremos qué es Docker en más profundidad…