Redes en Docker: los 5 modelos explicados

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:37

Redes en Docker: los 5 modelos explicados

Curso de Docker Avanzado

Clase 18 de 34

Clase 18 / 34

Recursos

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.

Alfredo Olmedo

Hace 2 años

Docker ofrece varios modelos de red que permiten a los contenedores comunicarse entre sí, con el host y con redes externas. Estos modelos son gestionados a través del motor de redes de Docker.

1. bridge (predeterminada en Docker)

Descripción: Es la red predeterminada que Docker asigna a los contenedores. Se crea automáticamente cuando instalas Docker.
Uso típico: Comunicación entre contenedores en un mismo host de Docker.
Características:
- Los contenedores en la red bridge pueden comunicarse entre sí utilizando IPs privadas.
- Puedes mapear puertos del contenedor al host para acceso externo.
Ejemplo:docker network create my_bridge_network docker run --network my_bridge_network my_image

2. host

Descripción: Usa directamente la red del host en lugar de crear una interfaz virtual para los contenedores.
Uso típico: Escenarios donde necesitas un alto rendimiento en la red o evitar la sobrecarga de virtualización.
Características:
- No aísla el tráfico de red.
- El contenedor comparte la pila de red del host, por lo que no tiene su propia dirección IP.
Ejemplo:docker run --network host my_image

3. none

Descripción: Desactiva la conectividad de red del contenedor.
Uso típico: Cuando quieres contenedores completamente aislados de la red.
Características:
- El contenedor no puede comunicarse con otros ni con el host.
Ejemplo:docker run --network none my_image

4. overlay

Descripción: Permite la comunicación entre contenedores en diferentes hosts de Docker.
Uso típico: Redes distribuidas en un clúster Docker Swarm o Kubernetes.
Características:
- Requiere que Docker esté configurado en modo Swarm.
- Crea redes lógicas que conectan múltiples hosts.
Ejemplo:docker network create --driver overlay my_overlay_network docker service create --network my_overlay_network my_image

5. macvlan

Descripción: Asigna una dirección MAC a cada contenedor, lo que permite que parezcan dispositivos físicos en la red.
Uso típico: Integración directa con la red física del host.
Características:
- Los contenedores aparecen como dispositivos independientes en la red.
- Útil para aplicaciones que requieren acceso a la red física.
Ejemplo:docker network create \ --driver macvlan \ --subnet=192.168.1.0/24 \ --gateway=192.168.1.1 \ -o parent=eth0 my_macvlan_network docker run --network my_macvlan_network my_image

6. custom network (redes personalizadas)

Descripción: Puedes crear redes personalizadas con configuraciones específicas.
Uso típico: Configurar reglas específicas para la comunicación y aislamiento de contenedores.
Características:
- Compatibilidad con bridge, overlay, y otros.
- Personalización de subredes, rangos IP, y DNS.
Ejemplo:docker network create \ --driver bridge \ --subnet=192.168.1.0/24 my_custom_network docker run --network my_custom_network my_image

Comparación de Modelos

ModeloAislamientoUso ExternoUso en ClústerFacilidad de UsobridgeSíMapeo PuertosNoAltohostNoSíNoAltononeSíNoNoMediooverlaySíSíSíMediomacvlanNoSíNoBajo

Optimización Avanzada en Docker

Optimización avanzada de Docker para cloud native

Docker productivo vs comandos básicos

Multi-stage builds en Docker con ASP.NET

Cómo escanear vulnerabilidades en imágenes Docker

Imágenes distroless: de 840 MB a 52 MB

Imágenes Docker para múltiples arquitecturas

Cómo funciona el caché en Docker builds

De 1.19 GB a 126 MB con Alpine

Qué es el build context en Docker

Docker Hub para compartir imágenes en la nube

Buenas Prácticas en Docker

Cómo reducir capas en Docker

Cómo usar .dockerignore para imágenes más pequeñas

Limpia Docker y recupera gigas con prune

Creando usuarios en Docker sin privilegios root

6 prácticas Docker para imágenes listas para producción

Instalación y Configuración en Entornos Multiplataforma

Publica imágenes Docker en Azure Container Registry

Azure Container Registry hacia Container App

Redes Avanzadas y Balanceo de Carga

Redes en Docker: los 5 modelos explicados

Cómo funcionan los puertos en Docker

Balanceo de carga con NGINX en Docker

Automatización de CI/CD

Optimizar Dockerfile con comandos RUN y scripts

Automatiza Docker con GitHub Actions

Pruebas automáticas de Docker con GitHub Actions

Despliegue automático en Azure con GitHub Actions

Orquestación

Docker Compose: balanceo de cargas automatizado

Estructura y plantilla de Docker Compose YAML

Volúmenes Docker: bind vs nombrados

docker-compose down vs Control C en apagado

Docker Swarm para principiantes paso a paso

Despliegue Docker Swarm con réplicas de Nginx

Costos ocultos de contenedores en la nube

Cómo habilitar Kubernetes en Docker Desktop

Planes y límites de Docker Hub en producción

Develop

Dev containers en VS Code con Docker

Redes en Docker: los 5 modelos explicados