Moby: COPY avec des fichiers exclus n'est pas possible

Voir https://docs.docker.com/reference/builder/#dockerignore -file
Vous pouvez ajouter des entrées à un fichier .dockerignore à la racine du projet.

.dockerignore ne résout pas ce problème. Comme je l'ai écrit, "l'autre partie fait l'objet d'une autre COPIE".

Donc, vous voulez copier conditionnellement en fonction d'une autre copie ?

Le contexte contient de nombreux répertoires A1...A10 et un répertoire B. A1...A10 ont une destination, B en a une autre :

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

Et c'est gênant.

Quelle partie de celui-ci est gênante ? Les énumérer tous individuellement ?

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

Est-ce que ça marche?

Les noms A1..A10, B étaient faux. De plus, COPY A* ... rassemble le _contenu_ des répertoires.

Il y a quelques options, je l'admets, mais je pense qu'elles sont toutes maladroites. J'en ai mentionné trois dans mon message initial. Une quatrième option consiste à réorganiser mon code source de façon permanente afin que A1..A10 soient déplacés dans un nouveau répertoire A. J'espérais que ce n'était pas nécessaire car un niveau d'imbrication supplémentaire n'est pas quelque chose à souhaiter, et mes outils actuels nécessaires pour cas particulier mes projets dockerisés alors.

(BTW, # 6094 (suivant les liens symboliques) aiderait dans ce cas. Mais apparemment, ce n'est pas non plus une option.)

@branger si COPY se comportait exactement comme cp , cela résoudrait-il votre cas d'utilisation ?

Je ne suis pas sûr de comprendre à 100%.
Peut-être que @duglin peut jeter un œil.

@branger Je pense que @cpuguy83 a posé la bonne question, comment résoudriez-vous cela si vous utilisiez 'cp' ? J'ai regardé et je n'ai pas remarqué une sorte d'option d'exclusion sur 'cp', donc je ne sais pas non plus comment résoudre ce problème en dehors d'une 'construction docker'.

Avec le comportement cp, je pourrais améliorer la situation en disant

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

C'est toujours un léger problème de maintenance car je devrais penser à cette ligne si j'ajoutais un répertoire "A11". Mais ce serait acceptable.

En outre, cp n'a pas besoin d'exclusions, car tout copier et supprimer les parties indésirables n'a pratiquement aucun impact sur les performances au-delà de la copie elle-même. Avec la copie de docker, cela signifie que le cache est invalidé à tort à chaque fois que B est modifié et que les images sont plus grandes.

@branger vous pouvez faire :

COPY a b c d /some/where

tout comme vous suggériez.

Quant à faire un RUN rm ... après le COPY ... , oui, vous aurez une couche supplémentaire, mais vous devriez toujours pouvoir utiliser le cache. Si vous voyez un manque de cache à cause de cela, faites-le moi savoir, je ne pense pas que vous devriez.

Mais

COPY a b c d /some/where/

copie le contenu des répertoires abcd ensemble, au lieu de créer les répertoires /some/where/{a,b,c,d}. Cela fonctionne comme rsync avec une barre oblique ajoutée au répertoire src. Par conséquent, les _quatre_ instructions

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

sont nécessaires.

Quant au cache... si je dis

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

alors le cache n'est pas utilisé si e change, bien que e ne soit pas effectivement inclus dans l'opération.

@branger oui , malheureusement tu as raison. Je suppose que nous pourrions ajouter un indicateur de type --exclude zzz , mais selon https://github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntax, il se peut qu'il n'y ait pas beaucoup de traction en ce moment.

Assez juste. Ensuite, je vais utiliser un COPY + rm pour le moment et ajouter un commentaire FixMe. Merci pour votre temps!

Juste pour :+1 : ce problème. Je regrette régulièrement que COPY ne reflète pas la sémantique de la barre oblique finale de rsync. Cela signifie que vous ne pouvez pas COPIER plusieurs répertoires dans une seule instruction, ce qui entraîne une prolifération des couches.

Je rencontre régulièrement un cas où je veux copier plusieurs répertoires sauf un (qui sera copié plus tard, car je veux qu'il ait différents effets d'invalidation de couche), donc --exclude serait également utile.

Aussi, à partir 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

Je suppose que cela ne peut pas être changé maintenant sans casser beaucoup de Dockerfile sauvages.

Comme exemple concret, disons que j'ai un répertoire ressemblant à ceci:

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

Je veux quelque chose qui ressemble à :

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

Ainsi, part1-N n'invalide pas la construction de /vendor . (puisque /vendor est rarement mis à jour par rapport à part1-N).

J'ai déjà contourné ce problème en mettant part1-N dans leur propre répertoire, donc:

/vendor
/src/part1-N

Mais j'ai également rencontré ce problème dans des projets que je ne suis pas libre de réorganiser aussi facilement.

@praller bon exemple, nous sommes confrontés exactement au même problème. Le principal problème est que filepath.Match de Go ne permet pas beaucoup de créativité par rapport aux expressions régulières (c'est-à-dire pas d'anti-modèle)

Je viens de trouver une solution de contournement un peu folle pour cela. COPY ne peut pas exclure des répertoires, mais ADD _can_ expand tgz.

C'est une étape de construction supplémentaire :
tar --exclude='./deferred_copy' -czf all_but_deferred.tgz .
construction de menu fixe ...

Puis dans votre Dockerfile :
AJOUTER ./all_but_deferred.tgz /application_dir/
.. des trucs dans les couches qui changent rarement ..
AJOUTER . /application_dir/
.. trucs dans les couches souvent changeantes

Cela donne la syntaxe complète de tar pour inclure/exclure/quoi que ce soit sans des tas de couches gaspillées essayant d'inclure/exclure.

@jason-kane C'est une belle astuce, merci pour le partage. Un petit point : il semble que vous ne puissiez pas ajouter le drapeau z (gzip) à tar — cela modifie la valeur de la somme de contrôle sha256, ce qui invalide le cache Docker. Sinon, cette approche fonctionne très bien pour moi.

+1 pour ce problème, je pense qu'il pourrait être pris en charge de la même manière que de nombreuses bibliothèques glob le prennent en charge :

Voici une proposition pour tout copier sauf node_modules

COPY . /app -node_modules/

Je rencontre également le même problème, et c'est un peu pénible pour moi lorsque mes applications Web Java pèsent environ 900 Mo, mais que près de 80% de celles-ci sont rarement modifiées.
C'est un état précoce de mon application et la structure des dossiers est quelque peu stable, donc cela ne me dérange pas d'ajouter une couche COPY 6-7 pour pouvoir utiliser le cache, mais cela fera sûrement mal à long terme lorsque de plus en plus de fichiers et de répertoires sont ajoutés

👍

J'ai le même problème bien qu'avec docker cp , je veuille copier tous les fichiers d'un dossier sauf un

Exactement le même problème ici. Je souhaite copier un référentiel git et exclure le répertoire .git.

@oaxlin , vous pouvez utiliser le fichier .dockerignore pour cela.

@antoineco es-tu sûr que ça marchera ? Cela fait un moment que j'ai essayé mais je suis presque sûr que .dockerignore n'a pas fonctionné avec docker cp , du moins à l'époque

@kkozmic-seek absolument sûr :) Mais la sous-commande CLI docker cp que vous avez mentionnée est différente de l'instruction COPY trouvée dans le Dockerfile, qui est la portée de ce problème.

docker cp n'a en effet rien à voir avec Dockerfile et . dockerignore, mais d'un autre côté, il n'est pas utilisé pour créer des images.

J'aimerais vraiment cela aussi - pour accélérer la construction, je pourrais copier un dossier dans les parties précédentes de la construction, puis le cache m'aiderait ...

Je ne suis pas sûr de comprendre quel est le cas d'utilisation, mais ne toucherait-il pas simplement les fichiers à exclure avant que COPY ne résolve le problème?

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

AFAIK COPY n'écrase pas le fichier, c'est pourquoi je pense que cela pourrait fonctionner.

Oups, tant pis, on dirait que COPY écrase en fait les fichiers. Je suis maintenant un peu perplexe devant https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ que npm installe puis fait un COPY . /usr/src/app . Je suppose que cela suppose que node_modules est ignoré par Docker ? D'un autre côté, avoir une commande COPY_NO_OVERWRITE (meilleur nom nécessaire) pourrait être un moyen d'ignorer les fichiers pendant la copie (vous devriez créer des fichiers/répertoires vides pour les éléments que vous souhaitez ignorer).

FWIW, je trouve cela très moche.

J'ai trouvé une autre solution de piratage:

Exemple de structure de projet :
application/
configuration/
scénario/
spécification/
statique/
...

Nous voulons:

1. Copier statique/
2. Copier d'autres fichiers
3. Copier l'application/

Solution de piratage :
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

Second ADD est équivalent à : copier tout, sauf "./st " et "./a ".
Des idées d'améliorations ?

Quel est le statut du commentaire ?

👍

👍

👍

👍

qu'en est-il d'avoir un fichier .dockerignore de la même manière que .gitignore ?

@mirestrepo Voir les deux premiers suivis de ce numéro.

Actuellement, il s'agit d'un méga nerf de performance pour le développement C # / dotnet.

Ce que je veux:

• Copiez d'abord toutes les dll externes dans les images docker (tout sauf My*.dll)
• Copiez ensuite toutes mes dll (en commençant par My.*.dll).

Maintenant, il semble que ce ne soit pas (facilement) possible car je ne peux pas tout copier sauf.

Ainsi, soit les dll sont copiées en double, ce qui augmente la taille du fichier docker, soit tout est copié en une seule couche.
Ce dernier étant un méga nerf car les DLL externes sont copiées à chaque fois au lieu d'être mises en cache.

@adresdvila merci pour la solution dans laquelle j'ai pu la scinder :

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

Bien que cela laisse toujours le problème que les fichiers .json sont copiés à la première commande

J'interviens juste pour dire merci à @antoineco mon problème est résolu. Je ne copie plus le répertoire .git dans mes images docker.

Cela a considérablement amélioré la taille de l'image et rend mon image beaucoup plus conviviale pour le système de mise en cache Docker.

J'ai le même problème. J'ai un gros fichier que je veux copier avant le reste des fichiers donc tout changement dans le contexte ne le répète pas car il prend beaucoup de temps à copier (fichier bin de 7 Go). Existe-t-il de nouvelles solutions de contournement ?

Le problème avec l'approche COPY et prune est que la couche avant l'élagage continue de contenir toutes les données.

COPY . --exclude=a --exclude=b serait extrêmement utile. Qu'en pensez-vous, @cpuguy83 ?

@Nowaker J'aime ça. Semble en ligne avec tar et rsync toute façon.
Je suppose que cela devrait prendre en charge le même format que dockerignore?

@tonistiigi @dnephin

Ce cas serait traité par #32507 je pense.

@ cpuguy83 Ouais. Plus particulièrement, conformément à COPY --chown=uid:gid

@dnephin RUN --mount ressemble à un cas d'utilisation totalement différent, centré sur la génération de quelque chose basé sur des données dont nous n'avons pas besoin après la génération de la sortie. (Par exemple, compiler avec Go, générer des HTML à partir d'un fichier Markdown, etc.). RUN --mount est dope et je l'utiliserais certainement dans le projet sur lequel je travaille actuellement (génération de documents API à l'aide de Sphinx).

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 est centré sur la copie de données qui doivent se retrouver dans l'image mais éparpillées sur plusieurs instructions COPY, pas une seule. L'objectif est d'éviter les COPY first second third .... eleventh destination/ explicites lorsque le projet a beaucoup de répertoires à la racine et qu'il est sujet à changement/augmentation.

Dans mon cas, je souhaite d'abord copier la plupart des fichiers, à l'exception de ceux qui ne sont pas essentiels, pour m'assurer que le cache est utilisé si les fichiers source n'ont pas changé. Ensuite, compilez/générez - et utilisez le cache si les fichiers copiés n'ont pas changé (yay). Au tout début, copiez les fichiers que j'ai exclus précédemment et qui auraient pu changer depuis la version précédente, mais leur modification n'affecte pas la compilation/génération. Évidemment, j'ai une tonne de fichiers et de répertoires en . que je veux COPIER en premier, et seulement quelques-uns que je veux COPIER quelque part à la fin.

L'idée est que RUN --mount est capable de résoudre beaucoup de problèmes. COPY --exclude ne résout qu'un seul problème.

Je préfère ajouter quelque chose qui résout beaucoup de problèmes plutôt que d'ajouter un tas de syntaxe pour résoudre des problèmes individuels. Vous utiliseriez RUN --mount... rsync --exclude ... (ou un script qui copie des choses individuelles) et ce serait l'équivalent de COPY --exclude .

@dnephin Oh, je n'ai pas pensé à RUN --mount rsync ! Excellent! 👍

C'est excellent en effet. Cependant, vous ne pourrez pas tirer parti efficacement de la mise en cache @Nowaker , car le cache sera invalidé si quelque chose change dans le répertoire monté, pas seulement ce que vous voulez rsync.

Si vous utilisez la sortie de ce rsync comme entrée pour autre chose et qu'aucun fichier n'y a été réellement modifié, le cache reprendra. Si vous êtes vraiment partant, vous pouvez le faire actuellement avec quelque chose comme https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140 . Le seul changement dans RUN --mount (ou LLB dans le kit de construction) est que vous n'avez pas à copier les fichiers entre les étapes, mais que vous pouvez y accéder directement, ce qui est beaucoup plus rapide.

Que diriez-vous d'utiliser 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, alors ce n'est plus excellent. Merci de l'avoir signalé..

@MartijnHols C'est une bonne solution de contournement. Merci d'avoir posté.

Aux mainteneurs : cela dit, nous pourrions dire "pourquoi implémenter --chown dans COPY, vous pouvez utiliser RUN chown dans une construction en plusieurs étapes". Nous avons besoin --exclude pour rester sain d'esprit. Il y a trop de solutions de contournement dans Dockerfiles ces jours-ci.

J'ai un cas d'utilisation qui bénéficierait de COPY --exclude . J'ai un dossier Big Data qui doit être copié dans le conteneur dans son intégralité. Le contenu de ce répertoire est sujet à de fréquentes modifications. Afin d'améliorer les performances du cache, il y a un seul gros fichier dans le répertoire que je veux copier dans sa propre couche, avant de copier le reste. À l'heure actuelle, il est inutilement verbeux de décrire ce type de conteneur.

Quelle est la bonne façon d'utiliser la mise en cache en couches centrée sur requirements.txt

J'ai ceci:

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

Et 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"]

Quelle est la bonne façon d'utiliser la deuxième commande COPY pour exclure le cache de construction des exigences ... et de la même manière, superposer mes app-1 et app-2 s'ils ne changent pas beaucoup?

@axehayz Je ne sais pas si c'est ce que vous demandez, mais je ferais quelque chose de similaire au flux de travail du nœud dans https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8.

C'est-à-dire qu'il est normal que votre deuxième copie soit simplement COPY . ; tant que votre pip install vient avant, cela n'invalidera pas la mise en cache des packages installés.

Face au même problème. Pour le moment, je préférerais développer les fichiers dans différents répertoires.

J'ai un autre cas pour COPY --exclude=... --exclude=...

J'essaie de faire une COPIE --from=oldimage afin de réduire la taille de mon image et j'ai besoin de copier la plupart des fichiers, mais sans certains d'entre eux. Je peux le faire répertoire par répertoire, ce qui est pénible, mais fonctionne... Mais être capable d'exclure une liste de répertoires/fichiers ou de fournir plusieurs options --exclude serait tellement mieux et plus facile à entretenir.

Donc, après trois ans et demi, il n'y a aucune reconnaissance du tout ?

@asimonf Il y a des tonnes de reconnaissance et de va-et-vient pour comprendre le cas d'utilisation. Je suppose que vous voulez dire que personne n'a fait ce travail? C'est exact. Nous devons tous faire des choix sur les choses sur lesquelles nous travaillons.

Honnêtement, cela peut être fait assez facilement en utilisant les fonctionnalités existantes, même si cela signifie que vous devez écrire un peu plus dans votre Dockerfile pour que cela se produise.

# 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/* /

Avec le kit de construction, vous n'avez même pas besoin d'une étape supplémentaire

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

À moins que quelque chose ne me manque, l'utilisation d'une construction en plusieurs étapes ne semble pas être la solution ici. Le cache est toujours invalidé à l'étape COPY.

À moins que quelque chose ne me manque, l'utilisation d'une construction en plusieurs étapes ne semble pas être la solution ici. Le cache est toujours invalidé à l'étape COPY.

C'est correct. Comme c'est le problème que j'ai en ce moment.

Le multi-étage fonctionne très bien pour moi.

Je divise ma construction en plusieurs étapes, pour tirer pleinement parti du cache, cela ressemble à ceci :

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, le défi avec ce processus est que vous avez dû organiser la mise en page de votre application spécifiquement pour une construction de menu fixe, ce que beaucoup de gens ne veulent pas faire.
L'utilisation de docker est l'une des nombreuses considérations à prendre en compte lorsque vous déterminez comment mettre en page vos fichiers d'application (par exemple, maintenabilité, facilité d'utilisation pour les nouvelles recrues, normes inter-projets, exigences du cadre, etc.).

@cfletcher Je ne suis pas sûr de comprendre complètement ce que vous voulez dire.

Pour le changement que j'ai mentionné ci-dessus, j'ai en fait déplacé mon Dockerfile dans un sous-sous-répertoire (ce qui m'a causé de nombreux problèmes lorsque j'essayais d'utiliser rsync pour stagifier ces fichiers), ce qui signifie que j'essayais de cacher mon Dockerfile.

L'approche que j'ai proposée est générale comme je l'imagine. Disons que vous avez 100 fichiers dans votre projet. Il en choisit simplement 1 pour créer l'étape 0, puis 1 + 10 d'entre eux pour créer l'étape 1, puis les 100 pour former l'étape 2. Chaque étape est empilée au-dessus de la précédente et a une commande de construction différente. Pour une structure de projet compliquée, cela signifie simplement que la logique de stagification des fichiers serait compliquée.

Pour moi, la principale raison est que je divise mon code en modules, et j'ai besoin que tous les fichiers package.json soient copiés avant d'exécuter npm install .

Voudrait également une sorte d'argument d'exclusion pour la copie. Nous avons plus de 20 fichiers et plus de 10 répertoires dans le répertoire racine. Nous codons fortement sur 2 des répertoires et quelques-uns des fichiers. Je voudrais les diviser en deux couches COPY. L'un pour les fichiers et répertoires statiques auxquels nous ne touchons jamais, et l'autre pour les fichiers et répertoires que nous touchons toujours.

C'est très triste que cela soit encore ignoré. Cela m'aurait aidé à gagner 5 minutes par build si je pouvais exclure UN répertoire pour ne pas invalider le cache.

Avec le kit de construction, le cache ne dépend pas de l'image parent comme c'est le cas avant le kit de construction.
Alors oui, avec la solution rsync mentionnée, vous aurez besoin de synchroniser chaque fois qu'il y a un changement, mais les étapes suivantes seront mises en cache en fonction du contenu, et si le contenu de ce qui est transféré n'est pas modifié alors. .. au moins dans ma théorie complète sur place, ces étapes devraient utiliser le cache.

C'est triste d'ajouter un simple drapeau --exclude à COPY est si difficile à vendre. C'est dans le TOP30 des billets les plus votés , et une mise en œuvre relativement facile par rapport aux autres billets du TOP30. :(

Ce n'est pas controversé, cela demande du travail.

@ cpuguy83 Oui . Cela ressemblait à controversé / quelque peu rejeté. Cela signifie-t-il qu'un PR approprié avec COPY --exclude serait probablement accepté s'il respecte les normes de qualité ?

Je ne peux pas parler pour tous les responsables, mais j'en ai parlé à @tonistiigi il y a environ un mois et l'IIRC est le plus gros obstacle en ce qui concerne le dockerignore, la syntaxe, etc. (et le fait que le dockerignore est insuffisant syntaxiquement).

Le changement devrait aller dans buildkit.

Upvoting COPY --exclude=... --exclude=... - également nécessaire dans mon cas d'un repo monolithique

Vote positif ! J'ai essayé avec COPY !(excludedfile) . qui devrait fonctionner sur Bash mais pas sur Docker

Je n'aime pas les suggestions de devoir tout répéter dans le fichier .dockerignore pour chaque instruction COPY dans le Dockerfile . Être capable de rester SEC avec ce qui va faire partie de l'image et non devrait être une priorité, à mon humble avis.

En regardant # 33923, je ne pense pas que ce soit une coïncidence si ce que vous voulez exclure du contexte de construction est exactement la même chose que vous voulez exclure des instructions COPY . Je pense que quelque chose comme ça serait une bonne solution:

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

Ou peut-être même quelque chose comme ça :

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

Voyant que .dockerignore est généralement une reproduction à 90 % de .gitignore déjà, il est très ennuyeux de devoir répéter chaque fichier et dossier ignoré pour chaque instruction COPY . Il doit y avoir une meilleure façon.

@asbjornu .gitignore et .dockerignore ne sont pas du tout les mêmes choses. Surtout pour les builds en plusieurs étapes où les artefacts sont générés sur une étape de build et ne sont pas du tout présents dans git, ils doivent néanmoins être inclus dans l'image résultante.
Et oui, avec les versions en plusieurs étapes introduites, IL DEVRAIT Y AVOIR la possibilité d'utiliser différents fichiers .dockerignore par étape - absolument.

Je veux souvent copier en dehors de "docker build". Dans ces cas, .dockerignore ne fait rien. Nous avons besoin d'un amendement à "docker cp" c'est la seule solution sensée

Cela fait 5 ans que ce numéro a été ouvert. En septembre 2020, je veux toujours ça. Beaucoup de gens ont suggéré des hacks pour contourner le problème, mais presque tous et d'autres ont demandé le drapeau exclude sous une forme ou une autre. S'il vous plaît, ne laissez pas ce problème sans solution pendant plus de temps maintenant.

Si vous voulez quelque chose, vous devez y travailler ou trouver quelqu'un pour y travailler.

Si vous voulez quelque chose, vous devez y travailler ou trouver quelqu'un pour y travailler.

Nous devons d'abord savoir si l'amont le souhaite.

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

Après examen du code source, je pense que nous devrions d'abord étendre la fonction de copie ici https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go . Après cela, nous pouvons étendre backend.go dans libsolver, et ce n'est qu'après qu'il sera possible d'étendre AST et l'interface de buildkit.
Mais après cela, la copie sera plus proche de la sémantique rsync qu'unix cp.

MISE À JOUR : oui, après l'extension de copy.go, tout sera proche de https://github.com/moby/buildkit/pull/1492 plus la liste d'analyse des exclusions.