Gestión de actualizaciones y fallos en Docker Swarm

Contenido del curso

Conceptos básicos

Primeros pasos

Administrando Servicios

Swarm avanzado

Swarm productivo

Conclusiones

24
Escalabilidad con Docker Swarm: listo para millones
00:52 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0018:32

Gestión de actualizaciones y fallos en Docker Swarm

Curso de Swarm

Clase 13 de 24

Clase 13 / 24

Recursos

Controla despliegues en Docker Swarm con confianza: aprende a escalar réplicas, acelerar updates masivos con parallelism y order, y activar rollback automático ante fallos. Mantén el uptime alto incluso en escenarios de alta demanda y CI/CD.

¿Cómo escalar un servicio y simular alta demanda en Docker Swarm?

Al trabajar con servicios críticos, necesitas garantizar que la aplicación no caiga durante cambios frecuentes. Con un servicio como Pinger, puedes simular carga y validar comportamiento en producción sin escribir código nuevo.

Escalar réplicas para alta demanda.
Actualizar argumentos para simular una nueva versión.
Observar tareas para verificar rotaciones.

¿Qué comando usar para cambiar réplicas?

En lugar de usar scale, puedes actualizar el servicio directamente con update y ajustar réplicas:

docker service update --replicas 20 pinger

Útil cuando automatizas despliegues y no necesitas ver el output en vivo. Con el modo desacoplado (-d en docker run o docker compose up -d), el control vuelve de inmediato al proceso que orquesta.

¿Cómo validar el estado de las tareas?

Consulta las tareas del servicio y verifica la rotación:

docker service ps pinger

Úsalo tras updates para confirmar que cada tarea alcanzó el estado deseado.

¿Qué es update config y cómo acelerar un despliegue?

La especificación del servicio define cómo se actualiza. Con docker service inspect verás update_config, que controla la estrategia de rotación de tareas.

parallelism: cuántas tareas se actualizan al mismo tiempo.
order: define si usar stop-first o start-first.
- stop-first: detiene la tarea vieja antes de crear la nueva.
- start-first: crea la nueva y luego elimina la vieja. Permite overprovisioning temporal para evitar pérdida de capacidad.

Acelera el despliegue incrementando el parallelism y usando start-first en escenarios productivos:

docker service update \
  --update-parallelism 4 \
  --update-order start-first \
  pinger

Simula una nueva versión cambiando los argumentos del contenedor:

docker service update --args "ping facebook.com" pinger

Con parallelism 4 verás rotaciones por lotes, mucho más rápidas que de a una.
Con start-first mantienes capacidad mientras validas que las nuevas tareas levantan correctamente.

¿Cómo proteger producción con rollback automático ante fallos?

En updates reales, algunos cambios pueden fallar. Swarm te permite definir qué hacer si una tarea nueva no arranca.

failure-action: decide el comportamiento ante fallos: pause, continue o rollback.
monitor: ventana de tiempo para considerar que una tarea arrancó bien. Está expresada en nanosegundos; ajusta el valor si tu servidor tarda varios segundos en iniciar.
max-failure-ratio: porcentaje de fallos permitido antes de activar la acción definida.
rollback_config: misma lógica que update_config, pero aplicada al proceso de rollback.

¿Cómo activar rollback automático y definir el umbral de fallo?

Configura el rollback cuando falle al menos el 50 % de las tareas durante el update:

docker service update \
  --update-failure-action rollback \
  --update-max-failure-ratio 0.5 \
  pinger

Si más del 50 % de las tareas nuevas no llega a “ready”, Swarm revierte automáticamente.
Ajusta --update-monitor <duración> si tu app necesita más tiempo de arranque.

¿Cómo acelerar el retorno al estado estable?

Si estás en emergencia y necesitas volver “todo de golpe”, ajusta el rollback para hacerlo sin lotes:

docker service update --rollback-parallelism 0 pinger

Paralelismo 0 en rollback indica revertir sin particionar. Útil cuando la app ya está caída y priorizas restaurar capacidad.
Con start-first, el rollback puede ser inmediato: si las nuevas tareas fallan en arrancar, basta con borrar esas tareas nuevas; no hace falta recrear las viejas.

Para provocar y observar la reversión automática, lanza un update con argumentos que sabes que fallarán y verifica cómo Swarm revierte al estado anterior en cuanto el umbral supera el max-failure-ratio.

Habilidades y conceptos aplicados: configuración de update_config y rollback_config. Gestión de parallelism, order (start-first, stop-first). Control de failure-action, monitor y max-failure-ratio. Prácticas orientadas a CI/CD y alta disponibilidad.

¿Tienes una estrategia favorita para combinar start-first con max-failure-ratio sin sacrificar capacidad? Comparte tu enfoque y cuéntanos qué métricas observas al desplegar en producción.

Emanuel Alejandro Mamani

Hace 7 años

tengo una duda, habias puesto de ejemplo real de si el servidor normalmente tarda 5 segundos en arrancar y detecta que ya pasó ese tiempo entonces se produce el error y swarm automaticamente hace el rollback, ahora bien como hacemos para que swarm haga esto mismo pero con errores de codigo que no afectan de manera directa como por ej: dar un error 500 o tirar el server abajo, si no que daña el flujo interno al solo ser error de codigo, te doy un ejemplo, no poder conectarse a mysql desde php, hay maneras de hacer un catch de ese tipo de errores y asi podemos tambien hacer que swarm se adapte a nuestro contexto de errores?

Anthony Farias

Hace 7 años

Creo que no hay forma, pero igual eso que dices está muy mal hecho. Para eso tienes que tener ambientes de prueba donde antes de deployar en produccion tienes que testear tu codigo, y para eso mismo tambien es docker, una vez testeas el codigo, y corras la imagen, esa misma te va a servir en produccion, porque las imagenes de docker corren en cualquier parte sin problemas, entonces a produccion deberia ser muy dificil que llegue un bug de ese estilo.

Gonzalo Amador Hernández

Hace 6 años

Las cuestiones que mencionas no deberian ser tratadas por Swarm, tu aplicacion debe estar configurada para arrogar el error sino pudo conectarse a base de datos. debes hacer que tu aplicacion no se llevante hasta que tenga TODO listo.

Lo normal es que tu app lo intente un cierto numero de veces, sino lo logra entonces no arranca y DEBE salir con un error, y es cuando Swarm entra en accion. O simplemente confiras el "timeout" de Swarm para que estere que tu aplicacion arranque.

En resumen tu app jamas deberia levantarse hasta que este lista y tambien deberia salir con codigo de error para que swarm sepa que fallo.

Comentarios (24)24 comentarios

Estuardo Efraín Ramos Castro

Ariel Ayala

Hace 8 años

Nestor Julian Murphy

Esteban Martini

DAVID EDUARDO BAEZ SANCHEZ

Matías Daniel Cravero

Hace 5 años

Iván Céspedes

Hace 4 años

Boris Vargas Paucara

Wilson Fernando Antury Torres

German Tellez Vanegas

Jean Frannlee Rodriguez Tapiero

Hace 2 años

Pablo Aquino

Camilo Andrés Mejía Posada

Nicolás Mayorga Vargas

Carlos Enrique Ramírez Flores

Gustavo Saldivia

Andres Esteban Garcia Pacheco

Hace 8 meses

Yohan Estiven Arias Vasquez

Guido Vilariño

Profesor

Luis Troya

Conceptos básicos

Docker Swarm sin gastar dinero en la nube

Escalando Docker con Docker Swarm

Por qué Docker Swarm es esencial para producción

Arquitectura de Docker Swarm: managers y workers

Los 12 factores para aplicaciones en Docker Swarm

Primeros pasos

Instalación de Docker en Mac, Ubuntu y Windows

Cómo iniciar Docker Swarm en tu máquina

Creando servicios en Docker Swarm

Cómo funciona docker service ps internamente

Qué es Play with Docker para practicar

Creando un Docker Swarm multinodo real

Administrando Servicios

Docker Swarm: escalado y rolling updates

Gestión de actualizaciones y fallos en Docker Swarm

Cómo exponer servicios Docker Swarm

Swarm avanzado

Cómo Docker Swarm enruta tráfico sin perder peticiones

Docker Swarm constraints: dónde correr cada tarea

Cómo drenar nodos en Docker Swarm sin downtime

Redes Overlay en Docker Swarm: Comunicación entre Servicios

Docker Stack: automatiza despliegues multinodo

Implementación de Reverse Proxy con Traefik en Docker Swarm

Swarm productivo

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

Administración de Swarm con Portainer: Gestión y Despliegue

Optimización de Swarm: Mantenimiento, Logs y Monitoreo Avanzado

Conclusiones

Escalabilidad con Docker Swarm: listo para millones

Gestión de actualizaciones y fallos en Docker Swarm

Progreso del curso

Conceptos básicos

Primeros pasos

Administrando Servicios

Swarm avanzado

Swarm productivo

Conclusiones

Recursos

Recursos