Docker Swarm constraints: dónde correr cada tarea
Clase 16 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
Viendo ahora - 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
Controla con precisión dónde corren tus servicios en Docker Swarm para proteger a los managers y mantener el clúster estable. Aquí verás cómo usar constraints, montar el docker socket y desplegar una interfaz web de visualización para entender, de un vistazo, la distribución de tareas. Todo con comandos claros y foco en disponibilidad.
¿Por qué decidir dónde corren las tareas en Docker Swarm?
En un entorno productivo, ubicar las tareas en los nodos correctos es crítico. Los managers realizan tareas administrativas invisibles que sostienen el swarm; si reciben cargas pesadas, pueden desestabilizarlo.
- Evita ejecutar contenedores que consumen mucha RAM en managers.
- Define explícitamente dónde corre cada tarea con constraints.
- Usa una interfaz web para ver en qué nodo corre cada tarea.
- Si una tarea necesita acceder al estado del swarm, debe correr en un manager.
¿Cómo desplegar Visualizer con constraint y bind mount?
La herramienta de visualización es una interfaz web que muestra el estado del swarm. Para funcionar, necesita: 1) correr en un manager y 2) comunicarse con el docker daemon a través del socket.
docker service create \
-d \
--name vis \
-p 8080:8080 \
--constraint 'node.role==manager' \
--mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
dockersamples/visualizer
- -d: modo detached.
- --name vis: nombre del servicio.
- -p 8080:8080: publica la interfaz web.
- --constraint 'node.role==manager': garantiza acceso a la data del swarm.
- --mount type=bind,...: monta el socket del docker daemon desde el host.
¿Cómo validar el estado del servicio?
- Consulta el progreso y estados como preparing, starting y running.
docker service ps vis
- Cuando esté en running, accede al puerto 8080: verás las tareas distribuidas de tu app y del propio Visualizer.
¿Cómo migrar servicios a workers con constraint y actualización?
Para que la aplicación corra solo en workers, agrega una restricción al servicio existente. Además, puedes ajustar la actualización para no ir uno por uno y acelerar el cambio de estado.
docker service update \
--constraint-add 'node.role==worker' \
app
- --constraint-add: obliga a que las nuevas y actuales tareas cumplan la condición.
- Ajusta el parámetro de update a 0 para sobreescribir el paralelismo por defecto si deseas acelerar la transición.
¿Qué efecto tiene en el replanificado?
- Docker Swarm detecta tareas que ya no cumplen el constraint y las replanifica automáticamente a workers.
- Visualizer muestra cómo se eliminan tareas de managers y se crean en workers.
- Resultado: redistribuyes la carga desde managers a workers con un solo cambio declarativo.
¿Tienes una estrategia para distribuir cargas entre managers y workers? Comparte tus prácticas y dudas en los comentarios.