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

Domina cómo Docker Swarm enruta tráfico a tus servicios con routing mesh e Ingress network para escalar sin choques de puertos. Verás por qué una petición al puerto publicado siempre encuentra un contenedor, incluso cuando el nodo que recibe el request no tiene tareas locales.

¿Qué es el routing mesh y cómo evita perder peticiones?

El routing mesh es la pieza que garantiza que una petición HTTP a un puerto publicado llegue a un contenedor disponible. En cualquier nodo del swarm, el flujo es claro: si hay una tarea escuchando localmente, procesa. Si no, el routing mesh captura la petición y la deriva a otro nodo que sí tiene una tarea para ese puerto. Así, no se pierden requests aunque tengas menos contenedores que nodos.

• Arquitectura flexible: managers y workers, en cualquier cantidad.
• En cualquier nodo: se verifica el puerto publicado y se redirige si es necesario.
• Beneficio clave: alta disponibilidad del servicio en el puerto.

¿Cómo verifica Swarm el puerto publicado?

• Revisa si el nodo receptor tiene una tarea escuchando en ese puerto.
• Si no, el routing mesh busca otro nodo con una réplica activa.
• Redirige la petición a ese nodo para su procesamiento.

¿Qué papel cumple la Ingress network?

• Los puertos no se “bindean” al host como en docker run con port binding.
• Se publican en una red especial: la Ingress network.
• Puedes verla con:

docker network ls

• Clave: los puertos publicados viven en la red Ingress que soporta el routing mesh.

¿Por qué docker run y docker service difieren con puertos?

• En docker run, publicar el mismo puerto dos veces en la misma máquina falla.
• En servicios de Swarm, el puerto publicado se gestiona por Ingress y routing mesh.
• Resultado: varias tareas del mismo servicio pueden convivir aunque compartan puerto.

¿Qué demuestra el escalado con docker service scale?

La prueba práctica: escalar a más tareas que nodos y mantener un único puerto publicado.

• Escalado del servicio: docker service scale app=6.
• Revisión del despliegue:

docker service ps app

• Caso observado: un worker con dos tareas del mismo servicio.
• Validación local en el nodo:

docker ps

• Hallazgo: dos contenedores en el mismo puerto sin conflictos, porque no hay port binding al host.
• Comprobación con curl: se observan múltiples IDs de contenedor respondiendo antes de repetirse, señal de distribución correcta del tráfico.

¿Qué límites y buenas prácticas marca el instructor?

Aunque el routing mesh es potente, hay reglas claras que respetar.

• Límite de publicación: no puedes tener dos servicios distintos en el mismo puerto publicado.
• Flexibilidad: sí puedes tener muchas tareas del mismo servicio escuchando en ese puerto.
• Operación recomendada: evitar ejecutar cargas en los managers.
• Próximo paso: aprender a decidir dónde corren ciertas tareas y dónde no, para aislar workloads en workers.

Palabras y comandos clave para dominar: - Docker Swarm, managers, workers, servicio, tareas, contenedores, puerto publicado. - Routing mesh, Ingress network, port binding. - docker service scale, docker service ps app, docker ps, docker network ls, curl.

¿Te quedó alguna duda sobre routing mesh, Ingress o escalado de servicios? Cuéntalo y seguimos la conversación.