直接用Docker重构旧版ERP系统的核心是封装+解耦+标准化：摸清真实依赖（数据库、系统库、路径），选用兼容基础镜像，配置与数据外置，通过Docker Compose编排多服务协同，不改业务逻辑但大幅提升可迁移性与运维效率。
直接用 Docker 重构旧版 ERP 系统，核心不是“重写”，而是“封装+解耦+标准化”。关键在于把原本紧耦合、强依赖操作系统和本地路径的老系统，变成可独立运行、端口明确、配置外置、数据持久的容器服务。整个过程不改业务逻辑，但大幅提升可迁移性与运维效率。
摸清老系统真实依赖
动手前必须搞清楚三件事：它用什么数据库（Oracle 10g？SQL Server 2005？）、依赖哪些系统级库（如 glibc 版本、JDK 1.6？）、配置文件和数据目录在哪（/opt/erp/conf/？C:\ERP\DATA\？）。很多老 ERP 启动失败，不是镜像没打好，而是启动时缺一个.so文件或找不到 license.dat 路径。建议在原服务器上执行 ldd $(which java)、java -version、ls -l /proc/$(pgrep -f 'erp.jar')/exe 这类命令，把真实运行环境快照下来。
选对基础镜像，宁旧勿新
别盲目用 ubuntu:22.04 或 alpine。旧 ERP 往往卡在 libc、openssl、字体渲染等底层兼容性上。实操中更稳妥的选择是：
- Oracle 10g 类系统 → centos:6.10（glibc-2.12 兼容性最佳）
- Java 1.6/1.7 + Tomcat 6/7 → openjdk:7-jre-slim 或定制 centos:7 + 手动装 JDK
- .NET Framework 3.5 应用 → mcr.microsoft.com/dotnet/framework/runtime:3.5-20220419-windowsservercore-ltsc2019（仅 Windows 容器）
镜像越老，越要验证其安全基线——可通过 trivy image your-image:tag 扫描已知漏洞，必要时打补丁再打包。
配置与数据必须外置
老系统最怕“配置写死在 jar 包里”或“数据库连接硬编码”。重构时务必做到：
- 把数据库地址、账号密码、文件上传路径等全部抽成环境变量，用 -e DB_HOST=db -e UPLOAD_PATH=/data/uploads 传入容器
- 用 volumes 挂载配置目录（如
-v ./conf:/opt/erp/conf）和数据目录（如-v ./data:/opt/erp/data），确保容器重启不丢配置、不丢单据 - 若原系统读取绝对路径的 license 文件，可在 Dockerfile 中用 COPY license.lic /opt/erp/license.lic，再通过启动脚本软链到预期位置
用 Docker Compose 编排依赖关系
单容器跑不起来？老 ERP 常依赖独立的报表服务、消息中间件或认证网关。这时不要硬塞进一个镜像，而是拆成多服务协同：
- 主 ERP 应用（app）→ 暴露 8080，依赖 db 和 redis
- 数据库（db）→ 用 postgres:9.6 或 mysql:5.7，初始化脚本通过 volumes 挂载
./init.sql:/docker-entrypoint-initdb.d/init.sql - 缓存（redis）→ redis:6-alpine，禁用 AOF 避免老系统不兼容
- 反向代理（nginx）→ 处理静态资源、HTTPS 终止、URL 重写（比如把 /erp/* 转发给 app）
这样既保留原有架构逻辑，又获得一键启停、日志统一收集、资源限制等现代运维能力。
