Omarchy 研发基础设施迁移至 DigitalOcean 云平台实践

1. 从一台笔记本到一个云平台：Omarchy 迁移这件事到底在折腾什么

Omarchy 这个名字，最近在 Arch 和 Hyprland 圈子里出现的频率不低。它本质上是一套围绕 Arch Linux 打造的、开箱即用的桌面环境发行版方案，把 Hyprland 平铺窗口管理器、主题、快捷键、常用工具链打包成一套可以直接上手的工作站体验。很多人第一次接触它，是因为厌倦了从零配置 Hyprland 的那一堆配置文件——waybar、hyprpaper、hypridle、dunst、rofi 这些组件一个个调，调完还要处理字体、输入法、显示器缩放，没个两三天根本跑不顺。Omarchy 的价值就在于把这些琐碎活儿提前干完了。

但这次要聊的不是桌面美化，而是 Omarchy 把它的研发基础设施整体迁移到了 DigitalOcean 云平台上。这件事听起来像是一次普通的服务器搬家，实际上涉及的东西比想象中多得多：构建流水线、镜像分发、文档站点、CI 跑测试的机器、还有那些平时没人注意但一挂就全员停摆的辅助服务。研发基础设施这个词听着虚，落到具体就是——代码从提交到变成可用的系统镜像，中间经过的每一台机器、每一个脚本、每一份缓存。

我之所以关注这次迁移，是因为它踩中了一个很多个人项目和小团队都会遇到的节点：本地或自建的基础设施跑着跑着就不够用了。可能是构建时间越来越长，可能是带宽扛不住镜像下载，也可能是某台老机器硬盘开始报警。这时候摆在面前的选择无非是继续加硬件、换托管商、或者干脆上云。Omarchy 选了第三条路，而且选的是 DigitalOcean，这个选择本身就值得拆开看看。

这篇文章适合几类人看：正在维护自己项目构建流水线的开发者、用 Arch 或 Hyprland 做日常主力环境的技术爱好者、以及任何在考虑把自建服务往云上搬的人。我不会只讲"迁移成功了"这种结论，而是把迁移过程中真正会卡住人的地方——镜像源配置、构建缓存策略、云主机选型、成本控制——一个个摊开讲。你看完不一定非要照搬 DigitalOcean，但至少能知道迁移这件事的坑都在哪。

2. 为什么是 DigitalOcean，而不是继续自建或者换别家

2.1 自建基础设施的天花板在哪

先说说为什么非得迁。Omarchy 这类项目的基础设施有几个特点：构建产物大（系统镜像动辄几个 GB）、分发带宽消耗高（每次发版都有大量用户下载）、CI 任务对 CPU 和磁盘 IO 有要求（编译内核模块、打包软件）。如果这些跑在一台自建机器上，很快就会碰到三个天花板。

第一个是上行带宽。家用或小型机房的宽带上行通常是对称的，但绝对数值不高，几十兆上行撑不住几百人同时拉镜像。用户下载慢，体验就差，最后反馈全堆到 issue 里。第二个是磁盘寿命。CI 频繁读写、镜像反复打包，对 SSD 的写入量消耗很快，消费级硬盘撑不了多久。第三个是可用性。自建机器一旦断电、断网、或者你手滑改错配置，整个构建链路就断了，没有冗余也没有快照回滚。

这三个问题里，带宽是最先暴露的。我见过不少项目，代码写得挺好，就是发版时下载速度劝退用户。所以迁移的核心诉求往往不是"云更高级"，而是"我需要一个上行带宽足够、磁盘 IO 稳定、能随时扩容的环境"。

2.2 DigitalOcean 在这个场景下的取舍

DigitalOcean 不是最便宜的，也不是功能最全的，但它在几个点上刚好契合这类项目。第一是 Droplet 的带宽配额比较实在，基础套餐就带可观的月流量，超出部分计费也透明，不像有些平台流量费是个黑洞。第二是它的快照和镜像功能简单直接，构建环境可以做成自定义镜像，新机器几分钟就能拉起来，这对 CI 弹性扩容很关键。第三是它的对象存储 Spaces 和 CDN 配合，适合放系统镜像这种大文件，用户下载走 CDN 边缘节点，源站压力小很多。

对比一下常见的几个选择：如果追求极致便宜，可能会看一些按小时计费更低的平台，但往往在流量和快照上找补回来；如果追求生态完整，大厂云功能确实多，但配置复杂度也上去了，对一个桌面发行版项目来说属于杀鸡用牛刀。DigitalOcean 的位置刚好在"够用"和"不折腾"之间。

提示：选云平台别只看 CPU 和内存单价，把带宽、快照存储、对象存储请求数这些隐性成本一起算进去，很多时候账面上的便宜机器实际跑下来更贵。

2.3 迁移前必须盘清楚的资产清单

动手之前，我建议先把现有基础设施列个清单，不然迁到一半发现漏了东西很麻烦。Omarchy 这类项目通常包含这几类资产：

这张表看着简单，但每一项背后都有细节。比如构建环境的可复现性，如果之前是手工在一台机器上装了一堆包，迁移时就得把这些包固化到脚本或镜像里，否则新环境跑出来的产物可能不一致。再比如密钥管理，CI 里用的签名密钥、API token，迁移时要确保新环境能安全读取，而不是硬编码在脚本里。

3. 把 Arch 构建环境搬上云主机的完整过程

3.1 云主机规格怎么选才不浪费

构建 Arch 系统镜像对机器的要求和跑 Web 服务完全不同。它吃的是多核 CPU 和快速磁盘，内存反倒不是瓶颈。我一般会这样估算：如果本地构建一次镜像要 20 分钟，用的是 8 核，那云主机至少也要 8 核起步，否则构建时间会拉长到难以接受。磁盘方面，一定要选 SSD，而且要注意 IOPS 上限，有些低价套餐的 SSD 是共享 IO，构建时磁盘等待会很高。

DigitalOcean 的 General Purpose 和 CPU-Optimized 两类 Droplet 都适合构建场景。CPU-Optimized 单核性能更强，适合编译密集型任务；General Purpose 内存和 CPU 更均衡，适合同时跑多个构建任务。我的经验是，如果构建脚本里有大量并行编译（比如 make -j），CPU-Optimized 更划算；如果是串行打包为主，General Purpose 够用。

内存方面，Arch 的构建环境本身不重，但打包大镜像时会有临时文件占用，建议至少 4GB，8GB 更稳妥。磁盘至少 80GB，因为镜像产物、缓存、临时文件加起来很容易超过 50GB。

3.2 从零配置一台可用的构建机

拿到一台全新的 Droplet 后，配置构建环境的步骤要尽量脚本化，这样以后扩容或重建都能复用。下面是我实际用的一套流程，基于 Arch 的包管理逻辑，但云主机初始系统可能是 Ubuntu，所以第一步是处理基础环境。

# 更新系统并安装基础工具 apt update && apt upgrade -y apt install -y curl wget git rsync build-essential # 安装 arch-install-scripts，用于构建 Arch 环境 apt install -y arch-install-scripts # 创建工作目录 mkdir -p /srv/omarchy/{build,cache,output}

这里有个细节：在非 Arch 系统上构建 Arch 镜像，通常用pacstrap或mkarchiso。mkarchiso是 archiso 包提供的工具，需要从 Arch 仓库获取。如果云主机是 Ubuntu，直接装 archiso 不方便，更常见的做法是用 Docker 跑一个 Arch 容器来做构建，这样环境隔离干净，也方便复现。

# 用 Docker 跑 Arch 构建环境 docker run --rm -it \ -v /srv/omarchy/build:/build \ -v /srv/omarchy/cache:/var/cache/pacman/pkg \ -v /srv/omarchy/output:/output \ archlinux:latest /bin/bash

把 pacman 缓存目录挂载出来是关键一步。Arch 的包缓存默认在/var/cache/pacman/pkg，如果不挂载，每次构建都要重新下载所有包，既慢又费流量。挂载之后，第二次构建能省掉大量下载时间。这个缓存目录也可以定期同步到对象存储，作为跨机器的共享缓存。

3.3 镜像源配置：迁移后最容易翻车的地方

迁移到云平台后，镜像源配置是第一个会咬人的地方。Arch 的默认镜像源列表是全局的，但云主机的地理位置决定了哪个源快。DigitalOcean 的机房分布在不同区域，如果机器在新加坡，却用着欧洲的源，下载速度会惨不忍睹。

配置镜像源的正确做法是先用 reflector 测速，再写入配置：

# 安装 reflector pacman -S reflector # 按速度排序，取最快的 10 个源，只保留 https reflector --country China --age 12 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

如果构建机在海外，--country参数要换成对应区域，或者干脆不限国家，让 reflector 按实际延迟排序。这里有个坑：reflector 测速依赖网络状况，如果跑的时候网络抖动，选出来的源可能不是最优。我的做法是跑两三次，对比结果，取稳定出现的源。

注意：镜像源配置改完后，一定要跑一次pacman -Syyu强制刷新数据库，确认没有报错。我遇到过改完源但数据库还是旧的，构建时包版本对不上，排查了半天。

另外，如果构建环境在 Docker 容器里，镜像源配置要写进容器的/etc/pacman.d/mirrorlist，而不是宿主机的。这个容易搞混，尤其是挂载了宿主机目录的时候。

3.4 构建缓存与产物的存放策略

构建缓存和产物不能都堆在云主机本地磁盘上，原因有两个：一是磁盘容量有限，二是机器一旦销毁，缓存就没了。合理的做法是分层存放。

本地磁盘放热缓存，也就是最近几次构建用到的包和中间文件，追求读写速度。对象存储放冷缓存和最终产物，追求容量和持久性。DigitalOcean 的 Spaces 兼容 S3 协议，可以用 s3cmd 或 rclone 来同步。

# 用 rclone 同步缓存到 Spaces rclone sync /srv/omarchy/cache spaces:omarchy-cache/pacman # 构建完成后上传产物 rclone copy /srv/omarchy/output spaces:omarchy-releases/$(date +%Y.%m.%d)/

产物上传后，分发就走 Spaces 的 CDN。用户下载镜像时，请求打到最近的边缘节点，源站只负责回源，压力小很多。这里要注意设置合适的缓存头，镜像文件内容不变，可以设长缓存；但版本索引文件要设短缓存，否则用户看不到新版本。

4. CI 流水线在云上的重新编排

4.1 Runner 部署方式的选择

CI 流水线迁移的核心是 Runner 放哪。常见有三种做法：跑在固定的 Droplet 上、用容器按需拉起、或者用托管 Runner。固定 Droplet 最简单，但扩容不灵活；容器按需拉起弹性好，但配置复杂；托管 Runner 省心，但可能不满足自定义构建环境的需求。

Omarchy 这类项目构建环境特殊（需要 Arch 容器、需要大磁盘），托管 Runner 往往不适用，所以更可能是固定 Droplet 加容器的方式。具体做法是在一台配置较高的 Droplet 上装 Docker，Runner 以容器形式运行，构建任务再在 Runner 里起 Arch 容器。

# 以 GitLab Runner 为例的配置片段 [[runners]] name = "omarchy-builder" executor = "docker" [runners.docker] image = "archlinux:latest" privileged = true volumes = ["/srv/omarchy/cache:/var/cache/pacman/pkg", "/srv/omarchy/output:/output"] shm_size = 0

privileged = true在构建系统镜像时经常需要，因为要挂载 loop 设备、操作分区。但这也带来安全考量，所以 Runner 机器要和其他服务隔离，不要在上面跑对外暴露的服务。

4.2 构建任务的触发与并发控制

构建任务不能无限制并发，否则会把机器资源吃光，反而拖慢所有任务。合理的做法是设置并发上限，并且区分任务优先级。发版构建优先级高，可以独占资源；日常测试构建优先级低，排队执行。

在流水线配置里可以用资源组（resource_group）来控制同一时间只有一个发版任务在跑：

build_release: stage: build resource_group: release_build script: - ./scripts/build-iso.sh - rclone copy output spaces:omarchy-releases/

resource_group的作用是同一组的任务串行执行，避免两个发版构建同时跑导致产物冲突或资源争抢。这个机制在 GitLab CI 里叫 resource_group，其他 CI 平台也有类似概念，名字可能不同。

触发方式上，发版构建建议手动触发或打 tag 触发，日常构建可以每次 push 触发。手动触发的好处是可控，不会因为一次误提交就启动一个耗时很长的构建。

4.3 密钥与凭证的安全管理

CI 里要用到不少敏感信息：对象存储的访问密钥、签名用的 GPG 私钥、可能还有通知服务的 token。这些绝对不能写在代码或流水线文件里，要用 CI 平台提供的密钥管理功能。

以 GitLab 为例，在项目设置的 CI/CD Variables 里添加变量，并勾选 Masked（日志里隐藏）和 Protected（只在受保护分支可用）。GPG 私钥这种多行内容，可以 base64 编码后存成变量，用的时候解码。

# 在流水线里还原 GPG 私钥 echo "$GPG_PRIVATE_KEY_BASE64" | base64 -d | gpg --import

这里有个实操心得：GPG 签名在非交互环境下需要设置--batch --yes --pinentry-mode loopback，否则会卡在密码输入。如果私钥有密码，还要通过--passphrase传入，或者用 gpg-agent 预设。我踩过这个坑，流水线跑到签名步骤就挂起，日志里啥也没有，最后发现是等密码输入。

提示：密钥轮换要提前规划。迁移时顺便把旧密钥换掉，别把老环境的密钥直接搬过来，尤其是如果旧环境的密钥可能已经泄露或权限过宽。

5. 迁移过程中真正会卡住人的几个坑

5.1 网络与 DNS 切换的时序问题

迁移不是一次性切换，而是新旧并行一段时间。这期间 DNS 怎么切、证书怎么续、旧服务什么时候下线，都有讲究。最常见的错误是 DNS 切太快，新环境还没验证完就切过去，结果用户访问到半成品。

我的做法是分三步：第一步，新环境用临时域名验证所有功能；第二步，把正式域名的 TTL 调低（比如 300 秒），等旧 TTL 过期；第三步，切换 DNS 到新环境，观察一段时间再下线旧环境。TTL 调低这一步很多人省掉，结果切换后旧记录还缓存着，一部分用户访问旧环境，一部分访问新环境，数据不一致。

证书方面，如果用 Let's Encrypt，新环境要提前申请好证书，别等 DNS 切过去才申请，因为验证需要域名已经指向新环境。可以用 DNS 验证方式提前签发，这样不依赖域名指向。

5.2 构建产物一致性怎么保证

迁移后最怕的是新环境构建出来的镜像和旧环境不一致，用户装完发现行为变了。保证一致性的关键是固定工具链版本和构建脚本。Arch 是滚动发行版，包版本一直在变，如果不锁定，今天构建和明天构建的产物就可能不同。

锁定版本有几种做法：一是用 Arch 的存档仓库（Archive），指定日期快照；二是在构建脚本里固定关键包的版本；三是把整个构建环境做成容器镜像，打上版本标签，每次构建用同一个镜像。

# 固定构建环境的 Dockerfile 示例 FROM archlinux:base-20240101.0.204074 RUN pacman -Syu --noconfirm archiso git make # 后续构建都基于这个镜像

用带日期标签的基础镜像，能保证每次构建的起点一致。虽然 pacman -Syu 还是会更新到最新，但至少基础环境是固定的。更严格的做法是把所有包版本写进一个清单，构建时按清单安装。

5.3 成本失控的预防

云平台按用量计费，稍不注意账单就上去了。迁移后要盯几个指标：Droplet 运行时长、对象存储容量和请求数、CDN 流量、快照存储。构建机如果 24 小时开着但实际只用几小时，就是浪费。可以考虑用定时开关机，或者用按需创建的临时构建机。

对象存储的请求数容易被忽略。如果 CI 频繁列出桶内容、频繁上传小文件，请求数会累积得很快。优化方法是合并小文件、减少列桶操作、用 CDN 缓存减少回源请求。

# 设置 Spaces 生命周期规则，自动清理旧缓存 # 在 DigitalOcean 控制台配置，或通过 API # 规则示例：30 天前的缓存对象自动删除

我建议迁移后第一个月每周看一次账单明细，找出异常增长的项目。很多时候不是大项超支，而是一堆小项加起来超了预期。

6. 迁移完成后，日常运维要盯住哪些东西

6.1 构建流水线的健康监控

迁移不是终点，日常运维才是。构建流水线要监控几个关键指标：构建成功率、平均构建时长、队列等待时间。成功率下降往往意味着依赖源出问题或环境漂移；构建时长突然变长可能是缓存失效或磁盘 IO 下降；队列等待时间长说明并发不够或任务卡住。

监控可以用简单的脚本加通知，不必上重型监控系统。比如每次构建结束把结果写到一个日志文件，定时脚本统计最近 N 次的成功率和时长，异常时发通知。

# 简单的构建结果记录 echo "$(date +%s),$CI_PIPELINE_ID,$CI_JOB_STATUS,$CI_JOB_DURATION" >> /var/log/omarchy/builds.csv

这个 CSV 后续可以用任何工具分析，比在 CI 界面里翻历史记录方便得多。

6.2 镜像分发的可用性检查

用户下载镜像的体验直接决定项目口碑。要定期检查下载链接是否可用、速度是否正常。可以写个脚本，从不同地区（如果有条件）拉取镜像头部，测响应时间和速度。

# 检查镜像下载响应 curl -sI -o /dev/null -w "%{http_code} %{time_total}s %{size_download}\n" \ https://releases.example.com/omarchy-latest.iso

如果发现某个地区下载慢，可能是 CDN 节点覆盖问题，或者源站回源慢。DigitalOcean 的 CDN 在不同区域表现有差异，必要时可以针对特定区域做优化。

6.3 备份与灾难恢复

云平台虽然可靠，但不等于不用备份。构建脚本、CI 配置、密钥、产物索引这些都要有备份。备份策略要明确：备份什么、存哪、多久一次、怎么恢复。我见过项目把 CI 配置只存在平台里，结果平台账号出问题，配置全丢。

备份至少要有两份，一份在对象存储，一份在本地或其他平台。恢复流程要实际演练一次，别等真出事才发现备份不能用。演练时重点验证：新机器能否用备份快速重建构建环境、密钥能否正常导入、产物能否重新分发。

7. 我个人在类似迁移里攒下的几条经验

迁移这件事，技术方案可以照搬，但有些经验是踩过才知道的。第一条，别追求一次迁完。把基础设施拆成独立模块，一个一个迁，每迁一个验证一个。全量迁移一旦出问题，排查范围太大。第二条，旧环境别急着删。新环境跑稳之前，旧环境保持可回滚状态，哪怕多花几天成本也值。第三条，文档要跟着迁移更新。很多项目迁移后文档还写着旧地址、旧流程，新人照着做就出错。

还有一条关于成本：云平台的免费额度和试用金要利用好，但别依赖。迁移初期用试用金跑，容易对真实成本没概念，试用结束账单出来才发现超预算。我的做法是迁移前就用正常计费跑一周，摸清真实用量，再决定规格和优化方向。

最后说个细节，时区。云主机默认可能是 UTC，构建脚本里如果有依赖本地时间的逻辑（比如按日期命名产物），要统一时区，否则产物命名会乱。这个坑很小，但排查起来费时间，因为构建本身是成功的，只是文件名不对。

整套迁移做下来，最大的感受是：基础设施迁移的难点不在技术，而在细节的完整性和时序的把控。技术方案网上都能查到，但每个项目的资产清单、依赖关系、切换时序都不一样，这些只能自己盘清楚。Omarchy 这次迁移到 DigitalOcean，选型合理，路径清晰，剩下的就是执行和运维的功夫了。