Estaba tratando de construir mi imagen Docker para mi aplicación Gatsby . Cada vez que ejecuto el comando docker build . -t gatsbyapp
, me da error:
failed to solve with frontend dockerfile.v0: failed to build LLB: failed to compute cache key: "/.env" not found: not found
Mientras tanto, mi Dockerfile se muestra a continuación:
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"]
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:
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
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 .
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
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 :
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.