docker集装箱按照名称查看（ping）对方的问题

我有三个docker集装箱，

1. Java容器（JC）：为我的Java应用程序（春季开机）
2. elasticsearch容器（EC）：用于ElasticSearch
3. testing容器（TC）：testing容器，用pingtesting进行故障排除

目前，JC无法通过“名称”查看EC。 而当我说“看”我的意思是，如果我做一个平的JC到EC，我得到一个ping: unknown host 。 有意思的是，如果我在TC上做了一个ping到EC，我确实得到了回应。

这是我如何启动容器。

1. docker run -dit --name JC myapp-image
2. docker run -d --name EC elasticsearch:1.5.2 elasticsearch -Des.cluster.name=es
3. docker run --rm --name TC -it busybox:latest

然后，从JC ping EC，我发出以下命令。

 docker exec JC ping -c 2 EC 

我得到一个ping: unknown host

有了TC，因为我已经在shell了，所以我可以做一个ping -c 2 EC然后得到2个回复。

我想也许这与我的Java应用程序有关，但我怀疑它，因为我修改我的Dockerfile只是站起来的容器。 Dockerfile看起来如下所示。

 FROM java:8 VOLUME /tmp 

请注意，您可以通过docker build -no-cache -t myapp-image .创build上述docker docker build -no-cache -t myapp-image . 。

另外请注意，我已经安装了Docker Weave Net，这似乎并没有帮助JC通过名称查看EC。 另一方面，我试图find每个容器的IP地址如下。

1. docker inspect -f '{{ .NetworkSettings.IPAddress }}' JC – > 172.17.0.4
2. docker inspect -f '{{ .NetworkSettings.IPAddress }}' EC – > 172.17.0.2
3. docker inspect -f '{{ .NetworkSettings.IPAddress }}' TC – > 172.17.0.3

我肯定可以通过IP地址从JC上ping EC： docker exec JC ping -c 2 172.17.0.2 。 但是通过IP地址让容器看到对方并没有帮助，因为我的Java应用程序需要将主机名引用作为其configuration的一部分。

任何想法是怎么回事？ 容器是自己的图像吗？ 为什么busybox容器映像能够通过名称ping ElasticSearch容器，但java容器不能？

一些更多的信息。

• VirtualBox 5.0.10
• Docker 1.9.1
• 编织1.4.0
• CentOS 7.1.1503
• 在部署到AWS之前，我在Windows 10桌面上的CentOS VM中运行docker作为临时环境

任何帮助表示赞赏。

Answer 1

在同一个--link守护进程中，使用旧的--link选项来更新每个组件的/ etc / hosts，并确保可以ping另一个：

 docker run -d --name EC elasticsearch:1.5.2 elasticsearch -Des.cluster.name=es docker run -dit --name JC --link ED myapp-image docker run --rm --name TC -it busybox:latest 

然后，一个docker exec JC ping -c 2 EC应该工作。

如果没有，请检查这是否由于基本映像和安全问题引起的：请参阅“ 解决Atomic主机上的容器Ping问题 ”。
JC基于docker/_java:8 ，本身基于jessie-curl ， jessie 。

Answer 2

此默认networking中的容器能够使用IP地址相互通信。 Docker不支持默认网桥上的自动服务发现。 如果要在此默认桥接networking中与容器名称进行通信，则必须通过传统泊坞窗运行 – 链接选项连接容器。 docs.docker.org 。

它也应该使用新的networking。

 docker network create -d bridge non-default docker run --net non-default ... 

没有一个特定的选项将这种行为应用到默认networking（从查看docker network inspect AFAICT）。 我想这只是由选项“com.docker.network.bridge.default_bridge”触发。

在另一个问题的第一部分，build议在Docker 1.9中对此进行了更改。 请注意，Docker 1.9是在稳定版本中打开新的networking系统时。 我从上面引用的用户指南部分在版本1.8中不存在。 Docker 1.9.0“bridge”与自定义桥接networking导致主机文件和SSH_CLIENT envvariables不同