Docker容器内微服务向注册中心注册ip地址的问题

Question

微服务启动的时候，会自动向服务注册中心报告自己的ip和端口。但是服务是在docker容器内运行的，注册的ip就成了172开头的docker内部ip, 这个地址是无法被其它机器访问的。

这种情况是不是必须手动将服务注册的地址改成宿主机的地址和端口呢，有其它好方案没

----- update -----
docker 1.12版本以后engine有了swarm模式，经测试使用swarm的overlay网络可解决跨主机通讯问题，这种方案是否合适呢

Answer 1

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

Answer 2

I don’t know much about networking. Please google docker cross-host communication to find some solutions.

Answer 3

Use host to add internal dns

Answer 4

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

Answer 5

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

Answer 6

Very simple, various cross-host docker network communication solutions.

Kubernetes uses flannel.

Answer 7

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