What does the --net = host option really do in the Docker command?
I am a bit of a Docker beginner. I couldn't find a clear description of what this setting does in the docker run command in a deep and a bit confusing way.
Can we use it to access applications running on docker containers without specifying a port? As an example, if I run a webapp deployed via -p 8080:8080
docker image on port 8080 using the command in the docker run command, I know that I will need to access it on port 8080 on the Docker containers ip / theWebAppName. But I can't imagine how it works --net=host
.
source to share
After installing docker, you have 3 networks by default:
docker network ls
NETWORK ID NAME DRIVER SCOPE
f3be8b1ef7ce bridge bridge local
fbff927877c1 host host local
023bb5940080 none null local
I'm trying to keep it simple. So if you run the default container it will be created inside the bridge network (docker0).
$ docker run -d jenkins
1498e581cdba jenkins "/bin/tini -- /usr..." 3 minutes ago Up 3 minutes 8080/tcp, 50000/tcp friendly_bell
The jenkins dockerfile displays ports 8080
and 50000
. These ports are open to a container on the bridge network. Thus, everyone within this bridge network can access the container on port 8080
and 50000
. Everything in the bridge network is in a closed range "Subnet": "172.17.0.0/16",
. If you want to access them from the outside, you need to map the ports to -p 8080:8080
. This will map the port of your container to the port of your real server (host network). This way, access to your server 8080
will not be routed to your bridgenetwork on the port 8080
.
You now also have a host network. That does not allow containerizing networks. So if you run a container on the host's network it looks like this (this is the first one):
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
Difference with ports. Your container is now inside your host network. Therefore, if you open a port 8080
on your host, you will immediately get a container.
$ sudo iptables -I INPUT 5 -p tcp -m tcp --dport 8080 -j ACCEPT
I have opened a port 8080
in my firewall and when I now connect to my server on the port 8080
, I can access my jenkins. I think this blog is also helpful to understand it better.
source to share
This option is --net=host
used to make the programs inside the Docker container look like they are running on the host itself, from a network point of view. It provides the container with more network access than it can get.
Typically you should forward ports from the host machine to the container, but when containers share a host network, any network activity happens directly on the host machine - just as if the program were running locally and not inside the container.
While this means you no longer need to open ports and map them to container ports, it means you need to edit your Dockerfiles to configure the ports each container listens to to avoid conflicts, since you cannot have two containers running. on the same host port. However, the real reason for this setting is to run applications that require network access that are difficult to redirect to a container at the port level.
For example, if you want to run a DHCP server, you need to be able to listen to broadcast traffic on the network and extract the MAC address from the packet. This information is lost during the port forwarding process, so the only way to start a DHCP server in Docker is to start the container as --net=host
.
Generally speaking, --net=host
only needed when you are running programs with very specific, unusual networking needs.
Finally, from a security point of view, Docker containers can listen on many ports, even though they only advertise (expose) one port. This is usually fine as you only forward one expected port, however if you use --host=net
you will get all the container ports listening on the host, even those not listed in the Dockerfile. This means that you need to carefully check the container (especially if it is not yours, for example, the official one provided by the software project) to make sure that you did not accidentally provide additional services on the machine.
source to share
- You can create your own new network like --net = "anyname"
- this is done to isolate services from another container.
- Suppose the same service runs in different containers, but the port mapping remains the same, the first container starts fine, but the same service from the second container fails. so to avoid this, either change the port mappings or create a network.
source to share