RHEL母盘制作全流程：从环境标准化到批量克隆部署

说个真事。前年有个项目要交付三十来台服务器，甲方要求所有机器系统环境一致、软件版本一致、安全基线一致。一开始我们老老实实一台台装RHEL，装到第八台的时候我意识到一个问题：再这么装下去不仅手要废，而且每台机器之间必然会产生细微差异——某个包版本高了一点、某处配置手滑改错、安全补丁漏了那么一两个。后来我们花了两天时间做了一台标准母盘，剩下的二十多台机器全部从母盘克隆部署，每台用时不到一首歌的功夫，而且环境几乎完全一致。这篇文章就把这套RHEL母盘制作流程掰开揉碎讲清楚，从为什么做、怎么做、到克隆之后那些看不见的坑，全部摊开给你看。

我做母盘不是第一次了。踩过的坑、翻过的车、复盘过的教训，加起来应该够写个小册子。如果你正准备批量交付Linux环境，或者你所在的团队还在用“人肉装机”的方式处理重复性工作，这篇文章应该能帮你省下不少熬夜时间。

1. 为什么要做母盘？批量交付环境一致性的破局点

1.1 一台台装系统的真实成本：三十台机器的教训

先算一笔账，装一台RHEL系统，如果带图形界面手动装，熟练工也要四十分钟到一个小时，包括分区、选包、设密码、等待安装完成。这个工作放到三十台机器上，就是整整一两天的高强度重复劳动。人不是机器，一旦开始机械操作，失误率会指数级上升。

我复盘过那次的三十台机器交付，发现了很多典型问题：

• 某台机器忘了装lsof，排查问题的时候发现工具没带上
• 某台机器的/etc/hosts里残留了上一个环境的解析记录
• 两台机器的SSH主机密钥一模一样，后续连错机器被安全扫描直接报警
• 补丁版本不齐，有几台落后了两三个安全更新

这些问题单看都不严重，但合在一起就变成了交付质量的硬伤。母盘的价值就在于：它把环境一致性问题从“每台机器都要靠人来保证”变成了“只要母盘没问题，克隆出来的机器就都没问题”。

1.2 母盘、自动安装、容器镜像：三个概念别搞混

很多人容易把母盘和另两个概念混淆，我先把这层窗户纸捅破。

母盘（黄金镜像/Golden Image）是一台经过标准化配置、清理了本机身份信息的完整操作系统副本，用于批量克隆部署。它的核心特征是“已经安装并配置好，拿过来就能跑”。

KickStart/PXE自动安装则是一套从零开始的自动化装机系统。它给你一份配置脚本，按脚本自动完成分区、装包、设密码等动作。它生产的是“一台新机器”，而不是“一台标准机器的复制品”。

容器基础镜像更轻量，它只包含应用运行所需的依赖环境，没有完整的系统服务，也没有systemd作为初始化进程。它解决的是“应用跑起来的环境一致性”，而母盘解决的是“整台服务器系统环境的一致性”。

三者各有各的用途。我做母盘，解决的是物理机或虚拟机的批量交付场景；自动安装则适合不挑硬件、每台都要独立安装的场景；容器镜像是应用层的，不在这里展开。

1.3 不适合做母盘的场景：别把模板用过头

母盘很好用，但它不是万能的。我见过几个把母盘用砸的案例，都是因为场景不匹配。

第一种是硬件差异巨大的环境。母盘通常在特定硬件或虚拟化平台上制作。如果目标机器有的是UEFI启动、有的是Legacy BIOS，有的用NVMe硬盘、有的还是SAS盘，一份母盘很难全部兼容。虽然可以通过改进驱动包解决一部分问题，但复杂度会上升很多。

第二种是少量机器场景。如果只要装三五台，做母盘的准备工作和调试时间可能比手动装还长。要控制成本，先估算一下你要装多少台。

第三种是安全合规要求很严格的场景。有些等保环境要求每台机器安装过程可审计、可追溯，系统安装记录必须完整。这种情况下，逐台安装加统一配置脚本更合适。

我的经验判断标准很简单：需要一致部署的机器数量超过十台，或者交付环境后续还要批量扩容，就值得做母盘。否则，先缓缓。

2. 制作前的规划：版本选择、分区设计与软件包取舍

2.1 RHEL版本怎么定：存量6.9与新装8/9的思路差异

搜索热度里挂着“rhel 6.9”这个词，我推测还有不少朋友在维护老版本RHEL。先给个结论：新环境不建议再装6.x，RHEL 6已停止维护多年，安全补丁断供，合规上很难过关。如果你是因为存量业务绑定在6.9上，那做母盘时得注意几件事：

• 6.x使用旧的udev和network脚本机制，网卡清理方式跟7/8/9差异很大，不能照抄新版操作
• 6.x默认文件系统是ext4，后续如果要做大分区，提前规划好LVM
• 6.x的Python和GCC版本很老，装现代运维工具（比如Ansible、Cloud-init新版）会碰壁

新环境我的建议是RHEL 8或9，理由有两点：一是RHEL 8以后用NetworkManager管理网络，克隆时的网卡配置容错性更强；二是8/9自带的系统角色、Cockpit管理工具和Cloud-init生态更成熟，配合母盘自动化非常顺。

如果你所在单位用的是国产Linux发行版（基于RHEL衍生或兼容的），母盘制作的思路几乎可以原样平移。核心手法都一样：装好、配好、清理身份标识、重新打包。

2.2 分区方案：让LVM成为母盘的缓冲垫

分区是母盘里最不能将就的部分。我踩过的最大坑就是在母盘上用了普通分区，没有建LVM。后来要扩容时发现/分区已经用满，只能重新装系统。

LVM（逻辑卷管理器）相当于给磁盘分区加了一层“动态缓冲垫”。它把物理磁盘先组合成卷组（VG），再从卷组里切逻辑卷（LV）给系统用。后续哪块空间不够，只要卷组里有空闲空间，就能在线扩容。

母盘分区我建议这么设计：

用LVM还有一个好处：克隆部署时，如果目标磁盘比母盘大，可以在首次启动时通过脚本调整LV大小。这个灵活度在批量交付时太宝贵了，后文我会给具体做法。

2.3 软件包取舍：最小化是美德，但别让后续工作抓狂

装什么软件包进母盘，是个平衡题。装太多，镜像体积膨胀、攻击面增大；装太少，克隆出来的机器缺工具，业务部署时还要临时补包。

我的建议是拿最小化安装做底子，然后补上运维刚需包。RHEL 8/9里最小化安装只带最基础的工具，我在这个基础上会补装这些组：

bash复制dnf install -y vim tar rsync lsof net-tools wget curl unzip \
                bind-utils sysstat iotop iftop htop psmisc \
                lvm2 device-mapper-persistent-data \
                cloud-init cloud-utils-growpart \
                yum-utils

cloud-init和cloud-utils-growpart这两组我特意强调。前几年做母盘时我漏装了它们，导致克隆到云平台或虚拟化平台后无法自动设置主机名、无法自动扩分区，后来又返工。如果你打算在OpenStack、VMware或者公有云场景用母盘，这两组必须带。

至于图形界面，能不装就不装。服务器装GUI不仅浪费资源，还引入大量没必要的依赖。实在有桌面需求的机器，单独装都来得及。

2.4 环境登记表：母盘交付的基本功

这是我从一次交付事故里学到的教训。有次我们交付了十几台机器，三个月后客户问“这些机器的系统版本和补丁记录有没有文档”，当场问住了。

从那以后，我制作母盘时始终坚持维护一张环境登记表，内容包括：

• 母盘版本号、制作日期、制作人
• 基础系统版本（例如RHEL 8.10）、内核版本
• 已安装的补丁清单和最后更新日期
• 预装软件清单及版本
• 分区方案、swap大小、SELinux状态
• 已知问题和定制项（例如关闭了某个不必要的服务）

这张表不光是给客户看的，更是给未来接手的人看的。母盘迭代到第三版时，如果没有登记表，你根本说不清每版之间改了什么。我不止一次靠这张表快速定位“这个版本为什么和上一个版本行为不一样”的问题。

3. 制作完整流程：从基础安装到封盘打包的每一步

3.1 基础安装：手动装一次，剩下的交给KickStart

首次制作母盘，我建议老老实实手动安装一遍。为什么？因为手动安装能让你完整走一遍流程，看清每个环节的选项和后果。等母盘逻辑验证稳定了，再把这套手动过程固化成KickStart配置文件，未来重建母盘就是一条命令的事。

手动安装时有几个细节直接决定母盘成败：

• 安装语言和键盘建议选en_US.UTF-8，避免后续中文编码问题
• 时区必须选对，我一般设Asia/Shanghai，后续通过NTP自动同步
• 安全策略建议先按基线设置（详见3.2节），千万别选“没有安全策略”，否则克隆出来的机器SELinux状态会出偏差
• Root密码只用于首次登录，后续统一用钥匙认证或托管账号

装完以后先别急着做任何操作，重启进入一个干净的系统状态，再进行下一步——因为安装器留下的环境是“未配置”的原始状态，最合适作为母盘的起点。

3.2 补丁固化和基线配置：让母盘一出生就是合规状态

母盘最大的优势之一，就是可以让所有克隆机上线即达到合规状态，而不是等机器跑起来再一台台打补丁。所以，在制作母盘的过程中，这一步不能省。

bash复制dnf update -y
dnf install -y vim tar rsync lsof net-tools wget curl unzip \
                bind-utils sysstat iotop iftop htop psmisc \
                lvm2 device-mapper-persistent-data \
                cloud-init cloud-utils-growpart \
                yum-utils
dnf clean all

补丁打完，接着做几个基础配置：

1. 关闭或配置SELinux（推荐保持enforcing，但要在重打包前触发重打标签，详见4.2节）
2. 配置NTP时间同步，指向内网或公网时间源
3. 配置/etc/resolv.conf和内部DNS地址，这样克隆出去的机器一开始就能解析域名
4. 设置limits.conf、内核参数（比如vm.swappiness）等基线配置
5. 创建统一的sudo账号，并配置SSH公钥认证

这里有个我犯过的错误：为了省事在母盘里把SELinux直接禁用了。后来安全扫描不过关，又紧急写脚本批量改回来。重打SELinux标签在这条路上绕了个大弯。建议从源头就把SELinux保持开启，它本身不影响系统运行性能，只是要求你学会用audit2allow处理偶尔的权限拦截。

3.3 清理第一弹：网络标识、SSH密钥与机器身份

做完配置，母盘还不能直接打包。因为这台母盘已经带了独一无二的“身份信息”，如果不擦除干净，克隆出来的每台机器都会共享同一套身份，连到同一网络时直接出问题。

这个身份包括三类东西：

第一类是网络标识。现代RHEL用NetworkManager管理网络，它会在/etc/sysconfig/network-scripts/ifcfg-*里写入网卡的MAC和UUID。克隆时目标机器网卡MAC通常不同，旧配置会导致网卡无法正常启用。

bash复制# 清理NetworkManager连接配置中的MAC和UUID绑定
sed -i '/^UUID=/d;/^HWADDR=/d' /etc/sysconfig/network-scripts/ifcfg-*
rm -rf /etc/NetworkManager/system-connections/

第二类是SSH主机密钥。/etc/ssh/ssh_host_*是这台机器首次启动SSH服务时生成的。如果母盘里带着它，所有克隆机的密钥都相同，安全扫描直接报高危。

bash复制rm -f /etc/ssh/ssh_host_*

第三类是机器标识。现代systemd会在/etc/machine-id里写入一个全局唯一ID。所有克隆机带着相同ID启动，虽然一般业务觉察不到，但日志分析、systemd关联和部分集群软件会把它当作错误来源。

bash复制rm -f /etc/machine-id

这三步做完，母盘才算在“身份层”上归零了。接下来清理用户痕迹。

3.4 清理第二弹：日志、历史记录与临时文件

机器身份清完之后，还要把母盘里留存的操作痕迹抹掉，让克隆出来的机器像“刚装完系统”一样干净。

bash复制# 清空root的历史命令
truncate -s 0 /root/.bash_history

# 清空所有用户的历史记录
find /home -type f -name '.*history' -exec truncate -s 0 {} \;

# 清理日志
find /var/log -type f -name '*.log' -exec truncate -s 0 {} \;
truncate -s 0 /var/log/wtmp
truncate -s 0 /var/log/btmp

# 清理临时目录
rm -rf /tmp/* /var/tmp/*

# 清理缓存
rm -rf /var/cache/dnf /root/.cache

有个细节值得注意：/var/log/journal目录里保存着systemd的持久日志，这里面的信息很细，包括启动记录、服务状态。建议直接清掉：

bash复制find /var/log/journal -type f -delete

我第一次做母盘时没清journal，克隆出来的机器日志里带着母盘制作期间的各种操作记录，被客户审计人员挑出来了，追问“为什么这台新机器里有另一个环境的日志”。这种细节看似微不足道，真出了事要解释半天。

3.5 封盘打包：tar、dd还是虚拟机模板？

环境清理完毕，最后一步是打包。根据目标部署环境不同，有三种主流方式：

我的通用做法：在虚拟化环境里做母盘时直接导出OVA或qcow2模板，这种方式最省事；如果是物理机场景，先做tar归档，再配合KickStart的%post脚本自动恢复。

需要说明的是，tar打包时要保留权限和ACL。初学者最容易在这步出问题：

bash复制tar --xattrs --acls --selinux -czvf rhel-master-base.tar.gz -C / .

注意--selinux参数，RHEL系统文件带有SELinux上下文，打包时丢失会导致恢复后的系统出现诡异问题——例如SSH启动失败、Nginx无法绑定端口，排查半天发现都是SELinux标签错位。我建议在tar打包时就保留，恢复时配合restorecon重打一遍。

4. 最容易翻车的隐藏状态：那些看不见的“环境残留”

4.1 machine-id与systemd随机种子：两个最隐蔽的坑

清理machine-id这事我上面提过，但为什么值得单独说？因为它的影响范围比很多人想象的大。

/etc/machine-id被systemd-journald用来标识日志来源，被systemd-networkd用来生成DHCP客户端标识，还可以被某些数据库软件用来生成实例ID。如果所有克隆机ID相同，可能出现两个问题：日志平台无法区分机器；DHCP服务器下发地址时可能给相同标识的客户端分到同一个IP。

清理方法很简单：把文件删掉即可。systemd会在首次启动时自动生成一个新的。

另一个隐蔽的坑是/var/lib/systemd/random-seed。systemd每次开机都会从这里读取随机种子来初始化/dev/urandom。如果母盘里带着它，克隆机重启后的随机序列就有迹可循，加密相关的服务（如SSH、TLS）的随机性会打折扣。做母盘时顺手删掉：

bash复制rm -f /var/lib/systemd/random-seed

这个文件比较容易被忽略，我自己也是在一次渗透测试演练后才注意到的——审计人员报告里提到了“随机种子复制”问题，我们连夜赶了个清理脚本推给所有已经交付的机器。

4.2 SELinux安全标签：重打标签是生死线

SELinux是RHEL安全体系的关键组件，它通过给每个文件打上安全上下文标签来控制访问。做母盘时如果处理不当，克隆出来的机器可能出现各种诡异故障。

原因在于：打包时文件带了母盘的SELinux标签，但克隆机首次启动时，如果直接按这些标签运行，一旦触发重标记或上下文不匹配，服务就起不来。最常见的症状是SSH服务启动失败，连系统都登不进去。

标准做法是创建空标记文件，让系统在首次启动时自动重打标签：

bash复制touch /.autorelabel

这个文件告诉SELinux在下次开机时对整个文件系统重新标记安全上下文。听起来简单，但有个实际体验问题：首次开机的重标记过程可能持续几分钟到十几分钟，视磁盘速度而定。期间你看到CPU飙高、系统卡顿都很正常，别以为是故障直接断电。

我建议在交付文档里明确标注这一点：“克隆机首次开机需等待自动重标记完成后再执行后续操作。”不然运维同事第一次做克隆部署时，看到系统长时间无响应，很可能以为是死机，直接强制重启。

4.3 网卡UUID、MAC地址绑定：克隆后起不了网的原因

如果你经历过“克隆出来的机器网卡起不来，报错说设备不存在”，大概率就是网卡配置里带了旧MAC地址的锅。

RHEL 8/9用NetworkManager管理连接时，每个连接配置文件里都有一个唯一UUID和对应的MAC地址。当连接被复制到新机器上，新网卡的MAC对不上，NetworkManager就会认为那块网卡不存在，导致网络无法自动激活。

清理思路我在3.3节给过命令，这里补充一个更彻底的方法：与其逐个删除字段，不如直接删除网卡配置文件，让系统在首次开机时通过DHCP自动创建新连接。

bash复制rm -f /etc/sysconfig/network-scripts/ifcfg-ens*
rm -rf /etc/NetworkManager/system-connections/*

这个方法有个前提：目标机器网络环境有DHCP，或者你会在首次启动后用其他方式（例如Cloud-init）配置静态IP。如果没有DHCP又没法自动配置，建议保留ifcfg文件但只删掉UUID=和HWADDR=两行——这样网络服务会用新的UUID和当前网卡MAC重新绑定连接。

这是我踩过的最深的一坑。当年第一版母盘克隆后，一半机器网络不可达，现场运维在机房折腾了大半天，最后才发现是ifcfg文件里的旧MAC惹的祸。那之后我干脆在模板脚本里强制删除旧的system-connections。

4.4 主机名与静态解析：别把“localhost”也复制走

还有一个容易忽略的是主机名配置。如果母盘里设置了固定主机名，克隆出来的机器都叫同一个名字；如果你干脆没设置，它们又都会叫localhost.localdomain。无论是哪种情况，在批量环境中都会造成识别混乱。

正确的做法是把主机名设置交给首次启动流程：

• 如果用Cloud-init，配置preserve_hostname: false，让它根据云平台metadata自动设置
• 如果纯手动环境，写一个首次启动脚本，根据用户输入或机器序号生成主机名并写入/etc/hostname
• 如果没这个条件，至少把母盘里的/etc/hostname清空或设为localhost，避免带一个固化名称出去

另外/etc/hosts里的静态解析也很关键。制作母盘时最好只保留本地回环条目，把其他静态记录全部删掉。否则克隆机连接系统后，可能解析到母盘上记录的旧地址。

5. 验证与迭代：确认母盘真的是“一键复活”的模板

5.1 首次克隆开机后的验证清单

母盘做完，第一件事就是克隆一台测试机，验证整个流程是否真的能“一键复活”。我这些年测试下来，验证清单已经固定成下面这几项，每一项都对应实际翻过车的场景：

1. 网络连通：机器能否拿到IP，能否解析域名，能否ping通网关
2. SSH登录：公钥认证是否正常，能否用管理账号登录（如果登录失败，优先怀疑SELinux标签或SSH密钥问题）
3. 主机名：是否是新生成的名称，而不是母盘里的旧名
4. 系统状态：systemctl status是否有大量failed服务，journalctl -p 3 -xb有没有异常报错
5. SELinux状态：getenforce返回的是不是Enforcing，ausearch -m AVC有没有新的拒绝记录
6. 磁盘分区：如果目标磁盘比母盘大，分区是否已自动扩展成功
7. 日志纯净度：/var/log/messages里有没有母盘制作期间的旧日志残留

我自己习惯把这套检查写成脚本，在克隆机首次启动后自动执行并输出报告脚本：

bash复制#!/bin/bash
# template_verify.sh - 首次启动验证脚本
echo "=== Hostname ==="
hostname
echo "=== SELinux ==="
getenforce
echo "=== Network ==="
ip -4 addr show | grep -E 'inet ' | grep -v '127.0.0.1'
echo "=== SSH Keys ==="
ls -l /etc/ssh/ssh_host_* 2>/dev/null | wc -l
echo "=== Failed Services ==="
systemctl --failed --no-legend | awk '{print $1}'
echo "=== Disk ==="
df -h / | tail -1

如果验证清单全部通过，这台母盘才算正式可用。

5.2 我复盘过三次的常见翻车点

第一次做母盘时我在SELinux重标记上栽了跟头。当时为了省时间跳过了/.autorelabel，结果克隆机上的SSH服务全部起不来，我只能通过虚拟化控制台进去手动执行restorecon -Rv /，那台机器折腾了快一个小时，教训极其深刻。

第二次栽在网卡标识上。前文已经提过，一半机器网络不可达，现场运维直接崩溃。从那以后，我清理ifcfg文件的动作就写进了标准流程。

第三次是机器ID重复。那次不算宕机级别的问题，但监控平台里所有机器被合并成了一条数据线，告警信息混在一起，排障时花费了大量时间。检查清单里加了一条cat /etc/machine-id是否唯一。

这三次翻车都有一个共同点：问题都不是当场暴露的，而是要等克隆机跑起来之后才逐步浮现。所以我的经验是，母盘验证永远不能只在母盘本机上验证，一定要克隆至少一台机器做全流程压测。

5.3 用配置脚本固化母盘版本，持续迭代

母盘不是一次性的。系统一打补丁、业务一加依赖、基线一调整，母盘就得跟着更新。我现在的做法是：每次更新母盘都先改配置脚本，再用脚本从零自动构建，而不是直接在旧母盘上改来改去。

我推荐的流程是：

1. 解包旧母盘，或使用KickStart自动安装一台新基准机
2. 修改脚本中需要变更的配置（比如新补丁、新包、新参数）
3. 在基准机上执行配置脚本
4. 按3.4节的清理手法处理干净
5. 重新打包、克隆验证、更新登记表
6. 如果验证通过，版本号递增并归档旧版本

这套流程里，配置脚本就是母盘的“源代码”，母盘打包产物反而只是编译结果。一旦你养成了脚本驱动的习惯，母盘迭代会非常顺滑——改一行配置，重新构建一次，整个流程半小时内完成。

6. 从母盘到规模化平台：PXE自动安装与容器基础镜像

6.1 把母盘思路搬进PXE+KickStart流水线

如果你觉得母盘只能解决“克隆部署”这一类场景，那就小了。母盘制作的收获，可以平移进PXE+KickStart自动安装体系。

PXE启动允许客户端机器从网络引导安装程序，KickStart文件则自动回答安装过程中的所有问题。把它们组合起来，就得到了一条从裸机到可用系统的自动化流水线。制作母盘时积累的配置经验——分区方案、包选择、SELinux策略、基线加固——全部可以写进KickStart文件：

bash复制# 一个精简的ks.cfg示例
lang en_US.UTF-8
keyboard us
timezone Asia/Shanghai --utc
rootpw --iscrypted $6$...
authselect --enablesssd --profile sudo
selinux --enforcing
firewall --enabled --service=ssh
services --enabled=sshd,chronyd
zerombr
clearpart --all --initlabel
part /boot --fstype="xfs" --size=1024
part pv.01 --size=1 --grow
volgroup rhel_auto pv.01
logvol / --fstype="xfs" --name=root --vgname=rhel_auto --size=40960
logvol swap --name=swap --vgname=rhel_auto --size=8192
%packages
@^minimal-environment
vim
tar
rsync
lsof
cloud-init
%end
%post
echo 'containerized setup' > /root/setup.done
%end

母盘适合与PXE配合的原因在于：PXE解决“从零安装”的问题，母盘解决“同构快速复制”的问题。两者结合，你既能优雅处理硬件差异（PXE按需定制），也能享受快速交付的红利（母盘秒级复制）。

6.2 容器基础镜像：同样逻辑，不同载体

容器基础镜像的制作思路和母盘可以说如出一辙——选一个干净的基础层，装上应用依赖，清理不必要文件，然后构建成一个不可变的模板。区别在于容器没有systemd、没有网卡绑定、没有SSH，身份标识的清理也简单得多。

我从做母盘的经验里悟出的一点：容器镜像同样需要“环境登记表”。很多团队用的基础镜像连版本号都不写，出了问题根本无法追溯。如果你把做母盘时那套记录习惯迁移到容器镜像维护上，运维事故的排查效率会提高一个量级。

如果你已经熟练掌握了RHEL母盘制作，其实你已经理解了“模板化环境交付”的精髓：不可变、可重复、可追溯。容器镜像是这个理念在应用层的延伸，转换成本很低。

6.3 版本与补丁的维护节奏

母盘做出来之后，版本和补丁的维护节奏是要提前想清楚的。

我一般这样定节奏：

• 每季度进行一次安全补丁刷新，更新母盘版本
• 每次内核大版本更新时，做一次完整克隆压测再推广
• 每次业务基线调整，同步更新配置脚本和登记表
• 旧版本母盘至少保留两个版本，方便回退

这里有个操作细节：不要在母盘正常运行的环境里做补丁和配置变更，如果你没有脚手架的隔离环境，宁可新建一台虚拟机重新构建，也不要直接改动“生产母盘”。曾经有一次我想省事，直接在正在使用的母盘模板机上测试新配置，结果配置没生效，还把基线打乱了，导致那一批新交付的机器全部需要重新返工。

如果你打算长期维护一套母盘体系，建议给它建一个独立的环境，比如一台专用虚拟机或一台隔离的物理机。打补丁、改配置、测试克隆机，都在这个隔离环境里做，母盘的生产版本始终保持稳定可发布的状态。

最后再分享一个我个人的习惯：做母盘前，先写清楚“这台母盘要服务谁”和“这台母盘不该包含什么”。这两个问题想清楚，整个制作过程的取舍都会变得非常清晰。做母盘不难，难的是把边界和细节想清楚再动手。