5.1 多环境部署：从试验台到生产线
5.1 多环境部署：从试验台到生产线
本节摘要：生产部署的核心不是「装得多么高级」，而是环境有序：开发、试验、生产三环境各司其职，配置与插件按工序流动，数据库与附件三件套按策略备份并可恢复。本节给出拓扑设计、迁移工序与备份演练的完整做法。
2.1 装的那台实例是试验台，可以随便拆。但从今天起要服务的同事不会原谅「重启一下试试」。生产部署的第一课，是承认样机与设备的区别，然后给设备建一套环境秩序。
一、三环境拓扑：各自负责什么
开发环境是车间：装插件、改配置、大胆试错，坏了就重建。试验环境是验收台：结构与生产一致，任何要上生产的东西先在这里过一遍——升级、新插件、批量配置改动。生产环境是现场：只接收经过试验环境验证的变更，日常只做两件事，运行与备份。
三环境之间的流动物只有三种：配置导出包（页面、区块、角色等元数据）、插件包（4.2 的六站产物）、以及随发布流程走的数据结构变更。不流动的东西同样要明确：生产的真实数据永不回流到开发（要调试用脱敏副本），开发的半成品永不直连生产。
图 5-1 生产部署拓扑：一台反向代理带路
二、迁移工序：配置怎么从试验台到现场
三环境立起来后，高频动作是把试验环境里调好的配置搬到生产。搬的是配置导出包，不是数据库备份——数据库里混着真实数据，配置包里只有结构化的元数据。工序四步：
配置发布四步（试验环境 → 生产环境）： 1. 试验环境：配置变更完成、自测通过后，做配置导出 （界面操作：设置 → 应用 → 导出，产出单个配置包文件） 2. 发布记录：包文件命名带日期与变更摘要，连同说明归档 3. 生产环境：选择业务低峰，先做一次当日的例行备份 4. 导入配置包 → 冒烟验证（登录、核心页面、一条流程） 异常则回退：恢复导入前的备份，分析原因后重来
插件发布同走此工序，只是第 1 步换成在试验环境安装并验证插件包。把这套工序写进团队手册，坚持三个月，它会从束缚变成安全感——每一次发布你都知道怎么退回去。
三、备份三件套与恢复演练
备份清单在 2.1 埋过伏笔，这里收口成三件套：数据库定时全量备份、附件存储目录同步、配置导出包归档。三者缺一不可——只备数据库，附件丢了表格里全是死链；只备附件，配置记录丢了页面打回原形。存放位置必须离开本机：另一台机器或对象存储都行，同一个机柜断电时本机备份帮不了你。
节奏建议：数据库每日全量、保留四周滚动；附件每日增量同步；配置包按发布节奏归档，与发布记录一一对应。比节奏更重要的一条铁律写在图 5-1 里：没演练过恢复的备份等于没有备份。演练的做法很朴素——在试验环境拿最近的备份完整恢复一次，核对数据、附件、配置三样都活着。每季度一次，恢复手册的存在感就是在这时候建立的。
⚠️ 常见坑：把生产实例的容器当成持久物。有人在生产容器里手动装了依赖、改了配置文件，容器一重建全部蒸发。生产实例上的任何变更要么走环境变量与编排文件，要么走平台界面，绕开这两条路的改动都活不过下一次重建。
💡 关键直觉：多环境的价值不在「显得专业」，在于让每一次变更都有预演场地、每一次失败都有退路。两台便宜机器加一套工序，比一台昂贵机器省下的都是事故。
备份与恢复：可直接照抄的命令序列
三件套的备份动作落成命令，按日执行。数据库全量与附件同步是两根柱子：
# 数据库全量备份（容器化部署，crontab 每日凌晨执行） docker exec <数据库容器名> pg_dump -U nocobase nocobase | gzip > /backup/nocobase-$(date +%F).sql.gz # 校验：文件大小与前一日相当即视为正常，骤减要查 # 附件目录同步（rsync 到另一台机器） rsync -a --delete /data/storage/ 备份机:/backup/storage/ # 配置导出包：发布日手动导出后拷入 /backup/config/，随发布记录归档 # 保留策略：滚动清理四周前的数据库备份 find /backup -name "nocobase-*.sql.gz" -mtime +28 -delete
备份写完，恢复演练的命令同样要备在手边——没练过的备份等于没备份：
# 恢复演练（在试验环境执行，每季度一次） docker exec -i <试验库容器> psql -U nocobase nocobase < 解压后的备份.sql # 恢复后核对三样：数据表可查、附件在位、登录可用 # 演练记录归档：日期、备份文件、耗时、发现问题
装机记录的一页纸模板
5.1 提过装机记录，把它落成一页纸模板，新装机三十分钟内填完：
装机记录（一页纸，装完即填，入团队知识库）： 实例名与用途：____________ 装机日期：____ 机器与规格：____ 部署方式：容器或源码 镜像与版本：____________ 编排文件仓库地址：____ 环境变量清单：见附录（密钥只记存放位置不记值） 数据库与备份：库实例____ 备份位置____ 节奏____ 附件目录：____________ 配置包归档：____ 管理员账号存放：____________ 值守人：____ 已装插件：____ 特殊改动：无则写无
这页纸的真正价值在交接与救火两个时刻。交接时，接手人靠它三十分钟建立全貌；救火时，「环境变量有没有改过」「插件什么时候装的」这类问题不用考古，翻纸即答。每个实例一页，连同备份演练记录、升级台账，构成运维的三份基本档案——都不厚，但都是保命的。
环境漂移：三环境的隐形敌人
三环境跑久了会得一种慢性病：漂移——环境之间的配置悄悄不一致，试验环境装了个插件生产没有，生产改了个环境变量试验没跟。漂移的破坏力在用的时候才爆发：试验环境验证通过的升级，上了生产行为不一样，排查半天发现是环境差异。治理漂移的思路是「让差异可见」：每月跑一次环境比对，核对三样——插件清单与版本、环境变量（比对键名与是否非空，不比密钥值）、已启用的功能开关。
月度环境比对（三环境两两对，十五分钟）： □ 插件清单一致（版本差异即记录） □ 环境变量键名集合一致 □ 功能开关与启用状态一致 发现漂移：判定哪边是标准 → 补齐 → 记入当月运维日志
装配要点回顾
- 三环境分工：开发试错、试验验收、生产只收验证过的变更；
- 流动三物：配置包、插件包、结构变更，数据永不逆流、半成品不直连生产；
- 发布四步：导出、记录、低峰备份、导入加冒烟，异常回退重来；
- 备份三件套：数据库、附件、配置包，存放出楼，每季恢复演练；
- 下一站：5.2 给这套环境装上仪表盘，值班从盲巡变成看表。