Entender el networking en Docker es clave para conectar contenedores entre sí, simular entornos reales y elegir la topología correcta antes de pasar a producción. Aquí verás los cinco modelos de red disponibles, cuándo usar cada uno y un ejercicio práctico con el modelo bridge, el más común en proyectos locales.
¿Cuáles son los modelos de networking en Docker?
Docker ofrece cinco modelos de red, pero solo uno se usa de forma habitual en el día a día. Los demás existen para pruebas, experimentación y escenarios muy específicos de despliegue.
- Bridge: el modelo por defecto. Permite que los contenedores en tu máquina local se comuniquen entre sí enviando mensajes y compartiendo recursos dentro de una red interna [1:00].
- Host: deja que el contenedor use la dirección IP real de tu máquina. Es más eficiente y simula que el contenedor es la propia máquina, aunque consume más recursos de red [1:30].
- Isolated: aísla por completo al contenedor del exterior. Ideal para ver cómo reacciona tu sistema cuando falta comunicación en una de sus piezas [2:00].
- Overlay: permite que contenedores en máquinas distintas se comuniquen entre sí. Es la topología que usa Kubernetes para orquestar miles de contenedores en cientos de máquinas [2:30].
- MacVLAN: asigna una dirección MAC real a cada contenedor, de modo que la red los percibe como máquinas físicas independientes [3:15].
¿Cuál es el modelo de red por defecto en Docker? El modelo bridge. Conecta contenedores dentro de tu host para que puedan hablar entre ellos sin exponerse al exterior.
¿Por qué el modelo bridge es el más usado?
Porque resuelve el caso más frecuente: tener varios contenedores corriendo en tu máquina que necesitan comunicarse de forma controlada. No requiere infraestructura adicional ni configuraciones complejas, y es seguro porque la red queda aislada del navegador del host salvo que expongas puertos.
¿Cómo crear una red bridge y conectar dos contenedores?
El ejercicio consiste en levantar dos contenedores —uno con Nginx como servidor web y otro con Alpine como cliente— y verificar que se ven entre sí dentro de una misma red personalizada.
Paso 1: crear la red
El primer comando crea una red bridge con un nombre identificable:
bash
docker network create mi_red_bridge
Docker responde con un identificador largo que confirma que la red ya existe y está lista para recibir contenedores.
Paso 2: levantar el servidor Nginx
Ahora despliegas Nginx en segundo plano y lo conectas a la red recién creada:
bash
docker run -d --network mi_red_bridge --name servidor_web nginx
El parámetro -d ejecuta el contenedor en background y --network lo asigna a tu red. Si abres Docker Desktop, verás la imagen nginx en uso y el contenedor corriendo.
Paso 3: levantar el cliente Alpine
Para probar la comunicación necesitas una terminal Linux ligera. Alpine es la imagen más pequeña y se ejecuta así:
bash
docker run -it --network mi_red_bridge --name cliente alpine /bin/sh
El parámetro -it habilita la interactividad con la terminal del contenedor. Es lo mismo que abrir la pestaña Exec del contenedor en Docker Desktop.
¿Cómo verificar que los contenedores se comunican?
Dentro de la terminal de Alpine instalas curl sin guardar caché para mantener la imagen liviana:
bash
apk add --no-cache curl
Luego haces una petición al servidor usando el nombre del contenedor como hostname:
bash
curl http://servidor_web
Docker resuelve servidor_web automáticamente porque ambos contenedores comparten la red bridge personalizada. La respuesta es el HTML de bienvenida de Nginx, lo que confirma que el cliente alcanzó al servidor.
¿Por qué no puedo abrir el contenedor Nginx desde mi navegador? Porque tu host no forma parte de la red mi_red_bridge. Esa red es exclusiva para los contenedores conectados a ella, y para acceder desde el navegador necesitarías mapear un puerto con -p.
¿Qué pasa si intento acceder desde el host?
Nada. El navegador no encuentra la dirección porque la red es interna. Esto demuestra una propiedad clave del modelo bridge: aísla el tráfico entre contenedores y el exterior, lo que añade una capa natural de seguridad mientras desarrollas.
¿Cuándo conviene usar overlay o MacVLAN?
Estos modelos rara vez se configuran a mano. El overlay aparece cuando trabajas con orquestadores como Kubernetes, donde miles de contenedores distribuidos en distintas máquinas necesitan hablar entre sí sin que tú gestiones la red. El MacVLAN, en cambio, es útil cuando necesitas que cada contenedor se comporte como una máquina física independiente dentro de tu red local, con su propia MAC.
La recomendación es jugar con cada modelo en un entorno de pruebas antes de decidir cuál encaja con tu proyecto. ¿Ya probaste alguno de estos modelos en tus despliegues? Cuéntame cuál usaste y qué resultado obtuviste.
