Docker Compose 网络原理与实战：同一 Compose 服务间如何稳定通信

火车叼位
14 阅读10分钟

在使用 Docker Compose 编排多个服务时，一个最常见的问题就是：

同一个 compose 文件里的多个 services，到底怎么互相通信？一共有多少种方案？

如果只说结论，其实很简单：

  • 最常用、最推荐的方式：把服务放到同一个网络里，直接用服务名访问
  • 如果按工程实践细分，常见可分为 4 类主流方案
  • 如果再扩展到跨项目、兼容旧配置等场景，可以理解为 6～8 种变体

这篇文章会从原理、配置、示例和避坑四个层面，把 Docker Compose 服务通信一次讲清楚。

一、先说结论：最推荐的方式是什么？

在同一个 Docker Compose 项目里，服务间通信的标准做法是：

  1. 让服务加入同一个网络
  2. 通过 service 名称 直接访问目标服务
  3. 不依赖固定 IP
  4. 通常不需要把内部服务端口暴露给宿主机

例如：

services:
  app:
    image: myapp

  redis:
    image: redis:7

启动后，app 容器里就可以直接访问：

redis:6379

这里的 redis，就是 Compose 里的 service 名。

二、Docker Compose 为什么能通过服务名通信？

Docker Compose 启动项目时，会自动创建一个默认网络。
同一个 Compose 项目中的服务，默认都会加入这个网络。

Docker 内置了 DNS 服务发现能力，因此在同一网络中的容器可以通过：

  • service 名
  • network alias

来解析到对应容器的地址。

也就是说，Compose 中最常见的服务发现方式不是 IP，而是：

  • db
  • redis
  • api

这样的逻辑名称。

这也是为什么在生产或开发环境中，不建议手写容器 IP。
容器重建后 IP 可能会变化，但服务名通常不会变。

三、同一个 Compose 下 services 通信，有多少种方案？

如果从现代 Docker Compose 实践来分，可以归纳为 4 类主流方案：

  1. 默认网络 + 服务名访问
  2. 自定义 network
  3. network alias（网络别名）
  4. host 网络模式

如果再扩展场景，还可以加上：

  1. 多网络组合
  2. external network（外部网络，跨 Compose 项目通信）
  3. 通过宿主机端口转发访问
  4. links（历史方案，不推荐）

严格说，“有多少方案”没有唯一标准答案。
但在实际工程里，重点掌握前 2～4 种 就够了。

四、方案一：默认网络 + 服务名访问

这是最简单、最常见、也是最推荐的方式。

示例

version: "3.8"

services:
  app:
    image: curlimages/curl:8.8.0
    command: ["sleep", "infinity"]

  api:
    image: hashicorp/http-echo
    command: ["-text=hello-compose", "-listen=:5678"]

启动：

docker compose up -d

进入 app 容器：

docker compose exec app sh

测试访问：

curl http://api:5678

如果一切正常，会返回：

hello-compose

特点

  • 配置最少
  • Compose 自动创建默认网络
  • 可以直接通过 service 名 通信
  • 不需要关心容器 IP

适用场景

  • 本地开发
  • 单项目微服务编排
  • Web + API + DB 的典型三层结构

五、方案二：自定义 network

当项目稍微复杂一点时，通常会手动定义网络，而不是完全依赖默认网络。

这样做的好处是：

  • 更清晰
  • 更安全
  • 更容易隔离前后端、数据库等不同层次的服务

示例：前端、后端、数据库隔离

version: "3.8"

services:
  frontend:
    image: nginx:alpine
    networks:
      - web

  backend:
    image: nginx:alpine
    networks:
      - web
      - dbnet

  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: 123456
    networks:
      - dbnet

networks:
  web:
  dbnet:

通信关系分析

  • frontend 和 backend 都在 web 网络中，因此能互通
  • backend 和 db 都在 dbnet 网络中，因此能互通
  • frontend 不在 dbnet，所以不能直接访问 db

适用场景

  • 前后端分层
  • 网关与内部服务隔离
  • 数据库只暴露给后端
  • 更符合最小权限原则

六、方案三：使用网络别名 alias

有时你希望一个服务除了 service 名之外，还能用其他域名访问。
这时可以给它配置 network alias。

示例

version: "3.8"

services:
  app:
    image: curlimages/curl:8.8.0
    command: ["sleep", "infinity"]
    networks:
      - appnet

  redis:
    image: redis:7
    networks:
      appnet:
        aliases:
          - cache
          - redis-master

networks:
  appnet:

此时在 app 中，下面几个主机名都可以访问到 redis：

  • redis
  • cache
  • redis-master

例如：

redis-cli -h cache

适用场景

  • 兼容旧系统中的主机名配置
  • 服务迁移时保持地址不变
  • 同一个服务暴露多个逻辑名称

七、方案四：host 网络模式

这是另一类通信方式，但它并不是 Compose 内部服务发现的主流方案。

示例

services:
  app:
    image: nginx:alpine
    network_mode: host

它的含义

host 模式下，容器直接使用宿主机网络栈，而不是 Docker 的桥接网络。

也就是说：

  • 容器没有独立的容器网络隔离
  • 服务直接监听在宿主机网络上
  • 一般不再需要 ports 映射

优点

  • 网络路径更直接
  • 某些场景下配置简单
  • 对某些需要宿主机网络能力的服务有帮助

缺点

  • 隔离性差
  • 不适合作为普通服务间通信的首选
  • 在不同平台上的行为差异需要特别注意

适用建议

除非你明确知道自己为什么要用 host，否则在 Compose 内部服务互联场景下，优先使用 bridge 网络 + 服务名访问。

八、扩展方案一：多网络组合通信

一个服务可以加入多个网络，这在复杂系统中非常常见。

示例

version: "3.8"

services:
  gateway:
    image: nginx:alpine
    networks:
      - public
      - internal

  user-service:
    image: nginx:alpine
    networks:
      - internal

  order-service:
    image: nginx:alpine
    networks:
      - internal

networks:
  public:
  internal:

说明

  • gateway 同时加入 public 和 internal
  • user-service、order-service 只在 internal
  • 这样网关既能接入外部流量，又能访问内部服务

这是很多微服务架构里非常常见的设计。

九、扩展方案二：external network 跨 Compose 项目通信

如果不是同一个 Compose 项目，而是多个 Compose 项目之间想互通，可以把它们接入同一个外部网络。

先创建网络

docker network create shared-net

Compose 配置

services:
  app:
    image: nginx:alpine
    networks:
      - shared-net

networks:
  shared-net:
    external: true

另一个 Compose 项目也加入同一个 shared-net，就可以通过服务名或别名进行通信。

适用场景

  • 多个 Compose 项目协作
  • 公共网关、日志、监控等基础设施共享
  • 分仓库部署但需要互联

十、扩展方案三：通过宿主机端口访问

严格说，这不是 Compose 内部服务通信的最佳方式，但确实也是一种“能连通”的方式。

例如：

services:
  db:
    image: mysql:8
    ports:
      - "3306:3306"

此时其他容器理论上可以绕一圈，通过宿主机地址访问这个端口。
但这种方式存在几个问题：

  • 增加了绕路和复杂度
  • 依赖宿主机网络环境
  • 不利于移植
  • 不符合 Compose 内部服务发现的最佳实践

因此：

同一个 Compose 项目内部，优先用服务名，不要优先用宿主机端口。

十一、历史方案：links，不建议再用

Docker 早期支持 links 用于容器间连接，但现在已经不再是推荐做法。

原因很简单：

  • 同网络下的 DNS 服务发现已经足够好用
  • links 可读性和可维护性更差
  • 官方更推荐使用用户自定义网络

如果你看到老项目里有 links，通常可以考虑逐步迁移到标准网络方案。

十二、Compose 内部通信最容易踩的坑

1. 把 localhost 当成别的服务

这是最常见错误。

在容器里：

  • localhost
  • 127.0.0.1

指向的是当前容器自己，不是其他 service，也不是宿主机。

例如在 app 容器里：

curl http://localhost:6379

访问的是 app 自己，而不是 redis。

正确方式应当是：

curl http://redis:6379

2. 误以为 services 通信必须写 ports

不是。

ports 的作用

用于把容器端口映射到宿主机，给宿主机或外部访问。

容器间通信

只要在同一网络里，并且目标服务在容器内监听了对应端口，通常就可以直接访问。

例如：

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: 123456

即使不写 ports，同网络中的其他服务仍然可以访问：

db:3306

3. 误以为 depends_on 就代表服务可用

depends_on 只能保证启动顺序，不能保证服务已经准备就绪。

例如数据库容器虽然启动了，但数据库初始化可能还没完成。
这时应用去连接，仍然可能失败。

更稳妥的方式包括：

  • 应用内做重试
  • 增加 healthcheck
  • 使用等待脚本

4. 过度依赖 container_name

Compose 支持手动指定容器名：

container_name: my-db

但在 Compose 的日常使用中，通常更推荐使用 service 名 来做服务发现。

原因包括：

  • service 名更符合 Compose 设计
  • 更利于维护
  • 更适合后续扩展和自动化管理

十三、一个完整示例：Web + API + MySQL

下面给一个更接近真实项目的例子。

version: "3.8"

services:
  web:
    image: nginx:alpine
    depends_on:
      - api
    networks:
      - appnet
    ports:
      - "8080:80"

  api:
    image: node:18-alpine
    working_dir: /app
    command: ["sh", "-c", "node server.js"]
    volumes:
      - ./api:/app
    depends_on:
      - db
    networks:
      - appnet

  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: 123456
      MYSQL_DATABASE: demo
    networks:
      - appnet

networks:
  appnet:

通信路径

  • 浏览器访问宿主机 localhost:8080，进入 web
  • web 通过 http://api:3000 调用 API
  • api 通过 db:3306 连接 MySQL

这里的重点

  • web -> api 用服务名 api
  • api -> db 用服务名 db
  • 只有 web 对外暴露了 ports
  • api 和 db 的内部通信不需要暴露端口给宿主机

十四、到底该怎么选？

如果你只是想知道“Compose 下服务怎么互相通信”，可以按这个选择：

场景一：普通项目

直接使用 默认网络 + 服务名访问

这是首选。

场景二：希望隔离不同层

使用 自定义网络

例如：

  • web
  • app
  • db

分别接入不同网络，后端做桥梁。

场景三：需要兼容旧域名或逻辑名

使用 alias

场景四：需要跨 Compose 项目通信

使用 external network

场景五：明确需要宿主机网络能力

才考虑 host 模式

十五、最佳实践总结

把这篇文章压缩成几条可执行建议，就是：

  1. 优先使用同一网络 + 服务名访问
  2. 不要写死容器 IP
  3. 容器内不要把 localhost 当成其他服务
  4. 内部服务通信通常不需要 ports
  5. 复杂项目建议显式定义 networks
  6. 数据库等核心服务建议放在独立内部网络
  7. depends_on 不等于服务已就绪
  8. 除特殊需求外，不优先使用 host 模式
  9. 老项目中的 links 可以逐步淘汰

十六、结语

Docker Compose 的服务间通信并不复杂，关键是理解两个核心点：

  • 网络隔离由 network 决定
  • 服务发现通常靠 service 名，而不是 IP

所以如果你问：

同一个 Compose 下的 services 如何互相通信？

最标准、最实用的答案就是：

让它们处于同一个网络中，然后直接通过服务名访问。

如果你再进一步问：

一共有多少方案？

那可以回答：

  • 主流看 4 类
  • 扩展看 6～8 种
  • 真正常用且推荐的，核心还是 默认网络 / 自定义网络 + 服务名通信

参考资料

以下为可核实的官方与权威文档方向，建议发布时保留：

  1. Docker Docs - Compose networking
    docs.docker.com/compose/how…

  2. Docker Docs - Networking in Compose
    docs.docker.com/compose/

  3. Docker Docs - Bridge network driver
    docs.docker.com/network/dri…

  4. Docker Docs - Use host networking
    docs.docker.com/network/hos…

注：不同 Docker / Compose 版本在文档入口路径上可能有调整，但上述主题均可在 Docker 官方文档中查证。

avatar
文章
阅读
粉丝