Cómo diseñar redes Docker fáciles de mantener

Introducción

Diseñar redes Docker fáciles de mantener significa conseguir que cada contenedor pueda comunicarse únicamente con los servicios que necesita, mediante nombres comprensibles, reglas previsibles y una estructura que siga teniendo sentido cuando la plataforma crece. Docker permite crear redes con mucha facilidad, pero esa misma facilidad puede llevar a una infraestructura confusa: todos los contenedores conectados a una única red, puertos publicados sin necesidad, dependencias basadas en direcciones IP y redes antiguas cuyo propósito ya nadie recuerda.

Una red Docker mantenible no busca maximizar el aislamiento ni crear el mayor número posible de segmentos. Busca expresar de forma sencilla las relaciones reales entre servicios. Una aplicación web necesita hablar con su base de datos; un proxy inverso necesita alcanzar varias aplicaciones; una herramienta de monitorización puede necesitar acceso a distintos servicios. Cada comunicación debe existir por una razón reconocible.

El diseño de red también afecta a la seguridad, al diagnóstico y a la capacidad de migración. Si todos los proyectos comparten una misma red, cualquier cambio puede tener consecuencias inesperadas. Si cada aplicación depende de IP fijas, una recreación puede romper conexiones. Si se publican puertos internos hacia el host sin necesidad, aumenta la superficie expuesta y se pierde parte del valor del aislamiento de Docker.

Este artículo explica cómo organizar redes Docker desde una perspectiva práctica: redes privadas por proyecto, redes compartidas, comunicación por nombre, uso del proxy inverso, publicación de puertos, redes externas, DNS interno, dependencias entre proyectos, diagnóstico básico y criterios para retirar configuraciones antiguas. El objetivo no es convertir una plataforma pequeña en una arquitectura de red compleja, sino hacer que siga siendo comprensible y previsible con el paso del tiempo.

La separación general entre proyectos se desarrolla en cómo estructurar un entorno Docker para varios servicios independientes. Aquí el foco se limita a una pregunta concreta: ¿cómo diseñar la conectividad entre contenedores para que sea clara, segura y fácil de mantener?

Índice

• Entender qué resuelve una red Docker
• Aplicar el principio de conectividad mínima
• Usar una red privada por proyecto como patrón base
• Comunicar servicios por nombre y no por IP
• Distinguir puertos internos y puertos publicados
• Compartir un proxy inverso sin mezclar toda la plataforma
• Cuándo utilizar redes compartidas
• Qué son las redes externas en Docker Compose
• Mantener las bases de datos fuera de la exposición pública
• Usar nombres y aliases con criterio
• Comprender el DNS interno de Docker
• Cuándo definir subredes manualmente
• Evitar solapamientos de direcciones
• Conectar contenedores con servicios del host
• Controlar salida a Internet y dependencias externas
• Usar la red como frontera de seguridad práctica
• Diagnosticar problemas de conectividad
• Documentar la topología mínima
• Cambiar redes sin romper servicios
• Retirar redes antiguas con seguridad
• Tres patrones de red mantenibles
• Errores frecuentes
• Procedimiento práctico de diseño
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Entender qué resuelve una red Docker

Una red Docker permite que varios contenedores se comuniquen entre sí manteniendo una separación lógica respecto a otros servicios. Cuando dos contenedores comparten una red, pueden intercambiar tráfico de acuerdo con la configuración del entorno y utilizar mecanismos de resolución de nombres proporcionados por Docker.

El valor principal no está en “crear redes”, sino en representar relaciones.

Por ejemplo:

aplicacion-web
    |
    +---- base-datos

proxy
    |
    +---- aplicacion-web
    +---- panel-interno

Este esquema ya sugiere que no todos los componentes necesitan compartir la misma red. La aplicación web y la base de datos pueden tener una red privada. El proxy puede utilizar otra red compartida con los servicios que debe publicar.

Una red representa una capacidad de comunicación

Si un contenedor está conectado a una red, debería existir una razón concreta. Esa regla sencilla ayuda a evitar redes globales donde todos los servicios pueden verse entre sí sin necesidad.

Aplicar el principio de conectividad mínima

El principio más útil para diseñar redes mantenibles es conectar cada servicio únicamente con aquello que necesita.

Una aplicación típica puede necesitar:

• su base de datos;
• un servicio de caché;
• un proxy inverso;
• una API externa;
• Internet para descargar o enviar información.

Eso no implica que necesite acceder a las bases de datos de otras aplicaciones, a todos los servicios internos del host o a cada contenedor de monitorización.

Menos conexiones, menos dependencias

La conectividad mínima mejora tres cosas:

• reduce exposición innecesaria;
• facilita comprender dependencias;
• limita el impacto de errores de configuración.

No se trata de implementar una segmentación extrema. En una plataforma pequeña, dos o tres redes bien diseñadas pueden ser mejores que veinte redes difíciles de documentar.

Usar una red privada por proyecto como patrón base

Docker Compose crea normalmente una red propia para cada proyecto si no se especifica otra cosa. Ese comportamiento puede utilizarse como patrón base porque mantiene relacionados los contenedores de una misma aplicación.

Por ejemplo:

services:
  web:
    image: ejemplo-web:1.0

  db:
    image: postgres:17

Ambos servicios pueden compartir la red del proyecto sin que sea necesario publicar la base de datos hacia el host.

Ventajas del patrón

• aislamiento lógico entre proyectos;
• nombres previsibles;
• menos colisiones;
• retirada más sencilla;
• menor exposición de servicios internos;
• dependencias más fáciles de identificar.

No compartir por comodidad

Cuando aparece una segunda aplicación, puede resultar tentador conectarla a la red existente para reutilizar una base de datos o alcanzar otro servicio. Antes de hacerlo conviene preguntar si esa dependencia es realmente parte del diseño o solo una solución rápida.

La organización general de estas unidades se relaciona con cómo organizar correctamente los proyectos Docker.

Comunicar servicios por nombre y no por IP

Una red Docker mantenible debería evitar depender de direcciones IP internas fijas salvo que exista una razón técnica clara.

Dentro de una red Compose, un servicio puede localizarse normalmente mediante su nombre.

services:
  app:
    environment:
      DB_HOST: db

  db:
    image: postgres:17

La aplicación puede conectarse a db sin conocer la IP concreta asignada al contenedor.

Por qué evitar IP fijas

Los contenedores se recrean. Su dirección puede cambiar. Si una aplicación depende de una IP escrita manualmente, la infraestructura deja de aprovechar la naturaleza dinámica de Docker.

Los nombres aportan:

• legibilidad;
• portabilidad;
• menos configuración manual;
• migraciones más sencillas;
• menos dependencia de la topología actual.

Distinguir puertos internos y puertos publicados

Uno de los conceptos más importantes es diferenciar el puerto donde escucha una aplicación dentro de la red Docker del puerto que se publica hacia el host.

Un servicio interno puede escuchar en:

5432/tcp

sin necesidad de publicar:

5432:5432

Publicar solo lo necesario

Si una base de datos solo es utilizada por la aplicación que comparte su red, normalmente no necesita un puerto accesible desde el host.

En cambio, un servicio web puede publicar un puerto si debe ser accesible directamente, aunque en muchas arquitecturas sea preferible que solo el proxy inverso tenga los puertos públicos.

Menos puertos simplifican la operación

Evitar publicaciones innecesarias reduce:

• conflictos de puertos;
• exposición;
• reglas de firewall;
• confusión sobre qué servicio debe utilizarse;
• dependencia del host.

Compartir un proxy inverso sin mezclar toda la plataforma

Un proxy inverso suele ser uno de los pocos servicios que necesita comunicarse con varias aplicaciones independientes.

Un patrón mantenible consiste en utilizar:

• una red privada para cada proyecto;
• una red compartida para el proxy y las aplicaciones publicadas.

Conceptualmente:

red-proyecto-a
  app-a ---- db-a

red-proyecto-b
  app-b ---- db-b

red-proxy
  proxy ---- app-a
        ---- app-b

Las bases de datos permanecen fuera de red-proxy. El proxy solo alcanza los servicios web que necesita publicar.

Separar entrada y datos

Este patrón ayuda a que la capa pública no tenga acceso directo a componentes internos que no necesita.

La red compartida se convierte en dependencia

Si varios proyectos dependen de red-proxy, su nombre y propósito deben documentarse. No debería eliminarse ni recrearse sin saber qué aplicaciones la utilizan.

Cuándo utilizar redes compartidas

Una red compartida es útil cuando varios proyectos independientes necesitan comunicarse de forma deliberada.

Casos habituales:

• proxy inverso común;
• monitorización;
• servicio interno de autenticación;
• API utilizada por varias aplicaciones;
• pasarela común;
• servicio de mensajería compartido.

La pregunta clave

Antes de conectar un proyecto a una red común, conviene preguntar: “¿qué servicio concreto necesita alcanzar?”.

Si la respuesta es vaga —“por si acaso”, “para que se vean” o “porque es más fácil”— probablemente la red está ampliando su alcance sin necesidad.

No convertir la red compartida en red universal

Una red donde terminan todos los contenedores acaba eliminando las fronteras que se habían creado mediante proyectos separados.

Qué son las redes externas en Docker Compose

Cuando una red debe existir independientemente del ciclo de vida de un proyecto Compose, puede declararse como externa.

networks:
  proxy:
    external: true
    name: red-proxy

Y un servicio puede conectarse a ella:

services:
  app:
    networks:
      - default
      - proxy

Ventaja operativa

La red compartida no se elimina automáticamente al ejecutar:

docker compose down

sobre uno de los proyectos que la utiliza.

Responsabilidad adicional

Una red externa necesita gestión explícita. Debe saberse:

• quién la crea;
• qué proyectos la utilizan;
• qué nombre debe tener;
• qué ocurriría si se elimina;
• cómo recrearla durante una recuperación.

Mantener las bases de datos fuera de la exposición pública

Una base de datos utilizada por una aplicación Docker suele necesitar comunicación interna, no acceso público.

Un patrón sencillo:

services:
  app:
    networks:
      - frontend
      - backend

  db:
    networks:
      - backend

networks:
  frontend:
  backend:
    internal: true

La configuración exacta debe adaptarse a cada arquitectura, pero el principio es claro: la base de datos no necesita estar conectada a todas las redes de la aplicación.

No publicar el puerto si no es necesario

Durante pruebas puede resultar cómodo publicar una base de datos para conectarse desde el host. Esa excepción no debería mantenerse indefinidamente en producción por simple inercia.

Usar nombres y aliases con criterio

Docker permite utilizar aliases de red para que un servicio sea accesible mediante nombres adicionales.

Puede ser útil cuando:

• se migra un servicio manteniendo un nombre lógico;
• varios consumidores esperan una denominación estable;
• se desea separar el nombre técnico del nombre de servicio.

No crear demasiados nombres

Si un mismo contenedor tiene cinco aliases y nadie sabe cuál es el oficial, la flexibilidad se convierte en ambigüedad.

Conviene mantener:

• un nombre funcional estable;
• aliases solo cuando resuelvan una necesidad;
• documentación de cualquier compatibilidad temporal.

Comprender el DNS interno de Docker

Docker proporciona resolución de nombres dentro de sus redes. Esta capacidad permite que los servicios se localicen mediante nombres lógicos en lugar de IP.

Diagnosticar resolución

Cuando una aplicación no alcanza otro servicio, conviene diferenciar:

• el nombre no resuelve;
• resuelve pero el puerto no escucha;
• el servicio escucha pero rechaza la conexión;
• la aplicación utiliza un nombre incorrecto;
• los contenedores no comparten red.

Dentro de una imagen que disponga de herramientas adecuadas pueden utilizarse comandos como:

getent hosts db

o realizar una conexión directa al puerto del servicio.

Las imágenes mínimas pueden no incluir herramientas

La ausencia de ping, curl o utilidades DNS no significa que la red esté fallando. Muchas imágenes eliminan herramientas innecesarias para reducir tamaño y superficie.

Cuándo definir subredes manualmente

Para muchos proyectos pequeños no es necesario elegir manualmente rangos IP. Docker puede gestionar la asignación.

Definir subredes empieza a tener sentido cuando existen necesidades como:

• integración con redes externas;
• VPN;
• reglas de firewall basadas en rangos;
• varios hosts;
• evitar colisiones conocidas;
• requisitos concretos de direccionamiento.

No añadir direccionamiento manual por apariencia técnica

Una subred definida sin necesidad aumenta configuración y puede crear conflictos futuros.

La mantenibilidad mejora cuando solo se fijan aquellas propiedades que realmente necesitan ser estables.

Evitar solapamientos de direcciones

Cuando Docker convive con VPN, redes corporativas, laboratorios o varias interfaces, pueden aparecer rangos IP solapados.

El síntoma puede ser confuso:

• un destino deja de ser accesible solo desde contenedores;
• la VPN funciona en el host pero no dentro de Docker;
• el tráfico toma una ruta inesperada;
• una red nueva rompe acceso a un rango existente.

Inventariar rangos cuando la infraestructura crece

En una plataforma sencilla puede no ser necesario. Cuando aparecen VPN, varias máquinas o redes físicas diferentes, conviene documentar:

• red local;
• VPN;
• redes Docker;
• subredes virtuales;
• rangos reservados.

Conectar contenedores con servicios del host

No todas las dependencias están contenerizadas. Un contenedor puede necesitar acceder a un servicio que se ejecuta directamente sobre el host.

Esta situación debe diseñarse con cuidado porque rompe parcialmente la separación entre plataforma Docker y servidor anfitrión.

Preguntas útiles

• ¿por qué el servicio permanece en el host?
• ¿qué puerto necesita el contenedor?
• ¿debe ser accesible por todos los proyectos?
• ¿existe autenticación?
• ¿cómo se documentará esta dependencia?

Evitar dependencias invisibles

Una aplicación que solo funciona porque el host tiene un daemon instalado y escuchando en una dirección concreta puede ser difícil de migrar si esa dependencia no está documentada.

Controlar salida a Internet y dependencias externas

Muchos contenedores necesitan salir a Internet para consumir APIs, enviar correo, consultar servicios, descargar actualizaciones o validar licencias.

La conectividad externa también forma parte de la arquitectura.

Identificar dependencias

Conviene saber qué servicios necesitan:

• DNS externo;
• HTTPS;
• SMTP;
• APIs concretas;
• registros de imágenes;
• almacenamiento externo.

No confundir fallo externo con fallo Docker

Si un servicio deja de responder porque una API externa está caída, los contenedores y redes locales pueden estar funcionando perfectamente.

El diagnóstico de estas situaciones se relaciona con cómo detectar problemas de rendimiento en Docker, donde se explica cómo separar red local, DNS y dependencias remotas.

Usar la red como frontera de seguridad práctica

Las redes Docker no sustituyen una estrategia completa de seguridad, pero ayudan a reducir comunicaciones innecesarias.

Separar exposición y confianza

Un servicio publicado en Internet no debería obtener acceso automático a todas las bases de datos o herramientas internas del host.

No conectar servicios privilegiados sin necesidad

Herramientas administrativas, paneles y componentes capaces de modificar infraestructura requieren especial cuidado.

La segmentación debe seguir siendo comprensible

Una arquitectura con demasiadas reglas que nadie entiende puede ser menos segura en la práctica porque termina generando excepciones improvisadas.

La seguridad útil combina:

• pocas redes con propósito claro;
• puertos mínimos;
• autenticación;
• actualizaciones;
• documentación;
• monitorización;
• copias y recuperación.

Diagnosticar problemas de conectividad

Cuando dos contenedores no se comunican, conviene seguir un orden en lugar de cambiar redes al azar.

1. Confirmar que ambos están activos

docker ps

2. Revisar sus redes

docker inspect nombre_contenedor

Comprueba si comparten la red que deberían compartir.

3. Revisar la red

docker network inspect nombre_red

Esto permite ver qué contenedores están conectados y parte de su configuración.

4. Probar resolución de nombre

Desde el contenedor consumidor, si dispone de herramientas:

getent hosts nombre-servicio

5. Probar el puerto

La resolución puede funcionar y el servicio no escuchar en el puerto esperado.

6. Revisar logs

Los logs pueden mostrar errores de conexión, DNS, autenticación o timeout.

7. Comprobar el host si afecta a varios servicios

Un fallo del firewall, de Docker Engine o de la red física puede afectar a varios proyectos.

Documentar la topología mínima

Una red Docker debería poder explicarse sin abrir todos los archivos Compose.

Para cada red compartida conviene registrar:

• nombre;
• propósito;
• quién la crea;
• qué proyectos la utilizan;
• qué servicios deben comunicarse;
• si es externa;
• si tiene subred definida;
• si existe alguna excepción relevante.

No hace falta dibujar una topología gigantesca. Un esquema simple suele ser suficiente:

Internet
   |
 proxy
   |
 red-proxy
   +---- app-a
   +---- app-b

app-a ---- red-a ---- db-a
app-b ---- red-b ---- db-b

La documentación general de la plataforma se desarrolla en cómo documentar una infraestructura basada en Docker.

Cambiar redes sin romper servicios

Modificar una red puede afectar a varios contenedores aunque el cambio parezca pequeño.

Antes del cambio

• identifica servicios conectados;
• revisa nombres y dependencias;
• comprueba puertos;
• documenta el estado actual;
• prepara una forma de volver atrás.

Modificar primero en pruebas cuando sea posible

Los cambios de red son especialmente adecuados para probar fuera de producción porque pueden recrearse de forma relativamente sencilla mediante Compose.

Validar por servicio

Después del cambio no basta con comprobar que los contenedores están activos. Hay que verificar:

• resolución interna;
• conexión a bases de datos;
• proxy;
• acceso externo;
• APIs y servicios compartidos.

Retirar redes antiguas con seguridad

Las redes pueden acumularse después de pruebas, cambios de nombres o proyectos retirados.

Para listar redes:

docker network ls

Antes de eliminar una red conviene inspeccionarla:

docker network inspect nombre_red

No limpiar por apariencia

Una red sin un nombre familiar puede seguir siendo necesaria. Debe verificarse:

• qué contenedores están conectados;
• si pertenece a un proyecto activo;
• si es una red externa compartida;
• si forma parte de un procedimiento de recuperación o prueba.

La retirada segura forma parte del mantenimiento, igual que la eliminación controlada de imágenes, contenedores y volúmenes.

Tres patrones de red mantenibles

Patrón 1: aplicación aislada

red-app
  web
  db

Útil para una aplicación interna que no necesita compartir servicios con otros proyectos.

Patrón 2: aplicación con proxy común

red-app
  app
  db

red-proxy
  proxy
  app

La aplicación participa en su red privada y en la red del proxy. La base de datos permanece únicamente en la red privada.

Patrón 3: varios proyectos con servicio compartido

red-a
  app-a
  db-a

red-b
  app-b
  db-b

red-servicio-comun
  app-a
  app-b
  servicio-comun

La red común existe porque ambos proyectos necesitan una dependencia concreta. No sustituye las redes privadas de cada aplicación.

Estos patrones pueden combinarse sin convertir la plataforma en una topología innecesariamente compleja.

Errores frecuentes

Conectar todos los contenedores a una única red

Elimina fronteras y dificulta saber qué dependencias son reales.

Publicar todos los puertos hacia el host

Aumenta exposición, conflictos y configuración innecesaria.

Usar IP internas fijas sin necesidad

Introduce dependencias rígidas que complican recreaciones y migraciones.

Crear una red nueva para cada comunicación

La segmentación excesiva puede ser tan difícil de mantener como la ausencia de segmentación.

No documentar redes externas

Un proyecto puede depender de una red que no crea y fallar al migrarse a otro host.

Eliminar una red compartida durante una limpieza

Puede interrumpir varios proyectos aparentemente independientes.

Confundir red con seguridad completa

La segmentación ayuda, pero no sustituye autenticación, permisos, actualizaciones ni firewall.

Dejar puertos de pruebas publicados en producción

Las excepciones temporales tienden a convertirse en permanentes si no se revisan.

No comprobar solapamientos con VPN

Puede generar fallos de ruta difíciles de interpretar.

Usar nombres ambiguos

Una red llamada network1 aporta poca información sobre su función o propietario.

Procedimiento práctico de diseño

1. Identifica los servicios. Lista qué contenedores componen cada aplicación.
2. Dibuja las comunicaciones necesarias. Indica quién debe hablar con quién.
3. Crea una red privada por proyecto. Utilízala como patrón inicial.
4. Evita publicar servicios internos. Expón solo aquello que realmente debe llegar al host o al exterior.
5. Utiliza nombres de servicio. Evita IP fijas salvo necesidad concreta.
6. Introduce redes compartidas solo por dependencia real. Proxy, monitorización o servicios comunes.
7. Documenta redes externas. Registra quién las crea y quién depende de ellas.
8. Revisa subredes solo si necesitas control manual. No fijes direccionamiento por defecto.
9. Comprueba compatibilidad con VPN y redes físicas. Evita solapamientos.
10. Prueba resolución y puertos. Verifica conectividad real entre servicios.
11. Valida acceso externo. Proxy, DNS y certificados deben seguir funcionando.
12. Retira excepciones antiguas. Puertos de pruebas, redes temporales y aliases obsoletos.
13. Actualiza la documentación. La topología final debe poder explicarse con facilidad.

Lista de comprobación

Preguntas frecuentes

Conclusión

Diseñar redes Docker fáciles de mantener no exige una topología sofisticada. Exige que la conectividad represente de forma clara las dependencias reales entre servicios.

Una red privada por proyecto es un buen punto de partida. A partir de ahí, las redes compartidas deben introducirse únicamente cuando existe una dependencia común, como un proxy inverso, monitorización o un servicio interno utilizado por varias aplicaciones. Los nombres de servicio deben sustituir a las IP fijas siempre que sea posible y los puertos solo deben publicarse cuando realmente necesiten llegar al host o al exterior.

Una red mantenible permite responder rápidamente a tres preguntas: qué servicios pueden comunicarse, por qué pueden hacerlo y qué ocurriría si esa conexión desaparece.

La simplicidad también mejora el diagnóstico. Si las redes tienen un propósito claro, resulta más fácil localizar problemas de DNS, puertos, rutas o dependencias. Si la plataforma crece, documentar redes externas, rangos y servicios compartidos evita que las decisiones antiguas se conviertan en restricciones invisibles.

Docker facilita crear redes; el criterio técnico consiste en crear solo las necesarias, darles un propósito estable y retirarlas cuando dejan de aportar valor. Esa disciplina permite que la infraestructura siga siendo comprensible, segura y portable a medida que aparecen nuevos proyectos y servicios.