Docker Host network alternatives for Windows containers

One of the things I like to do on my spare time is browse around forums, such as Reddit, Stack Overflow, and others, to check on questions people have around Windows containers that are not showing up on comments or here on Tech Community. Recently, a few topics emerged more than once, so I thought I should blog about it to cover in more details.

The first one is about Docker Host Network on Windows containers.

Is Host network available on Windows containers?

The short answer is no. The longer version of this is more complex.

On Linux containers, host network is an option that gives performance on one hand and low flexibility on the other. Host network means standalone containers don’t get an IP address and instead have the container share the container host networking namespace. For scenarios on which you have a large range of ports to be accessible, Host network come in handy as the ports are automatically mapped, with no need for Network Address Translation (NAT). On a Linux container, processes on the container will bind to the port on the host. For example, a website trying to spin its service on HHTP and HTTPS will bind its process to ports 80 and 443, respectively.

The other side of that is that you can’t have multiple instances of containers running and trying to bind the same port on the same node.

What can I use instead on Windows containers?

Since Host network is not available, the alternative will depend on what you are trying to achieve. In terms of networking, by default Windows containers use a NAT network. With this network driver, the container gets an IP address from the NAT network (which is not exposed outside of that network) and ports are mapped from the host to the container. For example, you can have multiple containers listening on their port 80, but when mapping from the host, you expose a different port, such as 8081 for container 1 and 8082 for container 2. This option is great because you don’t have to worry about changing the container itself. On the other hand, you do need to keep tracking of the ports. The other benefit of this option is that you can easily publish a range of ports using something like:

docker run -p 8000-9000:8000-9000

The main thing about the NAT network is that you still need to translate the address from the host to the container. When thinking about scale and performance, this option might not be ideal.

Alternatively, Windows containers offer multiple other options for networking. If you are familiar with Hyper-V, the transparent network is the most simple one. Transparent network works pretty much as an External Virtual Switch on Hyper-V. With that network driver, containers that are attached to this network will get IP addresses from the network – assuming a DHCP server is available, of course, or statically configured per container. You can spin up a new Transparent network using:

docker network create -d "transparent" --subnet 10.244.0.0/24 --gateway 10.244.0.1 -o com.docker.network.windowsshim.dnsservers="10.244.0.7" my_transparent

And to assign this network to new containers, you can use:

docker run --network=my_transparent

Keep in mind this mode is not supported on Azure VMs. This is because you are creating an External Virtual Switch that requires MAC address spoofing.

The Transparent network is a great alternative for small production scenarios and cases on which you want the containers to behave pretty much as any other compute resource in your network. However, as I mentioned, there are other options. In our documentation, we have a great summary of the network types available, their pros and cons, and how to configure each of them:

Hopefully this will give you an idea on what are the alternatives for networking on Windows containers. If you still have a scenario that you’d like to see, let us know in the comments section below.