docker 容器部署时 run 与 create 的使用及其存在的一些问题

背景描述

容器化场景中，业务能力封装为多个容器，需要在系统安装部署阶段导入这些容器镜像并部署运行。使用 docker run 方式部署完容器就重启，出现部分容器服务异常问题。

部署容器涉及的部分数据库中间件

pg、nginx、业务容器

docker run 部署容器方法及其存在的问题

1. 打包阶段将容器镜像打包到安装文件中
2. docker load 加载容器镜像
3. docker run 依次部署所有的容器
4. reboot 系统
5. 系统重启后容器被启动服务拉起

将容器分为两类：

1. 首次部署需要生成持久化数据的容器
2. 首次部署不需要生成持久化数据的容器

如何判断部署是否成功？

1. 对于不需要生成持久化数据的容器，docker run 返回即表示成功
2. 对于需要生成持久化数据的容器，持久化数据生成完成后表示部署成功

存在的问题：docker run 返回完成并不表示容器内持久化数据生成完成，持久化数据的生成也是部署的一部分，需要增加判断逻辑

示例逻辑：pg 数据库持久化，在 docker run 部署 pg 后可以持续调用容器内 pg_isready -q 命令检测是否就绪

统一逻辑：约束需要生成持久化数据的容器支持健康检查，部署后持续检查直到容器状态健康

docker create 部署方式及其存在的问题

1. 打包阶段将容器镜像打包到安装文件中
2. docker load 加载容器镜像
3. docker create 依次创建所有的容器
4. reboot 系统
5. 系统重启后容器按照依赖逐个 start

存在的问题：系统安装好第一次重启可能需要很长时间，在这个时间内需要编写逐个 start 容器的启动代码，并检测需要做数据持久化的容器是否成功，最后需要在容器都运行起来后移除逐次 start 的启动过程，再次重启就按照容器依赖启动

进一步的思考

也并非需要数据持久化的容器才需要考虑本文中描述的问题，实际上只要 docker run 命令返回不能表示容器部署完成，就会存在相同的问题。

反思下，设计阶段在场景上仅仅考虑了部署容器这个动作，但是对这个动作对系统做的改变以及对部署成功的反馈并未考虑。