The overlay network provided by docker swarm can provide intra-container network communication across hosts. The local container can specify a network at startup to form an internal network. Then nginx can be deployed in host mode on the swarm host, using etcd, consul and other dynamics. Register services and update nginx's reverse proxy configuration to achieve dynamic service discovery. However, overlay currently has the largest performance loss among all cross-host communication methods, reaching 60%. Someone has done a test online, you can check it out. Therefore, for now, the production environment still needs to consider kubernetes or mesos
There are several ideas: 1. When starting the service, the host device reports the IP 2. When starting the service, inject the host IP information into the container environment variable 3. When the registration center receives the registration request, it gets it from the network layer ip
Because containers are dynamic, IP addresses are usually assigned randomly. After using the container scheduling system to automatically start some containers, the access addresses of these containers can be recorded to the service registration center through service registration. In this way, when external services want to access these containers, they can access these containers through service discovery
You can consider other ways 1. Use service orchestration tools such as kubernetes (significant changes to docker) 2. Use registration centers such as consul (significant changes to the registration center code)
If the microservice uses spring cloud, the second option is more recommended, which can perfectly solve this problem
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
The overlay network provided by docker swarm can provide intra-container network communication across hosts. The local container can specify a network at startup to form an internal network. Then nginx can be deployed in host mode on the swarm host, using etcd, consul and other dynamics. Register services and update nginx's reverse proxy configuration to achieve dynamic service discovery.
However, overlay currently has the largest performance loss among all cross-host communication methods, reaching 60%. Someone has done a test online, you can check it out. Therefore, for now, the production environment still needs to consider kubernetes or mesos
I don’t know much about networking. Please google docker cross-host communication to find some solutions.
Use host to add internal dns
There are several ideas:
1. When starting the service, the host device reports the IP
2. When starting the service, inject the host IP information into the container environment variable
3. When the registration center receives the registration request, it gets it from the network layer ip
Because containers are dynamic, IP addresses are usually assigned randomly. After using the container scheduling system to automatically start some containers, the access addresses of these containers can be recorded to the service registration center through service registration. In this way, when external services want to access these containers, they can access these containers through service discovery
Very simple, various cross-host docker network communication solutions.
Kubernetes uses flannel.
You can consider other ways
1. Use service orchestration tools such as kubernetes (significant changes to docker)
2. Use registration centers such as consul (significant changes to the registration center code)
If the microservice uses spring cloud, the second option is more recommended, which can perfectly solve this problem