多机 Docker 部署：用 Uncloud 把几台云主机拼成集群，没有控制面也不维护 quorum

Uncloud 是一个轻量级集群与容器编排工具，目标是把多台云主机、独立服务器或裸金属组合成一个统一的计算环境，用来跑 Web 应用，同时把集群本身的管理开销压到最低。它在你的 Docker 主机之间建立 WireGuard 网状网络，提供自动服务发现、负载均衡、带 HTTPS 的入口，以及一组类 Docker 的 CLI 命令。

写 Go，约 5.5k stars，目前是 pre-1.0。

• 仓库：
• 文档：
• 配套的 Unregistry：
• 设计文档在仓库的 misc/design.md

和 K8s、Swarm 的差异在哪

它没有中心控制面，也没有需要维护的 quorum。每台机器通过点对点通信各自持有一份同步的集群状态，即使部分机器下线，集群操作仍然可以继续。

这一点直接决定了它的取舍。K8s 的控制面和 etcd 提供强一致的调度与丰富的 API 对象，代价是要运维一整套控制面组件；Docker Swarm 有 manager 节点和 Raft quorum，manager 数量与可用性需要规划。Uncloud 把状态同步交给基于 CRDT 的分布式 SQLite（Fly.io 的 Corrosion），换来的是没有单点、没有 quorum 要数，任何一台机器 SSH 上去就能管整个集群。代价是没有一个全局强一致的调度决策中心，也就不适合需要集中仲裁的场景。

特性

• Deploy anywhere：云主机、独立服务器、裸金属可以混着组，不挑位置和厂商。
• Docker Compose：服务与卷用 Compose 格式定义，不引入新 DSL。
• 零停机部署：滚动更新不中断服务；失败自动回滚标注为即将推出。
• 集成 Unregistry：镜像直接构建推送到自己的机器，不依赖外部 registry，只传缺失的层。
• 服务发现：内置 DNS 服务器把服务名解析到容器 IP。
• 持久化存储：跨机器管理 Docker 卷，可以跑有状态服务。
• 零配置私有网络：自动 WireGuard 网状网络，带 peer 发现与 NAT 穿透，容器拿到唯一 IP 可跨机直连。
• 无控制面：全去中心化，消除单点故障。
• 命令式优先于声明式：偏命令式操作，心智模型和排障路径都更短。
• 托管 DNS：公开访问的服务自动获得 *.xxxxxx.uncld.dev 记录（Uncloud DNS 服务）。
• 自动 HTTPS：内置 Caddy 反代，用 Let's Encrypt 申请和续期证书。
• 类 Docker CLI：管理基础设施和应用的命令沿用熟悉的手感。
• 远程管理：SSH 到集群中任意一台机器，就能掌控整个基础设施。

快速开始

安装 CLI：

brew install psviderski/tap/uncloud
# 或者
curl -fsS https://get.uncloud.run/install.sh | sh

初始化第一台机器：

uc machine init root@your-server-ip

从镜像部署应用，把容器 8000 端口以 HTTPS 发布到 app.example.com：

uc run -p app.example.com:8000/https image/my-app

在 DNS 服务商（Cloudflare、Namecheap 等）加一条 A 记录，把 app.example.com 指向服务器 IP，等几分钟生效。

清理：

uc ls           # 查看
uc rm my-app-name

彻底卸载机器上的 Uncloud：

uncloud-uninstall

表面之下的工作方式

初始化机器时：CLI 通过 SSH 登录机器，安装 Docker 和由 systemd 管理的 uncloudd 守护进程；生成唯一 WireGuard 密钥对，为该机器及其容器分配专用子网 10.210.0.0/24；配置并启动 corrosion（Fly.io 的基于 CRDT 的分布式 SQLite，作为 Docker 容器由 uncloudd 管理）在各机器间共享集群状态；创建连接到 WireGuard 接口的 Docker 网桥；该机器成为集群入口，连接信息写在本地 ~/.config/uncloud/config.yaml。

加机器时：分配新子网（如 10.210.1.0/24），注册进集群状态并与已有机器交换 WireGuard 密钥，两机建立隧道，容器可跨机直连。新机器只需和已有机器中的一台建立连接，其余机器通过共享状态自动建立隧道。

跑服务时：CLI 选一台机器运行容器，uncloudd 用 grpc-proxy 把请求转发到目标机器启动容器；容器从网桥拿到集群内唯一 IP（10.210.X.2-254）；以 global 模式跑在每台机器上的 Caddy 反代监听集群状态变化，更新配置把流量路由到新容器。

适合谁，不适合谁

适合想自托管、但不想背 Kubernetes 运维复杂度的开发者：几台 VPS 或裸金属，需要跨机部署、自动 HTTPS、私有网络和服务发现，愿意接受命令式工作流。

不适合需要成熟 GA 行为、强一致集中调度、复杂 RBAC 与庞大生态的团队；集群规模往几十上百节点走，也应该先评估 Corrosion 状态同步与网状网络的实际表现。

项目状态

pre-1.0，活跃开发中，版本之间可能有破坏性变更。build/push/deploy 这条核心工作流已经稳定，运行时大量依赖久经考验的项目：Docker、Caddy、WireGuard、Corrosion。

设计上的灵感来源包括 Kamal（证明命令式简单部署仍然有价值）、Fly.io、Tailscale、Talos Linux/KubeSpan、Docker Swarm Classic、Rancher 1.x；集群状态则用了 Fly.io 的 Corrosion。