De acuerdo con la documentación de la ventana acoplable sobre redes de puentes :

En términos de Docker, una red de puente utiliza un puente de software que permite que los contenedores conectados a la misma red de puente se comuniquen, mientras proporciona aislamiento de los contenedores que no están conectados a esa red de puente.

De acuerdo con la documentación de la ventana acoplable sobre redes de host

Si usa el controlador de red del host para un contenedor, la pila de red de ese contenedor no está aislada del host de Docker. Por ejemplo, si ejecuta un contenedor que se une al puerto 80 y utiliza una red de host, la aplicación del contenedor estará disponible en el puerto 80 en la dirección IP del host.

Si desea implementar varios contenedores conectados entre ellos con una red interna privada, utilice la red puente. Si desea implementar un contenedor conectado a la misma pila de red que el host (y acceder a las mismas redes que el host), use redes de host. Si simplemente desea publicar algunos puertos , ejecute el contenedor con la opción --publish o -p , como -p 8080:80 .

En su primer ejemplo, esperaría que se pudiera acceder a la aplicación en la dirección IP del host en el puerto 8000 (el puerto reasignado) y en el segundo puerto 5000 (no hay opción de reasignación con la red del host). Si hay algún tipo de problema de configuración o firewall que impide que esto funcione, debe solucionarlo, en lugar de piratearlo con --net host .

La red de puente es el modo de red estándar de Docker. Deberías preferirlo si es posible. Hay, de manera confusa, dos modos diferentes, pero el formulario que muestra con una docker network create es una buena práctica y debe usarlo si es posible. La red de host desactiva por completo el aislamiento de la red de Docker. Significa que los contenedores ven y usan exactamente las mismas interfaces de red que tiene disponible el host, sin una capa NAT intermedia.

Con las redes de puente, necesita la opción docker run -p para hacer visibles puertos específicos fuera de Docker. Como operador, puede reasignar puertos, vincularse a interfaces específicas en un sistema de múltiples terminales o simplemente negarse a hacer que un servicio sea visible para otros hosts. El formulario docker network create explícito permite que los contenedores se conecten entre sí usando su docker run --name como nombres de host. Si está ejecutando varias pilas de aplicaciones en el mismo host, se pueden aislar parcialmente entre sí mediante el uso de redes separadas. Cada contenedor tiene su propio espacio de red independiente y localhost significa "este contenedor". Este modo también es un paso fácil hacia los modelos de red en sistemas de múltiples hosts como Docker Swarm o Kubernetes.

Con la red de host, nada de lo anterior funciona en absoluto; no puede usar docker run --net host -p ... y no tiene elección sobre dónde o cómo se exponen los puertos. No puede llegar a otros contenedores, a menos que estén configurados para publicar puertos ellos mismos. Dado que está utilizando la red del host, localhost significa la vista que el host tiene de sí mismo.

Por todo lo que se recomienda con frecuencia en las respuestas de SO, --net host rara vez es necesario. Los dos casos en los que puedo pensar son para un servicio que necesita interrogar la pila de red del host (por ejemplo, un sistema de descubrimiento de servicios como Consul necesita saber cada puerto que el host está escuchando para anunciar eso) o para un servicio que tiene un conjunto grande o inconsistente de puertos que utiliza. Si está utilizando --net host porque ha codificado localhost en su aplicación, es mejor que lo haga configurable.