每次有人开始折腾自托管(homelab、小团队的内网服务),很快就会陷进同一个兔子洞:
要不要上 K8s?上了 K8s 是不是得配 ArgoCD/Flux 做 GitOps?于是还没部署一个服务,先研究了两周 Helm chart 和 CRD。我想说句实话:单机、或者三五台机器的自托管,根本不需要 ArgoCD。 你想要的那点GitOps 价值——「git 仓库是唯一真相源,改了就自动上线,能回滚,有记录」——用 git +docker compose 二十行脚本就能拿到 90%,而且没有控制平面要维护。## 「够用版」GitOps 到底是什么GitOps 的核心就两条:1. 声明式:系统的期望状态写在 git 里(对自托管来说,就是你的 docker-compose.yml)。2. 拉取式:机器自己去 git 拉变更并收敛,而不是你 ssh 上去手敲。对应到一台 docker 主机,最小实现是这样的:host 上一个 webhook(或者 60 秒一次的git fetch),发现跟踪的分支动了,就跑:```bashgit pull --ff-onlydocker compose pulldocker compose up -d --remove-orphans````–remove-orphans很关键:你从 compose 文件里删掉的服务,会真的被停掉,而不是阴魂不散留在那。就这么三行,你已经有了一个能用的 GitOps 循环:改 compose → push → 机器自动收敛。## 真正会咬你的两件事够用版能跑,但有两个坑,踩过的人都懂:### 1. 零停机裸docker compose up -d是**重建**容器——旧的停、新的起,中间有几秒空窗。后台服务无所谓,但只要是用户在访问的东西,这几秒就是 502。- composev2.17+的up --wait至少会**等健康检查通过**再算成功,能挡住「起来就挂」的情况;- 真要零停机,得搞两个 service 名(蓝绿),前面挂个反代,新的健康了再把流量切过去、停旧的。别指望 compose 自带优雅滚动,它没有。### 2. 回滚这是最多人忽略、出事最致命的一点。如果你的镜像 tag 是:latest,那「回滚」就等于「改文件然后祈祷」——你根本不知道上一个能用的版本是哪个。正确做法:**镜像 tag 钉死成 git 的 commit SHA**(myapp:9f8322f而不是myapp:latest),并且**记录当前线上跑的是哪个 SHA**。这样回滚就退化成一句「重新部署上一个 SHA」,确定、可重复。没有这一步,你的 GitOps 迟早会悄悄变成「git pull 然后听天由命」。## 什么时候该上更重的工具够用版的边界也很清楚:- **一台机器**:二十行脚本完全够,别想太多。- **3 台以上、或者要审计「谁在什么时候部署了什么」**:这时候手写脚本开始还技术债了—— 你需要并发部署多台、统一的回滚、谁触发的记录。这才是更重的工具开始回本的点。但请注意:这个临界点比大多数人以为的**晚得多**。绝大多数自托管场景,你都还在「二十行脚本够用」那一侧。## 后来我把这套打包了道理我都懂,但每次新搭一台机器都手抄一遍 webhook + pull + compose + SHA 钉版 + 回滚记录,还是烦。于是我索性把它——以及前面的 CI 构建、多机 SSH 零停机部署、容器管理——全塞进了一个Go 单二进制里,叫 **Pipewright**:scp 一个文件上服务器,跑起来,浏览器打开就是可视化的流水线 + 一键部署 + 容器面板,没有别的运行时依赖(前端用 embed.FS` 打进二进制,默认 SQLite)。它本质上就是把上面这套「够用版 GitOps」产品化了,顺手补上了零停机和按 SHA 回滚这两个坑。开源 MIT,定位是个人开发者 / 小团队——不打算去替 200 人团队的 GitLab。仓库在这:https://github.com/huangchengsir/pipewright不过就算你不用它,这篇的核心还是那句话:**自托管的 GitOps,大概率你不需要 ArgoCD。**先用 git + compose 跑起来,等真撞到墙了再加重。欢迎来提 issue 拍砖。