Probablemente no sea el problema que tuvo el OP, pero tuve este problema al intentar construir mi contenedor ejecutándose dentro del Subsistema de Windows para Linux (WSL) (Debian WSL2), justo después de haber instalado Docker Compose y todo lo que tenía que hacer era cerrar el ( Debian) terminal y vuelva a abrirlo y mi problema se resolvió.

Tuve el mismo problema y todo lo que tenía que hacer era poner en mayúsculas el nombre del archivo de configuración de Docker:

dockerfile > no funcionó

Dockerfile > funcionó

Si está utilizando Docker Desktop, reiniciar Docker funcionó para mí. Solucionar problemas → Reiniciar

En mi caso, estaba tratando de copiar la carpeta wp-content de mi directorio actual, dentro de la imagen de Docker que estaba creando. Al igual que:

 FROM wordpress:latest # Copy wp-content COPY ./wp-content/ ./var/www/html/wp-content/

Sin embargo, noté que tenía un archivo .dockerignore , al que se le indicó explícitamente que ignorara wp-content .

Cuando eliminé wp-content/ de .dockerignore , funcionó bien.

En mi caso, tenía un espacio extra después de "." en la opción de contexto:

 docker build -t myapp .[EXTRA_SPACE_HERE]

En mi caso, tuve dos problemas:

1. me perdí el . al final del comando que da la opción de contexto, y
2. Tengo una extensión ".txt" en el nombre de archivo del Dockerfile.

Después de estos dos ajustes, todo funcionó como se esperaba.

Asegúrese de que su .dockerignore no coincida con su archivo.

Un patrón que a veces se usa con .dockerignore es agregarle un comodín y excluir el archivo específicamente esperado del contexto con la sintaxis !filename . P.EJ:

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

Si luego intenta usar un archivo en Dockerfile , coincidirá con el comodín y no estará presente en el contexto. Agregue una excepción al nuevo archivo o elimine el comodín para solucionar este problema.

Si está utilizando el Subsistema de Windows para Linux (WSL), verifique si Docker se está ejecutando antes de iniciar la ventana. Si ha iniciado Docker después de iniciar la ventana. Luego simplemente reinicie su terminal. Y debería funcionar si su archivo es correcto.

En mi caso

no se pudo resolver con la interfaz dockerfile.v0: no se pudo crear la definición de LLB: no hay etapa de compilación en el contexto actual

fue causado por establecer ENV antes de FROM. Probablemente esto no esté permitido para algunas instrucciones de Dockerfile. Después de mover ENV justo después de FROM, el error desaparece.

A veces, este tipo de error proviene de un estúpido error de sintaxis... En mi caso, modifiqué un Dockerfile y eliminé algunas variables de entorno, pero olvidé quitar la barra invertida de la última línea...

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

No recuerdo exactamente dónde leí esto, pero si está usando WSL2 y recibe ese error, elimine el archivo de configuración de Docker en su carpeta de inicio de WSL2 e intente reconstruir su imagen.

Es decir, si ya verificó los nombres de sus archivos y volvió a confirmar que todo tiene el nombre correcto ( Dockerfile , .dockerignore , etc.)

Ubuntu WSL2:

 rm ~/.docker/config.json

Experimenté este problema después de actualizar a la última versión de Docker Desktop en Mac. Resuelto con el comentario sobre este tema .

Solución: no use buildkit y funciona para mí.

 export DOCKER_BUILDKIT=0 export COMPOSE_DOCKER_CLI_BUILD=0

Tuve un error tipográfico,

FROM apline:3.7 en lugar de FROM alpine:3.7

Tuve este problema cuando me quedé sin espacio en el disco, presumiblemente exacerbado por las numerosas cachés de capas de imágenes que se acumulaban mientras probaba y modificaba mi Dockerfile.

Si está viendo este problema, en realidad no es el problema real. El problema real está anidado en los registros de errores en alguna parte. Para ver el problema real, debe ejecutar su comando de compilación de esta manera:

 DOCKER_BUILDKIT=0 docker build .

Observe DOCKER_BUILDKIT=0 . Eso hará que el kit de compilación no oculte el error anidado. A partir de ahí, debería poder buscar en Google la solución correcta.

Esto también hará que la compilación se vea diferente en la línea de comandos, pero no te preocupes por eso. Solo busca el error.

Coincidiendo con otra posibilidad que me sucedió: si está utilizando etapas de compilación, asegúrese de tener los nombres correctos de las etapas en todo momento.

Yo tenía una etapa definida con

FROM zzz AS development

que luego se utilizó para otra etapa

FROM development AS yyy

Por un capricho cambié development a dev , pero solo en la primera instancia. Entonces, el último todavía era FROM development mientras que el primero era AS dev .

Es extraño lo arcano que es el mensaje de error para un error tan pequeño ... Uno pensaría que podrían tener el mensaje de error diciendo "no se pudo encontrar development " o algo así.

Tuve que configurar "credsStore": "" en mi ~/.docker/config.json ... . Anteriormente estaba establecido en credentials.exe .

En WSL2, el inicio de ddev falla en docker-credential-desktop.exe, "error al enumerar las credenciales" #2342

Especifique el servidor proxy configurando las variables de entorno HTTP_PROYY y HTTP_PROXYS .

Ejemplo:

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

Deshabilite el marco de virtualización de macOS v11 (Big Sur):

Asegúrese de estar utilizando las mismas plataformas, por ejemplo, si crea la primera imagen (mi servicio personalizado) con

 FROM --platform=linux/amd64 node:14

luego debe agregar --platform a otros Dockerfile s que usan la imagen base del primero:

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

Me encontré con este problema usando WSL2 Ubuntu y lo solucioné cambiando los permisos del Dockerfile.

Cuando configuré WSL2 en mi computadora, copié algunos de mis archivos (incluido el Dockerfile) directamente desde Windows a la carpeta raíz de Ubuntu , lo que aparentemente da como resultado archivos con permisos en blanco:

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

Para solucionarlo, ejecuté chmod 644 Dockerfile :

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

Y después de eso, Docker pudo construir la imagen sin más problemas.

Por lo que puedo ver, este error puede tener muchas razones.

En mi caso, hubo dos errores: (1) en el Dockerfile: la línea # syntax = ***** se escribió incorrectamente y (2) en el archivo docker_compose.yaml , la línea web / build: * apuntaba a el directorio equivocado.

Me ayudó leer la documentación de Dockerfile y tomarme un descanso para recuperar la atención.

Para mí el siguiente fue el error:

no se pudo resolver con la interfaz dockerfile.v0: no se pudo crear la definición de LLB: no se pudo hacer la solicitud: Head https://registry-1.docker.io/v2/library/postgres/manifests/13-alpine : net/http: TLS tiempo de espera de apretón de manos

Estoy usando WSL2 en Windows 10 y Docker Desktop y tuve este problema después de actualizar Docker Desktop a la versión 3.5.

Solucioné el problema habilitando la integración de WSL con distribuciones adicionales.

Para habilitarlo:

Abra Docker Desktop en Windows y vaya a configuración → Recursos → Integración WSL → Habilite la integración con distribuciones adicionales y habilítela para la aplicación de Ubuntu que instaló.

En mi caso, tuve que desinstalar Astrill VPN.

Enfrenté el problema debido a la conectividad VPN .

Todo lo que tenía que hacer era configurar un proxy manual en la sección PROXIES de Docker Desktop :

He tenido este problema/error antes cuando tenía una secuencia de comandos que usaba para compilar varios Dockerfiles y donde uno de los Dockerfiles estaba comentado. Una vez que eliminé el comentario del Dockerfile y ejecuté el script nuevamente, funcionó bien para mí.

Tuve el mismo error, pero moviendo el Dockerfile fuera de la subcarpeta y dentro de la carpeta raíz de mi aplicación. Reparó el mensaje de error.

Tengo el mismo problema.

Nombre de archivo de la ventana acoplable :

• Archivo D ocker - error
• archivo docker - error
• D ockerfile - ¡trabajo!

Solo necesita un carácter en mayúscula.

Si usa Docker para Windows, asegúrese de que el motor de Docker esté configurado en el modo que coincida con la imagen que desea compilar (Windows/Linux).

Si usa Docker para Windows, debe deshabilitar el kit de compilación. Esto funciona para mi.

Establezca la opción del kit de compilación en false .

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

Si está utilizando Docker Desktop para Mac o Windows, es posible que también deba deshabilitarlo en su configuración JSON de 'Docker Engine'.

Docker Desktop → Configuración → Docker Engine → cambie las "características": {buildkit: true} a "features": {buildkit: false}.

En caso de que su archivo docker esté en una ruta diferente con un nombre diferente al de Dockerfile , puede ejecutar

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

Tuve el mismo problema al crear una imagen de Docker a través de Visual Studio 2019 . Mi archivo Docker tenía un nombre como Dockerfile.

Dockerfile> no funcionó

dockerfile > funcionó

En caso de que tengas una estructura de proyecto similar

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

es posible que te falte especificar el build: context en docker-compose.yml

 version: '3' services: mlflow: build: context: ./ dockerfile: ./docker/mlflow/Dockerfile container_name: ml_app_mlflow volumes: - ./db:/db ports: - 5000:5000

En caso de que haya ejecutado previamente docker buildx install , su comando docker tiene un alias de docker buildx , que se basa en Docker Buildkit , que actualmente no es compatible (lamentablemente) en Windows.

Para eliminar el alias, ejecute el siguiente comando:

 docker buildx uninstall

Espero que les ahorre tiempo a personas como yo, que se olvidaron de este alias.

Para mí, descubrí que estaba tratando de compilar desde el directorio incorrecto.

En mi caso, esto se debió a los casos de uso subexpresados de los documentos. casi todos los ejemplos te dicen que uses . y Dockerfile (D mayúscula), pero en su mayoría no dice explícitamente cómo personalizar.

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

Este es mejor en mi opinión, y espero que ayude a los que vienen aquí. any_file_name es realmente cualquier nombre de archivo con instrucciones de compilación, "dockerfile" no es necesario, pero ayuda a identificar y proporcionar la ruta completa si difiere de la carpeta de contexto. path_to_your_context_folder es básicamente donde reside su trabajo, como una aplicación web.

por ejemplo, la siguiente es mi prueba actual en Windows donde COPY . /app usa la carpeta de contexto como . :

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

PD: El tema realmente tiene respuestas interesantes para el mismo problema pero por muchas causas exóticas. la mía es solo una nota al margen de un problema oculto a simple vista.