Table of contents
2. Communication between containers
2.1. Communication through IP address
2.2. Communication through DNS Server
2.3. Communication through Joined
3. Container cross-node communication
3.1. Implemented through port mapping of the container on the host
3.2. Realized through Docker Overlay network
1 Introduction
In the last article "07.Docker Network Communication Mode", we have a preliminary understanding of several network communication modes in Docker, including bridge, host, container, and none. Through these different network communication modes, containers running on the host can communicate with each other.
2. Communication between containers
The communication methods between containers mainly include:
- Communicate via IP address
- Communicate via Docker DNS Server
- Communicate through joined
2.1. Communication through IP address
When we create a Docker container, the Docker daemon process (daemon process) will assign a virtual machine IP address to each container. However, the external network cannot access the application in the container through this virtual IP address.
Because this virtual IP is only used by the various containers inside Docker to communicate with each other. That is, through this evil ghost IP, the mutual communication between containers in Docker is realized.
Simply simulate the following communication between containers through virtual IP addresses. Here we use the custom network we created in the previous section: mybridge. If you haven't seen the custom network in the previous article, you can move to "07.Docker Network Communication Mode".
1) Create two containers, use the custom mybridge network mode, and specify their IP addresses.
docker run -it --net=mybridge --ip=172.19.0.3 busybox
docker run -it --net=mybridge --ip=172.19.0.4 busybox
2) Execute the ping command in one of the containers to see if the virtual IP addresses in the two containers can communicate.
It can be seen that the network is interoperable.
Of course, there are limitations to this approach:
- When the IP between containers changes, we need to switch frequently; if there are many IP configuration items, then these must be changed.
- When the container connected to the host needs to change according to the environment. Then the host needs to constantly change the container IP, and it needs to be restarted. For example, if you need to connect to container A in the host test environment, but you need to connect to container B in the formal environment, then you need to make constant modifications, and as the number of containers increases, it is more difficult to manage.
2.2. Communication through DNS Server
Inter-container communication over IP, with some limitations mentioned above. Then someone will definitely mention that if these IPs are specifically configured with hosts, and only a fixed hostname needs to be configured in the configuration file, this problem can be solved. That's right, another communication method is mentioned here: Docker DNS Server.
Starting from version 1.10 of Docker, the Docker engine comes with an embedded DNS Server. And we only need to communicate through the container name.
Simple use of DNS Server for container communication.
1) Create two containers, use the custom mybridge network mode, and specify their container names.
# 需要指定dns，不然ping失败
docker run -it --net=mybridge --name=busybox1 --ip=172.19.0.3 --dns=8.8.8.8 busybox
docker run -it --net=mybridge --name=busybox2 --ip=172.19.0.4 --dns=8.8.8.8 busybox
2) In one of the containers, you can execute the ping container name to see if the virtual IP addresses in the two containers can be connected.
Note: DNS Server communication is used here, which is only used in the custom bridge network, and the default bridge network is not acceptable.
2.3. Communication through Joined
Joined is a special inter-container communication method provided by the Docker engine. It essentially uses the container meme because in the container mode, multiple containers share the same network environment and the configuration of the network card. Therefore, in containt mode, containers can communicate directly through localhost or 127.0.0.1.
Simply use the Joined method for container communication.
1) Create a container based on the httpd image, named http1.
docker run -it --name http1 httpd
2) Create a new container based on the busybox image, busybox1, and specify to communicate with the "http1" container through the parameter --net=container:http1.
docker run -it --net=container:http1 --name busybox1 busybox
3) In the container busybox1, you can use wget 127.0.0.1 to directly access the http1 container http service.
wget 127.0.0.1
Response inside http1 container:
3. Container cross-node communication
The above introduces 3 ways to access different containers on the same host, and communicate directly with the help of docker0 bridge. In actual projects, a complex system often needs to deploy many components, and in order to improve the operating efficiency of the components, these components will be deployed on different hosts. So how do containers communicate across hosts?
There are three ways:
- It is realized through the port mapping of the container on the host machine.
- Realized through Docker Overlay network.
- It is realized through a third-party network, such as the flannel network.
3.1. Implemented through port mapping of the container on the host
This method is very simple, which is to map the ports in the container and directly use the host machine for forwarding, so the communication efficiency is relatively low. But the method is also the most direct.
3.2. Realized through Docker Overlay network
The overlay network encapsulates the data of the IP message without changing the existing network, so as to realize the data forwarding function by using the IP routing protocol. In the Overlay network, 16M users can be supported by extending the identification bits.
Docker's Swarm cluster is an implementation of the Overlay network, and the use of the Overlay network requires the support of the registration center. The registry can provide service registration and discovery functions. The registries supported by Docker are ZooKeeper, Consu and ETCD. The following takes ZooKeeper as an example to introduce.
Here I created a new virtual machine, and the information of the two virtual machines is as follows:
| CPU name |
IP address |
deployment service |
| master |
192.168.74.132 |
docker、zookeeper |
| node |
192.168.74.133 |
docker |
1) Select 192.168.74.132 as the master node and install Zookeeper by yourself. Existing installations are ignored.
Start zookeeper after installation:
./zkServer.sh start
# 查看zookeeper状态
./zkServer.sh status
2) The master node modifies the docker.service file. Add support for zookeeper registry.
Add the following, and save:
- --cluster-store: Indicates the ip address and port number of zookeeper.
- --cluster-advertise: Register docker to the address information in zookeeper.
3) Restart the Docker service.
systemctl daemon-reload
systemctl restart docker
4) Modify docker.service on the node (192.168.74.133) machine.
vi /usr/lib/systemd/system/docker.serviceAdd the following content, save, and pay attention to the IP change.
Restart the docker service.
5) Start the zookeeper client.
./zkCli.sh
6) In the zookeeper client, check the registration information of the master and node nodes in zookeeper.
ls /docker/nodes
7) Create an Overlay network on any node, here it is created directly on the master node.
docker network create -d overlay my_overlay_net
8) On the master node, start a container using the network my_overlay_net just created.
docker run -it --net=my_overlay_net --name box1 --dns 8.8.8.8 busyboxYou can see that the IP address of the container is 10.0.0.2.
9) Also on the node node, use my_overlay_net to start a container.
docker run -it --net=my_overlay_net --name box2 --dns 8.8.8.8 busyboxYou can see that the IP address of the container is 10.0.0.3.
10) Now, the two containers can communicate through the virtual IP, or through the DNS Server.
4. Summary
Communication between docker containers is an essential part of actual project deployment using docker. Knowing several network communication methods can better manage container deployment.