Azure管道在Visual中使用相同的停靠文件生成码头映像失败

Question

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

[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生成的停靠文件，由azure管道阶段引用，以创建对接器映像。

 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"]

​

​

##sectionStarting:构建容器映像 ==============================================================================任务: Docker描述:生成、标记、推送或运行Docker映像，或运行Docker命令。任务可以与Docker或Azure容器注册表一起使用。作者: Microsoft：More Information) ==============================================================================命令/usr/bin/docker构建-f /home/vsts/work/1/s/DockerTest/Dockerfile ikhaontainers.azure.io/DockerTest:6 /home/vsts/work/1/s/DockerTest将构建上下文发送到Docker守护进程6.144kB步骤1/15 :从mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim作为基础2.2-拉伸-苗条:从dotnet/core/运行时743f2d6c1f65:拉fs层07488b8de0:拉fs层3ccad844418d:拉动fs层3adcc844418d:等待ac831735b47a层3adcc844418d：下载完整的743f2dd6c1f65:验证校验和743f2d6c1f65:下载完整的074da88b8de0:验证校验和074da88b8de0:下载完整的3adcc844418d:验证校验和zadcc844418d:下载完整的743f2d6c1f65:拉出完整的074da88b8de0:拉完整的ac831735b47a:拉出完整的3adcc844418d:拉出完整的Digest: mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim的下载状态：-> c0f9ab44ecc1步骤2/15 : WORKDIR /app ->运行在6d1a5f5600dd中运行的中间容器6da5f5600dd-5fce274dd-5fce271aff 3。/15 :来自mcr.microsoft.com/ dotnet/core/sdk :2.2-拉伸作为构建2.2-拉伸:从dotnet/core/sdk c5e155d5a1d1:拉出fs层221d80d009:拉fs层4250b3117dca:拉fs层3b7ca19181b2:拉fs层3466298fc231:拉出fs层310737d73ed1:拉出fs层dc981de74fae:拉扯层3b7ca19181b2:等待3429668fc231:等待310737d73dca:等待dc981de74fae:验证校验校验4250b3117dca:下载完整22d80d009:校验d22009下载完整代码:c5e155d5a1d1 29834231:下载完整的c5e155d5a1d1 29834231:验证以下内容：验证校验和c5e155d5a1d1:下载完整的校验和3b7ca19181b2:验证校验和3b7ca19181b2:下载完整的c5e155d5a1d1:拉出完整的221d80d00ae9:拉出完整的310737d73ed1:验证校验和310737d73ed1:下载完整的4250b3117dca:拉出完整的校验和dc981de74fae:下载完整的校验和dc981de74fae:下载完整的3b7ca19181b2:拉完成3466298fc231:拉出完整的310737d73ed1:拉完全的dc981de74fae:拉出完整的dc981de74fae:mcr.microsoft.com/doot737ddk/sdk:2.2-拉伸-> e4747ec2aaff步骤4/15 : for KDD-/src> /src -/src->运行在a7ebcac87f68中删除中间容器a7ebcac87f68 --> d7541674a9da步骤5/15 :复制"DockerTest/DockerTest.csproj"，"DockerTest/“副本失败: stat /var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:no这样的文件或目录 stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:no这样的文件或目录 ##sectionFinishing/usr/bin/docker返回代码失败:1 ##sectionFinishing:构建容器映像

Answer 1

stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:失败: errorCOPY没有这样的文件或目录

根据此错误消息，错误发生在您的dockerfile：COPY ["DockerTest/DockerTest.csproj", "DockerTest/"]行上。

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

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

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

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

Answer 2

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

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

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

Answer 3

当您通过Visual (至少是v16.3.9)生成Docker支持时，在Azure管道中用预定义的Docker管道模板使用这个生成的项目时就会出现这个问题，要么使用老式的所有单击方式，即所谓的，即经典编辑器，要么使用新的4步轻松单击方式，即所谓的，现代编辑器。

生成的文件中的更改

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

至

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

解决Azure管道的问题，但是它会破坏Visual中的本地构建的。

添加

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

对于由现代编辑器生成的YAML文件，将中断构建任务。现代编辑器中使用的模板依赖于默认的构建上下文，解析器将不识别( buildContext )命令。

​

​

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

可以在经典编辑器的生成映像任务中重写构建上下文。

​

​