Docker Swarm 是 Docker 原生的集群编排方案。提供与 Docker 工具集成的服务编排，使用 legacy Compose v3 子集而非完整当前 Compose 规范——适合小团队和单集群场景。
什么时候需要编排？#
单机 Compose Swarm / K8s
───────────── ─────────────
1 台机器 多台机器
可设重启策略 服务任务故障重新调度
固定端口 负载均衡
单机更新 可配置滚动更新（是否无中断需验证）
可手动扩副本 跨节点副本调度（Swarm 无内置 HPA）Swarm 快速上手#
初始化集群
以下仅为已规划的测试集群示例。需要节点间管理/overlay 通信与防火墙策略，manager 应按仲裁规划；join token 是敏感凭据，必须安全传递。文档地址需替换为可达节点地址。
# 初始化 Swarm 管理器节点
docker swarm init
# 输出含 join 命令，用于其他机器加入集群：
# docker swarm join --token <worker-join-token> 192.0.2.10:2377
# 在其他机器上执行 join 命令
docker swarm join --token <worker-join-token> 192.0.2.10:2377
# 查看集群节点
docker node ls
# ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
# abc123 * node-1 Ready Active Leader
# def456 node-2 Ready Active
# ghi789 node-3 Ready Active部署服务
# 创建服务（类似 docker run，但跑在集群上）
docker service create \
--name web \
--replicas 3 \
--publish 80:80 \
nginx:alpine
# 查看服务
docker service ls
docker service ps web
# 输出显示 3 个副本分别跑在哪些节点上Stack Deploy：迁移兼容的 Compose v3 配置#
共同的服务字段可复用，但 stack deploy 使用 legacy Compose v3；现代 develop/watch/profiles、build 等不能直接迁移。提前构建并把镜像发布到所有节点可访问的 registry。
# stack.yaml（legacy Compose v3 示例，按 CLI 支持验证）
version: "3.8"
services:
web:
image: nginx:alpine
ports:
- "80:80"
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
restart_policy:
condition: on-failure
resources:
limits:
memory: 256M
healthcheck:
test: ["CMD", "wget", "-q", "--spider", "http://localhost/"] # 确认镜像提供 wget
interval: 30s
api:
image: myapi:latest
deploy:
replicas: 2
environment:
NODE_ENV: production# 部署为 Swarm Stack
docker stack deploy -c compose.yaml myapp
# 查看 stack 状态
docker stack ls
docker stack services myapp
docker stack ps myapp
# 更新（镜像变化或 yaml 变化后）
docker stack deploy -c compose.yaml myapp
# 删除
docker stack rm myapp关键：共享文件只适用于兼容字段。先检查 docker stack config 的输出与告警，再检查镜像、secret/config 来源、网络、placement 和卷；单机 Compose 通过不等于集群部署行为通过。
Swarm vs Compose 功能对比#
| 功能 | Compose (单机) | Swarm (集群) |
|---|---|---|
deploy.replicas |
单机多副本 | 跨节点多副本 |
deploy.update_config |
不支持 | 滚动更新控制 |
deploy.placement |
不支持 | 节点标签调度 |
| 负载均衡 | 手动 | 内置 VIP + DNS RR |
| 故障转移 | 手动 | 自动 |
| Secrets | 支持文件注入，来源保护自行负责 | Swarm secrets 提供加密 Raft 存储和分发 |
| Configs | 绑定挂载 | 声明式配置注入 |
Swarm 专有配置
services:
api:
deploy:
replicas: 3
# 更新策略
update_config:
parallelism: 1 # 每次更新 1 个副本
delay: 10s
failure_action: rollback
# 节点调度
placement:
constraints:
- node.role == worker
- node.labels.zone == eastSwarm 的网络：Overlay + Ingress#
节点 A (manager) 节点 B (worker) 节点 C (worker)
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ web 副本 1 │ │ web 副本 2 │ │ web 副本 3 │
│ api 副本 1 │ │ │ │ api 副本 2 │
└──────────────────┘ └──────────────────┘ └──────────────────┘
│ │ │
└──────────────────────────────┼──────────────────────────────┘
│
Overlay Network
(跨节点的虚拟二层网络)Ingress 网络：访问任何节点的 80 端口都会自动路由到 web 服务的某个健康副本。routing mesh 提供入口转发；外部负载均衡、TLS 和健康流量策略仍可能需要。
什么时候从 Swarm 上 K8s？#
| 当前需求 | 工具 |
|---|---|
| 1-5 台机器，没专门运维 | Docker Compose（单机）/ Swarm |
| 需要跨节点故障转移 + 简单扩缩 | Swarm |
| 规模扩大且需要生态/调度治理 | 根据运维能力评估 Kubernetes，没有固定节点数门槛 |
| 需要自动扩缩（HPA） | Kubernetes |
| 需要完善的 RBAC/多租户 | Kubernetes |
| 团队已经有 K8s 经验 | Kubernetes |
| 需要 Service Mesh（Istio 等） | Kubernetes |
工具选择取决于可用性、调度、治理和团队能力。Swarm 延续 Docker 服务操作，Kubernetes 提供不同的控制器与生态；学习耗时不能按固定分钟或周数保证。
后续学习路径#
graph LR
A["Docker 基础 / (run/build/compose)"] --> B["Swarm / (stack deploy)"]
B --> C["Kubernetes / (kubectl/helm)"]
A2["Podman 基础"] --> D["Pod + Quadlet"]
D --> CDocker 和 Podman 两条路径最终在 K8s 汇合——不管你用哪个引擎构建镜像和跑本地测试，生产部署也可以保持单机或其他编排，是否采用 Kubernetes 由需求决定。
故障与数据边界#
Swarm 调度可在节点故障后重建任务，但 local volume 不会自动把数据复制到另一节点；数据服务需共享存储、复制或明确 placement 与恢复方案。manager 丢失多数仲裁会影响调度管理。滚动更新中的 start-first、健康检查和 failure_action 也不能保证数据库迁移可逆或流量无中断。删除 stack 停止服务，卷与外部 secret/config 生命周期应逐项核对。
参考与延伸
根据技术笔记重新整理，示例使用通用名称。