用 Docker 简化部署与版本升级：一份可复用的实践

同事写了一个 app，笔者用它作为例子，聊聊 Docker 部署方式下如何简化部署和版本升级。核心思路很简单：把配置和代码分开，升级时只换代码，配置从备份里拿回来。

01 | 升级前先停服务

升级的第一步不是拉代码，而是先停掉正在运行的容器，避免文件被占用或状态错乱。下面的容器名 ontoforge_app_1 来自 docker-compose 的默认命名规则（项目名_服务名_序号），请先用 docker ps 确认你环境中的实际容器名：

bash 复制代码

docker ps
docker stop ontoforge_app_1

停完之后，把旧目录整体改名备份。这样做的好处是，旧目录里的 docker-compose.yml 还能留着，之后可以从中复制数据库配置和端口配置：

bash 复制代码

mv ontoForge ontoForge_bak

这一步的意图可以用一张流程图概括：旧目录不是被删除，而是被"冻结"成一个配置来源，后续新目录会从这里取回属于自己的那份配置。
flowchart LR A $运行中的容器\ontoforge_app_1$ -->|docker stop| B $容器停止$ B -->|mv ontoForge ontoForge_bak| C $旧目录备份\保留 docker-compose.yml$ C --> D $作为配置来源\供新目录复制$

02 | 拉取最新代码

备份完成后，克隆最新版本：

bash 复制代码

git clone git@github.com:zhengwanbo/ontoForge.git

进入新目录后，先对比新克隆的 docker-compose.yml 与备份中的配置。若仓库中的文件是默认模板或已被忽略，就需要把备份目录里的配置复制回来；若仓库中已包含你的实际配置，则无需覆盖：

bash 复制代码

cd ontoForge
cp ../ontoForge_bak/docker-compose.yml ./

这一步是整篇实践里最关键的地方：代码用最新的，配置用自己原来的。数据库连接、端口这些信息都保留在旧配置里，复制过来即可，不用重新手写。

可以用一张图看清"代码"和"配置"这两条来源的分离关系：
flowchart TB subgraph 新代码 G $git clone\最新 ontoForge$ end subgraph 旧配置 B $ontoForge_bak\docker-compose.yml$ end G --> N $新目录 ontoForge$ B -->|cp 复制回配置| N N --> R $代码最新 + 配置不变$

03 | 清理旧容器与镜像

配置就位后，清理掉旧的容器和镜像，避免 build 时用到缓存或旧层：

bash 复制代码

docker rm ontoforge_app_1
docker images
# 注意：docker image prune -f 会清理所有悬空镜像，多项目共用主机时请谨慎
docker image prune -f
# 若镜像不存在或仍被占用会报错，可先确认再删除
docker rmi localhost/ontoforge_app || echo "镜像不存在或仍被占用，请检查 docker ps -a"
docker images

这里先删容器，再清理无用镜像，最后删掉 app 对应的镜像。中间两次 docker images 是为了确认相关历史镜像确实已经删除，再进入下一步。

清理顺序本身也有依赖关系，容器不先移除，镜像往往无法顺利删除：
flowchart LR A $docker rm\删除旧容器$ --> B $docker image prune -f\清理无用镜像$ B --> C $docker rmi\删除 app 镜像$ C --> D $docker images\确认已删除$

04 | 重新构建并启动

确认旧镜像清理干净后，重新构建最新版本并后台启动：

bash 复制代码

docker-compose up -d --build
docker-compose ps
docker-compose logs -f --tail=50

--build 会强制重新构建镜像，-d 让容器在后台运行。启动后请用 docker-compose ps 确认容器状态、用日志确认服务正常。若升级失败，可回到 ontoForge_bak 目录用旧配置重新 docker-compose up -d 回滚。

05 | 小结

这套流程可以概括为三步：停服务并备份旧目录、克隆新代码并复制回自己的配置、清理旧镜像后重新 build。它的价值在于把"配置"和"代码"解耦，升级时通常不用重新配置环境。但前提是旧目录备份仍然存在，且数据库等有状态数据已通过 volume 持久化；否则配置或数据仍可能丢失，建议升级前单独备份 docker-compose.yml 和关键数据卷。对于用 Docker 部署的小型项目，这是一个简单又稳妥的做法。
flowchart LR S1 $停服务 + 备份旧目录$ --> S2 $克隆新代码 + 复制回配置$ S2 --> S3 $清理旧镜像 + 重新 build$ S3 --> S4 $升级完成$

关注我，和AI一起成长~