在使用 Docker Compose 部署应用时，若遇到 `MongoError: connect ECONNREFUSED` 导致 MongoDB 连接失败，通常是由于服务容器未正确配置网络所致。本文将深入探讨 Docker Compose 中容器间通信的原理，并提供通过定义共享网络来解决此类连接问题的详细教程，确保应用服务能顺利连接数据库。
1. 理解 Docker Compose 中的 MongoDB 连接失败问题
在使用 Docker Compose 编排多个服务时，如应用服务（app 或 game）需要连接到数据库服务（mongo2），可能会遇到类似 MongoError: failed to connect to server [mongo2:27018] on first connect [MongoError: connect ECONNREFUSED 172.19.0.3:27018] 的错误。这个错误明确指出，尝试连接 mongo2:27018 失败，因为连接被拒绝（ECONNREFUSED）。这通常不是 MongoDB 服务本身未运行或端口错误的问题，而是连接方无法正确解析或路由到 MongoDB 服务的问题，即容器间的网络通信障碍。
考虑以下一个典型的 docker-compose.yaml 配置和连接代码片段：
version: '3'
services:
app:
image: chaseloyd/portfolio-site:latest
ports:
- "3000:3000"
mongo2:
image: mongo
container_name: mongo2
restart: always
ports:
- "27018:27018"
game:
image: chaseloyd/multiplayer-game:latest
ports:
- "3030:3030"
links:
- "mongo2"应用连接代码：
var mongoose = require("mongoose");
mongoose.connect("mongodb://mongo2:27018/db");尽管 game 服务使用了 links 关键字来连接 mongo2，但如果其他服务（如 app）也尝试连接 mongo2，或者 links 的行为在特定 Docker Compose 版本或复杂场景下未能按预期工作，就可能出现连接失败。核心问题在于，所有需要相互通信的服务必须位于同一个 Docker 网络中，以便 Docker 的内置 DNS 服务能够通过服务名进行解析。
2. Docker Compose 网络机制详解
Docker Compose 在默认情况下会为 docker-compose.yaml 文件中定义的所有服务创建一个默认的桥接网络。在这个默认网络中，服务可以通过其服务名（例如 mongo2）相互发现和通信。然而，在某些情况下，尤其是在 version: '3' 及其更高版本中，为了更明确地控制网络拓扑、实现更好的隔离性或解决复杂的通信需求，显式定义和分配自定义网络是更健壮的做法。
- 服务发现： Docker 引擎内置了一个 DNS 服务器。当一个容器尝试通过服务名（如 mongo2）连接另一个容器时，Docker DNS 会将该服务名解析为对应容器的 IP 地址。这个机制的前提是，这两个容器必须共享同一个网络。
- links 关键字的局限性： links 是 Docker Compose version: '2' 及更早版本中用于容器间通信的方式，它在容器的 /etc/hosts 文件中添加条目。但在 version: '3' 及更高版本中，links 被认为是遗留特性，官方推荐使用 networks 来管理容器间通信，因为它提供了更灵活和强大的网络管理能力。
3. 解决方案：定义和使用自定义网络
解决 MongoError: connect ECONNREFUSED 的最有效方法是显式地定义一个自定义网络，并将所有需要相互通信的服务（例如应用服务和数据库服务）都加入到这个网络中。
步骤：
- 在 docker-compose.yaml 文件底部定义一个网络。
- 在每个需要通信的服务下，通过 networks 关键字将其加入到这个自定义网络中。
以下是修正后的 docker-compose.yaml 示例：
version: '3'
services:
app:
image: chaseloyd/portfolio-site:latest
ports:
- "3000:3000"
networks: # 将 app 服务加入 test-network
- test-network
mongo2:
image: mongo
container_name: mongo2
restart: always
ports:
- "27018:27018"
networks: # 将 mongo2 服务加入 test-network
- test-network
game:
image: chaseloyd/multiplayer-game:latest
ports:
- "3030:3030"
links:
- "mongo2" # 尽管使用了 links，但将其加入自定义网络是更推荐的做法
networks: # 将 game 服务加入 test-network
- test-network
networks: # 定义一个名为 test-network 的自定义网络
test-network:通过上述配置，app、mongo2 和 game 服务都被显式地放置在了 test-network 这个自定义网络中。这样一来，当 app 或 game 容器中的应用代码尝试连接 mongodb://mongo2:27018/db 时，Docker 的内置 DNS 服务就能在 test-network 内部正确地将 mongo2 解析为 MongoDB 容器的内部 IP 地址，从而建立成功的连接。
应用代码中的连接字符串 mongodb://mongo2:27018/db 无需修改，因为 mongo2 作为服务名，在共享网络中是可解析的。27018 是 MongoDB 容器内部监听的端口。
4. 最佳实践与注意事项
- 显式网络的重要性： 尽管 Docker Compose 会自动创建默认网络，但显式定义和使用自定义网络是推荐的最佳实践。它提供了更清晰的网络拓扑、更好的服务隔离性，并使管理和调试变得更容易。
- 端口映射 (ports) 与容器间通信： ports 关键字（如 27018:27018）是将容器内部端口暴露给宿主机。对于容器间的通信，通常只需要知道目标容器的内部端口（例如 MongoDB 的默认端口 27017 或本例中的 27018），而无需通过宿主机的端口映射。
- links 的替代： 在 Docker Compose version: '3' 中，应优先使用 networks 来管理服务间的依赖和通信，而非 links。links 可能会在未来版本中被移除。
- 网络隔离： 如果您的应用包含多个不相关的服务组，可以为每个组创建独立的网络，以实现更好的网络隔离和安全性。
-
调试技巧：
- 使用 docker network ls 查看当前 Docker 网络列表。
- 使用 docker inspect
查看特定容器的网络配置，包括其所属网络、IP 地址等信息。 - 在连接失败的容器内部，尝试使用 ping
或 telnet 来测试网络连通性。
5. 总结
MongoError: connect ECONNREFUSED 在 Docker Compose 环境中是一个常见的连接问题，其根源往往在于容器间的网络通信配置不当。通过在 docker-compose.yaml 文件中显式定义一个自定义网络，并将所有需要相互通信的服务（如应用服务和数据库服务）加入到该网络中，可以有效解决此类问题。这种做法不仅确保了服务的正确连接，也提升了 Docker Compose 配置的清晰度和可维护性，是构建健壮容器化应用的关键一步。
