Solución:
Después de la instalación de la ventana acoplable, tiene 3 redes por defecto:
docker network ls
NETWORK ID NAME DRIVER SCOPE
f3be8b1ef7ce bridge bridge local
fbff927877c1 host host local
023bb5940080 none null local
Estoy tratando de mantener esto simple. Entonces, si inicia un contenedor de forma predeterminada, se creará dentro de la red del puente (docker0).
$ docker run -d jenkins
1498e581cdba jenkins "/bin/tini -- /usr..." 3 minutes ago Up 3 minutes 8080/tcp, 50000/tcp friendly_bell
En el dockerfile de jenkins los puertos 8080 y 50000 están expuestos. Esos puertos están abiertos para el contenedor en su red de puentes. Entonces, todo dentro de esa red de puentes puede acceder al contenedor en el puerto 8080 y 50000. Todo en la red de puentes está en el rango privado de "Subnet": "172.17.0.0/16", Si desea acceder a ellos desde el exterior, debe mapear los puertos con -p 8080:8080. Esto asignará el puerto de su contenedor al puerto de su servidor real (la red de host). Entonces, accediendo a su servidor en 8080 se enrutará a su red de puente en el puerto 8080.
Ahora también tienes tu red de host. Lo que no contenedoriza la red de contenedores. Entonces, si inicia un contenedor en la red de host, se verá así (es el primero):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1efd834949b2 jenkins "/bin/tini -- /usr..." 6 minutes ago Up 6 minutes eloquent_panini
1498e581cdba jenkins "/bin/tini -- /usr..." 10 minutes ago Up 10 minutes 8080/tcp, 50000/tcp friendly_bell
La diferencia está en los puertos. Su contenedor ahora está dentro de su red de host. Entonces, si abres el puerto 8080 en su host accederá al contenedor inmediatamente.
$ sudo iptables -I INPUT 5 -p tcp -m tcp --dport 8080 -j ACCEPT
He abierto puerto 8080 en mi firewall y cuando ahora estoy accediendo a mi servidor en el puerto 8080 Estoy accediendo a mis jenkins. Creo que este blog también es útil para entenderlo mejor.
los --net=host La opción se usa para hacer que los programas dentro del contenedor Docker parezcan estar ejecutándose en el propio host, desde la perspectiva de la red. Permite al contenedor un mayor acceso a la red del que normalmente puede obtener.
Normalmente, tiene que reenviar puertos desde la máquina host a un contenedor, pero cuando los contenedores comparten la red del host, cualquier actividad de red ocurre directamente en la máquina host, tal como lo haría si el programa se ejecutara localmente en el host en lugar de dentro de un envase.
Si bien esto significa que ya no tiene que exponer puertos y asignarlos a los puertos del contenedor, significa que debe editar sus Dockerfiles para ajustar los puertos en los que escucha cada contenedor, para evitar conflictos, ya que no puede tener dos contenedores operando en el mismo Puerto host. Sin embargo, la verdadera razón de esta opción es la ejecución de aplicaciones que necesitan acceso a la red y que es difícil de reenviar a un contenedor a nivel de puerto.
Por ejemplo, si desea ejecutar un servidor DHCP, debe poder escuchar el tráfico de transmisión en la red y extraer la dirección MAC del paquete. Esta información se pierde durante el proceso de reenvío de puertos, por lo que la única forma de ejecutar un servidor DHCP dentro de Docker es ejecutar el contenedor como --net=host.
Generalmente hablando, --net=host solo es necesario cuando se ejecutan programas con necesidades de red muy específicas e inusuales.
Por último, desde una perspectiva de seguridad, los contenedores Docker pueden escuchar en muchos puertos, aunque solo anuncian (exponen) un solo puerto. Normalmente esto está bien ya que solo reenvía el puerto esperado único, sin embargo, si usa --net=host entonces obtendrás todos los puertos del contenedor que escuchan en el host, incluso aquellos que no figuran en el Dockerfile. Esto significa que deberá verificar el contenedor de cerca (especialmente si no es suyo, por ejemplo, uno oficial proporcionado por un proyecto de software) para asegurarse de no exponer inadvertidamente servicios adicionales en la máquina.