零停机发布关键在于精确控制容器生命周期：采用start-first顺序确保新容器就绪后再停旧容器，结合健康检查定义真正可用状态，并通过冗余副本与渐进式替换保障服务连续。

利用 docker 容器生命周期实现零停机发布，关键在于让新旧容器在状态转换过程中不出现服务空档。核心不是“快停快启”，而是精确控制容器从启动、就绪、接收流量到优雅终止的全过程，使负载均衡器只把请求分发给真正可用的实例。

用好 start-first 启动顺序

这是滚动更新中避免中断的第一道防线。配置 order: start-first 后，编排系统会先拉起新容器并等待其通过健康检查，再停止对应的旧容器。整个过程旧容器持续处理已有连接，新容器逐步承接新请求。

• 在 docker-compose.yml 中明确声明：order: start-first
• 配合 parallelism: 1 和 delay: 10s，可控制每次只替换一个副本，留足验证时间
• 若省略此配置，默认是 stop-first，即先停旧再启新，极易造成短暂断连

靠健康检查定义“真正就绪”

容器进入 running 状态 ≠ 能处理业务请求。必须通过 HEALTHCHECK 指令告诉系统：什么时候才算准备好接流量。

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 在 Dockerfile 中添加：HEALTHCHECK --interval=30s --timeout=3s --start-period=15s --retries=3 CMD curl -f http://localhost:8080/health || exit 1
• start-period 给应用冷启动留出缓冲时间，避免刚启动就被判失败
• 只有健康检查连续通过，编排平台才会将该容器加入服务发现列表，流量才开始流入

让旧容器“优雅退出”而非强制 kill

零停机不仅要看新容器是否上来，更要看旧容器是否干净收尾。直接终止会导致正在处理的请求被中断或响应不全。

• 应用需监听 SIGTERM 信号，在收到后停止接受新连接，等待已有请求完成（如 HTTP server 的 graceful shutdown）
• Docker Compose 默认给予 10 秒终止宽限期，可通过 stop_grace_period: 30s 延长
• 配合反向代理（如 Nginx）或服务网格（如 Istio），可主动摘除上游节点，再触发容器停止

依赖冗余与渐进式替换

单实例永远做不到零停机。必须保证任何时候都有足够副本在线服务，才能腾出空间做更新。

• 至少部署 2 个及以上副本（replicas: 3 更稳妥），确保更新期间总有实例可用
• 用 maxUnavailable: 1（K8s）或 parallelism: 1（Compose）限制同时下线数量
• 更新不是“全量切换”，而是逐个实例滚动，每个环节都受健康检查和启动顺序约束