Arquitectura con Docker Swarm

Estoy en el proceso de deployar un cluster de Docker Swarm en producción y estas son algunas de mis ideas de cómo las cosas deberían estar. En mi caso el deploy es en AWS pero estoy esquivando intencionalmente todas las partes que sean específicas a AWS en este artículo.

Lo básico

Un swarm consiste en managers, nodos y servicios.
Un nodo es basicamente un worker de tu swarm, solo recibirá instrucciones.
Un manager es un nodo que puede dar instrucciones a tu swarm (por ejemplo crear o remover servicios). Los managers también pueden ejecutar instancias de servicios.

Un servicio puede tener múltipes replicas y Docker las distribuirá entre tus nodos - si tenés 3 nodos (activos) y un servicio con 3 replicas, cada nodo tendrá una instancia de ese servicio.

Para cada servicio en el swarm, Docker hará un round-robin entre las replicas (mirá Load balancing is impossible). Docker llama a la funcionalidad de distribuir conexiones entrantes de afuera del swarm ingress load balancing. Es importante notar que si accedés a un servicio desde dentro del swarm también va a pasar por el distribuidor de carga incorporado.

Si intentás acceder a un servicio en un nodo que no lo está ejecutando, Docker va a re-rutear la petición a un nodo que tenga una instancia de ese servicio ejecutándose.

En la ilustración anterior el componente LB sirve como un reverse proxy y necesitará ser capaz de descubrir nuevos nodos en tu swarm dinámicamente.

Redes

Para mi configuración básica creé una red overlay encriptada para - inicialmente - todos mis servicios.

1	docker network create --driver overlay --subnet 10.0.9.0/24 --opt encrypted my-network

Por supuesto que podés crear redes específicas para grupos de servicios pero eso dependerá de tus requerimientos y casos de uso.

Comunicación entre servicios

Por defecto Docker Swarm configura un service discovery de forma que podrás acceder de un servicio a otro a través del nombre si ambos comparten la misma red.

Registro

En mi caso, configuré un registro privado para servir mis imágenes de Docker (leé Configurando un Docker Registry local). Ya que no va a ser público y solamente lo necesito acceder dentro de la red virtual donde se encuentran mis instancias no veo ninguna razón por la cual debería configurarlo con TLS (lo que la documentación recomienda).

Grupos de autoscalling

Es muy importante tener redundancia de managers en tu swarm ya que si tenés solo un manager y algo va mal, vas a perder el swarm entero. Segundo, es importante tener un número impar de managers por la naturaleza del algoritmo que Swarm usa para elegir el lider (podés leer más en esta sección). Adicionalmente también deberías hacer un backup del estado del swarm rutinario.

Idealmente vas a contar con dos grupos de autoscalling, uno para tus managers y otro para tus nodos.

Para clusteres pequeños no veo ningún inconveniente en dejar que los managers ejecuten instancias de los servicios pero en clusteres más grandes deberías tener managers dedicados - mirá cómo hacerlo acá.

Conclusión

Este artículo se enfoca en decisiones de arquitectura pero definitivamente los procesos de desarrollo y deployment son otras dos partes muy importantes que faltan. Tal vez escriba acerca de eso una vez que esté más familiarizado.

Si configuraste tu swarm de una manera diferente o no estoy mencionando algunas funcionalidades importantes contame en los comentarios!