从‘它怎么又挂了？’到‘服务稳如狗’：我是如何用Docker给老旧.NET应用续命的

从“它怎么又挂了？”到“服务稳如狗”：我是如何用Docker给老旧.NET应用续命的

三年前接手这个项目时，每次半夜被报警短信吵醒，看到“服务不可用”的提示，我的第一反应总是：“它怎么又挂了？”——这是一套运行在Windows Server 2008上的古董级内部系统，依赖着特定版本的IIS和.NET Framework，每次部署都像在拆炸弹。直到去年，我们用Docker完成了容器化改造，现在同事们开玩笑说这服务“稳如狗”。今天就来聊聊这段“拯救大兵瑞恩”式的技术历险。

1. 为什么容器化是老旧.NET应用的救命稻草

那个周五下午，当我第N次蹲在机房给这台老爷机做“心肺复苏”时，突然意识到：环境依赖才是真正的凶手。这套系统需要：

• IIS 7.5（不能多也不能少）
• .NET Framework 4.5.2
• 特定版本的C++运行时库
• 一个早已停止维护的第三方COM组件

更可怕的是，我们的部署文档里写着：“安装完系统后，请手动调整以下15项IIS设置”。这种“祖传配置”就像中世纪炼金术配方，每次新服务器部署都是场豪赌。

容器化带来的三大救赎：

1. 环境固化：把IIS、.NET、COM组件全部打包成不可变镜像
2. 部署标准化：从“手工艺术品”变成可重复的工业化流程
3. 版本控制：每个镜像版本都是可追溯的快照

提示：Windows容器虽然体积较大，但对遗留系统兼容性远胜Linux容器

2. 改造实战：从物理机到容器的惊险跳跃

2.1 选择合适的基础镜像

在Docker Hub上翻找微软官方镜像时，发现版本选择比想象中复杂：

我们最终选择了aspnet:4.8-windowsservercore-ltsc2019这个标签，因为：

• 需要IIS支持
• 保持与旧系统相同的Windows Server 2019内核
• 长期支持版本(LTSC)更稳定

# 基础镜像选择是成功的第一步 FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019

2.2 处理那些“祖传配置”

迁移Web.config时遇到了经典问题：原本直接写在配置文件里的服务器IP和路径。我们的解决方案是：

1. 用环境变量替代硬编码配置
2. 通过Dockerfile的ARG和ENV实现多环境适配
3. 保留原配置作为默认值，确保向后兼容

<!-- 改造前的死亡配置 --> <add key="ReportPath" value="\\192.168.1.100\reports\" /> <!-- 改造后的灵活配置 --> <add key="ReportPath" value="#{REPORT_PATH}#" />

然后在Dockerfile中使用sed进行替换：

RUN powershell -Command \ (Get-Content C:\inetpub\wwwroot\Web.config).Replace('#{REPORT_PATH}#', $env:REPORT_PATH) | \ Set-Content C:\inetpub\wwwroot\Web.config

2.3 搞定顽固的文件权限

那个第三方COM组件有个坏习惯：必须往C:\Program Files\Vendor里写日志。在容器世界里，这相当于在别人家墙上涂鸦。我们的破解方案：

1. 在镜像中创建相同路径的目录
2. 给IIS应用池身份赋予完全控制权
3. 用卷挂载持久化这些“非法建筑”

# 在Dockerfile中添加权限设置 RUN mkdir "C:\Program Files\Vendor" && \ icacls "C:\Program Files\Vendor" /grant "IIS AppPool\DefaultAppPool:(OI)(CI)F"

3. 部署流水线：从“手工耿”到工业化生产

3.1 构建自动化流水线

原来的部署流程：

1. 手动复制文件到服务器
2. 运行5个不同的PowerShell脚本（顺序还不能错）
3. 在IIS管理器里点点点
4. 祈祷不要报错

现在的CI/CD流程：

graph LR A[代码提交] --> B[构建镜像] B --> C[运行测试] C --> D[推送镜像到仓库] D --> E[蓝绿部署]

（实际实现时我们用Jenkins pipeline脚本）：

pipeline { agent any stages { stage('Build') { steps { bat 'docker build -t legacy-app:%BUILD_NUMBER% .' } } stage('Test') { steps { bat 'docker run --rm legacy-app:%BUILD_NUMBER% powershell .\RunTests.ps1' } } stage('Deploy') { when { branch 'main' } steps { bat 'kubectl rollout restart deployment/legacy-app' } } } }

3.2 回滚：时光机器的魔法

以前回滚意味着：

1. 找出上周的备份磁带
2. 花2小时恢复
3. 丢失所有新数据

现在只需要：

# 回滚到上一个版本 kubectl rollout undo deployment/legacy-app # 或者指定历史版本 kubectl rollout history deployment/legacy-app kubectl rollout undo deployment/legacy-app --to-revision=3

4. 那些年我们踩过的坑

4.1 内存泄漏：容器不是虚拟机

最初我们以为容器化能自动解决内存泄漏问题——太天真了。某次半夜服务再次崩溃后，我们学会了：

• 在Dockerfile中设置内存限制
• 使用Windows性能计数器监控
• 配置自动重启策略

# 限制内存为4GB CMD ["powershell", "New-WebAppPool -Name DefaultAppPool; \ Set-ItemProperty IIS:\AppPools\DefaultAppPool -Name processModel -Value @{memoryLimit=4096}; \ C:\\ServiceMonitor.exe w3svc"]

4.2 日志收集：别让容器成为黑匣子

最初几天我们完全不知道容器内部发生了什么，直到建立了ELK日志系统：

1. 用Filebeat收集IIS日志
2. 将应用日志重定向到控制台
3. 使用Docker的日志驱动转发到中央仓库

# 让应用日志输出到stdout RUN Set-WebConfigurationProperty -PSPath 'IIS:\' -Filter 'system.applicationHost/log' \ -Name 'centralLogFileMode' -Value 'CentralW3C'

5. 效果对比：从看护到放养

改造前后的关键指标对比：

最让我欣慰的是，现在可以安心休假了——去年春节七天长假，系统零报警。那些曾经让我夜不能寐的“定时炸弹”，如今在容器里乖巧得像被驯服的野兽。