Why cross-container host communication? Our application may not be deployed on the same machine as the infrastructure it depends on. We may have infrastructure like mysql deployed on test-Node-1 and test applications deployed on test-Node-2, so there will be a need for two containers on two machines to communicate with each other.

Since the author only used two servers here, we will not build a cluster (swarm and K8S). What we expect is the simplest cross-host communication solution. Like swam, it has its own cross-host communication, but we don’t need it today. We use KV memory as the implementation scheme of cross-host communication. Docker supports a variety of KV memory, consul is used here.

Those of you who have played microservice may know that ConusL consul acts as a registry in microservice, and it’s also a KV memory.

1. Install Consul

Consul is installed on the test-node-1 platform, so all operations in this section will be performed on test-Node-1. For convenience, consul will be installed directly in the Docker environment, but there is a downside to this, it will be slow to restart docker. Docker can’t connect consul and will keep trying. You can install it directly to the host if you mind.

docker run -d -p 8500:8500 \ -v /data/consul:/consul/data \ -e CONSUL_BIND_INTERFACE='eth0' \ --name=consul1 \ consul Agent-server-bootstrap-ui-client ='0.0.0.0'Copy the code

⚠️ Note: Consul must be enabled for persistence! Otherwise, data will be cleared after Consul restarts, affecting other containers that have been started! In this way, Docker stores network parameters in Consul and shares them with other Docker instances. The container creation command above has persistence enabled.

2. Verify the container

Execute the following command:

docker ps -a
Copy the code

The execution result is shown below, andSTATUSisUpState.

3. Visual interface

Access 172.16.113.9:8500 from a browser. In normal cases, you can go to the consul management page.

4. Configure docker

⚠️ Both machines need to be operated

This is the key step. We need to modify the configuration of docker to allow docker to access Consul and share network parameters.

#Edit the docker configuration file
vim /etc/docker/daemon.json 
Copy the code

Configuration content added in “cluster – store” : “consul: / / 172.16.113.9:8500”, the results are as follows:

{
"registry-mirrors": [
"https://docker.mirrors.ustc.edu.cn"]."cluster-store": "Consul: / / 172.16.113.9:8500"."graph": "/data/docker"
}
Copy the code

And then you have to reboot

systemctl restart docker
Copy the code

This completes the network access and you can see that the consul has been registered.

5. Create overlay network

Overlay driven networking allows cross-host communication. Now we can create one. To execute on any machine, the author executed on test-Node-2:

Docker network create \ --driver overlay \ --attachable \ --subnet 10.10.0.0/24 \ app_networkCopy the code

The results are shown below:

6. Verify overlay network

You can run docker network ls on test-Node-1 to check the Docker network list. If app_network appears in the list, it indicates that the cross-host communication network is successfully set up. The following figure shows the command execution result:

7, summary

Consul’s key/value store is mainly used here to achieve cross-host container communication. Docker not only supports Consul, but also can use others such as ETCD to achieve communication.