Como ya sabéis, la tecnología docker me encanta; seguía con mi cruzada para dockerizar todos mis sistemas, cuando me topé con un artículo antiguo. En este artículo os contaré los problemas con los que me enfrenté en esta tarea y como los pude superar, explicando lo aprendido en el proceso.
Algunas veces nos hemos encontrado que necesitamos ejecutar dos procesos o más para un servicio, aunque uno de ellos es el servicio principal y el otro se limita a ayudar al otro de alguna manera. Mejor que ponerlos en el mismo contenedor, podemos limitarnos a usar el patrón sidekick containers.
Cuando usamos herramientas concretas para todos los miembros de un mismo equipo, suele ser problemático instalarlo en sus equipos. Por la ausencia de instalación y su gran reproducibilidad, es cada vez más frecuente distribuir esas herramientas en una imagen de Docker, aunque esto no garantiza estar libres de otros problemas.
Ya vimos en un artículo anterior como delegar en SystemD la persistencia de túneles SSH. El otro día intenté reproducirlo sin éxito en un servidor con una versión baja de SystemD; finalmente me di cuenta de que había otra herramienta en el servidor capaz de reiniciar un túnel caído: Docker.
Algunas veces queremos probar nuestras aplicaciones en local y necesitamos una base de datos MongoDB; en estos casos, Docker nos presta un gran servicio. Es posible que en estos casos necesitemos un replica set para probar; aunque Docker sigue ayudando, la inicialización del cluster sigue siendo un tedioso proceso manual.
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.
A veces nos encontramos en un ordenador que no tenemos preparado para usar nuestras aplicaciones habituales, o simplemente no es el nuestro, o no queremos ensuciarlo para probar aplicaciones nuevas. Si disponemos de docker, es posible ejecutarlas compartiendo solamente el unix socket del servidor gráfico para verlas en nuestra pantalla.
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.
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.