Docker Compose 与 Swarm 协同：多容器应用部署策略

? Docker Compose 与 Swarm 协同：多容器应用部署策略

咱做互联网开发的，谁手里还没几个容器化的项目？Docker 家族的工具链里，Compose 和 Swarm 算是俩得力干将。可好多人搞不清这俩该怎么搭配用，要么觉得功能重叠，要么不知道啥时候该上 Swarm。今儿咱就掰开揉碎了聊，看看这俩工具怎么手拉手把多容器应用部署玩明白。

? 先搞懂 Compose 和 Swarm 是干啥的

好多新手容易把这俩工具弄混，其实它们解决的问题压根不在一个层面。Docker Compose 说白了就是个「本地多容器管家」，你平时开发的时候，写个 docker-compose.yml，就能一键启动多个容器，还能定义它们之间的网络、卷挂载、环境变量啥的。比如你本地跑个前后端分离项目，前端容器、后端容器、数据库容器，全靠 Compose 管得明明白白，特适合开发和测试阶段。

那 Swarm 是干啥的呢？它是 Docker 原生的集群管理工具，能把一堆服务器变成一个「虚拟大主机」，你只需要把服务往集群里一丢，Swarm 自己会负责分配容器到各个节点，还能做负载均衡、故障恢复。比如你项目上线了，需要部署到多台服务器上，这时候就得靠 Swarm 来管理集群资源了。简单说，Compose 管「单机多容器」，Swarm 管「多机多容器」，俩工具刚好覆盖了从开发到生产的全流程。

⚙️ 为啥非得让它俩协同工作

有人可能会问：我直接用 Swarm 不就行了？干嘛还要 Compo se？这里面讲究可多了。首先，开发阶段咱讲究的是效率，Compose 的语法简单易懂，改个配置文件就能重启服务，本地调试特别方便。要是一开始就上 Swarm，集群环境复杂，调试起来麻烦死了。

等到了生产环境，单台服务器扛不住了，需要扩展到多台，这时候 Swarm 的优势就来了。但问题是，Swarm 的服务定义跟 Compose 的语法特别像，你完全可以在开发阶段用 Compose 写好配置文件，稍微改改就能扔到 Swarm 里部署，无缝衔接。这就好比写代码，本地用小本本记思路，整理好了再搬到正式文档里，效率老高了。

还有一个关键的点，协同工作能让咱们统一部署规范。不管是开发、测试还是生产环境，都用类似的配置文件，团队成员上手快，维护成本也低。不会出现「开发环境能用，生产环境报错」的糟心事儿。

? 手把手教你搭一套协同部署流程

咱以一个简单的电商项目为例，包含前端（Nginx）、后端（Node.js）、数据库（MySQL），看看怎么从 Compose 过渡到 Swarm。

1. 本地用 Compose 搞定开发环境

首先，写一个 docker-compose.yml，定义三个服务：

yaml

version: '3.8'  
services:  
  web:  
    build: ./frontend  
    ports:  
      - "8080:80"  
    depends_on:  
      - api  
  api:  
    build: ./backend  
    environment:  
      - DB_HOST=db  
  db:  
    image: mysql:5.7  
    environment:  
      - MYSQL_ROOT_PASSWORD=secret  
    volumes:  
      - db_data:/var/lib/mysql  
volumes:  
  db_data:

写完之后，一句 docker-compose up 就能启动整个项目，本地访问 http://localhost:8080 就能看到效果。改代码的时候，重启单个服务就行，特别方便调试。

2. 给 Compose 文件加上 Swarm 所需的配置

Swarm 部署用的是 docker stack deploy 命令，它支持的 docker-compose.yml 格式稍微有点不一样，需要加上 deploy 字段。比如，我们要给每个服务定义副本数、资源限制、负载均衡策略：

yaml

version: '3.8'  
services:  
  web:  
    build: ./frontend  
    ports:  
      - "80:80"  
    deploy:  
      replicas:   
      resources:  
        limits:  
          cpus: '0.5'  
          memory: 512M  
      networks:  
        - frontend  
  api:  
    build: ./backend  
    environment:  
      - DB_HOST=db  
    deploy:  
      replicas:   
      resources:  
        limits:  
          cpus: '0.5'  
          memory: 512M  
      networks:  
        - frontend  
        - backend  
  db:  
    image: mysql:5.7  
    environment:  
      - MYSQL_ROOT_PASSWORD=secret  
    deploy:  
      replicas:   
      resources:  
        limits:  
          cpus: '0.5'  
          memory: 1G  
      networks:  
        - backend  
      volumes:  
        - db_data:/var/lib/mysql  
volumes:  
  db_data:  
networks:  
  frontend:  
  backend:

这里的 deploy 字段就是 Swarm 特有的配置，比如 replicas 定义副本数，让前端服务跑 3 个实例，后端跑 2 个，数据库就跑 1 个主实例。资源限制能避免某个服务把服务器资源吃光，影响其他服务。

3. 初始化 Swarm 集群

假设咱有三台服务器，一台当管理节点，另外两台当工作节点。先在管理节点上运行：

bash

docker swarm init --advertise-addr <管理节点IP>

然后会生成一个加入集群的命令，在两台工作节点上执行这个命令，把它们加入集群。可以用 docker node ls 查看节点状态，确保三台机器都在线。

4. 用 Swarm 部署整个栈

现在，把改好的 docker-compose.yml 传到管理节点，运行：

bash

docker stack deploy -c docker-compose.yml myapp

Swarm 会自动根据配置文件，在集群里创建网络、启动容器，把 3 个前端容器、2 个后端容器、1 个数据库容器分布到各个节点上。这时候用 docker service ls 能看到每个服务的运行状态，用 docker container ls -a 能看到各个节点上的容器。

5. 体验一下 Swarm 的强大功能

比如，咱想给前端服务增加副本数，应对突发流量，只需要改 docker-compose.yml 里的 replicas: 5，然后重新执行 docker stack deploy，Swarm 会自动启动两个新的前端容器，旧的容器还能继续处理请求，完全不影响用户使用。

要是某个节点挂了，Swarm 会自动把上面的容器调度到其他健康的节点上，保证服务不中断。这就是集群管理的魅力，单机故障不影响整体可用性。

? 协同部署的最佳实践

咱在实际操作中，还得注意这些事儿，能少踩不少坑。

1. 统一版本管理

Compose 文件的版本号一定要指定清楚，比如 version: '3.8'，不同的 Docker 版本支持的 Compose 语法不一样，指定版本能避免兼容性问题。Swarm 对 Compose 文件的版本也有要求，一般建议用 3.3 以上的版本，功能更全。

2. 分开环境配置

开发环境和生产环境的配置肯定不一样，比如数据库密码、端口映射、资源限制。咱可以用 Compose 的环境变量或者配置文件来区分，比如在 docker-compose.prod.yml 里写生产环境特有的配置，部署的时候用 docker-compose -f docker-compose.yml -f docker-compose.prod.yml up 来加载多个配置文件，既保持了配置的统一性，又能灵活调整。

3. 做好服务发现

在 Swarm 集群里，容器的 IP 地址是动态变化的，靠 IP 地址互相访问肯定不行。好在 Swarm 自带服务发现功能，同一服务内的容器可以通过服务名直接访问，比如后端服务可以通过 db 这个名字访问数据库容器，跟本地 Compose 里的用法一样，特别方便，不用自己搞复杂的服务发现机制。

4. 监控和日志管理

集群环境下，日志分散在各个节点上，查日志特别麻烦。咱可以用 ELK 栈（Elasticsearch、Logstash、Kibana）来集中管理日志，每个容器把日志输出到标准输出，Logstash 收集各个节点的日志，存到 Elasticsearch 里，再通过 Kibana 可视化查询。监控方面，可以用 Prometheus 和 Grafana，实时监控各个服务的资源使用情况、请求延迟等指标，出了问题能及时发现。

5. 灰度发布和回滚策略

Swarm 支持滚动更新，咱可以给服务设置更新策略，比如每次更新一个副本，等待一段时间观察是否正常，再继续更新下一个。如果更新过程中发现问题，能立即回滚到上一个版本。比如：

yaml

deploy:  
  update_config:  
    parallelism:   
    delay: 10s  
  rollback_config:  
    parallelism:

这样，每次更新一个副本，等 10 秒再更新下一个；回滚的时候，每次回滚两个副本，加快回滚速度。

❓ 常见问题及解决办法

好多人在协同部署的时候会遇到这些问题，咱一个个说解决办法。

1. Compose 文件在 Swarm 里不生效？

首先检查版本号，Swarm 只支持 3.x 版本的 Compose 文件，2.x 版本的不支持。然后看看是不是用了 Swarm 不支持的字段，比如 docker-compose.yml 里的 ports 字段，在 Swarm 里建议用 published 字段代替，或者直接在 deploy 里定义端口映射。另外，Swarm 部署用的是 docker stack deploy，别用成了 docker-compose up，这俩命令适用的场景不一样。

2. 服务之间连不上？

先确认是否在同一个网络里，Swarm 里的服务要通信，必须属于至少一个共同的网络。在 Compose 文件里，用 networks 字段把需要通信的服务加到同一个网络里，比如前面例子里的 frontend 和 backend 网络。另外，检查服务名是否正确，Swarm 里服务名就是容器之间互相访问的域名，写错了肯定连不上。

3. 集群节点加入失败？

首先确保所有节点的 Docker 版本一致，版本差异太大容易出兼容性问题。然后检查防火墙设置，Swarm 需要用到几个特定的端口，比如 2377 用于管理通信，7946 用于节点间通信，4789 用于覆盖网络流量。把这些端口放开，节点之间才能正常通信。另外，管理节点的 IP 地址要正确，用 --advertise-addr 指定的必须是其他节点能访问到的 IP，别用 localhost 或者内网 IP 却暴露在公网环境里。

4. 资源分配不合理，服务频繁重启？

这时候得检查 deploy 里的资源限制配置，比如 cpus 和 memory，是不是给的太少了，导致服务运行时资源不足被杀死。可以先用 docker stats 查看各个容器的资源使用情况，再根据实际情况调整限制值。另外，注意区分 limits 和 reservations，limits 是硬限制，不能超过；reservations 是预留资源，保证容器至少能用到这么多资源，根据服务的重要程度合理设置。

?️ 总结：让 Compose 和 Swarm 成为最佳拍档

Docker Compose 和 Swarm 这俩工具，一个管本地开发，一个管集群部署，天生就是一对好搭档。咱在实际项目中，只要按照「开发用 Compose 快速迭代，生产用 Swarm 稳定扩展」的思路，把配置文件写规范，做好环境区分和集群管理，就能轻松搞定多容器应用的部署难题。

从单机到集群，从开发到生产，这套协同策略能帮咱们省去大量重复配置的时间，把精力集中在业务逻辑上。下次再遇到容器化部署的项目，不妨试试这套组合拳，说不定会有惊喜哦！

【该文章由dudu123.com嘟嘟 ai 导航整理，嘟嘟 AI 导航汇集全网优质网址资源和最新优质 AI 工具】

Docker Compose 与 Swarm 协同：多容器应用部署策略