不可变基础设施与发布
服务器不原地打补丁，而是整体替换：镜像或虚机模板作为制品构建、版本化；发布=替换实例，回滚=用上一版制品重新拉起。好处是环境与制品一一对应、漂移消失；代价是对构建、配置注入与替换流程的工程化要求更高：构建、镜像仓库、编排与回滚链路都要成体系。
基本信息
| 原则 | 改动产生新制品，不修改运行中的实例 |
|---|---|
| 制品 | 容器镜像、虚机模板等版本化产物 |
| 发布 | 新实例替换旧实例 |
| 回滚 | 重新部署上一版本制品 |
| 配置 | 环境差异走配置与密钥注入，制品保持同一份 |
典型使用场景
- 容器化部署：镜像即制品
- 虚机镜像流水线：定期烘焙新模板
- 批量替换升级：滚动替换整体版本
- 快速回滚：换回旧制品即可
- 消除漂移：不再登机器改配置
- 合规审计：每个实例对应可查的制品版本，审计时直接引用
替换式发布
替换式发布
docker build -t registry.example.com/app:1.9.0 . # 制品带版本
docker push registry.example.com/app:1.9.0
kubectl set image deployment/app app=registry.example.com/app:1.9.0
# 回滚：把镜像指回上一版本制品
kubectl rollout undo deployment/app与原地修改对比
| 维度 | 不可变 | 原地修改 |
|---|---|---|
| 变更方式 | 替换实例 | 登入改配置、就地升级 |
| 漂移 | 基本消除 | 随时间积累 |
| 回滚 | 换制品 | 手工回退难 |
与配置注入配合：环境差异走配置与密钥，制品本身保持同一份。
旧实例别留恋：确认流量切走、观察期过后再销毁，保留窗口覆盖回滚需求。
制品也要清理：旧镜像与旧模板按保留策略回收，别让仓库无限膨胀。
渐进采用：先容器化、再替换虚机，不必一步到位；关键是「改动不落到运行实例」。
环境晋级同一制品：同一版本依次经预发到生产，晋级只改引用不重构建；标签用语义化版本或提交号，禁止 :latest 上线，否则回滚时找不到确切内容。