回滚本质是停用当前容器并启动指定旧版镜像的新容器；需确保历史镜像存在、使用语义化版本标签、配合Compose或脚本实现标准化操作。
回滚不是“还原容器”，而是换镜像重启服务——关键在历史镜像是否就位、标签是否清晰、启动参数是否一致。
确认旧版镜像已就绪
回滚的前提是目标版本镜像已在本地存在。运行以下命令检查：
- docker images | grep your-app-name —— 查看是否有类似 your-app:v1.2.0 这样的语义化标签镜像
- 若缺失，先执行 docker pull your-app:v1.2.0（确保该 tag 在远程仓库中存在）
- 避免依赖 latest 标签——它不固定、不可追溯，生产环境必须用明确版本号
停旧启新，四步完成切换
以当前运行 myweb:v2.1.0、需回退至 myweb:v1.9.3 为例：
- docker stop myweb —— 停止正在运行的容器
- docker rm myweb —— 删除容器（如挂载了外部卷或配置文件，可跳过此步；但后续启动必须改名或清理冲突端口）
- docker run -d --name myweb -p 80:80 --restart unless-stopped myweb:v1.9.3 —— 按原参数启动旧镜像
- curl -I http://localhost 或 docker logs -n 10 myweb —— 快速验证服务响应与日志输出
用 Docker Compose 简化回滚流程
若使用 docker-compose.yml 管理服务，只需改一行再重部署：
- 编辑 docker-compose.yml，将 image: myweb:v2.1.0 改为 image: myweb:v1.9.3
- 执行 docker compose down && docker compose up -d
- Compose 会自动复用原有网络、卷和启动选项，比手动 run 更可靠
提前预防：让回滚真正“快速”
回滚快不快，取决于日常是否做了这几件事：
- 每次构建都打带版本号的 tag（如 v1.9.3），并推送到私有/公共 registry
- 本地定期 docker save -o backup_v1.9.3.tar myweb:v1.9.3，离线也能恢复
- 记录每次上线的镜像 SHA256 值（docker images --digests），避免 tag 被覆盖导致误判
- 关键服务用脚本封装回滚动作，例如 ./rollback.sh v1.9.3，内含停、删、拉、启、验全流程
