5.2Swarm exprés : clúster, stack y réplicas
Lo esencial en 30 segundos
- Iniciar en un comando : la máquina local se vuelve manager, las demás se unen como workers — incluso en mono-nodo, Swarm aporta réplicas y actualizaciones sin corte.
- Desplegar el stack : el archivo Compose ampliado (deploy : replicas, update_config, restart_policy) se despliega en el clúster — las réplicas se reparten, la actualización pasa una por una.
- Ver y escalar : listar servicios y réplicas, ajustar el número, dejar que Swarm sustituya las réplicas de un nodo muerto — con un healthcheck obligatorio para una actualización limpia.
Mini-caso hilado — Idir monta su primer clúster
Idir, devops junior en Alger, pasa a la práctica : su app pronto deberá correr en dos máquinas. Primero se entrena en mono-nodo : inicia Swarm en su máquina, añade deploy (3 réplicas, actualización una por una) a su servicio web, despliega el stack y lista las réplicas. Luego escala a 5 y a 2 y observa el reparto. Continuación del caso 5.1 — Idir pasa de la auditoría de la necesidad al primer clúster replicado.
Continuación del caso 5.1 — Idir se entrena en mono-nodo antes de todo multi-máquina.
1. Iniciar en un comando
docker swarm init hace de la máquina local un manager (el piloto) ; docker swarm join le adjunta workers (los ejecutantes) con el token proporcionado. Idir empieza solo : incluso en una sola máquina, Swarm ya aporta réplicas y rolling updates — el terreno de entrenamiento ideal antes del multi-máquina.
En desarrollo mono-nodo, se piensa en salir limpiamente (docker swarm leave) para volver a un Docker sencillo. La regla de Idir : dominar el mono-nodo antes de añadir máquinas.
2. Desplegar el stack : el Compose ampliado
docker stack deploy -c compose.yml monapp despliega el Compose en el clúster, con la sección deploy : replicas: 3, update_config (actualización una por una con retardo), restart_policy. Las réplicas se reparten en los nodos, la actualización sustituye las réplicas una por una : cero corte si el healthcheck es bueno. Idir añade estas tres claves a su servicio web.
El healthcheck es la condición de la actualización limpia : Swarm solo promueve una nueva réplica si está probado que está lista. Sin healthcheck, se escala y se actualiza a ciegas — cortes garantizados.
3. Ver y escalar
docker service ls lista los servicios, docker service ps muestra el estado de cada réplica (dónde, qué, desde cuándo), docker service scale ajusta el número. Idir escala a 5 y a 2 y observa el reparto. Si muere un nodo, Swarm reemplaza las réplicas en otro lado : es la autorreparación prometida.
Trampa n.º 1 del multi-nodo : los volúmenes locales no viajan — un volumen local se queda en su nodo. Hacen falta almacenamiento compartido o bases externas, si no los datos faltan según el nodo que responde.
🔎 Ejemplo concreto — La web de Idir en 3 réplicas sin corte
Iniciar, desplegar, observar, escalar.
docker swarm init
docker stack deploy -c compose.yml monapp
docker service ls
docker service ps monapp_web
docker service scale monapp_web=5Lectura : 3 réplicas al inicio, actualización una por una, luego paso a 5.
Lección : durante el update, el servicio siempre responde gracias a las réplicas.
Vocabulario de la sección
- Manager / worker
- El manager pilota el clúster, los workers ejecutan las réplicas.
Ejemplo sencillo: Idir inicia su máquina en manager antes de adjuntarle workers.
Lo que no es: máquinas aisladas sin piloto común.
Reflejo: ¿quién pilota, quién ejecuta en mi clúster?
- Stack
- El archivo Compose desplegado en el clúster con su sección deploy.
Ejemplo sencillo: Idir despliega monapp con replicas y update_config.
Lo que no es: un simple compose sin deploy lanzado en una máquina.
Reflejo: ¿mi sección deploy está escrita?
- Réplica
- Un ejemplar de un servicio, repartido en los nodos.
Ejemplo sencillo: Idir ejecuta 3 réplicas de su web.
Lo que no es: un contenedor único sin doblaje.
Reflejo: ¿cuántos ejemplares corren ahora mismo?
- Scale
- Ajustar el número de réplicas de un servicio según la demanda.
Ejemplo sencillo: Idir pasa de 3 a 5 réplicas y luego baja a 2.
Lo que no es: relanzar toda la app para cambiar de capacidad.
Reflejo: ¿puedo ajustar la vela sin corte?
- Healthcheck
- La sonda que prueba que una réplica está lista antes de promoverla.
Ejemplo sencillo: Idir solo autoriza la actualización en réplica probada lista.
Lo que no es: una actualización a ciegas sin sonda.
Reflejo: ¿cada servicio duradero tiene su sonda?
En la práctica — Su primer clúster
- Inicie Swarm en su máquina (init).
- Añada deploy (3 réplicas + actualización una por una) a su servicio web.
- Despliegue el stack y liste servicios y réplicas.
- Escale a 5 y a 2 : observe el reparto.
Guion listo para decir — anunciar el primer clúster al equipo
«Monto nuestro primer clúster Swarm en Alger : primero en mono-nodo para entrenarnos — 3 réplicas, actualización una por una, healthcheck obligatorio — luego añadiremos las máquinas. Les mostraré el reparto de las réplicas y la actualización sin corte antes de todo multi-nodo real.»
Para decir al equipo para enmarcar el entrenamiento mono-nodo antes del multi-máquina.
Modelo copiar-pegar — stack Swarm genérico
STACK SWARM GENÉRICO — archivo compose.yml
services:
web:
image: mon-registre/mon-app:stable
ports:
- "8080:80"
healthcheck:
test: ["CMD", "wget", "--spider", "-q", "http://localhost/"]
interval: 30s
timeout: 5s
retries: 3
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
restart_policy:
condition: on-failure
COMANDOS : docker swarm init · docker stack deploy -c compose.yml monapp · docker service ls · docker service ps monapp_web · docker service scale monapp_web=5Solo / presupuesto reducido
Idir solo : un clúster mono-nodo basta para aprender réplicas y actualizaciones.
TPE / equipo reducido
Demo de a dos : uno despliega, el otro observa las réplicas durante la actualización.
PYME en Alger
Idir fija en Alger un hueco sandbox : init, deploy y scale sin tocar la prod.
Equipo que empieza
Binomio : uno escribe la sección deploy, el otro verifica healthcheck y reparto.
✓ Buenas prácticas
- Pruebe en mono-nodo antes de todo multi-máquina.
- Healthcheck obligatorio en cada servicio duradero.
- Actualizaciones una por una (paralelismo a 1).
✗ Errores frecuentes
- Volúmenes locales no compartidos entre nodos (datos faltantes).
- Escalar sin healthcheck (cortes durante el update).
- Olvidar salir de Swarm en dev tras el entrenamiento.
Puntos clave
- Init = manager, join = workers — incluso en mono-nodo para entrenarse.
- Deploy añade réplicas, actualización una por una y política de reinicio.
- Scale ajusta el número, Swarm sustituye las réplicas de un nodo muerto.
- Healthcheck = actualización sin corte ; volúmenes locales = trampa n.º 1.
Reto 48h — aplique mañana
Despliegue en mono-nodo un stack con 3 réplicas + healthcheck : liste las réplicas, escale a 5 y a 2, y anote el reparto observado.
- Puedo iniciar Swarm y desplegar un stack replicado.
- Mis servicios tienen deploy + healthcheck.
- Sé por qué los volúmenes locales bloquean el multi-nodo.
Preguntas frecuentes
¿Los volúmenes siguen en Swarm?
No por defecto : un volumen local se queda en su nodo, no viaja con las réplicas. En multi-nodo, prevea almacenamiento compartido o bases externas — es la trampa n.º 1 del paso al clúster. Pruebe siempre dónde viven sus datos antes de escalar.
¿Cómo salir de Swarm tras el entrenamiento?
Con el comando de salida en el nodo (salir, en fuerza si hace falta en un manager). En dev mono-nodo, piense en salir para volver a un Docker sencillo una vez terminado el ejercicio.
Para una actualización Swarm sin corte, ¿qué hace falta?