Problème Docker COPY - "aucun fichier ou répertoire"
Dans mon Dockerfile, j'ai la déclaration "COPY" suivante:
# Copy app code
COPY /srv/visitor /srv/visitor
Il va sans dire que dans mon système Host, sous le répertoire "/ srv/visitor", il y a bien mon code source:
[root@V12 visitor]# ls /srv/visitor/
Dockerfile package.json visitor.js
Maintenant, lorsque j'essaie de créer une image à l'aide de ce Dockerfile, il se bloque à l'étape où la "COPIE" est censée se produire:
Step 10 : COPY /srv/visitor /srv/visitor
INFO[0155] srv/visitor: no such file or directory
Il dit qu'il n'y a pas un tel répertoire, mais il y en a clairement.
Des idées?
MISE À JOUR 1:
On m'a fait remarquer que je me trompais, dans ma façon de comprendre le contexte de construction. La suggestion revenait à changer la déclaration "COPY" en ceci:
COPY . /srv/visitor
Le problème est que je l'ai eu de cette façon, et le processus de construction s'est arrêté à l'étape suivante:
RUN npm install
Il a dit quelque chose comme "aucun fichier package.json trouvé", quand il y en a clairement un.
MISE À JOUR 2:
J'ai essayé de l'exécuter avec ce changement dans le Dockerfile:
COPY source /srv/visitor/
Il s'est arrêté lors de la tentative d'exécution de npm:
Step 12 : RUN npm install
---> Running in ae5e2a993e11
npm ERR! install Couldn't read dependencies
npm ERR! Linux 3.18.5-1-Arch
npm ERR! argv "/usr/bin/node" "/usr/sbin/npm" "install"
npm ERR! node v0.10.36
npm ERR! npm v2.5.0
npm ERR! path /package.json
npm ERR! code ENOPACKAGEJSON
npm ERR! errno 34
npm ERR! package.json ENOENT, open '/package.json'
npm ERR! package.json This is most likely not a problem with npm itself.
npm ERR! package.json npm can't find a package.json file in your current directory.
npm ERR! Please include the following file with any support request:
npm ERR! /npm-debug.log
INFO[0171] The command [/bin/sh -c npm install] returned a non-zero code: 34
Alors, la copie a-t-elle été réalisée? Si oui, pourquoi npm est-il incapable de trouver package.json?
De la documentation:
Le
<src>chemin doit être dans le contexte de la construction; vous ne pouvez pas COPIER ../quelque chose/quelque chose, car la première étape d'une construction de docker consiste à envoyer le répertoire de contexte (et ses sous-répertoires) au démon de docker.
Lorsque vous utilisez /srv/visitor vous utilisez un chemin absolu en dehors du contexte de construction même s'il s'agit en fait du répertoire courant.
Vous feriez mieux d'organiser votre contexte de construction comme ceci:
├── /srv/visitor
│ ├── Dockerfile
│ └── resources
│ ├── visitor.json
│ ├── visitor.js
Et utilise :
COPY resources /srv/visitor/
Remarque:
docker build - < Dockerfile n'a pas de contexte.
D'où l'utilisation,
docker build .
Pour moi, le répertoire était dans le bon contexte, seulement il était inclus dans le (caché) .dockerignore fichier à la racine du projet. Cela conduit au message d'erreur:
lstat mydir/myfile.ext: no such file or directory
Pour moi, le problème était que j'utilisais docker build - < Dockerfile
De la documentation Remarque: Si vous construisez en utilisant STDIN (docker build - < somefile), il n'y a pas de contexte de génération, donc COPY ne peut pas être utilisé.
Comme l'a dit Xavier Lucas [extrêmement utile], vous ne pouvez pas utiliser COPY ou ADD à partir d'un répertoire en dehors de votre contexte de construction (le dossier à partir duquel vous "docker build" doit être le même répertoire que votre .Dockerfile). Même si vous essayez d'utiliser un lien symbolique, cela ne fonctionnera pas.
Remarque: Ceci est spécifique à POSIX (Linux, Unix, Mac, éventuellement sous-système Linux pour Windows). Vous pourrez peut-être faire de même dans Windows en utilisant JUNCTION.
cd ~/your_docker_project/
cp -al /subfolder/src_directory ./
echo "COPY src_directory /subfolder/" >> Dockerfile
Danger: Cette utilisation rendra votre projet Docker spécifique à l'hôte. Vous ne voulez presque jamais faire ça! Manipuler avec soin.
Application: apprendre, expérimenter dans un environnement de développement
Cela a fait l'affaire pour moi. cp -al copie la structure du répertoire et crée des liens physiques pour tous les fichiers. Lorsque vous avez terminé, exécutez "rm -rf ./src_directory" pour le supprimer.
Je rencontrais ce problème et j'ai découvert que j'étais en mesure d'ajouter un contexte à la variable de construction afin de charger mes Dockerfile (s) à partir d'autres répertoires. Cela m'a permis de changer un peu plus la structure de mon fichier Docker par défaut à mon goût. Voici un extrait de mon docker-compose.yml:
version: '3'
services:
webserver:
build:
context: .
dockerfile: ./server/Dockerfile
...
En ajoutant le contexte, j'ai pu définir où les fichiers doivent être référencés. Vous pouvez référencer les documents Docker ici: https://docs.docker.com/compose/compose-file/#context
J'espère que cela t'aides!
Pour l'erreur suivante,
COPY failed: stat
Je l'ai eu en redémarrant le service docker.
Non seulement le fichier doit se trouver dans un répertoire du contexte de génération actuel, mais le fichier ne peut pas non plus être un lien logiciel vers un fichier en dehors du contexte de génération.
J'avais un lien vers un fichier dans mon répertoire personnel et le lien se trouvait dans le répertoire du projet. Après avoir supprimé le lien et déplacé le fichier lié dans le projet (rm mylink ; mv ~/myrealfile ./), puis ça a marché.
Cela m'est arrivé en essayant d'exécuter le fichier Docker à partir d'un répertoire différent.
J'avais le COPY failed: stat /var/lib/docker/tmp/docker-builder929708051/XXXX: no such file or directory et a réussi à résoudre ce problème en spécifiant le fichier Docker.
Fonctionnement docker build . -f docker/development/Dockerfile travaillé.
Mais l'exécution de Runningdocker build docker/development/Dockerfile` a provoqué ce problème.
-f ou --file pour spécifier le nom et l'emplacement du Dockerfile.
Cela m'a paru étrange au début parce que lorsque j'avais le Dockerfile dans le répertoire racine des applications, cela fonctionnait bien. Cela vous aidera si vous souhaitez gérer un peu mieux les fichiers de votre environnement Docker.
J'ai finalement résolu ce problème dans mon cas était Dockerfile qui exécute la copie à un niveau plus profond du projet. J'ai donc réalisé que le chemin de génération de l'hôte est exprimé par rapport à l'emplacement du fichier Dockerfile.
Pour moi, le problème était que le nom de fichier que j'ajoutais avait un espace de fin. Un renommage l'a corrigé.