Moby: КОПИРОВАТЬ с исключенными файлами невозможно

См. https://docs.docker.com/reference/builder/#dockerignore -file
Вы можете добавить записи в файл .dockerignore в корне проекта.

.dockerignore не решает эту проблему. Как я уже писал, "другая часть подлежит другому КОПИЮ".

Итак, вы хотите условно скопировать на основе какой-то другой копии?

Контекст содержит множество каталогов A1...A10 и каталог B. У A1...A10 один пункт назначения, у B другой:

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

И это неловко.

Какая часть неловкая? Перечислить их все по отдельности?

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

Это работает?

Имена A1..A10, B были поддельными. Кроме того, COPY A* ... объединяет _содержимое_ каталогов.

Есть пара вариантов, которые я допускаю, но я думаю, что все они неудобны. Я упомянул три в своем первоначальном сообщении. Четвертый вариант — постоянно переупорядочивать мой исходный код так, чтобы A1..A10 перемещались в новый каталог A. Я надеялся, что в этом нет необходимости, потому что дополнительный уровень вложенности не является чем-то желательным, а мои текущие инструменты необходимы для тогда мой докеризованный проект в особом случае.

(Кстати, #6094 (после символических ссылок) поможет в этом случае. Но, видимо, это тоже не вариант.)

@bronger , если бы COPY вел себя точно так же, как cp , решит ли это ваш вариант использования?

Я не уверен, что понимаю на 100%.
Может быть, @duglin может взглянуть.

@bronger Я думаю, что @cpuguy83 задал правильный вопрос, как бы вы решили это, если бы использовали «cp»? Я посмотрел и не заметил какой-то опции исключения в «cp», поэтому я не уверен, как вы решите это вне «сборки докера».

С поведением cp я мог бы улучшить ситуацию, сказав

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

Это все еще небольшая проблема обслуживания, потому что мне пришлось бы думать об этой строке, если бы я добавил каталог «A11». Но это было бы приемлемо.

Кроме того, cp не нуждается в исключениях, потому что копирование всего и удаление ненужных частей почти не влияет на производительность, кроме самого копирования. С КОПИЕЙ докера это означает, что каждый раз, когда B изменяется, кеш ошибочно аннулируется, а изображения увеличиваются.

@bronger вы можете сделать:

COPY a b c d /some/where

как вы и предлагали.

Что касается выполнения RUN rm ... после COPY ... , да, у вас будет дополнительный слой, но вы все равно сможете использовать кеш. Если вы видите промах кеша из-за этого, дайте мне знать, я не думаю, что вам следует.

Но

COPY a b c d /some/where/

копирует содержимое каталогов abcd вместе, вместо создания каталогов /some/where/{a,b,c,d}. Он работает как rsync с добавлением косой черты к каталогу src. Поэтому _четыре_ инструкции

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

нужны.

Что касается кеша... если я скажу

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

тогда кеш не используется, если e изменяется, хотя e не включается в операцию эффективно.

@bronger да, к сожалению, ты прав. Я думаю, мы могли бы добавить флаг типа --exclude zzz , но согласно https://github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntax он может не получить много тяга прямо сейчас.

Справедливо. Затем я пока воспользуюсь COPY+rm и добавлю комментарий FixMe. Спасибо за уделенное время!

Просто к :+1: этой проблеме. Я регулярно сожалею, что COPY не отражает семантику завершающей косой черты rsync. Это означает, что вы не можете КОПИРОВАТЬ несколько каталогов в одном выражении, что приводит к увеличению количества слоев.

Я регулярно сталкиваюсь со случаем, когда я хочу скопировать много каталогов, кроме одного (который будет скопирован позже, потому что я хочу, чтобы у него были разные эффекты недействительности слоев), поэтому --exclude также было бы полезно.

Кроме того, от 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

Я думаю, это нельзя изменить сейчас, не сломав множество диких Dockerfile s.

В качестве конкретного примера предположим, что у меня есть каталог, который выглядит так:

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

Я хочу что-то похожее на:

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

Так что part1-N не аннулирует создание /vendor . (поскольку /vendor редко обновляется по сравнению с part1-N).

Раньше я работал над этим, помещая part1-N в их собственный каталог, поэтому:

/vendor
/src/part1-N

Но я также столкнулся с этой проблемой в проектах, которые я не могу так легко изменить.

@praller хороший пример, мы столкнулись с той же проблемой. Основная проблема заключается в том, что путь к файлу Go.Match не позволяет много творчества по сравнению с регулярными выражениями (т.е. без анти-шаблона)

Я только что придумал несколько хитроумный обходной путь для этого. COPY не может исключать каталоги, но ADD _может_ расширять tgz.

Это один дополнительный шаг сборки:
tar --exclude='./deferred_copy' -czf all_but_deferred.tgz .
сборка докера...

Затем в вашем Dockerfile:
ДОБАВИТЬ ./all_but_deferred.tgz /application_dir/
.. вещи в редко меняющихся слоях ..
ДОБАВЛЯТЬ . /application_dir/
.. вещи в часто меняющихся слоях

Это дает полный синтаксис tar для включения/исключения/всего без кучи ненужных слоев, пытающихся включить/исключить.

@jason-kane Это хороший трюк, спасибо, что поделились. Один небольшой момент: похоже, что вы не можете добавить флаг z (gzip) к tar — он изменяет значение контрольной суммы sha256, что делает недействительным кеш Docker. В противном случае этот подход отлично работает для меня.

+1 за эту проблему, я думаю, что ее можно поддерживать так же, как ее поддерживают многие глобальные библиотеки:

Вот предложение скопировать все, кроме node_modules

COPY . /app -node_modules/

Я тоже сталкиваюсь с той же проблемой, и для меня это довольно болезненно, когда мои веб-приложения Java занимают около 900 МБ, но почти 80% из них редко меняются.
Это раннее состояние моего приложения, и структура папок несколько стабильна, поэтому я не против добавить слой 6-7 COPY, чтобы иметь возможность использовать кеш, но это, безусловно, повредит в долгосрочной перспективе, когда все больше и больше файлов и каталогов добавлены

👍

У меня такая же проблема, хотя с docker cp я хочу скопировать все файлы из папки, кроме одного

Точно такая же проблема здесь. Я хочу скопировать репозиторий git и исключить каталог .git.

@oaxlin , вы можете использовать для этого файл .dockerignore.

@antoineco ты уверен, что это сработает? Прошло некоторое время с тех пор, как я пытался, но я уверен, что .dockerignore не работал с docker cp , по крайней мере, в то время

@kkozmic-seek абсолютно уверен :) Но подкоманда CLI docker cp , которую вы упомянули, отличается от инструкции COPY , найденной в Dockerfile, которая является областью действия этой проблемы.

docker cp действительно не имеет ничего общего с Dockerfile и . dockerignore, но, с другой стороны, он не используется для создания образов.

Мне бы тоже этого очень хотелось - для ускорения сборки я мог бы скопировать какую-нибудь папку в более ранних частях сборки, и тогда мне бы помог кеш...

Я не уверен, что понимаю, каков вариант использования, но не будет ли просто касаться файлов, которые нужно исключить, прежде чем COPY решит проблему?

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

AFAIK COPY не перезаписывает файл, поэтому я думаю, что это может сработать.

К сожалению, неважно, похоже, что COPY на самом деле перезаписывает файлы. Теперь я немного озадачен https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ , который устанавливает npm, а затем выполняет COPY . /usr/src/app . Я предполагаю, что предполагается, что node_modules игнорируется докером? С другой стороны, наличие команды COPY_NO_OVERWRITE (требуется лучшее имя) может быть одним из способов добиться игнорирования файлов во время копирования (вам придется создавать пустые файлы/каталоги для вещей, которые вы хотите игнорировать).

FWIW, я нахожу это очень уродливым.

Я нашел другое решение для взлома:

Пример структуры проекта:
приложение/
конфиг/
сценарий/
спец/
статический/
...

Мы хотим:

1. Скопировать статический/
2. Скопируйте другие файлы
3. Копировать приложение/

Решение для взлома:
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

Второй ADD эквивалентен: копировать все, кроме "./st " и "./a ".
Есть идеи по улучшению?

Каков статус комментария ?

👍

👍

👍

👍

как насчет файла .dockerignore таким же образом, как и .gitignore?

@mirestrepo Посмотрите первые два дополнения к этой проблеме.

В настоящее время это мега производительность для разработки C # / dotnet.

Что я хочу:

• Сначала скопируйте все внешние dll в образы докеров (все, кроме My*.dll)
• Затем скопируйте все мои dll (начиная с My.*.dll).

Теперь кажется, что это (легко) невозможно, потому что я не могу скопировать все, кроме.

Таким образом, либо dll копируются дважды, что увеличивает размер файла докера, либо все копируется в один слой.
Последнее является меганерфом, потому что внешние DLL каждый раз копируются, а не кэшируются.

@adresdvila спасибо за решение, на которое я смог его разделить:

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

Хотя это по-прежнему оставляет проблему, заключающуюся в том, что файлы .json копируются при первой команде.

Просто вмешиваюсь, чтобы поблагодарить @antoineco, моя проблема решена. Я больше не копирую каталог .git в свои образы докеров.

Это значительно увеличило размер образа и сделало мой образ гораздо более удобным для системы кэширования докеров.

У меня точно такая же проблема. У меня есть большой файл, который я хочу скопировать перед остальными файлами, поэтому любое изменение в контексте не повторяется, так как копирование занимает много времени (бинарный файл 7 ГБ). Есть ли новые обходные пути?

Проблема с подходом COPY и prune заключается в том, что слой до обрезки по-прежнему содержит все данные.

COPY . --exclude=a --exclude=b было бы чрезвычайно полезно. Что думаешь, @cpuguy83?

@Nowaker Мне это нравится. В любом случае, похоже на tar и rsync .
Я предполагаю, что это должно поддерживать тот же формат, что и dockerignore?

@tonistiigi @dnephin

Я думаю, этим делом будет заниматься #32507.

@ cpuguy83 Да. В частности, в соответствии с COPY --chown=uid:gid

@dnephin RUN --mount звучит как совершенно другой вариант использования, сосредоточенный на создании чего-то на основе данных, которые нам не нужны после создания вывода. (Например, компиляция с помощью Go, создание HTML-файлов из файла Markdown и т. д.). RUN --mount — это круто, и я бы определенно использовал его в проекте, над которым я сейчас работаю (генерация документов API с использованием Sphinx).

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 сосредоточен на копировании данных, которые должны попасть в образ, но разбросаны по нескольким операторам COPY, а не только по одному. Цель состоит в том, чтобы избежать явной COPY first second third .... eleventh destination/ , когда проект имеет много каталогов в корне и может быть изменен/увеличен.

В моем случае я хочу сначала скопировать большинство файлов, кроме тех, которые не являются необходимыми, чтобы убедиться, что кеш используется, если исходные файлы не изменились. Затем скомпилируйте/сгенерируйте - и используйте кеш, если скопированные файлы не изменились (ура). В самом начале скопируйте файлы, которые я исключил ранее, которые могли измениться с момента предыдущей сборки, но их изменение не влияет на компиляцию/генерацию. Очевидно, у меня есть тонны файлов и каталогов в формате . что хочу КОПИРОВАТЬ сначала, и только пару, что хочу КОПИРОВАТЬ куда-то в конце.

Идея состоит в том, что RUN --mount способен решить множество проблем. COPY --exclude решает только одну проблему.

Я бы предпочел добавить что-то, что решает много проблем, чем добавить кучу синтаксиса для решения отдельных проблем. Вы должны использовать RUN --mount... rsync --exclude ... (или какой-нибудь скрипт, который копирует отдельные вещи), и это будет эквивалентно COPY --exclude .

@dnephin О, я не думал о RUN --mount rsync ! Отлично! 👍

Это действительно отлично. Однако вы не сможете эффективно использовать кеширование @Nowaker , потому что кеш будет аннулирован, если что- либо изменится в смонтированном каталоге, а не только то, что вы хотите rsync.

Если вы используете выходные данные этого rsync в качестве входных данных для чего-то еще, и файлы там фактически не изменились, кеш снова заработает. Если вы действительно готовы к этому, вы можете сделать это сейчас с помощью чего-то вроде https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140. Единственное изменение в RUN --mount (или LLB в buildkit) заключается в том, что вам не нужно фактически копировать файлы между этапами, но вы можете получить к ним прямой доступ, что намного быстрее.

Как насчет использования 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 Хорошо , тогда это уже не отлично. Спасибо, что указали..

@MartijnHols Это хороший обходной путь. Спасибо за публикацию.

Сопровождающим: тем не менее, мы могли бы сказать: «Зачем реализовывать --chown в COPY, вы можете использовать RUN chown в многоэтапной сборке». Нам нужно --exclude для здравомыслия. В Dockerfiles в наши дни слишком много обходных путей.

У меня есть вариант использования, который выиграет от COPY --exclude . У меня есть папка с большими данными, которую нужно полностью скопировать в контейнер. Содержимое этого каталога подвержено частым изменениям. Чтобы повысить производительность кеша, в каталоге есть один большой файл, который я хочу скопировать в отдельный слой, прежде чем копировать остальные. На данный момент излишне подробно описывать этот тип контейнера.

Каков правильный способ использования многоуровневого кэширования, основанного на требованиях.txt

У меня есть это:

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

И Докерфайл:

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

Как правильно использовать вторую команду COPY, чтобы исключить кеш сборки требований ... и аналогичным образом наложить мои приложения-1 и приложение-2, если они не сильно меняются?

@axehayz Не уверен, что это то, о чем вы спрашиваете, но я бы сделал что-то похожее на рабочий процесс узла в https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8.

Т.е. ваша вторая копия может быть просто COPY . ; пока ваш pip install идет раньше, это не приведет к аннулированию кэша для установленных пакетов.

Столкнулся с той же проблемой. На данный момент я бы предпочел развернуть файлы в разных каталогах.

У меня есть другой случай для COPY --exclude=... --exclude=...

Я пытаюсь сделать COPY --from=oldimage, чтобы уменьшить размер моего изображения, и мне нужно скопировать большинство файлов, но без некоторых из них. Я могу сделать это каталог за каталогом, что болезненно, но работает... Но возможность --exclude либо списка каталогов/файлов, либо предоставления нескольких --exclude опций была бы намного лучше и проще в обслуживании.

Значит, спустя три с половиной года нет никакого признания?

@asimonf Существует множество подтверждений и обратно, чтобы понять вариант использования. Я полагаю, вы имеете в виду, что никто не делал эту работу? Это правильно. Нам всем приходится делать выбор в отношении вещей, над которыми мы работаем.

Честно говоря, это можно сделать довольно легко, используя существующую функциональность, даже если это означает, что вам нужно написать немного больше в вашем Dockerfile, чтобы это произошло.

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

С buildkit вам даже не нужен дополнительный этап

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

Если я что-то упустил, использование многоэтапной сборки не похоже на решение здесь. Кэш по-прежнему становится недействительным на этапе COPY.

Если я что-то упустил, использование многоэтапной сборки не похоже на решение здесь. Кэш по-прежнему становится недействительным на этапе COPY.

Это верно. Поскольку это проблема, которая у меня сейчас.

Многоэтапность отлично работает для меня.

Я разбиваю свою сборку на многоэтапную, чтобы полностью использовать кеш, это выглядит примерно так:

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 проблема с этим процессом заключается в том, что вам нужно было настроить макет приложения специально для сборки докера, чего многие люди не хотят делать.
Использование docker является одним из многих соображений, которые следует учитывать при выяснении того, как размещать файлы вашего приложения (например, удобство сопровождения, простота использования для новых сотрудников, межпроектные стандарты, требования к инфраструктуре и т. д.).

@cfletcher Я не уверен, что полностью понимаю, что ты имеешь в виду.

Для изменения, о котором я упоминал выше, я фактически переместил свой файл Dockerfile в подкаталог (что вызвало у меня много проблем при попытке использовать rsync для стагнации этих файлов), что означает, что я пытался скрыть свой файл Dockerfile.

Подход, который я предложил, является общим, насколько я понимаю. Допустим, у вас есть 100 файлов в вашем проекте. Он просто выбирает 1 из них, создавая этап 0, затем 1+10 из них для создания этапа 1, а затем все 100 для формирования этапа 2. Каждый этап накладывается поверх предыдущего и имеет другую команду сборки. Для сложной структуры проекта это просто означает, что логика stagify-files будет сложной.

Для меня главная причина в том, что я разбиваю свой код на модули, и мне нужно скопировать все файлы package.json перед запуском npm install .

Также хотелось бы какой-то аргумент исключения для копирования. У нас есть 20+ файлов и 10+ каталогов в корневом каталоге. Мы сильно кодируем 2 каталога и несколько файлов. Я хотел бы разделить их на два слоя COPY. Один для статических файлов и каталогов, к которым мы никогда не прикасаемся, а другой — для файлов и каталогов, к которым мы всегда прикасаемся.

Очень жаль, что это до сих пор игнорируется. Это помогло бы мне сэкономить 5 минут на каждую сборку, если бы я мог исключить ОДИН каталог, чтобы не сделать кеш недействительным.

С помощью buildkit кеш не зависит от родительского образа, как если бы он был pre-buildkit.
Так что да, с упомянутым решением rsync вы получите удар, поскольку вам нужно будет синхронизировать каждый раз, когда происходят какие-либо изменения, но последующие этапы будут кэшироваться на основе содержимого, и если содержимое того, что передается, не изменяется тогда. .. по крайней мере, в моей полной теории на месте эти этапы должны использовать кеш.

Печально, что добавление простого флага --exclude к COPY — такая трудная задача. Он входит в ТОП30 самых популярных билетов и относительно прост в реализации по сравнению с другими ТОП30 билетами. :(

Это не спорно, это требует работы.

@cpuguy83 Ура . Это выглядело как спорное/несколько отвергнутое. Означает ли это, что правильный PR с COPY --exclude , скорее всего, будет принят, если он соответствует стандартам качества?

Я не могу говорить за каждого сопровождающего, но я говорил с @tonistiigi месяц назад или около того об этом, и IIRC — самое большое препятствие, как это связано с dockerignore, синтаксисом и т. д. (и тот факт, что dockerignore недостаточно синтаксически).

Изменение должно быть включено в buildkit.

Голосование COPY --exclude=... --exclude=... — также необходимо в моем случае монолитного репо.

Голосую! Я пробовал с COPY !(excludedfile) . , который должен работать на Bash, но не на Docker.

Мне не нравятся предложения повторять все внутри файла .dockerignore для каждого оператора COPY в Dockerfile . Возможность оставаться СУХИМ с тем, что будет частью образа, а не должно быть приоритетом, имхо.

Глядя на # 33923, я не думаю, что это совпадение, что то, что вы хотите исключить из контекста сборки, - это точно то же самое, что вы хотите исключить из операторов COPY . Я считаю, что что-то вроде этого было бы хорошим решением:

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

Или, возможно, даже что-то вроде этого:

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

Видя, как .dockerignore обычно на 90% воспроизводит уже .gitignore , становится особенно раздражающим необходимость повторять каждый игнорируемый файл и папку еще раз для каждого оператора COPY . Там должен быть лучший способ.

@asbjornu .gitignore и .dockerignore — это совсем не одно и то же. Особенно для многоэтапных сборок, где артефакты генерируются на этапе сборки и вообще не присутствуют в git, тем не менее должны быть включены в результирующий образ.
И да, с введением многоэтапных сборок ДОЛЖНА БЫТЬ возможность использовать разные файлы .dockerignore на каждом этапе - абсолютно.

Я часто хочу копировать за пределами «сборки докеров». В этих случаях .dockerignore ничего не делает. Нам нужна поправка к «docker cp», это единственное разумное решение.

Прошло 5 лет, как этот вопрос был открыт. В сентябре 2020 я все еще хочу это. Многие люди предлагали обходные пути, но почти все они и другие запрашивали флаг exclude в той или иной форме. Пожалуйста, не оставляйте этот вопрос нерешенным еще какое-то время.

Если вы чего-то хотите, вам нужно над этим работать или найти кого-то, кто будет над этим работать.

Если вы чего-то хотите, вам нужно над этим работать или найти кого-то, кто будет над этим работать.

Сначала нам нужно знать, хочет ли этого восходящий поток.

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

После просмотра исходного кода я думаю, что мы должны сначала расширить функцию копирования здесь https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go . После этого мы можем расширить backend.go в libsolver, и только после этого можно будет расширить AST и фронтенд buildkit.
Но после этого копия будет близка по семантике к rsync, чем к unix cp.

ОБНОВЛЕНИЕ: да, после расширения copy.go все будет близко к https://github.com/moby/buildkit/pull/1492 плюс парсинг списка исключений.