Implementación de Docker Swarm en Producción: Arquitectura y Gestión
Clase 21 de 24 • Curso de Swarm
Contenido del curso
Primeros pasos
- 6

Instalación de Docker en Mac, Ubuntu y Windows
10:13 min - 7

Cómo iniciar Docker Swarm en tu máquina
08:35 min - 8

Creando servicios en Docker Swarm
05:36 min - 9

Cómo funciona docker service ps internamente
11:09 min - 10

Qué es Play with Docker para practicar
06:27 min - 11

Creando un Docker Swarm multinodo real
06:15 min
Administrando Servicios
Swarm avanzado
- 15

Cómo Docker Swarm enruta tráfico sin perder peticiones
06:56 min - 16

Docker Swarm constraints: dónde correr cada tarea
09:04 min - 17

Cómo drenar nodos en Docker Swarm sin downtime
07:56 min - 18

Redes Overlay en Docker Swarm: Comunicación entre Servicios
13:39 min - 19

Docker Stack: automatiza despliegues multinodo
10:49 min - 20

Implementación de Reverse Proxy con Traefik en Docker Swarm
16:49 min
Swarm productivo
Conclusiones
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.