Docker
Host, none, overlay, macvlan y límites de cada modelo.
El network driver determina cómo se conecta el namespace de un container con el host, otros containers o varios nodos. Cambiar de driver no es una optimización menor: cambia aislamiento, routing, observabilidad, seguridad y responsabilidades operativas.
container namespace
→ network driver
→ topología single-host, host, cluster o red físicaLa mayoría de aplicaciones en un solo Engine funcionan correctamente con user-defined bridge. Los drivers avanzados deben responder un requisito concreto.
Es el modelo normal single-host.
Ventajas:
Costes:
Usa bridge como punto de partida.
docker run --network host my-serviceEl container comparte el namespace de red del host en plataformas compatibles.
Consecuencias:
-p pierde sentido;Puede ser útil para:
No lo uses para corregir una app que escucha mal o evitar entender bridge. Docker Desktop y otros entornos pueden ofrecer comportamiento diferente.
docker run --network none my-jobEl container conserva loopback, pero no recibe conectividad normal.
Casos:
No reemplaza otros controles: un mount sensible sigue siendo accesible y la aplicación puede fallar si intenta DNS, telemetry o licencias.
Overlay conecta servicios a través de varios hosts en modos de orquestación compatibles.
node A container
→ encapsulación/overlay
→ red entre nodos
→ node B containerAporta:
Responsabilidades:
Un overlay no convierte Docker Compose single-host en HA. Necesita una plataforma que programe workloads entre nodos.
Macvlan presenta containers como participantes con direcciones MAC/IP de la red física.
Casos posibles:
Trade-offs:
No lo elijas solo porque “quiero una IP propia”. Evalúa bridge + reverse proxy o routing normal primero.
Ipvlan comparte la MAC del parent y diferencia tráfico por IP, con modos y comportamiento específicos.
Puede evitar algunas limitaciones de múltiples MAC, pero requiere conocimiento de:
Es una decisión de infraestructura, no solo un flag de Docker.
Drivers externos pueden integrar SDN, cloud networks o políticas especializadas.
Antes de adoptarlos revisa:
Un plugin con privilegios puede ampliar la superficie del host.
| Driver | Alcance | Aislamiento | Uso típico |
|---|---|---|---|
| bridge | Un host | Bueno | Aplicaciones normales |
| host | Host directo | Reducido | Casos de red especiales |
| none | Sin red | Máximo de conectividad | Jobs offline |
| overlay | Varios hosts | Lógico por cluster | Orquestación |
| macvlan/ipvlan | Red física | Depende de LAN | Legado/appliances |
Un proceso comprometido interactúa directamente con la red del host y puede alcanzar servicios localhost (se abre en otra pestaña). Reduce separación.
El container puede quedar expuesto a la LAN sin pasar por reglas de publicación esperadas. Debe tener firewall y autenticación propios.
Protege control plane, certificados y puertos entre nodos. Considera cifrado de datos en tránsito según sensibilidad.
Reduce red, pero no impide ataques por filesystem, kernel o devices.
docker network inspect network
docker exec container ip addr
docker exec container ip routeComprueba listeners directamente en host:
ss -lntpSepara:
Revisa:
Host networking falla al arrancar aunque el mismo container funcionara en bridge.
Overlay/VPN puede permitir ping pequeño y fallar con TLS o payloads grandes.
Macvlan no funciona aunque la configuración local parezca correcta.
Algunos drivers o funciones tienen limitaciones. Verifica soporte real.
Host/macvlan no equivalen necesariamente a Engine Linux nativo por la VM intermedia.
Pierdes aislamiento y portabilidad por una mejora quizá irrelevante.
Añade más complejidad que resolver service discovery correctamente.
La red multi-host no programa, repara ni escala workloads por sí sola.
Produce overlaps, rutas ambiguas o IPs duplicadas.
--network none.Docker Compose: fundamentos, donde varios containers, networks, volumes y configuraciones se modelan como una sola aplicación declarativa.