4.3Redes avanzadas y reverse proxy
Lo esencial en 30 segundos
- Se segmenta por función : una red frontal (proxy hacia aplicaciones) y una red backend (aplicaciones hacia bases) — la base, limitada al backend, queda inalcanzable directamente aunque el proxy sea comprometido.
- Un solo puerto publicado, todo lo demás enrutado : el reverse proxy (frontal) es el único publicado y enruta por nombre de host — las aplicaciones solo exponen en interno y se alcanzan por sus nombres.
- Reflejo de Idir : añadir un servicio = una entrada de enrutado, cero puerto adicional — config del proxy montada en solo lectura.
Mini-caso hilado — Idir ordena los puertos en desorden detrás de un frontal
Idir, devops junior en Argel, gestiona dos aplicaciones que publican cada una su puerto : las URL son ilegibles y la base es alcanzable desde la red frontal. Crea dos redes (frontal y backend), solo publica el puerto del proxy, enruta por nombres de host y limita la base al backend. Tercer hito del hilo : un punto de entrada único, servicios segmentados, cero puerto en desorden.
Continuación de los casos 4.1-4.2 — los servicios fiabilizados de Idir ahora se exponen limpiamente.
1. Segmentar : una red por función
Más allá de una red única, se segmenta : frontal (proxy hacia aplicaciones) y backend (aplicaciones hacia bases). Un servicio pertenece a varias redes si hace falta ; una base solo está en backend : incluso comprometido el proxy, queda inalcanzable directamente.
La segmentación es aislamiento concreto : cada red solo ve lo que debe ver. Idir coloca ahí cada servicio según lo que debe alcanzar — y nada más.
2. El reverse proxy : un puerto para todos
Traefik o Nginx en frontal : solo su puerto 80/443 está publicado, enruta por nombre de host (cada host hacia su servicio). Las aplicaciones ya no publican nada : exponen en interno y el proxy las alcanza por nombres. Un punto de entrada, N servicios — añadir una aplicación es una entrada de enrutado.
Nginx (config explícita, perfecto para aprender) y Traefik (descubrimiento automático, ideal cuando los servicios se mueven) aplican el mismo esquema : Idir empieza simple con una config explícita.
3. En local : nombres propios, futuros certificados
En desarrollo, se declaran los hosts en el archivo hosts (cada nombre hacia la máquina local) ; en producción, el DNS + TLS cifran el tráfico. Retenga el esquema : uno solo publicado, todo lo demás enrutado.
Y la config del proxy se monta en solo lectura : el contenedor la lee sin poder reescribirla.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Dos apps detrás de Nginx
El frontal de Idir : solo el proxy publica el puerto 80.
services:
proxy:
image: nginx:1.27
ports: ["80:80"]
volumes: [./proxy.conf:/etc/nginx/conf.d/default.conf:ro]
networks: [frontal]
app1:
image: nginx:1.27
networks: [frontal]
app2:
image: nginx:1.27
networks: [frontal]
networks:
frontal:
backend:Lectura : solo el proxy publica el puerto 80 ; las aplicaciones solo son visibles por él.
Lección : añadir una tercera aplicación = una entrada de enrutado, cero puerto adicional.
Vocabulario de la sección
- Reverse proxy
- Frontal que recibe las peticiones y las ENRUTA hacia los buenos servicios según los nombres de host.
Ejemplo sencillo: El proxy de Idir envía cada host hacia su aplicación.
Lo que no es: una publicación de cada puerto de aplicación hacia el exterior.
Reflejo: varios servicios, un solo puerto : poner un frontal.
- Segmentación
- Cortar en REDES POR FUNCIÓN (frontal, backend) para aislar los flujos.
Ejemplo sencillo: Idir limita su base al backend, inalcanzable desde la entrada.
Lo que no es: una red única donde todo ve todo.
Reflejo: base de datos : nunca en la red frontal.
- Enrutado por host
- Cada NOMBRE DE HOST se dirige hacia su servicio (un host = una aplicación).
Ejemplo sencillo: Cada aplicación de Idir tiene su nombre, enrutado por el proxy.
Lo que no es: un puerto distinto improvisado por aplicación.
Reflejo: nuevo servicio : una entrada de enrutado, no un puerto.
- EXPOSE
- Declaración INTERNA de un puerto, sin publicación hacia el exterior.
Ejemplo sencillo: Las aplicaciones de Idir exponen en interno ; solo el proxy publica.
Lo que no es: una publicación de puerto accesible desde la máquina.
Reflejo: detrás de un proxy : exponer, no publicar.
En la práctica — En práctica — Poner un frontal
- Cree las redes frontal y backend.
- Lance dos aplicaciones no publicadas en frontal.
- Lance el proxy publicado con enrutado por host.
- Pruebe los dos hosts, luego corte un backend : el otro sobrevive.
Guion listo para decir — justificar el frontal al equipo (30 s)
« Soy Idir : en lugar de un puerto por aplicación, solo exponemos el proxy y enruta por nombres. Las aplicaciones ya no son alcanzables directamente, la base queda limitada a su red, y la próxima aplicación solo costará una línea de enrutado. »
Para decir cuando aún proponen « un puerto más » : muestre la lista de puertos actuales.
Modelo copiar-pegar — frontal Nginx + redes (Compose)
services:
proxy:
image: nginx:1.27
ports: ["80:80"]
volumes: [./proxy.conf:/etc/nginx/conf.d/default.conf:ro]
networks: [frontal]
app1:
image: nginx:1.27
networks: [frontal]
app2:
image: nginx:1.27
networks: [frontal]
networks:
frontal:
backend:Segunda aplicación
Como Idir : una entrada de enrutado más, ningún puerto publicado adicional.
Servicios que se mueven a menudo
Pasar a Traefik : descubrimiento automático de los servicios, mismo esquema frontal único.
Base por proteger
Base limitada al backend, alcanzada por nombre desde las aplicaciones : inalcanzable desde la entrada.
Desarrollo local
Nombres declarados en el archivo hosts : el mismo archivo de frontal sirve en local y luego en producción.
✓ Buenas prácticas
- Uno solo publicado : el proxy.
- Rutas por nombres de host explícitos.
- Config proxy en montaje solo lectura.
✗ Errores frecuentes
- Publicar cada aplicación (puertos en desorden).
- Base en la red frontal.
- Config proxy escribible desde el contenedor.
Puntos clave
- Segmentar : frontal vs backend.
- Un proxy publicado lo enruta todo.
- Apps no publicadas, alcanzadas por nombres.
- TLS en prod, hosts en dev.
Reto 48h — aplique mañana
Detrás de un proxy único publicado : exponga 2 aplicaciones no publicadas enrutadas por hosts, base limitada al backend, config en solo lectura.
- Sé segmentar en redes frontal y backend.
- Sé publicar solo el proxy y enrutar por hosts.
- Sé limitar la base y montar la config en solo lectura.
Preguntas frecuentes
¿Traefik o Nginx?
Nginx : config explícita, perfecto para aprender. Traefik : descubrimiento auto por etiquetas, ideal cuando los servicios se mueven. Ambos aplican el mismo esquema : uno solo publicado, enrutado por hosts.
¿Hace falta un proxy en dev?
Desde dos aplicaciones : sí, aunque simple. Es el mismo archivo que servirá en producción, sin los puertos en desorden.
Tres apps web en una máquina, un solo puerto 80. ¿Qué hace?