Shulou(Shulou.com)05/31 Report--

This article mainly explains "What are Docker's network modes?" Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let Xiaobian take you to learn "What are Docker's network modes?"

When we create Docker containers using Docker Run, we can specify the network mode of the container with the--net option. Docker has the following four 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, specified with--net=bridge, default.

Here is a look at Docker's various network modes.

1 host mode

Docker uses Linux Namespaces to isolate resources, such as PID Namespace to isolate processes, Mount Namespace to isolate file systems, Network Namespace to isolate networks, etc. A Network Namespace provides an independent network environment, including network cards, routing, IPtable rules, etc., isolated from other Network Namespaces. A Docker container is generally assigned a separate Network Namespace. However, if the container is started using host mode, the container will not get a separate Network Namespace, but will share a Network Namespace with the host. The container will not virtualize its own network card, configure its own IP, etc., but use the host's IP and port.

For example, we started a Docker container with web apps in host mode on machine 10.10.101.105/24, listening on tcp port 80. When we execute any ifconfig-like command in the container to view the network environment, all we see is information on the host. For external access to the application in the container, you can directly use 10.10.101.105: 80 without any NAT translation, just like running directly in the host. However, other aspects of the container, such as file systems, process lists, and so on, remain isolated from the host.

2 container mode

After understanding the host pattern, this pattern is easy to understand. This pattern specifies that a newly created container shares a Network Namespace with an existing container, rather than with the host. The newly created container does not create its own network card, configure its own IP, but shares IP, port range, etc. with a specified container. Similarly, the two containers are isolated except for the network aspect, such as file system, process list, etc. The processes of the two containers can communicate through the lo network card device.

3 none mode

This pattern is different from the first two. In this mode, Docker containers have their own Network Namespace, but no network configuration is done for Docker containers. In other words, this Docker container has no network card, IP, routing and other information. We need to add network cards and configure IP for Docker containers ourselves.

4 bridge mode

Bridge mode is Docker's default network setting, assigning a Network Namespace, setting IP, etc. to each container, and connecting Docker containers on a host to a virtual bridge. This pattern is highlighted below.

4.1 topology of bridge pattern

When Docker server starts, a virtual bridge named docker0 is created on the host, and Docker containers started on this host are connected to this virtual bridge. Virtual bridges work similarly to physical switches, so that all containers on a host are connected to a Layer 2 network through the switch. Docker will select an IP address and subnet different from the host from the private IP network segment defined in RFC1918 and assign it to docker0. The container connected to docker0 will select an unoccupied IP from this subnet to use. For example, Docker generally uses the segment 172.17.0.0/16 and assigns 172.17.42.1/16 to Docker0 bridge (docker0 can be seen on the host using ifconfig command, which can be considered as the management interface of the bridge and used as a virtual network card on the host). The network topology in a standalone environment is as follows, with host address 10.10.101.105/24.

Docker completes the above network configuration process is roughly like this:

1. Create a virtual network card veth pair on the host. Veth devices always come in pairs, they form a data channel, and data coming in from one device comes out of the other. Therefore, veth devices are often used to connect two network devices.

2. Docker places one end of the veth pair device in the newly created container and names it eth0. The other end is placed in the host, named like veth75f9, and this network device is added to the docker0 bridge, which can be viewed with the brctl show command.

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

After describing the network topology, let's look at how containers communicate in bridge mode.

4.2 Container communication in bridge mode

In bridge mode, containers connected to the same bridge can communicate with each other (or they can be prevented from communicating for security reasons by setting--icc=false in the DOCKER_OPTS variable, so that only--link can be used to make two containers communicate).

Containers can also communicate with the outside world. If we look at the IPtable rule on the host, we can see this one

-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

This rule will translate packets with source address 172.17.0.0/16 (i.e., packets generated from Docker containers), and not originating from Docker0, to the address of the host NIC. This may not be easy to understand, but give an example. Suppose the host has a NIC eth0, IP address 10.10.101.105/24, and gateway 10.10.101.254. Ping Baidu (180.76.3.151) from a container with IP 172.17.0.1/16 on the host. IP packets are first sent from the container to its default gateway docker0, and when the packets arrive at docker0, they also arrive at the host. It then queries the host's routing table and finds that packets should be sent from eth0 on the host to gateway 10.10.105.254/24 on the host. The packet is then forwarded to eth0 and sent out from eth0 (ip_forward forwarding for the host should already be turned on). At this point, the Iptable rule above will work, doing SNAT translation on the packet, changing the source address to the address of eth0. Thus, to the outside world, this package is sent from 10.10.101.105, and Docker containers are invisible to the outside world.

So, how does an outside machine access Docker container services? We first create a container with a web application and map port 80 of the container to port 80 of the host with the following command:

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

Then look at the changes in the Iptable rule and find that there is an additional rule:

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

This rule is to perform DNAT translation on tcp traffic received by host eth0 with destination port 80, and send the traffic to 172.17.0.5: 80, which is the Docker container we created above. Therefore, outsiders only need to visit 10.10.101.105: 80 to access the services in the container.

In addition, we can customize the IP address, DNS and other information used by Docker, and even use our own bridges, but the way it works is still the same.

At this point, I believe that everyone has a deeper understanding of "Docker's network model," so let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.