Docker 维护：备份、升级、回退与清理

镜像发布、备份恢复与升级

维护Docker 双服务计数项目前先保存Context、store/gateway、项目名与 counter 卷，恢复后以容器日志、UPSTREAM 和实际挂载验收。具体配置见配套示例。

发布标识与回滚

Docker 发布 digest 应与源码提交、基础镜像、平台、配置版本和数据迁移一起记录。标签只帮助人定位，最终部署内容用不可变 digest 确认；重启已有容器不等于采用新镜像，重新创建才能使用新的配置与 image 引用。

回滚镜像不等于回滚数据。如果新程序已把 schema 改成旧程序不能读取的形态，换回旧镜像会再次失败。变更应先设计向前兼容、备份和恢复时间，按同一镜像产物逐环境提升。主例无 schema 迁移，仅创建缺失表；不能因此推断任何数据库应用都可无条件回退。

卷备份与恢复次序

Docker 备份 卷 要覆盖数据、构建文件、配置与镜像引用。SQLite 计数库可在停止写入后复制数据库文件，或使用数据库在线备份接口；不要把运行中的数据库和 journal 任意拼接。恢复先写入新卷，校验计数与权限，保留旧卷直到确认恢复成功。镜像 save 与容器 export 都不能代替卷的应用一致备份。

备份清单至少记录来源项目、卷名、快照时间、应用状态、校验值、加密位置与恢复步骤。只看到 tar 文件存在不代表可以恢复；本课程没有执行恢复演练，因此只提供判断框架，不给“已可恢复”的保证。

日志、容量与资源

Docker 日志 轮转 限制的是容器日志文件，不限制业务数据增长。主例 local driver 设置 max-size 与 max-file；SQLite 数据卷仍需单独容量策略。不要手工删除 Docker 内部日志或 /var/lib/docker 文件来抢空间，这会破坏 daemon 的状态关系。

CPU 配额可能导致请求变慢，内存上限可能导致 OOM；退出码 137 只能说明收到了 SIGKILL 的编码，必须结合 OOMKilled、宿主日志与手工 kill 证据，不能机械认定内存超限。共享宿主磁盘、inode、PID 和日志后端也会造成服务故障。

权限与维护边界

Docker socket 权限 接近宿主管理权，加入 docker 组不是普通应用访问权。把 socket 挂入容器、暴露未认证 TCP API 或使用 privileged 解决普通目录权限，会扩大宿主风险。非 root USER 只降低容器内默认权限，不消除危险挂载或共享内核边界。

Engine 升级前需核对存储驱动、image store、运行时与发行版兼容性，并明确停机窗口、备份和回退限制。不能把直接复制 daemon 数据目录当作跨版本恢复方案。清理遵循先列对象、确认归属、再精确删除；不要对共享主机运行全局 system prune。Rootless、SELinux 和 Windows VM 的卷实现还需各自核对。

维护练习与解答

问题：容器正常重启却读到旧配置，为什么？答案：创建时环境变量固化在容器配置，改 Compose 文件后仅 restart 不会应用新配置，需重建并确认依赖和数据兼容。

问题：可以用 down --volumes 修复卷权限吗？答案：这会删除数据，不能当作权限修复。先保存数据并确认拥有者，针对具体目录权限处理，或恢复到有正确权限的新卷。

按需继续阅读原有Registry、资源、安全、日志、维护、CI/CD。它们保留较宽操作覆盖，旧具体版本和示例环境须重新核对。一手依据：Docker security、Logging drivers。核对 2026-10-17。

从服务清单还原初始化与发布依赖

为什么复制 Apollo 或多产品 Compose 文件不能证明初始化和发布已经完成？ 容器启动、数据库初始化、配置生效和外部入口是四项不同检查。Apollo 旧记录要求先执行 apolloconfigdb.sql 与 apolloportaldb.sql，再调整 ServerConfig 中的 eureka.service.url；另一个文件列 portal、configservice、adminservice 的数据库 URL 与 DEV_META。这里保留的学习价值是初始化依赖：仅有镜像和 depends_on 不能证明 SQL 已执行，原记录没有提供 SQL 内容，也没有证明数据库 schema 与镜像匹配。阅读这类系统时先列出初始化产物、负责服务、访问身份、配置来源及验证信号，再判断能否发布。不要把一组 IP 替换当作完成迁移。

多产品旧部署还暴露出入口与数据的分离：Gogs 同时记录 Web 外部 URL 和 SSH 发布端口，FRP 分别记录服务端控制连接、代理业务端口与管理入口，MinIO 列对象数据和配置挂载，Nginx 列站点文件、证书路径和上游地址。它们需要分别进入地址表和数据清单；旧配置里的个人域名、口令、未锁定镜像与 TLS 片段不是新环境参数。MongoDB 的 --auth 与创建用户记录也只能说明作者尝试了认证，不能代替应用账号权限与数据目录设计。原配置全文留在编辑归档，课程只吸收这种依赖还原方法，不提供未验证的新部署清单。

对应本课，store 的数据库初始化发生在应用启动路径，gateway 的就绪依赖 store 的 /ready；它们的配置、源码与数据卷均须一起检查。遇到外部数据库或配置中心时，还要补足本项目没有的 schema 版本、迁移与账号管理证据。Compose 启动次序支持启动与就绪的区分，产品特定初始化仍需按目标产品版本核对。

Docker 维护、备份与升级

1. 维护前

docker context show
docker version
docker ps -a --no-trunc
docker volume ls
docker system df -v
docker buildx du

确认负责人、窗口、健康检查、回滚 digest、备份位置和恢复时限。

2. 安全清理

先列出对象，再删除明确目标：

docker image ls --filter dangling=true
docker image prune
docker buildx du --verbose
docker buildx prune --filter 'until=168h'
docker network ls

共享 builder cache 可能属于其他流水线；预创建网络可能暂未连接。危险： volume prune、system prune -a --volumes 和 compose down --volumes 可能删除唯一数据或回滚镜像，不作为常规维护命令。

3. 备份范围

• Git 中的 Dockerfile、Compose、部署配置；
• image digest、SBOM、provenance、签名和 Registry 副本；
• 数据库原生备份；
• 卷/外部存储的应用一致备份；
• daemon 配置、CA 与授权清单；
• 已演练的恢复 runbook。

不把直接复制 /var/lib/docker 当作跨版本/存储驱动通用恢复方案。

4. 卷备份与恢复

先用 docker volume inspect app-data 确认源卷确实存在且属于目标应用，避免卷名拼错时自动创建空卷；然后停止写入或创建应用一致快照：

mkdir -p ./backup
docker run --rm \
  --mount type=volume,src=app-data,dst=/source,readonly \
  --mount type=bind,src="$PWD/backup",dst=/backup \
  alpine:3.23 \
  tar -C /source -czf /backup/app-data.tar.gz .
sha256sum ./backup/app-data.tar.gz > ./backup/app-data.tar.gz.sha256

恢复到新卷验证：

docker volume create app-data-restore
docker run --rm \
  --mount type=volume,src=app-data-restore,dst=/target \
  --mount type=bind,src="$PWD/backup",dst=/backup,readonly \
  alpine:3.23 \
  tar -C /target -xzf /backup/app-data.tar.gz

数据库优先用版本匹配的 pg_dump/mysqldump 等工具；恢复演练必须包含业务校验。

5. 升级

1. 阅读完整 release notes，检查废弃项、API、存储、网络、cgroup 和防火墙变化。
2. 同 OS/kernel 测试节点回归。
3. 完成备份、回退和维护审批。
4. 滚动升级，验证容器、网络、卷、日志、Build 与 Compose。

原手册的 2026-08-12 版本快照为 Engine/CLI 29.7.2，不是当前最新版本或目标环境已验证基线。Engine 29.0 有破坏性变化，且新安装默认 containerd image store；不能假设升级机器状态相同。

Ubuntu：

apt-cache madison docker-ce
sudo apt-get update
sudo apt-get install \
  docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

固定版本时使用当前仓库显示的完整版本字符串。

6. 升级后与回退

docker version
docker info
docker compose version
docker buildx version
sudo journalctl -u docker --since '15 min ago' --no-pager

回退前确认旧包、数据格式、storage/containerd 状态和配置迁移。包降级不一定受支持；可靠回退依赖经测试的节点镜像/快照和外部数据备份。

7. 周期任务

周期	任务
每日	daemon/容器健康、OOM、磁盘、日志采集
每周	system df、cache、证书到期趋势
每月	安全公告、镜像重建、容量趋势
每季度	恢复演练、权限与 docker 组审计

8. 官方参考

• Engine release notes
• Prune unused objects
• Ubuntu upgrade