Host mode networking setup for Docker

Introduction

Laymen explanation

If you have used docker, you may be aware that it provides environment which includes network interface. If your docker instance is http server, then you need high throughput and low latency. It depends on network interface. In case, network interface is directly bound with host NIC, its better. Host mode networking mode of docker performs the same.

Technical explanation

The docker documentation claims that this mode does ‘not containerize the containers networking!’. That being said, what this really does is just put the container in the hosts network stack. That is, all of the network interfaces defined on the host will be accessible to the container.

Host Mode networking uses guide

Host mode seems pretty straight forward but there are some items you need to keep in mind when deploying it. Namely, some of the configuration I thought might happen automagically doesn’t actually happen. Let’s look at an example so you can see what I’m talking about. Let’s start a basic web container on the docker2 host. I’ll do so with this command…

docker run -d --name web1 --net=host jonlangemak/docker:webinstance1

Note: All of the containers I use in these labs are available in my public repo so feel free to download them for testing. There are 4 images I use in this lab all of which are running CentOS with Apache. 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.

Note that I’m passing the ‘–net=host’ flag in the docker run command. Also note that I’m not specifying any port mappings. Once the image is downloaded docker will run the image as a container called ‘web1’. 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 connected, let’s check and see what network interfaces we have in the container…

I hope that makes this obvious, but they’re totally identical. This brings up some interesting possibilities. But before we get carried away, let’s check and see what’s going on with our Apache server. 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. Let’s give it a try…

No rule to allow http. One might suggest that since we didn’t use the ‘-p’ flag docker didn’t know to make a rule in iptables. While that seems to be a possible fix it really isn’t. Starting the container with a port mapping yields the same result. That being said, it’s safe to say that you’re on your own when it comes to host mode networking. Docker will expose the hosts network stack to the container but its then up to you to make the appropriate firewall rules. So let’s add a rule that allows port 80 traffic through iptables…

iptables -I INPUT 5 -p tcp -m tcp --dport 80 -j ACCEPT

Note: Interestingly enough you could actually make this rule from the container itself if you were to pass the ‘privileged=true’ flag in the docker run command. While this may seem appealing from a automation perspective it seems unnecessary and possibly a bad idea.

With the iptables rule in place we should be able to browse to the web page through the host IP address…

At this point I can still get to my web1 index page but what happened with web2? Let’s log into web2 and see what’s going on…

docker exec –it web2 /bin/bash

Let’s check the service status…

That looks even worse. So this isn’t a docker problem, it just the fact that the web instance 1 container is already bound to port 80 on the interfaces of the docker2 host. We can see this binding by checking out netstat from inside the web instance 2 container…

We don’t get the PID info since this container’s processes are different than web instance 1’s but if we head back to the host and run the command again we can see that port is being used by httpd…

The docker2 host is still there but the container is really right up front on the physical edge sine it’s sharing the same network stack as the host. So this all seems very limiting. Fortunately, we do have an option for running multiple identical services on the same docker host. Recall that docker1 now has two IP address, .100 and .200. If we run two Apache instances in host network mode one should be able to use .100 and the other .200.

Again – This isn’t a docker configuration problem. Just as if this was a physical server running Apache we need to tell Apache where to listen and on what port. This is done by modifying the apache config (in my case /etc/httpd/conf/httpd.conf) and setting the ‘Listen’ command. By default, Apache will listen on port 80 on every interface. The default config would look something like ‘Listen 80’. To make this work we need to change the config to something like what is shown below on each respective container…

Fortunately for you, I already have two containers pre-configured with this configuration. Testweb1 is setup to listen on 10.20.30.100:80 and testweb2 is listening on 10.20.30.200:80. Let’s run them on docker1 and see the result…

docker run -d --name web1 --net=host jonlangemak/docker:testweb1

docker run -d --name web2 --net=host jonlangemak/docker:testweb2

Once both are downloaded let’s ensure they are both running…

Looks good, let’s check the docker host to see what it thinks is going on…

Nice, so the docker host sees two Apache processes one listening on each of it’s interfaces. Our final diagram shows each container almost as its own distinct host…