方舟 · Ark

Appearance

Docker部署IIS网站指南 ​

这篇文档针对的是 Windows + IIS 站点 场景，不是主流推荐路线，但在接手旧 ASP.NET Framework 项目、客户环境要求固定、或需要把已有 IIS 发布产物快速打包时，仍然很有参考价值。

1. 先说结论：什么情况下适合用 ​

Docker 化 IIS 网站，适合下面这些情况：

  • 旧版 ASP.NET Framework 项目
  • 运行依赖 IIS，而不是 Kestrel / Nginx
  • 客户环境已经是 Windows Server 体系
  • 想把“发布产物 + IIS 配置”固定进镜像，减少环境漂移

不太适合的情况：

  • 新项目
  • ASP.NET Core 项目
  • 计划跨 Linux / Windows 统一部署

因为：

新项目更推荐直接走 ASP.NET Core + Linux 容器路线。

IIS 容器更多是旧系统过渡方案，而不是首选现代方案。

2. 典型部署思路 ​

这类场景通常不是“在容器里完整搭一个 Windows 服务器”，而是：

  1. 先把网站在本地或 CI 中发布好
  2. 准备 Dockerfile
  3. 用 Windows 基础镜像 + IIS 运行环境构建镜像
  4. 把发布产物拷进去
  5. 在目标机器上运行容器

也就是说，这里容器的角色更像：

把已有 IIS 站点封成一个可复制的运行包。

3. 基础 Dockerfile 示例 ​

下面是一份适合发布产物打包的基础示例：

dockerfile
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022

SHELL ["powershell", "-Command"]

# 根据需要加载 IIS 管理模块
RUN Import-Module WebAdministration; \
    Set-ItemProperty 'IIS:\AppPools\DefaultAppPool' -Name processModel.loadUserProfile -Value true

WORKDIR /inetpub/wwwroot

# 将发布后的站点文件复制到默认站点目录
COPY Publish/ ./

3.1 这份 Dockerfile 做了什么 ​

  • 选择了带 ASP.NET Framework 运行环境的 Windows 基础镜像
  • 通过 PowerShell 执行 IIS 配置
  • 把发布后的站点文件复制到 wwwroot

3.2 什么时候需要再往里加配置 ​

如果你的站点依赖：

  • 自定义应用程序池
  • 特定站点名称
  • 特定端口绑定
  • 额外的 Windows 组件

那就需要继续在 Dockerfile 或启动脚本里补充 IIS 配置。

4. 推荐的目录结构 ​

text
iis-docker/
├── Dockerfile
├── Publish/
│   └── ...                 # 网站发布产物
└── README.md

这里最关键的是：

Publish/ 里放的是已经发布好的站点文件，而不是整个源码仓库。

这能让镜像构建过程更稳定，也更接近真实交付链路。

5. 构建镜像 ​

在 Dockerfile 所在目录执行：

bash
docker build -t my-iis-site:1.0.0 .

经验建议：

  • 标签尽量带版本，不要长期只用 latest
  • 构建目录里不要混入无关文件

如果站点很大，建议同时准备 .dockerignore，避免无关文件进入构建上下文。

6. 运行容器 ​

bash
docker run -d --name my-iis-site -p 8080:80 my-iis-site:1.0.0

然后访问：

text
http://127.0.0.1:8080

6.1 常见运行参数 ​

  • -d：后台运行
  • --name：指定容器名称
  • -p 8080:80：把宿主机 8080 端口映射到容器 IIS 的 80 端口

7. 镜像导出与跨机器部署 ​

这类 IIS 容器一个非常实际的用法，是在一台机器打好镜像，再带去另一台机器运行。

7.1 导出镜像 ​

bash
docker save -o my-iis-site.tar my-iis-site:1.0.0

7.2 导入镜像 ​

bash
docker load -i my-iis-site.tar

然后再执行：

bash
docker run -d --name my-iis-site -p 8080:80 my-iis-site:1.0.0

这个方式适合：

  • 客户现场环境
  • 无公网访问环境
  • 需要离线交付

8. 生产环境要注意什么 ​

8.1 不要把它当成现代化云原生最佳实践 ​

IIS 容器能用，但它更像旧系统迁移和交付方案，不是现代新项目的默认推荐。

8.2 镜像体积会比较大 ​

Windows 容器镜像普遍比 Linux 镜像更重，这是正常现象。

8.3 宿主机版本要匹配 ​

Windows 容器对宿主机版本匹配更敏感，这一点和 Linux 容器不一样。

换句话说：

不要只验证“镜像能 build”，还要验证“目标服务器能 run”。

8.4 配置尽量代码化 ​

如果镜像里还依赖手工点 IIS 管理器做配置，后续就很难复制。

更推荐：

  • 把必要的 IIS 配置写进 Dockerfile
  • 或放进 PowerShell 初始化脚本

9. 这类方案最常见的问题 ​

9.1 站点能启动，但页面 500 ​

优先排查：

  • 发布文件是否完整
  • 运行时依赖是否齐全
  • IIS 应用程序池配置是否符合站点要求

9.2 容器跑了，但外部访问不到 ​

检查：

  • docker ps 是否看到端口映射
  • 宿主机防火墙是否放行
  • 是否把容器 80 端口映射到了宿主机

9.3 本机构建成功，目标机运行失败 ​

重点怀疑：

  • Windows 镜像兼容性
  • 宿主机版本不匹配
  • 容器模式（Windows / Linux）切换错误

10. 什么时候该换路线 ​

如果你正在做的是：

  • 新的 Web 系统
  • 计划长期维护
  • 还希望统一 Linux / Windows 部署

那就别再继续加码 IIS 容器路线了，建议尽早切到：

  • ASP.NET Core
  • Linux 容器
  • Nginx / Kestrel

这条路后续维护成本明显更低。

11. 一句话总结 ​

Docker 化 IIS 网站的价值，不在于“它多先进”，而在于把旧的 IIS 站点交付方式变得更可复制、更可迁移。如果你接手的是 Windows 老项目，这条路线很实用；如果是新项目，就尽量不要再往这条路上走深了。

方舟 · Ark

Copyright © 2026-present WhatHappenin