Docker Compose 更新、回滚与卸载服务：控制版本和数据风险
更新容器不是简单地重新执行一次 up -d。镜像、Compose 配置、环境变量和持久化数据共同决定服务能否启动；一旦新版本修改数据库结构，仅切回旧镜像通常无法恢复原状态。
本文给出单机 Docker Compose 服务的通用生命周期方法。项目专用迁移命令、多组件更新顺序和版本兼容范围仍以目标服务的官方发布说明为准。
操作边界
| 操作 | 改变的对象 | 默认是否删除数据 |
|---|---|---|
| 更新 | 镜像和重新创建的容器 | 否 |
| 配置回退 | Compose、.env 和代理配置 | 否 |
| 程序回滚 | 镜像版本 | 否，但旧程序未必兼容新数据 |
| 数据恢复 | 卷、绑定目录或数据库 | 会改变目标数据 |
| 卸载 | 容器和网络，可选卷与目录 | 取决于命令和人工清理范围 |
更新前盘点
在 Compose 项目目录校验当前配置，并记录镜像和容器状态：
docker compose config --quiet
docker compose config --images
docker compose images
docker compose ps
docker compose config --volumes在权限受限且已纳入加密备份的位置保存实际使用的 compose.yaml、.env 和反向代理配置；多 Compose 文件或 --env-file 也要一并保存。不要将 docker compose config 的完整输出重定向到普通文件或公开日志：配置输出可能展开环境变量和敏感值。升级前按 Docker 备份与恢复数据 备份不可重建的数据，并阅读目标版本的 Release notes。使用 latest 时无法从配置直接判断旧版本，正式环境应先改成明确 tag，关键服务可以进一步记录 digest。
更新 Compose 服务
先修改镜像 tag 和必要配置，再检查最终 Compose：
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200pull 只下载镜像，up -d 才会按变化重新创建服务。不要在没有版本说明和数据备份时同时跨多个大版本。多服务项目还要核对数据库、应用、Worker 和前端是否要求配套版本。
更新验收
验收不能停在容器显示 running。至少检查健康状态、一个真实业务请求、登录或鉴权、已有数据读取和一次新的写入；后台任务、WebSocket、邮件、对象存储等项目能力也应各选一条代表性路径。
docker compose ps
docker compose logs --tail=100 app
curl -fsS http://127.0.0.1:8080/healthapp、端口和 /health 是示意值，换成项目实际服务名、绑定端口和健康或业务路径；没有健康接口时不要凭空添加该请求。只有结果符合预期，且备份仍可恢复，才能按保留策略清理旧镜像和升级前副本。
回滚服务
回滚分为三个层次：
- 新镜像没有接触持久化数据时，可以恢复旧 tag 后重新执行
docker compose pull和docker compose up -d。 - 配置结构发生变化时，同时恢复升级前的 Compose 文件、
.env、额外环境文件和代理配置，再运行docker compose config --quiet。 - 新版本已经迁移数据时，应停止新服务，把升级前备份恢复到新卷或隔离目录，然后让旧镜像读取恢复副本。
不要让旧版本直接打开已经由新版本迁移的数据。官方没有声明降级兼容时，应把“切回镜像”称为程序回退，而不是完整回滚。
卸载与删除
停止并删除容器和项目默认网络，同时保留命名卷：
docker compose down删除 Compose 声明的命名卷和容器附带的匿名卷属于不可逆操作：
docker compose down --volumes第二条命令执行前必须通过 docker compose config --volumes、docker compose ps 和针对实际卷名的 docker volume inspect <卷名> 盘点命名卷与匿名卷，确认数据只属于当前项目并已有可恢复备份。Compose 不会自动删除绑定目录、外部数据库、对象存储、OAuth 应用、DNS、证书和云资源；这些对象需要单独列出并逐项处理。共享数据库或 external volume 不应纳入默认卸载。
安全边界
更新期间不要把密钥写进命令行或提交到版本库。配置归档和备份可能包含凭据，应限制权限并加密异机保存。删除卷、清空绑定目录和数据库恢复必须在明确目标、停止写入和保留原副本后执行，不能用全局 prune 命令代替项目级清理。
常见问题
更新后容器反复重启
运行 docker compose logs --tail=200，检查环境变量、文件权限、依赖健康和数据库迁移。不要持续重启可能正在失败迁移的服务。
回退镜像后仍无法启动
检查新版本是否改变数据或配置格式。恢复升级前配置和数据副本，在隔离环境验证旧版本，不要继续覆盖唯一生产卷。
执行 down 后数据还在
普通 down 默认保留命名卷，也不会删除绑定目录。这是安全行为，不代表卸载失败；先盘点归属，再决定是否删除。
操作完成后
为服务保留当前版本、目标版本、变更内容、备份位置、验收结果和回滚条件。下一次更新应复用这份记录，而不是依赖 Shell 历史猜测旧状态。
总结
Compose 生命周期需要分别控制镜像、配置和数据。先固定旧状态、备份数据、验证新版本，再按迁移事实选择程序回退或数据恢复；卸载时则明确区分容器、卷、绑定目录和外部资源。