先说清楚：什么时候单机不够用了#

前面十几篇里，我们的服务都跑在一台机器上：一份 Compose 文件、一台服务器、一个 docker compose up -d 搞定。这套打法简单、省心，但它有两个天花板，撞上任何一个，单机就真的不够用了。

第一个是可用性。单机意味着单点：服务器宕机、Docker 守护进程崩溃、机房断网，服务就整体消失。Watchtower 更新容器时那几秒的重启窗口可以忍，但机器本身挂掉几小时这种事，如果服务是对外营业的，就忍不了。更现实的场景是：你想给服务器打补丁、换内核、重启 Docker，单机上无路可退，只能挑深夜停机维护。

第二个是横向扩容。单机的 CPU 和内存就是上限。某个服务火了、流量翻了十倍，你在单机上能做的只有把 replicas 写大——可副本再多也挤在同一台机器上抢资源，机器本身就是瓶颈。真正需要的是把副本分散到多台机器上，机器不够了再加一台。

撞上这两堵墙，就需要”集群编排”：让多台机器组成一个整体，你只声明”我要这个服务跑 3 个副本”，系统自己决定每个副本落在哪台机器上，某台机器挂了，副本自动在别的机器上补回来。

做这件事的工具，名气最大的是 Kubernetes，但它概念多、组件重，学习曲线陡峭。其实 Docker 自己就内置了一个编排器——Swarm。它就藏在你已经装好的 Docker 里，不用额外安装任何软件，一条命令就能把单机 Docker 变成集群节点。Swarm 的定位就是：用你已经会的 Compose 知识，平滑地跨到多台机器上。本篇我们用三台机器把集群组起来，跑服务、玩自愈、做滚动更新，最后把 Swarm、单机 Compose、Kubernetes 三者的选型边界讲清楚。

WARNING

Swarm 是 Docker 的内置功能，docker swarm 系列命令在装好 Docker Engine 的机器上直接可用。本文的三台机器请提前各自按系列第一篇的方法装好 Docker，并确保它们之间网络互通（同机房、同内网最好）。

核心概念：先把词对上号#

Swarm 的概念不多，一张表对完号，后面实战就不会晕。

这里面最重要的是理解**“服务”和”容器”的区别**。以前你操作的是容器：docker run 出来一个，死了就是死了。现在你操作的是服务：你只负责声明”应该是什么样”，Swarm 负责让现实不断向声明靠拢——副本死了它补、节点挂了它迁移。这种”声明式”的思维方式，是所有编排系统的共同点，先在这里适应，后面看 Kubernetes 也不会陌生。

组集群实战：三台机器变一台”大机器”#

假设三台机器的内网 IP 分别是：

1
docker swarm init --advertise-addr 192.168.1.11

1
Swarm initialized: current node (xxxx) is now a manager.
2

3
To add a worker to this swarm, run the following command:
4

5
    docker swarm join --token SWMTKN-1-xxxxxx 192.168.1.11:2377

1
docker swarm join --token SWMTKN-1-xxxxxx 192.168.1.11:2377

1
# 查看 worker 加入令牌
2
docker swarm join-token worker
3

4
# 查看 manager 加入令牌
5
docker swarm join-token manager

1
docker node ls

1
ID                            HOSTNAME   STATUS   AVAILABILITY   MANAGER STATUS   ENGINE VERSION
2
a1b2c3 *                      node1      Ready    Active        Leader           27.x
3
d4e5f6                        node2      Ready    Active                          27.x
4
g7h8i9                        node3      Ready    Active                          27.x

1
docker node update --availability drain node1

第一个服务：亲眼看一次自愈#

在 Manager 上创建第一个服务：

1
docker service create --name web --replicas 3 --publish published=8080,target=80 nginx:alpine

参数逐个看：--name web 服务名；--replicas 3 要维持 3 个副本；--publish published=8080,target=80 把容器内的 80 端口通过路由网格发布到集群所有节点的 8080 端口。注意新式写法推荐 published=...,target=... 的长格式，比老式的 -p 8080:80 更明确（短格式当然也能用）。

查看服务与副本分布：

1
docker service ls
2
docker service ps web

1
NAME   MODE        REPLICAS   IMAGE         PORTS
2
web    replicated  3/3        nginx:alpine  *:8080->80/tcp
3

4
ID        NAME     IMAGE         NODE      CURRENT STATE
5
xxxx      web.1    nginx:alpine  node1     Running
6
yyyy      web.2    nginx:alpine  node2     Running
7
zzzz      web.3    nginx:alpine  node3     Running

REPLICAS 3/3 表示期望 3 个、实际 3 个，状态健康。Swarm 自动把三个副本均匀摊到了三台机器上。现在，在浏览器或用 curl 访问任意一台机器的 8080 端口：

1
curl http://192.168.1.13:8080

都能打开 nginx 的欢迎页——哪怕你访问的这台机器上根本没有空闲副本在监听，路由网格也会把请求转到有副本的节点。这就是集群的感觉：三台机器对外像一台。

接下来见证自愈。去 node2 上，把 web.2 对应的容器强行删掉，或者干脆直接在 node2 上执行 docker stop 停掉那个容器。然后回 Manager 上再看：

1
docker service ps web

你会看到 web.2 的旧任务变成 Shutdown/Failed，紧接着一个新的任务被创建并调度起来，REPLICAS 很快回到 3/3。整个过程你什么都没做。你声明了”3 个副本”，Swarm 就永远让现实等于 3 个，这就是编排的全部魔法。极端一点，你把 node2 整台机器关机，它的副本会被重新调度到 node1、node3 上补齐——单机时代那种”机器挂了服务就没了”的日子结束了。

玩够了删掉服务：

1
docker service rm web

stack 部署：把 Compose 文件搬上集群#

单个服务用命令创建还行，真实项目是一组服务加网络加卷，还是得靠文件。这就是 stack：它吃的正是你已经写熟的 Compose 文件，部署命令是 docker stack deploy。

先看一份能直接用于 stack 的 Compose 文件（保存为 stack.yml）：

1
services:
2
  web:
3
    image: nginx:alpine
4
    ports:
5
      - "8080:80"
6
    deploy:
7
      replicas: 3
8
      update_config:
9
        parallelism: 1
10
        delay: 10s
11
      restart_policy:
12
        condition: on-failure
13
        max_attempts: 3

和普通 Compose 文件九成相同，区别集中在新增的 deploy 段：replicas 是副本数，update_config 控制滚动更新的节奏，restart_policy 控制副本失败后的重启策略。这些字段的思路在系列的 Compose 进阶篇里已经铺垫过，细节可以回去对照看：Docker Compose 进阶：环境变量、健康检查与多环境。

部署：

1
docker stack deploy -c stack.yml myapp

myapp 是栈名，栈内所有服务、网络、卷的名字都会自动加上 myapp_ 前缀，避免多栈之间撞名。查看与管理：

1
docker stack ls                 # 所有栈
2
docker stack services myapp     # 栈里的服务
3
docker stack ps myapp           # 栈里的全部任务
4
docker stack rm myapp           # 整个栈一键拆除

滚动更新：换版本不停服#

服务跑起来只是开始，真正体现编排价值的是更新。假设 nginx 出了新版本，要把镜像从 nginx:1.27-alpine 升到 nginx:1.28-alpine。

先看用命令怎么滚动更新一个已有服务：

1
docker service update \
2
  --image nginx:1.28-alpine \
3
  --update-parallelism 1 \
4
  --update-delay 10s \
5
  web

--update-parallelism 1 表示一次只更新 1 个副本，--update-delay 10s 表示每批更新之间停 10 秒观察。更新过程是：停掉一个旧副本 → 在原地（或别的节点）拉起新版副本 → 等它 Running → 隔 10 秒 → 再动下一个。3 个副本分三批换完，全程服务始终有副本在对外响应，零停机。如果用的是 stack 管理，更新更简单：改掉 stack.yml 里的镜像标签和 update_config，重新执行一遍 docker stack deploy -c stack.yml myapp，Swarm 会自己算出差异并滚动收敛。

观察更新进度：

1
docker service ps web
2
docker service inspect --pretty web

更新到一半发现新版有 bug？一条命令回滚到上一个版本：

1
docker service rollback web

Swarm 保存了服务的上一份规格，回滚同样是滚动执行的——旧版本副本逐个替换回来。注意 rollback 只能回退一步，它不是版本历史系统；真正的版本管理靠你的镜像标签和 Git 里的 Compose 文件，这也是为什么 stack 文件要进版本库。

WARNING

滚动更新零停机的前提是服务本身无状态、且新旧版本能短暂共存（比如数据库表结构变更要兼容新旧两个版本）。有状态的强一致服务别指望靠滚动更新蒙混过关，下一节细说。

数据与状态：Swarm 的现实短板#

必须把话说在前面：Swarm 天生适合无状态服务，有状态服务在它上面很难受。

原因在于卷（volume）的本质。Docker 的本地卷是绑在某台具体机器上的：一个数据库服务的副本今天落在 node2，它的卷就在 node2 的硬盘里；明天 node2 宕机，Swarm 在 node3 上把这个副本补起来——可 node3 上没有那份数据，新副本面对的是一个空卷，等于数据”丢”了。对 nginx 这类无状态服务这完全不是问题，副本之间一模一样、随起随灭；但对 MySQL、PostgreSQL 这类服务，这是灾难。

业界的通行处理方式有三条，按推荐程度排序：

放置约束的写法长这样，把服务钉在 node2 上：

1
    deploy:
2
      placement:
3
        constraints:
4
          - node.hostname == node2

钉住之后它就不再漂移，本质上是”借 Swarm 的壳、行单机之实”，可用性回到了单机水平，但至少更新和管理统一了。我的建议很明确：应用层放心上 Swarm，数据库这类有状态核心先留在集群之外，等规模真的逼到那一步，再考虑 Kubernetes 生态里的 StatefulSet 和专业存储方案。

secrets 与 configs：敏感信息别再写进环境变量#

在单机 Compose 时代，密码经常直接写在 .env 或环境变量里，多机集群下这更危险——环境变量在 docker service inspect 里一览无余。Swarm 内置了 secrets（机密）和 configs（普通配置）两个机制：它们由 Manager 加密保存（静态加密于 Raft 日志中），只在运行时以文件形式挂进需要它的容器，路径是 /run/secrets/<名字>，且只存在于内存文件系统里，不落盘。

1
# 从标准输入创建 secret，不在命令行和 shell 历史里留明文
2
printf 'myS3cretPass' | docker secret create db_pass -
3

4
# 创建服务时挂载
5
docker service create --name db \
6
  --secret db_pass \
7
  -e MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db_pass \
8
  mysql:8

1
docker config create nginx_conf ./nginx.conf
2

3
docker service create --name web \
4
  --config source=nginx_conf,target=/etc/nginx/nginx.conf \
5
  nginx:alpine

选型：Swarm、Compose、Kubernetes 怎么选#

最后把三者的边界一次说清：

我的建议分三档：

• 一台机器能装下、停机几分钟能接受：继续单机 Compose，别折腾。这仍是个人项目和小型服务的最佳解。
• 有了两三台机器、要高可用和不停机更新、团队不想再学一套新系统：选 Swarm，它的每一分复杂度都花在了刀刃上。你前面十几篇积累的镜像、网络、Compose 知识全部直接复用，一个下午就能上线。
• 规模奔着几十台以上、需要自动伸缩、复杂调度、接第三方生态（监控、日志、服务网格全家桶）：直接 Kubernetes，不要在 Swarm 上硬撑。需要说明的是，Swarm 本身仍由 Docker 公司维护、没有停止更新，“Swarm 已死”的说法并不准确；但新功能与社区生态的重心确实在 Kubernetes 一边，选型时要把这点算进长期账。

判断标准就一条：先看你的痛点是”单机不够用”还是”需要平台级能力”，前者 Swarm 绰绰有余，后者一步到位上 Kubernetes，中间反复横跳才是最贵的。

排障：最常见的四类问题#

1
docker service ps --no-trunc web
2
docker service inspect web

小结#

这一篇我们跨过了单机到集群的门槛：

• Swarm 是 Docker 内置编排器，不用另装，先想清楚”可用性”和”横向扩容”两个单机天花板再上；
• 核心概念就一组：你声明服务的期望状态，Swarm 用任务副本去逼近它，副本死了自动补，这就是自愈；
• 经理节点用 Raft 多数派，数量只取奇数，3 台是小集群甜点，2 台是最差配置；
• docker stack deploy 复用 Compose 文件，但 build: 会被忽略、镜像必须先推仓库，deploy 段在集群里才真正生效；
• 滚动更新靠 --update-parallelism 与 --update-delay 控制节奏，出事一条 rollback 回退；
• 有状态服务是 Swarm 的短板，数据库留在集群外、或用放置约束钉住节点，别让卷漂移；
• 密码走 secrets、配置走 configs，别再进环境变量；
• 选型记住一句话：单机痛点用 Swarm，平台级需求上 Kubernetes。

至此，从单机部署、自动更新、监控、安全，一路走到多机集群，这套 Docker 系列的骨架就完整了。