ADR-005: Migración a Enrutamiento Directo mediante Traefik

Estado

Aceptado

Contexto

Originalmente, el microservicio Travel utilizaba un contenedor Nginx adicional como "escudo" o proxy inverso interno. Este proxy recibía el tráfico de Traefik y decidía si enviarlo al API o servir archivos estáticos.

Esta arquitectura presentaba varios inconvenientes: 1. Complejidad de Configuración: Requería mantener dos capas de Nginx (proxy y runtime). 2. Bucle de Configuración: Un error en la asignación de archivos de configuración provocaba bucles infinitos de redirección y errores 502/504 difíciles de depurar. 3. Dificultad de Escalabilidad: Para cada microservicio nuevo era necesario configurar un proxy intermedio específico.

Decisión

Se ha decidido eliminar el servidor proxy intermedio de Nginx en el microservicio Travel y utilizar las capacidades nativas de Traefik v3 para gestionar el enrutamiento basado en rutas (Path routing).

Cambios técnicos realizados: * Se eliminó el servicio proxy del docker-compose.yml. * Se configuró el contenedor travel-frontend solo como servidor de archivos estáticos (port 8080). * Se añadieron etiquetas de Traefik al Backend (timeliber-travel-api) con una regla de PathPrefix('/api') y prioridad alta (100). * Se añadieron etiquetas de Traefik al Frontend con una regla general de Host y prioridad baja (10).

Consecuencias

• Positivas: Reducción de 1 contenedor en la infraestructura, configuración más clara y declarativa, mejor rendimiento al saltarse un salto de red intermedio.
• Negativas: Ahora Traefik debe tener acceso a ambas redes (proxy-net y timeliber-net) para alcanzar tanto al frontend como al backend.