Aquellos que seguís este blog de forma regular, habréis notado mi predilección por los contenedores docker, en gran parte porque es con lo que trabajo en mi día a día. Hartos de usar la plataforma custom que tenemos en la compañía buscamos una nueva, que simplifique el trabajo que hacemos.
No son pocas las veces que queremos hacer una redirección de algunos de nuestros dominios a otros. Puede que queramos añadir el clásico www delante del dominio, o tal vez queramos forzar el uso de https. Hacer copias de nuestro dominio no es viable, pero podemos usar redirecciones fijas 301.
Usar un cluster de docker swarm no es transparente para nuestro uso; necesitamos cambiar de mentalidad y tener en cuenta algunos conceptos. Donde antes hablábamos de contenedores, aquí se habla de servicios, que básicamente son un número variable de contenedores repartidos por los diferentes nodos del cluster de forma balanceada.
Usar docker en nuestro dia a dia es muy interesante y tiene un montón de aplicaciones prácticas; sin embargo no es la mejor opción confiar en un único servidor en producción. Para tener alta disponibilidad y alto renidmiento podemos montar un cluster, como por ejemplo su implementación oficial, docker swarm.
Normalmente, me gustan los servidores con un número de servicios tirando a mezquino; menos servicios significan menos actualizaciones, menos superficie de ataque y menos recursos ocupados. Sin embargo, hay algunos que son imprescindibles, mientras que otros son altamente recomendables. Este es el caso del NTP, que mantiene la hora actualizada.
Siempre nos han vendido que docker ejecuta un solo proceso, y que este puede ser cualquiera. Sin embargo, este proceso se ejecuta con PID 1, que es un poco especial y que tiene unas responsabilidades adicionales. Si no queremos implementarlas, podemos usar alguna solución que ya lo haga para nosotros.
En el día a día de mi trabajo, me encuentro con un conjunto muy variado de ficheros Dockerfile que vienen a hacer lo mismo, pero de formas muy distintas. El fichero original se pasa de mano en mano, pervirtiéndose en cada paso y al final queda hecho un gran asco.
En mi trabajo se ha decidido por el uso de virtualización por contenedores usando Openshift. No es nada demasiado nuevo, puesto que ya usábamos Docker de manera habitual, pero ha habido alguna feature que nos ha hecho plantearnos el modo en el que hacemos las cosas, especialmente para las escrituras.
Cuando trabajas con procesos en background, es fácil que algunos de los procesos hagan algo que necesite exclusividad, no siendo seguro ejecutar varios de estos procesos a la vez. Por ejemplo, archivos que se descomprimen, se procesan y luego se borran; si usan la misma carpeta suele ser un problema.
Finalmente ha sucedido: ha llegado el esperado lanzamiento de Debian Stretch. Como buen linuxero no me he podido resistir a hacer alguna instalación para probar, aunque solo sea como una máquina virtual. Su función, determinada por mi actual flujo de trabajo, va a ser como servidor de docker con docker-compose.