Cómo configurar una red de Docker dedicada para backends de proxy inverso

Conecta el proxy inverso y cada backend HTTP a una red definida por el usuario compartida; mantén las bases de datos en redes privadas de las aplicaciones.

Publicar todos los puertos de los backends en el host NAS es innecesario cuando el proxy puede resolver los nombres de servicio de Compose en un bridge definido por el usuario. Un patrón de dos redes proporciona al proxy una ruta controlada hacia los backends web, mientras que las bases de datos permanecen accesibles únicamente para sus aplicaciones. Define la propiedad de las redes, evita alias ambiguos, decide qué servicios requieren acceso saliente y verifica que los puertos del host permanezcan cerrados.

Dibuja la matriz de accesibilidad prevista

Enumera cada conexión: cliente al proxy, proxy al backend, backend a la base de datos, backend a API externas y administrador a endpoints de mantenimiento. Indica el protocolo, el puerto, el nombre DNS y si la ruta atraviesa el host.

Normalmente, solo el proxy inverso debería publicar los puertos 80 y 443. Los backends exponen su puerto de aplicación a la red de Docker sin una asignación ports al host. Las bases de datos deben unirse únicamente a la red privada de la aplicación, salvo que se requiera una ruta de administración explícita.

Elige nombres de servicio o alias de red estables y únicos. El DNS de Docker resuelve los servicios en redes definidas por el usuario compartidas, pero los alias genéricos como web pueden entrar en conflicto cuando muchos proyectos de Compose se conectan a la misma red del proxy.

Crea una red compartida del proxy y una red privada de la aplicación

Crea la red del proxy una sola vez, márcala como externa en cada proyecto de aplicación y conecta el proxy y el backend previsto. Esto mantiene estable la identidad de la red cuando se vuelve a crear un proyecto individual de Compose.

Define una red privada independiente, predeterminada o con nombre, para cada aplicación y conecta su backend y su base de datos. El backend se convierte en el puente controlado entre el tráfico del proxy y el estado privado; el proxy no debería unirse a la red de la base de datos.

La documentación de definiciones de redes de Compose explica las redes externas y la conexión de servicios en Compose. Trata una red externa como propiedad del ciclo de vida fuera de la pila de la aplicación: la implementación debe comprobar que existe en lugar de asumir que Compose la creará o eliminará.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Elimina los puertos innecesarios del host y revisa el tráfico saliente

Después de que funcione la ruta del proxy, elimina las publicaciones de puertos del host de los backends. La declaración expose puede documentar el puerto del contenedor, pero no es un firewall; la pertenencia a la red determina qué contenedores pueden conectarse.

Considera internal: true solo para las redes cuyos miembros realmente no necesiten una ruta externa. Los backends que llaman a proveedores de identidad, webhooks, servicios de paquetes o API remotas pueden fallar en una red únicamente interna. Usa una segunda red con capacidad de salida cuando el diseño de la aplicación lo requiera.

Protege el socket de Docker utilizado para la detección automática del proxy. Un montaje de enlace de solo lectura reduce las escrituras accidentales, pero no hace que el socket sea inofensivo; un proxy de socket restringido o una configuración estática proporciona una superficie de control más limitada.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifica el DNS de los servicios, la exposición de puertos y el aislamiento

Desde el contenedor del proxy, resuelve el nombre del servicio backend y solicita su endpoint de estado en el puerto del contenedor. Desde un contenedor no relacionado, confirma que el nombre o la conexión no estén disponibles, a menos que ese contenedor esté intencionadamente en la red del proxy.

Analiza el host NAS desde otro dispositivo de la LAN y confirma que solo estén abiertos los puertos del proxy. Después, prueba TLS, las cabeceras reenviadas, las actualizaciones de WebSocket, las cargas grandes y las redirecciones de la aplicación a través del nombre de host público. El mapa de servicios del servidor doméstico debería registrar la red del proxy como parte del mapa de servicios del servidor doméstico.

Revierte restaurando la asignación de puertos anterior únicamente para el diagnóstico, no como dependencia oculta permanente. Detente si el proxy necesita acceso directo a la base de datos, los alias dirigen al proyecto equivocado o eliminar un puerto del host rompe una integración no documentada.

Preguntas frecuentes 

¿Una red de Docker externa es automáticamente más segura?

No. Externa describe la propiedad del ciclo de vida, no la seguridad. En general, cada contenedor conectado puede comunicarse según el comportamiento del controlador de red y del firewall del host.

¿Los servicios backend deben seguir declarando expose?

Es opcional para la conectividad en una red definida por el usuario, pero puede documentar el puerto previsto del contenedor. No publica el puerto en el host.

¿Se puede marcar la red del proxy como interna?

Solo si el proxy y el diseño de enrutamiento siguen teniendo las rutas entrantes y salientes necesarias. Una red interna bloquea la conectividad externa normal de los contenedores conectados y puede romper los flujos de certificados o identidad.

¿Por qué usar nombres de servicio en lugar de direcciones IP de contenedores?

Las direcciones de los contenedores pueden cambiar después de volver a crearlos. El descubrimiento de servicios de Docker proporciona un nombre estable dentro de la red compartida, lo que hace que la configuración del proxy sea más duradera.

restaura la línea base guardada, aplica una vez la configuración aprobada, repite la carga de trabajo original similar a producción, verifica la señal de éxito prometida y luego ejecuta la reversión documentada. No cierres el cambio hasta que los registros, los tiempos, los permisos, la capacidad y los resultados recuperados coincidan con los criterios de aceptación.