单机 Docker 蓝绿发布

单机发布的中断痛点与零停机诉求

当单机服务器运行 Docker Compose 与 Nginx 时，传统发布往往通过重建或重启唯一的应用容器完成，这会导致用户请求中断。对于资源有限但希望降低发布风险的团队，既需要候选版本验证、原子切流和自动回滚能力，又不引入 Kubernetes 的复杂度。若数据库迁移或共享状态处理不当，即便应用层切换成功，仍可能出现数据不一致或任务重复消费。

最小拓扑与发布闭环设计

技能通过两个应用槽位 app_blue 与 app_green、一个活动上游及状态文件（active、candidate、previous）构建最小可控发布闭环。核心流程包括：

• 前置条件评估：验证 CPU、内存、磁盘、端口、会话存储、后台任务等资源，确保能同时运行两个实例。
• 发布契约与健康检查：明确进程存活、依赖就绪、关键查询和版本号等检查项，避免用首页 200 替代全部健康状态。
• 数据库迁移审查：采用 expand/contract 模式，先扩展兼容结构，再部署兼容版本应用，最后清理旧结构，不可逆迁移需备份和独立回滚方案。
• 共享状态处理：统一认证密钥、上传存储和缓存，通过 leader、队列或开关防止后台任务双实例重复消费。
• Stage/Promote/Rollback 三段式操作：在非活动端口启动候选版本并验证，原子切流后持续探测关键路由，仅在成功后写入更新通知，失败则回滚到上一状态。

适用边界与风险提示

该方案不适用于服务器资源不足以同时运行两个实例的场景，此时应选择滚动重启、短维护窗或扩容。需明确单机蓝绿发布并非机器级高可用方案，主机故障仍会导致服务中断。数据库不兼容时，应用回滚不等于完整回滚，需额外验证数据一致性。更新通知仅在 Promote 成功后触发，避免过早暴露未稳定的候选版本。