COPIER un fichier dans un Dockerfile, pas de tel fichier ou répertoire?

J'ai un Dockerfile configuré dans mon dossier racine (~). Les trois premières lignes de mon fichier ressemblent à ceci:

COPY file1 /root/folder/
COPY file2 /root/folder/
COPY file3 /root/folder/

mais il renvoie l'erreur suivante pour chaque ligne:

Aucun fichier ou répertoire de ce nom

Les fichiers sont dans le même répertoire que mon Dockerfile et j'exécute également la commande docker build - < Dockerfiledans le même répertoire dans le terminal.

Qu'est-ce que je fais de mal ici exactement?

L'instruction COPY dans le Dockerfilecopie les fichiers dans srcle destdossier. On dirait que vous manquez soit la file1, file2et file3ou d' essayer de construire à Dockerfilepartir du mauvais dossier.

Reportez-vous à Dockerfile Doc

De plus, la commande de construction du Dockerfiledevrait être quelque chose comme.

cd into/the/folder/
docker build -t sometagname .

Vérifiez également le .dockerignorefichier.

Je sais que c'est un cas très rare, mais j'avais ce dossier mentionné ici.

Cela est peut-être dû au fait que vous faites référence à fichier1 / fichier2 / fichier3 comme un chemin absolu qui n'est pas dans le contexte de construction, Docker recherche uniquement le chemin dans le contexte de construction.

Par exemple, si vous utilisez COPY / home / votrenom / fichier1, la construction Docker l'interprète comme $ {répertoire de travail de construction docker} / home / votre nom / fichier1, si aucun fichier avec le même nom ici, aucune erreur de fichier ou de répertoire n'est générée.

Reportez-vous à l' un des problèmes de docker

Il semble que les commandes:

docker build -t imagename .

et:

docker build -t imagename - < Dockerfile2

ne sont pas exécutés de la même manière. Si vous souhaitez créer 2 images docker à partir d'un même dossier avec Dockerfile et Dockerfile2, la commande COPY ne peut pas être utilisée dans le deuxième exemple à l'aide de stdin (<Dockerfile2). Au lieu de cela, vous devez utiliser:

docker build -t imagename -f Dockerfile2 .

Ensuite, COPY fonctionne comme prévu.

L'exécution a docker build . -f docker/development/Dockerfilefonctionné, ce qui vous permet d'exécuter votre fichier docker à partir d'un répertoire spécifié autre que la racine de votre application.

Utilisez -fou --filepour spécifier le nom et l'emplacement du fichier Dockerfile.

Cela m'est arrivé en essayant d'exécuter le fichier docker à partir d'un répertoire différent.

J'ai eu le COPY failed: stat /var/lib/docker/tmp/docker-builder929708051/XXXX: no such file or directoryet j'ai réussi à résoudre ce problème en spécifiant le fichier docker.

C'est ce docker build docker/development/Dockerfilequi a causé ce problème pour moi.

J'ai trouvé cela étrange au début, car lorsque j'avais le Dockerfilerépertoire racine des applications, cela fonctionnait bien. Cela vous aidera si vous souhaitez gérer un peu mieux les fichiers Docker de votre environnement.

Je viens de rencontrer ce problème et aucune des suggestions ici n'a résolu mon problème. Il s'avère que j'avais les mauvaises fins de ligne dans mon fichier et j'ai dû les changer pour les fins de ligne appropriées. (Dans ce cas de CRLF à LF, donc Ubuntu 14.04 reconnaîtrait le script, que j'avais édité sous Windows.)

J'ai changé les fins de ligne en utilisant VSCode, et la plupart des éditeurs de code devraient avoir la possibilité de choisir des fins de ligne.

J'espère que cela aide quelqu'un.

Je me sens un peu stupide, mais mon problème était que j'exécutais docker-compose et que mon Dockerfile était dans un sous-répertoire ./deploy. Ma référence ADD devait être relative à la racine du projet, pas au Dockerfile.

Modifié: ADD ./file.tar.gz / etc / folder / en: ADD ./deploy/file.tar.gz / etc / folder /

Quoi qu'il en soit, j'ai pensé publier au cas où quelqu'un rencontrerait le même problème.

Voici la solution et la meilleure pratique:

Vous devez créer un dossier de ressources dans lequel vous pouvez conserver tous vos fichiers que vous souhaitez copier.

├── Dockerfile
│   └── resources
│       ├── file1.txt
│       ├── file2.js

La commande de copie de fichiers doit être spécifiée de cette manière:

COPY resources /root/folder/

où

* resources - votre dossier local que vous avez créé dans le même dossier où Dockerfile est

* / root / folder / - dossier dans votre conteneur

Pour l'erreur suivante,

COPY failed: stat /<**path**> :no such file or directory

Je l'ai fait en redémarrant le service docker.

sudo service docker restart

Erreur de fichier introuvable avec Docker put_archive. J'utilise l'API Python pour docker. Docker version 1.12.5, build 7392c3b

docker.errors.NotFound: 404 Client Error: Not Found ("lstat /var/lib/docker/aufs/mnt/39d58e00519ba4171815ee4444f3c43d2c6a7e285102747398f6788e39ee0e87/var/lib/neo4j/certificates: no such file or directory")

Je ne parviens pas à copier des fichiers dans un conteneur Docker créé.

con = cli.create_container(...)
cli.put_archive(...)
cli.start(con['Id'])

Si je change l'ordre de fonctionnement, il n'y a pas d'erreur et les fichiers sont copiés exactement là où je les veux. Je sais donc que mon code fonctionne et fait ce que je veux qu'il fasse. Mais il est important de copier les fichiers de configuration dans un conteneur avant de le démarrer. Copier les fichiers après le démarrage oblige le conteneur à démarrer avec une configuration par défaut et non avec la configuration personnalisée qui doit être copiée avant le démarrage du conteneur. Docker prétend que ce problème est résolu mais qu'il affecte toujours mon application.

Cela marche; Ordre d'exécution différent du même code.

con = cli.create_container(...)
cli.start(con['Id'])
cli.put_archive(...)

si vous êtes sûr d'avoir fait la bonne chose, mais que docker se plaint toujours, jetez un œil à ce problème: https://github.com/moby/moby/issues/27134 .
J'ai été brûlé par cela, et il semble que le redémarrage du moteur Docker résoudra service docker restartsimplement ce problème.

Je cherchais un correctif à ce sujet et le dossier que j'avais ajouté ou copié n'était pas dans le dossier de construction, plusieurs répertoires ci-dessus ou référencé à partir de /

Le déplacement du dossier de l'extérieur du dossier de construction vers le dossier de construction a résolu mon problème.

l'un des moyens de ne pas utiliser stdin et de conserver le contexte est:

1) dans votre Dockerfile, vous devez ajouter

ADD /your_dir_to_copy /location_in_container

2) après, vous devriez aller sur le parent de / your_dir_to_copy dir

2) puis exécutez cette commande

sudo docker build . -t (image/name) -f path_of_your_dockerfile/Dockerfile

3) après avoir créé votre conteneur

docker run -ti --rm cordova bash

4) Après avoir copié votre répertoire dans votre conteneur

Les appels précédents sur COPY peuvent modifier le répertoire.

COPY ./server/package.json ./server      # this passes, but the dest ./server is considered a file

COPY ./server/dist ./server/dist         # error, ./server/dist is not a directory

Ajouter une barre oblique à la fin du premier appel

COPY ./server/package.json ./server/

Je suis tombé sur ça. La copie de certains répertoires n'a pas fonctionné. La copie des fichiers l'a fait. Il s'est avéré que les fichiers contenus dans .gitignore (pas seulement .dockerignore) sont également ignorés. Voir: https://github.com/zeit/now/issues/790

Je sais que c'est vieux, mais quelque chose à souligner. Si vous pensez que tout est comme prévu, vérifiez votre fichier .gitignore :)

Vous pouvez avoir le dossier localement, mais si le dossier est dans votre git ignore, il n'est pas sur le serveur, ce qui signifie que Docker ne peut pas trouver ce dossier car il n'existe pas.

Similaire et grâce à la réponse de tslegaitis , après

gcloud builds submit --config cloudbuild.yaml . 

ça montre

Check the gcloud log [/home/USER/.config/gcloud/logs/2020.05.24/21.12.04.NUMBERS.log] to see which files and the contents of the
default gcloudignore file used (see `$ gcloud topic gcloudignore` to learn
more).

En vérifiant ce journal, il indique que docker utilisera .gitignore:

DATE Using default gcloudignore file:
# This file specifies files that are *not* uploaded to Google Cloud Platform
# using gcloud. It follows the same syntax as .gitignore, with the addition of
# "#!include" directives (which insert the entries of the given .gitignore-style
# file at that point).
# ...

.gitignore

J'ai donc corrigé mon .gitignore(je l'utilise comme liste blanche à la place) et le docker a copié le fichier.

[J'ai ajouté la réponse car je n'ai pas assez de réputation pour commenter]

J'ai eu ce problème même si mon répertoire source était dans le bon contexte de construction. J'ai trouvé que la raison était que mon répertoire source était un lien symbolique vers un emplacement en dehors du contexte de construction.

Par exemple, mon Dockerfile contient les éléments suivants:

COPY dir1 /tmp

S'il dir1s'agit d'un lien symbolique, la COPYcommande ne fonctionne pas dans mon cas.

C'est donc arrivé à quelques reprises récemment. En tant que développeur .Net, en utilisant VisualStudio, j'ai changé le nom de ma version de en SomeThingen Somethingtant que nom de la DLL mais cela ne change pas le fichier .csproj qui resteSomeThing.csproj

Le Dockerfile utilise des noms de fichiers Linux sensibles à la casse, de sorte que le Dockerfile nouvellement généré automatiquement essayait de copier Something.csproj ce qu'il ne pouvait pas trouver. Donc, renommer manuellement ce fichier (en le rendant minuscule) a tout fonctionné

Mais ... voici un avertissement. Ce changement de nom de fichier sur mon ordinateur portable Windows n'est pas pris en charge par Git, donc la source du dépôt était toujours SomeThing.csprojsur le dépôt et pendant le processus CI / CD, la construction de Docker a échoué pour les mêmes raisons ...

J'ai dû changer le nom de fichier directement en tant que commit sur le dépôt ... petite solution de contournement méchante mais m'a permis de continuer

tl; dr Si sous Windows O / S, vérifiez le respect de la casse des noms de fichiers et sachez que les noms de fichiers locaux ne sont pas pris en compte en tant que changement Git, alors assurez-vous que votre dépôt est également modifié si vous utilisez CI / CD

Quelques bonnes réponses ici déjà. Ce qui a fonctionné pour moi, c'est de déplacer les commentaires à la ligne suivante.

MAUVAIS :

WORKDIR /tmp/app/src # set the working directory (WORKDIR), so we can reference program directly instead of providing the full path.
COPY src/ /tmp/app/src/ # copy the project source code

BON :

WORKDIR /tmp/app/src
  # set the working directory (WORKDIR), so we can reference program directly instead of providing the full path.
COPY src/ /tmp/app/src/
  # copy the project source code