Shulou(Shulou.com)06/03 Report--

Blog outline:

First, Bridge mode (communication between containers on the same Docker server). Second, deploy consul service to achieve Docker container cross-host communication preface:

When you start to use Docker on a large scale, you will find that you need to know a lot about the network. As the most popular lightweight container technology, Docker has many commendable features, such as Docker image management. However, Docker also has many imperfections, and the network is the weak part of Docker. Therefore, it is necessary for us to have an in-depth understanding of Docker's network knowledge in order to meet higher network requirements. This paper first introduces the four network working modes of Docker itself, and then introduces some custom network modes.

When we install Docker, it automatically creates three networks, bridge (create container connects to this network by default), none, and host.

Host: the container will not virtualize its own Nic or configure its own IP, but will use the IP and port of the host. None: this mode turns off the network function of the container, which is equivalent to a loopback network. Bridge: this mode allocates and sets IP for each container, connects the container to a virtual bridge called docker0, and communicates with the host through the docker0 bridge and Iptables nat table configuration. [root@docker ~] # docker network ls # execute this command to view the network created by docker

The three networks mentioned above are explained as follows:

Host: equivalent to the bridging mode in Vmware, it is on the same network as the host, but does not have a separate IP address. As we all know, Docker uses Linux's Namespaces technology to isolate resources, such as PID Namespace isolation process, Mount Namespace isolation file system, Network Namespace isolation network and so on. A Network Namespace provides an independent network environment, including network cards, routing, Iptable rules, etc. are isolated from other Network Namespace. A Docker container typically allocates a separate Network Namespace. However, if you start the container in 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 or configure its own IP, but will use the IP and port of the host. For a container launched in Host mode, when you execute ifconfig in the container, all you see is the information on the host. This mode is not flexible enough and is prone to port conflicts. None: this mode places the container on its own network stack, but does not make any configuration. In fact, this mode turns off the network functionality of the container, similar to changing addresses, and is useful in two cases: the container does not need a network (for example, a batch task that only needs to write disk volumes). Overlay: as the name implies: overlay, but it is not overlay. Its function is to add a network card to the original network of the container and assign an IP address to it. All docker containers can be associated to the same LAN, which is suitable for scenarios where containers and containers communicate across hosts. Bridge: equivalent to the NAT mode in Vmware, the container uses a separate network Namespace and connects to the docker0 virtual network card (default mode). Communicate with the host through docker bridge and IPtables nat table configuration. Bridge mode is the default network setting of Docker. This mode assigns a Network nameSpace to each container, sets IP, and connects the Docker container on a host to a virtual bridge docker0.

In the production environment, Bridge mode and overlay mode are the most widely used. This blog post will focus on these two models.

I. Bridge mode

When Docker server starts, a virtual bridge named docker0 is created on the host, and the Docker container launched on this host is connected to the virtual bridge. The virtual bridge works like a physical switch, so that all containers on the host are connected to a layer 2 network through the switch. Generally, Docker uses the network segment 172.17.0.0and16, and assigns this segment to the docker0 bridge (docker0 can be seen using the ifconfig command on the host), and then assigns the container an IP address of the same network segment.

The network topology in the stand-alone environment is as follows (the host address is 10.10.0.186Universe 24):

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

Create a pair of virtual network card veth pair devices on the host. Veth devices always appear in pairs. they form a channel for data, and data enters from one device and comes out of another. Therefore, veth devices are often used to connect two network devices. 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 after a similar name such as veth75f9, and the network device is added to the docker0 bridge, which can be viewed by the brctl show command. Assign an IP from the docker0 subnet to the container and set the IP address of the docker0 as the default gateway of the container.

When all containers are created based on the default docker0, apart from firewalls, IPtables and other related settings, theoretically, the containers can communicate with each other, but the docker0 network comes with the system, some functions can not be realized, and is not flexible enough.

In fact, we can also customize the creation of the network, and can specify which network segment it belongs to, and so on. This is something that docker 0 cannot achieve, so if each container is not created on the same network (such as Docker0), then? How can they communicate with each other?

Let's take a look at the working mode of Bridge in the following configuration.

The results are as follows:

Based on docker0 (the driver name of docker causes bridge) network to create 2 containers, namely box1 and box2. Create a custom network with the network type bridge and the name my_net1. Create two container box3,box4 based on this network (if the network segment is not specified, the network segment 172.18.0.0 box5 16 will be used, and a network bit will be added based on docker0) to create a custom network with the network type bridge, the name my_net2, and the specified network segment 172.20.18.0 box5 24. Based on this network, two container box5 (172.20.18.6) and box6 (172.20.18.8) will be created. The configuration implements that box2 can communicate with box3, and box4 and box5 can communicate with each other. [root@docker ~] # docker run-itd-- name box1-- network bridge busybox # the option to create a container box1,--network can be omitted. The default is bridge. This is just to show the command [root@docker ~] # docker run-itd-- name box2-- network bridge busybox # ditto, create a container box2 [root@docker ~] # docker network create-d bridge my_net1 # to create a bridging network Name is my_ Net1 [root @ docker ~] # docker run-tid-- name box3-- network my_net1 busybox # create a container based on my_net1 [root@docker ~] # docker run-tid-- name box4-- network my_net1 busybox # ditto, create box4 [root@docker ~] # docker network create-d bridge-- subnet 172.20.18.0 24 my_net2 # create a bridging network my_net2 And specify its network segment [root@docker ~] # docker run-tid-- name box5-- network my_net2-- ip 172.20.18.6 busybox # create a container box5 based on my_net2 network And specify its IP address [root@docker ~] # docker run-tid-- name box6-- network my_net2-- ip 172.20.18.8 busybox # as well as [root@docker ~] # docker network connect my_net1 box2 # above connect box2 to the my_net1 network [root@docker ~] # docker exec box2 ping box3 # for ping testing, you can find that box2 can ping box3. # and if you don't connect box2 to the network my_net1, you will never get through ping. PING box3 (172.18.0.2): 56 data bytes64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.069 ms64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.076 ms [root@docker] # docker network connect my_net2 box4 # connects box4 to the my_net2 network # with the ping test of box2 and box3, it is impossible to ping without connecting box4 to the network where box5 is located. [root@docker ~] # docker exec box5 ip a # View the IP address of box5. # omit part 16: eth0@if17:

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.