Docker Swarm: crea servicios y entiende el quorum
Docker Swarm incorpora orquestación de servicios en Docker Engine. Puede facilitar una práctica de varios nodos, pero no convierte automáticamente un archivo Compose local en una arquitectura tolerante a fallos.
Utiliza equipos de laboratorio con versiones compatibles y red privada. Revisa los puertos requeridos por Swarm y limítalos a los nodos autorizados.
Managers y trabajadores
Los managers mantienen el estado y requieren quorum. Tener dos managers no ofrece la tolerancia que muchas personas esperan: el diseño debe considerar cuántos pueden perderse conservando mayoría.
Los trabajadores ejecutan tareas según la planificación. Varias réplicas sobre un solo host no protegen frente a la pérdida de ese host.
Inicializa la práctica
En el manager elegido:
docker swarm init --advertise-addr IP_PRIVADA_DEL_MANAGER
docker node lsReemplaza la dirección después de revisar interfaces. La salida puede incluir un token de unión; protégelo. Comparte con cada equipo solo el acceso que corresponda.
Para añadir nodos, utiliza el comando de unión autorizado y verifica su rol. No publiques tokens en repositorios o capturas.
Crea un servicio de prueba
docker service create --name web-lab \
--replicas 2 nginx:stable-alpine
docker service ls
docker service ps web-labEl ejemplo no publica un puerto. Primero comprueba tareas, distribución y salud. Si necesitas exponerlo, revisa el routing mesh y qué nodos aceptarán tráfico según el modo elegido.
Escala y actualiza
docker service scale web-lab=3
docker service ps web-labRevisa recursos disponibles y eventos. Una solicitud de tres réplicas no garantiza que todas puedan ejecutarse.
Al actualizar, define paralelismo, retraso, comprobación de salud y política de fallo según la aplicación. “Zero downtime” no es una propiedad automática de cualquier update.
Stacks y diferencias con Compose
docker stack deploy utiliza el formato y funciones que soporta Swarm. No procesa necesariamente todas las opciones de un Compose moderno de la misma manera.
Las imágenes deben estar disponibles para los nodos. Un build local no garantiza que los trabajadores puedan descargarlas. Revisa nombres, credenciales de registro y arquitectura.
Datos y secretos
Un volumen local pertenece a un nodo. Reubicar una tarea no transporta automáticamente su información. Diseña almacenamiento y respaldo de servicios con estado.
Swarm tiene un mecanismo propio de secretos con garantías distintas de montar un archivo local en Compose. Limita acceso, rota y comprueba qué servicios los consumen.
Retira sin borrar a ciegas
Eliminar un servicio no elimina necesariamente imágenes, volúmenes u otros recursos. Comprueba qué pertenece al laboratorio.
No utilices leave --force en managers como instrucción general de limpieza. Revisa quorum, copia y procedimiento de retirada del clúster.
Preguntas frecuentes
¿Swarm ejecuta exactamente cualquier Compose?
No. Revisa compatibilidad de opciones y comportamiento de docker stack deploy antes de trasladar el archivo.
¿Dos managers toleran perder uno?
La necesidad de mayoría puede impedir esa expectativa. Diseña el número de managers y prueba fallos conforme al quorum.
¿Las réplicas duplican mis datos automáticamente?
No. La persistencia y replicación de la aplicación son decisiones distintas de ejecutar varias tareas.
En pocas palabras
Swarm administra servicios distribuidos, pero disponibilidad depende de nodos, quorum, red y datos. Un servicio con varias réplicas no resuelve por sí solo el almacenamiento compartido.
Conclusión
Prueba fallos y recuperación en una red de laboratorio antes de confiar un servicio. Conserva manifiestos y revisa qué ocurre con datos y puertos al actualizar o retirar.
Para continuar, revisa Docker: qué es y cómo usarlo para ejecutar contenedores y Cómo instalar Docker en Ubuntu 24.04: guía práctica paso a paso.