![docker network host docker network host](https://binarymaps.com/wp-content/uploads/2020/03/docker-network1.jpg)
While that seems to be a possible fix it really isn’t. One might suggest that since we didn’t use the ‘-p’ flag docker didn’t know to make a rule in iptables. Let’s take a look at the iptables rule set and see what it has… So what’s going on? Recall that docker makes rather extensive use of iptables for it’s bridging mode.
![docker network host docker network host](https://user-images.githubusercontent.com/1522731/66223639-3d745480-e6d4-11e9-8348-11cc8d7e4b31.png)
Since the IP of the container is the IP of the host one would assume that we should be able to hit our index.html on 10.20.30.101. But before we get carried away, let’s check and see what’s going on with our Apache server. This brings up some interesting possibilities.
![docker network host docker network host](https://goldmann.pl/images/docker-network/network.png)
I hope that makes this obvious, but they’re totally identical. For comparison sake, let’s see them side by side… Rather, we actually have all of the interfaces from the docker2 host. Note that we don’t have an IP address in the 172.17.0.0/16 address space. Once connected, let’s check and see what network interfaces we have in the container… Since we told docker to run this container as a daemon let’s connect to a bash shell on the container using this command… docker exec –ti web1 /bin/bash Once the image is downloaded docker will run the image as a container called ‘web1’. Also note that I’m not specifying any port mappings. Note that I’m passing the ‘–net=host’ flag in the docker run command. The only difference is slight configuration changes in the index.html page so we can see which one is which as well as some Apache config which I talk about more below. There are 4 images I use in this lab all of which are running CentOS with Apache.
DOCKER NETWORK HOST DOWNLOAD
Note: All of the containers I use in these labs are available in my public repo so feel free to download them for testing. I’ll do so with this command… docker run -d -name web1 -net=host jonlangemak/docker:webinstance1 Let’s start a basic web container on the docker2 host. Let’s look at an example so you can see what I’m talking about. Namely, some of the configuration I thought might happen automagically doesn’t actually happen. Host mode seems pretty straight forward but there are some items you need to keep in mind when deploying it. Note that my docker1 host now has two IP interfaces. Keep in mind that all these modes area applied at the container level so we can certainly have a mix of different network modes on the same docker host.įor this post, I’m going to use the same lab I used in the first post but with a minor tweak… This allows for you to create custom network configuration which we’ll talk about more in a later post. It tells docker to put the container in its own network stack but not to do configure any of the containers network interfaces. None – This one is pretty straight forward. This means that while other resources (processes, filesystem, etc) will be kept separate, the network resources such as port mappings and IP addresses of the first container will be shared by the second container. Mapped Container mode – This mode essentially maps a new container into an existing containers network stack. This one is sort of interesting and has some caveats but we’ll talk about those in greater detail below. That is, all of the network interfaces defined on the host will be accessible to the container.
![docker network host docker network host](http://2.bp.blogspot.com/-4CmWzGymKDA/V8nN5fnp4_I/AAAAAAAAAe0/6D_AtV9sElsgzaaX9nIlw82Gs1SFIfp3QCK4B/s1600/Docker%2BHost%2BNetworking.jpg)
That being said, what this really does is just put the container in the hosts network stack. Host mode – The docker documentation claims that this mode does ‘not containerize the containers networking!’. There are really 4 docker ‘provided’ network modes in which you can run containers…īridge mode – This is the default, we saw how this worked in the last post with the containers being attached to the docker0 bridge. In this post, I’d like to start covering the remaining non-default network configuration modes. In our last post we covered what docker does with container networking in a default configuration.