一、当传统应用遇上现代容器

老张是某银行的系统管理员，他们核心的票据处理系统已经稳定运行了15年——用C++编写，依赖CentOS 6，通过共享库调用打印机驱动。直到某天收到通知：老旧服务器即将退役。这个场景是不是很熟悉？传统应用迁移就像给百年老宅换地基，稍有不慎就会引发系统崩溃。

容器技术此时就像搬家公司的特种集装箱：把房子整体打包搬运，连墙角的蜘蛛网都原封不动。以这个票据系统为例，我们完全可以用Docker保留原有环境：

# 基于原始系统的CentOS 6基础镜像
FROM centos:6.10

# 安装遗留依赖库
RUN yum install -y glibc-2.12 \
    && rpm -ivh printer-driver-legacy.rpm

# 固化环境变量（解决原系统靠/etc/profile配置的问题）
ENV LD_LIBRARY_PATH=/opt/oldlib:$LD_LIBRARY_PATH

# 将编译好的二进制直接放入镜像
COPY ./ticket-system /usr/local/bin/

# 保持原启动方式
CMD ["/usr/local/bin/ticket-system --daemon"]

这个Dockerfile的精妙之处在于：

  1. 严格复现了老系统的glibc版本
  2. 将模糊的"安装过某个驱动"变为明确的rpm包依赖
  3. 把隐式的库路径配置转为显式环境变量

二、拆解复杂依赖的庖丁之术

某物流公司的.NET Framework 4.5应用需要连接SQL Server 2008，还依赖IIS的特定模块配置。通过容器分层构建，我们可以像解剖麻雀般处理这种复杂依赖：

# 第一阶段：构建基础环境层
FROM mcr.microsoft.com/dotnet/framework/runtime:4.5 AS base
RUN Install-WindowsFeature Web-ASP-NET45

# 第二阶段：数据库依赖层
FROM base AS db
SHELL ["powershell", "-Command"]
RUN Invoke-WebRequest -URI "https://old-sql-driver/sql2008.msi" -OutFile C:\sql2008.msi ; \
    Start-Process -Wait -FilePath "msiexec.exe" -ArgumentList "/i C:\sql2008.msi /quiet"

# 最终镜像
FROM base AS final
COPY --from=db /Program\ Files/Oracle/SQL2008/ ./
COPY ./web.config C:/inetpub/wwwroot/

关键技术点解析：

  1. 多阶段构建避免镜像臃肿
  2. 使用Windows容器特有的SHELL指令
  3. 精确复制而非整体迁移

三、那些年我们踩过的坑

给某政府单位迁移Java 1.6应用时，发现容器化后出现随机崩溃。最终定位是JVM对cgroup内存限制的识别问题。解决方案是在启动脚本添加：

#!/bin/bash
# 修正老版本Java对容器环境的支持
JAVA_OPTS="-XX:+UnlockExperimentalVMOptions \
           -XX:+UseCGroupMemoryLimitForHeap \
           -XX:MaxRAMFraction=1"

# 保持与原系统相同的启动参数
exec java $JAVA_OPTS -jar /app/legacy.jar

这类问题有三大典型特征：

  1. 只在容器环境出现
  2. 与系统资源分配相关
  3. 老版本软件对Linux新特性支持不足

四、让旧系统焕发新生

上海某医院的HIS系统通过容器化获得了意外收获：原本需要2小时的回滚操作，现在只需18秒。他们的方案是：

  1. 将Oracle数据库客户端封装为sidecar容器：
services:
  his-system:
    image: his:v3
    depends_on:
      - oracle-proxy
  oracle-proxy:
    image: custom-oracle:11g
    volumes:
      - ./tnsnames.ora:/etc/oracle/
  1. 通过Volume保留动态生成的文件
  2. 使用健康检查实现服务依赖等待

改造前后的对比数据：

  • 部署时间从47分钟降至90秒
  • 系统故障率下降68%
  • 年度硬件成本节省220万

五、选择正确的容器化策略

根据上百个案例经验，我总结出传统应用容器化的四种模式：

  1. 全封装模式
    适合：依赖复杂的单体应用

    docker run --name legacy -v /dev/printers:/dev/printers old-app

  2. 拆分改造模式
    适合：有可分离组件的系统

    # 将数据库访问层独立为微服务
FROM python:2.7
COPY ./db-proxy.py /
EXPOSE 5000

  3. 桥接兼容模式
    适合：必须保留物理设备的场景

    # Nginx配置硬件串口转发
stream {
    server {
        listen 9001;
        proxy_pass /dev/ttyS0;
    }
}

  4. 仿真测试模式
    适合：先验证再迁移的场景

    # 使用QEMU模拟旧硬件
docker run --rm -it qemu-i386 /old-app

六、不可忽视的细节清单

  1. 时区问题：

    RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

  2. 文件权限：

    RUN adduser --system --no-create-home appuser \
 && chown -R appuser /data

  3. 信号处理：

    # Python处理SIGTERM的正确方式
import signal
signal.signal(signal.SIGTERM, graceful_shutdown)

  4. 日志收集：

    logging:
  driver: syslog
  options:
    syslog-address: "tcp://192.168.1.10:514"

七、面向未来的架构设计

某汽车制造商的ERP系统在容器化后，通过添加适配层实现了渐进式改造：

// 新旧系统兼容层示例 (Java技术栈)
public class LegacyAdapter {
    // 将老式JDBC调用转为REST
    @PostMapping("/legacy/order")
    public String createOrder(@RequestBody Order order) {
        LegacySystem.createOrder(
            order.getId(),
            order.getAmount() // 参数转换
        );
        return "success";
    }
}

这种改造带来三个优势：

  1. 新功能可以用现代技术开发
  2. 老系统继续稳定运行
  3. 迁移过程对用户透明

八、写在最后

容器化传统应用就像给古董车装新能源发动机——既要保留经典设计，又要适应现代公路。经过30多个项目的实践验证，我总结出三条黄金准则：

  1. 环境固化优于配置文档
    把"记得配置某个参数"变成Dockerfile里的ENV指令

  2. 最小改动最大兼容
    像考古学家那样对待遗留代码

  3. 留好逃生通道
    始终保持快速回退的能力

当某天你的领导问"这个系统还能撑几年"，你可以自信地回答："在容器里，它能活到领取养老金的那天"