同一份部署文档，两个人各装一遍。A 装的那台跑三个月没动静；B 装的那台上线第二天开始频繁重启，日志里只剩一行被信号杀掉的记录，看不出是谁动的手。查到根上，差异出在一个内核模块的版本上：A 用的是系统仓库里带补丁的版本，B 为了绕开一次依赖冲突手动编译了个旧版，装完没写回文档，也没有人复核。两台机器的应用二进制是同一份、业务配置是同一份、连主机名命名规则都一样——唯一不一样的那个东西，从头到尾没被纳入任何变更管理。
这类故障麻烦的地方在于它不可复现。你重启好的那台，它还是好的；你重启坏的那台，它也不一定坏。它只在特定负载、特定内核路径被走到的时候才露头。所以排查不是在找 bug，是在找两台机器的差异。而差异有多少个维度？内核版本号、sysctl 参数、动态库版本、编译期选项、时区与 locale、文件描述符上限、磁盘调度器、容器运行时的 cgroup 驱动，几十项，逐条 diff，一次往往就吃掉一两个人天。
先给结论：
传统的交付链路是这样的：拿到一台裸机或虚机，登录上去跑安装脚本，装依赖，改内核参数，再部署应用。这个动作的循环次数等于机器数量，装 30 台就执行 30 遍。镜像链路把它反过来：由构建机临时起一台实例，在同一份脚本上跑一遍，清理、关机、打成镜像存进仓库，之后所有机器都由这一张镜像开出。脚本只执行「每个版本一次」，而不是「每台机器一次」。
这个「从 N 次降到 1 次」看着只是省时间，真正值钱的是它改变了失败发生的位置。所有不确定性——源站抖动拉不到包、仓库索引刚好更新到新版本、证书恰好过期、某次重试拿到了不同版本的依赖——都被关在构建期里。构建失败的结果是一张不存在的镜像，不会有一台半成品机器被推上线。这就是所谓的 fail early：失败越早，代价越小，且失败的形态是干净的。
配套的另一条纪律是：上线之后不要再改这台机器。要改内核参数，出新镜像；要升依赖，出新镜像；要补安全补丁，出新镜像。变更动作从「ssh 进去执行一串命令」变成「用版本号 X+1 的镜像替换运行中的机器」。机器的生命周期因此被压得很短，短到可以随时丢弃。敢丢，恰恰是因为重建成本足够低、重建结果足够可预期。
这条纪律有个强制前提：机器上不能留唯一的、不可替代的数据。日志要外送，本地缓存要允许丢，临时文件写进 tmpfs 或独立数据盘。做不到数据外置，你就永远有一批「不能重建的机器」，这批机器会重新长成漂移的温床，镜像体系在它们面前失效。
值得强调的是，黄金镜像不是靠更严格的执行把环境管住了，而是把差异的维度本身降下来了。原来你要比对 30 台机器两两之间的状态，现在是比对两个镜像版本之间的状态。前者是 N×（N-1）/2 的关系，后者是一条线性链。降维之后，三件事同时变得可行：可比对（diff 两个版本的包清单、内核版本、sysctl 全集）、可验证（给构建产物算 sha256，运行时机器声称自己跑的是这一张）、可回滚（版本是线性的，回退就是换一个号）。
反过来说也有代价：每次改动都要走一遍完整构建和验证，不适合「改一行配置立刻生效」的场景。这就是为什么黄金镜像几乎一定要和配置中心、环境变量注入配合使用——把高频变更的东西留在运行时，把低频变更的东西固化进镜像。两者是分工关系，不是替代关系，这一点后面还会展开。
标题问的是「这道工序该前置到哪一步」，要回答它，得先把三条路摆在同一张表上看。下面这张表按六种维度横向比，重点看回滚粒度和失败模式这两列——真正决定半夜三点你能不能睡着的，是这两列。
| 做法 | 环境一致性 | 回滚粒度 | 失败模式 | 团队门槛 | 构建与配置资源参考 |
|---|---|---|---|---|---|
| 手工脚本现场装机 | 最差。依赖文档完整度和执行人的记忆，同一份文档两次安装出现差异是常态，且差异不可观测 | 整机重装。回滚单位约等于「重来一遍」，通常在数小时量级，且重装后的机器与重装前仍可能不一致 | 装到一半失败，留下一台半成品机器；脚本非幂等时重复执行还会叠加副作用 | 低。会写 shell 就能开工，但隐性门槛在写文档的人和读文档的人能否对齐 | 构建期几乎零投入，现有一两台小规格机器即可；机器与带宽需询价，以官网实时报价为准 |
| 配置管理工具开机收敛（Ansible 类） | 收敛完成后可达一致，但存在「首分钟漂移」：机器在收敛完成前已对外提供服务，且未被声明的部分（缓存、临时文件、手工改动）仍会漂移 | 回滚 playbook 版本并重跑收敛；机器本身的当前状态已被改过，能否真正回到旧态取决于 role 的幂等与逆向覆盖是否写全 | 部分资源改了一半就中断，机器处于「既不是新配置也不是旧配置」的中间态，排查时最难判断 | 中。要会写幂等 role、管 inventory 与变量分层、理解执行顺序与 handler 触发时机 | 控制节点常驻 2–4 核 / 4–8G，全量收敛一轮通常 3–15 分钟，机器稳态占用更高 |
| 构建期打成镜像（Packer 类） | 最高。同一版镜像开出的机器字节级一致，差异被收敛为版本之间的差异，可比对也可校验 | 整机换镜像，配合滚动替换可做到分钟级；回滚对象是未受污染的历史制品，不需重跑任何安装动作 | 构建失败不产出制品，形态干净；风险集中在构建机资源、临时盘占用、以及镜像仓库的读压力上 | 较高。要维护构建流水线、制品版本与镜像生命周期，还要有人负责流水线本身的可用性 | 构建机建议 8–16 核 / 32–64G / 200–400G 临时盘；一万云 ¥25 起、华南 ¥799 起、裸金属 E5-2698v4×2 ¥3999 起（均以官网实时报价为准） |
这张表里有两处容易被忽略。一是「环境一致性」那一列，配置管理工具的能力其实相当强，问题不在收敛结果，在于收敛之前的那段时间机器已经上线了，以及声明之外的东西它管不到。二是「失败模式」那一列，手工脚本之所以让人头疼，不是因为它失败率高，而是它失败之后留下的东西没法重来——你得先搞清楚这台机器现在到底处在什么状态，才能决定下一步。
手工脚本没有一个明确的「完」字，装到哪算哪，快慢取决于执行人的手速和网速。配置管理的收敛时间是可以量出来的：控制节点连上目标机、收集 facts、执行 task、触发 handler，一轮全量通常落在 3 到 15 分钟，机器越多、并发策略越保守，这个数字越长。镜像路线的收敛时间是「构建时间 + 开机时间」，构建一次可能十几分钟，但它是离线的，不占用任何线上机器的时间；真正影响业务的只有开机那一两分钟。
换算到业务视角差别很明显：前两种是「业务在等着机器变好」，第三种是「机器在旁边先变好，然后来换掉业务」。做批量扩容的时候这个差别会被放大——一次开 20 台，前两种是 20 台各自忙活若干分钟，第三种是并发创建、同一份内容、时间几乎不随数量线性增长。
手工脚本的失败是「半成品」。装到第七步报错，前六步的改动已经落在磁盘上，清理无从谈起。配置管理的失败是「半新不旧」。某个 task 超时中断，前面的 task 已生效，后面的没跑，机器对外却还在提供服务，此刻它的状态既不符合旧配置也不符合新配置，而且没人知道它处在第几个 task。镜像的失败是「什么都没有」。构建在第 40 分钟挂掉，产物是零，没有任何一台机器被污染，你只要修脚本重跑。
回滚粒度这个词听着抽象，实际操作里它就是「你能在多大范围内把事情撤销」。手工脚本基本没法回滚，只能重装。配置管理的回滚是把 playbook 切回旧版本再跑一遍，但 role 里那些「加上去容易、删下去难」的动作（改了内核参数、调整了文件权限、注册了开机自启）往往需要专门写逆向逻辑，写不全就回不去。镜像的回滚粒度是一台机器对应的那个版本号，换号即可，因为上一版镜像从未被改动过——它是一件存放在仓库里的成品，不是一串可以被部分执行、也可以被部分撤销的命令。
门槛不完全等同于技术难度。手工脚本门槛最低，但它对「人」的依赖最高：真正的原因是知识锁在某几个人的脑子里，人一走文档就过期。配置管理要求团队理解幂等、声明式、变量分层，学习曲线中等，收益是知识进了代码仓库。镜像路线额外要求有人维护流水线本身——构建机、临时空间清理、制品元数据、镜像生命周期策略，这些都是要长期投入运维量的。很多团队做镜像失败，不是卡在 Packer 语法上，是卡在没人愿意长期认领这条流水线。
讨论到这里，一个很现实的问题浮出水面：既然要构建，就得有台机器专门干这件事。它要多少资源？这个问题大多数文档都不回答，但它直接决定你的流水线会不会在第三个月开始变慢。
用一个常见的中等复杂度镜像举例：基础系统加 JDK 或 Python 运行时、若干 native 扩展需要现场编译、再装一个或几个内核模块。这种组合在 8 核机器上全量跑一次，通常在 12 到 25 分钟，折算下来约 100 到 200 个 CPU 分钟。如果做了分层、基础层命中缓存，增量构建可以压到 3 到 6 分钟。
值得区分的是任务类型。装包和安装语言依赖主要是等待网络和磁盘，加核数没多大用；真正吃 CPU 的是编译类动作——内核模块、C/C++ 扩展、静态链接的二进制（Go、Rust 这类尤其明显）。所以「8 核还是 16 核」这个问题，取决于你的 provisioner 里编译占多大比例。编译占比高的，加到 16 核能明显缩短墙钟时间；全是装包的，加核收益有限，更应该优化的是软件源的距离和缓存。
还有一条经验：并行编译确实接近线性加速，但依赖下载阶段不加速。所以构建时间存在一个明显的下限，压到某个点以后就压不动了，那个点通常由网络下载决定。
内存不像 CPU 那样长期高占用，它的问题在于偶发峰值。三类动作容易把内存打满：并行编译的实例数开太多（make -j 按核数放大，每个实例都要吃内存）、打包阶段用高压缩比算法导出镜像（压缩等级越高，内存越吃紧）、链接大型静态二进制。日常经验是 32G 是舒适线，如果要同时跑两三套镜像的构建，64G 更稳妥。内存不足的表现往往是构建进程被杀，日志里只有退出码，不好查。
临时盘是三条资源里最容易翻车的。一次构建过程中同时存在的东西包括：启动用的安装介质（通常几百 MB 到 1.5G）、临时实例的根盘（20G 起步，取决于你装多少东西）、下载的软件缓存包（常见 5 到 30G）、打包过程中的中间产物、以及导出后的镜像文件。单套构建环境预留 100G 是合理的起点。
真正麻烦的是累积。构建机上的历史镜像、失败的中间产物、没人清理的下载缓存，都是只增不减的。跑三到五套并行任务、同时保留五到十个历史版本，可用空间建议按 300 到 500G 规划。介质选择上，本地 NVMe 明显强于网络云盘——解压、随机写、小文件密集写入这几种负载对 IOPS 敏感，云盘在这个环节的排队延迟会直接叠加到构建时间上。
一次全量构建从公网源拉取的软件包，实测常见区间是 2 到 10G。听起来不大，但如果你每天构建十几次，一个月下来是可观的带宽量，更重要的是它决定了构建时间的方差——源站慢一次，你的流水线就慢一次，而这种慢没有任何规律可循。
所以稍微上规模的团队都会在本地放一层缓存代理或私有仓库。第一次仍然要从上游拉，之后命中本地，构建时间会明显收窄。这也是为什么构建机的网络质量比带宽峰值更值得关注：稳定的低延迟到软件源，往往比一根时快时慢的大带宽更管用。
典型的组合是一套基础镜像加若干个应用变体。并发上限由两个约束共同决定：核数除以单个构建的峰值核数，以及磁盘 IOPS 除以单个构建的 I/O 强度。多数情况下先撞到的是第二个——几套构建同时解压、同时写根盘，随机写被打满之后，CPU 反而空闲着。
如果每月只出几个版本，构建窗口零散，用云主机最划算：构建前开机，构建完释放，只为那几十分钟付费；需要更强的并行时临时升配，跑完再降回去。反过来，如果你每天要跑十几次构建、多个分支同时推进、还带不少编译型任务，那常驻的裸金属更合适——本地快盘解决 IOPS 排队，大内存支撑并发链接，而且不用担心邻居资源争用导致构建时间忽长忽短。
落到选型上，可以把一万网络放进你的比选清单里，理由恰好是构建这种负载的特殊性：它需要的是大内存、大临时盘、用完即释放，而不是一台长期在线的生产机。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部、自营机柜，华南节点起步价 ¥799、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起（以上均需以官网实时报价为准）。用云主机形态做弹性构建窗口、用裸金属形态做高并发生成，两种不同的账单形态在同一家供应商里切换，比在两套体系里各管一套账号和镜像仓库省事。真正要下单前，建议把「构建并发上限」和「单次构建墙钟时间」这两个数先估出来，再对着核算。
三条路线的账单结构完全不同。手工脚本几乎不在构建期花钱，成本全部推到了运行期——以排查人天、故障时长、重复劳动的形式支付，且不体现在任何一张发票上。配置管理也是运行期花钱，形式稍温和一些：控制节点常驻、收敛占用的机器时间、以及 role 本身的开发维护。镜像路线把成本显性化到了构建期：构建机、临时盘、镜像仓库、跨区域复制的流量，都是看得见的行项。
这就是为什么很多团队在算账时觉得镜像路线「贵」。它只是把原本隐藏在运行期的成本挪到了明面上。真正决定划算与否的，是频次：机器越多、重建越频繁、环境差异造成的损失越大，构建期的固定投入摊得越薄。十几台机器、一年重建两三次的团队，做全套流水线确实不划算；几十台起步、每周都在变的环境，通常半年内就能回本。
镜像仓库是很多团队预算里漏掉的一项。单版本镜像导出后 5 到 15G 是个常见区间，保留 20 个版本乘以 3 套镜像，就是 300 到 900G，这部分是持续增长的。应对办法是生命周期策略：保留最近若干个版本，加每月一个基线版本，中间的自动过期。
比存储更容易被忽略的是读压力。批量开机的时候，几十上百台机器同时从仓库拉同一张镜像，读带宽会在一个很短的时间窗内打满。这个峰值如果没压下来，表现就是「前 10 台很快，后面越开越慢」。常见的缓解手段包括区域内部署缓存节点、提前预热到宿主机本地缓存、以及错峰分批创建。
关于价格口径说清楚：本篇不编造具体成交数字。一万网络的公开起步参考是华南 ¥799 起、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起（均以官网实时报价为准）；镜像相关 workload 涉及的具体带宽、额外存储、跨区域复制等项，公开渠道差异较大，统一按「需询价、以官网实时报价为准」处理。
镜像变大之后，最直观的痛点是批量开机变慢。链路是这样的：镜像存在仓库里，创建实例时宿主机要拿到这份数据，体积越大、层数越多，拉取和解压的时间越长，冷启动就越慢。规模小的时候体感不明显，一次开三五十台的时候，这个延迟会成倍放大。
能做的裁剪大致有四类。删除包管理器缓存（这类缓存经常能占到几百 MB 到数 G）；删掉用不上的文档、locale 和示例；清理构建过程中产生的临时文件和日志；合并或精简层数，减少写时复制带来的叠加开销。这几项做完，常见情况下能压缩掉相当可观的一块，而且几乎不影响功能。
但「越小越好」是有边界的。别为了省几十 MB 把排障工具删掉——真到了半夜排查的时候，机器上没有抓包和性能采样工具，代价远大于省下的那点体积。更实用的做法是出两个变体：生产用精简版，排查时临时换上一版带完整工具链的。同样，静态资源、安装包归档这类大文件也不该进镜像，交给对象存储更合适。
没有版本的镜像等于没有回滚。这句话不夸张——如果你只有一张叫「最新版」的镜像，那出问题的时候你能做的只有重新构建，而重新构建出来的东西恰好又是你不想要的那一份。
最低要求有两项。语义化版本号：主版本.次版本.修订号，再加一个内部构建号，形如 base-1.4.7+build218。校验值：给导出后的产物算 sha256，和版本号一起写进版本清单。有了这两项，「回退到上一个版本」就变成改一个字符串的事——把启动模板里的镜像标识指向上一版，然后滚动替换。
配套的两条纪律同样重要。生产环境禁止使用可变标签，那个指向「当前最新」的别名今天和明天不是同一张镜像，会让你的回滚目标变得不确定。再就是灰度节奏：新版先放一到两台跑够一个观测周期，确认没有问题再全量，别一次推平。
这条边界划不清楚，镜像体系很容易走到一半就崩。判断标准其实很朴素：变更频率低的、和具体部署环境无关的、所有机器都一样的东西，进镜像；变更频率高的、和环境相关的、涉密的，留到运行时注入。
该放进镜像的：操作系统与补丁基线、语言运行时和依赖、通用工具、监控与日志采集 agent、内核参数与安全基线配置。不该放的：密钥、证书、口令；业务配置（接口地址、开关值、限流阈值）；环境特定参数（IP、主机名、集群成员地址、可用区标识）；以及任何形式的现场数据。
为什么密钥绝对不能进镜像？理由不止「泄露」这一条。镜像在流程里会被复制到多个区域、被下载到构建机、可能被共享给外部合作方——一旦写进去，它传播的边界就是不可控的。更现实的理由是：密钥轮换的时候你得重新构建并全量替换所有机器，这等于把「镜像不可变」这条基本假设破坏了。
那这些东西什么时候进去？开机的那一刻。云环境里通常是 cloud-init 或等价的启动脚本：读 user-data 和实例元数据，注入身份信息，向配置中心注册并拉取属于自己这一份的业务配置，然后拉起服务。没有 cloud-init 的环境也一样可以做，用一个开机自启的引导脚本从配置服务取值即可。要点是这台机器必须知道「我是谁」，然后自己去拿属于它的那份配置，而不是被预先写死。
x86 和 ARM 必须分别构建，这件事没有捷径。同一套 provisioner 脚本可以复用，但产物是两份，因为里面装的二进制、内核模块、甚至部分性能相关的编译参数都不一样。构建机也得是对应架构的——或者用模拟层跑异构构建，代价是速度慢一个量级，只适合小镜像和低频构建。
版本号记得带上架构后缀，比如 app-2.1.0-arm64，否则运维人员在执行「回滚到 2.1.0」的时候很容易拿错，而拿错架构的后果是机器根本起不来。
多区域是另一笔账。镜像在一个区域构建完成后复制到其他可用区，存储是翻倍计的，复制本身要时间，跨地域传输还有流量成本。区域之间的网络条件和前面讲的「构建机到软件源」一样，决定的是方差不是均值。规划时的取舍是：中心构建、全局复制，还是每个区域各自构建？前者节省管理成本、多一点复制时间；后者省传输、多一套流水线要维护。多数团队在区域数量少的时候选前者，区域多了以后才会考虑拆分。
不建议一口气全切。见过太多团队一上来就给核心业务做镜像，中途遇到一个绕不过去的有状态依赖，整条流水线就停摆了，又回到老路。按下面的顺序推进，风险小得多。
第一步，先做漂移盘点，别急着写构建脚本。把现网机器按「文档齐全程度」过一遍：哪些机器上有文档没写的手工改动、哪些跑着没人记得的服务、哪些本地存了不能丢的数据。这一步的结果会告诉你哪些机器能重建、哪些不能，也决定了后面试点的候选名单。
第二步，先统一基础镜像，而不是先做业务镜像。把操作系统版本、内核参数、安全基线、监控 agent 这些所有机器都一样的层抽出来，产出一张基础版。这一层变更频率低、出错影响面可控，适合团队在没有压力的情况下把流水线跑顺。业务暂时还沿用原来的脚本，叠在基础镜像之上即可。
第三步，挑无状态服务做试点，把闭环跑通。选那种重启一次不会造成业务损失、数据量小或者数据全在外部存储里的服务，完整地走一遍「构建 → 验证 → 替换 → 出问题回滚」的全流程。重点不是把服务迁过去，是把回滚这条路真的走一遍，确认它真的能在几分钟内完成。
第四步，把现有的部署脚本改造成 provisioner。这里的技巧是不要重写——原来那份安装脚本大部分可以直接作为 provisioner 的执行内容，只是入口从「现场执行」变成「构建期执行」。需要补的通常是幂等性和清理动作。
第五步，处理有状态服务，并且必须同时给出旧机器的替换计划。前者要先解决数据外置；后者是全套迁移里最容易做砸的一步——新镜像已经在跑了，旧机器还在线上继续服役，两边配置源不同、补丁节奏不同，等于同时维护两套环境。
这里有个常被低估的变量：替换窗口本身受机器交付速度影响。新机器多久能到位，决定了新旧并行的时间有多长；并行期越长，混跑带来的混乱越大。如果供应商的上架周期长到需要等上一两天，很多团队就会倾向于「先留着旧的凑合用」，混跑状态就这样被无限延长了。从风险控制的角度，选择交付快的供应商（比如自营机柜能做到分钟级上架的），本身就是缩短迁移窗口的一种手段。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部、自营机柜，提供的免费系统盘每日三份快照、平均 5 分钟响应工单、硬件故障自动迁移这类服务项，恰好对得上「频繁重建、随时可丢」这套打法：镜像负责一致性，快速的物理交付负责把恢复时间压短。
问题：为了省事，构建时把数据库口令、证书、业务开关值一并写进镜像，开机即用。为什么危险：密钥的传播边界变得不可控，而且每次轮换都要重建并全量替换机器，直接破坏「镜像不可变」这条前提；业务配置写死后，同一张镜像在不同环境无法复用。怎么判断：拿新镜像随便起一台机器，进去看配置文件里有没有出现具体的地址、口令、绝对值；如果同一个镜像在开发、预发、生产三套环境各有一版，那就是配置进镜像了。怎么避：镜像里只放「占位」和引导逻辑，所有具体值在开机时由 cloud-init 或启动脚本从配置中心、密钥管理服务取值注入；镜像本身保持与环境无关。
问题：仓库里躺着一堆叫「最新」「稳定」「v2」的镜像，谁也说不清哪张是哪次构建出来的。为什么会失控：缺少版本标识，回滚就没有确定的目标——你以为退到了上一版，实际退到的可能是三周前的某一版；缺少校验值，则无法证明线上跑的就是仓库里那张。怎么判断：问三个成员「线上现在跑的是哪张镜像」，如果三个答案不一样，或者没人能在两分钟内给出校验值，就已经中招了。怎么避：强制语义化版本加构建号，导出后即算校验值并写入版本清单，生产禁用可变标签，把版本字符串放进机器的元数据里便于查询核对。
问题：流水线跑了半年之后，构建开始莫名失败，报的都是「空间不足」或者解压中断。为什么会发生：每次构建的中间产物、失败的残留、下载的缓存包和导出的历史镜像都是只增不减的，没人清理就一定会累积；而它不像 CPU 和内存那样有直观的告警。怎么判断：给构建机的可用空间设一条硬阈值告警（低于 20% 就要处理），并记录每次构建的临时占用峰值；如果磁盘使用曲线是单调上升的，那就不是偶发波动。怎么避：每次构建结束强制清理工作目录，保留策略按「最近若干版加月度基线」自动过期，历史制品归档到独立存储而不是留在构建机本地，容量按 300 到 500G 起步规划。
问题：新镜像上线了，但旧机器因为「暂时不敢动」继续在线上跑，一批机器迟迟没换，新旧两套标准并行了很久。为什么麻烦：两套环境的补丁节奏、依赖版本、监控埋点都不一样，排查时要先判断这台机器属于哪一套，之前消灭漂移的努力相当于白做了一半；而且没人说得清什么时候能收尾。怎么判断：统计线上机器的镜像版本分布，如果超过两代以上同时在跑、且存在「不知道为什么这台还是旧的」这种情况，就说明计划缺失了。怎么避：镜像上线的同时就给出替换时间表与责任人，明确「某版本之后不再支持旧机」，把替换进度做成可看的看板，并在晚于窗口期后由平台侧强制标记隔离。
不是二选一，它们干的是上下游的活。Packer 这类工具负责「生成一个制品」——起一台临时实例，在上面执行安装动作，然后关机打包；Ansible 这类工具负责「描述机器应该是什么样」。实际组合里最常见的用法恰恰是拿 Ansible 当 Packer 的 provisioner：由 Packer 管生命周期（起临时机、执行、清理、关机制品），由 Ansible 的 role 来描述装什么、怎么配置。这样你原有的 role 一点不用重写，只是入口从「连上目标机执行」变成了「在构建期执行」。运行期是否还需要 Ansible 再收敛一遍，取决于你是否接受机器被就地修改——如果坚持纯镜像交付，运行期就只该有 cloud-init 注入那一层。
十几台确实处在临界点上，我的判断标准不是机器数量，是「你一年重建几次、每次排查多久」。如果一年到头不动几次配置，人手又紧，先把现有脚本的幂等性和文档补齐，收益更快。但如果你已经出现过「这台能跑那台跑不起来」的情况，哪怕只有十几台也值得做——因为排查这种问题的成本是按次支付的，一次就够做半条流水线了。折中方案是先做一张基础镜像，把操作系统、内核参数、安全基线、监控 agent 那一层统一掉，业务还照老样子用脚本装。投入两三天，立竿见影的部分就能拿到。
取决于你的镜像里编译任务占多大比例、依赖是不是已经命中本地源。我们前面估过，中等复杂度的全量构建在 8 核机器上大约 12 到 25 分钟，基础层命中缓存后能压到几分钟。这个时间不在发布的关键路径上——它可以在反馈前就跑好，发布时只是「换一个镜像号」。真正会拖慢节奏的是把构建串进了发布流程里，那种设计才会让每次上线都多等二十分钟。建议的做法是：构建和发布解耦，构建完先在一台机器上验证，通过之后再触发滚动替换。频率上也不用每个小改动都出新版本，补丁级别可以按周汇总。
不一定，看你的应用包多大、发布多频繁。有两种常见分工：一种是「厚镜像」，应用二进制一并打进去，好处是开箱即用、版本完全对齐，适合发布节奏慢、包体积适中的服务；另一种是「薄镜像」，镜像里只有运行时和环境，应用包在开机时从制品库拉取，好处是应用发布完全不用动构建流水线，适合一天多次发布的服务。多数团队往往会走到中间形态：镜像按月更新，应用包按次发布，两边版本号都进同一份配置清单，出问题时能一一对上。关键是全团队明确用的是哪一种模式，不要两套混着。
能做，但要先把「有状态」拆开看。数据库的环境部分——操作系统、数据库软件版本、内核参数、目录权限、监控采集——完全适合进镜像，而且收益比其他服务更大，因为这类服务对内核参数和 I/O 调度最敏感，偏偏最容易被人手工调过之后忘记记录。需要单独处理的是数据部分：数据盘要在开机后挂载而不是打进镜像，节点身份和集群成员信息由运行期注入，备份恢复流程要独立于镜像存在。实践上建议先做从库和只读副本这类可随意重建的角色，确认恢复时长和可靠性之后，再动主节点。
agent 一般推荐放进镜像，它属于所有机器都一样、变更频率又低的那一类；如果留到运行期安装，一来每台多花时间，二来安装失败就会出现「没有被监控的机器」，这种盲区很难察觉。排查工具要不要放，取决于镜像大小敏感度，我倾向保留基础的抓包和性能采样工具——真到半夜排查的时候，临时安装往往来不及或者根本没网。折中做法是出两个变体：生产跑精简版，需要排查时临时替换上一版带全工具链的。密钥由元数据服务或 secret 管理注入，不放镜像。
不能就地改造，或者说，就地改造等于没做。你可以把它上面的改动梳理清楚、写成 provisioner、用同一份脚本构建出一张镜像，看起来环境是一致的——但没人能证明这台机器上没有别的历史遗留。这也是为什么黄金镜像的价值里有一半来自「重建」这个动作本身：只有真的从零重建一台，你才知道生产的那个环境是不是可复现的。实操建议按风险排序，先换无状态边缘服务，再动核心无状态服务，有状态的服务排在末尾，并且每一批都要给出替换时间表。这里面「机器多久能到位」会直接影响新旧共存的时长，选交付快的供应商能把这段风险窗口压短。
脚本大体能共用，产物一定不能共用。provisioner 里绝大多数步骤——装包、写配置、设权限——两边是通用的，可以用变量区分源路径与包名差异后同一份维护。但二进制产物必须分别产出，因为指令集不同；构建机也要对应架构，用模拟层跑异构构建只适合小而低频的情况，速度差距很大。版本号一定要带架构后缀，否则运维说「回滚到某某版本」的时候很容易拿错，而拉错架构的结果是机器直接起不来。多区域同理，中心构建加复制，还是每区域各自构建，取决于你的区域数量和发布频率。
回到标题那个问题：这道工序该前置到哪一步。我的答案是，前置到「第一台机器被交付到你手上之前」，也就是把「装环境」从交付之后挪到交付之前。不要等到有了三十台机器、出了三次诡异故障之后再补。
而它真正兑现的价值，多数人一开始就估错了方向。装机省下的那点时间——几分钟或者几十分钟——实在不值得为此搭一条流水线。真正被省下来的是排查时间：那种「同样一份代码，这台能跑那台不能跑」，需要逐项 diff 几十个环境维度、耗掉一两个人天的排查。镜像体系把差异从 N 台机器之间的两两关系，压成一条线性的版本链，diff 的对象从几十项降到一个版本号。这个降维才是它的核心收益。
如果你的团队还没有出现过环境漂移导致的故障，先别急着做整套流水线，把基础镜像那一层统一掉就够了，投入两三天能看到效果。如果你已经有过一次「两台机器差在一个内核模块版本上」的经历，那就别再犹豫——从无状态服务开始试点，同时把版本规范和旧机替换计划一起定下来。补丁我们可以慢慢打，一致性得先立起来。
本文关于不可变基础设施、构建期与运行期分工、版本与回滚粒度的讨论，属于工程方法论层面的通行实践；关于构建机 CPU 分钟数、内存占用、临时盘峰值、单次拉取包体积的具体量级，为常见中等复杂度镜像的经验区间，不同业务的实际值应当以自身构建日志实测量为准，本文不引用任何虚构的测试数据或跑分。
硬件与价格口径方面：一万网络相关产品的公开起步参考为华南 ¥799 起、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起，均需以官网实时报价为准；镜像仓库的额外存储、跨区域复制流量、批量开机的带宽峰值等项公开渠道差异较大，统一按需询价处理，本文不给出确定报价。品牌与资质信息据公开资料：一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部、自营机柜，资质含增值电信业务经营许可证、国家高新技术企业、专精特新中小企业，服务项含 7×24 中文工单、平均 5 分钟响应、硬件故障自动迁移、免费系统盘每日三份快照、免费备案协助、5–20G 免费防护、BGP 多线与 CN2 GIA 优化线路。
适用边界也说清楚：本文面向的是十几到几十台云主机或裸金属、当前依赖手工脚本交付的团队；机器数量在一两台、或者已经完整落地容器编排与声明式交付的团队，这套方法的边际收益会明显下降。涉及网络线路的实际延迟与带宽表现，需按运营商与机房实测确认，本文不作保证性描述。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
