Learn what the Host driver is, how it provides the best performance, how to use it, possible use cases and limitations
Link to video: https://www.youtube.com/watch?v=qice7-Cfgzw
What is the
host network driver in Docker and how does it provide the best network performance?
This blog will try to answer that (and more) as simply as possible.
This blog is the fifth one in a series for Docker Networking.
- blog #1 - Why is Networking important in Docker?
- blog #2 - Basics of Networking
- blog #3 - Docker Network Drivers Overview
- blog #4 - None Network Driver
If you are looking to learn more about the basics of Docker, I’ll recommended checking out the Docker Made Easy series.
Here’s the agenda for this blog:
- What is the
- How to use it?
- When to use it? - possible use cases
- its limitations
Here are some quick reminders:
- A Docker host is the physical or virtual machine that runs the Docker daemon.
- Docker Network drivers enable us to easily use multiple types of networks for containers and hide the complexity required for network implementations.
When a container uses the
hostnetwork driver, the container shares the network stack (namespace) of its host.
This means the network of the container is not virtualized, making the container appear as if it is the host itself, from a networking perspective.
A direct consequence of this is that - if a container using the
host driver publishes a port, let’s say 8000, then that port will also be published on the host machine. If that port is already in use, then the container will not start successfully.
However, in all other ways - like storage, process, and user namespace, the container is isolated from the host.
host driver is only supported on Linux as of now i.e. host driver is not available on Mac or Windows platforms.
Example without specifying any network - using default
Let’s start off by running an nginx container named
app1 in the background (
-d) without specifying any network:
docker run -d --name app1 nginx:alpine
The nginx container by default maps onto port 80 inside the container. Docker uses the default
bridge network driver if no driver is specified.
If we use curl localhost inside the container, we’ll see nginx the nginx index page successfully:
# works docker exec app1 curl localhost
NOTE: Did you know port 80 is the default HTTP port? Therefore
curl localhostautomatically refers to
But if we try to curl localhost from the host machine, it will fail:
# fails curl localhost
This is because we cannot reach the nginx container from the host, as the host and the container are using separate network namespaces (when using the default
The solution is port mapping.
app1 and create it again using the port mapping
docker rm -f app1 docker run -d --name app1 -p 2000:80 nginx:alpine
The port mapping option (
-p 2000:80) instructs Docker to map port 2000 on the host to port 80 on the container.
Let’s check out results using curl:
# fails curl localhost # works curl localhost:2000 # works docker exec app1 curl localhost
We’ll learn more about
bridge drivers in the next part of this series.
As we’d learnt, when using the host driver, the network stack is the same for both the container and host, so there’s no need for port mapping. Let’s check it out.
NOTE: you need a Linux machine to use the
We’ll run a similar nginx container named
app2 using the
docker run -d --name app2 --network host nginx:alpine
Curling localhost will now work:
# works curl localhost
Can you guess why?
The answer will be clear if we...
Check differences in IP configuration
Let’s first look at IP addresses assigned to all network interfaces on the host machine:
Note the number of interfaces and the associated IPs.
What happens if we execute the same command inside the
app1 container (the one using the default
docker exec app1 ip addr
We should certainly see differences between the configuration in the host machine and
app1, since they are using different network namespaces.
Now let’s try that for
app2 container (the one using the
docker exec app2 ip addr
You’ll notice that the network configuration is exactly the same as for the host machine.
This is a clear indication that
host driver makes the container share the host machines network.
One consequence of using the host driver is...
You cannot run multiple containers that bind to the same port using
To demonstrate this, we’ll try to run a very similar nginx container to
app2, but named as
docker run -d --name app3 --network host nginx:alpine
If we check the logs:
docker logs -f app3
We’ll notice that nginx failed to start because the port it tried to bind to (80) was already in use.
We can confirm that
docker ps -a
To end the hands-on lab, we’ll clean up the containers:
docker rm -f app1 app2 app3
Now that we have seen it in action, let’s learn...
The following are some use cases where the
host driver could be suitable.
When the highest network performance is required
hostnetwork driver provides the best network performance compared to the other drivers since it uses the network namespace of the host machine directly and does not require port-mapping / network address translation (NAT).
When a single container needs to handle a large number of ports
If our workload demands a container to handle a large number of ports, then it might be preferable to use the
hostnetwork directly, instead of mapping each port to the host one by one.
When network isolation is not required
This can actually simplify our networking since we won’t need to bother with port mapping or NAT.
Given its properties in mind, we should be aware of the...
Lack of network isolation
As the container’s network is not virtualized using
host, it may not provide the level of isolation required for many multi-container workloads.
Additionally, any networking configuration applied to the host machine will also be applied to the container. If the container is deployed in privileged mode, the container could reconfigure the host’s network stack as well.
This tight binding with the host machine could raise bugs or security issues.
As we have seen, we cannot run multiple containers that use the same port when using the
Only works on Linux machines
hostdriver is only supported on Linux, not on Docker Desktop for Mac or Windows.
In this blog, we learnt about the
host network driver in docker - what it is, how to use it, some possible use cases and its limitations.
By not providing network isolation, the host driver provides the best performance and simplicity. But its drawbacks are to be kept in mind when using the
host driver in production.
I hope I could make things clearer for you, be it just a tiny bit.
In the next blog, we will learn about the
bridge driver - the default network driver, that is likely used the most in development environments.
Thanks for making it so far! 👏
See you at the next one.
Be bold and keep learning.
But most importantly,