In that last few parts of our Building a Docker Media Server guide, we discussed hardware selection, installed the Docker Engine hypervisor and made some changes to our host network (Part 1 & Part 2) to ensure it was easy to manage.  Now that we have our media server up and running, it’s a good time to discuss how Docker manages networking.

As I mentioned in the introduction to this series, Docker containers are distinct entities. It’s almost as if they were individual, single app computers running on the network. To allow them to communicate – with each other as well as other devices and network services – Docker Engine configures and manages network access for your app containers. This network access can be configured in various ways depending on your needs.

As you’ll soon discover, when installing and configuring app containers, you’ll need a good understanding of Docker networking basics to ensure those apps can communicate with each other. Without that understanding, things will quickly become confusing. I’ll do my best here to explain these concepts in simple terms to ensure no-one is left behind, but this part of the guide is not designed to be an exhaustive walk through of networking basics per se.

Defining the Terms

Before we dive into Docker networking, let’s define a number of terms I’ll be using to describe our network configuration options in this guide.

  • Host network – this is your regular, physical network that is used by your computers and network devices to communicate. It consists of IP addresses (e.g. 192.168.1.1), subnet masks (255.255.255.0) and (in most cases) is managed by your router – a physical (possibly quite ugly) piece of hardware.
  • Docker network – this is a virtual network of containers that is managed by Docker Engine. By default, it runs with a different set of IP addresses (e.g. 172.17.0.1) and subnet mask (255.255.0.0) than your host/physical network, but can be configured to run in a number of varying modes.
  • Port – a port (or network port) is used to identify specific services on a computer network. You’ll see ports commonly used in URLs when connecting to specific services. By default, you communicate with websites using port 80 or the secure port 443 (HTTPS) but if you wanted to access a specific service on a server, you could use a different port such as http://mylovelyserver.com:8080 or http://192.168.1.100:8088. Many media server apps are accessed on your network via a combination of the IP address (or a domain name, if you have one configured) plus their port number (the number that follows the colon).
  • Port forwarding – also known as port mapping, this is the process of redirecting communications from one IP address/port number combination to another. You may have used port forwarding previously to direct remote web access to a certain computer or server on your network. In this guide, we’ll be using port forwarding to allow communications between services on the Docker network and devices or services on the “external” or physical network. We’ll do this by remapping port numbers on the host network to the relevant Docker container.

Docker Networking Modes

Docker is able to run in a number of network modes. There are pros and cons to each mode, depending on the level of flexibility or simplicity you’re seeking to achieve. They include:

Bridge Mode

In Bridge mode, which is the default, Docker Engine creates a new network – distinct from your regular (host) network and runs your containers within that network. This standalone Docker network is connected to your physical network by way of a virtual router, or bridge, called docker0 with various ports forwarded to your app containers as required.

To illustrate, ensure that Docker Engine is running and let’s take a look at the network configuration. In Linux (Ubuntu Desktop) click the Network icon in the menu bar and select Connection Information. Use the tabs in the window that pops up to switch between your host network and the Docker network.

As you can see, the host network is configured with IP addresses in the 192.168.86.x range, with the docker0 network is using a different range – 172.17.0.x.

On Windows, open a Command Prompt and run the following command to see your network configuration:

ipconfig /all

3

Here you can see a virtual Ethernet adapter (DockerNAT) is managing devices on the 10.0.75.x range, while underneath, a physical Ethernet adapter (on my host network) is running in the same 192.168.86.x range as the Ubuntu device we just looked at.

At the current time, Docker on macOS has a known limitation, in that you cannot view the docker0 network interface on a Mac. If you use the ifconfig command in Terminal (which offers similar functionality to ipconfig in Windows) the docker0 interface is not exposed. Fingers crossed that is sorted out in the future.

On a QNAP NAS, head to Container Station, then in the Preferences section, click the Network tab to view the Docker network settings. In the example below, you can see that a 10.0.3.x address range is being used.

4.png

Finally, on a Synology NAS, open up the Docker package and select Network from the sidebar. Click the arrow next to bridge to expose the IP address range in use.

5.png

 

When bridge mode is used, any Docker containers running on the same host can easily talk to each other directly via IP – no additional configuration is required for that basic level of communication. However, as mentioned, if you wish for those containers to be able to communicate with devices outside of the Docker network, then port forwarding will be required. We’ll cover that as we work through configuration of each app. For now, let’s move on to Docker’s alternative networking modes.

Host Mode

In host mode, Docker Engine uses the IP address of the host computer for containers. This means that the container has full access to the host network (plus associated devices and services) without the need for port forwarding. It can be more straightforward setup but you’re obviously losing a degree of separation.

None Mode

The third type of network mode is called a none network. This provides a container-specific network stack that lacks a network interface (that is, it only has a local loopback interface).

In this guide, we’ll work predominately with Bridge mode. It means we’ll need a little more configuration up front when setting up containers, but ensures we cover media server apps with the default Docker settings in place. You can, of course, feel free to plough your own furrow in Docker networking once you’re feeling happy with the default settings and wish to experiment further.

Viewing Your Docker Networks

To check out the three networks running on your Docker installation, use the following command:

docker network ls

6

When you run a container you can use the --network flag to specify which network you want to run a container on. For example:

docker run --network=host

Note, however, that if you do not specify a network on which to run a container, the default bridge network will be used to connect your containers

Note too that while you can add your own user-defined networks to Docker, the default networks are required and cannot be removed.

If you wish to find out more details about one of your Docker networks, use the following command:

docker network inspect [network name]

So, if you type the command

docker network inspect bridge

You can discover a swathe of information, including the network subnet and gateway (should you ever need it).

7.png

When you run containers on a network, you can repeat that command to show their respective IP addresses.

In the example below, I’m running two containers on this Linux host (craftily named Container1 and Container2). If I repeat the docker network inspect bridge command each container is listed with an associated IP address (172.17.0.3 and 172.17.0.2).

8.png

OK, that’s as far as we’re going to go at this stage with the basics of Docker networking. I really don’t want to disappear down a rabbit hole before we get going with our containers! As we begin to work through the installation and configuration of our media server apps, we’ll come back to discussing networking for sure, but for now this should be sufficient to inform our next steps.