4 Types of Docker network mode

When we create a Docker container using Docker run, we can specify the network mode of the container with the--net option, Docker has the following 4 network modes:

host mode, specified with--net=host.

container mode, specified with--net=container:name_or_id.

None mode, specified with--net=none.

bridge mode, using--net=bridge to specify the default settings.

The following sections describe each of the various network modes of Docker.

1 Host Mode

As we all know, Docker uses Linux namespaces technology for resource isolation, such as PID namespace isolation process, Mount namespace isolated file system, network namespace isolation networks, etc. A network namespace provides a separate networking environment, including network cards, routing, iptable rules, etc., that are isolated from other networks namespace. A docker container is typically assigned a separate network Namespace. However, if you use the host mode when you start the container, the container will not get a separate network Namespace, but instead share a network Namespace with the host. The container will not be virtual out of its network card, configure its own IP, etc., but use the host's IP and port.

For example, we started a Docker container with a Web application on the 10.10.101.105/24 machine and listened to the TCP80 port using host mode. When we perform any similar ifconfig command in the container to view the network environment, we see the information on the host. The external access to the application of the container, the direct use of the 10.10.101.105:80, without any NAT conversion, such as running directly in the host. However, other aspects of the container, such as the file system, the list of processes, and so on, are isolated from the host.

2 Container Mode

After understanding the host mode, this mode is also good to understand. This mode specifies that the newly created container shares a network Namespace with a container that already exists, rather than sharing it with the host. The newly created container does not create its own network card, configures its own IP, but shares the IP, port range, and so on with a specified container. Similarly, two containers, in addition to the network, other such as file system, process list, etc. are still isolated. Two container processes can communicate over the LO network card device.

3 None Mode

This pattern differs from the first two. In this mode, the Docker container has its own network Namespace, but it does not make any networking configuration for the Docker container. In other words, this Docker container does not have network cards, IP, Routing and other information. We need to add network cards, configure IP, etc. for our Docker containers.

4 Bridge Mode

Bridge mode is the default network setting for Docker, which assigns a net Namespace, sets IP, and so on for each container, and connects the Docker container on a host to a virtual bridge. The following highlights this pattern.

4.1 Topology for bridge mode

When the Docker server starts, a virtual bridge named Docker0 is created on the host, and the Docker container that is launched on the host is connected to the virtual bridge. A virtual bridge works like a physical switch so that all the containers on the host are connected through a switch to a two-tier network. The next step is to assign IP to the container, and Docker will select a different IP address and subnet from the RFC1918 defined by the host to assign to Docker0, and the container connected to DOCKER0 will select an unoccupied IP usage from this subnet. such as General Docker will use 172.17.0.0/16 this segment, and assign 172.17.42.1/16 to Docker0 Bridge (using Ifconfig command on the host can be seen DOCKER0, you can think of it as a bridge management interface, Used as a virtual NIC on the host). The network topology under the single-machine environment is as follows, the host address is 10.10.101.105/24.

The process for Docker to complete the above network configuration is roughly the same:

1. Create a pair of virtual NIC Veth pair devices on the host. Veth devices are always paired, and they make up a channel of data that comes in from one device to another. As a result, veth devices are commonly used to connect two of network devices.

2. Docker places one end of the veth pair device in the newly created container and is named Eth0. The other end is placed in the host, named after a similar name VETH65F9, and the network device is added to the Docker0 Bridge, which can be viewed through the Brctl Show command.

3. Assign an IP from the DOCKER0 subnet to the container, and set the DOCKER0 IP address as the default gateway for the container.

After the introduction of the network topology, we then describe how the container communicates in bridge mode.

4.2 container Communication in bridge mode

In bridge mode, containers that are connected to the same bridge can communicate with each other (or, for security reasons, you can disable communication between them, by setting--icc=false in the docker_opts variable so that only two containers are used to communicate with--link).

The container can also communicate with the outside, we look at the iptable rule on the host, we can see such a

-A postrouting-s 172.17.0.0/16! -O Docker0-j Masquerade

This rule will source address 172.17.0.0/16 package (that is, from the Docker container generated packets), and not from the DOCKER0 network card issued, the source address translation, converted to the address of the host network card. That might not be a good idea to understand, give an example to illustrate. Assume that the host has a NIC with a ETH0,IP address of 10.10.101.105/24 and a gateway of 10.10.101.254. Ping Baidu (180.76.3.151) from a container on the host with an IP 172.17.0.1/16. The IP packet is first sent from the container to its own default gateway Docker0, and after the packet arrives at Docker0, it arrives at the host. The host's routing table is then queried to discover that the package should be sent from the host's eth0 to the host's Gateway 10.10.105.254/24. The package is then forwarded to eth0 and sent from Eth0 (the host's ip_forward forwarding should already be turned on). At this time, the above iptable rules will work, the package does Snat conversion, the source address for the eth0 address. In this way, from the outside, the package is sent from the 10.10.101.105, the Docker container is not visible outside.

So, how does the outside machine access the Docker container service? We first create a container with a web app with the following command to map the container's port 80 to port 80 on the host.

Docker run-d--name web-p 80:80 fmzhen/simpleweb

Then look at the changes in the iptable rule and find that there is more than one rule:

-A DOCKER! -I docker0-p tcp-m tcp--dport 80-j DNAT--to-destination 172.17.0.5:80

This rule is to dnat the TCP traffic that the host eth0 receives for the destination port of 80, sending traffic to 172.17.0.5:80, the Docker container we created above. Therefore, the outside world simply accesses the 10.10.101.105:80 to access the service in the container.

In addition, we can customize the IP address, DNS and other information that Docker uses, and even use its own defined bridge, but it works the same way.

4 Types of Docker network mode