Problema no Docker COPY - "esse arquivo ou diretório não existe"

No meu Dockerfile, tenho a seguinte instrução 'COPY':

# Copy app code
COPY /srv/visitor /srv/visitor

Não é necessário dizer que no meu sistema host, no diretório "/ srv / visitor", existe realmente o meu código-fonte:

[root@V12 visitor]# ls /srv/visitor/
Dockerfile  package.json  visitor.js

Agora, quando tento criar uma imagem usando esse Dockerfile, ela fica parada na etapa em que a "CÓPIA" deve acontecer:

Step 10 : COPY /srv/visitor /srv/visitor
INFO[0155] srv/visitor: no such file or directory

Ele diz que não existe esse diretório, mas claramente existe.

Alguma ideia?

ATUALIZAÇÃO 1:

Foi-me apontado que eu estava enganado, da maneira que entendi construir contexto. A sugestão foi alterar a declaração "COPY" para isso:

COPY . /srv/visitor

O problema é que eu o fiz dessa maneira, e o processo de criação foi interrompido na etapa seguinte:

RUN npm install

Dizia algo como "nenhum arquivo package.json encontrado", quando claramente existe um.

ATUALIZAÇÃO 2:

Tentei executá-lo com esta alteração no Dockerfile:

COPY source /srv/visitor/

Ele parou ao tentar executar o 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

Então, a cópia foi executada? Se sim, por que o npm não consegue encontrar o package.json?

A partir da documentação:

O <src>caminho deve estar dentro do contexto da construção ; você não pode COPIAR ../algo / algo, porque a primeira etapa de uma construção do docker é enviar o diretório de contexto (e subdiretórios) para o daemon do docker.

Quando você usa, /srv/visitorestá usando um caminho absoluto fora do contexto de construção, mesmo que seja realmente o diretório atual.

É melhor você organizar seu contexto de construção assim:

├── /srv/visitor
│   ├── Dockerfile
│   └── resources
│       ├── visitor.json
│       ├── visitor.js

E use :

COPY resources /srv/visitor/

Nota:

docker build - < Dockerfile não tem nenhum contexto.

Daí o uso,

docker build .

Para mim, o diretório estava no contexto correto, apenas foi incluído no .dockerignorearquivo (oculto) na raiz do projeto. Isso leva à mensagem de erro:

lstat mydir/myfile.ext: no such file or directory

Para mim, o problema era que eu estava usando docker build - < Dockerfile

Na documentação Nota: Se você construir usando STDIN ( docker build - < somefile), não haverá contexto de construção, portanto, COPY não poderá ser usado.

Como a resposta de Xavier Lucas [extremamente útil] afirmou, você não pode usar COPY ou ADD de um diretório fora do seu contexto de construção (a pasta na qual você executa o "docker build" deve ser o mesmo diretório que o arquivo .Docker). Mesmo se você tentar usar um link simbólico, ele não funcionará.

Nota: Isso é específico para POSIX (Linux, Unix, Mac, possivelmente Linux Subsystem for Windows). Você pode fazer o mesmo no Windows usando JUNCTION.

cd ~/your_docker_project/
cp -al /subfolder/src_directory ./
echo "COPY src_directory /subfolder/" >> Dockerfile

Perigo: Usar isso tornará seu projeto de janela de encaixe específico para o host. Você quase nunca quer fazer isso! Manuseie com cuidado.

Aplicação: Aprendizado, Experimentação em um ambiente de desenvolvimento

Isso fez o truque para mim. cp -al copia a estrutura de diretórios e cria links físicos para todos os arquivos. Quando terminar, execute "rm -rf ./src_directory" para removê-lo.

Eu estava com esse problema e descobri que era capaz de adicionar um contexto à variável de compilação para carregar meus Dockerfile (s) de outros diretórios. Isso me permitiu alterar minha estrutura de arquivos padrão do Docker um pouco mais ao meu gosto. Aqui está um trecho do meu docker-compose.yml:

version: '3'
services:
  webserver:
    build:
      context: .
      dockerfile: ./server/Dockerfile
    ...

Ao adicionar o contexto, pude definir onde os arquivos devem ser referenciados. Você pode consultar os documentos do Docker aqui: https://docs.docker.com/compose/compose-file/#context

Espero que isto ajude!

Para mim, o problema era que o nome do arquivo que eu estava adicionando tinha um espaço à direita. Uma renomeação corrigiu.

Para o seguinte erro,

COPY failed: stat

Eu resolvi isso reiniciando o serviço docker.

Finalmente resolvi esse problema no meu caso: o Dockerfile, que executa a cópia, estava em um nível mais profundo do projeto. Então, percebi que o caminho de construção do host é expresso em relação ao local do arquivo do Dockerfile.

Isso aconteceu comigo ao tentar executar o arquivo docker de um diretório diferente.

Eu tinha o COPY failed: stat /var/lib/docker/tmp/docker-builder929708051/XXXX: no such file or directorye consegui resolver isso especificando o arquivo docker.

Correr docker build . -f docker/development/Dockerfilefuncionou.

Mas a execução do Runningdocker build docker / development / Dockerfile` causou esse problema.

-fou --filepara especificar o nome e o local do Dockerfile.

Achei estranho no começo, porque quando eu tinha o Dockerfilediretório raiz do aplicativo, ele funcionou bem. Isso ajudará se você deseja gerenciar um pouco melhor os arquivos da janela de encaixe ambiente.

O arquivo não deve estar apenas em um diretório no contexto de compilação atual, mas também não pode ser um link flexível para um arquivo fora do contexto de compilação.

Eu tinha um link para um arquivo no meu diretório pessoal e o link estava no diretório do projeto. Depois de excluir o link e mover o arquivo vinculado para o projeto ( rm mylink ; mv ~/myrealfile ./), funcionou.

Para mim, foi um problema com o Google Cloud SDK:

https://code.google.com/p/google-cloud-sdk/issues/detail?id=1431