作为一个常年跟容器化部署打交道的Java开发我太清楚这个场景了项目早期用的是java -jar直接裸机启动后来上了 Docker把 Spring Boot 服务打进了镜像运维和部署确实省心不少。但等到真要发新版本的时候不少人会卡住——旧容器还在跑着端口占着镜像也堆了一堆不敢随便停也不知道正确的更新流程到底该怎么走。这篇文章就是专门解决这个问题的我会从检查当前部署状态讲起把重新部署的完整流程、背后原理、常见坑全部捋一遍适合已经用 Docker 部署过 Java 服务、但还没系统整理过发布流程的开发者参考。1. 先搞清楚你现在的部署形态再谈重新部署很多人一上来就急着执行命令结果旧容器没停干净新容器起不来服务直接中断。重新部署第一步不是敲命令而是先花两分钟搞清楚当前服务是怎么部署的。1.1 查看正在运行的容器和镜像打开终端先执行docker ps看当前到底有哪些容器在跑。这一步能确认几个关键信息容器名是什么、映射了哪些端口、镜像用的是哪个版本。docker ps输出大致长这样CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a1b2c3d4e5f6 myapp:1.2.3 java -jar app.jar 2 weeks ago Up 2 weeks 0.0.0.0:8080-8080/tcp myapp-container这里面IMAGE列的myapp:1.2.3是当前运行的镜像版本NAMES列的myapp-container是容器名这俩后面都要用。再执行docker images看看本地都有哪些镜像尤其是同一个服务的历史版本占了多大空间docker images顺便用docker inspect myapp-container查看容器的详细配置重点看Mounts挂载了哪些卷、NetworkSettings.Ports端口映射和RestartPolicy重启策略这些信息决定了你重新部署时要复刻哪些参数。1.2 确认部署方式单容器还是编排工具重新部署的步骤完全取决于你当初是怎么起的容器常见的有三种直接用docker run启动的单容器部署脚本可能就是几行 shell。用docker-compose.yml定义并启动的多服务组合比如 Java 服务加 MySQL、Redis。生产环境用 Kubernetes 这类编排平台管理的容器由 Deployment 对象控制。如果你用的是 Docker Compose那重新部署会简单很多因为docker-compose.yml里已经把端口映射、环境变量、数据卷、网络都固化好了改版本号就行。如果是裸docker run启动的你就得手动把启动参数完整地记下来或者在docker inspect里逐个对照。我有一个建议哪怕只是单容器部署也尽量写成 Compose 文件。这样以后每次发版不用回忆当初用了什么参数改一行镜像版本号就能重新部署这是我在实际项目里踩过坑之后总结出来的最实用的改进。2. 发新版本前的准备工作重新部署不只是重新跑一个容器那么简单尤其是 Java 服务牵扯到构建产物、镜像版本、数据卷、依赖服务提前准备能省掉大量翻车时间。2.1 构建新镜像之前先做好版本标记Java 服务的代码改完、测试通过之后第一步是打包一般用 Maven 或 Gradle 生成新的 jar/war 包mvn clean package -DskipTests然后写一个合理的 Dockerfile。这里强烈建议镜像标签不要一直用latest而是用带版本号的标签比如myapp:2.0.0。原因很现实latest虽然每次构建都覆盖但你无法从生产环境的容器上直观地看出当前跑的是哪个版本出现问题时排查难度会变大。我见过不止一次生产环境事故查了半天才发现线上还是上个版本的镜像就是因为大家习惯了覆盖latest。推荐的镜像标签规则场景推荐标签说明正式发版myapp:2.0.0版本号清晰可回溯测试环境myapp:dev-20250115带上日期知道构建时间临时验证myapp:pr-123对应具体的合并请求构建命令很简单docker build -t myapp:2.0.0 .如果构建机器和部署机器不是同一台构建完还要推送到镜像仓库docker push registry.example.com/myapp:2.0.02.2 备份当前数据和镜像很多 Java 服务的状态不只存在数据库里还可能会有上传文件、日志、临时文件写在容器内的某个路径。如果你当初启动容器时没有把这些路径挂载到宿主机那容器一删数据就全没了。所以重新部署前先检查数据卷的挂载情况docker inspect myapp-container | grep -A 10 Mounts如果Mounts里有类似/host/data:/app/data这种映射说明数据在宿主机上删容器不影响数据这是安全的。如果容器里确实有需要保留但没挂载的数据目录先把它复制出来docker cp myapp-container:/app/data ./backup-data另外旧镜像也建议保留一份或者至少记下当前镜像的 hash。万一新版本有严重问题你要回滚到旧版本有旧镜像在手就能秒级恢复docker tag myapp:1.2.3 myapp:rollback-1.2.32.3 确认依赖服务的兼容性Java 服务发新版往往不光是 Java 代码变了依赖的 MySQL、Redis、MQ 也可能需要同步调整。重新部署 Java 容器之前先对照一下数据库有没有新增表、有没有 SQL 迁移脚本要执行Redis 的 key 结构有没有变化消息队列的 topic 有没有改名。最常见的翻车现场是新版 Java 服务启动后连不上数据库报Access denied或者表不存在。原因多半是代码里改动了数据库连接配置但容器环境变量没同步更新。所以发布前一定要把配置差异列出来比如SPRING_DATASOURCE_URL、SPRING_DATASOURCE_PASSWORD这些环境变量的新旧值都核对一遍。3. 重新部署的标准操作流程准备做完了下面进入正题。这里我给出一套在我多个项目里验证过的流程每一步都能直接复制执行。3.1 方式一单容器手动重新部署这是最基础的方式适用面最广也最容易理解。整套流程可以用四步概括构建新镜像、停旧容器、删旧容器、起新容器。首先构建新镜像如果跑在部署机上docker build -t myapp:2.0.0 .然后停止并删除正在运行的旧容器docker stop myapp-container docker rm myapp-container注意docker stop不会删除容器只是发送停止信号。停止后容器还是存在的所以要执行docker rm才能真正删掉。如果缺了这一步直接docker run同名容器会报 name already in use 错误。最后启动新容器。启动参数要和旧容器保持一致尤其是端口映射、数据卷、环境变量docker run -d \ --name myapp-container \ -p 8080:8080 \ -v /host/app/logs:/app/logs \ -v /host/app/data:/app/data \ -e SPRING_PROFILES_ACTIVEprod \ -e SPRING_DATASOURCE_URLjdbc:mysql://... \ --restart always \ myapp:2.0.0启动之后确认状态docker ps | grep myapp-container docker logs -f myapp-container看到日志输出Started Application in X seconds这类信息说明服务启动成功了。再用接口测一下curl -s http://localhost:8080/actuator/health3.2 方式二Docker Compose 重新部署如果项目用的是 Compose重新部署的步骤会大幅简化。你只需要做两件事修改镜像版本号然后执行更新命令。假设docker-compose.yml长这样version: 3.8 services: app: image: myapp:1.2.3 container_name: myapp-container ports: - 8080:8080 volumes: - /host/app/logs:/app/logs - /host/app/data:/app/data environment: - SPRING_PROFILES_ACTIVEprod restart: always发新版本时把image: myapp:1.2.3改成image: myapp:2.0.0然后执行docker compose up -d这个命令会对 Compose 文件里定义的服务做一次状态对比发现镜像版本变了就会先创建新容器、停掉旧容器然后把新容器拉起来。它所做的工作就等于手动方式里的docker stop、docker rm、docker run三步只是由工具自动完成了。如果新镜像在远程仓库需要先拉取docker compose pull docker compose up -d用 Compose 还有一个好处如果你同时定义了 MySQL、Redis 等依赖服务docker compose up -d只会重建发生变化的容器依赖服务不受影响。这在手动管理多个容器时是不容易做到的。3.3 为什么必须先删除旧容器才能启动新容器这里展开讲一下原理理解了之后你就不容易在流程上出错。Docker 的容器名是宿主机级的唯一资源。容器本身是一个可读写层叠加在镜像上的运行时实例而名字是对这个实例的引用。当docker run指定了--name myapp-container时Docker 会在本地 namespace 里注册这个名字。如果同名容器还存在于容器列表中哪怕它已经停止了Docker 也会拒绝创建新容器报错信息是docker: Error response from daemon: Conflict. The container name /myapp-container is already in use by container xxxx.... You have to remove that container (or rename) before you can reuse that name.所以流程上必须先docker rm把旧容器的元数据和可写层清理干净才能创建同名的新容器。这也是为什么我在上面的流程里特别强调了docker rm不能省。3.4 更新后如何处理旧镜像新容器跑起来之后宿主机上会残留旧镜像和旧容器如果你没有删干净。用docker ps -a可以查看所有容器包括已退出的docker ps -a那些已经停止且确认不再需要的旧容器可以清理掉docker container prune旧的镜像如果不再需要回滚也可以删除释放磁盘空间docker rmi myapp:1.2.3如果镜像堆积太多想一步清理未被任何容器使用的悬空镜像docker image prune这里我特别提醒一下先确认新版本稳定运行了再去删旧镜像。我刚接手一个项目时图省事在发完新版本当天就把旧镜像删了结果第二天发现新版本有个隐蔽的内存泄漏想回滚旧版本发现镜像没了只能重新构建耽误了小半天。正确的做法是保留旧镜像至少两到三个版本磁盘不够了再按时间优先级清理。4. 部署背后的关键原理镜像、容器与数据卷的关系很多人命令能跑通但遇到意外就懵根因是不理解容器化部署的几个核心概念。这里花点篇幅把原理讲透。4.1 镜像是只读模板容器是运行实例可以把镜像理解成一个打包好的安装盘里面包含了 Java 运行时、依赖库、应用 jar、配置文件。镜像是不可变的构建完成后内容就固定了。而容器是安装盘安装出来的运行环境它在镜像之上加了一个可写层程序运行产生的日志、临时文件会写在这个可写层里。这个设计带来的直接推论就是容器是脆弱的、临时的删除容器不会影响镜像反过来只修改容器内部的文件而不重新构建镜像重启容器后修改就会丢失因为新容器仍然基于原始的镜像层。很多 Java 开发新手在容器里临时改了application.yml或者把某个 jar 塞进了运行目录然后重启容器发现改动全没了就是因为忽略了这条原理。正确的做法是所有配置变更都要通过环境变量、挂载文件或者重新构建镜像来生效。4.2 数据卷是容器与宿主机之间的桥梁上面提到容器是可写层但可写层有个致命问题容器删除后数据就没了。为了保存日志、上传文件这类业务数据必须用数据卷Volume或绑定挂载Bind Mount。数据卷有两种用法我在实际项目中最常用的是绑定挂载因为它直观docker run -d -v /host/app/logs:/app/logs myapp:2.0.0/host/app/logs是宿主机目录/app/logs是容器内目录。写入容器内/app/logs的任何文件实际都会落在宿主机上。这样即使容器被删掉再重建只要挂载关系不变日志和数据都在。这里有一个极其常见的坑Java 服务如果使用 Logback 日志框架默认往容器内/app/logs写日志但容器启动时没有挂载这个目录日志就写在容器可写层的/app/logs下面。一旦重新部署旧容器被删除日志全部丢失。处理办法有两个一是把日志目录挂载到宿主机二是使用docker logs配合 JSON 文件日志驱动采集。生产环境我建议两者都做挂载目录方便按天归档docker logs在排查启动异常时更直接。4.3 镜像构建的层缓存机制构建新镜像时Docker 会逐条执行 Dockerfile 的指令每一条指令生成一个镜像层。如果这次构建的某一层内容和上次完全相同Docker 会直接复用缓存不重新执行。这个机制对 Java 服务有非常重要的优化空间。看一个典型的 Spring Boot DockerfileFROM openjdk:17-jdk-slim WORKDIR /app COPY target/app.jar /app/app.jar ENTRYPOINT [java, -jar, app.jar]这里的问题在于Java 代码每次改动都要重新打包 jarjar 变了COPY target/app.jar这一层缓存就失效了而这一层之后的层也会全部重建。对于单模块的小项目影响不大但如果是大单体或者多模块项目构建时间会被拖长。更合理的做法是先把依赖层分离出来利用 Maven 的依赖缓存FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /build/target/app.jar /app/app.jar ENTRYPOINT [java, -jar, app.jar]这样改代码的时候pom.xml没变RUN mvn dependency:go-offline这一层就能命中缓存构建时间能明显缩短。我在持续集成环境里实测过这种分层方式能把 Spring Boot 项目的镜像构建时间从五分钟压到一分钟以内。4.4 为什么容器里 Java 服务要关注 JVM 参数Java 服务容器化之后一个被反复讨论的问题是 JVM 参数怎么设置。尤其是没有显式设置-Xmx的 Spring Boot 应用在容器里运行会出现两个极端要么 JVM 认为宿主机内存很大、堆开得过大直接把容器内存打爆要么容器被 cgroup 限制后 JVM 无法正确感知内存上限导致 OOM 被操作系统杀掉。以前 Java 8 的 JVM 默认不识别 cgroup 内存限制会拿宿主机内存作为默认堆大小的依据。Java 10 之后默认开启了UseContainerSupportJVM 能感知到容器限制行为正常很多。但即便如此我依然建议在启动参数里显式指定内存java -Xms256m -Xmx512m -jar app.jar对应的 DockerfileENTRYPOINT [java, -Xms256m, -Xmx512m, -jar, app.jar]或者用环境变量传参ENTRYPOINT [java, -XX:MaxRAMPercentage75.0, -jar, app.jar]-XX:MaxRAMPercentage75.0的意思是使用容器可用内存的 75% 作为堆上限剩余留给 JVM 非堆内存和系统开销这个比例是 Spring Boot 容器最常见的安全配置。有次我接手一个部署在 512MB 限制容器里的服务默认 JVM 堆按宿主机内存设置每次发版后运行几个小时就容器重启改成环境变量传-XX:MaxRAMPercentage之后问题彻底消失。5. 生产环境的发布策略与回滚方案前面讲的是单实例更新命令层面能解决问题。但生产环境往往要求服务不中断这里就需要引入一些更成熟的发布策略。5.1 滚动更新与零停机发布如果你只有一台机器最简单的零停机方案是端口错开的手动滚动更新先在宿主机上用另一个端口启动新版本容器比如-p 8081:8080验证新版本健康检查通过之后再把网关或者负载均衡的流量切到新端口最后停掉旧容器。这个过程业务不中断但操作比较繁琐。如果用了 Docker Compose 且没有做负载均衡docker compose up -d会先创建新容器再停止旧容器中间有一个极短的重叠窗口。只要服务本身的优雅停机做好了——比如 Spring Boot 的server.shutdowngraceful配置——用户基本感知不到重启。5.2 如何优雅地回滚到旧版本回滚这件事不要太依赖临时操作要在部署时就把回滚路径留好。最保险的做法是保留上一版本的镜像回滚时只要把 Compose 文件里的镜像版本号改回去重新执行docker compose up -d或者手动方式docker stop myapp-container docker rm myapp-container docker run -d --name myapp-container ... myapp:1.2.3这里有一个关键细节回滚到旧版本容器时数据库结构可能已经升级了。如果新版上线时执行了数据库迁移回滚代码版本不一定能兼容新的表结构。所以生产环境的回滚验证不能只看容器能不能起来还要跑一遍核心业务流程确认前后端和数据库的兼容性。我在实际项目里吃过这个亏新版本加了字段并执行了迁移回滚后发现旧版本代码查询时因为这个新字段的约束报错最后只能让数据库团队配合调整。回滚预案里必须包含数据库兼容这一项。5.3 健康检查是发布安全的最后一道防线不管是手动部署还是 Compose 部署新容器拉起来后都要有判断标准的检查手段。Java 服务最常见的做法是暴露 Spring Boot Actuator 的健康检查接口management: endpoints: web: exposure: include: health,info容器层面可以配合HEALTHCHECK指令HEALTHCHECK --interval30s --timeout5s --retries3 \ CMD curl -f http://localhost:8080/actuator/health || exit 1注意很多精简版 JRE 基础镜像没有 curl可以改用 Java 自带的能力或者直接在启动脚本里用wget无论如何健康检查接口必须在发布流程里作为一个强制验证步骤。6. 常见问题与排查技巧实录最后这部分是我的实战记录整理出重新部署 Java 容器时最容易遇到的几个问题每个都附上排查思路和解决方案。6.1 端口被占用导致新容器启动失败现象docker run报错port is already allocated。排查思路# 查看哪些容器占用了这个端口 docker ps | grep 8080 # 或者用系统命令检查 lsof -i :8080如果是旧容器还在运行按流程停掉并删除即可。如果宿主机上有其他非 Docker 进程占用比如你之前用java -jar起的服务还没停那要先处理掉那个进程。这里还要提醒一种少见但真实存在的情况服务已经切到 Docker但之前的 nohup java 进程没杀干净端口一直被占用新容器死活起不来。遇到这类问题先用ps -ef | grep java排查宿主机上是否有残留的 Java 进程。6.2 容器启动了但立刻退出现象docker run -d执行成功但docker ps里看不到容器docker ps -a里显示Exited (1)。排查思路看日志是第一步。docker logs myapp-containerJava 容器启动后立刻退出的常见原因有几类启动命令写错了比如 Dockerfile 里ENTRYPOINT [java, -jar, app.jar]但 jar 路径不对报Unable to access jarfile。环境变量缺失数据库连接失败Spring 启动中断。端口被容器内其他进程占用不太常见但 Spring Boot 如果配置了两个相同的端口监听也会启动失败。内存不足被 OOM killer 杀掉docker inspect里的OOMKilled字段会是true。6.3 时区不对导致日志时间差了八小时这是个经典的 Java 容器问题。默认的官方 JRE 镜像时区是 UTC日志里打印的时间和本地时间差 8 个小时排查线上问题的时候特别容易产生误导。解决方案有两个在启动命令里挂载时区文件docker run -d \ -v /etc/localtime:/etc/localtime:ro \ -e TZAsia/Shanghai \ myapp:2.0.0或者在 Dockerfile 里直接设置ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime echo Asia/Shanghai /etc/timezone对于基于 Debian 的镜像ln -snf这种方式最稳。我建议直接在基础镜像层面把时区问题解决掉因为每次挂载-v /etc/localtime在 Windows 和 Mac 的 Docker Desktop 上有时会有兼容问题而镜像内设置时区在所有平台都表现一致。6.4 重新部署后配置没生效现象代码明明改了配置明明更新了但新版容器起来后行为还是旧的。排查方向有两条。第一确认你有没有在构建镜像前把代码重新打包mvn clean package之后target下的 jar 如果没刷新docker build会用旧的产物。第二确认配置来源Spring Boot 的配置优先级是启动参数、环境变量、外部配置文件、jar 内配置文件依次降低如果你容器里同时挂载了一个application.yml到/app/config而它和你代码里新定义的配置有冲突那挂载文件会覆盖 jar 内的默认配置。我处理过一个具体案例运维在宿主机/opt/app/config/application.yml里维护了一份数据库连接配置用-v挂载进容器后来我改代码在 jar 内配置了新的 Redis 地址结果 Redis 还是连的旧的排查半天才发现是被挂载文件覆盖了优先级。这种问题靠肉眼很难发现需要查看容器内的实际配置docker exec myapp-container cat /app/config/application.yml6.5 排查问题时定位不到当前运行的镜像版本生产环境出问题了第一个问题永远是现在线上跑的是哪个版本。如果镜像标签管理混乱排查就会卡在第一步。推荐做法是每次部署后把版本信息主动暴露出来。在 Spring Boot 的application.yml里配置info: app: version: project.version再配合 Actuator 的 info 接口访问/actuator/info就能看到当前运行程序的版本号。这样不管容器怎么漂移只要服务还活着就能确定版本。同样的信息在暴露到外部可能有安全风险建议只在内网环境开启或者用 Spring Security 做限制但作为内部排查手段价值非常大。6.6 Docker 磁盘空间被镜像和日志占满长期频繁发版宿主机磁盘会被一堆旧镜像、旧容器和容器日志填满。最直接的影响是容器写日志报no space left on device服务随即异常。第一时间排查df -h docker system df清理策略# 删除停止的容器 docker container prune -f # 删除悬空镜像 docker image prune -f # 清理所有未使用资源 docker system prune -f注意docker system prune会删除所有未被容器引用的镜像包括你还没推送到远程仓库的本地镜像执行前确认是否需要保留。容器日志文件默认存在/var/lib/docker/containers/id/*-json.log长时间运行下来可能膨胀到几个 GB一般通过配置 Docker daemon 的log-opts限制单容器日志大小{ log-driver: json-file, log-opts: { max-size: 20m, max-file: 5 } }配置完需要重启 Docker daemon 才生效所以这个动作最好在维护窗口期做。7. 我自己的部署习惯分享给你干这行这么些年我对部署这件事最大的体会是流程一定要脚本化、参数要显性化不要依赖人的记忆。哪怕是一个单 Java 服务的个人项目我也推荐把docker run那一长串参数固化成一个deploy.sh脚本版本号作为参数传进去#!/bin/bash IMAGE_VERSION$1 docker build -t myapp:${IMAGE_VERSION} . docker stop myapp-container || true docker rm myapp-container || true docker run -d \ --name myapp-container \ -p 8080:8080 \ -v /host/app/logs:/app/logs \ -e SPRING_PROFILES_ACTIVEprod \ myapp:${IMAGE_VERSION}发布的时候只要执行./deploy.sh 2.0.0避免每次重新输入命令时漏掉某个挂载或环境变量。还有一个小技巧值得分享在新版本容器启动命令里加上--health-cmd配合 Shell 脚本做发布后的自动健康检查脚本里如果连续几次健康检查失败就自动执行回滚。这套东西实现起来不难但能显著降低深夜发布时的手忙脚乱。生产环境的核心诉求永远是稳定和可回滚理解了容器部署的原理把这些流程固定下来你就能从每次发版都提心吊胆变成发版只是走个过场。
作为一个常年跟容器化部署打交道的Java开发我太清楚这个场景了项目早期用的是java -jar直接裸机启动后来上了 Docker把 Spring Boot 服务打进了镜像运维和部署确实省心不少。但等到真要发新版本的时候不少人会卡住——旧容器还在跑着端口占着镜像也堆了一堆不敢随便停也不知道正确的更新流程到底该怎么走。这篇文章就是专门解决这个问题的我会从检查当前部署状态讲起把重新部署的完整流程、背后原理、常见坑全部捋一遍适合已经用 Docker 部署过 Java 服务、但还没系统整理过发布流程的开发者参考。1. 先搞清楚你现在的部署形态再谈重新部署很多人一上来就急着执行命令结果旧容器没停干净新容器起不来服务直接中断。重新部署第一步不是敲命令而是先花两分钟搞清楚当前服务是怎么部署的。1.1 查看正在运行的容器和镜像打开终端先执行docker ps看当前到底有哪些容器在跑。这一步能确认几个关键信息容器名是什么、映射了哪些端口、镜像用的是哪个版本。docker ps输出大致长这样CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a1b2c3d4e5f6 myapp:1.2.3 java -jar app.jar 2 weeks ago Up 2 weeks 0.0.0.0:8080-8080/tcp myapp-container这里面IMAGE列的myapp:1.2.3是当前运行的镜像版本NAMES列的myapp-container是容器名这俩后面都要用。再执行docker images看看本地都有哪些镜像尤其是同一个服务的历史版本占了多大空间docker images顺便用docker inspect myapp-container查看容器的详细配置重点看Mounts挂载了哪些卷、NetworkSettings.Ports端口映射和RestartPolicy重启策略这些信息决定了你重新部署时要复刻哪些参数。1.2 确认部署方式单容器还是编排工具重新部署的步骤完全取决于你当初是怎么起的容器常见的有三种直接用docker run启动的单容器部署脚本可能就是几行 shell。用docker-compose.yml定义并启动的多服务组合比如 Java 服务加 MySQL、Redis。生产环境用 Kubernetes 这类编排平台管理的容器由 Deployment 对象控制。如果你用的是 Docker Compose那重新部署会简单很多因为docker-compose.yml里已经把端口映射、环境变量、数据卷、网络都固化好了改版本号就行。如果是裸docker run启动的你就得手动把启动参数完整地记下来或者在docker inspect里逐个对照。我有一个建议哪怕只是单容器部署也尽量写成 Compose 文件。这样以后每次发版不用回忆当初用了什么参数改一行镜像版本号就能重新部署这是我在实际项目里踩过坑之后总结出来的最实用的改进。2. 发新版本前的准备工作重新部署不只是重新跑一个容器那么简单尤其是 Java 服务牵扯到构建产物、镜像版本、数据卷、依赖服务提前准备能省掉大量翻车时间。2.1 构建新镜像之前先做好版本标记Java 服务的代码改完、测试通过之后第一步是打包一般用 Maven 或 Gradle 生成新的 jar/war 包mvn clean package -DskipTests然后写一个合理的 Dockerfile。这里强烈建议镜像标签不要一直用latest而是用带版本号的标签比如myapp:2.0.0。原因很现实latest虽然每次构建都覆盖但你无法从生产环境的容器上直观地看出当前跑的是哪个版本出现问题时排查难度会变大。我见过不止一次生产环境事故查了半天才发现线上还是上个版本的镜像就是因为大家习惯了覆盖latest。推荐的镜像标签规则场景推荐标签说明正式发版myapp:2.0.0版本号清晰可回溯测试环境myapp:dev-20250115带上日期知道构建时间临时验证myapp:pr-123对应具体的合并请求构建命令很简单docker build -t myapp:2.0.0 .如果构建机器和部署机器不是同一台构建完还要推送到镜像仓库docker push registry.example.com/myapp:2.0.02.2 备份当前数据和镜像很多 Java 服务的状态不只存在数据库里还可能会有上传文件、日志、临时文件写在容器内的某个路径。如果你当初启动容器时没有把这些路径挂载到宿主机那容器一删数据就全没了。所以重新部署前先检查数据卷的挂载情况docker inspect myapp-container | grep -A 10 Mounts如果Mounts里有类似/host/data:/app/data这种映射说明数据在宿主机上删容器不影响数据这是安全的。如果容器里确实有需要保留但没挂载的数据目录先把它复制出来docker cp myapp-container:/app/data ./backup-data另外旧镜像也建议保留一份或者至少记下当前镜像的 hash。万一新版本有严重问题你要回滚到旧版本有旧镜像在手就能秒级恢复docker tag myapp:1.2.3 myapp:rollback-1.2.32.3 确认依赖服务的兼容性Java 服务发新版往往不光是 Java 代码变了依赖的 MySQL、Redis、MQ 也可能需要同步调整。重新部署 Java 容器之前先对照一下数据库有没有新增表、有没有 SQL 迁移脚本要执行Redis 的 key 结构有没有变化消息队列的 topic 有没有改名。最常见的翻车现场是新版 Java 服务启动后连不上数据库报Access denied或者表不存在。原因多半是代码里改动了数据库连接配置但容器环境变量没同步更新。所以发布前一定要把配置差异列出来比如SPRING_DATASOURCE_URL、SPRING_DATASOURCE_PASSWORD这些环境变量的新旧值都核对一遍。3. 重新部署的标准操作流程准备做完了下面进入正题。这里我给出一套在我多个项目里验证过的流程每一步都能直接复制执行。3.1 方式一单容器手动重新部署这是最基础的方式适用面最广也最容易理解。整套流程可以用四步概括构建新镜像、停旧容器、删旧容器、起新容器。首先构建新镜像如果跑在部署机上docker build -t myapp:2.0.0 .然后停止并删除正在运行的旧容器docker stop myapp-container docker rm myapp-container注意docker stop不会删除容器只是发送停止信号。停止后容器还是存在的所以要执行docker rm才能真正删掉。如果缺了这一步直接docker run同名容器会报 name already in use 错误。最后启动新容器。启动参数要和旧容器保持一致尤其是端口映射、数据卷、环境变量docker run -d \ --name myapp-container \ -p 8080:8080 \ -v /host/app/logs:/app/logs \ -v /host/app/data:/app/data \ -e SPRING_PROFILES_ACTIVEprod \ -e SPRING_DATASOURCE_URLjdbc:mysql://... \ --restart always \ myapp:2.0.0启动之后确认状态docker ps | grep myapp-container docker logs -f myapp-container看到日志输出Started Application in X seconds这类信息说明服务启动成功了。再用接口测一下curl -s http://localhost:8080/actuator/health3.2 方式二Docker Compose 重新部署如果项目用的是 Compose重新部署的步骤会大幅简化。你只需要做两件事修改镜像版本号然后执行更新命令。假设docker-compose.yml长这样version: 3.8 services: app: image: myapp:1.2.3 container_name: myapp-container ports: - 8080:8080 volumes: - /host/app/logs:/app/logs - /host/app/data:/app/data environment: - SPRING_PROFILES_ACTIVEprod restart: always发新版本时把image: myapp:1.2.3改成image: myapp:2.0.0然后执行docker compose up -d这个命令会对 Compose 文件里定义的服务做一次状态对比发现镜像版本变了就会先创建新容器、停掉旧容器然后把新容器拉起来。它所做的工作就等于手动方式里的docker stop、docker rm、docker run三步只是由工具自动完成了。如果新镜像在远程仓库需要先拉取docker compose pull docker compose up -d用 Compose 还有一个好处如果你同时定义了 MySQL、Redis 等依赖服务docker compose up -d只会重建发生变化的容器依赖服务不受影响。这在手动管理多个容器时是不容易做到的。3.3 为什么必须先删除旧容器才能启动新容器这里展开讲一下原理理解了之后你就不容易在流程上出错。Docker 的容器名是宿主机级的唯一资源。容器本身是一个可读写层叠加在镜像上的运行时实例而名字是对这个实例的引用。当docker run指定了--name myapp-container时Docker 会在本地 namespace 里注册这个名字。如果同名容器还存在于容器列表中哪怕它已经停止了Docker 也会拒绝创建新容器报错信息是docker: Error response from daemon: Conflict. The container name /myapp-container is already in use by container xxxx.... You have to remove that container (or rename) before you can reuse that name.所以流程上必须先docker rm把旧容器的元数据和可写层清理干净才能创建同名的新容器。这也是为什么我在上面的流程里特别强调了docker rm不能省。3.4 更新后如何处理旧镜像新容器跑起来之后宿主机上会残留旧镜像和旧容器如果你没有删干净。用docker ps -a可以查看所有容器包括已退出的docker ps -a那些已经停止且确认不再需要的旧容器可以清理掉docker container prune旧的镜像如果不再需要回滚也可以删除释放磁盘空间docker rmi myapp:1.2.3如果镜像堆积太多想一步清理未被任何容器使用的悬空镜像docker image prune这里我特别提醒一下先确认新版本稳定运行了再去删旧镜像。我刚接手一个项目时图省事在发完新版本当天就把旧镜像删了结果第二天发现新版本有个隐蔽的内存泄漏想回滚旧版本发现镜像没了只能重新构建耽误了小半天。正确的做法是保留旧镜像至少两到三个版本磁盘不够了再按时间优先级清理。4. 部署背后的关键原理镜像、容器与数据卷的关系很多人命令能跑通但遇到意外就懵根因是不理解容器化部署的几个核心概念。这里花点篇幅把原理讲透。4.1 镜像是只读模板容器是运行实例可以把镜像理解成一个打包好的安装盘里面包含了 Java 运行时、依赖库、应用 jar、配置文件。镜像是不可变的构建完成后内容就固定了。而容器是安装盘安装出来的运行环境它在镜像之上加了一个可写层程序运行产生的日志、临时文件会写在这个可写层里。这个设计带来的直接推论就是容器是脆弱的、临时的删除容器不会影响镜像反过来只修改容器内部的文件而不重新构建镜像重启容器后修改就会丢失因为新容器仍然基于原始的镜像层。很多 Java 开发新手在容器里临时改了application.yml或者把某个 jar 塞进了运行目录然后重启容器发现改动全没了就是因为忽略了这条原理。正确的做法是所有配置变更都要通过环境变量、挂载文件或者重新构建镜像来生效。4.2 数据卷是容器与宿主机之间的桥梁上面提到容器是可写层但可写层有个致命问题容器删除后数据就没了。为了保存日志、上传文件这类业务数据必须用数据卷Volume或绑定挂载Bind Mount。数据卷有两种用法我在实际项目中最常用的是绑定挂载因为它直观docker run -d -v /host/app/logs:/app/logs myapp:2.0.0/host/app/logs是宿主机目录/app/logs是容器内目录。写入容器内/app/logs的任何文件实际都会落在宿主机上。这样即使容器被删掉再重建只要挂载关系不变日志和数据都在。这里有一个极其常见的坑Java 服务如果使用 Logback 日志框架默认往容器内/app/logs写日志但容器启动时没有挂载这个目录日志就写在容器可写层的/app/logs下面。一旦重新部署旧容器被删除日志全部丢失。处理办法有两个一是把日志目录挂载到宿主机二是使用docker logs配合 JSON 文件日志驱动采集。生产环境我建议两者都做挂载目录方便按天归档docker logs在排查启动异常时更直接。4.3 镜像构建的层缓存机制构建新镜像时Docker 会逐条执行 Dockerfile 的指令每一条指令生成一个镜像层。如果这次构建的某一层内容和上次完全相同Docker 会直接复用缓存不重新执行。这个机制对 Java 服务有非常重要的优化空间。看一个典型的 Spring Boot DockerfileFROM openjdk:17-jdk-slim WORKDIR /app COPY target/app.jar /app/app.jar ENTRYPOINT [java, -jar, app.jar]这里的问题在于Java 代码每次改动都要重新打包 jarjar 变了COPY target/app.jar这一层缓存就失效了而这一层之后的层也会全部重建。对于单模块的小项目影响不大但如果是大单体或者多模块项目构建时间会被拖长。更合理的做法是先把依赖层分离出来利用 Maven 的依赖缓存FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /build/target/app.jar /app/app.jar ENTRYPOINT [java, -jar, app.jar]这样改代码的时候pom.xml没变RUN mvn dependency:go-offline这一层就能命中缓存构建时间能明显缩短。我在持续集成环境里实测过这种分层方式能把 Spring Boot 项目的镜像构建时间从五分钟压到一分钟以内。4.4 为什么容器里 Java 服务要关注 JVM 参数Java 服务容器化之后一个被反复讨论的问题是 JVM 参数怎么设置。尤其是没有显式设置-Xmx的 Spring Boot 应用在容器里运行会出现两个极端要么 JVM 认为宿主机内存很大、堆开得过大直接把容器内存打爆要么容器被 cgroup 限制后 JVM 无法正确感知内存上限导致 OOM 被操作系统杀掉。以前 Java 8 的 JVM 默认不识别 cgroup 内存限制会拿宿主机内存作为默认堆大小的依据。Java 10 之后默认开启了UseContainerSupportJVM 能感知到容器限制行为正常很多。但即便如此我依然建议在启动参数里显式指定内存java -Xms256m -Xmx512m -jar app.jar对应的 DockerfileENTRYPOINT [java, -Xms256m, -Xmx512m, -jar, app.jar]或者用环境变量传参ENTRYPOINT [java, -XX:MaxRAMPercentage75.0, -jar, app.jar]-XX:MaxRAMPercentage75.0的意思是使用容器可用内存的 75% 作为堆上限剩余留给 JVM 非堆内存和系统开销这个比例是 Spring Boot 容器最常见的安全配置。有次我接手一个部署在 512MB 限制容器里的服务默认 JVM 堆按宿主机内存设置每次发版后运行几个小时就容器重启改成环境变量传-XX:MaxRAMPercentage之后问题彻底消失。5. 生产环境的发布策略与回滚方案前面讲的是单实例更新命令层面能解决问题。但生产环境往往要求服务不中断这里就需要引入一些更成熟的发布策略。5.1 滚动更新与零停机发布如果你只有一台机器最简单的零停机方案是端口错开的手动滚动更新先在宿主机上用另一个端口启动新版本容器比如-p 8081:8080验证新版本健康检查通过之后再把网关或者负载均衡的流量切到新端口最后停掉旧容器。这个过程业务不中断但操作比较繁琐。如果用了 Docker Compose 且没有做负载均衡docker compose up -d会先创建新容器再停止旧容器中间有一个极短的重叠窗口。只要服务本身的优雅停机做好了——比如 Spring Boot 的server.shutdowngraceful配置——用户基本感知不到重启。5.2 如何优雅地回滚到旧版本回滚这件事不要太依赖临时操作要在部署时就把回滚路径留好。最保险的做法是保留上一版本的镜像回滚时只要把 Compose 文件里的镜像版本号改回去重新执行docker compose up -d或者手动方式docker stop myapp-container docker rm myapp-container docker run -d --name myapp-container ... myapp:1.2.3这里有一个关键细节回滚到旧版本容器时数据库结构可能已经升级了。如果新版上线时执行了数据库迁移回滚代码版本不一定能兼容新的表结构。所以生产环境的回滚验证不能只看容器能不能起来还要跑一遍核心业务流程确认前后端和数据库的兼容性。我在实际项目里吃过这个亏新版本加了字段并执行了迁移回滚后发现旧版本代码查询时因为这个新字段的约束报错最后只能让数据库团队配合调整。回滚预案里必须包含数据库兼容这一项。5.3 健康检查是发布安全的最后一道防线不管是手动部署还是 Compose 部署新容器拉起来后都要有判断标准的检查手段。Java 服务最常见的做法是暴露 Spring Boot Actuator 的健康检查接口management: endpoints: web: exposure: include: health,info容器层面可以配合HEALTHCHECK指令HEALTHCHECK --interval30s --timeout5s --retries3 \ CMD curl -f http://localhost:8080/actuator/health || exit 1注意很多精简版 JRE 基础镜像没有 curl可以改用 Java 自带的能力或者直接在启动脚本里用wget无论如何健康检查接口必须在发布流程里作为一个强制验证步骤。6. 常见问题与排查技巧实录最后这部分是我的实战记录整理出重新部署 Java 容器时最容易遇到的几个问题每个都附上排查思路和解决方案。6.1 端口被占用导致新容器启动失败现象docker run报错port is already allocated。排查思路# 查看哪些容器占用了这个端口 docker ps | grep 8080 # 或者用系统命令检查 lsof -i :8080如果是旧容器还在运行按流程停掉并删除即可。如果宿主机上有其他非 Docker 进程占用比如你之前用java -jar起的服务还没停那要先处理掉那个进程。这里还要提醒一种少见但真实存在的情况服务已经切到 Docker但之前的 nohup java 进程没杀干净端口一直被占用新容器死活起不来。遇到这类问题先用ps -ef | grep java排查宿主机上是否有残留的 Java 进程。6.2 容器启动了但立刻退出现象docker run -d执行成功但docker ps里看不到容器docker ps -a里显示Exited (1)。排查思路看日志是第一步。docker logs myapp-containerJava 容器启动后立刻退出的常见原因有几类启动命令写错了比如 Dockerfile 里ENTRYPOINT [java, -jar, app.jar]但 jar 路径不对报Unable to access jarfile。环境变量缺失数据库连接失败Spring 启动中断。端口被容器内其他进程占用不太常见但 Spring Boot 如果配置了两个相同的端口监听也会启动失败。内存不足被 OOM killer 杀掉docker inspect里的OOMKilled字段会是true。6.3 时区不对导致日志时间差了八小时这是个经典的 Java 容器问题。默认的官方 JRE 镜像时区是 UTC日志里打印的时间和本地时间差 8 个小时排查线上问题的时候特别容易产生误导。解决方案有两个在启动命令里挂载时区文件docker run -d \ -v /etc/localtime:/etc/localtime:ro \ -e TZAsia/Shanghai \ myapp:2.0.0或者在 Dockerfile 里直接设置ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime echo Asia/Shanghai /etc/timezone对于基于 Debian 的镜像ln -snf这种方式最稳。我建议直接在基础镜像层面把时区问题解决掉因为每次挂载-v /etc/localtime在 Windows 和 Mac 的 Docker Desktop 上有时会有兼容问题而镜像内设置时区在所有平台都表现一致。6.4 重新部署后配置没生效现象代码明明改了配置明明更新了但新版容器起来后行为还是旧的。排查方向有两条。第一确认你有没有在构建镜像前把代码重新打包mvn clean package之后target下的 jar 如果没刷新docker build会用旧的产物。第二确认配置来源Spring Boot 的配置优先级是启动参数、环境变量、外部配置文件、jar 内配置文件依次降低如果你容器里同时挂载了一个application.yml到/app/config而它和你代码里新定义的配置有冲突那挂载文件会覆盖 jar 内的默认配置。我处理过一个具体案例运维在宿主机/opt/app/config/application.yml里维护了一份数据库连接配置用-v挂载进容器后来我改代码在 jar 内配置了新的 Redis 地址结果 Redis 还是连的旧的排查半天才发现是被挂载文件覆盖了优先级。这种问题靠肉眼很难发现需要查看容器内的实际配置docker exec myapp-container cat /app/config/application.yml6.5 排查问题时定位不到当前运行的镜像版本生产环境出问题了第一个问题永远是现在线上跑的是哪个版本。如果镜像标签管理混乱排查就会卡在第一步。推荐做法是每次部署后把版本信息主动暴露出来。在 Spring Boot 的application.yml里配置info: app: version: project.version再配合 Actuator 的 info 接口访问/actuator/info就能看到当前运行程序的版本号。这样不管容器怎么漂移只要服务还活着就能确定版本。同样的信息在暴露到外部可能有安全风险建议只在内网环境开启或者用 Spring Security 做限制但作为内部排查手段价值非常大。6.6 Docker 磁盘空间被镜像和日志占满长期频繁发版宿主机磁盘会被一堆旧镜像、旧容器和容器日志填满。最直接的影响是容器写日志报no space left on device服务随即异常。第一时间排查df -h docker system df清理策略# 删除停止的容器 docker container prune -f # 删除悬空镜像 docker image prune -f # 清理所有未使用资源 docker system prune -f注意docker system prune会删除所有未被容器引用的镜像包括你还没推送到远程仓库的本地镜像执行前确认是否需要保留。容器日志文件默认存在/var/lib/docker/containers/id/*-json.log长时间运行下来可能膨胀到几个 GB一般通过配置 Docker daemon 的log-opts限制单容器日志大小{ log-driver: json-file, log-opts: { max-size: 20m, max-file: 5 } }配置完需要重启 Docker daemon 才生效所以这个动作最好在维护窗口期做。7. 我自己的部署习惯分享给你干这行这么些年我对部署这件事最大的体会是流程一定要脚本化、参数要显性化不要依赖人的记忆。哪怕是一个单 Java 服务的个人项目我也推荐把docker run那一长串参数固化成一个deploy.sh脚本版本号作为参数传进去#!/bin/bash IMAGE_VERSION$1 docker build -t myapp:${IMAGE_VERSION} . docker stop myapp-container || true docker rm myapp-container || true docker run -d \ --name myapp-container \ -p 8080:8080 \ -v /host/app/logs:/app/logs \ -e SPRING_PROFILES_ACTIVEprod \ myapp:${IMAGE_VERSION}发布的时候只要执行./deploy.sh 2.0.0避免每次重新输入命令时漏掉某个挂载或环境变量。还有一个小技巧值得分享在新版本容器启动命令里加上--health-cmd配合 Shell 脚本做发布后的自动健康检查脚本里如果连续几次健康检查失败就自动执行回滚。这套东西实现起来不难但能显著降低深夜发布时的手忙脚乱。生产环境的核心诉求永远是稳定和可回滚理解了容器部署的原理把这些流程固定下来你就能从每次发版都提心吊胆变成发版只是走个过场。
