docker中的docker和docker compose无故阻塞一个端口

Question

现在我正在设置一个基于 docker 映像进行部署的应用程序。

我使用 gitlab ci 来：

1. 测试每个服务
2. 构建每个服务
3. Dockerize 每个镜像（创建 docker 容器）
4. 运行集成测试（启动 docker compose，在特殊端口上启动所有服务，运行集成测试）
5. 停止 prod 映像并运行新映像

我为每项服务都这样做了，但遇到了问题。

当我启动我的 docker 容器进行集成测试时，它是在 gitlab ci 任务中设置的。对于每个任务，都使用基于 docker 的运行器。我还安装了我的主机 docker 套接字，以便能够在 docker 中使用 docker。

所以我的 gradle docker 镜像是由 gitlab runner 启动的。然后将安装 docker 并使用 docker compose 启动所有图像。

一个微服务监听 10004 端口。在 docker compose 文件中有一个 11004:10004 端口映射。

我的集成测试尝试连接到端口 11004。但这现在不起作用。

当我在尝试执行集成测试时附加到运行 docker compose 的图像时，我无法通过调用手动执行此操作

wget ip: port 

我只是将消息连接并等待响应。我的测试可以成功连接。我的服务没有记录任何关于新连接的消息。

当我在主机 shell 中执行此 wget 命令时，它就可以工作了。

这是一个公共 IP，在我的容器中，我还可以使用 telnet 和 wget 连接到其他端口。当我尝试从 docker 实例中的 docker 连接时，只有一项服务的一个端口损坏。

当我不使用 docker compose 时，它​​可以工作。 Docker compose 似乎设置了一个特殊的默认网络，它做了一些奇怪的事情。

将网络设置为主机也可以...

那么有没有人在使用 docker compose 的时候也有过这样的体验呢？

相同的设置在 docker for mac 中完美运行，但我的服务器在 Debian 8 上运行。

我现在的解决方案是使用 shell 运行器来避免 docker in docker 问题。它也可以在那里工作。

所以docker中的docker结合docker compose似乎有一个丑陋的bug。

我坐在地铁里写，但我希望描述我的问题也足以谈谈经验。我认为我们不需要一些源代码来找到错误的配置，因为它在 docker 和 Mac 上没有 docker 也可以工作。

Answer 1

我发现docker中的docker仍然有一些奇怪的行为。我通过添加一个新的 gitlab ci 运行程序来解决我的问题，它是一个 shell 运行程序。因此 docker-compose 在我的主机上运行，​​一切正常。

我可以在生产环境中重复使用相同的运行程序来启动 docker 镜像，就像在集成测试中那样。因此，简单的修复对我来说还有另一个好处。

结果是避免陷阱的最佳实践：

只有在真正需要时才在 docker 中使用 docker。

例如，确保您的主机 docker 镜像和您感兴趣的 docker 镜像之间的快速 io 通信。

享受使用 docker 的乐趣（在 docker 中（在 docker 中））：]