В моем Dockerfile у меня есть следующий оператор COPY:
# Copy app code
COPY /srv/visitor /srv/visitor
Само собой разумеется, что в моей хост-системе в каталоге «/ srv / visitor» действительно находится мой исходный код:
[root@V12 visitor]# ls /srv/visitor/
Dockerfile package.json visitor.js
Теперь, когда я пытаюсь создать образ с помощью этого файла Docker, он зависает на этапе, когда должно произойти «КОПИРОВАНИЕ»:
Step 10 : COPY /srv/visitor /srv/visitor
INFO[0155] srv/visitor: no such file or directory
Там написано, что такого каталога нет, но он явно есть.
Любые идеи?
ОБНОВЛЕНИЕ 1:
Мне указали, что я ошибался в том, как я понимал контекст сборки. Предложение сводилось к изменению выражения «COPY» на следующее:
COPY . /srv/visitor
Проблема в том, что у меня это было так, и процесс сборки остановился на следующем шаге:
RUN npm install
В нем говорилось что-то вроде «файла package.json не найдено», хотя он явно есть.
ОБНОВЛЕНИЕ 2:
Я попытался запустить его с этим изменением в Dockerfile:
COPY source /srv/visitor/
Он останавливался при попытке запустить 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
Итак, копия была выполнена? Если да, то почему npm не может найти package.json?
Для меня каталог был в правильном контексте, только он был включен в (скрытый) .dockerignore файл в корне проекта. Это приводит к сообщению об ошибке:
lstat mydir/myfile.ext: no such file or directory
Из документации:
В
<src>дорожка должен находиться в контексте сборки; вы не можете КОПИРОВАТЬ ../something / something, потому что первый шаг сборки докера - отправить контекстный каталог (и подкаталоги) демону докера.
Когда вы используете /srv/visitor вы используете абсолютный путь вне контекста сборки, даже если это фактически текущий каталог.
Вам лучше организовать контекст сборки следующим образом:
├── /srv/visitor
│ ├── Dockerfile
│ └── resources
│ ├── visitor.json
│ ├── visitor.js
И используйте:
COPY resources /srv/visitor/
Примечание:
docker build - < Dockerfile не имеет контекста.
Следовательно, используйте,
docker build .
Для меня проблема заключалась в том, что я использовал docker build - < Dockerfile
Из документация Примечание: если вы строите с использованием STDIN (docker build - < somefile), контекста сборки нет, поэтому COPY использовать нельзя.
Как заявил Ксавье Лукас [чрезвычайно полезный] ответ, вы не можете использовать COPY или ADD из каталога вне контекста сборки (папка, из которой вы запускаете «docker build», должна быть той же директорией, что и ваш .Dockerfile). Даже если вы попытаетесь использовать символическую ссылку, это не сработает.
Примечание. Это относится к POSIX (Linux, Unix, Mac, возможно, подсистема Linux для Windows). Вы можете сделать то же самое в Windows, используя JUNCTION.
cd ~/your_docker_project/
cp -al /subfolder/src_directory ./
echo "COPY src_directory /subfolder/" >> Dockerfile
Опасность: это сделает ваш проект докера специфичным для хоста. Вы почти никогда не захотите этого делать! Обращаться осторожно.
Применение: обучение, эксперименты в среде разработки
Это помогло мне. cp -al копирует структуру каталогов и создает жесткие ссылки для всех файлов. Когда вы закончите, запустите "rm -rf ./src_directory", чтобы удалить его.
Я столкнулся с этой проблемой и обнаружил, что смог добавить контекст в переменную сборки, чтобы загрузить свои файлы Docker из других каталогов. Это позволило мне немного изменить структуру файлов Docker по умолчанию по своему вкусу. Вот фрагмент из моего файла docker-compose.yml:
version: '3'
services:
webserver:
build:
context: .
dockerfile: ./server/Dockerfile
...
Добавив контекст, я смог определить, на какие файлы следует ссылаться. Вы можете ссылаться на документы Docker здесь: https://docs.docker.com/compose/compose-file/#context
Надеюсь это поможет!
Для следующей ошибки,
COPY failed: stat
Я получил это, перезапустив службу докеров.
Для меня проблема заключалась в том, что имя добавляемого файла имело конечный пробел. Это исправило переименование.
Я наконец решил эту проблему, в моем случае Dockerfile, который выполняет копирование, находится на более глубоком уровне проекта. Итак, я понял, что путь сборки хоста выражается относительно местоположения файла Dockerfile.
Это случилось со мной при попытке запустить файл докера из другого каталога.
У меня был COPY failed: stat /var/lib/docker/tmp/docker-builder929708051/XXXX: no such file or directory и удалось решить эту проблему, указав файл докера.
Бег docker build . -f docker/development/Dockerfile работал.
Но бег Runningdocker build docker / development / Dockerfile` вызвала эту проблему.
-f или --file указать название и местонахождение Dockerfile.
Сначала это показалось странным, потому что когда у меня Dockerfile в корневом каталоге приложений он работал нормально. Это поможет, если вы хотите немного лучше управлять файлами докеров среды.
Файл не только должен находиться в каталоге в текущем контексте сборки, но и не может быть программной ссылкой на файл вне контекста сборки.
У меня была ссылка на файл в моем домашнем каталоге, и ссылка находилась в каталоге проекта. После того, как я удалил ссылку и переместил связанный файл в проект (rm mylink ; mv ~/myrealfile ./), тогда это сработало.
Для всех, кому интересно, .gitignore также может вызвать проблему. В моем случае yarn.lock игнорировался. И это вызвало аналогичную ошибку.
Для меня это была проблема с Google Cloud SDK:
https://code.google.com/p/google-cloud-sdk/issues/detail?id=1431