El otro día estaba revisando viejos artículos, y me tropecé con uno anterior. Este estaba montado con ansible, y se me pasó por la cabeza reescribirlo usando contenedores con docker. Así pues, vamos a montar exactamente el mismo cluster, pero con el cambio que la última revolución tecnológica nos aporta.
Hace poco he cambiado de trabajo por motivos personales. En mi nueva posición me he encontrado con un cambio en las tecnologías usadas; lo que me he encontrado es algo que hacía tiempo que no tocaba: basan sus sistemas en Java y Tomcat. He necesitado un ligero reciclaje en ellos.
Los servidores de git son muy útiles, pero si solo lo accedemos mediante terminal, se quedan limitados a pocos usuarios avanzados. Sin embargo, las soluciones con interfaz web, como GitHub llegan a todo tipo de usuarios. En un intento de abaratar costes, se han hecho varios clones, entre ellos, Gitea.
Aquellos que leéis mis artículos habitualmente ya sabéis lo que es un balanceador de carga, especialmente los de peticiones HTTP; en especial conocemos nginx y haproxy. La parte mala de estos servicios es que la configuración es estática e inmutable, y en un mundo cloud, eso no es lo ideal.
Ya vimos que consul nos permitía mantener una foto del estado de nuestros servidores y de los servicios que corren en ellos. Es todavía más importante cuando contamos con varios servidores, y todos declaran sus partes a un servidor central, de forma que tenemos una foto global de la situación.
He visto muchos artículos por internet que hacen maravillas para tener un cluster de Docker Swarm funcional. Puede que en versiones anteriores fuera así, pero cada vez se ha simplificado más el setup para alinearse con la filosofía de la simplicidad, frente a otras soluciones más completas, pero más complejas.
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.
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.