《Docker 运维入门实战：两台机器一个集群——Docker Swarm 最简实战》

关键词：Docker Swarm、集群、调度、两台机器、服务发现

前面几篇里，副本从 1 个扩到 3 个，状态也挪出了副本本地，但有个前提一直没动：所有东西还在一台机器上。机器一宕，网关、副本、Redis 一起没。今天跨出这一步：拿两台机器组一个最简集群，用 Docker 自带的 Swarm 把服务真正分散开。目标不是生产级高可用，而是把上一篇列的那三步差——跨机器、调度、跨机器网络——亲手走一遍。

环境假设：两台装好 Docker 的 Linux 机器，能互相访问内网 IP（云上就是同 VPC 的两台云服务器）。下文称它们为机器 A（管理节点）和机器 B（工作节点）。

一、组集群：一条命令初始化，一条命令加入

Swarm 是 Docker 自带的编排能力，不用另装组件。在机器 A 上初始化：

docker swarm init --advertise-addr <机器A内网IP>

执行完会输出一条带令牌（token）的 join 命令，大意是这样：

docker swarm join --token SWMTKN-1-xxxx <机器A内网IP>:2377

把这条命令复制到机器 B 上执行，B 就加入了集群。回机器 A 验证：

docker node ls

能看到两个节点，A 是 Leader（管理节点），B 是 Ready 状态，集群就算组好了。就这么简单：没有额外的注册中心要装，节点之间的发现和管理通道，Swarm 自己维护。

动手前先检查云上安全组：Swarm 节点之间要通三个端口——2377（管理）、7946（节点间通信，TCP+UDP）、4789（跨机器容器网络，UDP）。同内网的两台机器之间放行这三个端口，不然节点能加入、服务却互相访问不通，是新手最常卡的一步。

二、部署服务：Compose 文件几乎不用改

在管理节点 A 上，用之前一直在用的 Compose 文件部署，只不过命令换成 stack：

docker stack deploy -c docker-compose.yml myapp
docker service ls
docker service ps myapp_api

docker stack deploy 会把 Compose 里的服务变成 Swarm 服务。最大的变化在 docker service ps 的输出里：api 的 3 个副本不再都在一台机器上，而是被调度到两台机器上分布——这正是上一篇说的"谁来决定副本跑在哪台机器"，现在由 Swarm 的调度器自动决定，人不用指定。

还是上一篇的老规矩：状态不进副本。Redis、数据库这类存状态的服务，在 Compose 里给它们加约束，让它们固定在一台机器上（比如就放 A），别跟着副本到处跑：

    deploy:
      placement:
        constraints:
          - node.hostname == <机器A主机名>

三、跨机器之后，发现和分摊还是老朋友

服务跑到两台机器上之后，前几篇讲的两件事依然成立，只是实现换成了集群版：

• 服务名就是地址：Swarm 内置 DNS，api 这个名字在集群内部任何节点上都能解析到它的副本，和单机 Compose 时一模一样的用法，配置不用改。
• 请求从哪台机器进都行：Swarm 的路由网格（routing mesh）让集群里每台机器都能接请求——你把请求发到 B 机器的网关端口，就算网关副本实际跑在 A 上，请求也会被自动转过去。外部只认"集群"这一个入口，不用关心副本具体在哪台机器。
• 分摊照旧轮换：请求在副本之间怎么分，还是负载均衡那套逻辑，只是分发范围从"一台机器内的副本"变成了"两台机器上的副本"。

这也是为什么要按前面的顺序学：概念没变，变的只是范围。单机上把服务名发现和网关分发练熟了，到集群里就是同一套心智模型放大一圈。

四、自愈：副本挂了、机器挂了，会自己补

集群比单机多出的最实在的能力是自愈。在 B 上手动停掉一个 api 副本容器，或者干脆把 B 关机演练一次，回 A 上看：

docker service ps myapp_api

你会看到副本数先掉下去，随后调度器在还活着的节点上把副本补回 3 个。docker service update --replicas 5 myapp_api 还能随时改副本数，调度器负责把多出来的副本安排到有余量的机器上。

注意自愈补的是无状态副本。如果挂掉的机器上跑着 Redis 或数据库，副本可不会自己把数据变回来——那是数据备份和主从的另一个话题。这也是为什么上一篇要先把状态外置、分清楚：调度器能搬走的是计算，搬不走的是数据。

五、三个新手最容易踩的坑

1. 安全组没放行，节点加进来了服务却不通
docker node ls 全是 Ready，就以为网络没问题，结果跨节点的容器互相访问超时。先查 2377、7946、4789 三个端口，这是 Swarm 的命脉。

2. 两台机器就想谈高可用
两台机器里管理节点只有 A 一个，A 挂了，集群的管理功能（改副本数、发新服务）就停了，已在跑的服务还能撑，但别把这叫高可用。管理节点要奇数个（3 个起）才能容错——两台机器的定位是"把集群走通"，不是"扛故障"，心里要有数。

3. 以为上了 Swarm 就不用管状态了
Swarm 解决的是副本放哪、挂了怎么补，它不解决数据放哪。会话、文件、业务数据该外置还得外置，规则和上一篇完全一样。

结语

从单机多副本到两台机器的 Swarm，变的是副本的位置和调度方式，不变的是服务名发现、网关分发、状态外置这三套基本功。到这里，这条线已经从"一台机器跑起一个服务"走到了"一个小集群"。还剩一个一直绕过去的东西没正经处理：配置和密码——数据库密码、接口密钥现在还明晃晃写在 Compose 文件里，下一篇把它们收起来，讲 Swarm 的 secret 与 config 怎么用。