Como ya sabrás, Docker es una de las plataformas de contenedorización más populares y utiliza la virtualización a nivel de sistema operativo para agrupar aplicaciones de software y sus dependencias en unidades reutilizables conocidas como contenedores.
Estos contenedores Docker pueden funcionar en cualquier ordenador equipado con Docker, ya sea en una máquina local o en un entorno remoto en la nube.
Dentro de Docker, se incorpora un sistema de red para gestionar la comunicación entre:
- Los contenedores
- El host
- Y los sistemas externos
Lógicamente, tenemos varios tipos de red disponibles para adaptarnos a diferentes escenarios. En concreto seis, y elegir mal es la causa de buena parte de los ratos perdidos con Docker: contenedores que no se ven entre sí, puertos que no responden o servicios que se pisan.
Vamos a verlos uno a uno, cuándo tiene sentido cada uno y con qué comandos se manejan. Y empezamos avisando de la trampa que más tiempo hace perder: la red que Docker te da hecha y la que creas tú no funcionan igual.
Tipos de Redes Docker
Para que los contenedores establezcan conectividad de red, deben estar vinculados a una red Docker. Las vías de comunicación disponibles para cada contenedor dependen de sus asociaciones de red. Docker ofrece seis controladores de red preconfigurados que sirven como columna vertebral para la funcionalidad de red:
Bridge o puente
Esta es la red por defecto. Cada vez que inicias Docker, se crea una red Bridge y todos los contenedores recién iniciados se conectarán automáticamente a la red puente por defecto. Puedes utilizar esto siempre que quieras que tus contenedores que se ejecutan de forma aislada se conecten y se comuniquen entre sí.
Aquí está el tropiezo que se lleva a todo el mundo por delante, y conviene tenerlo claro desde el principio: la red bridge por defecto y una red bridge que creas tú no se comportan igual.
En la red por defecto, los contenedores solo se ven por dirección IP. Si intentas que uno llame a otro por su nombre, te devuelve un bad address y te vuelves loco buscando el fallo donde no está. En una red que hayas creado tú, en cambio, Docker levanta un servidor DNS interno y los contenedores se encuentran por nombre sin que configures nada.
Por eso la recomendación práctica es siempre la misma: crea tu propia red y no uses la de por defecto para nada serio.
Dado que los contenedores se ejecutan de forma aislada, la red puente resuelve el problema del conflicto de puertos. Si los conceptos de red te bailan, los repasamos en redes y subredes explicadas. Los contenedores que se ejecutan en la misma red puente pueden comunicarse entre sí, y Docker utiliza iptables en la máquina anfitriona para evitar el acceso fuera del puente.
Host
Los contenedores que utilizan el modo de red host comparten directamente la pila de red del host sin aislamiento.
La red del contenedor se comporta como si estuviera directamente en el host. No reciben direcciones IP separadas; en su lugar, los enlaces de puerto se exponen directamente a la interfaz de red del host. En consecuencia, un proceso contenedor escuchando en el puerto 80 se enlazaría a <su_host_ip>:80.
Como no hay traducción de puertos de por medio, es también la opción más rápida y la que tiene sentido cuando un contenedor necesita abrir muchísimos puertos o escuchar tráfico de la red.
Overlay
Las redes superpuestas abarcan redes distribuidas que se extienden a través de múltiples hosts Docker, permitiendo la comunicación entre contenedores a través de hosts sin necesidad de soporte de enrutamiento a nivel de sistema operativo.
Aunque se emplean principalmente en clusters Docker Swarm, las redes superpuestas también pueden utilizarse para establecer comunicación directa entre contenedores en distintas instancias de Docker Engine, permitiendo así la creación de entornos personalizados tipo Swarm.
IPvLAN
IPvLAN funciona como un controlador avanzado que proporciona un control preciso sobre las direcciones IPv4 e IPv6 asignadas a los contenedores, junto con el etiquetado y enrutamiento VLAN de capa 2 y 3.
Este controlador es particularmente beneficioso para integrar servicios de contenedores en redes físicas existentes, ofreciendo ventajas de usabilidad sobre las redes basadas en puentes.
MACVLAN
MACVLAN presenta otra opción sofisticada que permite a los contenedores emular dispositivos físicos en la red asignando a cada contenedor una dirección MAC única. Este tipo de red requiere la dedicación de una de las interfaces físicas del host a la red virtual. Además, la infraestructura de red más amplia debe configurarse adecuadamente para dar cabida a la posible afluencia de direcciones MAC derivadas de un host Docker activo que gestione numerosos contenedores.
none
Aísla completamente un contenedor del host y de otros contenedores.
¿Qué tipo de red debo utilizar?
| Tipo de red | Para qué sirve | Cuándo la quieres | Aislamiento |
| bridge (la que creas tú) | Red privada entre contenedores del mismo host | Casi siempre. Es la respuesta por defecto | Alto |
| bridge por defecto | La que Docker usa si no dices nada | Nunca a propósito: no resuelve nombres | Alto |
| host | El contenedor usa la red del anfitrión tal cual | Cuando necesitas rendimiento o abrir muchos puertos | Ninguno |
| overlay | Une contenedores repartidos en varios hosts | Swarm o varios servidores hablando entre sí | Alto |
| macvlan | Cada contenedor aparece como un aparato físico con su MAC | Domótica y captura de tráfico en la LAN | Medio |
| ipvlan | Como macvlan pero sin MAC propia por contenedor | Cuando el switch o el router limitan las MAC | Medio |
| none | Sin red de ningún tipo | Procesos de cálculo que no deben salir a Internet | Total |
Las redes bridge son la opción más adecuada para la mayoría de los casos —siempre que sea una red creada por ti, como decíamos arriba—. Los contenedores que están en ella se comunican entre sí por nombre, sin necesidad de saberse las direcciones IP, y además tienen acceso a la red de tu host, por lo que pueden llegar a Internet y a tu LAN.
Las redes de host son las mejores cuando quieres vincular puertos directamente a las interfaces de tu host y no te preocupa el aislamiento de la red. Permiten que las aplicaciones en contenedores funcionen de forma similar a los servicios de red que se ejecutan directamente en el host.
Las redes Overlay son necesarias cuando los contenedores en diferentes hosts Docker necesitan comunicarse directamente entre sí. Estas redes te permiten configurar tus propios entornos distribuidos para una alta disponibilidad.
Las redes Macvlan son útiles en situaciones en las que los contenedores deben aparecer como un dispositivo físico en la red de tu host, como cuando ejecutan una aplicación que monitoriza el tráfico de red. Las redes IPvLAN son una opción avanzada para cuando se tienen requisitos específicos en torno a las direcciones IP, etiquetas y enrutamiento de los contenedores.
Los comandos que vas a usar de verdad
Toda la teoría anterior se maneja con un puñado de órdenes. Estas son las que se usan el 95 % del tiempo.
Ver qué redes tienes
docker network ls
Te saldrán al menos tres, que Docker crea solo y no debes borrar: bridge (la de por defecto), host y none.
NETWORK ID NAME DRIVER SCOPE
2f259bab93aa bridge bridge local
7c1a0d4e88b2 host host local
b30fe9a71c04 none null local
Crear la tuya
docker network create mi-red
Sin más parámetros te crea una red bridge, que es lo que quieres en la inmensa mayoría de los casos. Si necesitas fijar el rango de direcciones:
docker network create --subnet 172.28.0.0/16 mi-red
Arrancar un contenedor dentro de ella
docker run -d --name web --network mi-red -p 8080:80 nginx
Meter o sacar un contenedor que ya está corriendo
docker network connect mi-red web
docker network disconnect mi-red web
Un contenedor puede estar en varias redes a la vez, que es la forma limpia de montar, por ejemplo, un servidor web accesible desde fuera y una base de datos que solo hable con él.
Ver qué hay dentro de una red
docker network inspect mi-red
Es el comando al que vas a recurrir cuando algo no conecta: te dice el rango de direcciones, la puerta de enlace y qué contenedores están enchufados, con su IP.
Limpiar
docker network rm mi-red
docker network prune
El segundo borra de golpe todas las redes que no esté usando ningún contenedor.
prune: se lleva por delante cualquier red sin contenedores arrancados en ese momento. Si tienes un docker compose parado, su red también cae, y al levantarlo otra vez se recreará con un rango de direcciones distinto. Si algo dependía de esas IP, dejará de funcionar.Y con Docker Compose
Si usas Compose, casi nunca vas a escribir estos comandos: al levantar el proyecto se crea sola una red bridge propia con el nombre de la carpeta, y todos los servicios del fichero entran en ella. Por eso en un compose.yaml puedes llamar a la base de datos por su nombre de servicio (db, postgres…) sin configurar nada: estás en una red creada por ti, con el DNS interno funcionando.
Es exactamente el comportamiento del apartado anterior, solo que Compose te lo da hecho.
Fuentes
