企业官网建设流程全解析

这次我们来看 Docker 升级、降级、迁移和备份的完整操作流程。对于依赖 Docker 运行关键服务的开发者或运维人员来说，版本迭代和环境迁移是绕不开的坎。直接升级怕服务中断，降级又担心配置丢失，迁移到新机器更是让人头疼。这篇文章的核心就是解决这些痛点，提供一套按步骤操作、零风险、不丢配置的实战方案。

我们将重点关注几个核心问题：如何安全地进行 Docker 版本升级或降级？如何完整备份包括镜像、容器、卷和网络配置在内的整个 Docker 环境？如何将 Docker 环境从一台主机平滑迁移到另一台主机？整个过程会涉及具体的命令、备份文件的管理以及恢复时的注意事项。无论你是个人开发者管理自己的实验环境，还是团队需要维护生产环境的连续性，这套方法都能帮你把风险降到最低。

下面，我会带你一步步操作，从环境检查开始，到备份关键数据，再到执行版本变更或迁移，最后验证服务完整性。每个环节都有明确的命令和检查点，确保你执行时心里有底。

1. 核心能力速览：Docker 环境管理操作全景

在深入步骤之前，我们先通过一个表格快速了解本文涵盖的核心操作及其价值，让你对整体工作有个清晰的认识。

2. 适用场景与使用边界

这套操作流程主要适用于以下场景：

1. 计划性维护：在服务器维护窗口期内，对 Docker 进行安全升级。
2. 故障回滚：升级后应用出现兼容性问题，需要快速降级到旧版本以恢复业务。
3. 服务器迁移：更换云服务器、物理机或迁移到新的开发环境时，需要完整搬迁 Docker 环境。
4. 灾难恢复准备：定期备份 Docker 环境，作为灾难恢复计划的一部分。
5. 开发/测试环境同步：将生产环境的 Docker 配置（不含敏感数据）复制到测试环境。

使用边界与重要提醒：

• 数据卷是核心：本文方法能备份卷的定义和挂载关系，但默认的docker save/load和docker export/import不包含卷内的实际数据。对于volume和bind mount中的业务数据，需要单独备份（下文会详细说明）。
• 并非热迁移：此流程需要停止相关容器，属于冷迁移或冷升级。对于要求 24x7 高可用的服务，需要结合集群方案（如 Docker Swarm, Kubernetes）实现滚动升级，本文方案可作为底层准备。
• 系统兼容性：降级时，需确保目标旧版本与你当前的操作系统内核及依赖库兼容。
• 资源充足：备份和恢复镜像会占用磁盘空间，迁移过程需要网络传输，请确保资源充足。

3. 环境准备与前置检查

开始任何操作之前，做好准备工作是避免错误的第一步。请依次完成以下检查。

3.1 系统与 Docker 现状检查

首先，记录下当前环境的详细信息，这将在出问题时提供关键的对照依据。

1. 检查系统信息：

   # 查看操作系统版本 cat /etc/os-release # 查看内核版本 uname -r

2. 检查当前 Docker 状态：

   # 查看 Docker 版本、API 版本、Go 版本等详细信息 docker version # 查看 Docker 系统层面的信息，包括容器、镜像数量，存储驱动等 docker info

3. 记录正在运行的容器：

   # 列出所有正在运行的容器，并记录其容器 ID 和名称 docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}" # 列出所有容器（包括已停止的） docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}"

   将上述命令的输出保存到一个文本文件中，例如docker_status_before.txt。

3.2 磁盘空间检查

备份和镜像操作会消耗大量磁盘空间，务必提前检查。

# 查看 Docker 默认存储目录（通常是 /var/lib/docker）的磁盘使用情况 df -h /var/lib/docker # 查看根目录或备份目标目录的可用空间 df -h /

建议：确保有至少两倍于/var/lib/docker当前已用空间的空闲容量。

3.3 停止相关服务

为了保证数据一致性，在备份和升级/降级前，强烈建议停止所有容器。如果某些容器不能停止，请确保你理解不停止带来的风险（数据不一致）。

# 停止所有正在运行的容器 docker stop $(docker ps -q) # 再次确认没有容器在运行 docker ps

4. 完整备份：为你的 Docker 环境创建快照

这是实现“零风险”的基石。一个完整的备份应包括：镜像、容器定义、数据卷、网络配置以及 Docker 守护进程配置。

4.1 备份所有 Docker 镜像

使用docker save命令将镜像打包成 tar 文件，此操作会保留镜像的所有层和历史。

# 获取所有镜像的 ID docker images -q > image_list.txt # 将所有镜像打包到一个 tar 文件中（耗时较长，文件较大） docker save $(docker images -q) -o docker_images_backup_$(date +%Y%m%d).tar # 或者，逐个镜像备份到单独文件（便于管理特定镜像） for image in $(docker images --format "{{.Repository}}:{{.Tag}}"); do # 将镜像名中的`/`和`:`替换为`-`，作为文件名 filename=$(echo $image | sed 's[/[-]g' | sed 's[:]-]g').tar docker save $image -o $filename done

4.2 备份容器状态与配置

虽然容器本身可以从镜像运行，但容器的特定配置（如启动命令、环境变量、端口映射）需要备份。docker export只备份文件系统，不推荐用于配置备份。更好的方式是备份容器的“定义”。

1. 备份容器创建命令（推荐）： 对于每个需要备份的容器，使用docker inspect来获取其详细配置，但更简单的方式是记录下docker run命令。如果你当初是用docker-compose.yml启动的，那么备份这个 yml 文件即可。

   # 示例：手动记录。对于每个容器，运行类似命令查看其启动参数 docker inspect <container_name_or_id> | grep -A 10 -B 2 "Args\|Env\|Ports\|Mounts"

2. 使用docker commit谨慎备份（适用于临时保存容器当前状态）：

   # 将容器当前状态提交为一个新镜像 docker commit <container_name_or_id> backup/<container_name>:snapshot_$(date +%Y%m%d)

   注意：docker commit通常不推荐用于生产环境，因为它会把容器层（可能包含临时数据、日志）也固化到镜像中，导致镜像臃肿。它更适合作为临时应急快照。

4.3 备份数据卷（Volumes）

这是最关键也最容易遗漏的一步。Docker 卷是持久化数据的首选方式。

1. 列出所有卷：

   docker volume ls

2. 备份每个卷的数据： 我们需要运行一个临时容器，挂载需要备份的卷和宿主机的一个备份目录，然后使用tar命令将卷内数据打包。

   # 创建一个目录用于存放卷备份 mkdir -p /backup/docker-volumes # 对每个卷进行备份 for volume_name in $(docker volume ls -q); do echo "Backing up volume: $volume_name" docker run --rm -v $volume_name:/volume_data:ro -v /backup/docker-volumes:/backup alpine \ tar czf /backup/${volume_name}_backup_$(date +%Y%m%d).tar.gz -C /volume_data . done

   命令解释：

   • --rm：容器退出后自动删除。
   • -v $volume_name:/volume_data:ro：将 Docker 卷以只读方式挂载到容器的/volume_data目录。
   • -v /backup/docker-volumes:/backup：将宿主机的备份目录挂载到容器的/backup目录。
   • alpine：使用一个轻量级 Linux 镜像。
   • tar czf ...：在容器内执行打包命令，将/volume_data下的所有文件压缩到宿主机备份目录中。

4.4 备份 Docker 网络与配置

1. 备份网络列表：虽然网络配置通常可以重新创建，但备份一下更稳妥。

   docker network ls > docker_networks_list_$(date +%Y%m%d).txt # 对于自定义网络，可以导出其详细配置 for net in $(docker network ls --filter type=custom -q); do docker network inspect $net > network_${net}_backup.json done

2. 备份 Docker 守护进程配置：

   # Docker 的配置文件通常位于 /etc/docker/daemon.json sudo cp /etc/docker/daemon.json /backup/daemon.json.backup 2>/dev/null || echo "No daemon.json found." # 备份 Docker 服务文件（Systemd） sudo cp /lib/systemd/system/docker.service /backup/docker.service.backup 2>/dev/null || echo "No systemd service file found in standard location."

4.5 备份文件整理

至此，你的备份目录（例如/backup）应该包含以下文件：

• docker_images_backup_YYYYMMDD.tar：所有镜像的打包文件。
• /backup/docker-volumes/：目录下各个卷的.tar.gz备份文件。
• docker_status_before.txt：容器状态记录。
• docker_networks_list.txt：网络列表。
• *.json：自定义网络配置文件。
• daemon.json.backup等：Docker 配置备份。

最佳实践：将整个/backup目录打包压缩，并传输到安全的异地存储位置。

tar czf full_docker_backup_$(date +%Y%m%d).tar.gz -C /backup .

5. 执行升级或降级

完成备份后，你就可以放心地进行版本变更了。这里以 Ubuntu/Debian 系统为例，使用 apt 包管理器。

5.1 升级 Docker 到最新版本

1. 更新软件包索引：

   sudo apt-get update

2. 安装特定版本或最新版本：

   # 如果要安装特定版本，先列出可用版本 apt-cache madison docker-ce | awk '{print $3}' # 安装指定版本，例如 5:24.0.9-1~ubuntu.22.04~jammy # VERSION_STRING=5:24.0.9-1~ubuntu.22.04~jammy # sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin # 安装最新版本 sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

5.2 降级 Docker 到旧版本

降级过程本质上是安装一个更旧的指定版本。

1. 列出已安装版本，确定当前版本。

   apt list --installed | grep docker-ce

2. 安装旧版本。你需要知道确切的旧版本字符串。

   # 1. 首先，如果知道版本号，直接安装 # sudo apt-get install docker-ce=<OLD_VERSION> docker-ce-cli=<OLD_VERSION> containerd.io docker-buildx-plugin docker-compose-plugin # 例如：sudo apt-get install docker-ce=5:20.10.24~3-0~ubuntu-jammy docker-ce-cli=5:20.10.24~3-0~ubuntu-jammy containerd.io # 2. 如果不知道，可以尝试从旧版本的源安装，但这更复杂。 # 更稳妥的做法：从备份中恢复整个 Docker 环境（见第6节），而不是仅仅降级二进制文件。

   重要提示：直接降级包有时会因依赖问题失败。最安全、最彻底的“降级”方法是在新机器或干净环境中恢复整个备份。

3. 验证版本：

   docker version

6. 恢复与验证：从备份中重建环境

无论是升级后出现问题需要回滚，还是迁移到新机器，恢复流程都是一样的。

6.1 在新环境恢复 Docker 镜像

1. 传输备份文件：将之前打包的full_docker_backup.tar.gz传输到目标机器。
2. 解压备份文件：

   mkdir /restore && cd /restore tar xzf /path/to/full_docker_backup.tar.gz

3. 加载所有镜像：

   docker load -i /restore/docker_images_backup_YYYYMMDD.tar # 验证镜像已恢复 docker images

6.2 恢复数据卷

1. 创建空卷：首先，创建与备份同名的卷（如果不存在）。

   # 查看备份的卷列表（可以从备份的卷备份文件名中提取） ls /restore/docker-volumes/*.tar.gz | sed 's/.*\///;s/_backup_.*//' # 创建卷 for volume_name in $(ls /restore/docker-volumes/*.tar.gz | sed 's/.*\///;s/_backup_.*//'); do docker volume create $volume_name done

2. 将数据解压回卷：再次使用临时容器，将备份文件解压到新卷中。

   for backup_file in /restore/docker-volumes/*.tar.gz; do volume_name=$(basename $backup_file | sed 's/_backup_.*//') echo "Restoring volume: $volume_name from $backup_file" docker run --rm -v $volume_name:/volume_data -v /restore/docker-volumes:/backup alpine \ sh -c "rm -rf /volume_data/* /volume_data/..?* /volume_data/.[!.]* ; tar xzf /backup/$(basename $backup_file) -C /volume_data" done

   命令解释：先清空卷内可能存在的残留文件，然后解压备份。

6.3 恢复容器

如果之前用docker-compose.yml管理，恢复最简单：

# 进入你的 docker-compose.yml 所在目录 docker-compose up -d

如果是通过docker run命令启动的，则需要根据之前记录的参数重新运行。这就是为什么备份时强调要记录启动命令或使用 Compose 文件。

# 示例：根据记忆或记录重新运行容器，确保卷映射、端口映射等参数与之前一致 docker run -d \ --name my_app \ -v my_data_volume:/app/data \ -p 8080:80 \ my_image:tag

6.4 恢复网络与配置

1. 恢复自定义网络：如果容器依赖于特定的自定义网络（如自定义子网），需要先创建。

   # 参考备份的 network_*.json 文件中的配置，使用 docker network create 重新创建 # 例如：docker network create --driver bridge --subnet 172.20.0.0/16 my_custom_net

2. 恢复 Docker 配置：

   # 恢复 daemon.json sudo cp /restore/daemon.json.backup /etc/docker/daemon.json 2>/dev/null || echo "No daemon.json backup to restore." # 重启 Docker 守护进程使配置生效 sudo systemctl restart docker

6.5 完整性与功能验证

恢复后，必须进行验证。

1. 检查容器状态：

   docker ps -a

   确保所有需要的容器都处于Up状态。

2. 检查容器日志：

   docker logs <container_name>

   查看是否有启动错误。

3. 验证数据：

   # 进入一个容器，检查卷数据是否存在 docker exec -it <container_name> ls /path/to/mounted/volume # 或者直接检查卷数据 docker run --rm -v my_data_volume:/volume_data alpine ls -la /volume_data

4. 测试服务端口：

   curl http://localhost:<mapped_port>

   或者通过浏览器访问服务，确认业务功能正常。

7. 迁移备份：主机A到主机B的完整搬迁

迁移实质上是“在主机B上执行恢复操作”。流程完全一致，但有几个额外要点：

1. 环境一致性：尽量保证主机B的操作系统版本、内核版本与主机A相似，以减少兼容性问题。
2. Docker 版本：主机B上安装的 Docker 版本最好与备份时的版本一致，或至少是兼容的较新版本。如果版本跨度太大，先尝试在主机B上恢复镜像和卷，再升级 Docker。
3. 资源分配：确保主机B的磁盘空间、内存、CPU 资源不低于主机A。
4. 网络与存储：如果容器配置中使用的是主机B不存在的绝对路径（Bind Mounts），需要在恢复前在主机B上创建相应的目录结构。如果涉及特定的网络配置（如固定IP），也需要在主机B上预先配置好。
5. 分步验证：不要一次性启动所有容器。先启动基础服务（如数据库），验证无误后再启动应用服务。

8. 常见问题与排查方法

在升级、降级、迁移过程中，你可能会遇到以下问题。

9. 最佳实践与自动化建议

遵循以下建议，可以让 Docker 环境管理更轻松、更安全。

1. 一切皆代码（Infrastructure as Code）：

   • 强制使用 Docker Compose：所有容器，无论是单机还是复杂应用，都使用docker-compose.yml文件定义。这个文件本身就是最好的备份，包含了镜像、网络、卷、端口等所有配置。
   • 版本控制：将docker-compose.yml文件纳入 Git 等版本控制系统。

2. 定期备份策略：

   • 镜像备份：对于自定义构建的镜像，推送到私有镜像仓库（如 Harbor, Nexus）是比docker save更优的长期存储方案。
   • 卷备份自动化：将卷备份命令写成脚本，结合cron定时任务执行。可以考虑使用restic、borg等专业备份工具，支持增量备份和加密。
   • 3-2-1 备份原则：至少保留 3 份备份，使用 2 种不同介质，其中 1 份存放在异地。

3. 升级前测试：

   • 建立一个与生产环境相似的测试环境。先在测试环境中进行 Docker 版本升级和完整恢复演练，确认无误后再操作生产环境。

4. 清晰的文档：

   • 维护一个README.md或运维手册，记录以下信息：
     • 每个服务的docker run命令或docker-compose.yml路径。
     • 数据卷的用途和备份策略。
     • 自定义网络的配置。
     • 上次备份和恢复的日期、结果。

5. 考虑使用编排工具：

   • 当服务规模增长时，考虑使用 Docker Swarm 或 Kubernetes。它们内置了滚动升级、服务发现、配置管理等功能，能大大简化升级和迁移的复杂度。

10. 总结与下一步

通过以上步骤，你已经掌握了一套从备份、升级/降级到恢复、迁移的完整 Docker 环境管理流程。这套方法的核心价值在于“可预测”和“可回滚”，通过先备份再操作的原则，将风险控制在可接受的范围内。

最应该优先实践的是“完整备份”环节。即使暂时不进行版本变更，定期执行第 4 节的备份脚本，也能为你的 Docker 环境买一份“保险”。当意外发生时，你可以从容地从备份中恢复，而不是手足无措。

最容易踩的坑是“忽略数据卷的备份”。请务必反复检查并验证你的卷备份和恢复命令是否正常工作。一个简单的验证方法是：备份后，删除原卷，然后从备份恢复，最后对比恢复前后的数据是否一致。

下一步，你可以尝试：

1. 编写自动化脚本：将备份和恢复的步骤封装成 Shell 或 Python 脚本，减少手动操作出错的可能。
2. 集成到 CI/CD：在部署流水线中，加入部署前备份、回滚时自动恢复的环节。
3. 探索 Docker 存储驱动：了解overlay2等存储驱动的工作原理，这有助于你更深层次地理解镜像和容器的存储机制，在排查复杂问题时更加得心应手。

将这套流程固化下来，Docker 环境的维护将从一件令人焦虑的任务，转变为一项按部就班、安全可控的常规操作。