Llevar Docker Swarm a producción exige decisiones claras sobre alta disponibilidad, escalado y distribución de carga. Aquí verás por qué usar managers impares, cómo opera el algoritmo Raft, y cómo crear grupos de workers con etiquetas para ajustar el hardware a cada tipo de tarea, manteniendo costos bajo control y respuestas en tiempo real cuando hace falta.
¿Cómo asegurar alta disponibilidad en Docker Swarm?
Para que el cluster sea estable, los managers deben ser impares y con baja carga. Solo uno actúa como líder y decide sobre uniones de nodos, creación de servicios y planificación de tareas. Los demás replican su estado.
Un solo líder evita conflictos de autoridad. El resto acompaña.
La elección de líder rota periódicamente mediante Raft.
En producción, usa al menos tres managers. Cinco o siete si la escala lo demanda.
Mantén los managers con poca carga: su prioridad es el control del swarm.
Si cae un manager, el liderazgo pasa a otro de forma automática. La Ingress Network y los contenedores siguen funcionando, pero no podrás escalar ni replanificar hasta recuperar liderazgo.
¿Por qué managers impares y líder único?
Para eliminar empates en la votación de líderes. Raft coordina la elección por consenso: quien reúne más votos es el líder hasta el siguiente periodo.
¿Qué pasa si cae un manager?
El cluster entra en un modo de espera y otro manager asume. Cuando el nodo regresa, el algoritmo recupera el consenso. Así se conserva la disponibilidad del plano de datos y del routing.
¿Cómo verificar el estado de liderazgo?
Puedes inspeccionar el rol de cada nodo con:
dockernodels
¿Cómo diseñar pools de workers y etiquetas?
No todos los workers deben ser iguales. Se pueden crear grupos diferenciados por tipo de hardware y etiquetarlos con labels para desplegar servicios según sus necesidades de CPU y RAM.
Define pools por carga: asincrónica, real time, procesamiento intensivo, IO, etc.
Usa labels para orientar el scheduler a los nodos correctos.
Escala cada pool de forma independiente según la demanda.
Ajusta el número de máquinas para ahorrar costos cuando baje la carga.
¿Cómo usar labels y escalado por servicio?
El despliegue se realiza apuntando cada servicio al pool adecuado. El escalado ocurre por servicio, sin mover manualmente contenedores:
dockerservice scale NOMBRE_SERVICIO=RÉPLICAS
¿Qué redes conviene usar?
Todas las máquinas viven en la misma virtual network del proveedor. La comunicación entre servicios se aísla con redes de Docker, no redes físicas.
¿Qué balanceadores intervienen?
Las peticiones entran desde Internet a través de un load balancer de hardware del proveedor de nube y llegan al swarm, que enruta a los servicios activos.
¿Qué arquitectura productiva ilustra el caso de MURAL?
El ejemplo describe un único swarm con managers impares y varios pools de workers optimizados por carga. Se atienden picos con autoscaling groups o scale sets y se ajustan costos reduciendo nodos cuando baja el tráfico.
¿Cómo se generan thumbnails con navegador headless?
Cada cambio en un mural dispara un mensaje en una cola. Un proceso en el swarm lo consume, abre un navegador headless, realiza el rasterizing del mural y guarda el thumbnail. Esta tarea requiere mucha RAM y no es estrictamente en tiempo real, por lo que se ejecuta en un pool etiquetado, por ejemplo, como “rasterizers”.
¿Qué cargas requieren CPU vs RAM?
Rasterizing de murales: alta memoria para procesar bitmaps. La latencia de segundos es aceptable.
Reescalado de íconos e imágenes en tiempo real: alta CPU y respuesta inmediata. Muchas imágenes pequeñas, procesadas muy rápido.
Tareas ligeras (emails, notificaciones): baja prioridad de recursos.
¿Cómo se escala y se controla el costo en la nube?
Agrega o quita nodos en cada pool según la demanda del momento.
Mantén separados los servicios real time de los asincrónicos para evitar que compitan por CPU.
Ajusta el tamaño y número de máquinas por tipo de carga para evitar sobrecosto y garantizar rendimiento.
¿Quieres que revisemos tu diseño de pools, labels y escalado en Swarm? Cuéntame tu contexto y dudas en los comentarios.
Podemos configurar grupos de workers según la necesidad de computo.
El número de manager debe ser impar. Hay un único líder, y se rotan el liderazgo en un intervalo de tiempo
Hola! esta muy bueno poder tener maquinas con hardware diferente para necesidades diferentes, pero entonces como le digo al contenedor que corra es ese tipo de maquina? con labels?
en entornos de cluster no creo que se maneje el concepto de "necesidades diferentes" ya que es un escenario enfocado a una misma necesidad.
-Para que Docker Swarm funcione (utilizando buenas practicas), tiene que haber un número impar de Managers.
-En la arquitectura de Swarm debe haber un Nodo Manager Leader que toma la decisión final (creación, asignación, destrucción, tareas, servicios, etc.) y los otros replican lo que dice el líder.
-Cada cierto tiempo se rota el Status Leader entre los nodos Managers utilizando un algoritmo: [Raft] Utilizado en Clustering.
Cada worker lo tenes con un server fisico?
asi un worker es un nodo y efectivamente, es una instancia (ya sea un server on-premises, una rasp quizas o mas comunmente una histancia EC2 de AWS)
Pero todos en la misma red VPC network
Estoy preparando mi ambiente productivo de swarm integrado con el CI de gitlab y tengo un problema que no logro resolver, detuve el stack de forma manual y luego arranque otro antes de se eliminaran todos los task del anterior ahora tengo unos contenedores zombi corriendo que no encuentro forma de eliminarlo, agradesco cualquier comentario.
Saludos,
Que estas usando para el swarm? maquinas virtuales, Docker in docker, instancias en amazon o google, o tu propia maquina?
De ser asi has un docker stop id, docker rm id, o trata de borrar las imagenes y trata de hacer un kill a esos procesos desde el sistema operativo.
Encuentra dónde (en qué host) están corriendo tus contenedores zombis, accede a ellos y elimínalos con docker rm -f <container_id>
Muy interesante los concejos de los ambientes productivos.
El número de managers tiene que ser impar, el mínimo recomendable es 3. Los estados del nodo son tres: Leader, candidate and follower.
¿Qué pasa si por alguna razón se va la luz en el nodo 1 manager (de 3 nodos manager y 2 workers)? Si tengo un frontend en React por ejemplo, ¿Cómo hago para que la petición se haga a otro nodo automáticamente en caso de que se apague un nodo manager al que le estoy apuntando?
Deberías correr tu frontend de react en un nodo worker, no en un nodo manager
Al momento que asginas las replicas a un servicio al momento de crearlo:
docker service create ...--replicas=3
o cuando se escala:
docker service scale <service>=5
Docker swarm automáticamente distribuye las peticiones entre todos las tareas asociadas a ese servicio (como en la clase que se hizo el ejemplo del hostname con curl, en cada petición se respondían hostname diferentes). Esto es el balanceador de carga que viene por defecto en la arquitectura de Docker Swarm.
