Publicacion 04
Reverse proxy para microservicios
Una guia introductoria para enrutar multiples servicios detras de un reverse proxy en Docker Swarm con ubicacion explicita de servicios y estructura de stack.
9 min

Que incluye el stack
- Un cluster Swarm con nodos manager y worker.
- Un servicio de base de datos.
- Tres servicios de aplicacion.
- Un servicio de reverse proxy como punto de entrada publico.
- Un visualizador opcional para inspeccionar el cluster.
Inicializar el Swarm
Comienza en el nodo manager:
Despues une los workers usando el token generado por el manager:
Si necesitas volver a imprimir el token:
docker swarm join-token workerEtiquetar nodos por responsabilidad
Las etiquetas ayudan a ubicar servicios con intencion, en lugar de dejar todo a una decision generica del scheduler.
docker node ls
docker node update --label-add db=true NODE_ID
docker node update --label-add worker=true NODE_IDDefinicion del stack
El stack de abajo muestra una base de datos, tres servicios, un reverse proxy y un visualizador. Lo importante no son exactamente los nombres de imagen, sino como se reparten y restringen las responsabilidades.
version: '3.8'
services:
db:
image: mongo:latest
ports:
- 27017:27017
volumes:
- db-data:/data/db
deploy:
placement:
constraints:
- node.labels.db == true
resources:
limits:
cpus: '8.0'
memory: 8G
survey:
image: rhonalchirinos/exec04-survey:latest
ports:
- 3000:3000
command: sh -c "node /app/src/main.js"
depends_on:
- db
deploy:
replicas: 3
resources:
limits:
cpus: '1.0'
memory: 1G
placement:
constraints:
- node.labels.worker == true
auth:
image: rhonalchirinos/exec04-auth:latest
ports:
- 3001:3001
command: sh -c "node /app/src/main.js"
depends_on:
- db
environment:
- MONGO_DB=mongodb://db:27017/app
- PORT=3001
deploy:
replicas: 3
resources:
limits:
cpus: '1.0'
memory: 1G
placement:
constraints:
- node.labels.worker == true
stats:
image: rhonalchirinos/exec04-stats:latest
ports:
- 3002:3002
depends_on:
- db
deploy:
replicas: 2
resources:
limits:
cpus: '1.0'
memory: 1G
placement:
constraints:
- node.labels.worker == true
haproxy:
image: rhonalchirinos/exec04-haproxy:latest
ports:
- "80:8080"
depends_on:
- stats
- auth
- survey
deploy:
placement:
constraints:
- node.role == manager
visualizer:
image: dockersamples/visualizer:latest
ports:
- "8080:8080"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock:ro"
deploy:
placement:
constraints:
- node.role == manager
replicas: 1
volumes:
db-data:Desplegar el stack
Cuando las imagenes existen y los nodos estan listos, despliega el stack desde el manager.
docker stack deploy -c docker-compose.yml mystackPor que importa el reverse proxy
El proxy se convierte en la puerta de entrada publica del sistema. En vez de exponer cada servicio interno de forma directa, centralizas el ingreso y enrutas solicitudes segun hostnames, paths o puertos.
- El punto de entrada queda controlado.
- Los servicios internos pueden escalar de forma independiente.
- Las reglas de routing quedan concentradas en un solo lugar.
- La arquitectura se vuelve mas facil de evolucionar.
Que ensena este ejercicio
- Swarm puede orquestar multiples servicios con replicas.
- Las etiquetas de nodo ayudan a separar roles de infraestructura.
- Un reverse proxy da al sistema un punto de acceso externo estable.
- Los archivos Compose para Swarm funcionan como un contrato operativo legible.
Siguiente paso recomendado
Despues de que el stack funcione, la mejora mas valiosa es definir reglas de routing explicitas, health checks y rolling updates. Ahi es donde el montaje empieza a parecerse a una base real de produccion.