Docker-Rollout项目中的容器残留问题分析与解决方案

问题现象描述

在使用Docker-Rollout进行容器部署时，用户反馈在部署过程中会出现容器残留的问题。具体表现为：当执行部署脚本连续构建并滚动更新多个服务（如dashboard、api、website）后，系统中会遗留一些旧版本的容器实例，这些容器仍然保持运行状态。

从用户提供的容器列表可以看到，同一个服务（如api）存在多个不同编号的容器实例同时运行，这显然不是预期的部署结果。正常情况下，Docker-Rollout应该在启动新版本容器后自动停止并移除旧版本容器。

问题根源分析

经过技术分析，这个问题主要由两个因素导致：

1. 容器重启策略配置不当：用户在docker-compose文件中配置了restart: always策略，这意味着当容器被停止时，Docker守护进程会自动重新启动它们。而Docker-Rollout在执行滚动更新时，会先尝试停止旧容器，但由于重启策略的存在，这些容器又被自动重新启动了。

2. 部署过程中断：另一种情况是用户在滚动更新过程中手动中断了部署流程（如使用Ctrl+C），这会导致Docker-Rollout无法完成完整的清理流程，从而留下部分中间状态的容器。

解决方案

针对上述问题根源，建议采取以下解决方案：

1. 修改容器重启策略：将docker-compose文件中的restart: always改为restart: unless-stopped。这种策略同样能保证容器在异常退出时自动重启，但允许用户或脚本通过docker stop命令正常停止容器而不会触发自动重启。

2. 确保部署流程完整执行：避免在Docker-Rollout执行过程中手动中断部署流程。如果需要终止部署，建议先让当前服务的滚动更新完成，或者手动清理残留容器后再重新部署。

3. 定期清理策略：可以设置定期任务检查并清理残留容器，使用命令如docker container prune来移除所有已停止的容器。

技术原理深入

Docker-Rollout的工作原理是通过创建新版本容器并验证其健康状态后，再停止旧版本容器。这个过程依赖于Docker的正常生命周期管理。当容器配置了always重启策略时，会干扰这个生命周期管理：

• Docker-Rollout停止旧容器 → Docker检测到容器停止 → 根据策略重新启动容器

而unless-stopped策略则更加智能，它能区分正常停止和异常退出的情况，只在非正常退出时自动重启容器。

最佳实践建议

1. 对于生产环境部署，建议使用restart: unless-stopped而非always策略
2. 部署脚本应考虑加入错误处理和回滚机制
3. 在CI/CD流程中，可以添加部署后检查步骤，验证是否有残留容器
4. 对于关键服务，建议在部署前备份当前运行状态

总结

Docker-Rollout作为一个轻量级的部署工具，设计上追求简单高效。理解其工作原理并合理配置容器策略，能够有效避免部署过程中的容器残留问题。通过调整重启策略和保证部署流程完整性，用户可以充分利用Docker-Rollout的优势，实现平滑的容器化应用部署。