Docker运行旧版软件的核心是复刻原始运行环境，需精准选择基础镜像、离线还原依赖、绕过容器限制并严格验证行为兼容性。
用 Docker 运行旧版软件，核心不是“打包”，而是“复刻当时的运行土壤”——包括系统版本、库依赖、甚至时区和 locale 设置。关键在镜像构建时精准控制基础环境，而非后期硬凑。
选对基础镜像：别用 latest，要具体到发行版小版本
很多兼容问题源于基础系统差异。比如某老 Java 应用只认 CentOS 6.5 的 glibc 2.12，用 CentOS 7 或 Ubuntu 镜像直接报 GLIBC_2.14 not found。
- 查清原环境：登录老服务器执行
cat /etc/redhat-release或lsb_release -a - 优先使用官方历史 tag：如
centos:6.5、ubuntu:14.04、debian:jessie - 避免
centos:6这类浮动 tag——Docker Hub 上它可能已指向 6.10，而你的软件只在 6.3 下验证过
还原关键依赖：静态编译或离线安装包更可靠
旧软件常依赖特定版本的 Python、OpenSSL、JDK 等，且源已下线或 apt/yum 仓库不再提供。在线安装大概率失败。
- 提前在同版本旧系统中打包依赖：
apt-get download xxx=1.2.3（Debian/Ubuntu）或yumdownloader --resolve --destdir ./pkgs xxx-1.2.3（RHEL/CentOS） - Dockerfile 中用
COPY pkgs/ /tmp/pkgs/+RUN rpm -ivh /tmp/pkgs/*.rpm或dpkg -i /tmp/pkgs/*.deb - 对 C 工具链类软件（如老版 gcc），考虑用
musl-gcc静态编译，彻底摆脱 glibc 版本绑定
绕过系统级限制：权限、时间、路径一个都不能少
旧软件常假设自己运行在真实物理机，对容器默认行为敏感：
-
时间同步：某些金融类旧程序校验系统时间偏移，启动容器加
--cap-add=SYS_TIME并挂载宿主机/etc/localtime -
UID/GID 映射：若软件写死用 uid 500 启动，用
user: "500:500"启动，或在 Dockerfile 中RUN useradd -u 500 legacyuser -
路径硬编码：用
VOLUME ["/opt/legacy/conf"]暴露配置目录，再通过-v /host/conf:/opt/legacy/conf:ro复用原有配置，避免改源码
验证兼容性：别只看“能跑”，要看“跑得对”
启动成功不等于兼容。重点验证三类行为：
-
文件操作：创建带中文名的文件、读取 GBK 编码日志、访问
/proc下特定节点（如旧监控脚本读/proc/net/dev） -
网络行为：是否绑定特定网卡名（如
eth0）、是否依赖 IPv6 禁用状态、DNS 解析是否走/etc/resolv.conf原始配置 -
信号与退出：用
docker kill -s SIGTERM测试能否优雅退出；有些老程序收到 TERM 直接 kill -9，需在 entrypoint 中捕获并转为kill -USR2等自定义信号
旧软件容器化不是技术炫技，而是把一段确定的环境“封存”下来。越早锁定基础镜像和依赖包，后续维护成本越低。真正的兼容，藏在构建阶段的克制里，不在运行时的补救中。
