设置restart: always后执行docker-compose pull，服务重启将用新/旧镜像？

核心疑问：pull后崩溃重启用新镜像还是旧镜像？ #

执行docker-compose pull拉取新镜像后，如果现有服务崩溃触发restart: always重启，会继续使用旧镜像。

原因很直接：Docker容器是绑定到具体的镜像ID运行的，而非镜像标签（比如latest）。pull操作只是更新了本地标签指向的镜像ID，但已经运行的容器依然关联着创建时的旧镜像ID。只有重新执行docker-compose up -d（或手动重建容器）时，才会基于新的镜像ID创建并启动新容器。

多主机部署流程优化建议 #

你想用Ansible批量同步操作的思路没问题，这里给你两个实操方案：

方案一：缩短暂停窗口（推荐） #

1. 用Ansible并行执行docker-compose pull，确保所有主机拉取完最新镜像。Ansible默认支持并行任务，可通过调整forks参数提升并发数，加快全主机的pull速度。
2. 待所有主机pull完成后，立即用Ansible批量执行docker-compose up -d。这个命令会自动检测镜像更新：如果本地镜像标签对应的ID已更新，就会销毁旧容器、创建并启动新容器，同时保留restart: always策略。

这种方案操作简单，pull到up的时间窗口极短，服务在此期间崩溃的概率极低，基本可忽略。

方案二：完全规避窗口风险（适合高可用性场景） #

如果必须消除pull后到up前的任何重启风险，可以临时调整重启策略：

1. 用Ansible批量执行docker-compose update --restart-policy=no，临时将服务重启策略改为no。
2. 批量执行docker-compose pull拉取最新镜像。
3. 批量执行docker-compose up -d，重新创建容器（此时会使用新镜像，且重启策略会恢复为compose.yml中配置的always）。

注意：这个方案在调整重启策略到up完成的时段内，若服务崩溃不会自动重启，需根据业务可用性要求权衡是否采用。

内容的提问来源于stack exchange，提问作者spiroski