Moby: COPIAR com arquivos excluídos não é possível

Consulte https://docs.docker.com/reference/builder/#dockerignore -file
Você pode adicionar entradas a um arquivo .dockerignore na raiz do projeto.

.dockerignore não resolve esse problema. Como escrevi, "a outra parte está sujeita a outra CÓPIA".

Então você quer copiar condicionalmente com base em alguma outra cópia?

O contexto contém muitos diretórios A1...A10 e um diretório B. A1...A10 tem um destino, B tem outro:

COPY A1 /some/where/A1/
COPY A2 /some/where/A2/
...
COPY A10 /some/where/A10/
COPY B some/where/else/B/

E isso é estranho.

Que parte disso é estranho? Listando todos eles individualmente?

COPY A* /some/where/
COPY B /some/where/else/

Isto funciona?

Os nomes A1..A10, B eram falsos. Além disso, COPY A* ... junta o _contents_ dos diretórios.

Existem algumas opções, admito, mas acho que todas são estranhas. Mencionei três na minha postagem original. Uma quarta opção é reorganizar meu código-fonte permanentemente para que A1..A10 seja movido para um novo diretório A. Eu esperava que isso não fosse necessário porque um nível de aninhamento adicional não é algo a desejar, e minhas ferramentas atuais precisavam caso especial meus projetos dockerizados então.

(BTW, # 6094 (seguindo links simbólicos) ajudaria neste caso. Mas, aparentemente, isso também não é uma opção.)

@bronger se COPY se comportasse exatamente como cp , isso resolveria seu caso de uso?

Não sei se entendi 100%.
Talvez @duglin possa dar uma olhada.

@bronger Acho que @cpuguy83 fez a pergunta certa, como você resolveria isso se estivesse usando 'cp'? Eu olhei e não notei algum tipo de opção de exclusão em 'cp', então não tenho certeza de como você resolveria isso fora de uma 'compilação do docker'.

Com comportamento cp, eu poderia melhorar a situação dizendo

COPY ["A1", ... "A10", "/some/where/"]

Ainda é um problema de manutenção leve, porque eu teria que pensar nessa linha se adicionasse um diretório "A11". Mas isso seria aceitável.

Além disso, cp não precisa de exclusões, porque copiar tudo e remover as partes indesejadas quase não tem impacto no desempenho além da própria cópia. Com COPY do docker, significa cache invalidado incorretamente toda vez que B é alterado e imagens maiores.

@bronger você pode fazer:

COPY a b c d /some/where

exatamente como você estava sugerindo.

Quanto a fazer um RUN rm ... após o COPY ... , sim, você terá uma camada extra, mas ainda poderá usar o cache. Se você vir uma falha de cache devido a isso, me avise, acho que não deveria.

Mas

COPY a b c d /some/where/

copia o conteúdo dos diretórios abcd juntos, em vez de criar os diretórios /some/where/{a,b,c,d}. Funciona como rsync com uma barra anexada ao diretório src. Portanto, as _quatro_ instruções

COPY a /some/where/a/
COPY b /some/where/b/
COPY c /some/where/c/
COPY d /some/where/d/

são precisos.

Quanto à cache...se digo

COPY . /some/where/
RUN rm -Rf /some/where/e

então o cache não é usado se e mudar, embora e não seja efetivamente incluído na operação.

@bronger sim, infelizmente você está correto. Acho que poderíamos adicionar um tipo de sinalizador --exclude zzz , mas por https://github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntax, pode não obter muito tração agora.

É justo. Então vou usar um COPY+rm por enquanto e adicionar um comentário FixMe. Obrigado pelo seu tempo!

Apenas para :+1: este problema. Lamento regularmente que COPY não espelhe a semântica de barra à direita do rsync. Isso significa que você não pode COPIAR vários diretórios em uma única instrução, levando à proliferação de camadas.

Eu encontro regularmente um caso em que eu quero copiar muitos diretórios, exceto um (que será copiado mais tarde, porque eu quero que ele tenha diferentes efeitos de invalidação de camada), então --exclude também seria útil.

Além disso, de man rsync :

       A trailing slash on the source changes this behavior to avoid  creating
       an  additional  directory level at the destination.  You can think of a
       trailing / on a source as meaning "copy the contents of this directory"
       as  opposed  to  "copy  the  directory  by name", but in both cases the
       attributes of the containing directory are transferred to the  contain‐
       ing  directory on the destination.  In other words, each of the follow‐
       ing commands copies the files in the same way, including their  setting
       of the attributes of /dest/foo:

              rsync -av /src/foo /dest
              rsync -av /src/foo/ /dest/foo

Eu acho que não pode ser alterado agora sem quebrar um monte de Dockerfile s.

Como exemplo concreto, digamos que eu tenha um diretório assim:

/vendor
/part1
/part2
/part3
/...
/partN

Eu quero algo parecido com:

COPY /vendor /docker/vendor
RUN /vendor/build
COPY /part1 /part2 ... /partN /docker/ # copy directories part1-N to /docker/part{1..N}/
RUN /docker/build1-N.sh

Portanto, essa parte1-N não invalida a construção de /vendor . (já que /vendor raramente é atualizado em comparação com part1-N).

Eu já trabalhei em torno disso colocando part1-N em seu próprio diretório, então:

/vendor
/src/part1-N

Mas também encontrei esse problema em projetos que não tenho liberdade para reorganizar tão facilmente.

@praller bom exemplo, estamos enfrentando exatamente o mesmo problema. O principal problema é que o filepath.Match do Go não permite muita criatividade em comparação com expressões regulares (ou seja, nenhum anti padrão)

Acabei de criar uma solução um pouco maluca para isso. COPY não pode excluir diretórios, mas ADD _can_ expand tgz.

É uma etapa extra de construção:
tar --exclude='./deferred_copy' -czf all_but_deferred.tgz .
construção do docker...

Em seguida, no seu Dockerfile:
ADD ./all_but_deferred.tgz /application_dir/
.. coisas nas camadas que raramente mudam ..
ADICIONAR . /application_dir/
.. coisas nas camadas que mudam frequentemente

Isso fornece a sintaxe completa do tar para incluir/excluir/qualquer coisa sem muitas camadas desperdiçadas tentando incluir/excluir.

@jason-kane Este é um bom truque, obrigado por compartilhar. Um pequeno ponto: parece que você não pode adicionar o sinalizador z (gzip) a tar — ele altera o valor da soma de verificação sha256, o que invalida o cache do Docker. Caso contrário, essa abordagem funciona muito bem para mim.

+1 para este problema, acho que poderia ser suportado da mesma forma que muitas bibliotecas glob o suportam:

Aqui está uma proposta para copiar tudo, exceto node_modules

COPY . /app -node_modules/

Também me deparo com o mesmo problema, e é meio doloroso para mim quando meus aplicativos da Web Java têm cerca de 900 MB, mas quase 80% disso raramente é alterado.
É um estado inicial do meu aplicativo e a estrutura de pastas é um pouco estável, então não me importo de adicionar a camada 6-7 COPY para poder usar o cache, mas certamente prejudicará a longo prazo quando mais e mais arquivos e diretórios são adicionados

👍

Eu tenho o mesmo problema, embora com docker cp , quero copiar todos os arquivos de uma pasta, exceto um

Exatamente o mesmo problema aqui. Eu quero copiar um repositório git e excluir o diretório .git.

@oaxlin você pode usar o arquivo .dockerignore para isso.

@antoineco tem certeza que vai dar certo? Já faz um tempo desde que eu tentei, mas tenho certeza que .dockerignore não funcionou com docker cp , pelo menos na época

@kkozmic-seek absolutamente certo :) Mas o subcomando docker cp CLI que você mencionou é diferente da instrução COPY encontrada no Dockerfile, que é o escopo deste problema.

docker cp não tem nada a ver com Dockerfile e . dockerignore, mas por outro lado não é usado para construir imagens.

Gostaria muito disso também - para acelerar a compilação, eu poderia copiar alguma pasta em partes anteriores da compilação e, em seguida, o cache me ajudaria ...

Não tenho certeza se entendi qual é o caso de uso, mas não basta tocar nos arquivos para excluir antes que COPY resolva o problema?

RUN touch /app/node_modules
COPY . /app
RUN rm /app/node_modules

AFAIK COPY não substitui o arquivo e é por isso que acho que isso pode funcionar.

Ops, não importa, parece que COPY na verdade substitui os arquivos. Agora estou um pouco confuso com https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ que npm instala e depois faz um COPY . /usr/src/app . Eu acho que ele assume que node_modules é ignorado pelo docker? Por outro lado, ter um comando COPY_NO_OVERWRITE (melhor nome necessário) pode ser uma maneira de ignorar arquivos durante a cópia (você teria que criar arquivos/diretórios vazios para coisas que deseja ignorar).

FWIW, eu acho isso muito feio.

Encontrei outra solução de hack:

Exemplo de estrutura de projeto:
aplicativo/
configuração/
roteiro/
especificação/
estático/
...

Nós queremos:

1. Copiar estático/
2. Copiar outros arquivos
3. Copiar aplicativo/

Solução de hack:
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

O segundo ADD é equivalente a: copiar tudo, exceto "./st " e "./a ".
Alguma ideia de melhorias?

Qual é o status do comentário ?

👍

👍

👍

👍

que tal ter um arquivo .dockerignore da mesma forma que .gitignore?

@mirestrepo Veja os dois primeiros acompanhamentos desta edição.

Atualmente este é um nerf mega perf para desenvolvimento C#/dotnet.

O que eu quero:

• Primeiro copie todas as dll's externas para as imagens do docker (tudo exceto My*.dll)
• Em seguida, copie todas as minhas dll's (começando com My.*.dll).

Agora parece que isso não é (facilmente) possível porque não posso copiar tudo, exceto.

Portanto, ou as dlls são copiadas em dobro, o que aumenta o tamanho do arquivo docker ou tudo é copiado em uma camada.
O último sendo um mega nerf porque as dlls externas são copiadas sempre em vez de armazenadas em cache.

@adresdvila obrigado pela solução em que consegui dividi-la:

COPY ["[^M][^y]*","/app/"] 
COPY ./My* /app/

Embora isso ainda deixe o problema de que os arquivos .json são copiados no primeiro comando

Apenas entrando em contato para agradecer a @antoineco meu problema está resolvido. Não copio mais o diretório .git em minhas imagens docker.

Isso melhorou drasticamente o tamanho da imagem e torna minha imagem muito mais amigável para o sistema de cache do docker.

Eu tenho o mesmo problema. Eu tenho um arquivo grande que quero copiar antes do resto dos arquivos para que qualquer alteração no contexto não o repita, pois leva muito tempo para copiar (arquivo bin de 7 GB). Existem novas soluções alternativas?

O problema com a abordagem COPY and prune é que a camada antes da poda ainda continua a ter todos os dados.

COPY . --exclude=a --exclude=b seria extremamente útil. O que você acha, @cpuguy83?

@Nowaker eu gosto. Parece em linha com tar e rsync qualquer maneira.
Eu acho que isso deve suportar o mesmo formato que dockerignore?

@tonistiigi @dnephin

Este caso seria tratado por # 32507 eu acho.

@cpuguy83 Sim. Mais notavelmente, de acordo com COPY --chown=uid:gid

@dnephin RUN --mount soa como um caso de uso totalmente diferente, centrado em gerar algo baseado em dados que não precisamos depois que a saída foi gerada. (Por exemplo, compilando com Go, gerando HTMLs a partir do arquivo Markdown, etc). RUN --mount é ótimo e eu definitivamente o usaria no projeto em que estou trabalhando atualmente (gerando documentos de API usando Sphinx).

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 é centrado na cópia de dados que precisam terminar na imagem, mas espalhados por várias instruções COPY, não apenas uma. O objetivo é evitar COPY first second third .... eleventh destination/ explícito quando o projeto tem muitos diretórios na raiz e está sujeito a alteração/aumento.

No meu caso, quero copiar a maioria dos arquivos, exceto aqueles que não são essenciais, primeiro para garantir que o cache seja usado se os arquivos de origem não forem alterados. Em seguida, compile/gere - e use o cache se os arquivos copiados não forem alterados (yay). No início, copie os arquivos que excluí anteriormente, que podem ter sido alterados desde a compilação anterior, mas sua alteração não afeta a compilação/geração. Obviamente, eu tenho uma tonelada de arquivos e diretórios em . que eu quero COPIAR primeiro, e apenas alguns que eu quero COPIAR em algum lugar no final.

A ideia é que RUN --mount seja capaz de resolver muitos problemas. COPY --exclude resolve apenas um único problema.

Prefiro adicionar algo que resolva muitos problemas do que adicionar um monte de sintaxe para resolver problemas individuais. Você usaria RUN --mount... rsync --exclude ... (ou algum script que copia coisas individuais) e seria o equivalente a COPY --exclude .

@dnephin Oh, eu não pensei em RUN --mount rsync ! Excelente! 👍

Isso é excelente mesmo. No entanto, você não poderá aproveitar o cache de forma eficiente @Nowaker , porque o cache será invalidado se algo mudar no diretório montado, não apenas o que você deseja rsync.

Se você usar a saída desse rsync como entrada para outra coisa e nenhum arquivo realmente for alterado, o cache será ativado novamente. Se você estiver realmente pronto para isso, pode fazer isso atualmente com algo como https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140 . A única mudança em RUN --mount (ou LLB no buildkit) é que você não precisa copiar arquivos entre os estágios, mas pode acessá-los diretamente, por isso é muito mais rápido.

Que tal usar https://docs.docker.com/develop/develop-images/multistage-build/?

FROM php:7.2-apache as source
COPY ./src/ /var/www/html/
RUN rm -rf /var/www/html/vendor/
RUN rm -rf /var/www/html/tests/

FROM php:7.2-apache
COPY --from=source /var/www/html/ /var/www/html/

@antoineco Welp, então não é mais excelente. Obrigado por indicar..

@MartijnHols Esta é uma boa solução alternativa. Obrigado por publicar.

Para os mantenedores: dito isso, poderíamos dizer "por que implementar --chown em COPY, você pode usar RUN chown em uma compilação de vários estágios". Precisamos de --exclude para a sanidade. Há muitas soluções alternativas no Dockerfiles atualmente.

Eu tenho um caso de uso que se beneficiaria de COPY --exclude . Eu tenho uma pasta de big data que precisa ser copiada para o contêiner em sua totalidade. O conteúdo desse diretório está sujeito a alterações frequentes. Para melhorar o desempenho do cache, há um único arquivo grande no diretório que desejo copiar em sua própria camada, antes de copiar o restante. A partir de agora, é desnecessariamente verboso descrever esse tipo de contêiner.

Qual é a maneira correta de usar o cache em camadas centrado em requirements.txt

Eu tenho isto:

/root-app
 - /Dockerfile
 - /requirements.txt
 - /LICENSE
 - /helloworld.py
 - /app-1
     -/app-1/script1
     -/app-1/script2
     -/app-1/script3
 - /app-2
     -/app-2/script1

E Dockerfile:

FROM python:slim
COPY ./requirements.txt /
RUN pip install --trusted-host pypi.python.org -r /requirements.txt
WORKDIR /root-app
COPY . /helloworld
CMD ["python", "helloworld.py"]

Qual é a maneira correta de usar o segundo comando COPY para excluir o cache de compilação de requisitos ... e, da mesma forma, sobrepor meu app-1 e app-2 se eles não mudarem muito?

@axehayz Não tenho certeza se é isso que você está perguntando, mas eu faria algo semelhante ao fluxo de trabalho do nó em https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8.

Ou seja, não há problema em sua segunda cópia ser apenas COPY . ; contanto que seu pip install venha antes, isso não invalidará o cache dos pacotes instalados.

Enfrentou o mesmo problema. No momento eu preferiria expandir os arquivos em diretórios diferentes.

Eu tenho outro caso para COPY --exclude=... --exclude=...

Estou tentando fazer um COPY --from=oldimage para diminuir o tamanho da minha imagem e preciso copiar a maioria dos arquivos, mas sem alguns deles. Eu posso fazer isso diretório por diretório, o que é doloroso, mas funciona... Mas ser capaz de --excluir uma lista de diretórios/arquivos ou fornecer várias opções --exclude seria muito melhor e mais fácil de manter.

Então, depois de três anos e meio, não há nenhum reconhecimento?

@asimonf Há toneladas de reconhecimento e idas e vindas para entender o caso de uso. Eu suponho que você quer dizer que ninguém fez este trabalho? Está correto. Todos nós temos que fazer escolhas sobre as coisas em que trabalhamos.

Honestamente, isso pode ser feito facilmente usando a funcionalidade existente, mesmo que isso signifique que você precise escrever um pouco mais em seu Dockerfile para que isso aconteça.

# haven't tested exact syntax, but this is the general idea
FROM myRsync AS files
COPY . /foo
RUN mkdir /result && rsync -r --exclude=<pattern> /foo/ /result/

FROM scratch
COPY --from=files /result/* /

Com buildkit você nem precisa de um estágio extra

#syntax=docker/dockerfile:experimental
..
RUN --mount=target=/ctx rsync ... /ctx/ /src/

A menos que eu esteja perdendo algo usando uma compilação de vários estágios, não parece a solução aqui. O cache ainda é invalidado no estágio COPY.

A menos que eu esteja perdendo algo usando uma compilação de vários estágios, não parece a solução aqui. O cache ainda é invalidado no estágio COPY.

Isto está certo. Como é o problema que estou tendo agora.

Multi-estágio funciona muito bem para mim.

Estou dividindo minha compilação em vários estágios, para aproveitar totalmente o cache, é algo assim:

FROM alpine as source

WORKDIR /app
COPY . ./
RUN scripts/stagify-files

FROM node:12.4.0

WORKDIR /app

# Step 0: Setup environments
COPY --from=source /app/stage0 ./
RUN stage0-build.sh

# Step 1: Install npm packages
COPY --from=source /app/stage1 ./
RUN stage1-build.sh

# Step 2: Build project
COPY --from=source /app/stage2 ./
RUN stage2-build.sh

@zenozen o desafio com esse processo é que você teve que organizar o layout do aplicativo especificamente para uma compilação do docker, algo que muitas pessoas não querem fazer.
O uso do docker é uma das muitas considerações a serem equilibradas ao descobrir como fazer o layout dos arquivos do aplicativo (por exemplo, capacidade de manutenção, facilidade de uso para novos contratados, padrões entre projetos, requisitos de estrutura etc.).

@cfletcher Não tenho certeza se entendi completamente o que você quer dizer.

Para a mudança que mencionei acima, eu realmente movi meu Dockerfile para um sub-subdiretório (o que me causou muitos problemas ao tentar usar o rsync para estagificar esses arquivos), o que significa que eu estava tentando ocultar meu Dockerfile.

A abordagem que propus é geral, como imagino. Digamos que você tenha 100 arquivos em seu projeto. Ele simplesmente escolhe 1 deles fazendo o estágio 0, então 1+10 deles para fazer o estágio 1, e então todos os 100 para formar o estágio 2. Cada estágio é empilhado em cima do anterior e tem um comando de compilação diferente. Para uma estrutura de projeto complicada, significa apenas que a lógica de stagify-files seria complicada.

Para mim, o maior motivo é que divido meu código em módulos e preciso de todos os arquivos package.json copiados antes de executar npm install .

Também gostaria de algum tipo de argumento de exclusão para cópia. Temos mais de 20 arquivos e mais de 10 diretórios no diretório raiz. Nós codificamos fortemente em 2 dos diretórios e alguns dos arquivos. Eu gostaria de dividi-los em duas camadas COPY. Um para os arquivos e diretórios estáticos que nunca tocamos e o outro para os arquivos e diretórios que sempre tocamos.

É muito triste que isso ainda esteja sendo ignorado. Isso teria me ajudado a economizar 5 minutos por compilação se eu pudesse excluir UM diretório para não invalidar o cache.

Com buildkit, o cache não depende da imagem pai, como é pré-buildkit.
Então, sim, com a solução rsync mencionada, você sofrerá um golpe, pois precisará sincronizar toda vez que houver alguma alteração, mas os estágios subsequentes serão armazenados em cache com base no conteúdo e, se o conteúdo do que for transferido não for alterado. .. pelo menos na minha teoria completa no local, esses estágios devem usar o cache.

É triste adicionar um simples sinalizador --exclude a COPY ser tão difícil de vender. Está no TOP30 dos tickets mais votados e uma implementação relativamente fácil em comparação com outros tickets TOP30. :(

Não é controverso, requer trabalho.

@cpuguy83 Oba. Parecia controverso / um tanto rejeitado. Isso significa que um PR adequado com COPY --exclude provavelmente seria aceito, se passasse pelos padrões de qualidade?

Não posso falar por todos os mantenedores, mas falei com @tonistiigi há um mês ou mais sobre isso e o IIRC o maior obstáculo como isso se relaciona com o dockerignore, a sintaxe etc. (e o fato do dockerignore ser sintaticamente insuficiente).

A mudança precisaria entrar no buildkit.

Upvoting COPY --exclude=... --exclude=... - também necessário no meu caso de um repositório monolítico

Aprovando! Eu tentei com COPY !(excludedfile) . que deve funcionar no Bash, mas não no Docker

Eu não gosto das sugestões de ter que repetir tudo dentro do arquivo .dockerignore para cada instrução COPY no Dockerfile . Ser capaz de permanecer SECO com o que vai fazer parte da imagem e não deve ser uma prioridade, imho.

Olhando para #33923, não acho que seja coincidência que o que você deseja excluir do contexto de compilação seja exatamente a mesma coisa que você deseja excluir das instruções COPY . Acredito que algo assim seria uma boa solução:

COPY --use-dockerignore <source> <target>

Ou talvez até algo assim:

COPY --use-ignorefile=".gitignore" <source> <target>

Vendo como .dockerignore já é uma reprodução de 90% de .gitignore , parece ainda mais irritante ter que repetir todos os arquivos e pastas ignorados novamente para cada instrução COPY . Tem que haver uma maneira melhor.

@asbjornu .gitignore e .dockerignore não são a mesma coisa. Especialmente para compilações de vários estágios em que os artefatos são gerados em um estágio de compilação e não estão presentes no git, no entanto, devem ser incluídos na imagem resultante.
E sim, com as compilações multiestágio introduzidas DEVE HAVER a capacidade de usar diferentes arquivos .dockerignore por estágio - absolutamente.

Muitas vezes, quero copiar fora da "compilação do docker". Nesses casos, .dockerignore não faz nada. Precisamos de uma alteração para "docker cp" é a única solução sensata

Faz 5 anos que esta questão foi aberta. Em setembro de 2020, ainda quero isso. Muitas pessoas sugeriram hacks para contornar, mas quase todos eles e outros solicitaram o sinalizador exclude de uma forma ou de outra. Por favor, não deixe este problema ficar sem solução por mais tempo agora.

Se você quer algo, você precisa trabalhar nisso ou encontrar alguém para trabalhar nisso.

Se você quer algo, você precisa trabalhar nisso ou encontrar alguém para trabalhar nisso.

Primeiro precisamos saber se o upstream quer isso.

https://github.com/moby/moby/issues/15771#issuecomment -550571058

Após a revisão do código-fonte, acho que devemos estender a função de cópia aqui https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go em primeiro lugar. Depois disso, podemos estender o backend.go na libsolver, e somente depois será possível estender o AST e o frontend do buildkit.
Mas depois disso, a cópia estará próxima da semântica rsync do que o unix cp.

ATUALIZAÇÃO: sim, depois de estender copy.go tudo estará próximo a https://github.com/moby/buildkit/pull/1492 mais a lista de exclusões de análise.