Docker-计算缓存键失败: 未找到-在 VisualStudio 中运行良好

我使用 VisualStudio 生成了一个 Dockerfile。它在 Visual Studio 中运行得很好，现在我尝试从 Windows 本身构建它(docker build .，我尝试了许多组合)。然而，我得到了以下错误:

Error code

当我把副本改为 ./client.csproj时，它继续运行，然后我得到:

Second error with changed copy path

我做错了什么? 我改变 Docker Linux 到 Windows，改变 WSL，并重新启动一切。

Dockerfile 客户端

177458 次浏览
小开

请求不存在的目录将引发此错误。

对我来说，我尽力了

 > [stage-1  7/14] COPY /.ssh/id_rsa.pub /.ssh/:
------
failed to compute cache key: "/.ssh/id_rsa.pub" not found: not found

我忘了将 /.ssh文件夹添加到项目目录。在您的情况下，您应该检查 /client是否真的是 Dockerfile 构建上下文的子文件夹。

小开

在我的案例中，我发现 docker build 在目录名中是区分大小写的，所以我在 COPY 指令中编写/bin/Release/net5.0/Release，但是由于同样的错误而失败，我只是改为/bin/Release/net5.0/Release，并且成功了

小开

检查你的 .dockerignore文件。可能它忽略了复制命令所需的文件，并且计算缓存键错误失败。

小开
最佳答案

Visual Studio 做这件事的方式有点奇怪。

它没有在 Dockerfile 文件夹中启动 docker build，而是在父文件夹中启动，并使用 -f选项指定 Dockerfile。

我当时正在使用演示项目(试图为另一个问题创建一个最小化的解决方案) ，遇到了同样的情况。

我的演示项目的设置是

\WorkerService2  ("solution" folder)
+- WorkerService2.sln
+- WorkserService2  ("project" folder)
+- DockerFile
+- WorkerService2.csproj
+- ... other program files

因此，我会 期待去

cd \Workerservice2\WorkerService2
docker build .

但我收到了你的错误信息。

 => ERROR [build 3/7] COPY [WorkerService2/WorkerService2.csproj, WorkerService2/]                                                                                                                        0.0s
------
> [build 3/7] COPY [WorkerService2/WorkerService2.csproj, WorkerService2/]:
------
failed to compute cache key: "/WorkerService2/WorkerService2.csproj" not found: not found

相反，使用 .sln文件转到父目录，并使用 docker -f选项指定要在子文件夹中使用的 Dockerfile:

cd \Workerservice2
docker build -f WorkerService2\Dockerfile --force-rm -t worker2/try7 .


docker run -it worker2/try7

编辑 (感谢 Mike Loux，tblev & Goku) :

请注意 docker build命令的最后一个点。

对于 Docker，命令的最后一部分是 Docker 将处理的文件的位置。通常是这样这是一个文件夹，里面有 Dockerfile，但这就是 VS 的不同之处。在这种情况下，dockerfile 是用 -f指定的。任何路径(例如 dockerfile 中的 COPY指令)都是相对于指定位置的。.的意思是“工作目录”，在我的例子中是 \WorkerService2。

我是通过检查构建过程的输出来达到这个阶段的，详细程度设置为 Details。 如果你选择工具/选项/项目和解决方案/构建和运行，你可以调整构建输出冗长，我做了我的详细。

编辑 # 2 我想我已经知道为什么 Visual Studio 这样做了。 它允许将同一解决方案中的项目引用复制到。

如果它被设置为从项目文件夹执行 docker build，那么 docker 将不能执行解决方案中的任何其他项目。但是按照这种设置方式，使用工作目录作为解决方案文件夹，可以将引用的项目(子文件夹)复制到 docker 构建过程中。

小开

我也有同样的问题，我在添加 Docker 支持时将 Docker 环境设置为 Windows。即使在 VisualStudio 中运行也会导致错误。我将环境更改为 Linux，因为我的 Docker 正在 Windows 子系统中运行。

然后我回到终端运行命令。

我可以通过移动到 Solutions 文件夹(Root 文件夹)来解决这个问题。

我是这样做 docker build的:

docker build -t containername/tag -f ProjectFolder/Dockerfile .

然后我做了 docker run:

docker run containername/tag
小开

我也有同样的问题。在我的情况下，指定的目录是错误的。 我的文件是:

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS publish
WORKDIR /app
COPY . .
RUN dotnet publish -c Release -o publish/web src/MyApp/MyApp.csproj


FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /app
COPY --from=publish publish/web .
EXPOSE 80
CMD ASPNETCORE_URLS=http://*:$PORT dotnet MyApp.dll

然后我意识到，在第二个构建阶段，我试图从目录 publish/web中复制项目文件:

COPY --from=publish publish/web .

但是，由于我在第一阶段指定了 workdir/app，我的文件位于图像文件系统中的该目录中，因此将路径从 publish/web更改为 app/publish/web解决了我的问题。

所以我最后的工作文件是:

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS publish
WORKDIR /app
COPY . .
RUN dotnet publish -c Release -o publish/web src/MyApp/MyApp.csproj


FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /app
COPY --from=publish app/publish/web .
EXPOSE 80
CMD ASPNETCORE_URLS=http://*:$PORT dotnet MyApp.dll
小开

我也遇到过同样的问题。

原因是 Docker 文件中的 DLL 文件的名称区分大小写。

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY MyFirstMicroService.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c release -o /app


FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "**MyFirstMicroService.dll**"]

这个 。 dll名称应该与. csproj 文件匹配。

小开

在我的例子中，文件名中有一个鬼鬼祟祟的尾随空格。

------
> [3/3] COPY init.sh ./:
------
failed to compute cache key: "/init.sh" not found: not found

所以这个文件实际上被称为“ init.sh”，而不是“ init.sh”。

小开

当您没有为您的 COPY 命令输入提供正确的路径时，也会发生这种情况。我得到的最重要的线索是 WORKDIR 命令为容器打开一个文件夹，而不是在文件资源管理器中(所以它不会影响您需要为 COPY 命令指定的路径)。

小开

以下命令在 failed to compute cache key: not found中失败:

docker build -t tag-name:v1.5.1 - <Dockerfile

在将命令更改为以下命令后，它得到了修复:

docker build -t tag-name:v1.5.1 -f Dockerfile .
小开

对我来说, 我犯了个错误，让我解释一下 打开 DockerFile (它应该只命名为 DockerFile，而不是 DockerFile 或 DockerFile)。 你可能有这样的东西- Mcr.microsoft.com/dotnet/runtime:5.0 发布 net5.0。 ENTRYPOINT [“ dotnet”，“ HelloDocker.dll”]

将 发布 net5.0。替换为 拷贝仓/发布/net5.0/发布。

小开

错误: 计算缓存键失败: “ src”未找到: 未找到

在我的例子中，文件夹/文件被排除在. dockerannon 之外

  1. 解析后的文件从 docker忽略能够创建图像。
小开

我的情况是这样的:

  FROM mcr.microsoft.com/dotnet/aspnet:5.0
COPY bin/Release/net5.0/publish/ app/
WORKDIR /app
ENTRYPOINT ["dotnet", "MyApi.dll"]

最后我终于意识到我在我的文件中有 垃圾箱文件夹。

小开

在我的例子中，它是一个错误的 使用 PATH 构建配置，例如 Docker build context

  1. 简单的码头脚本 
    docker build .
    其中 .是构建上下文的路径
  2. Gradle + Docker 
    docker {
dependsOn build
dependsOn dockerFilesCopy
name "${project.name}:${project.version}"
files "build" // path to build context
}
  3. Gradle + GitHub 动作 
    name: Docker build and push


on:
push:
branches: [ main ]


# ...


jobs:
build:
runs-on: ubuntu-latest


# ...


steps:
- name: Checkout
uses: actions/checkout@v2


# ...


- name: Build and export to Docker
uses: docker/build-push-action@v2
with:
# ...
file: src/main/docker/Dockerfile
context: ./build                      # path to build context
小开

在我的案例中，对于 Angular 项目，我的项目在名为 ex: My-Folder-Project 的文件夹中，我正在放置 Dockerfile COPY —— from = Publishing app/dist/My-Folder-Project。 当然，正确的做法是将“ name”放在 package.json 中，比如 COPY —— from = Publishing app/dist/name-in-package. json。

小开

在我的例子中，我改变了上下文，并在 docker-compose. yml 配置文件中改变了 Dockerfile 的路径:

services:
server:
# inheritance structru
extends:
file: ../../docker-compose.server.yml
# I recommend you to play with this paths
build:
context: ../../
dockerfile: ./apps/${APP_NAME}/Dockerfile
...
小开

我遇到过类似的问题: 显然，出于安全原因，docker在构建期间将文件系统根植到指定的构建目录。因此，COPY和 ADD不能引用主机文件系统上的任意位置。此外，还有其他与语法特性有关的问题。最终奏效的方法如下:

COPY ./script_file.sh  /
RUN /script_file.sh

提交答案