一个错误，“无法用前端dockerfile.v0解决”;

我试图为我的盖茨比应用程序构建Docker映像。每当我运行命令docker build . -t gatsbyapp时，它都会给我一个错误:

failed to solve with frontend dockerfile.v0: failed to build LLB:
failed to compute cache key: "/.env" not found: not found

同时我的Dockerfile如下所示:

FROM node:13


WORKDIR /app


COPY package.json .


RUN yarn global add gatsby-cli


RUN yarn install


COPY gatsby-config.js .


COPY .env .


EXPOSE 8000


CMD ["gatsby","develop","-H","0.0.0.0"]
483706 次浏览
小开

可能不是OP的问题，但我在试图构建在Windows for Linux子系统 (WSL) (Debian WSL2)中运行的容器时遇到了这个问题，刚刚安装了码头工人组成，我所要做的就是关闭(Debian)终端并重新打开它，我的问题就解决了。

小开
最佳答案

我也有同样的问题，我所要做的就是将Docker配置文件名大写:

dockerfile祝辞没有工作

Dockerfile祝辞所做的工作

小开

如果你使用的是Docker桌面，重新启动Docker对我有用。 故障处理→重新启动 .处理步骤

小开

在我的情况下，我试图从我正在构建的Docker映像中的当前目录复制文件夹wp-content。像这样:

FROM wordpress:latest


# Copy wp-content
COPY ./wp-content/ ./var/www/html/wp-content/

然而，我注意到我有一个.dockerignore文件，它被显式地告知忽略wp-content。

当我从.dockerignore中删除wp-content/时，它工作得很好。

小开

在我的例子中，“;”后面有一个额外的空格;在context选项中:

docker build -t myapp .[EXTRA_SPACE_HERE]
小开

就我而言，我有两个问题:

  1. 我错过了。在给出上下文选项的命令的末尾，和
  2. 我有一个" txt"Dockerfile的文件名中的扩展名。

经过这两次调整，一切都达到了预期的效果。

小开

确保你的.dockerignore不匹配你的文件。

.dockerignore有时使用的模式是向其添加通配符，并使用!filename语法将特定期望的文件排除到上下文中。例如:

*
!Cargo.toml
!Cargo.lock
!src
!setup.py
!README.md
!project
!requirements
__pycache__

如果你稍后尝试在Dockerfile中使用一个文件，它将匹配通配符，而不会出现在上下文中。向新文件添加异常或删除通配符来修复此问题。

小开

如果你正在使用Windows for Linux子系统 (WSL)，在启动窗口之前检查Docker是否正在运行。如果您在启动窗口后启动了Docker。那么重启你的终端。如果你的文件是正确的，它应该可以工作。

小开

对我来说

无法用前端dockerfile解决。v0:创建LLB失败定义:当前上下文中没有构建阶段

是在FROM之前设置ENV引起的。对于某些Dockerfile指令，这可能是不允许的。在移动ENV之后，FROM错误就消失了。

小开
有时候这种错误来自于一个愚蠢的语法错误… 在我的例子中，我修改了Dockerfile并删除了一些环境变量，但忘记从最后一行删除反斜杠…

    WORDPRESS_HTTPS_PORT="8443" \
WORDPRESS_HTTP_PORT="8080" \
WORDPRESS_SKIP_INSTALL="yes" \ <-- to be removed


EXPOSE 8080 8443
USER 0
小开

我不记得我到底是在哪里读到这篇文章的，但如果你正在使用WSL2并收到这个错误，那么请删除WSL2主文件夹中的Docker配置文件，并尝试重建您的映像。

也就是说，如果你已经检查了你的文件名，并再次确认所有内容都是正确命名的(Dockerfile， .dockerignore等)。

WSL2 Ubuntu:

rm ~/.docker/config.json
小开

我在Mac上升级到最新的Docker桌面版本后遇到了这个问题。用这个问题上的注释解决了这个问题。

解决方案:不要使用buildkit，它适合我。

export DOCKER_BUILDKIT=0
export COMPOSE_DOCKER_CLI_BUILD=0
小开

我打错了，

FROM apline:3.7代替FROM alpine:3.7。

小开

当我用完磁盘空间时，我就遇到了这个问题，可能是由于我摆弄和调整Dockerfile时建立的大量图像层缓存加剧了这个问题。

小开

如果你看到了这个问题，它实际上并不是真正的问题。实际问题嵌套在错误日志的某个地方。要查看实际问题，您需要像这样运行构建命令:

DOCKER_BUILDKIT=0  docker build .

注意DOCKER_BUILDKIT=0。这将使构建工具包不隐藏嵌套错误。从那里你应该能够谷歌正确的解决方案。

这也会使构建在命令行中看起来不同，但不用担心。只需要查找错误。

小开

我还遇到了另一种可能性:如果您正在使用构建阶段，请确保始终使用正确的阶段名称。

我有一个定义的舞台

FROM zzz AS development

它后来被用于另一个阶段

FROM development AS yyy

一时兴起，我将development改为dev，但仅在第一个实例中。所以后者仍然是FROM development，而前者是AS dev。

奇怪的是，对于这样一个小错误，错误信息是多么神秘……你可能会认为他们只会让错误消息说“无法找到__abc0”;什么的。

小开

我必须在~/.docker/config.json ...中设置"credsStore": ""。它之前被设置为credentials.exe。

在WSL2中，ddev启动失败在docker-credential-desktop.exe， "error listing credentials"# 2342 < / >

小开

通过设置HTTP_PROYY和HTTP_PROXYS环境变量来指定代理服务器。

例子:

http_proxy=http://username:password@proxy.example.com:8080
https_proxy=http://username:password@proxy.example.com:8080
小开

禁用macOS v11 (Big Sur)虚拟化框架:

Enter image description here

小开
确保你使用相同的平台，例如: 如果您使用

构建第一个映像(my-custom-service) 
FROM --platform=linux/amd64 node:14

那么你需要将--platform添加到其他使用第一个基映像的__abc1中:

FROM --platform=linux/amd64 my-custom-service
小开

我在使用WSL2 Ubuntu时遇到了这个问题，我通过更改Dockerfile的权限来解决它。

当我在我的计算机上设置WSL2时，我直接将我的一些文件(包括Dockerfile)从Windows复制到Ubuntu根文件夹中，这显然会导致文件具有空白权限:

---------- 1 user user 10M Jan 1 00:00 Dockerfile

为了解决这个问题，我运行chmod 644 Dockerfile:

-rw-r--r-- 1 user user 10M Jan 1 00:00 Dockerfile

在那之后，Docker能够构建图像而没有任何进一步的问题。

小开

由于VPN连接，我遇到了这个问题。

我所要做的就是在码头工人的桌面 代理部分设置一个手动代理:

Enter image description here

小开

在我看来，这个错误有很多原因。

在我的例子中，有两个错误:(1)在Dockerfile中:#语法= *****行拼写错误;(2)在文件docker_compose.yaml中，web / build: *行指向错误的目录。

通过阅读Dockerfile文档和休息来重新集中注意力，我得到了帮助。

小开

对我来说，以下是错误:

无法用前端dockerfile解决。v0: failed to create LLB definition: failed to do request: Head https://registry-1.docker.io/v2/library/postgres/manifests/13-alpine: net/http: TLS握手超时

我在Windows 10和Docker Desktop中使用WSL2，我在更新Docker Desktop到3.5版本后得到了这个问题。

我通过启用附加分布的WSL集成来解决这个问题。

启用它:

在Windows中打开Docker Desktop，进入设置→资源→WSL集成→启用与其他发行版的集成，并为您安装的Ubuntu应用程序启用它。

小开

在我的情况下，我不得不卸载Astrill VPN。

小开

我有这个问题/错误之前，我有一个脚本，我用来构建多个Dockerfiles，其中一个Dockerfiles被注释掉了。 当我取消Dockerfile的注释并再次运行脚本时，它对我来说工作得很好

小开

我犯了同样的错误，但是把Dockerfile从子文件夹移到应用程序的根文件夹中。它修复了错误消息。

小开

我也有同样的问题。

码头工人文件名:

  • DockerFile -错误
  • dockerFile -错误
  • Dockerfile工作!

你只需要一个大写的字符。

小开

如果你在Windows上使用Docker，那么确保Docker引擎被设置为与你想要构建的映像(Windows / Linux)匹配的模式。

小开

我在通过Visual Studio 2019构建Docker映像时遇到了同样的问题。我的Docker文件有一个类似Dockerfile的名字。

Dockerfile祝辞没有工作

dockerfile祝辞所做的工作

小开

如果你有一个类似的项目结构，

├── docker
│   │
│   ├── app
│   │   └── Dockerfile
│   └── mlflow
│       └── Dockerfile
│
└── docker-compose.yml

你可能没有在docker-compose.yml中指定build: context:

version: '3'


services:


mlflow:
build:
context: ./
dockerfile: ./docker/mlflow/Dockerfile
container_name: ml_app_mlflow
volumes:
- ./db:/db
ports:
- 5000:5000
小开

如果你在Windows中使用Docker，你需要在设置中禁用Docker引擎中的buildkit。它适用于我，解决了我的错误

将buildkit选项设置为假。

{
"builder": {
"gc": {
"defaultKeepStorage": "20GB
< p >“, “enabled":没错 ｝ }， “experimental":假的, “features": { “buildkit":假的 ｝ } < / p >

Docker for Windows buildkit option

小开

如果你在Mac或Windows上使用码头工人的桌面，你可能也必须在你的“Docker引擎”JSON配置中禁用它。

Docker Desktop→设置→码头工人引擎→将“&;features"; {buildkit: true}”改为“&;features": {buildkit: false}”。

小开

如果你的Docker文件在不同的路径和不同的名字Dockerfile，你可以运行

docker build -t build_tag_name -f './path/to/dockerfile/exampledockerfile' .
小开

如果你之前执行了Docker buildx install，你的docker命令别名为码头工人buildx，它基于码头工人Buildkit，目前Windows容器不支持(很遗憾)。

使用实例删除别名。

docker buildx uninstall

我希望这能为像我这样忘记这个别名的人节省时间

小开

对我来说，我发现我试图从错误的目录进行构建。

小开

在我的案例中，这是因为文档中的用例没有得到充分表达。几乎所有的例子都告诉你要使用.和Dockerfile(大写D)，但它们大多没有明确地告诉你如何自定义。

docker image build --tag any_image_tag --file any_file_name path_to_your_context_folder

我认为这个更好，我希望它能帮助到那些来这里的人。any_file_name实际上是任何包含构建指令的文件名。“dockerfile"虽然它不是必需的，但是如果它与上下文文件夹不同，它有助于识别并给出完整的路径。path_to_your_context_folder基本上是你的工作所在的地方，比如一个web应用程序。

例如，下面是我当前在窗口中的测试，其中COPY . /app使用上下文文件夹作为.:

docker image build --tag nested_image --file C:\WorkSpace\myapp\dockerfiles\any_file_name C:\WorkSpace\myapp\contextfiles\

PS:对于同一个问题，这个主题确实有很多有趣的答案，但是是由许多奇异的原因引起的。我的问题只是一个显而易见的问题的旁注。

小开

在我的例子中，我有两张图片，我是从同一张图片复制的。我的具体错误是:failed to solve: failed to solve with frontend dockerfile.v0: failed to create LLB definition: circular dependency detected on stage: kubexit

FROM karlkfi/kubexit:latest AS kubexit
COPY --from=kubexit /bin/kubexit /bin/


FROM maven:3.8-jdk-11-slim AS build

所以这是一个循环引用。解决办法:

FROM karlkfi/kubexit:latest AS kubexit


FROM maven:3.8-jdk-11-slim AS build
COPY --from=kubexit /bin/kubexit /bin/
小开

在我的情况下，我不在dockerfile本身的同一个目录中。

小开

试试这个简单的解决方案，将dockerfile命名为Dockerfile，不带扩展名。

小开

它为我解决了

我正在使用一个MacBook Air (M1)并且有一个问题，因为我正在使用一个支持linux / amd64的映像，而我的系统架构是arm64。

因此，请确保根据您的设备运行兼容的映像。

小开

我的问题是由于使用VPN。

小开

还有另一种可能性:当我试图用Windows 10 servercore映像构建Dockerfile时，我在Windows 10上为WSL使用了基于linux的容器。

在系统托盘中，右键单击码头工人的桌面并选择切换到Windows容器…

小开
我通过在构建命令的开头添加sudo (Ubuntu)来解决这个问题。 例如:< / p > 
sudo docker build --tag somename .
小开

我所需要做的只是在构建中添加—no-cache作为参数。

小开

我今天遇到了这个问题。我的问题是我创建并填充Dockerfile，但没有保存Dockerfile中的更改，我尝试CTRL + S并再次尝试构建，为我工作))

小开

对我来说

我打开Docker桌面->打开设置->

{
"builder": {
"gc": {
"defaultKeepStorage": "20GB",
"enabled": true
}
},
"experimental": false,
"features": {
"buildkit": false
}
}

我的buildkit默认值为true ->我更改为false并重新启动docker引擎

这对我很有用

小开

如果你正在使用任何在v0 Dockerfile中不支持的新特性(如多个构建上下文)，你需要在Dockerfile的开头指定Dockerfile version

例如，在Dockerfile中，第一行将是:

#syntax=docker/dockerfile:1.4

小开
对于docker桌面，这个问题通常通过添加-f选项来解决。 例如:将docker文件放置在c:\Dockerfile.txt

您可以运行以下命令来构建映像

docker build -f "c:\ dockerfile .txt;

小开

我在使用visual studio 2022时也遇到了同样的问题。问题是visual studio 2022的逻辑目录结构与物理目录结构不同。因此，该文件在visual studio 2022展示的位置上并不存在。

一旦指定了正确的位置，它就可以正常工作。

我不需要改变DOCKER_BUILDKIT=0或任何设置。但使用-f选项指定docker文件。

小开

其他的答案都对我没用。在我的情况下，问题是我在CLI中使用docker有一些权限问题，而不是修复它，我只是使用sudo。所以我修复了这些权限问题(在~/.docker/buildx文件夹中)，并在没有sudo的情况下运行docker，它工作了。


提交答案