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 配置流水线定义、触发规则Runner 部署、密钥管理文档站点静态站点、域名DNS 切换、证书辅助服务状态页、下载统计依赖关系、迁移顺序这张表看着简单但每一项背后都有细节。比如构建环境的可复现性如果之前是手工在一台机器上装了一堆包迁移时就得把这些包固化到脚本或镜像里否则新环境跑出来的产物可能不一致。再比如密钥管理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 -jCPU-Optimized 更划算如果是串行打包为主General Purpose 够用。内存方面Arch 的构建环境本身不重但打包大镜像时会有临时文件占用建议至少 4GB8GB 更稳妥。磁盘至少 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 上装 DockerRunner 以容器形式运行构建任务再在 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 0privileged 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 调低这一步很多人省掉结果切换后旧记录还缓存着一部分用户访问旧环境一部分访问新环境数据不一致。证书方面如果用 Lets 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选型合理路径清晰剩下的就是执行和运维的功夫了。