关键不是“让它跑起来”，而是“让它像当年一样跑”：需精准复刻原始运行土壤，包括系统小版本、glibc等库版本、时区locale、路径硬编码等；选centos:6.3等精确镜像，离线还原依赖，绕过容器限制，并验证文件、网络、信号三类行为兼容性。
要让旧版软件在现代系统上稳定运行，关键不是“让它跑起来”，而是“让它像当年一样跑”。Docker 的价值不在于打包便利，而在于精准复刻原始运行土壤——从内核兼容性、系统库版本，到时区、locale、甚至文件路径硬编码行为。
选对基础镜像：版本必须精确到小版本号
很多崩溃源于基础系统差异。比如某财务软件只在 CentOS 6.3 下通过全量测试，但用了 centos:6 这类浮动标签，实际拉取的是 6.10，glibc 升级后直接报错 GLIBC_2.14 not found。
- 登录原服务器执行 cat /etc/redhat-release 或 lsb_release -a，确认发行版及具体小版本
- 优先使用 Docker Hub 官方历史 tag：如 centos:6.3、ubuntu:14.04.6、debian:jessie
- 避免使用 latest、stable 或无小版本后缀的镜像名
离线还原依赖：别指望在线安装能成功
旧软件依赖的 OpenSSL 1.0.2、Python 2.6.6、JDK 6u45 等，在当前仓库中早已下线。在线 apt install 或 yum install 大概率返回 404 或版本不匹配。
- 在同版本旧系统中提前下载完整依赖包：
Ubuntu/Debian：apt-get download libssl1.0.0=1.0.2g-1ubuntu4.20
RHEL/CentOS：yumdownloader --resolve --destdir ./pkgs openssl-1.0.2k-21.el7_9 - Dockerfile 中用 COPY pkgs/ /tmp/pkgs/ + RUN dpkg -i /tmp/pkgs/*.deb 或 RUN rpm -ivh /tmp/pkgs/*.rpm
- 对 C 类工具链（如老 gcc），考虑用 musl-gcc 静态编译，彻底摆脱 glibc 版本绑定
绕过容器默认限制：旧软件不认“容器”这回事
旧程序常假设自己运行在真实物理机，会校验时间偏移、读取 /proc/net/dev、写死 uid=500、依赖 eth0 网卡名……这些在默认容器里都会失败。
- 时间敏感应用：启动加 --cap-add=SYS_TIME，并挂载 -v /etc/localtime:/etc/localtime:ro
- UID/GID 写死：用 user: "500:500" 启动，或 Dockerfile 中 RUN useradd -u 500 legacyuser
- 路径硬编码：用 VOLUME ["/opt/app/conf"] 暴露目录，再通过 -v /host/conf:/opt/app/conf:ro 复用原有配置
- 网络校验：若绑定 eth0，启动时加 --network host；若禁用 IPv6，加 --sysctl net.ipv6.conf.all.disable_ipv6=1
验证是否“真兼容”：启动成功≠运行正确
光看到 Server started 不代表兼容。必须验证三类关键行为是否与原环境一致：
-
文件操作：创建中文名文件、读取 GBK 编码日志、访问
/proc/sys/kernel/shmmax等特定节点 -
网络行为：DNS 是否走原
/etc/resolv.conf、是否因 IPv6 启用导致连接超时、是否依赖特定网卡名 - 信号与退出：用 docker kill -s SIGTERM 测试能否优雅退出；有些老程序需捕获 TERM 并转为 USR2，需在 entrypoint.sh 中处理
复刻旧环境不是技术炫技，而是责任落地。每个版本号、每行 COPY、每次 cap-add，都是对业务连续性的承诺。
