Implementación de Docker Swarm en Producción: Arquitectura y Gestión

Clase 21 de 24Curso de Swarm

Resumen

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:

docker node ls

¿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:

docker service 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.

      Implementación de Docker Swarm en Producción: Arquitectura y Gestión