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.
Usar autenticación en las bases de datos de nuestros entornos, por muy privados que sean, suele ser una buena idea. Nos sirve para separar los accesos a un servicio compartido y evitar sobreescrituras cuando accidentalmente dos servicios usan la misma base de datos por un error de algún usuario despistado.
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.
En algunas ocasiones no nos basta con tener un servidor único. Queremos tener un conjunto de servidores que se comuniquen abiertamente entre ellos usando una red privada, pero solo queremos exponer al mundo una sola dirección IP. El resto de servidores necesitan acceso a internet a través de un representante.
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.
Configurar servidores desde cero es una tarea muy pesada, una fuente de errores innecesaria y hace nuestros servidores difícilmente reproducibles. Los setups más básicos son siempre los mismos, y podemos configurar nuestros servidores para que ejecuten un script la primera vez que se (re)inicien, a falta de mejores herramientas.
Cuando trabajamos con tamaños de disco muy limitados, como por ejemplo en dispositivos embedded o pendrives, nos vemos obligados a reducir nuestros sistemas de ficheros. Algunos de estos sistemas de ficheros son de solo lectura, y vienen comprimidos, lo que nos permite ahorrar en espacio de disco, no en funcionalidades.
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.
Cada vez que trabajo en un cliente me pasa lo mismo; las claves de acceso y las contraseñas de las diferentes herramientas y de los diferentes servidores están guardadas de forma caótica e inaccesible. Puesto que trabajamos en un equipo distribuido, me gusta tener esto publicado en remoto pero seguro.
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.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 » »»