Dockerfile中.NET发布与COPY交互导致自定义目录缺失的问题咨询

核心成因拆解 #

• 你观察到的目录“消失”现象，和dotnet publish、COPY指令的交互完全没有关联，根因是Docker多阶段构建的文件系统隔离规则。
• 你编写的Dockerfile使用了两个独立的FROM指令，对应两个完全隔离的构建阶段：
  1. 第一阶段名为dev，基于.NET SDK镜像构建，所有在这个阶段执行的mkdir、代码拷贝、dotnet restore、publish操作，都只存在于SDK镜像的临时构建层中。这些临时层在镜像构建完成后会被直接丢弃，不会自动成为最终运行镜像的一部分——除非你在后续阶段通过COPY --from=dev指令显式把需要的文件从这个临时层拷贝走。
  2. 第二阶段是最终真正用来运行容器的镜像，基于轻量化的.NET aspnet 3.1镜像构建，这个阶段你目前只做了三个操作：暴露80端口、从dev阶段拷贝/app/out下的publish产物到当前镜像的工作目录、配置dotnet启动命令。你在dev阶段创建的/app目录（SDK镜像内的独立路径）、/startup目录，从来没有被显式从dev阶段拷贝到这个最终运行镜像里，自然在你docker exec进入运行容器后，在文件系统里找不到对应路径。
• 特别容易被混淆的细节：两个阶段是独立的文件系统，哪怕路径字符串完全相同（比如两个镜像里都存在/app路径），两个路径下的内容也是完全隔离、互不关联的。你在dev阶段操作的/app目录，和最终aspnet镜像自带的/app工作目录，根本不是同一个存储空间，哪怕路径名字一样，也没有任何内容联动。

为什么之前的Dockerfile没出现这个问题 #

你之前编写的不带.NET相关命令的Dockerfile，是单阶段构建逻辑——所有的mkdir、文件拷贝操作都是在最终用来跑容器的同一个镜像层里完成的，这些目录自然会被保留在最终镜像中，不会出现“消失”的错觉。换成多阶段构建后，只要你没有显式把前置构建阶段的目录拷到最终阶段，不管你在前置阶段跑的是mkdir、dotnet publish还是其他任何命令，结果都是一样的：前置阶段操作的所有文件、目录都不会进入最终镜像。

如果需要把这两个目录保留到最终运行容器中 #

只需要在第二阶段的aspnet镜像构建流程中，显式通过COPY指令把对应目录从dev阶段拉取到最终镜像即可，参考修改后的Dockerfile片段：

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
EXPOSE 80
# 拷贝publish生成的应用产物
COPY --from=dev /app/out ./
# 显式拷贝需要保留的目录
COPY --from=dev /app /app
COPY --from=dev /startup /startup
ENTRYPOINT ["dotnet", "MyApp.WebUI.dll"]

小提示：.NET 3.1的aspnet镜像默认就把/app设为了工作目录，你之前把publish产物直接拷到这个工作目录下时，应用文件其实是正常存在、能正常运行的——你在目录树里找不到的，是dev构建阶段那个独立存在的/app路径下的源代码、restore缓存等内容，不是最终镜像自带的、存了应用dll的/app目录，这也是排查时最容易混淆的点。

内容的提问来源于stack exchange，提问作者m.tracey