最近更新一个 Docker 服务时我遇到了一个问题。镜像拉取成功容器也重新启动了整个过程没有任何报错dockercompose pull appdockercompose restart app可打开页面一看显示的仍然是 V1。第一反应通常是镜像没拉下来Docker 缓存出了问题要不要再重启一次其实 Docker 什么都没有做错。问题在于pull与restart操作的不是同一个对象pull更新本地镜像restart重新启动已经存在的容器让服务使用新镜像需要根据新镜像重新创建容器。我们可以把这个过程想成一次舞台换景剧院已经把新版布景运到了后台但台前仍然搭着旧布景。此时把幕布拉上再拉开只会让原来的舞台重新开场不会自动把后台的新布景换上来。*新版布景已经到达后台但台前仍在使用旧布景——就像新镜像已经拉到本地旧容器却没有被替换。*一、先分清镜像和容器镜像Image是一份标准化的软件包包含运行程序需要的文件、依赖和默认配置。它有点像版本化的安装包但这个类比只用来帮助入门Docker 镜像还包含分层文件系统和启动元数据。容器Container是根据某份镜像创建出来的隔离实例。创建时Docker 会选定具体镜像并结合环境变量、端口、挂载和启动命令准备运行环境。两者最重要的区别是对象负责什么生命周期镜像提供程序、依赖和默认配置创建后内容不可原地修改容器保存根据镜像创建出的实例状态可以启动、停止、重启或删除停止的容器仍然是容器。docker ps只显示运行中的容器docker ps -a才会把已经停止的容器也列出来。同一份镜像可以创建多个彼此独立的容器删除一个容器不会删除镜像更新镜像也不会自动改造已经创建好的容器。pull之前已经创建重新创建远端镜像 V2本地镜像 V2本地镜像 V1旧容器仍绑定 V1新容器使用 V2二、pull更新镜像不替换容器执行dockerpull nginx:alpineDocker 会从远程仓库下载nginx:alpine当前指向的镜像并更新本地的标签引用。这里有一个容易混淆的细节镜像内容由 image ID 或 digest 标识创建后不可原地修改但nginx:alpine这样的 tag 可以重新指向另一份镜像。因此下次pull之后同一个 tag 可能已经指向 V2但旧容器仍然绑定着创建时的 V1。如果想亲眼确认可以比较两者# 容器创建时绑定的镜像 IDdockerinspect--format{{.Image}}web# 当前 tag 指向的镜像 IDdockerimage inspect--format{{.Id}}nginx:alpine两个 ID 不同说明新镜像已经到了旧容器却还没有被替换。Docker 不自动替换容器其实是一种稳定性保证。否则一次普通的pull就可能直接改变正在运行的线上服务。[!important]镜像变了只代表本地有了一个可用的新版本容器重建后才代表服务真正开始运行新版本。三、restart为什么不能完成升级dockerrestart webrestart会停止并重新启动同一个容器。容器没有换绑定的镜像没有换创建时确定的环境变量、端口映射和挂载定义也没有换。它只是让容器中的主进程重新运行一次。所以restart适合这些情况进程临时卡死服务出现一次性异常已挂载的配置文件发生变化而且程序会在启动时重新读取只是希望让同一个运行实例重新开始。它不适合用来应用新镜像、新环境变量或新端口映射。这些信息大多在容器创建时确定发生的变化只执行 restart通常需要拉取新镜像仍使用旧镜像recreate修改环境变量仍使用创建时的值recreate修改端口映射原映射不变recreate修改 Dockerfile 或构建内容旧镜像、旧容器都不变build 后 recreate修改已挂载的配置文件文件已变化但程序未必重读reload 或 restart四、reload、restart、recreate的区别这三个动作看起来相近改变的层级却完全不同。Reload让应用重新读取配置如果修改的是已经挂载进容器的配置文件并且应用本身支持热加载可以调用应用提供的 reload。例如 Nginx 可以重新读取部分配置。reload 是应用程序自己的能力不是 Docker 提供的一种通用容器状态。哪些配置能够热加载需要查看具体程序的说明。Restart重新启动同一个容器dockercompose restart app它不会采用新的镜像也不会应用 Compose 中新修改的环境变量、端口等创建期配置。Recreate创建替代容器recreate 会根据当前镜像和当前创建期配置创建一个新容器用它替换旧容器。这才是更新镜像、环境变量、端口或挂载定义后通常需要的动作。回到舞台restart 是落幕后重新开幕台上还是原来的雨夜布景recreate 则是先撤掉旧景换上后台准备好的晴日新景再重新开场。可以把判断方法压缩成三句话进程临时异常考虑 restart应用支持重新读取配置考虑 reload镜像或创建期配置变化就要 recreate。需要注意重建容器时旧容器的可写层不会保留。重要数据应放在 Volume、Bind Mount 或外部存储中。Volume 独立于容器可写层但它也不是备份docker compose down -v仍然可以删除命名卷。五、让 Compose 完成正确的更新闭环真实项目通常不只有一个容器还可能包含 API、数据库、Redis 和 Nginx。这时可以让 Compose 根据声明的配置协调实际运行状态。更新远端镜像服务时dockercompose pull appdockercompose up-dapppull明确拉取镜像up -d检查服务使用的镜像和配置。发现变化时Compose 会停止并重建对应容器同时保留已挂载的卷。它不会每次都无条件重建。也可以明确要求启动前拉取dockercompose up-d--pullalways app如果修改了 Dockerfile 或构建上下文dockercompose up-d--buildapp只有在明确希望无论是否检测到变化都替换容器时才需要dockercompose up-d--force-recreate app--force-recreate不是默认万能修复。大多数情况下普通的compose up -d会在检测到镜像或服务配置变化后完成重建。阅读一份compose.yml时可以按下面的顺序services有哪些服务image/build程序来自现有镜像还是本地构建ports哪些端口暴露给宿主机volumes哪些数据脱离容器可写层保存environment服务带着什么参数启动depends_on/networks服务如何依赖和通信。depends_on的简短写法只保证依赖服务先启动不保证它已经能接受请求。需要等待服务真正就绪时要结合healthcheck和condition: service_healthy应用侧最好仍保留连接重试。六、下次更新不生效先问三个问题现在回头看最开始的操作dockercompose pull appdockercompose restart app第一条命令更新了本地镜像第二条命令却只启动了原来的容器。服务继续运行旧版本完全符合 Docker 的生命周期逻辑。下次再遇到“明明更新了为什么没有生效”先问自己我更新的是镜像、创建期配置还是应用能够重新读取的文件我现在操作的是当前镜像还是之前创建的旧容器这次需要重新读配置、重启同一容器还是创建替代容器最后记住这一句就够了新布景到了后台重新拉一次幕不会自动换景要演新版得先换景再开场。对应到 DockerPull 是拿到新镜像restart 是重启旧容器recreate 才让服务换成按当前镜像与配置创建的新容器。
