1
votes

La commande COPY échoue

J'ai été bloqué à ce sujet au cours des 3 derniers jours. Je construis une image dans un docker et La commande de copie échoue car le bon répertoire n’est pas trouvé.

Building users
Step 1/6 : FROM python:3.6.7-alpine
 ---> cb04a359db13
Step 2/6 : WORKDIR /usr/src/app
 ---> Using cache
 ---> 06bb39a49444
Step 3/6 : COPY ./requirements.txt /usr/src/app/requirements.txt
ERROR: Service 'users' failed to build: COPY failed: stat /var/snap/docker/common/var-lib-docker/tmp/docker-builder353668631/requirements.txt: no such file or directory

qui est exécuté par ce fichier docker-dev:

version: '3.7'

services:

  users:
    build:
      context: ./services/users
      dockerfile: Dockerfile-dev
  volumes:
    - './services/users:/usr/src/app'
  ports:
    - 5001:5000
  environment:
    - FLASK_APP=project/__init__.py
    - FLASK_ENV=development

et l’obtient erreur:

FROM python:3.6.7-alpine

WORKDIR /usr/src/app

COPY ./requirements.txt /usr/src/app/requirements.txt
RUN pip3 install -r requirements.txt

COPY . /usr/src/app

CMD python3 manage.py run -h 0.0.0.0

Je ne sais même pas par où commencer pour déboguer ceci. Lorsque j'ai essayé d'accéder au répertoire, cela m'a donné une erreur d'autorisation. J'ai donc essayé d'exécuter la commande avec sudo, ce qui n'a pas aidé. Des pensées?

docker dockerfile

5 commentaires

Y a-t-il un requirements.txt dans votre répertoire ./services/users ?

@larks Omg ... J'ai déplacé le fichier vers les utilisateurs et cela a fonctionné. Je pensais que c'était censé être dans le répertoire à partir duquel j'exécute le script. Je ne peux pas croire que j'ai été coincé sur cette erreur triviale pendant si longtemps.

Le fichier des exigences doit donc se trouver dans le même répertoire que celui vers lequel pointe l'attribut de contexte.

@BillyDarwin et bien c'est tout le but du contexte, si vous spécifiez un contexte, alors oui, les fichiers sont relatifs à lui. Si vous n'avez pas de contexte, alors le contexte est relatif à l'emplacement Dockerfile . docs.docker.com/compose/compose-file/#build

Et si vous n'utilisez pas docker-compose mais construisez l'image via docker build alors le contexte est ce seul paramètre que vous pouvez donner à la commande build docker build. # context est le répertoire actuel vs docker build / path / to / my / context

3 Réponses :

0
votes

Peu de retard pour répondre, mais deuxième commande COPY COPY. / usr / src / app remplace le contenu / usr / src / app généré par RUN pip3 install -r requirements.txt .

Essayez

FROM python:3.6.7-alpine

WORKDIR /usr/src/app

# install in temp directory
RUN mkdir /dependencies

COPY ./requirements.txt /dependencies/requirements.txt
RUN cd /dependencies && pip3 install -r requirements.txt

COPY . /usr/src/app

# copy generated dependencies
RUN cp -r /dependencies/* /usr/src/app/

CMD python3 manage.py run -h 0.0.0.0

1 commentaires

Ce ne serait un problème qu'avec les fichiers installés pip dans le répertoire actuel, et l'OP avait ces mêmes fichiers dans leur contexte de construction. Une commande de copie ne supprime pas les fichiers, et je pense que pip installera dans les répertoires utilisateur ou système plutôt que dans le répertoire de travail actuel.

0
votes

J'ai eu un problème similaire lors de la construction d'une image avec du béryllium, et j'ai résolu ce problème en la supprimant dans le .dockerignore

Sending build context to Docker daemon  12.92MB

Step 1/4 : FROM centos

 ---> 9f38484d220f

Step 2/4 : RUN yum install httpd -y

 ---> Using cache

 ---> ccdafc4ae476

Step 3/4 : COPY ./beryllium /var/www/HTML

 ---> 40ebc02992a9

Step 4/4 : CMD apachectl -DFOREGROUND

 ---> Running in dab0a406c89e

Removing intermediate container dab0a406c89e

 ---> 1bea741cfb65

Successfully built 1bea741cfb65

Successfully tagged apache:latest

Envoi du contexte de construction au démon Docker

$ sudo docker build -t apache .

0 commentaires

0
votes

Comme larsks le suggère dans son commentaire , vous avez besoin du fichier dans les services Répertoire / users . Pour comprendre pourquoi, il est utile de comprendre le «contexte».

Docker ne s'appuie pas sur le client, il ne voit pas votre répertoire actuel, ni d'autres fichiers sur votre système de fichiers. Au lieu de cela, le dernier argument de la commande de construction est passé en tant que contexte de construction. Avec docker-compose, ce contexte par défaut est le répertoire actuel, que vous verrez souvent comme . dans une commande docker build , mais vous pouvez le remplacer comme vous l'avez fait ici avec ./services/users comme contexte. Lorsque vous exécutez une build, la toute première étape consiste à envoyer ce contexte de build du client docker au serveur. Même lorsque le client et le serveur sont sur le même hôte (une valeur par défaut courante, en particulier pour les environnements de bureau), ce même processus se produit. Les fichiers répertoriés dans .dockerignore et les fichiers des répertoires parents vers le contexte de construction ne sont pas envoyés au serveur docker.

Lorsque vous exécutez un COPY ou ADD , le premier argument (ou tous les arguments sauf le dernier lorsque vous en avez plusieurs) font référence aux fichiers du contexte de construction, et le dernier argument est le fichier ou le répertoire de destination à l'intérieur de l'image. p >

Par conséquent, lorsque vous assemblez cette entrée de fichier de composition:

COPY ./requirements.txt /usr/src/app/requirements.txt

avec cette commande COPY:

build:
  context: ./services/users
  dockerfile: Dockerfile-dev

le COPY essaiera de copier le fichier requirements.txt à partir du contexte de construction généré à partir de ./services/users , ce qui signifie ./services/users/ requirements.txt doit exister et ne pas être exclu par un fichier .dockerignore dans ./services/users.

0 commentaires