Continuamos la serie enfocada a construir un entorno entero basado en docker swarm siguiendo desde el punto en que lo dejamos: con los servidores a punto y el cluster en marcha. Ahora vamos a poner en marcha un cluster de base de datos en el mismo swarm que, por ejemplo, va a ser un replica set de mongodb.
Continuamos con esta serie de artículos con la finalidad de crear un entorno dockerizado completo. Vamos a ir creando la infraestructura necesaria para alojar nuestro cluster de docker swarm. Esto implica crear una red privada, un gateway para esconderla, y finalmente ataremos el cluster de docker swarm.
Trabajando con Docker Swarm me doy cuenta de que hay muchos servicios tipo “ventanilla única” que suelo poner en los mismos managers. El asunto es que un despliegue con Docker Swarm funciona mejor con un número impar de managers, siendo 3 o 5 lo recomendable para un entorno de producción.
Tras probar algunos servicios pensados para la nube o para contenedores, veo que algunos de ellos dependen de una pieza central llamada zookeeper. Como soy una persona curiosa, he decidido dedicar un artículo a entender como funciona este servicio, que se limita a guardar cosas de forma distribuida y redundante.
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.
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.
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.
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.