Docker: Kontext kann nicht vorbereitet werden: Symlinks im Docker-Dateipfad können nicht ausgewertet werden: GetFileAttributesEx

beim Ausführen des folgenden Befehls:

docker build -t docker-whale .

überprüfen Sie, ob Dockerfile in Ihrem aktuellen Arbeitsverzeichnis vorhanden ist.

Wenn Sie unter Windows 8 arbeiten, verwenden Sie die Docker-Toolbox. Führen Sie im Verzeichnis mydockerbuild den folgenden Befehl aus, da Ihre Docker-Datei eine Textdatei ist

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

Der Name der Datei sollte Dockerfile und nicht .Dockerfile sein. Die Datei sollte keine Endung haben.

Entfernen Sie einfach die Erweiterung .txt aus Dockerfile und führen Sie den Befehl aus

docker build -t image-name 

Es wird sicher funktionieren.

Ich hatte meine Datei dockerfile anstelle von Dockerfile (mit Großbuchstaben) benannt und als ich das änderte, begann sie, meine "Dockerfile" zu verarbeiten.

Ich habe diesen Fehler (im MacBook), obwohl ich den richtigen Befehl zum Erstellen eines Bildes verwendet habe.

docker build -t testimg .

Später fand ich, dass der Weg das Problem ist. Navigieren Sie einfach zum richtigen Pfad, der die Docker-Datei enthält. Überprüfen Sie einfach Ihr aktuelles Arbeitsverzeichnis. Keine Panik!

Ich hatte mein DockerFile von VS2017 Docker Support Tool erstellt und hatte den gleichen Fehler. Nach einer Weile wurde mir klar, dass ich mich nicht in dem richtigen Verzeichnis befand, das die Docker-Datei (~\source\repos\DockerWebApplication\) enthält. cd'ed zu der korrekten Datei (~/source/repos/DockerWebApplication/DockerWebApplication), die sich im Projekt befand und das Docker-Image erfolgreich erstellt hat.

In der WSL scheint es ein Problem mit der Pfadkonvertierung zu geben. Der Speicherort der Docker-Datei in Ubuntu (auf der Docker ausgeführt wird und auf der Docker-Datei gespeichert ist) ist "/ home/sxw455/App1", aber keiner der folgenden Befehle hat funktioniert:

$ 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

In Windows lautet der tatsächliche Pfad jedoch:

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

Und so musste ich das tun (obwohl ich es von Bash aus ausgeführt habe):

$ 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.

Ich hatte ähnliche Probleme mit Umgebungsvariablen während der Erstinstallation und befolgte einige Ratschläge, die besagten, das Windows DockerCE zu installieren und die Umgebungsvariablen zu hacken, anstatt das Ubuntu DockerCE zu installieren, weil (ich hoffe, ich habe mich richtig daran erinnert) die WSL nicht vollständig implementiert systemctl. Sobald die Installation von Windows Docker CE abgeschlossen ist und Umgebungsvariablen festgelegt wurden, funktioniert Docker unter WSL/Ubuntu einwandfrei.

In Windows 10 ... ist Punkt der erste Parameter

docker build . -t docker-whale

Das liegt nur daran, dass Notepad ".txt" am Ende von Dockerfile hinzufügt

Ich hatte mein Dockerfile ursprünglich in PowerShell erstellt und obwohl ich keine Erweiterung für die Datei sah, wurde sie als PS-Dateityp angezeigt ... nachdem ich die Datei mit Notepad ++ erstellt hatte, war es sicher, die Option "Alle Typen (.) "Dateityp ohne Erweiterung des Dateinamens (Dockerfile). Damit konnte mein Befehl zum Erstellen von Images erfolgreich ausgeführt werden. Vergewissern Sie sich, dass Ihre Docker-Datei den Dateityp "Datei" hat.

Das Problem ist, dass der Dateiname Dockerfile und nicht DockerFile oder Dockerfile sein sollte. Es sollte sich um Großbuchstaben handeln, gefolgt von ockerfile in Kleinbuchstaben

Speichern Sie automatisierte Inhalte in Dockerfile, um Dockerfile zu erstellen. nicht Dockerfile, weil beim Öffnen eines Dateibefehls:

$ notepad Dockerfile 

(Eine Textdatei wird geschrieben, damit die Datei nicht erstellt werden kann.)

So erstellen Sie eine Datei:

$ notepad Dockerfile

und jetzt laufen:

$ docker build -t docker-whale .

Stellen Sie sicher, dass Sie sich im aktuellen Verzeichnis von Dockerfile befinden.

Stellen Sie sicher, dass der Dateiname "Dockerfile" nicht mit einer Erweiterung gespeichert ist. Erstellen Sie einfach eine Datei ohne Erweiterung.

Stellen Sie sicher, dass sich Dockerfile in demselben Verzeichnis befindet, in dem Sie das Docker-Image erstellen möchten.

Ich mein Fall (laufen von Windows 10)
1) Benennen Sie die Datei myDockerFile.Dockerfile in Dockerfile um (ohne Dateierweiterung).
Führen Sie dann von außerhalb des Ordners diesen Befehl aus:

docker build .\Docker-LocalNifi\ 

Das funktioniert für mich und für meine Arbeitskollegen, ich hoffe, das funktioniert auch für Sie

Stellen Sie vor allem sicher, dass Ihr Dateiname Dockerfile lautet. Wenn Sie einen anderen Namen verwenden, funktioniert dies nicht (zumindest nicht für mich).

Auch wenn Sie sich in demselben Verzeichnis befinden, in dem sich die Docker-Datei befindet, verwenden Sie einen ., d. H. docker build -t Myubuntu1:v1 ., oder verwenden Sie den absoluten Pfad, d. H. docker build -t Myubuntu1:v1 /Users/<username>/Desktop/Docker.

Das Problem hängt mit der DockerFile-Erstellungsprozedur zusammen.

Um zu arbeiten, öffnen Sie cmd, cd in das Verzeichnis von Interesse und geben Sie Folgendes ein:

abc>DockerFile

Dadurch wird eine Datei mit dem Namen DockerFile in Ihrem Ordner erstellt.

Geben Sie nun Folgendes ein:

notepad DockerFile 

Dadurch wird die DockerFile-Datei im Editor geöffnet und Sie müssen den bereitgestellten Standardcode kopieren/einfügen.

Speichern Sie die Datei und erstellen Sie nun Ihr Image mit Docker, indem Sie Folgendes eingeben:

docker build -t docker-whale . 

Das funktioniert für mich und ich hoffe es hilft anderen

Ich habe dies unter Windows erhalten, als sich der Pfad, in dem ich arbeitete, unter einem Junction-Verzeichnis befand. Mein Fix war es also, nicht unter diesem Pfad zu arbeiten.

Der folgende Befehl hat bei mir funktioniert: docker build -t docker-whale -f Dockerfile.txt.

Auf Mac funktioniert für den folgenden Befehl. (Ich hoffe, Ihr .Dockerfile befindet sich in Ihrem Stammverzeichnis).

docker build -t docker-whale -f .Dockerfile .

Es ist Schande!

Die Fehlermeldung ist irreführend. Das Problem hat eigentlich nichts mit Symlinks zu tun. Normalerweise kann der Docker die Docker-Datei , die den Build beschreibt, nicht finden.

Typische Gründe sind diese:

• Dockerfile hat einen falschen Namen .
  Es muss Dockerfile heißen. Wenn es zum Beispiel dockerfile, .Dockerfile, Dockerfile.txt oder andere heißt, wird es nicht gefunden.
• Dockerfile ist nicht im Kontext .
  Wenn Sie docker build contextdir sagen, muss sich das Dockerfile bei contextdir/Dockerfile befinden. Wenn Sie es in haben, sagen Sie stattdessen Dockerfile, wird es nicht gefunden.
• Dockerfile existiert nicht .
  Klingt albern? Nun, ich habe die obige Fehlermeldung von meinem GitLab CI erhalten, nachdem ich ein Nice Dockerfile geschrieben hatte, aber vergessen habe, es einzuchecken. Sicher. Unwahrscheinlich? Nein.

Es ist nicht die einzige Schande ...

Nicht nur diese eine Fehlermeldung ist vage und verwirrend. Ich finde im Allgemeinen, dass einige der Docker-Konzepte und viele der Dokumentationen semantisch ungenau sind.

Eine der wirklich schlechten Stellen ist Begriff "Tag" (Stand August 2019). Je nachdem, wo Sie in der Dokumentation nachschauen, werden alle folgenden Dinge (mehr oder weniger deutlich) gesagt:

• Es gibt den Befehl tag, aber das von Ihnen angegebene Argument heißt nicht Tag oder Tag-Name, sondern Image-Name.
• Ein Bildname besteht aus einem Bildnamen und einem Tag, die durch einen Doppelpunkt getrennt sind.
• Im Befehlsargument tag ist der Tag-Name optional, der Image-Name jedoch obligatorisch. Offensichtlich.
• In den Worten der Dokumentationsseite:
  docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
• Es ist jedoch nicht der gesamte Image-Name in diesem Image-Namen tatsächlich der Image-Name, da dem Image-Namen ein Host-Name vorangestellt werden kann.
• Obwohl manchmal dieser Host-Name-Teil als Teil des Image-Namens betrachtet wird .
• In jedem Fall sollte ein Bild mit einem Hostnamen x in (oder vorher, aber irgendwie magisch immer an ihm festhalten) seinem Imagenamen dann auf diesem Host x (in einer Registrierung) leben. Wenn Sie auf ein solches Image zugreifen möchten, müssen Sie diesen Namen mehr oder weniger mit dem Host-Präfix x verwenden.
• Ein Image mit diesem Namen kann jedoch auf jedem Host gespeichert werden, nicht nur auf x, da das "Verschieben" des Images auf x eine separate Operation ist.
• Es bedeutet also nicht viel, diesen Namen in einer Docker-Image-Auflistung zu sehen, aber es wird sicherlich etwas andeuten. Manchmal falsch.
• Übrigens: Habe ich Namespaces erwähnt? Sie können zwischen dem Hostnamen und dem Image-Namen im Image-Namen wechseln. Und sind auch Teil des Bildnamens oder nicht, je nachdem, wo Sie suchen.

Wenn Sie dies verwirrt, ist es nicht Ihre Schuld.

Ende des Geschwätzes.