容器化传统应用，最容易出现的偏差是把容器当成轻量级虚拟机。传统应用往往隐含了大量本地假设：配置文件放在固定目录、日志写入本地磁盘、通过主机名访问数据库、依赖系统服务或定时任务。直接把这些东西塞进镜像，跑起来会出现路径找不到、日志丢失、配置变更需要重新构建等一系列问题。真正有效的改造思路是：先评估应用与运行环境的耦合点，再通过镜像分层、配置外置、日志标准化和发布策略调整，逐步降低对固定环境的依赖。
先做应用画像：判断哪些传统应用适合容器化
并不是所有传统应用都值得第一时间容器化。无状态 Web 服务通常是最容易改造的对象，因为请求不依赖本地会话，实例可以随时销毁重建。比如基于 Spring MVC、Express 或 Django 的常见后台系统，只要把会话信息外置到 Redis 或数据库，就能获得水平扩展能力。相反，有状态服务比如传统关系型数据库、消息队列、文件存储节点，虽然也能跑在容器里，但需要额外处理持久卷、节点亲和性和数据备份问题，如果没有充分准备，不建议作为第一批迁移目标。
在动手写 Dockerfile 之前，可以先对每个应用做一次依赖清单排查。重点看几个方面：配置文件从哪里读取、写入日志的目录是否固定、是否使用了本地临时文件、是否依赖固定 IP 或主机名访问其他系统、是否需要 root 权限启动、是否绑定了固定端口。排查结果可以直接决定后续镜像拆分和编排策略。例如一个 Java 应用如果写死了 /etc/app/config.properties，镜像里又不存在这个文件，启动就会直接失败；如果应用读写本地临时目录，容器重启后数据就会丢失，需要提前改成挂载卷或使用内存文件系统。
| 检查项 | 常见问题 | 改造方向 |
|---|---|---|
| 配置读取 | 写死本地路径或环境变量名不统一 | 改为环境变量或挂载配置目录 |
| 日志输出 | 写入 /var/log/ 下固定文件 | 改为控制台输出或日志采集 sidecar |
| 本地存储 | 使用 /tmp 或本地目录保存业务文件 | 挂载持久卷或接入对象存储 |
| 网络依赖 | 通过固定 IP 访问数据库或服务 | 改为服务名或 DNS 解析 |
| 启动权限 | 使用 root 启动，或需要修改系统配置 | 使用非 root 用户，减少镜像层改动 |
这份清单的价值在于让团队分清哪些改造必须在镜像阶段完成，哪些可以在运行时通过编排平台解决。比如网络依赖问题，最好不要在镜像里写死 IP，而是通过 Compose 或 Kubernetes 的 Service 名称来访问。明确的边界划分可以避免反复修改镜像，也能减少测试环境与生产环境不一致带来的风险。
镜像拆分与配置外置：让同一份镜像适配多个环境
传统应用部署时经常把配置文件和代码包放在一起，每次切换环境就改一遍配置。容器化之后，如果还把配置写进镜像，就会导致开发、测试、生产各有一份镜像，发布链路上容易出现版本混乱。更合理的做法是镜像只包含代码、运行时和默认配置，具体环境差异通过环境变量或挂载文件注入。
一个常见的 Java 应用 Dockerfile 可以这样写：
FROM openjdk:8-jre-alpine WORKDIR /app COPY app.jar /app/app.jar ENV JAVA_OPTS="-Xms512m -Xmx1024m" EXPOSE 8080 CMD ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]
这段 Dockerfile 只声明了默认 JVM 参数和容器端口，并没有把数据库地址、账号密码写进去。运行时可以通过 -e 或 Compose 环境变量覆盖：
docker run -d --name legacy-app \ -p 8080:8080 \ -e DB_URL="jdbc:mysql://db:3306/legacy" \ -e DB_USER="app" \ -e DB_PASS="changeit" \ legacy-app:1.0
如果应用本身不支持环境变量读取，可以采用配置模板加启动脚本的方式。例如镜像里放一个 application.properties.tmpl，启动前用 envsubst 或一段简单脚本生成真实配置文件，再启动主进程。这样既能保持镜像不变，又能兼容旧应用的配置格式。配置挂载也是类似思路，把宿主机或配置中心的配置文件挂载到容器内的指定目录，应用启动时优先读取外部文件。需要注意的是，挂载目录的权限必须与应用运行用户匹配，否则会出现能读取但无法写日志或临时文件的问题。
日志与健康检查：把传统本地日志改成容器可见输出
容器平台默认收集的是标准输出和标准错误流，而传统应用习惯把日志写到 /var/log/app.log 这样的本地文件。如果容器销毁后日志文件没有挂载到持久卷，排障时就会丢失关键信息。短期方案是在镜像入口脚本里启动一个轻量级进程，用 tail -F 跟踪原日志文件并输出到标准输出，但这会引入额外进程管理复杂度，而且多文件配合时容易丢失内容。长期方案还是推动应用日志框架直接输出到控制台，例如 Logback 或 Log4j2 增加 ConsoleAppender，并保持原有文件输出用于本地调试。
健康检查是另一个容易被忽视的改造点。容器进程存在不代表应用已经能够正常处理请求。比如 Java 应用启动可能需要几十秒，期间端口虽然监听但数据库连接池还没有初始化完成。这时如果上游服务已经开始转发流量，就会出现大量请求失败。可以在 Dockerfile 中增加健康检查：
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \ CMD curl -f http://localhost:8080/health || exit 1
这里的 curl 需要包含在镜像中，如果镜像本身没有 curl，可以改用 wget，或者让应用提供一个轻量健康接口，用 Java 自带的方式探活。健康检查的作用不只是告诉编排平台容器是否就绪，它还能在发布过程中帮助判断新版本是否真正可用，减少人工确认成本。
发布与回滚：编排层面的改造节奏
刚开始做容器化，不必一上来就上 Kubernetes。对于传统单体应用，先用 Docker Compose 把应用、数据库、缓存等依赖在单机或测试环境编排起来，验证配置注入、日志收集和健康检查是否生效。Compose 文件里的服务名会自动成为内部 DNS，应用连接数据库时使用服务名而不是固定 IP，这样就完成了网络依赖的解耦。一个简化示例如下：
version: "3.8"
services:
legacy-app:
image: legacy-app:1.0
ports:
- "8080:8080"
environment:
DB_URL: "jdbc:mysql://db:3306/legacy"
DB_USER: "app"
DB_PASS: "changeit"
depends_on:
- db
volumes:
- ./config:/app/config:ro
- app-logs:/var/log/app
db:
image: mysql:5.7
environment:
MYSQL_ROOT_PASSWORD: "rootpass"
MYSQL_DATABASE: "legacy"
volumes:
- db-data:/var/lib/mysql
volumes:
app-logs:
db-data:
Compose 验证通过后，再逐步迁移到 Kubernetes 或其他容器编排平台。此时需要关注的点会更多：Pod 可能被调度到任意节点，所以本地存储必须换成持久卷；服务发现使用 Service 对象，应用内部不需要知道具体节点；发布策略从原来的停机替换变为滚动更新，要求应用能够同时存在新旧两个版本。传统应用如果还依赖本地 Session 或内存缓存，滚动更新可能导致用户被强制退出，需要提前做会话外置和缓存预热改造。
回滚能力同样重要。容器化让回滚变得简单，但前提是镜像标签规范、配置变更可追溯、数据库迁移脚本可以向前兼容。每次发布前保留上一个稳定版本，发布失败时直接通过镜像标签回退到旧版本，不要用 latest 这种不可追溯的标签。对于数据库结构变更，建议采用向前兼容的演进方式：先添加字段或新表，等新版本稳定运行后再清理旧结构，避免因为应用回滚导致数据库不兼容。传统应用的容器化改造是一个渐进过程，每一步都可以独立验证和回退，比一次性重写更稳妥。
容器化改造传统应用迁移Docker Compose修改时间：2026-09-30 10:51:55