.NET 的构建和发布方式这两年的变化确实有点大。系列前两篇我聊过统一产物目录和新版 SDK 在增量构建上的调整本来以为至少能消停一段时间没想到真正动刀最狠的反而是容器镜像这条链路——以前离不开 Dockerfile 和构建守护进程的事现在直接折叠进dotnet publish一步完成。这篇我打算放开讲一讲如果你手上是 .NET 8 以后的代码库尤其是微服务、中间件、API 网关这一类标准服务看完大概率能直接把发布流水线改造掉一截。先说一个最直观的对比。以前要把一个 .NET 服务变成可运行的容器镜像流程大概是项目根目录放一个 Dockerfile里面写好基础镜像、复制发布产物、声明端口和启动命令CI 里要安装 Docker CLI有 daemon 的机器直接 build没有 daemon 的机器还得折腾 DinD 或者特权模式构建过程中把整个项目上下文传给守护进程依赖一多构建上下文几百 MB 是常态。而现在同样的目标只需要一条dotnet publish命令不需要 Dockerfile不需要 daemon甚至连本地装了没装 Docker 都不重要。这听起来像营销话术但我第一次在一台完全干净的构建机上跑通之后确实被这套设计折服了。这篇文章不是 SDK 官方文档的翻译而是我在这轮发布方式迁移中的真实记录核心参数怎么用、底层基本机制是什么、落地时哪些坑几乎必踩、以及什么时候应该继续抱着 Dockerfile 不放。想直接照抄命令的往下看想搞明白“为什么能这么玩”的更值得往下看。1. 为什么“内置容器发布”值得单独开一篇1.1 传统发布链路里最容易痛的三个环节先说痛点不然你很难理解这次革新的分量。第一痛是 Dockerfile 的维护成本。一个服务一个 Dockerfile版本稍微一多latest、v1.2、fix-hotfix这类标签就开始打架跨团队协作时有人喜欢把基础镜像固定到具体 digest有人喜欢用大版本标签最终结果往往是“能跑就行”没人敢动。我见过一个内部项目的 Dockerfile 里注释比正式代码还长记录的都是“别动这一行动了就起不来”这类玄学。第二痛是构建机器对 Docker daemon 的依赖。Dockerfile 再好也得有 daemon 来执行。大部分 CI runner 出于安全考虑不开放特权模式于是要么自建 Docker 服务要么用 DinD 镜像要么干脆绕过容器化在宿主机上直接跑发布产物。这些方案都能用但每多一层基础设施就多一层维护成本和故障点。某次构建机磁盘被镜像缓存塞满整条流水线挂了两个小时原因只是“顺手清理一下”这种没有自动化的事。第三痛是构建上下文和网络策略的冲突。docker build会把整个上下文打包上传即使.dockerignore写了也是先收集再过滤而真正拉取基础镜像时daemon 又有自己的镜像源配置和凭据管理。在多团队共用一台构建机的环境里这些配置经常互相踩踏。1.2 这轮革新的核心变化发布命令直接产出 OCI 镜像新方案把这些痛点一次性处理掉。从 .NET 8 SDK 开始dotnet publish内置了容器镜像的构建和推送能力。只要在发布命令里带上容器相关参数SDK 就会自动走一条名为DefaultContainer的发布路径先把项目构建成常规发布产物然后把发布目录直接打包成一个 OCI 镜像并按你的要求推送到目标镜像仓库。关键是这个过程不依赖 Docker daemon。SDK 通过内部的构建任务直接和镜像仓库通信拉取基础镜像的 manifest 和层、把发布产物作为新的一层追加进去、重新组装 manifest、再推送到远端。整个过程不需要本地有 Docker、Podman 或者任何容器运行时。构建机只要满足两个条件能跑dotnet命令能访问目标镜像仓库。这带来的实际好处我在迁移之后体会得特别明显不再需要维护每个项目的 Dockerfile镜像名、标签、仓库地址全部作为发布参数声明CI runner 不需要特权模式不需要预先安装 Docker甚至不需要处理 Docker 凭据的复杂配置发布动作从“构建 容器化”两步变成“一个 publish 动作”流水线的故障排查面大幅缩小。当然这轮革新的边界也很明确它不是要取代传统 Dockerfile 的构建能力而是把“标准 .NET 服务容器化”这件高频事做到了极致简化。理解了这一点后面的选型判断就顺理成章了。2. 动手出镜像核心参数与第一次运行记录2.1 从项目到镜像的最短命令拿一个最常见的 ASP.NET Core Web API 项目举例。假设项目路径是./src/Api/Api.csproj目标框架是net8.0希望产出镜像example-gateway:1.0.0并推送到内网镜像仓库registry.internal:5000最小命令是dotnet publish ./src/Api/Api.csproj -c Release --os linux --arch x64 \ -p:PublishProfileDefaultContainer \ -p:ContainerImageNameexample-gateway \ -p:ContainerRegistryregistry.internal:5000 \ -p:ContainerImageTag1.0.0拆开看每个部分的作用--os linux --arch x64指定运行平台SDK 会根据平台选择对应的运行时标识RID进而决定基础镜像的架构。这是 .NET 8 引入的通用发布参数和容器与否无关但容器发布强烈建议显式写明避免在 macOS 上发布出osx-x64之类没人想要的产物。-p:PublishProfileDefaultContainer触发内置容器发布路径。这个不是某个项目里自定义的 profile 文件而是 SDK 内置的发布配置。-p:ContainerImageNameexample-gateway镜像名也就是仓库里:前面的主体部分。-p:ContainerRegistryregistry.internal:5000目标镜像仓库地址。如果不带端口可以不加端口写registry.internal。-p:ContainerImageTag1.0.0镜像标签。不写的话不同 SDK 版本的默认值可能不一样我习惯每次显式指定。执行完这条命令如果网络和凭据都正常你会看到发布过程里出现“Building container image”之类的输出最后提示镜像推送成功。整个过程里项目目录不需要 Dockerfile构建机也不需要 Docker daemon。2.2 常用参数体系的对应关系除了上面几个实际项目里我经常用到的还有这些参数作用示例ContainerBaseImage覆盖基础镜像默认是官方 aspnet 镜像-p:ContainerBaseImagemcr.microsoft.com/dotnet/aspnet:8.0ContainerRuntimeIdentifier显式指定运行时标识等价于给容器指定平台-p:ContainerRuntimeIdentifierlinux-x64ContainerPort声明容器监听端口类似 Dockerfile 里的 EXPOSE-p:ContainerPort8080ContainerWorkingDirectory设置镜像内工作目录-p:ContainerWorkingDirectory/appContainerUser设置镜像内运行用户-p:ContainerUserapp一个容易混淆的点ContainerPort只做“声明”不会真的帮你改应用监听端口。ASP.NET Core 应用实际监听哪个端口由进程内的环境变量和配置决定。新版官方镜像默认的监听端口是 8080并且默认以非 root 用户运行这也是我在一个服务上把容器内端口写成 80 之后联调失败才记住的。后面专门有坑位讲这个。这里额外提醒一句容器相关参数的 CLI 形态在不同 SDK 版本里有差异。.NET 8 早期的稳定写法绝大多数是 MSBuild 属性形式也就是-p:前缀到了 .NET 9CLI 层面补齐了一部分容器开关写起来更友好。拿不准的时候跑一下dotnet publish --help输出里带container字样的选项就是当前 SDK 支持的。2.3 镜像生成之后怎么验证发布命令执行完如果它是直接推送到仓库的验证起来很直接podman pull registry.internal:5000/example-gateway:1.0.0 podman run --rm -p 18080:8080 registry.internal:5000/example-gateway:1.0.0然后浏览器访问http://localhost:18080看服务是否起来。如果只想在本地看镜像信息不实际运行podman inspect registry.internal:5000/example-gateway:1.0.0重点看两个字段architecture是不是amd64以及ExposedPorts/Entrypoint是否符合预期。因为内置发布过程没有本地容器运行时参与很多第一次接触的人会对“镜像到底长什么样”不放心inspect一下心里的石头就落地了。我在第一次跑的时候还犯过一个低级错误发布机器能访问内网仓库但我的本地开发机不在同一个网络命令倒是成功推到了仓库自己却拉不下来绕了一圈发现是客户端网络问题。建议先确认好“发布机 目标仓库 运行环境”三者的网络关系再决定命令怎么写不然很容易出现“推上去但没人能拉”的尴尬。3. 没有 Dockerfile 之后构建流程发生了什么变化3.1 SDK 是如何在没有 daemon 的情况下“做镜像”的要理解这套机制可以把它想象成一个“无食堂模式的打包工人”。传统 Dockerfile 构建像去食堂打饭你要把菜上下文交给食堂窗口daemon食堂按菜单Dockerfile 指令帮你加工最后给你一份套餐。而内置容器发布更像直接和供应商对接SDK 自己充当打包工人直接向“食材仓库”镜像仓库索取基础镜像把应用发布产物封进一个标准包装OCI layer再贴上标签送到指定地点全程不需要食堂窗口。落到技术层面SDK 做的是这些事根据发布参数确定基础镜像从目标仓库拉取 manifest 和需要的层在本地把基础镜像层解包重组把dotnet publish生成的发布目录作为一条新层写入镜像文件系统组装新的镜像 manifest按ContainerRegistry推送到目标仓库。因为整个过程都是纯 HTTP 文件操作不需要任何容器运行时 API所以“没有 Docker daemon”根本不是障碍。这也解释了为什么 CI runner 不需要特权模式——特权模式解决的是 daemon 的权限问题现在压根没有 daemon。3.2 基础镜像选择与拉取缓存的现实影响默认情况下内置发布会使用mcr.microsoft.com/dotnet/aspnet作为基础镜像具体标签和 SDK 版本有关。这个选择对绝大多数 ASP.NET Core 服务是合理的镜像自带运行时、常用环境变量、健康检查入口开箱即用。但有三个现实影响必须提前心里有数。第一构建机必须能直接访问基础镜像所在的仓库。传统docker build可以在 daemon 侧配置镜像源甚至让 daemon 走一层内部转发内置发布没有这个中转站SDK 是直连仓库的。内网隔离环境如果访问不了默认仓库就必须显式指定ContainerBaseImage把它指到内网镜像仓库里的复制品。这也是我后来在一套离网环境里踩到的主要障碍。第二SDK 会缓存基础镜像的层但缓存位置和 Docker 的/var/lib/docker完全是两套。换句话说传统 Docker 构建积累的镜像缓存对内置发布没有任何帮助内置发布自己的缓存Docker 也看不见。第一次构建大概率比有缓存的传统构建慢因为要给基础镜像层做一次完整的本地解包第二次开始缓存在用户目录里生效速度会明显提升。第三基础镜像的拉取机制对“层”的处理是原子的。如果你自己维护了一个定制基础镜像里面包含了公司根证书、特定时区、常用调试工具那在ContainerBaseImage里直接指过去就行。这也是我推荐的方式把“定制系统环境”这件事前移用传统 Dockerfile 产出一个内部基础镜像让每个服务的构建都变得无比干净。3.3 本地没 Docker 也能构建这点在 CI 里格外值钱“没有 Docker 也能构建镜像”这个特性在 CI 里的价值怎么强调都不过分。很多团队的 runner 不开放 Docker daemon以前要么在流水线里嵌套 DinD要么安装一堆 Docker 组件现在只需要一个 .NET SDK 和一个网络位置。我见过的最典型场景是一个内部流水线平台runner 以临时容器方式运行本身不允许再嵌套容器。以前 .NET 服务的镜像构建只能放在另一台专用构建机上发布流程割裂成“代码构建”和“镜像构建”两套系统。切到内置发布之后整个流水线收拢成一条runner 拿到代码装上 SDK执行dotnet publish镜像直接落到仓库。后续部署系统只需要从仓库拉取。当然没有 daemon 意味着你也失去了 daemon 附带的一些便利比如docker login之后 SDK 有时需要读取 Docker 的凭据文件才能推送私有仓库。没有 Docker CLI 的机器要么手动准备凭据文件要么用环境变量把凭据传给发布过程。这个话题在 CI 章节里细说。4. 落地时最容易踩的坑和绕行方案4.1 私有镜像仓库的认证与自签名证书内置发布没有docker login过程帮你管理凭据它默认会尝试从常见的 Docker/Podman 凭据配置里读取已登录的认证信息。所以最简单的方案是在构建机上先执行一次docker login或podman login把凭据持久化下来后续构建直接复用。但这个方案有几个边界要绕一是凭据过期。CI 用的临时 runner 往往是每次全新环境登录态根本不存在。这时候不能靠交互式登录建议把用户名和密码通过 CI 平台的密钥变量注入环境变量再由发布命令读取。不同 SDK 版本对凭据参数的支持不同最稳妥的做法是查当前 SDK 的dotnet publish --help里container-registry-username、container-registry-password这类选项。二是自签名证书问题。内网私有仓库经常使用自签证书传统 Docker 可以在 daemon 配置里加上insecure-registries但内置发布不读 daemon 配置它用的是 .NET 自己的 HTTP 栈。也就是说构建机会直接用系统信任库去验证仓库 TLS 证书。遇到x509: certificate signed by unknown authority这类错误时正确做法是把仓库证书导入构建机的系统信任区而不是把某个“跳过校验”开关打开——后者在传统 Docker 里都已经是高危操作在无 daemon 的场景里更是没有任何等价位置。4.2 端口、环境变量和用户空间的默认值差异这是我迁移过程中唯一一次线上事故级别的踩坑。项目里有个服务部署文件写的是容器端口 80 映射到宿主机 8080老镜像一直这么跑没问题。切到内置容器发布之后服务怎么拉都连不上。排查到最后发现新版 aspnet 基础镜像默认监听 8080并且默认使用非 root 用户运行我把它当成老镜像去用部署文件里又硬编码了 80端口自然对不上。这个教训拆成两点第一构造镜像时如果用到ContainerPort最好和应用的监听端口保持一致别只写一个“看起来合理”的数字。第二部署层的端口映射要显式写清楚“宿主机端口:容器内端口”容器内端口不要想当然。如果你希望应用监听一个固定端口最可靠的做法是在应用代码或环境变量里把ASPNETCORE_URLS或ASPNETCORE_HTTP_PORTS定死这样不管基础镜像默认值怎么变容器启动行为都是稳的。至于“默认监听 8080”这件事我用的 SDK 版本生成出来的镜像就是如此但不同基础镜像版本可能有差异建议实际podman run之后看一眼启动日志里的监听地址而不是信任何一篇博客的判断包括我这篇。4.3 离网环境的镜像基础层预置有些环境完全无法访问外网但dotnet publish又需要拉取基础镜像。传统 Docker 只要把基础镜像提前docker pull到镜像仓库daemon 构建时直接复用本地层就行内置发布没有 daemon它仍然需要通过网络访问镜像仓库的 manifest。绕行方案也不算复杂找一个有网络权限的构建机把基础镜像从默认仓库拉下来再推送到内网镜像仓库docker pull mcr.microsoft.com/dotnet/aspnet:8.0 docker tag mcr.microsoft.com/dotnet/aspnet:8.0 mirror.internal/base/dotnet-aspnet:8.0 docker push mirror.internal/base/dotnet-aspnet:8.0然后在内网发布命令里显式指定dotnet publish ./src/Api/Api.csproj -c Release --os linux --arch x64 \ -p:PublishProfileDefaultContainer \ -p:ContainerBaseImagemirror.internal/base/dotnet-aspnet:8.0 \ -p:ContainerImageNameexample-gateway \ -p:ContainerRegistryregistry.internal:5000这期间有个隐藏的依赖关系SDK 自己的一些组件可能需要 NuGet 包源可达。虽然内置容器发布是 SDK 自带的但首次使用或新版本升级时构建过程的组件解析也可能触发包下载。离网环境建议同时把 NuGet 离线源和镜像仓库基础层预置都做好才能保证发布链路完全自洽。4.4 什么时候应该继续保留 Dockerfile再好的革新也有边界。如果你的镜像需要经历以下任何一步内置发布目前还替代不了 Dockerfile需要RUN apt-get install安装系统级依赖比如某些原生库、字体库、ODBC 驱动需要拷贝项目目录之外的文件比如统一签发的客户端证书、额外的 CA 证书需要多阶段构建比如先编译前端、再执行代码生成、最后把多个阶段产物合并需要在镜像里写入自定义启动脚本、健康检查脚本而不只是简单的ENTRYPOINT。在这些场景里我建议的不是“硬切”而是“分层”。把定制环境的部分做成一个独立的自定义基础镜像由传统 Dockerfile 负责产出服务本身的镜像继续用内置发布把ContainerBaseImage指向这个自定义基础镜像。这样既享受了内置发布的简洁又不牺牲 Dockerfile 的灵活性。后面我还会再展开这个混合路线的经验。5. 把内置发布接入现有 CI/CD 流水线5.1 两种可行的认证方式内置发布推送到私有仓库时的认证实操中我主要用两种方式。方式一runner 上保留 Docker/Podman 的登录态。在流水线里安排一个“登录镜像仓库”的步骤手动执行docker loginSDK 在推送时自然读取到凭据。优点是命令直观复用你已有的运维习惯缺点是需要 runner 有 Docker CLI哪怕环境本身没有 daemon光“登录”这个动作也得有个 CLI 才能执行。方式二彻底不装 Docker CLI直接把凭据通过环境变量或命令行参数传给发布过程。具体参数名以 SDK 的--help输出为准但思路是一致的用户名和密码从 CI 平台的密钥管理里读取以环境变量形式拼进命令。这种方式最适合“runner 尽可能干净”的安全要求缺点是要在处理凭据的细节上多花点时间。两种方式我都有过生产使用。如果团队基础设施比较传统方式一迁移成本最低如果安全规范严格、runner 需要无状态化方式二更合适。不管哪种密码都不应该明文出现在流水线文件里用 CI 平台的 secret 变量是底线。5.2 一个可直接照抄的流水线任务序列假设你用的是一个通用 CI 平台任务大致长这样伪代码steps: - name: Checkout checkout: true - name: 安装 .NET SDK run: 安装脚本或预装镜像自带 - name: 登录镜像仓库 run: docker login $REGISTRY -u $USERNAME -p $PASSWORD - name: 发布并生成镜像 run: | dotnet publish ./src/Api/Api.csproj \ -c Release --os linux --arch x64 \ -p:PublishProfileDefaultContainer \ -p:ContainerImageNameexample-gateway \ -p:ContainerRegistry$REGISTRY \ -p:ContainerImageTag$IMAGE_TAG - name: 镜像安全扫描拉取后扫描 run: | 拉取镜像并用容器安全扫描工具扫描这个序列里真正和“发布方式革新”强相关的只有中间两行登录镜像仓库 dotnet publish。以前有一段需要准备 Dockerfile、处理构建上下文、调用独立镜像构建任务的流程现在全部消失了。$IMAGE_TAG我一般直接用 CI 提供的构建号或提交短哈希保证每次发布都是唯一版本不覆盖旧标签。对内部频繁发布的服务来说这比latest安全得多。5.3 批量发布多个服务的脚本化技巧微服务项目动辄十几个服务每个服务写一大段重复命令很蠢。我的做法是维护一个简单的发布脚本接受服务名和标签两个参数#!/usr/bin/env bash set -euo pipefail PROJECT$1 IMAGE_TAG$2 dotnet publish ./src/${PROJECT}/${PROJECT}.csproj \ -c Release --os linux --arch x64 \ -p:PublishProfileDefaultContainer \ -p:ContainerImageName${PROJECT,,} \ -p:ContainerRegistry$REGISTRY \ -p:ContainerImageTag$IMAGE_TAG${PROJECT,,}是 bash 里把服务名转成小写的技巧避免镜像名里出现大写导致仓库拒绝。真正的流水线里只需要对每个服务调用一次这个脚本publish_service api-gateway 20240601-001 publish_service user-service 20240601-001批量发布还有一个容易被忽略的点所有服务最好使用相同的基础镜像版本和 SDK 版本否则镜像体积和启动行为会不一致。把这些公共属性收敛到一个 Directory.Build.props 或统一的发布参数模板里比在每个命令里写三遍更能避免漂移。6. 性能量级与选型判断这套革新的边界在哪6.1 构建时间与镜像体积的直观体感不吹不黑内置发布的速度受网络影响明显。我自己的体感是这样的仅代表个人环境不构成基准数据传统 Dockerfile 构建时如果 daemon 本地已经有基础镜像缓存整个构建往往很快因为大量层直接复用没有缓存时要从远程仓库拉取全部层速度直接看带宽。内置发布的场景里没有 daemon 帮忙做层复用但 SDK 自己会缓存基础镜像的层。冷缓存首次构建会比有包缓存的传统构建慢热缓存之后差距就很小了。从产物角度看内置发布生成的镜像层数比精心优化的 Dockerfile 要多一些因为它的工序是固定的“基础镜像层 发布产物层”少了几层也无所谓多不出来新问题。镜像体积主要由基础镜像决定官方 aspnet 镜像加应用产物最终大小对内部服务来说完全可接受。我在这里踩过的一个坑是磁盘占用。内置发布的缓存是完整的解包层多个服务反复构建会在用户目录下堆出几个 GB 的缓存。CI runner 如果不定期清理磁盘迟早报警。建议在流水线维护任务里把这一步纳入清理范围。6.2 什么项目最适合切到内置发布根据这些时间的实践我整理了一个选型清单项目类型是否建议切原因标准 ASP.NET Core API / 网关强烈建议没有特殊系统依赖内置发布一步到位Worker Service / 后台任务建议基础镜像选择runtime变体轻量且够用含前端构建的多阶段项目暂缓需要 Dockerfile 的多阶段 COPY / RUN需要系统级依赖的镜像保留 Dockerfileapt-get install阶段无法替代大量微服务、CI 环境受限强烈建议无 daemon 优势明显批量发布体验最好需要极强安全加固的自定义镜像保留 Dockerfile更精细的层控制和审计需求这份清单的底层逻辑只有一条你的发布过程中除了“编译产物 运行环境”之外还有没有额外的“对文件系统的修改动作”有就继续用 Dockerfile没有内置发布就是更高效的选择。6.3 我的个人取舍经验最后分享一点我现在的默认策略。对于由我负责维护的标准服务我已经完全不写 Dockerfile 了镜像统一通过内置发布生成基础镜像固定为官方 aspnet 镜像的某个大版本标签每次发布都用唯一版本号。这样做的好处是任何人拿到代码只要装了 .NET SDK一条命令就能产出和 CI 完全一致的镜像排障效率提升非常明显。对于确实需要定制环境的服务我维护一个独立的“基础镜像构建项目”用传统 Dockerfile 把公司根证书、时区设置、常用诊断工具预装好推送到内网镜像仓库然后服务的发布命令通过ContainerBaseImage指向它。这样一来Dockerfile 在整个组织里从几十份收敛到几份每一份都有专人维护而不是每个服务一份快照。这个混合模式运行了几个月稳定性和开发体验都让我满意。内置容器发布不是把 Dockerfile 彻底消灭而是把“每个服务都要处理容器化细节”这件事做了正确分工标准动作交给 SDK定制需求收敛到少数基础设施。等以后 SDK 如果补上多层构建能力我可能会把最后几个定制基础镜像也并进来——在那之前这个分工就是我眼中最舒服的发布方式。