web-dev-qa-db-fra.com

Docker: impossible de préparer le contexte: impossible d'évaluer les liens symboliques dans le chemin de Dockerfile: GetFileAttributesEx

Je viens de télécharger Docker Toolbox for Windows 10 64bit aujourd'hui. Je vais à travers le tutoriel. Je reçois l'erreur suivante lorsque j'essaie de créer une image à l'aide d'un fichier Docker.

Pas:

  • Lancement du terminal Docker Quickstart.
  • testdocker après l'avoir créé.
  • Préparez Dockerfile comme indiqué dans le lien Web "Créez votre propre image"
  • a couru sous la commande

docker build -t docker-whale .

Error: $ docker build -t docker-whale .

unable to prepare context: unable to evaluate symlinks in Dockerfile path: GetFileAttributesEx C:\Users\Villanueva\Test\testdocker\Dockerfile: The system cannot find the file specified.

BTW: J'ai essayé plusieurs options mentionnées @ https://github.com/docker/docker/issues/14339

    $ docker info
    Containers: 4
     Running: 0
     Paused: 0
     Stopped: 4
    Images: 2
    Server Version: 1.10.1
    Storage Driver: aufs
     Root Dir: /mnt/sda1/var/lib/docker/aufs
     Backing Filesystem: extfs
     Dirs: 20
     Dirperm1 Supported: true
    Execution Driver: native-0.2
    Logging Driver: json-file
    Plugins:
     Volume: local
     Network: bridge null Host
    Kernel Version: 4.1.17-boot2docker
    Operating System: Boot2Docker 1.10.1 (TCL 6.4.1); master : b03e158 - Thu Feb 11 22:34:01 UTC 2016
    OSType: linux
    Architecture: x86_64
    CPUs: 1
    Total Memory: 996.2 MiB
    Name: default
    ID: C7DS:CIAJ:FTSN:PCGD:ZW25:MQNG:H3HK:KRJL:G6FC:VPRW:SEWW:KP7B
    Debug mode (server): true
     File Descriptors: 32
     Goroutines: 44
     System Time: 2016-02-19T17:37:37.706076803Z
     EventsListeners: 0
     Init SHA1:
     Init Path: /usr/local/bin/docker
     Docker Root Dir: /mnt/sda1/var/lib/docker
    Labels:
     provider=virtualbox
116
villanux

en exécutant la commande suivante:

docker build -t docker-whale .

vérifiez que Dockerfile est présent dans votre répertoire de travail actuel.

145
kalyani chaudhari

Si vous travaillez sur Windows 8, vous utiliseriez la boîte à outils Docker. Dans le répertoire mydockerbuild, exécutez la commande ci-dessous, car votre fichier Docker est un fichier texte.

docker build -t docker-whale -f ./Dockerfile.txt .
29

Le nom du fichier doit être Dockerfile et non .Dockerfile. Le fichier ne doit avoir aucune extension.

14
SharpCoder

Il suffit de supprimer l’extension .txt de Dockerfile et d’exécuter la commande

docker build -t image-name 

Cela fonctionnera à coup sûr.

12
satya

J'avais nommé mon fichier dockerfile au lieu de Dockerfile (en majuscule) et une fois que j'ai changé, le traitement de mon "Dockerfile" a commencé.

11
Alan Fitzgerald

J'ai cette erreur (sous MacBook) bien que j'aie utilisé la bonne commande pour créer une image,

docker build -t testimg .

Plus tard, j'ai trouvé que c'est le chemin qui pose problème. Il suffit de naviguer vers le chemin correct contenant le fichier Docker. Il suffit de vérifier votre répertoire de travail actuel. Rien à craindre!

8
arunprakashpj

J'avais créé mon outil de support DockerFile par VS2017 et j'avais la même erreur. Après un moment, j'ai réalisé que je ne me trouvais pas dans le bon répertoire contenant le fichier Dockerfile (~\source\repos\DockerWebApplication\). Cd'ed dans le fichier correct (~/source/repos/DockerWebApplication/DockerWebApplication) qui était à l'intérieur du projet et a créé avec succès l'image du menu fixe.

4
Hasan

En WSL, il semble y avoir un problème de conversion de chemin. L'emplacement du fichier Dockerfile dans Ubuntu (où j'exécute docker et où réside le fichier Dockerfile) est "/ home/sxw455/App1", mais aucune de ces commandes ne fonctionne:

$ pwd
/home/sxw455/App1
$ ll
total 4
drwxrwxrwx 0 sxw455 sxw455 4096 Dec 11 19:28 ./
drwxr-xr-x 0 sxw455 sxw455 4096 Dec 11 19:25 ../
-rwxrwxrwx 1 sxw455 sxw455  531 Dec 11 19:26 Dockerfile*
-rwxrwxrwx 1 sxw455 sxw455  666 Dec 11 19:28 app.py*
-rwxrwxrwx 1 sxw455 sxw455   12 Dec 11 19:27 requirements.txt*

$ docker build -t friendlyhello .
unable to prepare context: unable to evaluate symlinks in Dockerfile path: GetFileAttributesEx C:\Windows\System32\Dockerfile: The system cannot find the file specified.

$ docker build -t friendlyhello "/home/sxw455/App1"
unable to prepare context: path "/home/sxw455/App1" not found

Mais sous Windows, le chemin réel est le suivant:

C:\Users\sxw455\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\home\sxw455\App1

Et donc je devais faire ça (même si je le courais depuis bash):

$ docker build -t friendlyhello 
"C:\Users\sxw455\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\home\sxw455\App1"

Sending build context to Docker daemon   5.12kB
Step 1/7 : FROM python:2.7-slim
 ---> 0dc3d8d47241
Step 2/7 : WORKDIR /app
 ---> Using cache
 ---> f739aa02ce04
Step 3/7 : COPY . /app
 ---> Using cache
 ---> 88686c524ae9
Step 4/7 : RUN pip install --trusted-Host pypi.python.org -r requirements.txt
 ---> Using cache
 ---> b95f02b14f78
Step 5/7 : EXPOSE 80
 ---> Using cache
 ---> 0924dbc3f695
Step 6/7 : ENV NAME World
 ---> Using cache
 ---> 85c145785b87
Step 7/7 : CMD ["python", "app.py"]
 ---> Using cache
 ---> c2e43b7f0d4a
Successfully built c2e43b7f0d4a
Successfully tagged friendlyhello:latest
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker Host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

J'ai eu des problèmes similaires avec les variables d'environnement lors de l'installation initiale et j'ai suivi certains conseils qui disaient d'installer Windows DockerCE et de pirater les variables d'environnement plutôt que d'installer Ubuntu DockerCE, parce que (j'espère m'en être souvenu correctement) que WSL n'est pas pleinement implémenté systemctl. Une fois l'installation de Windows Docker CE terminée et les variables d'environnement définies, docker fonctionne correctement sous WSL/Ubuntu.

3
Comissar

Dans Windows 10 ... le premier paramètre est la période

docker build . -t docker-whale

3
PDA

C'est juste parce que Notepad ajoute ".txt" à la fin de Dockerfile

3
Aurélien

J'avais initialement créé mon fichier Dockerfile dans PowerShell et, bien que je n’ai pas vu d’extension sur le fichier, il s’affichait comme type de fichier PS ... une fois le fichier créé à partir de Notepad ++, en étant sûr de sélectionner "Tous les types (.) "Type de fichier sans extension du nom de fichier (fichier Docker). Cela a permis à ma commande de génération d'image de se terminer correctement .... Assurez-vous simplement que votre fichier Dockerfile a un type de "fichier" ...

2
Helper7123

Le problème est que le nom du fichier doit être Dockerfile et non pas DockerFile ou dockerfile mais D majuscule suivi de ockerfile en minuscule.

2
vincent

Pour créer Dockerfile, enregistrez le contenu automatisé dans Dockerfile. pas Dockerfile car lors de l’ouverture d’une commande de fichier:

$ notepad Dockerfile 

(Un fichier texte est écrit pour que le fichier ne puisse pas être construit)

Pour construire un fichier, exécutez:

$ notepad Dockerfile

et maintenant courez:

$ docker build -t docker-whale .

Assurez-vous que vous êtes dans le répertoire actuel de Dockerfile.

1
niteshkumarmodi

Assurez-vous que le nom de fichier "Dockerfile" n’est enregistré avec aucune extension. Il suffit de créer un fichier sans aucune extension.

Et assurez-vous que Dockerfile se trouve dans le même répertoire que celui où vous essayez de créer une image de menu fixe.

1
Nakesh

J'ai mon cas (sous Windows 10)
1) Renommez le fichier myDockerFile.Dockerfile en Dockerfile (sans extension de fichier).
Puis lancez from en dehors du dossier cette commande:

docker build .\Docker-LocalNifi\ 

Cela fonctionne pour moi et pour mes collègues de travail, espérons que cela fonctionnera également pour vous.

1
Yohan

Plus important encore, assurez-vous que votre nom de fichier est Dockerfile si vous utilisez un autre nom, cela ne fonctionnera pas (du moins, ça ne me l'a pas été.)

De même, si vous vous trouvez dans le même répertoire que le fichier Dockerfile, utilisez un . c'est-à-dire docker build -t Myubuntu1:v1 . ou utilisez le chemin absolu, c'est-à-dire docker build -t Myubuntu1:v1 /Users/<username>/Desktop/Docker

1
ady6831983

Le problème est lié à la procédure de création de DockerFile.

Pour fonctionner, ouvrez cmd, cd dans le répertoire qui vous intéresse et tapez:

abc>DockerFile

Cela créera un fichier appelé DockerFile dans votre dossier.

Maintenant tapez:

notepad DockerFile 

Cela ouvrira le fichier DockerFile dans le bloc-notes et vous devrez copier/coller le code standard fourni.

Enregistrez le fichier et enfin, construisez votre image avec Docker:

docker build -t docker-whale . 

Cela fonctionne pour moi et j'espère que cela aidera les autres

0

Je l’ai sous Windows lorsque le chemin sur lequel je travaillais se trouvait dans un répertoire Junction. Donc, ma solution était de ne pas travailler sous cette voie.

0
Chris F Carroll

La commande ci-dessous a fonctionné pour moi docker construire -t docker-whale -f Dockerfile.txt.

0
AMAN BHARDWAJ

Sur Mac cela fonctionne pour la commande ci-dessous. (espérons que votre .Dockerfile se trouve dans votre répertoire racine).

docker build -t docker-whale -f .Dockerfile .
0
Chanaka Caldera

C'est dommage!

Le message d'erreur est trompeur. Le problème n'a vraiment rien à voir avec les liens symboliques. Habituellement, seul le docker ne peut pas trouver le fichier Dockerfile décrivant la construction.

Les raisons typiques sont les suivantes:

  • Dockerfile a un mauvais nom .
    Il faut l’appeler Dockerfile. S'il est appelé, par exemple, dockerfile, .Dockerfile, Dockerfile.txt ou autre, il ne sera pas trouvé.
  • Dockerfile n'est pas dans son contexte .
    Si vous dites docker build contextdir, le fichier Docker doit être à contextdir/Dockerfile. Si vous l'avez, par exemple, Dockerfile, il ne sera pas trouvé.
  • Dockerfile n'existe pas .
    Ça semble idiot? Eh bien, j'ai reçu le message d'erreur ci-dessus de mon CI GitLab après avoir écrit un fichier Nice Dockerfile, mais j'ai oublié de l'enregistrer. Silly? Sûr. Peu probable? Non.

Ce n'est pas la seule honte ...

Non seulement ce message d'erreur est vague et déroutant. Je trouve généralement certains concepts de docker et une grande partie de la documentation sémantiquement imprécis.

L'un des très mauvais points est le notion de "tag" (à partir d'août 2019). Selon l'endroit où vous regardez dans la documentation, il dit (plus ou moins clairement) toutes les choses suivantes:

  • Il existe la commande tag, mais l'argument que vous fournissez ne s'appelle pas une balise ou un nom de balise, mais un nom d'image.
  • Un nom d'image se compose d'un nom d'image et d'une balise, séparés par deux points.
  • Dans l'argument de commande tag, le nom de la balise est facultatif, mais le nom de l'image est obligatoire. Évident.
  • Dans les mots de la page de documentation:
    docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
  • Cependant, le nom de l'image dans ce nom ne correspond pas toujours au nom de l'image, car ce nom peut être préfixé par un nom d'hôte.
  • Bien que parfois la partie du nom d’hôte soit considérée comme faisant partie du nom de l’image.
  • Dans tous les cas, une image avec un nom d’hôte x dans (ou avant, mais s’accrochant toujours magiquement à) son nom d’image est alors supposée vivre sur cet hôte x (dans un registre). Si vous souhaitez accéder à une telle image, vous devez plus ou moins utiliser ce nom avec le préfixe de l'hôte x.
  • Mais une image portant ce nom peut vivre sur n'importe quel hôte, pas seulement sur x, car le "transfert" de l'image sur x est une opération distincte.
  • Donc, voir ce nom dans une liste d'images de docker ne veut pas dire grand-chose, mais cela insinuera sûrement quelque chose. Parfois à tort.
  • Au fait: est-ce que j'ai mentionné les espaces de noms? Ils peuvent aller du nom d'hôte au nom de l'image dans le nom de l'image. Et font également partie du nom de l'image ou non, selon l'endroit où vous regardez.

Si cela vous rend confus, c'est pas de votre faute.

Fin du discours.

0
Lutz Prechelt