17370845950

必须启用Release配置发布、匹配SDK与Runtime镜像版本、ENTRYPOINT指向发布后的.dll文件、配置.dockerignore文件。否则会导致镜像臃肿、启动失败或安全风险。

ASP.NET Core项目必须启用发布配置才能正确构建镜像

直接在项目根目录运行 dotnet publish 时若未指定配置，会默认使用 Debug，导致生成的输出包含调试符号、未裁剪的依赖，镜像体积大且存在安全风险。Docker 构建过程应严格使用 Release 配置。

• 确保 .csproj 中未硬编码 DebugType 或覆盖 Optimize；
• Dockerfile 中的 dotnet publish 命令必须显式加 -c Release；
• 若项目引用了 Microsoft.AspNetCore.App 共享框架，发布时需用 --self-contained false（默认行为），否则会打包整个运行时，镜像膨胀数倍。

Dockerfile 多阶段构建必须匹配 SDK 与 Runtime 镜像版本

常见错误是 SDK 镜像用

7.0，而 runtime 镜像写成 6.0，导致 Could not load file or assembly 或启动失败。版本不一致还会引发 TLS、JSON 序列化等运行时行为差异。

• 查看项目 TargetFramework（如 net7.0），以此为准选择镜像标签；
• SDK 阶段用 mcr.microsoft.com/dotnet/sdk:7.0，runtime 阶段用 mcr.microsoft.com/dotnet/aspnet:7.0（不是 runtime，ASP.NET Core 应用需 aspnet 镜像，它内置了 IIS 模块和 HTTPS 支持）；
• 避免使用 latest 标签——它可能跨主版本，破坏确定性。

ENTRYPOINT 必须指向已发布的可执行文件，而非项目文件

写成 ENTRYPOINT ["dotnet", "MyApp.csproj"] 是错的：容器内没有 SDK，且 .csproj 不是可执行体。正确路径是发布后生成的 .dll 文件，且该文件名与项目名一致（除非显式设置了 AssemblyName）。

• 发布命令输出目录（如 ./bin/Release/net7.0/publish/）中的 MyApp.dll 才是入口；
• ENTRYPOINT ["dotnet", "MyApp.dll"] 是标准写法；
• 若应用监听非 http://+:80 地址，需通过 ASPNETCORE_URLS 环境变量覆盖，例如 ENV ASPNETCORE_URLS=http://+:5000；
• 不要在 Dockerfile 中用 CMD 替代 ENTRYPOINT —— 后者更符合 .NET 容器最佳实践，也便于 docker run 传参扩展。

构建时忽略 .git、obj、bin 目录能显著提速并防止敏感泄露

Docker 构建上下文默认上传当前目录所有文件。若未排除 obj/ 和 bin/，不仅拖慢构建，还可能把本地 NuGet 缓存路径、用户密钥等意外打进镜像层。

• 在项目根目录创建 .dockerignore，内容包括：
  

  .git
  bin/
  obj/
  .vs/
  .user
  .env

• 不要在 Dockerfile 中用 RUN rm -rf /app/obj 补救——这些文件早已存在于上层镜像中，无法真正删除；
• 若项目含 appsettings.Development.json，也建议加入 .dockerignore，生产镜像应只保留 appsettings.json 和环境变量驱动的配置。

实际构建命令就是 docker build -t myapp .，但镜像是否精简、能否稳定运行，全取决于上面四点是否被严格执行。最容易被跳过的其实是 .dockerignore 和 runtime 镜像版本对齐——这两个地方出问题，往往表现为容器启动后立即退出，日志里只有 exit code 139 或空白输出。