Moby: 제외된 파일로 복사할 수 없습니다.

https://docs.docker.com/reference/builder/#dockerignore -file 참조
프로젝트 루트의 .dockerignore 파일에 항목을 추가할 수 있습니다.

.dockerignore는 이 문제를 해결하지 않습니다. 내가 쓴 것처럼 "다른 부분은 다른 COPY의 대상입니다".

다른 사본을 기반으로 조건부로 복사하시겠습니까?

컨텍스트에는 많은 디렉터리 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* ... 는 디렉토리의 _contents_를 함께 던집니다.

내가 인정하는 몇 가지 옵션이 있지만 모두 어색하다고 생각합니다. 나는 원래 게시물에서 세 가지를 언급했습니다. 네 번째 옵션은 소스 코드를 영구적으로 재배열하여 A1..A10이 새 디렉토리 A로 이동되도록 하는 것입니다. 추가 중첩 수준이 원하는 것이 아니기 때문에 이것이 필요하지 않기를 바랐고 현재 도구가 필요했습니다. 특별한 경우 내 도킹 된 프로젝트.

(BTW, #6094(다음 심볼릭 링크)가 이 경우에 도움이 될 것입니다. 그러나 분명히 이것은 옵션도 아닙니다.)

@bronger if COPY 가 cp 와 똑같이 작동하면 사용 사례가 해결됩니까?

제가 100% 이해했는지는 모르겠습니다.
@duglin 이 볼 수 있습니다.

@bronger @cpuguy83 이 올바른 질문을 했다고 생각합니다. 'cp'를 사용한다면 어떻게 해결하시겠습니까? 나는 'cp'에서 어떤 종류의 제외 옵션을 보았지만 알아차리지 못했기 때문에 '도커 빌드' 밖에서도 이것을 어떻게 해결할지 잘 모르겠습니다.

cp 동작을 사용하면 다음과 같이 상황을 개선할 수 있습니다.

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

"A11" 디렉토리를 추가하면 그 줄을 생각해야 하기 때문에 여전히 가벼운 유지 관리 문제입니다. 그러나 그것은 받아 들일 수 있습니다.

게다가 cp는 제외할 필요가 없습니다. 모든 것을 복사하고 원하지 않는 부분을 제거하는 것은 복사 자체 외에는 성능에 거의 영향을 미치지 않기 때문입니다. docker의 COPY를 사용하면 B가 변경될 때마다 캐시가 잘못 무효화되고 이미지가 더 커집니다.

@bronger 당신이 할 수 있는 일:

COPY a b c d /some/where

당신이 제안한 것처럼.

$ COPY ... RUN rm ... 를 수행하는 경우 추가 레이어가 있지만 여전히 캐시를 사용할 수 있어야 합니다. 이로 인해 캐시 누락이 발생하는 경우 알려주시면 안 된다고 생각합니다.

하지만

COPY a b c d /some/where/

/some/where/{a,b,c,d} 디렉토리를 만드는 대신 abcd 디렉토리의 내용을 함께 복사합니다. src 디렉토리에 슬래시가 추가된 rsync처럼 작동합니다. 따라서 _four_ 지침

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의 filepath.Match가 정규 표현식에 비해 많은 창의성을 허용하지 않는다는 것입니다(즉, 안티 패턴 없음).

나는 이것에 대한 약간의 균열 브레인 해결 방법을 생각해 냈습니다. COPY는 디렉토리를 제외할 수 없지만 ADD _can_ tgz를 확장합니다.

하나의 추가 빌드 단계입니다.
tar --exclude='./deferred_copy' -czf all_but_deferred.tgz .
도커 빌드 ...

그런 다음 Dockerfile에서:
추가 ./all_but_deferred.tgz /application_dir/
.. 거의 변경되지 않는 레이어의 내용 ..
추가하다 . /응용 프로그램 디렉토리/
.. 자주 변경되는 레이어의 내용

이는 포함/제외를 시도하는 낭비되는 레이어 없이 포함/제외/무엇이든 tar의 전체 구문을 제공합니다.

@jason-kane 이것은 좋은 트릭입니다. 공유해 주셔서 감사합니다. 한 가지 작은 점: z (gzip) 플래그를 tar 에 추가할 수 없는 것 같습니다. sha256 체크섬 값을 변경하여 Docker 캐시를 무효화합니다. 그렇지 않으면 이 접근 방식이 저에게 효과적입니다.

이 문제에 대해 +1, 많은 glob 라이브러리가 지원하는 것과 같은 방식으로 지원될 수 있다고 생각합니다.

다음은 node_modules 를 제외한 모든 항목을 복사하는 제안입니다.

COPY . /app -node_modules/

저도 같은 문제를 겪었는데 Java 웹 애플리케이션이 약 900MB이지만 그 중 거의 80%가 거의 변경되지 않을 때 고통스럽습니다.
내 응용 프로그램의 초기 상태이고 폴더 구조가 다소 안정적이므로 캐시를 사용할 수 있도록 6-7 COPY 레이어를 추가하는 데 신경 쓰지 않지만 점점 더 많은 파일과 디렉터리가 추가된다

👍

docker cp 을 사용하더라도 동일한 문제가 있습니다. 한 폴더를 제외한 폴더의 모든 파일을 복사하고 싶습니다.

여기에 똑같은 문제가 있습니다. git repo를 복사하고 .git 디렉토리를 제외하고 싶습니다.

@oaxlin 이를 위해 .dockerignore 파일을 사용할 수 있습니다.

@antoineco 정말 효과 가 있을까요? 시도한 지 오래되었지만 적어도 당시에는 .dockerignore 가 docker cp 와 함께 작동하지 않았다고 확신합니다.

@kkozmic-seek 절대적으로 확실합니다 :) 하지만 언급하신 docker cp CLI 하위 명령은 Dockerfile에서 발견된 COPY 명령문과 다르며, 이는 이 문제의 범위입니다.

docker cp 는 실제로 Dockerfile 및 . dockerignore 하지만 다른 한편으로는 이미지를 빌드하는 데 사용되지 않습니다.

이것도 정말 원합니다 - 빌드 속도를 높이기 위해 빌드의 이전 부분에서 일부 폴더를 복사한 다음 캐시가 도움이 될 것입니다 ...

유스 케이스가 무엇인지 잘 모르겠지만 COPY가 문제를 해결하기 전에 제외할 파일을 만지지 않습니까?

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

AFAIK COPY 는 파일을 덮어쓰지 않으므로 이것이 작동할 수 있다고 생각합니다.

죄송합니다. COPY 가 실제로 파일을 덮어쓰는 것처럼 보입니다. 저는 이제 npm이 설치한 다음 COPY . /usr/src/app 하는 https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ 에 약간 의아해합니다. 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"를 제외하고 모두 복사와 동일합니다.
개선을 위한 아이디어가 있습니까?

댓글 상태는?

👍

👍

👍

👍

.gitignore와 같은 방식으로 .dockerignore 파일을 사용하는 것은 어떻습니까?

@mirestrepo 이 문제에 대한 처음 두 가지 후속 조치를 참조하십시오.

현재 이것은 C#/dotnet 개발에 대한 엄청난 성능 저하입니다.

내가 원하는 것:

• 먼저 모든 외부 dll을 도커 이미지에 복사합니다(My*.dll을 제외한 모든 것).
• 그런 다음 My.*.dll로 시작하는 모든 dll을 복사합니다.

이제 내가 제외하고 모든 것을 복사할 수 없기 때문에 이것은 (쉽게) 가능하지 않은 것 같습니다.

따라서 dll이 이중으로 복사되어 도커 파일 크기가 증가하거나 모든 것이 하나의 레이어에 복사됩니다.
외부 dll이 캐시되는 대신 매번 복사되기 때문에 나중에 메가 너프가 됩니다.

@adresdvila 내가 그것을 나눌 수 있었던 solutoin에 감사드립니다:

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

이것은 여전히 ​​.json 파일이 첫 번째 명령에서 복사된다는 문제를 남깁니다.

@antoineco 덕분에 제 문제가 해결되었습니다. 더 이상 .git 디렉토리를 도커 이미지에 복사하지 않습니다.

이것은 이미지 크기를 극적으로 개선하고 내 이미지를 도커 캐싱 시스템에 훨씬 더 친숙하게 만듭니다.

나는 같은 문제를 가지고있다. 나머지 파일보다 먼저 복사하려는 큰 파일이 있으므로 복사하는 데 많은 시간이 걸리므로 컨텍스트의 변경 사항이 반복되지 않습니다(7GB bin 파일). 새로운 해결 방법이 있습니까?

COPY 및 프루닝 접근 방식의 문제는 프루닝 전 레이어에 여전히 모든 데이터가 포함되어 있다는 것입니다.

COPY . --exclude=a --exclude=b 는 매우 유용합니다. @cpuguy83 어떻게 생각하세요?

@노웨커 좋아요. 어쨌든 tar 및 rsync 와 일치하는 것 같습니다.
dockerignore와 동일한 형식을 지원해야 합니까?

@tonistiigi @dnephin

이 사건은 #32507에 의해 처리될 것이라고 생각합니다.

@cpuguy83 네. 특히 COPY --chown=uid:gid 에 따라

@dnephin RUN --mount 는 출력이 생성된 후 필요하지 않은 데이터를 기반으로 무언가를 생성하는 데 중점을 둔 완전히 다른 사용 사례처럼 들립니다. (예: Go로 컴파일, Markdown 파일에서 HTML 생성 등). RUN --mount 는 마약이고 현재 작업 중인 프로젝트(Sphinx를 사용하여 API 문서 생성)에서 확실히 사용할 것입니다.

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 는 이미지에서 끝나야 하지만 하나가 아닌 여러 COPY 문에 흩어져 있는 데이터 복사를 중심으로 합니다. 목표는 프로젝트의 루트에 많은 디렉토리가 있고 변경/증가할 수 있는 경우 명시적인 COPY first second third .... eleventh destination/ 를 피하는 것입니다.

제 경우에는 소스 파일이 변경되지 않은 경우 캐시가 사용되는지 확인하기 위해 먼저 불필요한 파일을 제외한 대부분 의 파일을 복사하고 싶습니다. 그런 다음 컴파일/생성 - 복사한 파일이 변경되지 않은 경우 캐시를 사용합니다(예). 맨 처음에는 이전 빌드 이후 변경되었을 수 있지만 변경 사항이 컴파일/생성에 영향을 미치지 않는 이전에 제외된 파일을 복사합니다. 분명히, 나는 ton 파일과 디렉토리를 가지고 있습니다. 내가 먼저 COPY하고 싶은 것, 그리고 마지막에 어딘가에 COPY하고 싶은 커플.

아이디어는 RUN --mount 가 많은 문제를 해결할 수 있다는 것입니다. COPY --exclude 는 하나의 문제만 해결합니다.

개별 문제를 해결하기 위해 많은 구문을 추가하는 것보다 많은 문제를 해결하는 것을 추가하고 싶습니다. RUN --mount... rsync --exclude ... (또는 개별 항목을 복사하는 일부 스크립트)를 사용하고 COPY --exclude 와 동일합니다.

@dnephin 아, RUN --mount rsync 생각을 못했네요! 훌륭한! 👍

정말 훌륭합니다. 그러나 캐싱을 효율적으로 활용할 수 없습니다 @Nowaker . 재동기화하려는 항목 뿐만 아니라 마운트된 디렉토리에서 변경 사항이 있으면 캐시가 무효화되기 때문입니다.

해당 rsync의 출력을 다른 것에 대한 입력으로 사용하고 실제로 변경된 파일이 없으면 캐시가 다시 선택됩니다. 당신이 정말로 그것을 위해 준비되어 있다면 https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140 과 같은 것으로 현재 이것을 할 수 있습니다. RUN --mount (또는 buildkit의 LLB)의 변경 사항은 실제로 단계 간에 파일을 복사할 필요가 없지만 파일에 직접 액세스할 수 있으므로 훨씬 빠릅니다.

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, 더 이상 우수하지 않습니다. 지적해주셔서 감사합니다..

@MartijnHols 이것은 좋은 해결 방법입니다. 게시해 주셔서 감사합니다.

유지 관리자에게: 즉, "COPY에서 --chown을 구현하는 이유는 다단계 빌드에서 RUN chown을 사용할 수 있습니다"라고 말할 수 있습니다. 온전한 상태를 유지하려면 --exclude 가 필요합니다. 요즘 Dockerfiles에는 해결 방법이 너무 많습니다.

COPY --exclude 의 이점을 얻을 수 있는 사용 사례가 있습니다. 컨테이너에 전체를 복사해야 하는 빅 데이터 폴더가 있습니다. 해당 디렉토리의 내용은 자주 변경될 수 있습니다. 캐시 성능을 향상시키기 위해 디렉토리에 하나의 큰 파일이 있는데 나머지는 복사하기 전에 자체 레이어에 복사합니다. 현재로서는 이러한 유형의 컨테이너를 설명하는 것이 불필요하게 장황합니다.

requirements.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 명령을 사용하는 올바른 방법은 무엇이며 ... 많이 변경되지 않으면 내 app-1 및 app-2를 유사하게 계층화합니까?

@axehayz 이것이 당신이 묻는 것인지 확실하지 않지만 https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8의 노드 워크플로와 유사한 작업을 수행할 것입니다.

즉, 두 번째 사본이 COPY . 이어도 됩니다. pip install 이전에 오는 한 설치된 패키지에 대해 캐시된 내용을 무효화하지 않습니다.

같은 문제에 직면했습니다. 현재로서는 다른 디렉토리에 있는 파일을 확장하는 것을 선호합니다.

COPY --exclude=... --exclude=...에 대한 또 다른 경우가 있습니다.

이미지 크기를 줄이기 위해 COPY --from=oldimage를 수행하려고 하고 대부분의 파일을 복사해야 하지만 일부는 복사하지 않습니다. 디렉토리별로 할 수 는 있지만 작동합니다... 그러나 디렉토리/파일 목록을 --exclude하거나 여러 --exclude 옵션을 제공할 수 있으면 훨씬 더 좋고 유지 관리하기 쉽습니다.

그래서 3년 반이 지나도 전혀 인정이 없는 건가요?

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

빌드킷을 사용하면 추가 단계가 필요하지 않습니다.

#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 해당 프로세스의 문제는 많은 사람들이 하고 싶지 않은 도커 빌드를 위해 특별히 애플리케이션 레이아웃을 정렬해야 한다는 것입니다.
도커를 사용하는 것은 응용 프로그램 파일을 레이아웃하는 방법(예: 유지 관리 가능성, 신입 직원을 위한 사용 용이성, 교차 프로젝트 표준, 프레임워크 요구 사항 등)을 결정할 때 균형을 맞춰야 하는 많은 고려 사항 중 하나입니다.

@cfletcher 무슨 말인지 완전히 이해하지 못했습니다.

위에서 언급한 변경 사항에 대해 실제로 Dockerfile을 하위 하위 디렉터리로 옮겼습니다(이로 인해 rsync를 사용하여 해당 파일을 단계화하려고 할 때 많은 문제가 발생함). 즉, Dockerfile을 숨기려고 했습니다.

내가 제안한 접근 방식은 내가 상상하는 일반적인 것입니다. 프로젝트에 100개의 파일이 있다고 가정해 보겠습니다. 그 중 1개를 선택하여 stage0을 만든 다음 그 중 1+10을 선택하여 stage 1을 만든 다음 100개를 모두 선택하여 stage 2를 만듭니다. 각 단계는 이전 단계 위에 쌓이고 다른 빌드 명령을 갖습니다. 복잡한 프로젝트 구조의 경우 stagify-files 논리가 복잡하다는 것을 의미합니다.

나에게 가장 큰 이유는 코드를 모듈로 분할하고 npm install 를 실행하기 전에 모든 package.json 파일을 복사해야 하기 때문입니다.

또한 복사에 대한 일종의 제외 인수를 원합니다. 루트 디렉토리에 20개 이상의 파일과 10개 이상의 디렉토리가 있습니다. 우리는 2개의 디렉토리와 몇 개의 파일을 많이 코딩합니다. 이것을 두 개의 COPY 레이어로 나누고 싶습니다. 하나는 절대 건드리지 않는 정적 파일 및 디렉토리용이고 다른 하나는 항상 만지는 파일 및 디렉토리용입니다.

이것이 여전히 무시되고 있다는 것은 매우 슬픈 일입니다. 캐시를 무효화하지 않기 위해 하나의 디렉토리를 제외할 수 있다면 빌드당 5분을 절약하는 데 도움이 되었을 것입니다.

빌드킷을 사용하면 사전 빌드킷과 같이 캐시가 상위 이미지에 종속되지 않습니다.
따라서 언급한 rsync 솔루션을 사용하면 변경 사항이 있을 때마다 동기화해야 한다는 점에서 성공할 수 있지만 후속 단계는 콘텐츠를 기반으로 캐시되며 전송되는 콘텐츠의 콘텐츠가 변경되지 않은 경우에는 다음과 같습니다. .. 적어도 현장 이론에서 이러한 단계는 캐시를 사용해야 합니다.

COPY 에 간단한 --exclude 플래그를 추가하는 것은 매우 어려운 일입니다. 가장 많이 투표된 티켓 TOP30에 있으며 다른 TOP30 티켓에 비해 구현 면에서 상대적으로 쉽습니다. :(

그것은 논쟁의 여지가 없으며 작업이 필요합니다.

@cpuguy83 예. 그것은 논란의 여지가 있는 것처럼 보였습니다 / 다소 거부되었습니다. COPY --exclude 가 있는 적절한 PR이 품질 표준을 통과하면 받아들여질 수 있다는 의미입니까?

모든 유지 관리자에 대해 말할 수는 없지만 한 달 정도 전에 @tonistiigi 와 이것에 대해 이야기했으며 IIRC가 이것이 dockerignore, 구문 등과 관련되는 가장 큰 장애물에 대해 이야기했습니다(그리고 dockerignore가 구문적으로 충분하지 않다는 사실).

변경 사항은 빌드킷으로 이동해야 합니다.

COPY --exclude=... --exclude=... 찬성 - 모놀리스 리포지토리의 경우에도 필요합니다.

찬성! Bash에서 작동해야 하지만 Docker에서는 작동하지 않는 COPY !(excludedfile) . 로 시도했습니다.

Dockerfile 의 모든 COPY 문에 대해 Dockerfile .dockerignore 파일 내의 모든 것을 반복해야 한다는 제안이 마음에 들지 않습니다. 이미지의 일부가 될 것이고 우선순위가 되어서는 안 될 부분으로 DRY를 유지할 수 있는 것, imho.

#33923을 보면 빌드 컨텍스트에서 제외하려는 것이 COPY 문에서 제외하려는 것과 정확히 같은 것이 우연이 아니라고 생각합니다. 나는 다음과 같은 것이 좋은 해결책이 될 것이라고 믿습니다.

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

또는 다음과 같은 것일 수도 있습니다.

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

.dockerignore 가 이미 .gitignore 의 90% 재생산인 것을 볼 때 무시된 모든 파일과 폴더를 각각의 모든 COPY 문에 대해 다시 반복해야 하는 것은 매우 성가신 일입니다. 더 나은 방법이 있어야 합니다.

@asbjornu .gitignore와 .dockerignore는 전혀 같은 것이 아닙니다. 특히 빌드 단계에서 아티팩트가 생성되고 git에는 전혀 없는 다단계 빌드의 경우 결과 이미지에 포함되어야 합니다.
그리고 예, 다단계 빌드가 도입되면 단계마다 다른 .dockerignore 파일을 사용할 수 있어야 합니다. 절대적으로.

나는 종종 "도커 빌드" 외부에서 복사하고 싶습니다. 이러한 경우 .dockerignore는 아무 작업도 수행하지 않습니다. 유일한 합리적인 솔루션인 "docker cp"에 대한 수정이 필요합니다.

이 문제가 공개된 지 5년이 되었습니다. 2020년 9월에도 나는 이것을 원한다. 많은 사람들이 해결 방법에 대한 해킹을 제안했지만 거의 모든 사람들과 다른 사람들이 어떤 형태로든 exclude 플래그를 요청했습니다. 지금 이 문제가 해결되지 않은 상태로 더 이상 방치하지 마십시오.

원하는 것이 있으면 작업하거나 작업할 사람을 찾아야 합니다.

원하는 것이 있으면 작업하거나 작업할 사람을 찾아야 합니다.

먼저 업스트림이 이것을 원하는지 여부를 알아야 합니다.

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

소스 코드 검토 후 https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go 에서 복사 기능을 먼저 확장해야 한다고 생각합니다. 그 후, 우리는 libsolver에서 backend.go를 확장할 수 있으며, 그 후에야 빌드킷의 AST와 프론트엔드를 확장할 수 있습니다.
그러나 그 후에는 복사본이 유닉스 cp보다 의미론적으로 rsync에 가깝습니다.

업데이트: 예, copy.go를 확장한 후 모든 것이 https://github.com/moby/buildkit/pull/1492 에 가깝고 제외 목록을 구문 분석합니다.