Docker Swarm服务生命周期管理实战：从部署到故障转移

接手生产环境之后你会发现，用 Docker Swarm 管理集群，真正的难点从来不是“搭起来”，而是把服务的整个生命周期管明白。这篇文章以 Docker 29.1.3 环境为基础，围绕 Swarm 集群的服务生命周期管理展开，从集群初始化、节点管理，到服务部署、扩缩容、滚动更新、回滚、服务发现和故障转移，把完整链路拆开讲清楚，并附上我在生产环境里真实踩过的坑。适合正在维护 Swarm 集群的运维同学，也适合准备从单机 Docker 迁到集群的开发者参考。

1. 先搞清楚 Swarm 的服务生命周期到底管什么

1.1 从“跑容器”到“管服务”的思维转变

很多从 Docker 单机过渡过来的朋友，一开始会特别不适应 Swarm 的操作方式。单机环境下你面对的是一个容器：启动、停止、删除，路径非常直接。但在 Swarm 里，最小的操作单元变成了“服务”，你不再关心具体某个容器跑在哪台机器上，而是声明“这个服务要有 3 个副本、占用多少资源、端口怎么暴露”。

这背后的逻辑其实和公司排班很像。单机模式相当于你自己盯一个员工，他请假了你就得手动找人顶班。Swarm 模式则是你告诉人事部门“这个岗位必须保持 3 个人在岗”，至于谁在岗、谁轮休、谁临时调来顶班，你不用操心。服务生命周期管理，就是在维护这套“人员调度规则”：怎么招人、怎么排班、怎么换人、怎么处理有人突然离职的情况。

具体到 Swarm 的技术实现上，这套“规则”由声明式配置来承载。你通过docker service create声明服务的期望状态，Swarm 的控制平面会持续对比期望状态和实际状态，发现不一致就自动纠正。比如你声明了 5 个副本，某个节点宕机导致只剩 4 个，Swarm 会自动在其他可用节点上补起 1 个。这个过程就是服务生命周期管理的核心闭环：创建、调度、运行、健康检查、更新、回滚、故障恢复。

1.2 为什么还在用 Swarm 而不是直接上 K8s

聊生命周期管理绕不开一个现实问题：现在 K8s 这么火，为什么还要用 Swarm？我的看法是，Swarm 的优势不在功能丰富度，而在“恰好够用且足够简单”。如果你维护的是几十个服务的规模，团队里也没有专职的 K8s 运维，Swarm 的学习成本和运维成本会低非常多。

Docker 29.1.3 这个版本下的 Swarm 已经相当成熟，虽然迭代节奏不如 K8s 猛，但该有的东西都有：多节点高可用、服务编排、滚动更新、内置 DNS 服务发现、Ingress 负载均衡。它内置在 Docker Engine 里，不需要额外部署一堆组件。对比一下，一套生产级 K8s 集群光是 etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、容器运行时就能让新手忙活一周，而 Swarm 集群两个命令就能完成初始化并加入节点。

当然，Swarm 的短板也很明显：生态和扩展性远不如 K8s，复杂的灰度发布、细粒度的权限控制都很难做。我个人的建议是：如果团队规模不大、业务场景偏中小型、不想维护复杂的基础设施，Swarm 是一个非常务实的选项。这篇文章里讲的很多生命周期管理思路，其实也能平移到 K8s 上，因为理念是相通的。

2. 集群初始化与节点管理——先把底座搭稳

2.1 初始化控制节点：swarm init 的关键参数

所有生命周期管理动作都建立在“集群已经健康运行”的基础上，所以第一步是把控制节点初始化好。执行初始化命令的时候有几个参数要特别注意，直接影响到后续的集群行为。

docker swarm init \ --advertise-addr 192.168.1.10 \ --listen-addr 0.0.0.0:2377 \ --data-path-addr 192.168.1.10 \ --task-history-limit 10

--advertise-addr是给其他节点用的地址，必须填其他节点能访问到的 IP，别填 127.0.0.1，否则工作节点根本加入不了。如果你有多网卡，尤其要留意这个参数，我曾经在双网卡服务器上忘了指定，结果管理节点广播了一个内网管理口的地址，业务网段的节点死活加入不进来。

--data-path-addr是数据面流量的专用地址，默认会复用 advertise-addr。如果机器有多块网卡，建议把控制面通信和数据面通信分开，避免大流量业务影响 Raft 心跳。--task-history-limit控制每个服务保留多少条历史任务记录，默认是 5，调大一点方便回溯更新和扩缩容的历史操作。

初始化完成后，用docker node ls查看节点状态，你会看到类似下面的输出：

ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION dxn1a2b3c4d5e * manager-01 Ready Active Leader 29.1.3

STATUS 是 Ready 才算正常，AVAILABILITY 是 Active 表示可以接收新任务，MANAGER STATUS 是 Leader 表示这是当前的控制面主节点。这几个状态字段在后面做节点维护时会反复用到。

2.2 工作节点接入与角色调整

初始化完成后，把工作节点加入集群用的是docker swarm join命令。初始化输出的 join token 如果丢了，可以通过docker swarm join-token worker重新获取。加入后建议立刻给节点打上标签，这会对后面的服务调度约束很有帮助。

docker node update --label-add role=redis node-02 docker node update --label-add zone=az1 node-03

节点标签是 Swarm 服务约束的基础设施。比如 Redis 这类有状态服务，你可以约束它只调度到带有role=redis标签的节点上，避免它到处乱跑。

节点维护时要改 AVAILABILITY 状态，有三种取值要记清楚：Active 是正常参与调度；Pause 是不接收新任务但保留现有容器；Drain 是排空，不仅不接收新任务，还要把已有容器迁移走。我之前吃过一次亏，给节点做内核升级时只用了 Pause 忘了 Drain，结果那台机器上的容器一直在跑，升级过程里业务容器被中断，教训很深。做硬件维护前一定要 Drain。

3. 服务部署与副本控制——生命周期管理的核心动作

3.1 创建服务时这些参数一定要想清楚

服务创建是生命周期管理的入口，参数选错后面全是坑。我通常会用一条完整的docker service create命令来部署一个生产服务，尽量把资源限制、重启策略、更新配置一次性声明清楚：

docker service create \ --name web-demo \ --replicas 3 \ --image nginx:1.26-alpine \ --publish published=8080,target=80 \ --constraint 'node.labels.zone == az1' \ --reserve-cpu 0.25 \ --reserve-memory 128m \ --limit-cpu 0.5 \ --limit-memory 256m \ --restart-condition any \ --restart-delay 5s \ --restart-max-attempts 5 \ --update-delay 10s \ --update-parallelism 1 \ --update-order start-first \ --rollback-parallelism 1 \ --rollback-monitor 20s \ --detach=false \ nginx:1.26-alpine

先解释--publish published=8080,target=80这个参数。在 Swarm 集群里，这个命令会自动创建一个 Ingress 网络，宿主机上的 8080 端口会接入 Swarm 内置的负载均衡，把流量转发到任意一个 nginx 副本上。这意味着客户端访问集群里任何一台机器的 8080 端口，都能到达服务，这是 Swarm 和普通 docker run -p 最大的区别。

资源限制参数同样重要。--reserve-memory 128m是告诉调度器“这个服务至少需要 128M 内存”，调度器会优先把任务放到内存充足的节点上；--limit-memory 256m是硬限制，超过 256M 容器会被 OOM Kill。生产环境我强烈建议这两个参数都设置，否则极端流量下某个服务可能把整台节点的内存吃满，导致同一节点上的其他服务一起遭殃。

--update-delay、--update-parallelism、--update-order这几个参数，直接决定你后续做滚动更新时候的“节奏”。我生产环境里常用的策略是：并行度设为 1，每个副本更新完等 10 秒，先启动新副本再停旧副本（start-first）。这样最稳，但更新耗时较长。如果服务比较多、追求速度，可以把并行度调高，但风险也会同步上升。

3.2 扩缩容的正确姿势和常见误区

服务运行起来之后，扩缩容是最频繁的操作。Swarm 提供了直接命令：

# 扩容到 5 个副本 docker service scale web-demo=5 # 缩容到 2 个副本 docker service scale web-demo=2

执行扩容后，Swarm 会按照当前节点的资源余量和约束条件选择节点来创建新任务。缩容则比较有意思：Swarm 不是简单地把副本数减下去，而是会停掉“最不稳定”的任务，优先停掉最近启动的、健康检查失败的、或者所在节点负载较高的任务。

实操中我经常被问到一个问题：用docker service update --replicas 5 web-demo和docker service scale web-demo=5有什么区别？功能上等价，但如果你同时要修改镜像版本或其他配置，用service update一条命令里写完更合适，不需要执行两次。

缩容时有个细节要注意：如果你临时需要把服务缩到 0 但又不想删除服务配置，docker service scale web-demo=0是合法操作，服务定义还在，副本全部停止。这个技巧在做迁移或者维护窗口时特别有用。千万不要养成“删了重建”的习惯，一旦删掉服务，服务发现、网络配置、更新历史就全没了，重建时很容易漏参数。

还有一个大量踩坑的点：创建服务时要区分有状态和无状态。无状态服务可以放心扩容、随意调度；有状态服务（比如数据库）如果也随意调度，数据就丢得不明不白。生产环境里我通常会配合--constraint加上节点标签约束，把有状态服务固定到特定节点上，副本数一般固定为 1。

4. 服务更新、回滚与故障转移——变更时最考验功底

4.1 滚动更新的完整流程和参数调优

服务更新在生产环境里几乎是每周都要做的事。Swarm 默认的更新策略已经够用，但需要针对业务特点调整节奏。比如你更新的是一个核心 API 服务，我建议把并行度设置为 1，并配置健康检查，否则 Swarm 无法判断新副本是否真正“可用”，只能靠容器进程是否存活来判断。

一个带健康检查的更新操作是这样：

docker service create \ --name api-gateway \ --replicas 4 \ --health-cmd "curl -f http://localhost/health || exit 1" \ --health-interval 5s \ --health-timeout 3s \ --health-retries 3 \ --update-parallelism 1 \ --update-delay 15s \ --update-order start-first \ --update-failure-action rollback \ your-image:1.0.0

这里--update-failure-action rollback是个保险，当更新过程出现失败时，Swarm 会自动把服务回滚到上一个版本。我现在管的所有生产服务都带这个参数，它相当于给你的变更上了一道安全锁。

实际更新镜像时，执行：

docker service update \ --image your-image:1.1.0 \ --update-parallelism 1 \ --update-delay 15s \ --update-order start-first \ --update-failure-action rollback \ api-gateway

执行后会看到 Swarm 逐个替换副本。更新期间用docker service ps api-gateway观察任务状态，你会发现任务 ID 在变，旧的副本状态会变成 Shutdown，新的副本逐渐启动并变为 Running。

我要强调一个容易被忽略的点：start-first 和 stop-first 的选择。start-first 是先起新容器，等新容器健康检查通过后再停旧容器，这要求你的服务必须能支持新旧版本同时运行一小段时间。如果你的数据库结构变更不兼容新旧版本同时访问，那就不能用 start-first，而要选 stop-first。这个选择不只是技术问题，更是业务问题，一定要和开发团队提前对齐。

4.2 回滚操作与故障转移机制

更新完后发现新版本有问题，回滚是最后一道防线。手动回滚的命令非常简单：

docker service rollback api-gateway

执行后 Swarm 会把服务参数恢复到上一次执行service create或service update之前的状态。这里有个容易误解的点：rollback 不只是镜像版本回退，还包括环境变量、挂载、端口等所有参数的回退。所以如果你在更新时不小心改错了一个环境变量，回滚也会把它一并还原。

故障转移是 Swarm 生命周期管理里最体现“自动化价值”的部分。当某个工作节点宕机时，Swarm 会检测到节点变成 Down 状态，并自动把原来调度在该节点上的任务重新调度到其他可用节点上。这个过程不需要人工干预，但有几个前提条件：

• 服务本身还有未满足的副本数期望值
• 集群里还有其他满足约束条件且资源充足的节点
• 管理节点本身健康，能正常协调调度

如果你限制了服务只能调度到特定标签的节点，而这些节点恰好全部宕机，那服务就无法完成故障转移。此时需要用docker service inspect查看服务详情，重点看“UpdateState”和“Placement”相关的字段。

管理节点的故障转移也值得一提。Swarm 使用 Raft 协议来维持控制面一致性，推荐生产环境至少部署 3 个管理节点。当 Leader 挂掉，其他管理节点会自动发起选举，选出新的 Leader。整个过程对服务运行基本无感。但要注意，Raft 需要多数派存活，3 个管理节点最多允许挂 1 个，5 个最多允许挂 2 个。控制面节点数不要配成偶数，否则网络分区时会出现平票问题。

5. 服务发现与流量接入——让外部请求稳定打到服务上

5.1 内置 DNS 与 VIP 机制的配合

Swarm 内部的服务发现是自动完成的。你在服务网络里启动的每个服务，都会自动注册一个 DNS 记录，记录名就是服务名。比如服务名是web-demo，其他服务直接访问http://web-demo就能到达服务，不需要关心副本跑在哪台机器上。

这个机制依赖 Swarm 内置的 DNS 服务器和 VIP（虚拟 IP）机制。每个服务被分配一个虚拟 IP，DNS 解析返回这个 VIP，流量到达 VIP 后再由 Swarm 的负载均衡转发到实际容器。这意味着你不需要在业务代码里集成任何服务发现 SDK，也不需要维护单独的注册中心。

我遇到过一个经典问题：服务 A 访问服务 B 时偶尔超时，但端口能通。排查半天发现是服务 A 自己所在的容器网络和服务 B 不在同一个 overlay 网络里。Swarm 的 DNS 只在同一个 attachable 网络内生效，跨网络访问必须把两个服务加到同一个网络里。

docker network create -d overlay --attachable demo-net docker service update --network-add demo-net web-demo

把需要互访的服务都加到同一个 overlay 网络，DNS 才能正常解析。这也是我创建服务时几乎总会手动指定网络的原因。

5.2 外部流量接入与端口冲突问题

外部流量进入 Swarm 服务，最常用的方式是--publish。这里面的语义值得好好理解：当你发布端口时，Swarm 会在集群里的每个节点上同时监听这个端口，并在 Ingress 网络上做负载均衡。所以客户端访问任何一个节点的宿主机 IP 加发布端口，都能到达服务。

多服务同时发布端口时，端口冲突是常见的坑。比如两个服务都想用宿主机的 8080 端口，第二个服务就会创建失败。解决方法有两个：一是换端口；二是利用 Swarm 的路由网格特性，把不同服务通过 Host 头或者路径区分开。不过说实话，Swarm 的 L7 路由能力比较弱，实践中还是用 Nginx 或者 Traefik 反代到不同端口更常见。

另一个生产实践是：不要让数据库这类服务直接发布到宿主机端口。数据库一般只对集群内部的服务开放，直接暴露端口会增加安全风险，也容易被人扫描爆破。正确做法是让数据库服务只加入 overlay 网络，不发布任何宿主机端口，只有应用层服务才发布端口。

6. 生产环境常见问题与排查技巧实录

6.1 高频故障排查速查表

下面这几类问题我在生产环境里都亲身遇到过，整理成一张速查表，方便大家对照排查。

6.2 一些只有踩过坑才懂的经验

先说说日志。Swarm 服务本身的docker service logs只能看单个任务的日志，而且任务漂移后日志就不好追了。生产环境一定要把容器日志接到统一的日志平台里，否则排查故障时你会像大海捞针。我现在的做法是每个节点上跑一个轻量日志采集容器，把所有容器日志汇聚到集中式日志系统，按服务名和节点名索引。

再说说备份思维。Swarm 的配置和集群状态用docker swarm相关命令可以导出，但更简单的做法是：把创建每个服务的命令整理成 Shell 脚本或 Compose 文件纳入版本管理。这样就算集群彻底损坏，也能用脚本快速重建。我吃过一次大亏，集群控制面损坏后才发现没有留存任何服务定义的“源码”，只能根据线上反向推断参数，整整折腾了一下午。

最后说一个很多人忽略的点：不要在高峰期做大规模变更。即使有滚动更新、自动回滚这些机制兜底，变更仍然可能引入未知问题。我现在的习惯是：所有服务更新都在业务低峰期操作，操作前确保有最近的可回滚版本镜像，操作后至少观察 15 分钟再离开。这套流程看起来朴素，但确实帮我挡掉了好几次线上事故。

Swarm 的服务生命周期管理，本质上是一套“声明期望状态、持续纠正偏差、变更可回退、故障自愈”的机制。把每一环的配置和原理吃透，生产集群就会变得省心很多。希望这篇基于 Docker 29.1.3 的实战总结能帮你少走一些弯路。