在 Visual Studio 中使用相同的 docker 文件构建 docker 映像的 Azure Pipeline 失败答案

【问题标题】：Azure Pipeline to build docker images fails using same docker file in Visual Studio在 Visual Studio 中使用相同的 docker 文件构建 docker 映像的 Azure Pipeline 失败
【发布时间】：2019-10-16 14:45:49
【问题描述】：

我正在尝试创建一个部署管道以将我的映像部署到 Kubernetes 集群。此过程的第一步是基于 docker 文件创建映像。我正在使用的 docker 文件是在我添加 docker 支持时从 Visual Studio 生成的，并在右键单击 docker 图像并选择创建它时成功创建了图像。当我配置 Azure Pipeline 时，创建 docker 映像一旦尝试构建实际解决方案就会失败。上一步抓取了所有源文件，但随后在 docker 镜像创建中失败了

[error]COPY failed: stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:
 no such file or directory

[error]/usr/bin/docker failed with return code: 1

以下是从 Visual Studio 生成的 docker 文件，并被 azure 管道阶段引用以创建 docker 映像。

 FROM mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim AS base

 WORKDIR /app   
 FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS
 build 

 WORKDIR /src      
 COPY ["DockerTest/DockerTest.csproj", "DockerTest/"]      
 RUN dotnet restore "DockerTest/DockerTest.csproj"      
 COPY . .      
 WORKDIR "/src/DockerTest"      
 RUN dotnet build "DockerTest.csproj" -c Release -o /app  

 FROM build AS publish      
 RUN dotnet publish "DockerTest.csproj" -c Release -o /app

 FROM base AS final      
 WORKDIR /app      
 COPY --from=publish /app .      
 ENTRYPOINT ["dotnet", "DockerTest.dll"]

##[section]开始：构建容器镜像
==================================================== ============================ 任务：Docker 描述：构建、标记、推送或运行 Docker 映像，或运行 Docker 命令。任务可以与 Docker 或 Azure 容器一起使用注册表。版本：0.150.6 作者：Microsoft Corporation 帮助： [更多信息]https://go.microsoft.com/fwlink/?linkid=848006)
==================================================== ============================ [命令]/usr/bin/docker build -f
/home/vsts/work/1/s/DockerTest/Dockerfile -t ihacontainers.azurecr.io/dockertest:6 /home/vsts/work/1/s/DockerTest 将构建上下文发送到 Docker 守护进程 6.144kB 步骤 1/15：FROM mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim AS 基础 2.2-stretch-slim：从 dotnet/core/runtime 拉取 743f2d6c1f65：拉取 fs 层 074da88b8de0：拉取 fs 层 ac831735b47a：拉取 fs layer 3adcc844418d: 拉取 fs layer 3adcc844418d: Waiting ac831735b47a：下载完成 743f2d6c1f65：验证校验和 743f2d6c1f65：下载完成 074da88b8de0：验证校验和 074da88b8de0：下载完成 3adcc844418d：验证校验和 zadcc844418d：下载完成 743f2d6c1f65：拉取完成 074da88b8de0：拉动完成 ac831735b47a：拉动完成 3adcc844418d：拉取完整的摘要： sha256:066c31b113b0a20e6155d3bd8a314563c688d2ec31c11d7e551af5bc2595f30c 状态：已下载更新的图像 mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim ---> c0f9ab44ecc1 步骤 2/15：WORKDIR /app ---> 在 6d1a5f5600dd 中运行移除中间容器 6d1a5f5600dd ---> 527fcebeaf1f 步骤 3/15：来自 mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS 构建 2.2-stretch：从dotnet/core/sdk拉c5e155d5a1d1：拉fs层221d80d00ae9：拉fs层4250b3117dca：拉fs层 3b7ca19181b2：拉 fs 层 3466298fc231：拉 fs 层 310737d73ed1：拉取 fs 层 dc981de74fae：拉取 fs 层 3b7ca19181b2：等待 3466298fc231：等待 310737d73ed1：等待 dc981de74fae：等待 4250b3117dca：验证校验和 4250b3117dca：下载完整的 221d80d00ae9：验证校验和 221d80d00ae9：下载完整的 3466298fc231：验证校验和 3466298fc231：下载完整的 c5e155d5a1d1：验证校验和 c5e155d5a1d1：下载完整的 3b7ca19181b2：验证校验和 3b7ca19181b2：下载完成 c5e155d5a1d1：拉取完成 221d80d00ae9：拉取完成 310737d73ed1：验证校验和 310737d73ed1：下载完成 4250b3117dca：提取完成 dc981de74fae：验证校验和 dc981de74fae：下载完成 3b7ca19181b2：拉取完成 3466298fc231：拉动完成 310737d73ed1：拉动完成 dc981de74fae：拉取完整的摘要： sha256:222cc0bb0bc93875ee0f6be626b2838beea838f65e53653e07c33eb9d00b0163 状态：已下载更新的图像 mcr.microsoft.com/dotnet/core/sdk:2.2-stretch ---> e4747ec2aaff 步骤 4/15 : WORKDIR /src ---> 在 a7ebcac87f68 中运行中间容器 a7ebcac87f68 ---> d7541674a9da 步骤 5/15：复制 ["DockerTest/DockerTest.csproj", "DockerTest/"] 复制失败：统计 /var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:no 这样的文件或目录

##[错误]复制失败：stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:no 这样的文件或目录

##[error]/usr/bin/docker failed with return code: 1 ##[section]Finishing: Build a container image

【问题讨论】：

标签： docker azure-devops dockerfile azure-pipelines

【解决方案1】：

我通过使用与 Visual Studio 中相同的 dockerfile 将 buildContext 设置为“$(Build.Repository.LocalPath)”解决了这个问题，而无需调整路径：

在 YAML-Konfiguration 中，我添加了以下行：

buildContext: '$(Build.Repository.LocalPath)'

【讨论】：

这应该是公认的答案。 Pipelines 默认在 Dockerfile 所在的目录（在项目级别）中运行命令，而 Visual Studio 在 Repository/Solution 级别运行它
这对我也有用.. 确保将它放在设置：输入下的 yaml 文件中（无论如何都在天蓝色）。我也在当地为此苦苦挣扎。但结果是一样的.. 指定你的 dockerfile 或根目录的相对路径
你也可以使用 buildContext: '$(Build.SourcesDirectory)'，因为 $(Build.SourcesDirectory) 是 $(Build.Repository.LocalPath) 的同义词。见docs.microsoft.com/en-us/azure/devops/pipelines/build/…

【解决方案2】：

[错误]复制失败：stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj：没有这样的文件或目录

根据这个错误信息，错误发生在你的dockerfile的那一行：COPY ["DockerTest/DockerTest.csproj", "DockerTest/"]。

首先，请确认您没有使用.dockerignore 文件排除此文件：DockerTest/DockerTest.csproj，该文件必须存在于您运行构建的目录中。

如果.dockerignore 文件没有忽略它，那么您需要考虑您的 dockerfile 位置级别。

DockerTest.csproj 文件不应放在较低的源文件路径级别。您需要更改上下文的来源，将其移动到更高的级别。所以手动修改你的dockerfile：

COPY ["DockerTest.csproj", "DockerTest/"]

【讨论】：

所以这确实让我克服了第一个错误，但现在它抱怨它在运行以下命令时没有合适的静态主入口点（当然它确实如此）。运行 dotnet build "DockerTest.csproj" -c Release -o /app
程序不包含适合入口点的静态“Main”方法[/src/DockerTest/DockerTest.csproj]
另一个副作用是现在从 Visual Studio 本地构建 docker 映像失败，因为我们更改了位置。也许有办法在获取源代码时从构建管道中设置正确的位置，这样我就不必修改dockerfile了。
实际上我认为我已修复它并允许它在任一位置工作。我恢复到工作室生成的原始 dockerfile，然后我取消选中构建映像任务上的“使用默认构建上下文”，然后清除它列出的文件夹“DockerTest”。现在整个事情从天蓝色和本地完成。感谢您的帮助。
@Geekn 的最新评论为我解决了这个问题（取消选中使用默认构建上下文）。它应该被添加为答案并标记为最佳答案！

【解决方案3】：

当您通过 Visual Studio（至少 v16.3.9）生成 Docker 支持并且您在 Azure Pipeline 中使用预定义的 Docker 管道模板或在老式的一切点击中使用此生成的项目时，会出现此问题称为经典编辑器的方式或称为现代编辑器的新 4 步易于点击的方式。

生成文件的变化来自

COPY ["DockerTest/DockerTest.csproj", "DockerTest/"]

到

COPY ["DockerTest.csproj", "DockerTest/"]

使用 Azure Pipeline 解决问题，但它会破坏您在 Visual Studio 中的本地构建。

添加

buildContext: '$(Build.Repository.LocalPath)'

现代编辑器生成的 YAML 文件会破坏构建任务。现代编辑器中使用的模板依赖于默认构建上下文，解析器将无法识别buildContext 命令。

解决此问题的唯一可能方法是覆盖默认构建上下文。此覆盖将在 Visual Studio 或 Azure Pipeline 中保留构建功能。

可以在经典编辑器的构建映像任务中覆盖构建上下文。

【讨论】：

您在此处看到的“意外属性 buildContext”错误是由于属性缩进不正确造成的。它需要缩进到与“命令”属性相同的级别
@JeffreyABecker 实际上，这是 YAML 解析器中的一个问题。如果我尝试手动更新文件，解析器会让我这样做，因为无论我把它放在哪里，解析器都会识别出带有构建上下文的行。如果我使用任务 Web 表单，一切正常。

【解决方案4】：

对我来说，它适用于以下 yaml 设置

步骤：

任务：Docker@2

displayName：构建泊坞窗

输入：

命令：'buildAndPush'

Dockerfile: '**/Dockerfile'

buildContext: '$(Build.Repository.LocalPath)'

dockerfile 可以保留为 Visual Studio 生成的。

【讨论】：

【解决方案5】：

就我而言，我的文件夹结构如下：

+-- [REPOSITORY FOLDER]
|   +-- [SOLUTION FOLDER]
|   |   +-- [*.SLN]
|   |   +-- [PROJECT Folder]
|   |   |   +-- [*.CSPROJ]
|   |   |   +-- [dockerfile]

我的 docker 文件在项目文件夹中。
在修改为仅使用第一个副本中的 CSPROJ 文件后，收到缺少的 MAIN 方法错误，没有合适的静态主入口点，我修复了它，将“copy ..”替换为“COPY . [project_name]/”


FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["SampleApi1.csproj", "SampleApi1/"]
RUN dotnet restore "SampleApi1/SampleApi1.csproj"
COPY . SampleApi1/
WORKDIR "/src/SampleApi1"
RUN dotnet build "SampleApi1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "SampleApi1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "SampleApi1.dll"]

【讨论】：

【解决方案6】：

尝试将 Dockerfile 移至根目录，以及 .sln 文件。

其他答案都不适合我，它永远找不到 csproj 文件的项目路径。

我的项目只包含一个需要容器化的项目，还有一些支持dll的项目，所以我把Visual Studio创建的原始Dockerfile和.sln文件一起移到了根目录下，我们的管道构建了镜像并部署了它到我们的 ACR 没问题。

我认为其他解决方案，如果它们对你有用，会更好，但如果不是，它会在你的情况下工作，试一试。

【讨论】：