moby 🚀 - 빌드 시간 전용 -v 옵션

비슷한 솔루션을 찾고 있습니다.

문제

최근에 내가 일하는 기업은 SSL 검사를 통해 Zscaler 프록시를 활성화했습니다. 이는 인증서가 설치되어 있고 빌드 중에 일부 환경 변수가 설정되어 있음을 의미합니다.

임시 해결책은 인증서와 환경 변수가 설정된 새 Dockerfile을 만드는 것이었습니다. 그러나 장기적으로 볼 때 이는 합리적이지 않아 보입니다.

그래서 내 첫 번째 생각은 HTTP 및 HTTPS로 투명 프록시를 설정했지만 다시 빌드하는 동안 인증서를 전달해야 합니다.

이상적인 시나리오는 동일한 Dockerfile을 사용하여 랩톱, 가정 및 기업에서 이미지를 구축할 수 있다는 것입니다.

가능한 해결책

# Enterprise
$ docker build -v /etc/ssl:/etc/ssl -t myimage .

# Home
$ docker build -t myimage .

tpires 에 2015년 06월 25일

👍13

ASP.Net 5 패키지 관리자 에 의해 다운로드/업데이트되는 이 기능에 대한 약간 다른 사용 사례가 있습니다. 패키지 관리자는 자체 캐시 폴더를 관리하므로 궁극적으로 빌드 간에 재사용할 수 있는 폴더만 있으면 됩니다.

즉:

docker build -v /home/dokku/cache/dnx/packages:/opt/dnx/packages -t "dokku/aspnettest" .

yngndrw 에 2015년 07월 08일

👍96

@yngndrw 당신이 제안한 것은 나에게도 괜찮을 것입니다. 즉, 컨테이너에 설치되었기 때문에 런타임에는 필요하지 않은 추가 리소스를 빌드 시 마운트해야 합니다.

FWIW 이 페이지의 어딘가에서 누군가가 "유사한 호스트 시스템에서 컴파일 문제를 해결한 다음 컨테이너에 배포 가능한 아티팩트 또는 exe를 설치하십시오"라는 라인을 따라 무언가를 말하는 것을 보았습니다.
나는 그것이 그렇게 단순한 사람이 아니라는 것이 두렵다. 때때로 /usr/bin에 설치해야 하지만 일부 구성 파일도 편집해야 합니다. 실행 중인 OS, 조정해야 하는 커널 매개변수, 변수에 따라 생성해야 하는 파일 또는 매니페스토 빌드 파일을 확인합니다. 컴파일된 제품의 단순한 복사본으로 만족하지 못하는 많은 종속성이 있습니다.

문제를 열 때 말한 내용을 다시 설명합니다. 매니페스트 선언 파일과 해당 프로세스와 아티팩트의 런타임 간에 차이가 있습니다.
우리가 코드로서의 인프라와 더 나아가 불변의 인프라를 진정으로 믿는다면, 도커 자체가 더욱 촉진되고 있고 저는 그것을 좋아합니다. 그렇다면 이것은 IMO로 심각하게 고려되어야 합니다(여기와 함께 포스트 1의 팽창 참조)

다시 감사합니다

zrml 에 2015년 07월 16일

정말 흥미로운 또 다른 사용 사례는 소프트웨어 업그레이드입니다. FreeIPA와 마찬가지로 프로덕션 데이터의 복사본으로 실제로 테스트하여 다른 모든 구성 요소가 완전히 업그레이드될 수 있는지 확인해야 하는 경우가 있습니다. 여전히 "빌드" 환경에서 업그레이드를 수행하려고 합니다. 새로운 업그레이드 버전의 컨테이너를 프로덕션으로 이동할 때 업그레이드를 수행한 정확한 데이터를 마운드할 수 있도록 데이터의 프로덕션 복사본이 다른 위치에 있기를 원합니다.

또 다른 예로는 스키마를 자주 변경하고 데이터베이스를 Oracle에서 버전 5.6(IIRC)의 Postgresql로 변경하는 Satellite/Spacewalk가 있습니다.

특히 분산/마이크로 서비스를 사용하여 컨테이너화된 빌드에서 소프트웨어 업그레이드를 수행하는 동안 일시적으로 데이터에 액세스해야 하는 많은 시나리오가 있습니다....

fatherlinux 에 2015년 08월 17일

본질적으로 저는 이제 -v bind 마운트로 일반 컨테이너를 실행한 다음 "도커 커밋"을 수행하여 수동 업그레이드를 수행해야 합니다. 자동화된 Dockerfile 빌드에서 동일한 기능을 사용할 수 없는 이유를 이해할 수 없습니까?

fatherlinux 에 2015년 08월 17일

👍7

두 번째 @yngndrw 는 캐싱을 지적합니다. 똑같은 논리가 Maven, npm, apt, rpm과 같은 많은 인기 있는 프로젝트에 적용됩니다. 공유 캐시를 허용하면 빌드 속도가 크게 빨라질 수 있지만 최종 이미지에 포함되어서는 안 됩니다.

stevenschlansker 에 2015년 08월 20일

👍61

@stevenschlansker에 동의합니다. 연결 캐시 볼륨에 대한 많은 요구 사항이 될 수도 있고 최종 이미지에 (분석된 상태로) 표시되어야 하지만 원시 데이터가 아닌 몇 기가바이트의 데이터가 될 수 있습니다.

NikonNLG 에 2015년 08월 20일

나는 또한 docker run 에서 사용할 수 있는 볼륨을 지원하기 위해 docker build 를 확장하는 것에 대한 일관된 저항에 물렸습니다. 재구축할 때마다 전체 패키지 리포지토리를 다시 다운로드해야 할 때 Docker 이미지에서 개발 및 반복 작업을 더 어렵게 만들고 시간을 소모하게 만드는 것처럼 보이기 때문에 '호스트 독립 빌드'라는 주문이 매우 설득력 있다는 것을 찾지 못했습니다. 이미지.

나의 초기 사용 사례는 개발 반복 속도를 높이기 위해 OS 패키지 리포지토리를 캐시하려는 것이었습니다. 내가 약간의 성공을 거두면서 사용한 해결 방법은 @fatherlinux 가 제안한 접근 방식과 비슷합니다. docker build 및 Dockerfile 로 레슬링을 완전히 포기하고 docker run 를 사용하여 처음부터 시작하는 것입니다. docker commit docker run

약간의 실험으로, 약간의 POSIX 셸 스크립팅: dockerize 를 사용하여 docker build 에 대한 본격적인 대체 기술로 내 기술을 확장했습니다.

누구든지 이 스크립트나 일반적인 접근 방식을 테스트하고 싶다면 그것이 흥미롭거나 도움이 되는지(또는 당신에게 전혀 효과가 있는지) 알려주십시오. 사용하려면 스크립트를 PATH의 어딘가에 넣고 빌드 스크립트( #! 항목)에 대한 shebang으로 추가한 다음 Docker 설치 스크립트의 시작을 표시하는 두 번째 shebang 줄 앞에 관련 환경 변수를 설정합니다.

FROM , RUNDIR 및 VOLUME 변수는 docker run 인수로 자동 전달됩니다.
TAG , EXPOSE 및 WORKDIR 변수는 docker commit 인수로 자동 전달됩니다.

다른 모든 변수는 셸에서 평가되고 docker run 환경 인수로 전달되어 빌드 스크립트 내에서 사용할 수 있습니다.

예를 들어, 이 스크립트는 빌드 간에 Alpine Linux 패키지를 캐시하고 재사용합니다(VOLUME은 홈 디렉토리를 CACHE에 마운트한 다음 설치 스크립트에서 OS의 패키지 저장소 캐시에 대한 심볼릭 링크로 사용됨).

#!/usr/bin/env dockerize
FROM=alpine
TAG=${TAG:-wjordan/my-image}
WORKDIR=/var/cache/dockerize
CACHE=/var/cache/docker
EXPOSE=3001
VOLUME="${HOME}/.docker-cache:${CACHE} ${PWD}:${WORKDIR}:ro /tmp"
#!/bin/sh
ln -s ${CACHE}/apk /var/cache/apk
ln -s ${CACHE}/apk /etc/apk/cache
set -e
apk --update add gcc g++ make libc-dev python
[...etc etc build...]

wjordan 에 2015년 08월 20일

👍10 ❤1

그래서 지난 주 MesoCon에서 Docker의 프랑스 파견단 :)을 만난 후 (즐거웠습니다) 사내에서 동일한 문제가 있다는 것을 알게 되었고 그들은 필요한 것을 새로운 슬림 이미지로 복사하는 해킹을 개발했습니다. .
나는 기업 세계에서 해킹을 환영합니다 ;) 이 요청을 적절하게 처리해야 한다고 말하고 싶습니다.
들어줘서 고마워 얘들아...

zrml 에 2015년 08월 24일

👍5

또한 빌드 시간 -v 플래그를 추가하여 빌드 사이에 캐시 디렉토리를 공유하여 빌드 속도를 높이는 데 찬성합니다.

raine 에 2015년 09월 17일

👍43

@yngndrw 관련 문제 두 개를 닫은 이유를 이해할 수 없습니다. 귀하의 #59 문제를 읽었지만 이것이 이것과 어떤 관련이 있는지 모르겠습니다. 어떤 경우에는 런타임에 필요하지 않을 때 컨테이너가 엄청나게 부풀려집니다. 1번 포스팅을 읽어주세요.
나는 내가 여기에서 뭔가를 놓치고 있지 않기를 바랍니다 ... 긴 하루 였기 때문에 :-o

zrml 에 2015년 09월 17일

@zrml 문제 https://github.com/aspnet/aspnet-docker/issues/59 는 모든 도커 파일에 빌드하는 동안 도커가 제공하는 기본 제공 레이어별 캐싱과 관련되었지만 이 현재 문제는 다음과 같이 미묘하게 다릅니다. 우리는 호스트 볼륨을 사용하여 볼륨을 특별히 사용하는 dockerfile에 의존하는 dockerfile 특정 캐싱을 제공하는 것에 대해 이야기하고 있습니다. https://github.com/aspnet/aspnet-docker/issues/59 문제는 aspnet-docker 프로젝트/리포지토리와 특별히 관련이 없기 때문에 종료했습니다.

당신이 언급하고 있다고 생각하는 다른 문제는 https://github.com/progrium/dokku/issues/1231 문제입니다. 이 문제는 기본 제공 도커 레이어 캐싱을 명시적으로 비활성화하는 Dokku 프로세스에 관한 것입니다. Michael은 이 동작을 구성할 수 있도록 Dokku를 변경했으며 Dokku 프로젝트/리포지토리와 관련된 문제가 해결되어 해당 문제도 종료되었습니다.

아직 해결되지 않은 Docker 관련 문제가 있을 수 있지만(예: https://github.com/aspnet/aspnet-docker/issues/59 문제에서 예상한 대로 Docker가 내장 계층 캐싱을 처리하지 않는 이유) 나는 그것이 왜 일어나는지 알아낼 기회가 없었고 여전히 일어나고 있는지 확인할 기회가 없었습니다. 여전히 문제인 경우 이 프로젝트/리포지토리에 대한 새 문제가 이 현재 문제와 구별되므로 이에 대해 제기해야 합니다.

yngndrw 에 2015년 09월 17일

@yngndrw 정확히, 그래서 우리는 이것이 다르고 알려진 @docker.com이라는 데 동의합니다. 그래서 괜찮으시다면 다시 열겠습니다... 글쎄요. 괜찮으세요?
적어도 닫기 전에 SF 동료들의 의견을 듣고 싶습니다.

BTW 로그 #3156에서 @cpuguy83 이 사용자 사례를 열고 모든 것을 설명하라는 요청을 받았습니다.

zrml 에 2015년 09월 18일

@zrml 내가 팔로우하고 있는지 잘 모르겠습니다. 다시 열고 싶은 것이 https://github.com/aspnet/aspnet-docker/issues/59 입니까? /aspnet/aspnet-docker 문제가 아니므로 해당 문제를 다시 여는 것이 옳지 않다고 생각합니다. /docker/docker에서 실제로 새로운 문제여야 하지만 확인이 필요하고 먼저 생성하는 재현 가능한 단계가 필요합니다.

yngndrw 에 2015년 09월 18일

아니, 아니.. 어제 닫은 #14080입니다.

zrml 에 2015년 09월 18일

이 문제가 아직 열려 있습니까?

yngndrw 에 2015년 09월 18일

@yngndrw 빨간색 "닫힌" 아이콘을 잘못 읽은 것 같습니다. 사과.

zrml 에 2015년 09월 21일

build time -v가 큰 도움이 될 것이라는 데 진심으로 동의합니다.

빌드 캐싱은 한 가지 사용 사례입니다.

또 다른 사용 사례는 빌드 시 ssh 키를 사용하여 계층에 저장하지 않고 개인 저장소에서 빌드하는 것입니다. 따라서 https://github.com/dockito/vault 와 같은 해킹(잘 설계된)이 필요하지 않습니다.

lukaso 에 2015년 09월 22일

👍10

여기가 기업 세계의 지옥이기 때문에 여기에 댓글을 다는 것입니다.
우리는 SSL 가로채는 프록시를 가지고 있습니다. 내가 이를 통해 트래픽을 보낼 수 있지만 많은 프로젝트는 SSL 연결이 양호하다고 가정하므로 끔찍하게 죽습니다.

내 컴퓨터(따라서 도커 빌더)가 프록시를 신뢰하더라도 도커 이미지는 신뢰하지 않습니다.
최악의 모범 사례는 이제 컨테이너 내부에서 컬을 사용하는 것이므로 고통스럽습니다. Dockerfile을 수정하여 빌드할 수 있도록 해야 합니다. -v 옵션을 사용하여 인증서를 마운트하고 만족할 수 있습니다.

이말입니다. docker의 오류가 적을수록 apt-get이 작동하는 방식과 유사한 시스템을 사용해야 할 때 https를 사용하는 패키지 관리자의 오류가 더 많습니다. 그것은 여전히 안전하고 검증 가능하며 http 프록시에 의해 캐시 될 수도 있습니다.

btrepp 에 2015년 10월 08일

@btrepp 또 다른 좋은 사용 사례에 감사드립니다.

zrml 에 2015년 10월 08일

다른 상황을 생각할 수 있습니다.

내 dockerfiles로 하고 싶은 것 중 하나는 "컴파일된" 도커 파일과 함께 빌드 도구를 제공하지 않는 것입니다. C 앱이 gcc를 필요로 하거나 루비 앱이 이미지에 번들러를 필요로 할 이유가 없지만 현재 이것을 가지고 있는 동안 도커 빌드를 사용하고 있습니다.

내가 가진 아이디어는 내부에 빌드할 때 여러 docker 명령을 실행하는 dockerfile을 지정하는 것입니다. 아래의 유사 dockerfiles.

다른 사람을 빌드하는 Docker 파일

FROM dockerbuilder
RUN docker build -t docker/builder myapp/builder/Dockerfile
RUN docker run -v /app:/app builder
RUN docker build -t btrepp/myapplication myapp/Dockerfile

btrep/myapplication dockerfile

FROM debian:jessie+sayrubyruntime
ADD . /app //(this is code thats been build using the builder dockerfile
ENTRYPOINT ["rails s"]

여기에 모든 번들링 설치/패키지 관리 및 빌드 스크립트를 수행하지만 런타임 컨테이너에 필요한 파일을 생성하는 임시 컨테이너가 있습니다.

그런 다음 런타임 컨테이너는 이것의 결과를 추가합니다. 즉, 설치된 ruby 이상이 필요하지 않습니다. GCC 또는 더 나은 정적으로 연결된 go의 경우 코어 OS 파일을 실행하는 것 외에 다른 것이 필요하지 않을 수 있습니다.

그렇게 하면 도커 이미지를 초경량으로 유지할 수 있습니다.

여기서 문제는 임시 빌더 컨테이너가 결국 사라질 것이라는 것입니다. 즉, 일종의 캐시를 로드할 수 있는 기능이 없으면 매우 비싸고 debian:jessie 를 여러 번 잡아야 한다는 의미입니다.

나는 사람들이 이와 같은 특정 기술을 사용하는 것을 보았지만 외부 http 서버를 사용하여 빌드 파일을 추가했습니다. 나는 모든 것을 docker로 빌드하는 것을 선호합니다. 도커 이미지를 사용하여 이를 제대로 수행하는 방법이 있을 수 있지만. run을 사용하여 볼륨을 마운트할 수 있습니다.

btrepp 에 2015년 10월 09일

👍6

여기 또 다른 예가 있습니다. 커널에 대한 모든 디버그 기호(Yuuuuge)가 있는 systemtap용 컨테이너를 빌드하고 싶다고 가정해 보겠습니다. yum 명령이 설치할 RPM을 알 수 있도록 기본 /lib/modules를 마운트해야 합니다.

또한 1.5GB 이미지(디버그 기호에서)가 아닌 다른 위치에 이러한 이미지를 표시하고 싶습니다.

나는 Dockerfile을 작성하러 갔고 그것이 불가능하다는 것을 깨달았습니다 :-(

docker run --privileged -v /lib/modules:/lib/modules --tty=true --interactive=true rhel7/rhel-tools /bin/bash
yum --enablerepo=rhel-7-server-debug-rpms install kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r)
docker ps -a
CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS                        PORTS               NAMES
52dac30dc495        rhel7/rhel-tools:latest   "/bin/bash"         34 minutes ago      Exited (0) 15 minutes ago                         dreamy_thompson
docker commit dreamy_thompson stap:latest

https://access.redhat.com/solutions/1420883

fatherlinux 에 2015년 10월 14일

해당 버그가 다른 이유로 종료되었으므로 #3949의 사용 사례를 여기에서 반복하고 싶습니다.

도커에서 독점 소프트웨어를 샌드박스 처리하고 싶습니다. 어디에서나 호스팅하는 것은 불법이며 다운로드 프로세스는 현실적으로(또는 법적으로) 자동화할 수 없습니다. 전체적으로 설치 프로그램은 약 22GB에 달합니다(릴리스마다 점점 커지고 있음). 빌드 시 이것이 도커 이미지에 복사되어야 한다고 기대하는 것은 어리석은 일이라고 생각합니다.

jeremyherbert 에 2015년 11월 19일

이 필요한 기능에 대한 소식이 있습니까?
감사 해요

zrml 에 2015년 11월 19일

_USER POLL_

_이 토론에 변경 사항이 있을 때 알림을 받는 가장 좋은 방법은 오른쪽 상단의 구독 버튼을 클릭하는 것입니다._

아래에 나열된 사람들은 무작위 +1로 귀하의 의미 있는 토론에 감사했습니다.

@vad

GordonTheTurtle 에 2015년 11월 30일

이 기능에 +1!

또 다른 사용 사례는 빌드 시 ssh 키를 사용하여 계층에 저장하지 않고 개인 저장소에서 빌드하는 것입니다. 따라서 https://github.com/dockito/vault 와 같은 해킹(잘 설계된)이 필요하지 않습니다.

이것은 우리의 사용 사례이기도 합니다(이 경우 호스트에서 tmpfs를 사용하여 렌더링된 ssh 키).

simonvanderveldt 에 2015년 12월 22일

이에 대한 또 다른 사용 사례는 빌드 시간을 줄이기 위해 CI 서버에 있는 node_modules 디렉토리의 로컬 캐시입니다.
npm install 는 매우 느리고 package.json 가 이미지에 ADD 인 현재 "최상의" 경우에도 npm install 가 실행되고 그 다음에야 실행됩니다. package.json 에 대한 변경 사항을 기반으로 추가되고 구축된 실제 프로젝트 소스는 모든 종속성을 다시 다운로드해야 합니다.

Node/npm 측에서 이에 대한 문제는 npm/npm#8836을 참조하십시오.

simonvanderveldt 에 2015년 12월 23일

👍16

느린 패키지 복원 및 레이어의 현재 패키지 캐싱 결과 이미지 크기와 관련된 aspnet-docker 문제입니다. 패키지 캐싱을 위해 탑재된 볼륨을 사용하는 것이 훨씬 더 좋습니다.
https://github.com/aspnet/aspnet-docker/issues/123

이것은 언어별 문제가 아니며 패키지 관리자가 이제 허용되는 표준이라는 점을 감안할 때 많은 사람들에게 영향을 미칠 것입니다.

yngndrw 에 2015년 12월 23일

OP는 "docker build -v"가 런타임 환경에서 빌드 프로세스를 분리하는 데 크게 도움이 된다는 점에서 문제를 해결했습니다.

나는 푸시/배포되는 실제 도커를 구축하는 데 사용되는 "Mulberry 항구"를 구축하는 여러 프로젝트를 보았습니다. 이는 관리 및 컴퓨팅 리소스 관점 모두에서 지나치게 복잡하여 CI 및 단위 테스트 속도가 느려지고 전반적으로 생산성이 떨어지는 개발 워크플로로 이어집니다.

qoke 에 2016년 01월 24일

👍1

나는 이것에 대해 생각해 왔으며 생각할 수있는 다른 옵션은 레이어를 "src"레이어로 표시하는 기능입니다.

해당 레이어의 라인을 따라 도커 빌드 중에만 액세스할 수 있지만 결과 이미지 파일에서는 가져올 수 없습니다.

이 방법으로 도커는 이전 레이어/이미지, 임시 빌드 아티팩트를 캐시할 수 있지만 최종 이미지를 활용하는 데 필요한 것은 아닙니다.

예.

FROM ubuntu
RUN apt-get install gcc
ADDPRIVATE . /tmp/src <--these can be cached by docker locally
RUNPRIVATE make     <-- basically these layers become scoped to the current build process/dockerfile
RUN make install <--result of this layer is required.

물론 이것은 중요한 파일을 제외할 수 있으므로 자신이 무엇을 더 잘하고 있는지 알아야 함을 의미합니다.

@yngndrw
netcore와 같은 상황에 대한 훨씬 더 나은 솔루션은 패키지 관리에 HTTPS를 사용하지 않고 도커 빌드를 위한 투명한 캐싱 프록시를 갖도록 iptables+squid를 설정하는 것입니다. 제 개인적인 의견은 이러한 패키지 관리자가 게임에서 ssl 사임으로 인해 기업 환경에서 사용하기에는 끔찍하지만 apt-get과 같은 것들은 완벽하게 잘 작동하고 이미 docker용 iptables+squid로 캐시할 수 있습니다.

또한 빌드 시간 볼륨 사용의 단점을 볼 수 있습니다. dockerfiles는 재현할 수 없으며 docker build -t btrepp/myapp 외부에서 추가 설정이 필요합니다. 또한 dockerhub에서 자동화된 빌드를 어렵게 만들 것입니다.

btrepp 에 2016년 03월 16일

👍1

@brepp : 나는 당신의 제안을 좋아합니다. 나는 Docker가 우리에게 알려주는 하드코딩된(일반적으로 나쁜 일이라는 것을 알고 있음) 사용 사례를 위해 살 수도 있습니다. 그래야 모든 레이어에서 최종 아티팩트를 빌드할 때 잊어버릴 수 있는/제거할 수 있는 최종 아티팩트를 알 수 있습니다. /this_is_the_tmp_explosion_folder_that_will_be_removed_from_your_final_container_image에 탑재됨
충분히 쉬운....

zrml 에 2016년 03월 16일

👍1

@btrepp 소스 레이어 아이디어가 아주 마음에 듭니다.

그러나 SSL을 사용하지 않는 패키지 관리자에 관해서는 동의하지 않을 수 없습니다.

그런 패키지를 캐시하려면 공식 소스를 미러링하는 대신 (로컬) 개인 패키지 피드를 사용해야 합니다. 특히 많은 패키지 관리자가 패키지에 서명하지 않아 HTTPS에 의존한다는 점을 고려할 때 HTTP로 되돌리는 것은 좋지 않은 생각인 것 같습니다.

yngndrw 에 2016년 03월 24일

이 문제가 아직 해결되지 않은 동안 사용할 수 있는 문법/로커 도구가 있습니다.

sergle 에 2016년 03월 24일

👍14 🎉9 ❤7

@yngndrw

내 요점은 로컬 프록시 등이 오랫동안 해결된 문제입니다. 패키지 관리자는 확인만 필요하며 개인 정보는 필요하지 않습니다. https를 사용하는 것은 인증을 제공하는 게으른 방법이지만 개인 정보 첨부 파일과 함께 제공됩니다.

http(s)를 통해 풀다운될 때 "super_awesome_ruby_lib"를 비공개로 설정해야 하는 이유는 없습니다. 더 좋은 방법은 루비 보석에 열쇠 고리가 있는 것입니다. 또는 알려진 공개 키를 사용하여 패키지에 서명할 수도 있습니다. 이것은 apt-get이 작동하는 방식이며 표준 http 프록시가 캐시할 수 있도록 합니다.

로컬 개인 패키지 피드와 관련하여 docker는 자체적으로 이를 잘 지원하지도 않습니다. 표준 피드를 비활성화하는 방법은 없으며 https 인증서가 인증서 저장소에 없으면 _올바르게_ 느슨해집니다. 나는 docker가 이미지를 가져올 때도 최소한 메인 피드를 항상 확인하기를 원한다고 확신합니다. Afaik 로켓/rkt 구현은 서명+http를 사용하여 컨테이너 이미지를 가져오려고 했습니다.

빌드 시간 볼륨의 주요 동기가 패키지 캐싱인 경우 현재 docker의 자동화/순수성을 일부 손상시키기보다는 캐싱을 더 잘 지원하도록 패키지 관리자에게 압력을 가해야 한다고 생각합니다.

분명히 말해서, 저는 패키지 관리자가 http를 사용하고 https를 삭제하도록 전환하는 것을 옹호하지 않습니다. 중간자 공격을 방지하기 위해 패키지 검증이 필요합니다. 그들이 필요로 하지 않는 것은 https를 "보안 catch all sledgehammer" 제공으로 사용하는 개인 정보 보호 측면입니다.

btrepp 에 2016년 03월 29일

👎2

정말 좁은 시야입니다. 당신은 패키지 관리자의 전체 영역에 애플리케이션이 구축될 것이라고 생각하는 방식에 대한 Docker의 처방에 맞게 동작 방식을 변경하도록 요청하고 있습니다.

이 스레드에서 이것이 필요한 이유에 대한 다른 예도 많이 있습니다. "응용 프로그램을 구축하는 데 사용하는 모든 도구가 작동하는 방식을 변경해야 합니다"라고 말하는 것이 문제를 해결하는 것이 아니라 사용자를 멀어지게 할 뿐입니다.

(나는 또한 공개 레지스트리에 대한 Docker의 첨부에 대해 강력히 동의하지 않습니다. 공개 레지스트리에 대한 액세스를 금지하고 내부 레지스트리만 사용하도록 허용하는 것을 매우 선호합니다. 그러나 그것은 완전히 다른 주제입니다.)

stevenschlansker 에 2016년 03월 29일

👍11

저에게는 docker build -v 도 필요합니다.

우리의 경우 관련 제품의 사전 구성된 설치로 구성된 이미지를 만들고자 하며 설치 프로그램은 2GB 이상입니다. 호스트 볼륨을 마운트할 수 없기 때문에 호스트 OS에 이미 다운로드를 했음에도 불구하고 설치 프로그램으로 이미지를 빌드할 수 없습니다. 이를 위해 https cert/auth가 있는 프록시와 같은 다양한 도구/프로토콜을 사용할 수 있습니다. , 또는 어쩌면 비트 토렌트.

이 문제를 해결하기 위해 wget을 사용하여 docker build 동안 설치 프로그램을 다시 다운로드해야 합니다. 이는 훨씬 제한된 환경이고 훨씬 덜 편리하고 시간이 많이 걸리고 오류가 발생하기 쉽습니다.

또한 제품 설치/구성 옵션의 유연성 때문에 설치 프로그램과 함께 이미지를 배송하는 것보다 제품이 사전 설치된 상태로 이미지를 배송하는 것이 훨씬 더 합리적입니다.

ryenus 에 2016년 08월 02일

👍7

@thaJeztah 이런 일이 일어날 가능성이 있습니까?

graingert 에 2016년 10월 20일

Fwiw 이것이 내가 docker를 사용하지 않는(또는 실제로 할 수 없는) 유일한 이유입니다.

jeremyherbert 에 2016년 10월 20일

-v 옵션이 포함된 Red Hat 버전의 docker에 패치가 있습니다. 그러나 이에 대한 진정한 해결책은 docker 빌드가 아닌 OCI Container Images를 빌드하는 새롭고 다른 방법을 빌드하는 것입니다.

rhatdan 에 2016년 10월 20일

👍5

@rhatdan RHEL 또는 Fedora?

jeremyherbert 에 2016년 10월 20일

👍2

우리는 또한 resin.io에서 내부 버전의 도커에서 도커 빌드의 -v 옵션을 구현했습니다. 여기에서 차이점을 찾을 수 있습니다. https://github.com/resin-io/docker/commit/9d155107b06c7f96a8951cbbc18287eeab8f60cc

petrosagg 에 2016년 10월 20일

@rhatdan @petrosagg 이에 대한 PR을 작성할 수 있습니까?

graingert 에 2016년 10월 20일

@jeremyherbert 패치는 RHEL, CentOS 및 Fedora의 모든 최신 버전에 제공되는 도커 데몬에 있습니다...

fatherlinux 에 2016년 10월 20일

👍3 🎉1

@graingert 과거에 제출했지만 거부되었습니다.

rhatdan 에 2016년 10월 20일

@rhatdan 링크가 있나요?

graingert 에 2016년 10월 21일

@runcom 링크 있나요?

rhatdan 에 2016년 10월 21일

@thaJeztah 이것이 너희들이 거부했을 것입니까?

graingert 에 2016년 11월 01일

다음은 종료되었거나 응답하지 않은 기존 문제 목록입니다.
https://github.com/docker/docker/issues/3949
https://github.com/docker/docker/issues/3156
https://github.com/docker/docker/issues/14251
https://github.com/docker/docker/issues/18603

RHEL/CentOS/Fedora에서 사용되는 Project Atomic 패치에 대한 정보는 다음에서 찾을 수 있습니다.
http://www.projectatomic.io/blog/2016/08/docker-patches/

daveisfera 에 2016년 11월 01일

@daveisfera 는 RW 볼륨이 아닌 R 볼륨만 추가하는 것처럼 보이므로 @yngndrw 및 내 사용 사례에서는 작동하지 않습니다.

graingert 에 2016년 11월 01일

@graingert RW 볼륨이 필요한 이유는 무엇입니까? 특정 경우에 대한 해결 방법으로 읽기 전용을 이해합니다.

cpuguy83 에 2016년 11월 01일

스키마 마이그레이션을 테스트하는 것이 좋은 이유 중 하나입니다...

2016년 11월 1일 오전 10시 36분에 Brian Goff는 다음과 같이 썼습니다.

@graingert https://github.com/graingert RW 볼륨이 필요한 이유는 무엇입니까?
특정 경우에 대한 해결 방법으로 읽기 전용을 이해합니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/14080#issuecomment -257582035,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAHLZdp0D6fAtuNglajPBIwnpWGq3slOks5q5050gaJpZM4FIdOc.

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

fatherlinux 에 2016년 11월 01일

@cpuguy83 RW의 또 다른 사용 사례는 ccache 입니다.

thebigb 에 2016년 11월 01일

@fatherlinux 팔로우가 확실하지 않습니다. 이 작업에 볼륨이 필요한 이유는 무엇입니까? 또한 빌드 단계에서 수행해야 하는 이유는 무엇입니까?

cpuguy83 에 2016년 11월 01일

ASP.Net 5 패키지 관리자에 의해 다운로드/업데이트되는 캐싱 패키지라는 이 기능에 대한 약간 다른 사용 사례가 있습니다. 패키지 관리자는 자체 캐시 폴더를 관리하므로 궁극적으로 빌드 간에 재사용할 수 있는 폴더만 있으면 됩니다.

예를 들어 마운트를 바인딩합니다.

docker build -v /home/jenkins/pythonapp/cache/pip:/root/.cache/pip  -t pythonapp .
docker build -v /home/jenkins/scalaapp/cache/ivy2:/root/.ivy2  -t scalaapp .

graingert 에 2016년 11월 01일

👍2

스키마 마이그레이션을 수행해야 하는 경우가 많기 때문에
소프트웨어가 설치됩니다. 읽기 전용 컨테이너를 실행하는 경우 다음을 수행해야 합니다.
에 있을 때 외에는 소프트웨어를 설치하지 마십시오.
빌드 단계.....

2016년 11월 1일 오전 10시 42분에 Brian Goff는 다음과 같이 썼습니다.

@fatherlinux https://github.com/fatherlinux 팔로우하고 있는지 잘 모르겠습니다.
이 작업에 볼륨이 필요한 이유는 무엇입니까? 또한 그 동안 수행되어야 하는 이유
빌드 단계?
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/14080#issuecomment -257583693,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAHLZfhBG8RUWtqPD-6RaLC7uoCNc-3nks5q50_TgaJpZM4FIdOc.

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

fatherlinux 에 2016년 11월 01일

이 디렉토리의 내용으로 인해 빌드가 호스트에 종속되지 않는다는 것을 알고 있습니다(이 마운트가 없으면 빌드가 어쨌든 작동하게 되지만 속도가 느려질 수 있음).

graingert 에 2016년 11월 01일

NFS는 30년 전에 이것을 해결했습니다...

2016년 11월 1일 오전 10시 45분에 Thomas Grainger는 다음과 같이 썼습니다.

이 디렉토리의 내용이 빌드를 중지하지 않는다는 것을 알고 있습니다.
멱등성 또는 호스트 종속성(이러한 마운트가 없으면
어쨌든 작동하는 빌드)
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/14080#issuecomment -257584576,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAHLZS75Vq0BSEvUjI2oXORsS0el2mwOks5q51CQgaJpZM4FIdOc.

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

fatherlinux 에 2016년 11월 01일

NFS는 30년 전에 이것을 해결했습니다...

도움이 되지 않는 댓글

graingert 에 2016년 11월 01일

@graingert 죄송합니다. 심각하게 잘못되었습니다. 너무 빨리 응답하려고 했고 충분한 컨텍스트를 제공하지 않았습니다. 진지하게, 우리는 이러한 유형의 문제 중 일부를 해결하기 위해 CRIO와 함께 NFS를 찾고 있습니다.

이미지 레지스트리와 buld는 공통점이 많습니다. 당신이 말하는 것은 기본적으로 캐싱 문제입니다. NFS, 특히 내장된 캐싱은 빌드 호스트를 독립적으로 만들고 모든 캐싱을 처리할 수 있습니다.

따라서 -v 빌드 시간 옵션을 사용하더라도 빌드를 하나의 호스트에만 잠글 필요는 없습니다. 인터넷 규모에 독립적이지 않을 수도 있지만 단일 사이트 또는 위치에서 빌드 환경을 제어하는 많은 사람들에게는 충분합니다.

fatherlinux 에 2016년 11월 01일

@fatherlinux gitlab 또는 travis 캐싱을 사용하여 캐시 디렉토리를 가져오고 S3에 업로드/다운로드합니다.

graingert 에 2016년 11월 01일

@graingert 예, 하지만 특정 유형의 데이터/앱에서만 작동하며, posix 메타 데이터 및 블록 수준이 아닌 오른쪽 버킷 수준에서만 작동합니다. certian 유형의 프런트 엔드 및 미들웨어 앱의 경우 문제가 없습니다. 데이터베이스 스키마 마이그레이션의 경우 미리 테스트하고 속도를 위해 캐시를 로컬로 유지해야 하며 일반적으로 posix여야 합니다.

1TB의 데이터가 포함된 MySQL Galera 클러스터가 있고 업그레이드를 하려고 하는데 모두 컨테이너에 있다고 상상해 보십시오. Containerized/Orchestrated multi-node, sharded Galera는 정말 편리합니다. 업그레이드할 때마다 스키마 마이그레이션을 수동으로 테스트하고 싶지 않습니다.

데이터 볼륨(Kube 세계의 pv)을 스냅샷하고 빌드 서버에 노출한 다음 업그레이드 및 스키마 마이그레이션을 테스트하고 싶습니다. 모든 것이 올바르게 작동하고 테스트가 통과되면 프로덕션 컨테이너를 빌드하고 프로덕션에서 스키마 마이그레이션이 발생하도록 합니다....

fatherlinux 에 2016년 11월 01일

👍1

@graingert 죄송합니다. 추가하는 것을 잊은 다음 테스트 실행에 사용된 스냅샷을 버립니다... 빌드 및 테스트 이벤트를 별도로 조정하고 싶지는 않지만 가능하겠지만...

fatherlinux 에 2016년 11월 01일

@fatherlinux 나는 그것이 직교 유스 케이스라고 생각합니다 ...

graingert 에 2016년 11월 01일

@graingert 유용한 의견이 아닙니다. 무엇에 직교합니까? 빌드 중 -v에 대한 요청과 직교하여 이 대화를 이해했습니다.

fatherlinux 에 2016년 11월 01일

이 플래그에는 몇 가지 다른 용도가 있습니다.

캐시, 도커 빌드 서버 간 공유
단일 Dockerfile의 '빌드 중'에만 적용되는 ADD와 유사한 키워드입니다. 예를 들어 대용량 파일을 추가한 다음 이미지에서 제외합니다.
모든 출력을 무시하는 키워드와 같은 ADD+RUN입니다. 예를 들어 거대한 파일을 추가한 다음 한 단계를 실행하고 이미지에 대한 변경 사항을 무시합니다. 한 단계에서 ADD+RUN을 한 다음 레이어를 건너뜁니다.

graingert 에 2016년 11월 01일

👍2

나중의 두 가지 사용 사례는 두 개의 새로운 키워드로 더 깔끔하게 해결할 수 있습니다.

BUILDCONSTFILE <path>

각 RUN 전에 COPY <path> 를 실행하고 이후 이미지에서 <path> 를 삭제합니다.

TEST <cmd> WITH <paths>

경로를 복사하고 명령을 실행한 다음 종료 상태가 0이면 상위 이미지에서 빌드를 계속하고 그렇지 않으면 빌드를 중지합니다.

graingert 에 2016년 11월 01일

👍1

개인적으로 TEST ... WITH는 컨테이너 전체를 테스트하는 다른 CI 단계에서 더 잘 처리된다고 생각합니다.

graingert 에 2016년 11월 01일

다음과 같이 시작하겠습니다. 저는 --mount 를 빌드에 추가하는 것이 _생각_합니다("-v"는 그다지 많지 않을 것입니다). 구현, 캐싱 처리(또는 처리되지 않음) 등에 대해 100% 확신할 수 없습니다.

도커 프로젝트의 경우 우리가 하는 일은 빌더 이미지를 빌드하는 것입니다.
기본적으로 필요한 모든 것이 있고 코드를 복사하지만 실제로 도커를 빌드하지는 않습니다.
이것을 조정하는 Makefile 가 있습니다. 따라서 make build 는 이미지를 빌드하고 make binary 는 build 를 종속성으로 사용하여 바이너리를 빌드합니다.

바이너리를 만들면 빌드 이미지가 실행되고 빌드가 수행됩니다. 이를 통해 증분 빌드를 위한 패키지 캐시를 포함하여 필요한 것을 마운트할 수 있습니다.
이 중 대부분은 매우 간단하고 쉽게 조정됩니다.
따라서 오늘날에는 확실히 이 경우를 처리할 수 있는 방법이 있습니다. 도커만으로는 100% 처리할 수 없으며(반드시 나쁜 것은 아닙니다) CI 시스템과 함께 이 작업을 수행해야 합니다.

cpuguy83 에 2016년 11월 01일

@ cpuguy83 내 사용 사례의 대부분을 못잡을 것이라고 생각합니다. 내가 이해하기 위해, 읽기 전용을 의미하는 --mount를 의미합니까? 그리고 -v는 읽기/쓰기입니까?

fatherlinux 에 2016년 11월 01일

@cpuguy83 우리는 또한 IMHO가 점점 더 일반적인 패턴이 되고 있는 "빌더" 이미지를 주로 구축하고 있습니다...

fatherlinux 에 2016년 11월 01일

@fatherlinux swarm 서비스 및 현재(1.13용) docker run 는 훨씬 더 정확하고 유연한 --mount 를 지원합니다. https://docs.docker.com/engine/reference/commandline/service_create/# /add -bind-mounts-or-volumes

문서에 세 번째 유형의 마운트인 tmpfs 가 누락된 것 같습니다.

cpuguy83 에 2016년 11월 01일

👍1

아 정말 멋지네요...감사합니다...

2016년 11월 1일 오후 2시 20분에 Brian Goff는 다음과 같이 썼습니다.

@fatherlinux https://github.com/fatherlinux 떼 서비스 및 현재
(1.13용) |도커 실행| 지원 |--mount| 훨씬 더 정확한
유연함:
https://docs.docker.com/engine/reference/commandline/service_create/#/add -bind-mounts-or-volumes
문서에 세 번째 유형의 마운트인 |tmpfs|가 누락된 것 같습니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/14080#issuecomment -257648598,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAHLZXv_VBfVi4WUAjVijE-SKR0ErRC4ks5q54L2gaJpZM4FIdOc.

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

fatherlinux 에 2016년 11월 01일

@cpuguy83 우리는 또한 빌더 패턴을 많이 사용하고 있으며 이미지에 지속되지 않고 레이어 무효화에도 살아남는 캐싱이 필요합니다.

우리는 Yocto 이미지를 구축하고 NFS 스토리지에 공유 상태 캐시를 가지고 있습니다. 또 다른 사용 사례는 npm 캐시로 전체 RUN npm install 레이어를 무효화할 수 있지만 캐시된 패키지로 인해 더 빠르게 다시 계산할 수 있습니다.

petrosagg 에 2016년 11월 01일

👍2

@graingert 의 게시물을 기반으로 한 가능한 타협으로 dockerfile에 거대한 파일의 선택적 해시가 없을 수 있으며 docker는 빌드를 실행할 때 이것을 확인합니까? 그러면 결정적 빌드에는 문제가 없으며, 빌드하는 사람에게는 특정 지점에서 이상한 오류가 폭발하기보다는 필요한 종속성이 없다는 것이 명백할 것입니다. 어쨌든 dockerfile과 함께 배포해야 하는 ssh 키 등에 대해서도 마찬가지입니다.

또한 거대한 파일을 _복사_해야 하는 아이디어는 이상적이지 않다고 생각합니다. 내가 사용하고 싶은 파일 크기는 10-40GB 정도이며, 좋은 ssd를 사용하더라도 최소 1~2분 분량의 복사가 필요합니다. 이것은 이미 도커에 있는 ADD 지시문에 대한 내 문제입니다. 빌드할 때마다 이미지에 30GB를 추가하고 싶지 않고 추가 여유 공간을 확보하고 이미지를 스쿼시해야 하는 문제를 처리해야 합니다.

jeremyherbert 에 2016년 11월 02일

그것은 우리가 이것을 사용하는 것에 대해 작동하지 않을 것입니다. yocto 빌드 시스템의 sstate 캐시가 포함된 볼륨이 있는데 이는 빌드에서 RW에 바인드 마운트된 것입니다. 모든 캐시 누락이 빌드 중에 계산되고 이후를 위해 sstate에 저장되기 때문입니다. 우리 디렉토리도 ~30GB에 있으므로 해시를 계산하는 데에도 시간이 걸립니다.

나는 결정론적 빌드 개념을 결코 이해하지 못했다. 오늘날의 의미론에도 발을 쏘는 방법이 있습니다. 예를 들어 내부 IP에서 무언가를 curl 할 수 있습니다. 갑자기 이 Dockerfile은 모든 곳에서 작동하지 않으며 호스트에 따라 다릅니다. 하지만 왜 그렇게 하고 싶은지 정당한 경우가 있습니다. 예를 들어 로컬 HTTP 캐시.

따라서 빌드는 어쨌든 결정적이지 않고 오늘날 네트워크를 통해 바인드 탑재 볼륨을 에뮬레이트할 수 있기 때문에 필요한 경우 적절한 경고와 함께 기본 방식을 제공하지 않는 이유는 무엇입니까?

petrosagg 에 2016년 11월 02일

👍1

@petrosagg @zrml @thaJeztah 우리가 알고 있는 것은:

#7115 #3156을 샅샅이 뒤지면 이 동일한 문제를 논의하는 데 오랜 세월이 흐른 긴 문제 목록을 찾을 수 있습니다.
대부분은 재현성 이유(또는 이전 Dockerfile syntax is frozen 주석, 그리고 HEALTHCHECK 명령이 추가된 후 고정이 제거되었지만 문제는 닫힌 상태로 남아 있음)로 인해 종료되었습니다.
이 문제로 인해 많은 팀이 수년 동안 일상적인 개발에서 좋은 컨테이너 사용성/생산성을 가지지 못했습니다. @brepp 이 말했듯이 이것은 지옥입니다.
Docker 사람들은 이 문제를 알고 있지만 Oh my docker build broken! 좋지 않은 공유 캐시로 인한 문제
그러나 디스크 캐시에서 네트워크 캐시로 이동하는 것은 어떤 식으로든 빌드 안정성을 향상시키는 것으로 보이지 않고 http를 통한 영광스러운 캐시처럼 작동하며 상황을 악화시키는 것으로 나타났습니다(모든 빌드, HTTPS, 파일 크기, 컨테이너 빌드 시 디스크 스래싱, 레이어 캐싱, 복잡한 빌드 오케스트레이션 등)

우리가 알고 있는 모든 것을 감안할 때 이것은 Dupe 또는 WontFix로 종료될 가능성이 높다고 생각합니다. 우리가 제공하는 사용 사례는 중요하지 않은 것 같습니다. 업데이트: 여기서 틀리게 되어 기쁩니다. 제안서가 열려 있습니다 :)

우리 회사는 불가지론적 컨테이너 런타임으로 이동했으며 곧 불가지론적 이미지 구축 환경으로 이동해야 합니다. 그러나 이것은 부정적인 것이 도움이 되지 않기 때문에 그것에 대해 논의하기에 적절한 장소가 아닙니다. 그건 별도의 포스팅이어야 합니다.

rdsubhas 에 2016년 11월 18일

👍4

@rdsub 작업이 끝나면 링크를 공유하시겠습니까?

jeremyherbert 에 2016년 11월 18일

👍2

@rdsubhas 멋진 요약입니다. @cpuguy83 이 대부분의 사용 사례를 다루는 빌드 중에 --mount 를 추가하는 것이 괜찮다고 생각하기 때문에 이 스레드가 속임수/원칙 수정으로 닫힐 것 같지 않습니다.

내가 알고 싶은 것은 현재 제안이 다음과 같다는 것입니다.

Dockerfile 구문을 변경하지 않음
빌드를 현재보다 더 호스트 종속적으로 만들지 않습니다.

아이디어에 대해 어떤 반론이 남아 있습니까? 없는 경우 --mount 메커니즘에 대한 구현 세부 정보를 논의하기 시작해야 합니다.

빌드가 이미 호스트 종속적이고 재현할 수 없다는 주장을 다시 시행하기 위해 이 속성과 함께 Dockerfile 조각 목록을 제공합니다.

# Install different software depending on the kernel version of the host
RUN wget http://example.com/$(uname -r)/some_resource

# example.intranet is only accessible from specific hosts
RUN wget http://example.intranet/some_resource

# get something from localhost
RUN wget http://localhost/some_resource

# gcc will enable optimizations supported by the host's CPU
RUN gcc -march=native .....

# node:latest changes as time goes by
FROM node

# ubuntu package lists change as time goes by
RUN apt-get update

# install different software depending on the docker storage driver
RUN if [ $(mount | head -n 1 | awk '{print $5}') == "zfs" ]; then .....; fi

petrosagg 에 2016년 11월 19일

👍9 ❤1

솔직히 --mount 를 추가하고 사용자가 캐시 무효화( --no-cache )를 처리하도록 하면 괜찮을 것 같습니다. CLI에서 전체 또는 아예 없는 것보다 더 세분화된 캐시 제어를 살펴보고자 할 수도 있지만 이는 별도의 주제입니다.

cpuguy83 에 2016년 11월 20일

👍4 ❤1

내 사용 사례

나는 잠시 동안 비슷한 문제에 직면해 왔지만 솔루션이 완성될 때까지 이미지 크기를 늘리기로 결정했습니다. 누군가가 더 나은 해결 방법을 찾을 경우를 대비하여 여기에 내 시나리오를 설명하려고 합니다.

정황

CircleCI에는 빌드 중에 모든 내부 종속성을 다운로드할 수 있는 ssh 키가 있습니다.
GitHub는 내부 종속성을 호스팅하고 다른 것들은 빌드하는 동안 이미지 내에서 다운로드할 수 있습니다.

옵션

--build-arg 를 사용하여 빌드 중에 토큰을 전달합니다(권장하지 않음). 이것은 추가 단계 없이 "그냥 작동"하기 때문에 매우 매력적이고 쉬운 옵션입니다.
모든 종속성을 다운로드하고 빌드 컨텍스트에 추가합니다. 불행히도 ADD 및 COPY 는 별도의 레이어에서 실행되므로 이전 레이어의 데이터가 붙어 있습니다.

어떤 경우에는 내 이미지의 크기가 두 배 이상이지만 전체 크기는 지금은 견딜 수 있습니다. 빌드 히스토리에서 빌드 시간 인수를 제거하기 위한 PR(찾을 수 없는 것 같습니다)이 있었던 것 같지만 irrc 캐싱 문제로 인해 허용되지 않았습니다.
다른 해결 방법이 사용 중이라는 소식을 듣게 되어 기쁩니다.

misakwa 에 2016년 12월 06일

@misakwa 우리는 1.14에서 빌드에 대한 비밀을 지원할 것입니다.

cpuguy83 에 2016년 12월 06일

👍5

@cpuguy83을 듣게 되어 매우 기쁩니다. 언제 출시될지 지켜봐야겠습니다. 내 작업 흐름 중 일부를 확실히 단순화할 것입니다.

misakwa 에 2016년 12월 06일

우리는 1.14에서 빌드에 대한 비밀을 지원할 것입니다.

yarn-cache 와 같은 다른 유형의 볼륨 매핑 빌드 타임 매핑에도 작동합니까?

whitecolor 에 2016년 12월 27일

👍2

BTW docker-compose를 사용하여 프로덕션 이미지를 빌드하는 흥미로운 방법이 있습니다. 작동하고 매우 효과적입니다.

따라서 docker-compose.build.yml 파일을 다음과 같이 작성할 수 있습니다.

services: 
  my-app:
    image: mhart/alpine-node:7.1.0
    container_name: my-app-build-container # to have fixed name
    volumes:
    - ${YARN_CACHE}:/root/.cache/yarn # attach yarn cache from host
    - ${HOME}/.ssh:/.ssh:ro    # attach secrets
    - ./:/source
    environment: # set any vars you need
     TEST_VAR: "some value"    
    ports:
    - "3000"
    working_dir: /app/my-app # set needed correct working dir even if if doesn't exist in container while build type
    command: sh /source/my-app.docker.build.sh # build script

1) docker compose를 사용하여 컨테이너를 빌드합니다.

$ docker-compose -f docker-compose.build.yml up --force-recreate my-app

컨테이너를 생성하고 쉘 빌드 스크립트 my-app.docker.build.sh 를 실행합니다. Dockerfile 를 사용하지 않고 빌드 스크립트에서 모든 작업을 수행합니다.

필요한 OS 패키지 설치
필요한 소스 코드 복사(매핑된 /source 폴더에서)
종속성 설치
필요한 경우 빌드/컴파일/테스트
대상 환경이 작동하는 데 필요하지 않은 패키지 및 항목 제거(최종 이미지 크기 줄이기)

그런 다음 대상 환경에서 실행해야 하는 CMD를 대체하여 컨테이너에서 이미지를 만듭니다.

docker commit -c "CMD npm run serve" my-app-build-container my-app-build-image:tag

따라서 이미지가 준비되었으며 빌드 시간 동안에만 사용할 수 있는 외부 얀 캐시 및 외부 비밀 키를 사용했습니다.

whitecolor 에 2016년 12월 28일

👍17 ❤3 🎉3 😄1

@whitecolor 넵 작동합니다 :) 한 가지만 제외하면 docker build 는 빌드 컨텍스트를 업로드하는 데 정말 효과적입니다. 탑재된 소스 볼륨은 불행히도 원격 도커 데몬에서 작동하지 않습니다(예: 저전력/대역폭 랩톱용 클라우드의 도커 머신). 이를 위해 우리는 성가신 docker run , docker cp , docker run 등 일련의 도커 명령을 수행한 다음 최종 이미지의 스냅샷을 찍어야 하지만 정말 해킹입니다.

이것을 공식적으로 docker 빌드의 일부로 만들고 레이어링을 사용하고 컨텍스트를 빌드하는 데 정말 도움이 됩니다 😄

rdsubhas 에 2017년 01월 11일

@rdsubhas 네 맞습니다

whitecolor 에 2017년 01월 11일

@whitecolor 정말 간단하고 효과적인 솔루션입니다. 프로젝트에서 30-40분 빌드를 약 5분으로 줄였습니다. 빌드 기능에 --mount를 사용할 수 있기를 기대하지만 현재로서는 이 솔루션이 파이프라인을 실제로 차단 해제합니다.

nuzz 에 2017년 01월 19일

이것은 내가 이해했지만 중복으로 표시되지 않은 문제 #17745에 대해 남긴 댓글입니다. 후자의 요점에 대해서는 내가 잘못 알고 있는 것 같습니다. "해결된 중복"으로 명시적으로 표시하고 버그의 맨 위 설명 영역에 표시하는 Bugzilla와 같은 시스템에 익숙하다는 것을 인정합니다. 나는 마음을 읽는 사람이 아닙니다. (그래서 내 사과 @graingert , 나는 아는 방법이 거의 없었으므로 20pt 글꼴로 나에게 소리칠 필요가 없습니다. 그건 과도했습니다.)

제 경우에는 이것이 데비안 시스템에서 유용할 것입니다. /var/cache/apt 를 볼륨으로 마운트하여 동일한 .deb 파일을 계속해서 다시 다운로드하지 않도록 합니다. (정말로 "무제한" 인터넷 할당량은 특히 여기 호주에는 존재하지 않으며, 있다고 하더라도 다운로드를 기다리는 데 시간을 낭비하게 됩니다.)

또는 다른 시나리오에서 빌드를 수행하고 있지만 이미지와 함께 제공할 필요는 없지만 주변에 있으면 유용한 아티팩트인 오류 목록 및 코드 검사 보고서와 같은 테스트 보고서도 생성합니다. 이는 CI 서버가 CI 서버가 선택하고 호스팅할 이미지를 빌드할 때 볼륨에 기록될 수 있습니다.

또는 오늘 밤에 저는 제 자신을 위해 Gentoo 기반 이미지를 만들고 있습니다. 호스트에서 /usr/portage 를 마운트하고 싶습니다. Dockerfile 가 볼륨을 마운트하지 않고 실행할 때 "이봐, /usr/portage (컨테이너에 있음)이 비어 있습니다. 문제 없습니다. 그냥 가져갈게요"라는 것을 깨닫는 것은 어렵지 않습니다. 또는, 볼륨을 있는 그대로 사용하여 새 복사본을 가져오는 시간을 절약합니다.

이러한 스마트를 추가하는 것은 Bourne 셸 스크립트에 간단한 if 문입니다... IF 볼륨을 탑재하는 기본 논리가 처음에 존재합니다. 지금 제 Gentoo 이미지에 대해 빌드를 할 때마다 /usr/portage 를 가져와야 합니다(다행히도 미러는 제 LAN에 있습니다). 이는 한 단계가 완료될 때까지 몇 분 정도 기다려야 한다는 것을 의미합니다.

이것이 가치 있는 제안인 많은 이유와 #7115에서 제안된 중첩 빌드가 위의 경우에 도움이 될지 의심스럽습니다.

@whitecolor 는 흥미로운 접근 방식을 가지고 있지만 그렇게 하면 빌드를 달성하기 위해 Docker 시스템 외부에서 Makefile 를 사용하는 것이 좋습니다.

sjlongland 에 2017년 01월 21일

@sjlongland 나는 당신에게 소리 지르는 것이 아니라 큰 "해결된 중복"통지를 폴리 필링하고있었습니다.

graingert 에 2017년 01월 23일

저는 docker 및 docker-compose를 사용하여 인프라를 위한 여러 컨테이너를 구축하고 있습니다. 컨테이너는 대부분 nodeJS로 작성된 마이크로 서비스이지만 maven 프레임워크를 사용하여 Java로 작성된 마이크로 서비스가 하나 있습니다.
Java 컨테이너를 다시 빌드할 때마다 Maven에서 수십 개의 종속성이 다운로드됩니다. 몇 분이 걸립니다. 그런 다음 코드는 약 15초 만에 빌드됩니다.

이것은 매우 추악하며 우리의 CI 전략에 상당한 영향을 미칩니다.

이 시나리오에서는 빌드 종속성이 있는 볼륨이 누락되거나 비어 있는지 여부가 중요하지 않습니다. 이 경우 종속성이 다운로드되기 때문입니다. 재현성은 영향을 받지 않습니다.

나는 의존성을 변조하고 거기에 불쾌한 코드를 주입할 수 있기 때문에 보안 문제가 있다는 것을 이해합니다. "빌드 볼륨"으로 빌드된 이미지를 docker-hub 또는 docker-store에 게시할 수 없도록 하여 쉽게 우회할 수 있는 IMHO.
이것을 다르게 설명하려면 기업용과 개인용 docker 사이에 범위를 구분해야 합니다.

stepps 에 2017년 01월 26일

👍1

@stepps 는 docker-compose 대신 https://pypi.python.org/pypi/shipwright 를 확인하십시오.

graingert 에 2017년 01월 27일

나는 나 자신을 위한 좋은 해결책을 찾기 위해 잠시 동안 이 스레드를 따라왔습니다. 최소한의 노력으로 유연한 방식으로 최소한의 컨테이너를 구축하기 위해 저는 @edannenberg의 https://github.com/edannenberg/gentoo-bb 를 정말 좋아합니다.

런타임 종속성과 빌드 시간 종속성을 구분합니다.
빌드는 컨테이너에서 수행되며 격리되고 깨끗하며 반복 가능합니다.
이미지와 빌드 순서 간의 종속성을 처리합니다.

이것은 Gentoo의 포티지 및 이머징을 기반으로 하므로 @sjlongland Gentoo 기반 이미지에 대해 좋아할 수 있습니다. dist 파일과 바이너리 패키지가 캐시되므로 다시 다운로드하거나 빌드할 필요가 없어 빠르게 다시 빌드할 수 있습니다. 빌드 프로세스를 쉽게 사용자 정의할 수 있는 후크가 있습니다. git을 사용하여 repo를 복제한 다음 빌드하고 최종 이미지에 빌드만 유지하는 것과 같이 타사 소프트웨어를 설치하는 것은 쉽습니다. Dockerfile을 템플릿화합니다.

figlet 에 대한 간단한 예는 다음과 같습니다. -

빌드.conf:

IMAGE_PARENT="gentoobb/glibc"

도커파일.템플릿:

FROM ${IMAGE_PARENT}
ADD rootfs.tar /
USER figlet
CMD ["gentoo-bb"]
ENTRYPOINT ["figlet"]

build.sh

PACKAGES="app-misc/figlet"

configure_rootfs_build() {
        useradd figlet
}

나는 @whitecolor 의 솔루션이 마음에 듭니다. Docker 기술과 간단한 셸 스크립트 또는 사용하려는 다른 것을 사용하면 간단합니다. gentoo-bb가 더 완벽하기 때문에 사용하고 있습니다. Shipwright는 브랜치 처리와 같은 개발자 중심 기능이 더 좋아 보입니다. https://github.com/grammarly/rocker 도 흥미로운 것 같습니다. 공유해 주셔서 감사합니다.

berney 에 2017년 02월 05일

👍2

더미에 또 다른 목소리가 추가되었습니다. 빌드 시 로컬 볼륨을 마운트할 수 있다면 매우 복잡한 개발 환경이 훨씬 더 간단해질 것입니다.

nickwilliams-eventbrite 에 2017년 02월 28일

👍11

해결 방법은 로컬 파일을 노출하는 http 서버를 빌드하는 동안 실행한 다음 curl/wget 등을 사용하여 파일을 도커 빌드로 가져오는 것입니다. 그러나 나는 그런 해킹이 필요하지 않기를 정말로 바랍니다.

ibukanov 에 2017년 03월 07일

또 다른 사용 사례. 10가지 다른 버전의 독점 OS를 구축하기 위한 도커 이미지를 만들고 싶습니다. 설치 미디어가 >80GB이므로 이것을 도커 빌드 환경에 복사할 수 없습니다. 바인드 마운트가 훨씬 더 바람직합니다.

uSpike 에 2017년 03월 10일

또 다른 하나 : 내 프로젝트 사용은 컨테이너의 소스에서 빌드하기 위해 저장소에 Dockerfiles를 배포합니다. 현재 github에서 컨테이너의 다른 git 클론을 가져옵니다. 얕은 클론 등이 있지만 여전히 ...

Piezoid 에 2017년 03월 22일

그래서 방금 rhel7 빌드 호스트에서 [1]을 테스트했으며 Red Hat의 docker 데몬 빌드에는 빌드에 대한 -v 옵션이 있습니다. 나는 CentOS/Fedora에서 테스트하지 않았지만 Fedora/CentOS에도 아마 있을 것이라고 상상할 것입니다. 테스트할 가치가 있습니다. 또한 RHEL 개발자 구독은 이제 무료입니다[2].

fatherlinux 에 2017년 03월 22일

👍1

@fatherlinux Fedora에서 `docker build -v'도 사용할 수 있습니다.

ibukanov 에 2017년 03월 22일

@fatherlinux CentOS 7 버전에 포함되어 있습니다.

+1 공식 도커에 추가할 때 정말 유용한 기능이라고 생각합니다.

nathanjackson 에 2017년 03월 30일

👍2

centos와 linuxmint(현재 17.03.1-ce 실행) 모두에서 업데이트되었습니다. 여기에 뭔가 빠졌습니까? -v 옵션이 보이지 않습니다.

민트에

$ docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
$ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18
DISTRIB_CODENAME=sarah
DISTRIB_DESCRIPTION="Linux Mint 18 Sarah"
$ docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

센토스 7에서

# docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
# docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:05:44 2017
 OS/Arch:      linux/amd64
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)

wilfriedroset 에 2017년 03월 30일

@wilfriedroset CentOS 7에서는 비공식 Docker 패키지가 옵션을 제공합니다. EPEL 저장소의 일부라고 생각합니다.

nathanjackson 에 2017년 03월 30일

@nathanjackson 감사합니다. 공식 릴리스에서 이 기능에 대한 ETA가 있습니까?

wilfriedroset 에 2017년 04월 01일

@wilfriedroset AFAIK, "빌드 이식성"을 유지하기 위해 이 기능이 공식 도커에 없어야 한다고(여러 번) 결정되었기 때문에 ETA가 없습니다. Docker 빌드 서비스를 포함하여 어디에서나 Dockerfile을 실행할 수 있습니다.

내 경험상 제한된 빌드 이식성은 고객이 진정으로 원하는 것입니다. 그들은 빌드 환경/팜을 설정하고 해당 환경에서 빌드를 항상 다시 빌드할 수 있도록 합니다. -v 빌드 옵션은 어떤 식으로든 이를 방지하지 않습니다.

예를 들어 NFS 마운트를 사용하는 경우 모든 빌드 서버의 fstab에 해당 마운트가 있는지 확인하면 팜의 어느 곳에서도 문제 없이 빌드가 완료됩니다.

RHEL 7.3에서
````
[ root@rhel7 ~]# 도커 빌드 --help

사용법: 도커 빌드 [옵션] 경로 | URL | -

Dockerfile에서 이미지 빌드

옵션:
--build-arg value 빌드 시간 변수 설정(기본값 [])
--cgroup-parent string 컨테이너에 대한 선택적 상위 cgroup
--cpu-period int CPU CFS(Completely Fair Scheduler) 기간 제한
--cpu-quota int CPU CFS(Completely Fair Scheduler) 할당량 제한
-c, --cpu-shares int CPU 공유(상대 가중치)
--cpuset-cpus string 실행을 허용할 CPU(0-3, 0,1)
--cpuset-mems 문자열 실행을 허용할 MEM(0-3, 0,1)
--disable-content-trust 이미지 확인 건너뛰기(기본값 true)
-f, --file string Dockerfile의 이름(기본값은 'PATH/Dockerfile')
--force-rm 항상 중간 컨테이너 제거
--help 인쇄 사용
--isolation string 컨테이너 격리 기술
--label value 이미지에 대한 메타데이터 설정(기본값 [])
-m, --memory string 메모리 제한
--memory-swap string 메모리에 스왑을 더한 것과 같은 스왑 제한: 무제한 스왑을 활성화하려면 '-1'
--no-cache 이미지를 빌드할 때 캐시를 사용하지 않습니다.
--pull 항상 최신 버전의 이미지를 가져오려고 시도합니다.
-q, --quiet 빌드 출력을 억제하고 성공 시 이미지 ID를 인쇄합니다.
--rm 성공적인 빌드 후 중간 컨테이너 제거(기본값 true)
--shm-size string /dev/shm의 크기, 기본값은 64MB입니다.
-t, --tag 값 이름 및 선택적으로 ' name:tag ' 형식의 태그(기본값 [])
--ulimit 값 Ulimit 옵션(기본값 [])
-v, --volume 값 빌드 시 바인드 마운트 설정(기본값 [])
```

fatherlinux 에 2017년 04월 02일

👍2

CI 구축 노드 프로젝트의 또 다른 사용 사례는 모든 이미지를 구축할 때 CI의 yarn 캐시를 공유하는 것입니다.

Puneeth-n 에 2017년 04월 05일

👍14

+1 : node_modules를 계속해서 설치하는 것은 특히 nodejs 마이크로 서비스의 경우 정말 끔찍합니다.
nfs로 이 문제를 해결하려고 하는데 "반복 가능"이 이 기능을 구현하지 않는 좋은 이유가 아니라고 생각합니다...

GongT 에 2017년 04월 11일

#31257과 #32063이 합쳐지면 더욱 중요해질 것 같습니다.

mkobit 에 2017년 04월 11일

#32507을 살펴보세요.

cpuguy83 에 2017년 04월 11일

👍1

@fatherlinux Dockerfile 내에서 COPY 명령을 사용할 수 있을 때 빌드 이식성이 어떻게 작동하는지 설명해 주시겠습니까? 큰 파일의 복사본 수를 피하고(시간 복잡성 이유로) 파일을 컨테이너와 공유하기 위한 빌드 시 읽기 전용 옵션을 찾고 있는 문제가 있습니다.

arunmk 에 2017년 05월 10일

👍1

@arunmk 참조 https://github.com/moby/moby/issues/32507

cpuguy83 에 2017년 05월 10일

@arunmk @cpuguy83 정확히. 아이디어는 빌드 시 데이터를 컨테이너에 복사하고 싶지 않다는 것입니다. 그것은 그것을 매우 크게 만들 수 있습니다. 우리는 단지 빌드 시간에 데이터를 사용할 수 있기를 원합니다. 위의 내용에 따라 Red Hat 버전의 docker 데몬에서 -v bind 마운트를 수행하여 데이터를 사용할 수 있지만 지금은 읽기 전용입니다(지난 주에 불타버렸습니다).

따라서 오늘 필요한 경우 Fedora, CentOS 또는 RHEL을 확인하고 빌드 시 데이터의 읽기 전용 복사본에 마운트할 수 있습니다...

그리고 빌드 팜 내에서 이식성이 필요한 경우 NFS 또는 이와 유사한 것을 제안합니다....

fatherlinux 에 2017년 05월 10일

복사에 신경 쓰지 않고 최종 이미지에 저장하는 데 신경 쓴다면 다단계 빌드를 사용하여 이를 처리할 수 있습니다.

인위적인 예:

FROM fatImage AS build
COPY bigData /data
RUN some_stoff /data

FROM tinyImage
COPY --from=build /data/result

cpuguy83 에 2017년 05월 10일

👍2

@fatherlinux 설명 감사합니다
@cpuguy83 자세한 정보 감사합니다. 흔하지 않을 수 있는 내 문제에 대한 자세한 내용을 추가하겠습니다. 3.3GB 파일을 생성하는 빌드 시스템이 있습니다. 이는 도커 컨테이너 내에 구축된 RPM에 추가됩니다. 따라서 두 개의 복사본이 생성됩니다. 하나는 빌드 시스템에서 도커 컨테이너로, 다른 하나는 도커 컨테이너에서 RPM 내로입니다. 이제 두 번째 사본을 피할 수 없습니다. 첫 번째 사본을 피하려고 생각했지만 다단계 빌드에서도 가능하지 않은 것 같습니다.
대용량 파일을 반복적으로 사용했다면 다단계 복사가 복사 실행 횟수를 '1'로 줄였다는 것을 이해할 수 있습니다. 한 번 사용하고 숫자를 '0'으로 줄이고 싶었습니다. 불가능할 것이라고 이해하는 것이 맞습니까?

arunmk 에 2017년 05월 11일

👍1

@arunmk 클라이언트에서 빌드 인스턴스로 복사해야 하는 것이 무엇이든 상관없습니다.

cpuguy83 에 2017년 05월 11일

@ cpuguy83 설명 감사합니다. 일단은 오버헤드를 감수해야 할 것 같습니다. 원자성을 갖기 위함인가?

arunmk 에 2017년 05월 11일

@fatherlinux

RHEL7에서 -v를 사용하여 빌드 중에 디렉토리를 읽기 전용으로 마운트하려고 시도했지만 다음 오류가 발생합니다.

볼륨은 도커 빌드에서 지원되지 않습니다. 바인드 마운트만 사용하십시오.

ghost 에 2017년 05월 18일

이것은 Docker가 아닌 RHEL의 docker 패키지에서만 작동합니다. 패치가 업스트림에서 수락되지 않았습니다.

rhatdan 에 2017년 05월 18일

@fatherlinux
RHEL7에서 -v를 사용하여 빌드 중에 디렉토리를 읽기 전용으로 마운트하려고 시도했지만 다음 오류가 발생합니다.
볼륨은 도커 빌드에서 지원되지 않습니다. 바인드 마운트만 사용하십시오.

@fcntl

오류가 말했듯이 바인드를 사용해야합니다. 아마도 $ /hostsomething:/containersomething -v /something 를 사용했을 것입니다.

runcom 에 2017년 05월 18일

@thebigb 및 아마도 다른 사람들, 우리는 도커 빌드 중에 ccache를 사용할 수 있도록 인프라를 설정했습니다. 도움이 된다면 https://github.com/WebHare/ccache-memcached-server 에 게시했습니다. 이 문제를 이상적으로 해결하면 아마도 쓸모가 없을 것입니다.

unilynx 에 2017년 06월 17일

제가 추가하려고 했던 바로 그 사용 사례는 ccache입니다. 도커 이미지 빌드 중에 ccache 캐시를 마운트할 수 있기를 원합니다. 이미지 자체에 있다는 것은 의미가 없습니다. @unilynx 해결 방법을 살펴보겠습니다. 좋은 타이밍입니다!

embray 에 2017년 07월 04일

또 다른 목소리를 냅니다.

내 사용 사례: 현재 나는 rocker 의 MOUNT 명령을 사용하여 /root/.cache 및 /var/cache/apk 디렉토리를 공유합니다.

어떤 이유로 apk 패키지 및 pip 패키지에 대한 네트워크 액세스가 매우(매우, 매우) 느립니다. 모든 재구축은 프로세스를 엄청나게 시간 소모적으로 만듭니다. 이 빌드 타임 MOUNT 기능을 사용하면 작업이 훨씬 쉬워집니다.

roxma 에 2017년 07월 04일

👍2

@embray @roxma 는 https://github.com/moby/moby/issues/32507 을 참조하여 사용 사례를 해결할 수 있습니다. 피드백 환영

thaJeztah 에 2017년 07월 04일

다단계 빌드 의 도입으로 Maven의 로컬 캐시에 대한 볼륨 마운트를 지정해야 할 필요성이 중요하다는 것을 알았습니다.

awhitford 에 2017년 07월 16일

👍11

@gim913 커뮤니티에 참여하는 방식이 아닙니다. 기여하고 싶다면 여기에 링크된 기존 제안을 검토하여 사용 사례를 해결하는 것이 있는지 확인하십시오.

cpuguy83 에 2017년 07월 27일

👍4

@gim913 다양한 배포판에 도커를 통합하는 이 단계에서 환경을 변경하는 것(즉, 도커를 완전히 삭제하는 것)은 'OS'를 변경하는 것보다 훨씬 더 파괴적인 것처럼 보입니다(다른 Linux 배포판에서 다음을 포함하는 RedHat 빌드로 전환하는 것을 의미한다고 가정합니다. -V? )

RedHat의 docker 버전을 사용하는 것이 더 쉽지 않을까요? 아마도 여기 누군가가 빌드에서 '-v' 옵션을 얻기 위해 관련 패치/포크/커밋을 알려줄 수 있습니다.

unilynx 에 2017년 07월 27일

@unilynx 여기 있습니다

Puneeth-n 에 2017년 07월 28일

👍4

wget을 사용하는 몇 가지 예를 보고 있는데 여기까지 왔습니다...내 사용 사례도 비슷합니다...큰 tarball의 압축을 풀고 실행하고 싶습니다. tarball을 사용하여 도커 파일을 어지럽히거나 로컬 웹 서버에서 wget을 수행하는 데 시간을 낭비하고 싶지 않습니다. docker compose를 사용하여 할 수 있는 것처럼 마운트하는 것은 빌드 시간에 하는 것이 합리적인 것처럼 보입니다. 괜찮아 보이면 Puneeth의 변경 사항을 병합하십시오 :-)

kenyee 에 2017년 08월 01일

👍1

나는 파이썬 바퀴를 미리 컴파일하고 그것들을 복사하지 않고 컨테이너에 설치하고 정말로 필요하지 않거나 어떻게든 스쿼시를 시도해야 하는 레이어를 만들고 싶습니다. 1일차에 벌써 rocker 알아보고 있어요 😢 😢 😢

이것은 추가하기 쉽고 매우 유용합니다(또는 마운트 명령, rocker 다시 참조). 이 기능이나 이와 유사한 누락 기능에 대해 (커뮤니티에서) 스크립팅하는 데 얼마나 많은 시간이 소요됩니까?

awbacker 에 2017년 08월 02일

👍2 👎1

@awbacker Multi-stag 빌드는 다음과 같은 작업을 수행할 수 있는 곳에서 이 문제를 꽤 잘 해결합니다.

FROM something AS my_wheels
RUN compile_all_the_things

FROM something
COPY --from my_wheels /wherever
RUN do_stuff_with_wheels

첫 번째 부분은 무언가가 변경된 경우에만 실행됩니다. 이에 대한 캐시는 다른 빌드/도커 파일 간에도 공유할 수 있습니다.
이것은 전체 빌드를 독립적으로 만듭니다.

또한 마운트 사양이 my_wheels 빌드 타겟을 복사하는 대신 마운트하도록 지시하는 RUN --mount 를 허용하는 제안도 있습니다.

@kenyee 와 마찬가지로 이것은 빌드 컨텍스트에서 무언가를 마운트할 수 있으며, 17.07-실험에서는 필요에 따라 증분적으로만 전송됩니다.

cpuguy83 에 2017년 08월 02일

👍1

@ cpuguy83 적어도 Gradle Java 빌드의 경우 실제로는 작동하지 않습니다. Gradle Jar 파일이 미리 캐시된 기본 Docker 이미지가 있지만 소스의 Gradle 빌드는 모든 종속성을 캐시로 다운로드하는 트리거입니다.

BryanHunt 에 2017년 08월 02일

👍1

@cpuguy83 다단계는 결과 이미지에서 복사된 휠을 제거하는 것을 허용하지 않습니다. @awbacker가 말하는 것입니다. 따라서 /wherever 폴더의 콘텐츠가 캐시되고 이미지 크기가 증가합니다.

Bahus 에 2017년 08월 02일

@BryanHunt 빌드 프로세스의 일부가 deps를 다운로드하는 것입니까? 확실히 Gradle은 실제로 빌드하지 않고 캐시하는 방법을 제공해야 합니까?

cpuguy83 에 2017년 08월 02일

@cpuguy83 예, deps는 빌드의 일부로 다운로드됩니다. 기본적으로 Maven과 동일합니다. 참고: https://github.com/gradle/gradle/issues/1049

BryanHunt 에 2017년 08월 02일

빌드 마운트에 대한 PR이 어딘가에 있었습니까?

graingert 에 2017년 08월 02일

@graingert 여기

Puneeth-n 에 2017년 08월 03일

👍이를 위해. Lunar Way에서는 CI 서버에서 빌드 및 테스트 종속성을 제거하기 위해 단일 Docker 빌드에서 완전한 "빌드 -> 테스트 -> 프로덕션 이미지 빌드" 프로세스를 수행하려고 합니다. 다단계 빌드를 사용하여 이를 수행할 수 있지만 빌드 프로세스의 중간 컨테이너에서 테스트 결과를 가져올 수 없습니다. 따라서 테스트 이미지를 빌드하고 실행한 다음 테스트가 성공하는 경우에만 제품 이미지 빌드 단계로 진행하기 위한 별도의 Dockerfile을 사용하여 지금 두 단계로 수행해야 합니다.

도커 빌드의 -v 옵션을 사용하면 CI 서버에서 마운트된 폴더에 테스트 결과를 저장할 수 있고 현재 2단계 프로세스가 필요하지 않습니다.

tbflw 에 2017년 09월 20일

👍3

@tbflw 기본적으로 Docker 빌드는 빌드 실패 후 중간 컨테이너를 제거하지 않습니다. 따라서 테스트가 실패하면 해당 테스트 결과를 얻을 수 있습니다.

ibukanov 에 2017년 09월 20일

👍1

제발 , 우리도 이 기능이 정말 필요합니다! 임시 패치가 있는 로커 또는 포크 도커와 같은 다른 도구에 의존하는 것은 "이동성 구축"이라는 복음주의적 개념을 깨는 것보다 훨씬 추합니다.

nardeas 에 2017년 09월 29일

👍4

@BryanHunt @stepps @yngndrw 다른 사람들도 @awhitford
빌드 종속성을 캐시하는 한 가지 방법 은 문서의 다단계 go 빌드 예제 또는 python onbuild Dockerfile 처럼 빌드가 작동하도록 하는 것입니다.
다음 은 maven에서 작동하는 것으로 보이는 예제입니다. 여기에 복사하겠습니다.

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

FROM openjdk
COPY --from=0 /usr/src/app/target/*.jar ./

나머지 코드베이스를 복사하기 전에 종속성을 다운로드하도록 설정해야 합니다. 또한 아티팩트가 저장 되는 위치가 VOLUME 에 없는지 확인합니다.

sixcorners 에 2017년 10월 05일

👍1

@sixcorners Gradle에서는 작동하지 않습니다.

BryanHunt 에 2017년 10월 05일

@BryanHunt 이 Dockerfile 또는 이 접근 방식은 gradle에서 작동하지 않습니까? cpuguy83이 실제로 빌드를 수행하지 않고 종속성을 다운로드하는 방법이 있는지 묻습니다. 종속성 해결 작업에 연결했습니다. build.gradle 파일을 추가하고 해당 작업을 실행할 수 없습니까?

sixcorners 에 2017년 10월 05일

@sixcorners 모듈이 많으면 빌드 파일 및 속성 파일과 함께 디렉터리 구조를 복제해야 합니다. 나는 그것이 가능하다고 생각하지만 이것은 매우 오류가 발생하기 쉽다고 생각합니다.

BryanHunt 에 2017년 10월 05일

@sixcorners 의 다단계는 흥미로운 트릭이며 다른 패키지 관리자(예: npm, 작곡가)에 사용되는 것을 보았습니다.

하지만 문제가 있습니다. 스테이지 0 이미지에서 종속성 목록이 변경될 때마다 COPY pom.xml 레이어가 제거되어 전체 캐시가 사라집니다. 즉, 개발자가 pom(주석, 1kBytes 종속성)에서 무엇이든 변경할 때마다 전체 캐시를 다시 다운로드해야 합니다.

이미지를 빌드한 다음 계속 변경되는 종속성을 사용하여 테스트를 실행하는 CI 머신의 경우(프록시 또는 업스트림에서) 다시 다운로드해야 하는 수천 개의 패키지로 인해 재구성 속도가 상당히 느려집니다. 볼륨으로 마운트된 로컬 파일 기반 캐시가 훨씬 빠릅니다.

이는 개발자가 이미지 빌드를 반복할 때, 특히 연결 속도가 느린 경우에도 문제입니다. 로컬 Nexus 인스턴스와 http_proxy를 설정할 수 있지만 다른 부작용이 있습니다(예: Nexus를 통한 http 요청 채널링).

다단계는 좋은 해결 방법이지만 이상적이지는 않습니다.

hashar 에 2017년 10월 05일

👍1

우리가 시도하려는 솔루션은 공유 라이브러리를 구축하고 종속성 캐시를 유지하여 이미지를 구축하는 것입니다. 그러면 이 이미지가 앱의 빌드 이미지가 됩니다. 이상적이지는 않지만 시도해 볼 가치가 있다고 생각합니다.

BryanHunt 에 2017년 10월 06일

하지만 문제가 있습니다. 종속성 목록이 변경될 때마다 스테이지 0 이미지의 COPY pom.xml로 인해 레이어가 제거되어 전체 캐시가 사라집니다. 즉, 개발자가 pom(주석, 1kBytes 종속성)에서 무엇이든 변경할 때마다 전체 캐시를 다시 다운로드해야 합니다.

@hashar COPY --from 기능은 빌드 단계에만 국한되지 않습니다. Dockerfile 참조 에서 :

선택적으로 COPY 는 전송된 빌드 컨텍스트 대신 사용할 이전 빌드 단계( FROM .. AS <name> 로 생성)로 소스 위치를 설정하는 데 사용할 수 있는 플래그 --from=<name|index> 를 허용합니다. 사용자에 의해. 플래그는 FROM 명령어로 시작하는 모든 이전 빌드 단계에 할당된 숫자 인덱스도 허용합니다. _ 지정된 이름의 빌드 단계를 찾을 수 없는 경우 동일한 이름의 이미지를 대신 사용하려고 합니다. _

이를 통해 종속성에 대한 이미지를 _빌드_하고, 태그를 지정하고, 이를 사용하여 종속성을 복사할 수 있습니다. 예를 들어:

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

docker build -t dependencies:1.0.0 .

그리고 종속성에 대해 dependencies:1.0.0 이미지를 사용하여 지정합니다.

FROM openjdk
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar ./

또는 (테스트할 아주 기본적인 예일 뿐입니다);

$ mkdir example && cd example
$ touch dep-one.jar dep-two.jar dep-three.jar

$ docker build -t dependencies:1.0.0 . -f -<<'EOF'
FROM scratch
COPY . /usr/src/app/target/
EOF

$ docker build -t myimage -<<'EOF'
FROM busybox
RUN mkdir /foo
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar /foo/
RUN ls -la /foo/
EOF

빌드 출력에서 다음을 볼 수 있습니다.

Step 4/4 : RUN ls -la /foo/
 ---> Running in 012a8dbef91d
total 8
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 .
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 ..
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-one.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-three.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-two.jar
 ---> 71fc7f4b8802

thaJeztah 에 2017년 10월 07일

👍4

이 사용 사례에 대해 언급한 사람이 있는지는 모르겠지만(간단하게 페이지를 검색했습니다) SSH 인증 소켓을 빌드 컨테이너에 탑재하면 비공개 git 리포지토리를 통해 배포된 종속성을 훨씬 쉽게 활용할 수 있습니다. 비 최종 빌드 단계 등에서 키를 복사하는 것과 관련하여 Dockerfile 내부의 상용구에 대한 필요성이 적습니다.

dustinlacewell-wk 에 2017년 10월 10일

👍6

buildkit에는 git에 대한 기본 지원이 있습니다.
https://github.com/moby/buildkit

AkihiroSuda 에 2017년 10월 10일

해결.
bash 스크립트 생성(~/bin/docker-compose 등):

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

그리고 socat을 사용하는 Dockerfile에서:

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

그런 다음 docker-compose build 를 실행합니다.

kinnalru 에 2017년 11월 30일

더미에 다른 사용 사례를 던지기 위해. Windows용 Docker를 사용하여 하나의 컨테이너에 임베디드 Linux 시스템을 빌드하기 위한 파일 시스템을 생성하고 빌드 단계에서 이를 다른 컨테이너와 공유하고 싶습니다. 이 컨테이너와 상호 작용하여 구성을 변경하고 다시 빌드하는 등 Dockerfile에서 빌드를 수행하고 다단계 빌드를 사용하는 것은 증분 빌드를 잃게 되므로 적합하지 않습니다. 클린 빌드를 수행하는 데 약 1.5시간이 걸리므로 이전 빌드 아티팩트를 캐시하고 싶습니다. Windows가 심볼릭 링크를 처리하는 방식으로 인해 호스트 마운트 볼륨으로 빌드를 수행할 수 없으므로 명명된 볼륨을 사용합니다. 이상적으로는 다른 이미지의 빌드 단계에서 이러한 명명된 볼륨을 공유하고 싶습니다. 현재 빌드 출력의 tar(약 4GB)를 만든 다음 도커 복사를 수행하여 후속 빌드를 위해 Windows 호스트에서 사용할 수 있도록 해야 합니다.

nigelgbanks 에 2018년 01월 08일

python의 경우 pip install package 하면 해당 종속 항목이 캐시 폴더에 다운로드된 다음 사이트 패키지에 설치됩니다.
좋은 습관으로 pip --no-cache-dir install package 를 사용하여 현재 레이어에 쓰레기/캐시를 저장하지 않습니다. 그러나 모범 사례를 위해 캐시 폴더를 빌드 컨텍스트에서 제외하는 것이 좋습니다. 따라서 build time -v가 도움이 될 것입니다.
위에서 언급한 일부 사용자가 COPY . /somewhere/in/container/ 를 사용하는 것은 사용자 앱이나 파일에 적합하지만 캐시에는 적합하지 않습니다. COPY는 자체 레이어를 하나 더 생성하고 이후 레이어에서 캐시를 제거하는 것은 유용하지 않기 때문입니다. 다른 나쁜 부작용은 COPY를 사용할 때 캐시가 변경되고 컨텍스트가 변경되고 다음 레이어가 무효화되고 강제로 재구축되는 경우입니다.

wtayyeb 에 2018년 01월 09일

@wtayyeb 요구 사항 파일이 변경될 때만 pip install ... 를 실행하는 Dockerfile이 있는 경우 요구 사항이 빌드할 때 응용 프로그램만큼 자주 변경되지 않기 때문에 build time -v는 그다지 중요하지 않은 것 같습니다.

manishtomar 에 2018년 01월 09일

👎1

@wtayyeb 다단계 Dockerfile을 사용하여 캐시와 린 이미지를 모두 가질 수 있습니다. 즉, 설치 프로그램 이미지를 사용하여 Python을 일부 디렉토리에 설치한 다음 최종 이미지에 COPY --from을 사용하여 설치 아티팩트 또는 pip 자체 없이 필요한 Python 파일만 전송합니다.

ibukanov 에 2018년 01월 09일

👍2

@manishtomar , 감사합니다. 예, 아니요! 깨끗한 경우 모든 종속성이 다시 다운로드되어 휠로 빌드 및 변환되고 캐시된 다음 대상 환경에 설치됩니다. 따라서 요구 사항을 입력하면 일회성 작업입니다. 그러나 하나의 작은 종속성이 업데이트되면 모든 종속성을 다시 다운로드하고, 다시 빌드하고, 휠링하고, 다시 캐시해야 사용할 수 있습니다.
CI를 사용하여 여러 작업의 매트릭스에서 라이브러리와 응용 프로그램을 빌드하고 테스트할 때 CI 서버의 동시 작업 수에 작업을 곱하면 SSD를 사용하는 경우에도 iowait가 3초 이상으로 증가하고 로드 평균이 15를 초과하게 됩니다. (이 숫자는 2개의 동시 빌드 및 ~20개의 종속성이 있는 앱의 경우 실제입니다.) pip 캐시가 올바른 방식으로 수행하고 있으며, 준비된 패키지를 다시 다운로드하고, 다시 빌드하고, 다시 돌리는 것을 피하고 있다고 생각합니다. bind -v가 없으면 시간과 서버 리소스가 느슨해집니다.

@ibukanov , 감사합니다. 내 앱 패키지를 빌드하고 나중에 사용하기 위해 다단계 Dockerfile을 사용하고 있습니다. Dockerfile이 하나만 있고 여러 번 빌드하려는 경우 도움이 될 것입니다. 그러나 Dockerfile이 여러 개 있고 각 파일이 Python 버전(현재는 2.7,3.6)에 대해 빌드되고 필요한 여러 c-확장자가 있는 경우에는 어떻게 될까요? 선택한 기본 이미지에 대해 빌드하시겠습니까? 위 단락은 어떻습니까?

wtayyeb 에 2018년 01월 09일

@thaJeztah 당신의 제안은 훌륭하고 시간을 절약할 수 있지만 빌드 캐시의 경우 다른 이미지에서 아무 것도 복사하고 싶지 않습니다.
복사하지 않고 다른 이미지에 액세스할 수 없는 이유는 무엇입니까?

thedrow 에 2018년 02월 06일

@thedrow 내 예는 현재 존재하는 기능에 대한 것이었습니다. RUN --mount 제안(https://github.com/moby/moby/issues/32507)을 살펴보십시오. 귀하의 사용 사례에 더 적합할 수 있습니다.

thaJeztah 에 2018년 02월 06일

🎉2

위의 스레드를 읽고 많은 사람들이 도커 빌드 프로세스의 기본 기능 격차를 해결하기 위해 클러지를 찾으려고 노력하는 것을 봅니다. 나는 호스트 마운트를 이미지 마운트와 혼동하지 않고 이식성을 기반으로 한 설득력 있는 주장을 볼 수 없습니다.

나는 또한 젠투 컨테이너 사용자이고 https://github.com/moby/moby/issues/3156 에서 리디렉션되었습니다. 이것은 이 누락된 기능에 대한 완전히 유효한 사용 사례입니다.

내가 정말로 원하는 것은 빌드 시간에 다른 이미지의 내용을 마운트하여 이미지가 부풀려지지 않도록 하는 것입니다.

kbaegis 에 2018년 02월 23일

👍2

@kbaegis 는 https://github.com/moby/moby/issues/32507 에서 제안된 기능과 정확히 일치하는 것처럼 들립니다.

thaJeztah 에 2018년 02월 23일

확신하는. 그것은 백로그에서 3년이 아닌 1년 동안 구현되지 않은 P3일 뿐입니다.

https://github.com/projectatomic/buildah 가 실제로 이 기본 기능에 대해 여기에서 도커 빌드를 훨씬 능가할 것 같습니다. 그런 일이 발생하면 파이프라인을 전환할 생각입니다.

kbaegis 에 2018년 02월 24일

👍1

@kbaegis 이 토론에 무엇을 추가하기 위해 여기에 오셨습니까? 다른 제안과 _정확히_ 일치하는 사용 사례를 설명했습니다.

내가 정말로 원하는 것은 빌드 시간에 다른 이미지의 내용을 마운트하여 이미지가 부풀려지지 않도록 하는 것입니다.

그것은 오픈 소스이며 모든 것이 마법처럼 존재하지 않습니다.

thaJeztah 에 2018년 02월 24일

토론에 무엇을 추가하려고 합니까?

간단히 말해서 이 도구 세트에서 계속 진행하겠습니다. 저 혼자가 아니라는 확신이 있기 때문에 개발 팀에 귀중한 정보라고 확신합니다.

이 사용 사례(및 이 기능을 제공하는 신뢰할 수 있는 해결 방법)를 지원하기 위한 빠른 속도와 낮은 우선 순위로 인해 다른 도구를 사용하게 되었고 기능 누락으로 인해 이 빌드 파이프라인을 포기하고 있습니다.

kbaegis 에 2018년 02월 24일

👍3 😕1

추가할 유스 케이스가 있습니다. #32507이 더 잘 어울립니다.

일부 생물 정보학 파이프라인에 대한 도커 이미지를 구축 중입니다. 일부 도구는 컴파일/설치 전에 일부 데이터베이스가 있어야 합니다( 제 코드 가 아니므로 묻지 마십시오). 이 데이터베이스의 무게는 최소 30GB입니다.

런타임 동안에는 해당 데이터베이스가 -v 볼륨으로 마운트될 예정입니다. 불행히도 빌드 프로세스 중에 "베이킹"하지 않고는 이 작업을 수행할 수 없으므로 다소 외설적인 크기의 이미지가 생성됩니다.

draeath 에 2018년 02월 27일

@draeth 는 https://github.com/grammarly/rocker 를 살펴보십시오. 이미 멋진 MOUNT 명령어를 지원합니다.

lig 에 2018년 02월 28일

👍1

@draeth 는 또한 Buildah를 확인하십시오. 프로그래밍 도구처럼 설정되어 있기 때문에 기본적으로 마운트를 지원합니다. Dockerfile을 사용한 마운트도 지원합니다.

https://github.com/projectatomic/buildah

fatherlinux 에 2018년 02월 28일

👍5

@fatherlinux 와 @lig 모두에게 감사드립니다. 이것은 제 작업을 완료하는 데 도움이 될 것입니다. 나는 여전히 그것을 하기 위해 프로젝트 외부에서 벗어날 필요가 없다고 생각하고 여전히 이것을 보고 #32507이 구현되는 것을 보고 싶습니다 ;)

draeath 에 2018년 02월 28일

나는 '도커 실행' 시간이 아닌 '도커 빌드' 시간에 동일한 기능, 볼륨을 요청하기 위해 인터넷 검색을 통해 여기에 왔습니다.

CPU가 포함된 임베디드 시스템이 있습니다. 제조업체는 시스템 이미지를 구성한 다음 이미지를 CPU로 전송하는 도구를 제공합니다. 이 도구는 제 3자이며 변경할 수 없습니다. 제조업체도 내 요청에 따라 변경하지 않을 것입니다.

첫 번째 패스 "펌웨어 이미지 빌드"를 수행하는 도커 이미지를 빌드한 다음 펌웨어 이미지를 최신 오프라인 PCB에 푸시하는 컨테이너를 생성할 수 있기를 원합니다. Dockerfile은 다음과 같을 수 있습니다.
----------[ 여기 자르기 ]----------
FROM 기본 이미지를 빌더로 사용
복사 src src
RUN 빌드-src

FROM 기본 이미지를 플래셔로 사용
복사 --from=빌더 빌드 아티팩트
RUN cpu-build-and-flash --build-only
----------[ 여기 자르기 ]----------
불행히도 cpu-build-and-flash 단계에서는 펌웨어 이미지를 장치로 푸시하지 않더라도 USB 버스를 통해 대상 장치에 액세스해야 합니다. 따라서 'docker run' 명령에서 '-v /dev/usb/bus:/dev/usb/bus'를 가져와서 대신 빌드에 포함해야 합니다.

이것은 현재 불가능하다는 것이 분명합니다.

내가 진행하려는 해결 방법은 컨테이너를 이미지에 '도커 컨테이너 커밋'하여 깜박이는 이미지를 수동으로 만드는 것입니다. 빌드 타임에 USB 버스를 마운트하는 것이 훨씬 낫습니다.

smacdonald-miov 에 2018년 03월 01일

관심 있는 분들을 위한 업데이트: 최근에 buildah로 전체 파이프를 성공적으로 재구축했습니다. 현재 병렬로 실행되는 두 개의 빌드 파이프라인이 있고 oci/buildah 파이프라인이 더 작은 이미지를 생성하고 있습니다(특히 다른 마운트로 마스킹하여 제 경우에는 /usr/portage 제거).

kbaegis 에 2018년 03월 02일

👍2

그리고 마지막으로 이 기능이 있습니다: https://github.com/docker/docker-py/issues/1498

socketpair 에 2018년 04월 28일

🎉2 👎1 👍1

하지만 빌드 캐시를 위한 RW 볼륨을 원합니다.

2018년 4월 28일 토요일 17:29 Коренберг Марк, [email protected] 작성:

그리고 마지막으로 이 기능이 있습니다: docker/docker-py#1498
https://github.com/docker/docker-py/issues/1498
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/14080#issuecomment-385188262 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAZQTJodLCCzyDdPFtNiIUZ_z85YvLWbks5ttJjagaJpZM4FIdOc
.

graingert 에 2018년 04월 28일

👍30

또한 CI 파이프라인의 다단계 빌드 프로세스 중에 단위 테스트 결과 파일을 내보낼 수 있도록 이 기능(쓰기 기능 포함)을 보고 싶습니다. 빌드 이식성의 정신을 유지하기 위해 -v 스위치가 제공되지 않으면 파일은 해당 단계의 테스트 이미지 내에서 내부적으로 간단히 작성됩니다.

이상적인 목표는 한 번 빌드하고 한 번 테스트하며 테스트가 실패하여 빌드를 중지하는 경우(특히 이벤트)에도 호스트 시스템에 결과 파일을 제공하는 것입니다.

mcattle 에 2018년 05월 17일

👍10

예, 부탁합니다. 하루 종일.

shanselman 에 2018년 05월 19일

😕2

완전히 관련이 있는 것은 아니지만 배포 인프라의 일부를 마이그레이션하고 있으며 빌드 후 이미지에서 파일을 복사하는 방법이 필요했습니다. 다음은 트릭을 수행했습니다.

docker build -t x .
ID=$(docker create x)
docker cp $ID:/package.deb .
docker rm $ID

hoffa 에 2018년 05월 21일

다단계 도커 파일이 도입되었을 때 이미 추가되어 있어야 합니다. 결국 CI 빌드 파이프라인의 경우 특히 다단계 도커 파일의 한 단계로 단위 테스트를 실행하기 시작하자마자 모든 사람이 이 문제에 직면하게 될 것입니다. 또한 단위 테스트 보고서를 VSTS에 게시해야 하는 이 문제에 직면해 있습니다. 이미 @hoffa 가 언급한 해결 방법을 적용하고 있습니다. 그러나 결국 그것은 해결 방법이며 일을 복잡하게 만듭니다.

TqrHsn 에 2018년 05월 23일

👍8

빌드 캐시를 위한 빌드 시간 볼륨을 원하거나 필요로 하는 사람들을 위해 다른 문제를 만들어야 합니까?

ajbouh 에 2018년 05월 23일

@ajbouh 예, 아마도 https://github.com/moby/buildkit/issues 에서

AkihiroSuda 에 2018년 05월 24일

https://github.com/moby/moby/issues/32507#issuecomment -391685221 참조

2018년 5월 23일 수요일 19:22 Akihiro Suda [email protected] 이 다음과 같이 썼습니다.

@ajbouh https://github.com/ajbouh 예, 아마도
https://github.com/moby/buildkit/issues
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/14080#issuecomment-391566368 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcnSqNoVc4j34ElECy53gIfPecQFKfks5t1hlkgaJpZM4FIdOc
.

ajbouh 에 2018년 05월 24일

빌드 시 볼륨을 추가할 수는 없지만 호스트를 추가할 수 있으므로 이제 빌드 이미지가 래퍼를 통해 감지하는 yum 미러를 제공하는 --add-host yum-mirror:$MIRROR_IP 와 같은 것으로 모든 도커 이미지를 빌드합니다. 냠. 내 프로젝트가 하루에 여러 번 종속성을 변경하고 오프라인 상태이거나 연결 상태가 좋지 않을 때 편리합니다(프로젝트의 일부에는 많은 dep 업데이트 및 정리가 포함됨).

나는 이 문제를 해결하기 위한 Docker의 저항이 화난다고 생각합니다.

chuckadams 에 2018년 06월 17일

👍7

빌드킷에 대한 실험적 지원이 최근 병합되었으며 RUN --mount=<opts> <command> 옵션이 제공됩니다.

cpuguy83 에 2018년 06월 17일

🎉15

@cpuguy83 참고 링크: https://github.com/moby/buildkit/pull/442

glensc 에 2018년 06월 17일

👍1

@glensc @cpuguy83 이 병합된 기능의 출시를 언제 예상할 수 있습니까?

agolomoodysaada 에 2018년 06월 18일

👍9

+1

ekovacs 에 2018년 06월 22일

👎12

RUN --mount 에는 볼륨 지원이 없으므로 https://github.com/avsm/docker-ssh-agent-forward 와 같은 것은 빌드 시 불가능한 상태로 유지됩니다. 이에 대한 솔루션은 무엇입니까?

bufdev 에 2018년 10월 01일

👍1

@피터 에지 https://github.com/moby/buildkit/pull/655

AkihiroSuda 에 2018년 10월 02일

docker build --secret 는 Docker 18.09에서 마침내 사용할 수 있습니다. https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

이 문제를 종료할 수 있습니까?

AkihiroSuda 에 2018년 11월 11일

👎7 😕5 👍2

--secret 는 캐싱 사용 사례에 사용할 수 없습니다.

jglick 에 2018년 12월 11일

👍1

@AkihiroSuda RUN --mount 일반적으로 이 문제에 대한 솔루션으로 적합할 것 같습니다.

lig 에 2018년 12월 11일

예, RUN --mount=type=cache (캐시 볼륨의 경우) 및 --mount=type=secret 와 docker build --secret (비밀 볼륨의 경우)가 거의 문제를 다룹니다.

AkihiroSuda 에 2018년 12월 11일

@AkihiroSuda 그래서, 원래 문제를 해결하는 작업 예제를 보는 것이 좋을 것입니다.

lig 에 2018년 12월 12일

@AkihiroSuda 기사에서 (https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066) 빌드 중 마운트를 사용하는 두 가지 사용 사례를 보았습니다. Secret 및 SSH

[비밀]

docker build --secret id=mysite.key,src=path/to/mysite.key .
RUN --mount=type=secret,id=mysite.key,required <command-to-run>

[SSH]

RUN --mount=type=ssh git clone [email protected]:myorg/myproject.git myproject

이 기사나 이번 호에서 사용 방법에 대해 설명하지 않은 2개의 다른 사용 사례(내가 기억하는)가 있습니다.

1) [캐시] RUN --mount=type=cache
2) 일반적인 볼륨(예: SSL 인증서를 마운트하거나 빌드 중에 사용해야 하지만 생성된 이미지에 포함되지 않는 대용량 볼륨의 경우 등...)

lucasbasquerotto 에 2018년 12월 12일

👍3

사용 사례가 webpack 를 실행하기 전에 yarn 작업 공간을 마운트하면

Puneeth-n 에 2018년 12월 12일

👍3

이 모든 것을 할 수 있습니다..

RUN --mount=type=cache,from=<some image>,source=<path in from image>,target=<target>

from=<some image> 를 from=<some build stage> 로 바꿀 수도 있습니다.

다음은 인위적인 예입니다.

# syntax=docker/dockerfile:1.0.0-experimental
FROM busybox as hello
RUN  echo hello > /hello.txt

FROM scratch
RUN --mount=type=cache,from=busybox,source=/bin,target=/bin --mount=type=cache,from=hello,source=/hello.txt,target=/tmp/hello.txt echo /tmp/hello.txt

cpuguy83 에 2018년 12월 12일

👍6

다음은 이에 대한 몇 가지 문서입니다. https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md

cpuguy83 에 2018년 12월 12일

👍2

@AkihiroSuda 에 동의합니다. 이것은 모든 경우를 처리해야 하지만... 그렇지 않은 경우 알려주십시오.

cpuguy83 에 2018년 12월 12일

@AkihiroSuda @cpuguy83 : 불행히도 현재 구현(docker 18.09의 buildkit)에는 개인 레지스트리에 문제가 있습니다. 현재로서는 개인 레지스트리를 통해 이미지를 가져와야 하는 경우 이러한 새로운 기능을 사용할 수 없습니다. https://github.com/moby/moby/issues/38303에서 내 테스트를 참조하십시오.

lbndev 에 2018년 12월 17일

나는 이것이 Jenkins 아티팩트에도 사용될 것이라고 생각합니다. 예를 들어 Docker 이미지를 만들고 내부에서 무언가를 컴파일하는 경우 junit pytest 출력과 같은 몇 가지 아티팩트를 얻고 싶습니다.

spstarr 에 2019년 03월 15일

이것은 매우 유용할 것입니다. RUN --mount=type=cache /user/.cache/pip pip install --experimental 를 추가할 필요가 없습니다(많은 패키지 인덱스 대역폭을 절약하기 위해).

buildah bud ( buildah build-using-dockerfile )에는 --volume / -v 옵션이 있습니다.
https://github.com/containers/buildah/blob/master/docs/buildah-bud.md

buildah 는 도커 소켓 없이 루트가 아닌 것으로 빌드를 실행할 수 있습니다.

westurner 에 2019년 04월 17일

네트워크에서 패키지 다운로드가 더 재현 가능하기 때문에?

westurner 에 2019년 04월 17일

"--experimental"을 추가할 필요가 없고 클라이언트에서 "DOCKER_BUILDKIT=1"만 추가하면 됩니다.

예, 컨텍스트가 모두 Dockerfile에 있다는 점에서 네트워크 빌드를 더 재현할 수 있습니다. 빌드가 작동하도록 하기 위해 호스트에서 컨텍스트를 마운트해야 하는 경우 나쁜 경험입니다.

이미지를 빌드에 탑재할 수도 있습니다.

cpuguy83 에 2019년 04월 17일

예, 컨텍스트가 모두 Dockerfile에 있다는 점에서 네트워크 빌드를 더 재현할 수 있습니다.

Dockerfile에 RUN apt-get update 가 있으면 이미지를 빌드하는 데 필요한 모든 단계가 포함됩니다. 그러나 타사에서 추가 컨텍스트를 다운로드하므로 재현할 수 없습니다. 마운트와의 유일한 차이점은 모든 외부 컨텍스트가 실제로 Dockerfile에 정의되어 있다는 것입니다.

빌드가 작동하도록 하기 위해 호스트에서 컨텍스트를 마운트해야 하는 경우 나쁜 경험입니다.

Docker 빌드에 대한 저의 나쁜 경험은 결코 재현할 수 없으며 일부 사용 사례의 속도를 높일 수 있는 호스트에서 캐시를 탑재함으로써 확실히 이점을 얻을 수 있다는 것입니다.

결국 내가 하는 일은 다단계 빌드를 하는 것입니다. 네트워크에서 컨텍스트를 가져오는 하나의 이미지로 원격 컨텍스트의 스냅샷 역할을 합니다. 그런 다음 임의의 버전으로 태그를 지정하면 날짜가 제대로 작동합니다. 예:

RUN apt-get update

docker build -t aptupdate-20190417

그리고 실제 이미지에서:

FROM aptupdate-20190417
FROM somebaseimage

COPY --from=aptupdate-20190417 /var/apt /var/apt

다른 원격 컨텍스트로 반복하면 어느 정도 재현 가능한 것을 갖게 됩니다.

또는 간단히 말해서: 네트워크 액세스에 의존하는 Dockerfile은 아마도 재현할 수 없습니다. 마운트를 사용하면 재현할 수 없지만 일부 사용 사례를 재현 가능하게 만드는 데 도움이 됩니다. 그러나 내 경험상 대부분은 건물 이미지를 계측하기 위해 자체 도구를 작성하지만 Dockerfile에는 실제로 이미지를 빌드하는 데 필요한 모든 단계가 있어야 합니다.

hashar 에 2019년 04월 17일

👍2

내 말은, RUN --mount=type=cache 가 바로 이것입니다.
또는 레지스트리의 다른 이미지에서 마운트하여 가져올 수도 있습니다.

가져오려는 것을 고정하여 apt 명령을 (상대적으로) 재현 가능하게 만들 수 있습니다.
그러나 정말로 모든 비트를 제어하고 싶다면 빌드에서 apt를 사용하는 이유는 무엇입니까? 이것을 빌드 호스트에 저장하는 것은 재현할 수 없으며 호스트에서 호스트로 쉽게 중단됩니다.
레지스트리에 보관하는 것은 네트워크 장애 가능성을 제외하고는 나쁘지 않습니다... 물론 공정한 비판입니다.

-v on buildah 및 redhat's fork는 너무 광범위하기 때문에 여기에서 명시적으로 거부되었습니다... 유용하지 않다는 것은 아니지만 호스트에서 호스트로 쉽게 중단되어 docker build 의 설계에 어긋납니다. .
한편 RH가 추가한 이유(더 정확하게는 작업하기로 결정한 이유)는 RHEL 자격 증명을 빌드 환경에 탑재할 수 있기 위해서였습니다.

cpuguy83 에 2019년 04월 17일

👍1

예, 컨텍스트가 모두 Dockerfile에 있다는 점에서 네트워크 빌드를 더 재현할 수 있습니다. 빌드가 작동하도록 하기 위해 호스트에서 컨텍스트를 마운트해야 하는 경우 나쁜 경험입니다.

나는 격렬하게 동의하지 않는다. 네트워크가 다운되었거나 손상되었을 수 있습니다. 이 경우 로컬 캐시는 인터넷이 다운된 동안 전체 빌드가 실패하는 것을 방지합니다.

docker-compose.yml에서 volumes: 를 한 번 지정할 수 있습니다. 하지만 대신 DOCKER_BUILDKIT=1 $를 수행하고 업스트림에서 관리되는 Dockerfiles에 RUN --mount=type=cache 를 추가해야 합니까? 왜요?

CI 빌드를 사용하면 볼륨 마운트에 캐시될 수 있는 수만에서 수천 개의 패키지(하루에 수십 또는 수백 번)를 불필요하게 다시 다운로드하는 것이 중요합니다. 호스트에서 자체 볼륨으로 권한 있는 컨테이너를 실행하는 기능).

패키지 색인은 많은 경우 기부금으로 아낌없이 지원됩니다. 원격 리소스가 빌드 구성 요소의 더 재생산 가능한 캐시라는 잘못된 믿음에 근거한 일부 잘못된 재생산 개념을 만족시키기 위해 대역폭에 그 돈을 낭비하는 것은 정말 실망스럽습니다.

docker-compose.yml이 작동하도록 --volume 를 추가하십시오.

westurner 에 2019년 04월 18일

내 docker-compose.yml이 작동하도록 --volume을 추가하세요.

"docker-compose"를 제대로 작동시키는 것은 거꾸로입니다.
docker-compose 소비자가 이 프로젝트를 수행하고 그 반대가 아닙니다.

cpuguy83 에 2019년 04월 18일

docker-compose는 도커 소켓과 상호 작용합니다. docker-compose YAML은 컨테이너 옵션을 저장하는 통합된 방법입니다(k8s pod defs(podman이 어느 정도 지원)로 변환할 수 있음). 재현 가능한 방식으로 DOCKER_BUILDKIT=1 를 지정하려면 어떻게 해야 합니까? docker-compose.yml에서 재현 가능한 방식으로 build_volumes: 를 지정할 수 있습니다.

하루에 n번 실행되는 CI 빌드 스크립트에서 docker-compose build (예: ansible 사용) 또는 packer (buildah 및 podman 대신)를 호출하여 이미지를 빌드할 때 몇 가지 목표가 있습니다.

자원을 절약하십시오 / 자원을 낭비하지 마십시오
- OS 및 언어별 패키지를 지속적으로 다시 다운로드하지 마십시오.
- 내 조직의 대역폭 리소스를 패키지 인덱스로 저장합니다.
가용성 보장
- 오프라인에서 작동해야 합니다.
- 필요한 만큼 적은 수의 구성 요소에 의존해야 합니다.
빌드 무결성 보장
- 동일한 매개변수로 동일한 이미지를 재현할 수 있습니다.
- 분산 분리 / 재현 가능한 빌드 제공
- 패키지 인덱스와 같은 원격 리소스는 제어하지 않습니다.
- 우리는 네트워크 경로를 제어하지 않습니다
  - DNSSEC 및 DNS over HTTPS가 올바르게 구현되지 않았을 수 있습니다.
- 우리는 금지되고 상당히 비율이 제한될 수 있습니다
- 서명된 리소스를 확인하려면 서명된 체크섬을 사용해야 합니다.
  - 키로 액세스하고 서명할 수 있는 권한이 어딘가에 위임됨
  - ENVironment 변수는 컨테이너 네임스페이스의 모든 프로세스에서 사용할 수 있습니다.
  - 빌드 시 볼륨 마운트는 빌드 시에만 필요한 키를 공유하는 한 가지 방법입니다(이미지 캐시로 누출되지 않음).
빠른 빌드 유지
- 빈번한 작업을 캐시하고 메모합니다.
- 캐시는 실패 지점, 잠재적 변동성 및 위험 재현성을 추가합니다.
  - HTTP(S!) 프록시 캐시
  - 네트워크를 통한 애플리케이션 계층 캐시
  - 로컬 파일 시스템 캐시
- 외부 종속성이 없는 벙어리, 플러시 가능한 캐시 구현
  - 로컬 파일 시스템 캐시

캐시 볼륨을 플러시해야 하는 경우 캐시 볼륨을 플러시할 수 있습니다.

0. 현상 유지

RUN pip install app && rm -rf /root/.cache

오늘 가능
O(n_builds): 대역폭 사용량
오프라인에서 작동하지 않음: 네트워크에 따라 다름
느린 재구축

가. 사본

COPY . /app/src/app
COPY .cache/pip /app/.cache/pip
RUN pip install /app/src/app \
    && rm -rf /app/.cache/pip

오늘 가능
~O(1) 패키지 인덱스 대역폭
O(n): 모든 빌드에서(* ONBUILD )
- 캐시를 복사합니다.
- 패키지 보관 취소
- 캐시 삭제
오프라인에서 작동
느린 재구축

B. 업스트림에서 모든 Dockerfile을 분기하고 수정하여 `RUN --mount=type=cache` 를 추가하고 환경 변수를 설정합니다.

# Fork by copying to modify every pip install line
RUN --mount=type=cache /app/.cache/pip pip install /app/src/pip

$ DOCKER_BUILDKIT=1 docker build . [...]

오늘 가능
이것은 이미 재현할 수 없는 결과를 초래합니다. 결과에 차이를 나타내는 extra-Dockerfile, extra-docker-compose.yml 매개변수가 있습니다. 명명된 빌드 이미지입니다.
문서: --mount=type=cache 캐시를 플러시하는 방법(?)
~O(1) 패키지 인덱스 대역폭
오프라인에서 작동
빠른 재구축

C. 빌드 시 마운트되는 볼륨 지정

C.1. 빌다

$ buildah bud -v .cache/pip:/app/.cache.pip

오늘 가능
또한 재현 불가능성을 소개합니다.
문서: 캐시를 플러시하는 방법
~O(1) 패키지 인덱스 대역폭
오프라인에서 작동
빠른 재구축

C.2. docker(이 문제가 요구하는 것)

C.2.1 도커 CLI

$ docker build -v .cache/pip:/app/.cache.pip

오늘은 불가능
또한 재현 불가능성을 소개합니다.
문서: 캐시를 플러시하는 방법
~O(1) 패키지 인덱스 대역폭
오프라인으로 작동
빠른 재구축

C.2.2 도커 작성

services:
  app:
    image: imgname:latest
    build: .
    build_volumes:  # "build_volumes" ?
    - ./.cache/pip:/app/.cache/pip

$ docker-compose build

오늘은 불가능
또한 재현 불가능성을 소개합니다.
문서: 캐시를 플러시하는 방법
docker-compose 스키마 개정이 필요합니다.
~O(1) 패키지 인덱스 대역폭
오프라인으로 작동
빠른 재구축

...

복사 || REMOTE_FETCH || 읽다()
- 다음 중 재현성이 가장 높은 것은 무엇입니까?

westurner 에 2019년 04월 18일

👍15 🚀3

:point_up: 알림입니다. 체크섬을 확인하여 다운로드한 파일을 고정할 수 있습니다. pip와 같은 일부 패키지 관리자도 이를 지원합니다.

Yajo 에 2019년 04월 18일

@westurner 자세한 설명 감사합니다.

나는 다음이 귀하의 사례 B와 비슷할 것이라고 생각하지만 캐시를 지울 수 있고 귀하의 사례 C2와 같이 끝날 것입니다(당신이 요구하는 바, 제 생각에).

_docker-compose.yml:_

services:
  my-cache:
    build: ./my-cache
    image: local/my-cache

  my-image:
    build: ./my-image

_my-cache/도커파일:_

FROM python

RUN pip install app

_my-image/도커파일:_

FROM my-repo/my-image

RUN --mount=target=/export,type=bind,from=local/my-cache

RUN pip install /app/src/app

(https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypecache)

다음을 사용하여 캐시 이미지를 빌드할 수 있습니다.

docker-compose build my-cache

RUN --mount=target=/export,type=bind,from=local/my-cache 명령은 이미지에 바인딩되어야 합니다. 캐시를 새로 고치려면 캐시 이미지를 제거하고 다시 작성할 수 있습니다.

RUN --mount... 의 캐시를 계속 사용하는 경우 버전과 함께 .env 파일을 사용할 수 있습니다. image: local/my-cache:$MY_VERSION 및 from=local/my-cache:$MY_VERSION 에 버전을 포함해야 합니다. 빌드 인수로 포함됨).

my-cache 서비스를 기본 서비스와 동일한 파일에 포함하지 않으려면 다른 docker-compose 파일에 포함할 수 있습니다.

여전히 DOCKER_BUILDKIT=1 를 사용해야 하며(B 케이스에서처럼, 그러나 향후 버전에서는 이것이 필요하지 않을 것이라고 생각합니다) 여전히 재현할 수 없습니다(그러나 C2 케이스도 그렇지 않음).

재현할 수 없는 경우 표시되는 패널티는 무엇입니까? 캐시 이미지 local/my-cache 를 도커 허브 (다른 리포지토리 이름 사용) 또는 개인 레지스트리 에 넣고 각 빌드에 대해 버전을 사용 하는 경우(다른 캐시 생성) 동일한 버전은 항상 동일합니다. 캐시, 재현 가능 하지 않을까요? docker-compose 파일에 서비스를 포함하고 빌드 명령을 호출할 필요조차 없습니다. (Docker Hub는 네트워크에서 액세스해야 하지만 다른 이미지에서도 동일하다고 가정하고 한 번 다운로드한 후에는 새 캐시로 새 버전을 생성하지 않는 한 더 이상 필요하지 않아야 합니다.)

면책 조항: 위의 코드를 테스트하지 않았습니다.

lucasbasquerotto 에 2019년 04월 18일

@Yajo pip의 체크섬 지원은 원래 'peep'에서 구현된 다음 pip로 병합되었습니다. pip 요구 사항 파일 항목에 URL 조각으로 알려진 양호한 해시를 추가할 수 있습니다. (올해 PyPA 프로젝트의 보안 개선을 위한 자금이 있습니다. PyPI의 TUF(업데이트 프레임워크, Docker Notary와 동일) 지원은 올해 후반에 계획됩니다.) 도커 이미지에서 pip 및 PyPI(키 및 신뢰 포함)를 올바르게 부트스트랩 올해 말에 주제가 될 것 같습니다.
(편집; 약간 OT하지만 관련) https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/

westurner 에 2019년 04월 18일

@lucasbasquerotto 도와주셔서 감사합니다. 이것은 빌드 시 --volume 를 지정하는 것보다 훨씬 더 복잡합니다. 즉, 다음이 필요한 것 같습니다.

docker build 쉘 환경에서 DOCKER_BUILDKIT=1 지정
RUN --mount=type=cache 및 args를 사용하여 모든 업스트림 Dockerfile RUN 명령 수정
다른 이미지에 대한 읽기/쓰기 액세스 권한이 있습니까? 가변성! 아니면 캐시가 아마도 오래된 버전으로 고정되었다고 말합니까?

호스트에서 파일을 복사할 수 있거나 다른 곳에 저장되지 않은 빌드 시간 매개변수를 지정할 수 있다면 빌드 시간에 볼륨을 마운트하는 것이 얼마나 재현성이 떨어지는지 알 수 없습니다.

복사 || REMOTE_FETCH || 읽다()
다음 중 재현성이 가장 높은 것은 무엇입니까?

westurner 에 2019년 04월 18일

@westurner

도커 빌드 셸 환경에서 DOCKER_BUILDKIT=1 지정

다른 게시물에서 보았듯이 docker-compose 를 사용하고 다음과 같이 컨테이너에서 실행하는 경우:

$ sudo curl -L --fail https://github.com/docker/compose/releases/download/1.24.0/run.sh -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

그런 다음 /usr/local/bin/docker-compose 에서 다운로드한 파일을 편집하여 해당 환경 변수를 사용할 수 있습니다. 변경:

exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" $IMAGE "$@"

에게

DOCKER_BUILDKIT=1
exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" --env DOCKER_BUILDKIT=$DOCKER_BUILDKIT $IMAGE "$@"

이것은 매우 쉬운 변경이며 명령을 실행하는 사람에게 투명합니다.

_(컨테이너로 실행하지 않으면 위의 사항이 적용되지 않음)_

RUN --cache 및 args를 사용하여 모든 업스트림 Dockerfile RUN 명령 수정

내가 노출 한 경우 RUN --mount=type=bind... 이지만 어쨌든 Dockerfile 을 변경해야 하는 것도 나쁜 IMO입니다. -v 옵션은 훨씬 더 좋고 투명 할 것입니다.

다른 이미지에 대한 읽기/쓰기 액세스 권한이 있습니까? 가변성! 아니면 캐시가 아마도 오래된 버전으로 고정되었다고 말합니까?

이미지를 바인딩할 때 아마도 컨테이너(또는 복제된 파일 시스템이 있는 이름이 무엇이든)를 생성할 것이고 빌드하는 동안 수행된 변경 사항은 원본 이미지를 변경해서는 안 됩니다(이해가 되지 않음). 따라서 빌드에서 my-repo/my-cache:my-version 라는 캐시 이미지를 사용하여 빌드하면 다음 빌드에서 정확히 동일합니다(불변성). 최신 캐시를 사용하려면 my-repo/my-cache:my-new-version 와 같이 새 버전으로 새 이미지를 만들어 사용할 수 있습니다.

다음 중 재현성이 가장 높은 것은 무엇입니까?

재생산은 다른 기계에서 실행해도 똑같을 것이라고 생각합니다. 이런 의미에서 이미지를 (안전하고 안정적인) 도커 레지스트리에 푸시하고 해당 이미지를 변경하지 않으면 재현 가능한 것으로 간주합니다(인터넷 연결에 대한 우려가 있는 경우 개인 레지스트리를 사용하여 내부 레지스트리에 액세스 VPN 또는 이와 유사한 것(개인 레지스트리를 직접 사용하지 않음)).

COPY 명령이 컴퓨터 캐시를 복사하는 경우 다른 컴퓨터에서 pip install (또는 apt-get 또는 기타)를 실행하면 다른 시간에 캐시의 내용이 동일할 것인가? 어쩌면 이것이 당신에게 걱정거리가 될 수 있습니다. 아마.

반면에 "소유"하고 있는 신뢰할 수 있는 위치(예: S3 버킷)에 파일이 있는 경우 해당 파일을 컴퓨터에 다운로드하고 COPY 명령을 사용하여 해당 파일을 복사한 다음 다른 곳에서 복제할 수 있습니다. 동일한 결과를 가진 머신(파일이 변경되지 않고 다른 머신이 이전 머신과 동일하다고 가정). 그래서 나는 이것을 재현 가능한 것으로 간주할 것입니다. 파일이 오는 위치 와 파일을 얼마나 제어할 수 있는지에 따라 다릅니다.

솔직히 말해서, 나는 모든 경우에 100% 재현할 수 있다고 생각하지 않지만(결국 하드웨어는 실패할 수 있음), 더 안정적일수록 더 좋습니다. 어떤 프로세스를 재현할 수 있다고 말할 때는 주로 그 내용과 결과가 같다는 말을 하고 있으며, 여기에는 시간이 지나도 내용이 변하지 않는다는 가정 하에 네트워크에서 다운로드한 내용도 포함됩니다(네트워크 가능성은 고려하지 않음). 이 경우 실패).

lucasbasquerotto 에 2019년 04월 18일

👍1

컨테이너 내부에서도 go mod download 를 신뢰할 수 없게 만드는 일종의 Docker 네트워킹 버그가 있습니다(적어도 우리 크기의 애플리케이션에서는). 그래서 매번 내 GOPATH/pkg/mod 를 다시 다운로드하기 위해 실행하는 것은 낭비일 뿐만 아니라 부서졌습니다. 🤷‍♀

--volume 를 사용할 수 있다면 불필요한 파일 복사를 완전히 피할 수 있습니다!

kevincantu 에 2019년 08월 08일

@kevincantu RUN --mount=type=cache가 유스케이스를 커버해야 합니다.

AkihiroSuda 에 2019년 08월 08일

이를 위해서는 도커 빌드 내에서 모듈을 한 번 이상 성공적으로 다운로드해야 하며, 이 특별한 경우에는 아직 본 적이 없습니다.

kevincantu 에 2019년 08월 08일

https://github.com/moby/moby/issues/14080#issuecomment -484314314 by @westurner 는 꽤 좋은 개요이지만 buildkit 를 작동시키지 못했습니다.

$ sudo docker -v
Docker version 19.03.1, build 74b1e89

$ sudo DOCKER_BUILDKIT=1 docker build .
Ä+Ü Building 0.1s (2/2) FINISHED                                                                                                                
 => ÄinternalÜ load build definition from Dockerfile                                                                                       0.0s
 => => transferring dockerfile: 407B                                                                                                       0.0s
 => ÄinternalÜ load .dockerignore                                                                                                          0.0s
 => => transferring context: 2B                                                                                                            0.0s
failed to create LLB definition: Dockerfile parse error line 8: Unknown flag: mount

내 Dockerfile 는 # syntax=docker/dockerfile:experimental 로 시작합니다.

실제로 docker-compose 를 통해 사용하고 싶습니다. $# Dockerfile #$에서 ENV DOCKER_BUILDKIT 1 를 시도하고 $ ARG DOCKER_BUILDKIT docker-compose.yml 에서 전달했지만 모두 동일합니다.

$ sudo docker-compose up --build
Building web
ERROR: Dockerfile parse error line 10: Unknown flag: mount

@lucasbasquerotto https://github.com/moby/moby/issues/14080#issuecomment -484639378에서 제안한 것이 설치된 버전의 docker-compose로 어떻게 변환됩니까?

마지막으로, 이것이 제 사용 사례에 적용되는지 확실하지 않습니다. 아마도 여러분 중 일부는 제가 이것을 추구해야 하는지 여부를 알려줄 것입니다. 종속성을 업데이트할 때 새 항목만 다운로드해야 하도록 빌드 간에 유지되는 로컬 개발용 빌드 시간 캐시를 사용하고 싶습니다. 따라서 Dockerfile 에 RUN --mount=type=cache,target=/deps 를 추가하고 종속성 관리자의 캐시를 /deps 로 설정합니다.

thisismydesign 에 2019년 08월 30일

docker compose의 경우 https://github.com/docker/compose/pull/6865 를 참조하세요. 이는 곧 출시될 compose 릴리스 후보가 될 것입니다.

thaJeztah 에 2019년 08월 30일

👍3

다른 사용 사례가 있습니다... binfmt가 구성된 x86_64 호스트에서 arm용 컨테이너를 구축하고 싶습니다. 이를 위해서는 /usr/bin 에 아키텍처별 정적 qemu cpu 에뮬레이터가 있어야 합니다.

내 현재 솔루션은 qemu-arm-static 을 다음과 같은 파일로 컨테이너에 추가하는 것입니다.

FROM arm32v7/alpine:3.10
COPY qemu-arm-static /usr/bin/qemu-arm-static
RUN apk update && apk upgrade
RUN apk add alpine-sdk cmake
...

더 쉬운 솔루션은 다음과 같이 컨테이너 내부에 필요한 경우에만 내 파일을 마운트하는 것입니다.
docker build -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static -t test:arm32v7 .
이것은 도커 실행에 매우 효과적이지만 컨테이너를 빌드하기 위한 이 기능이 그리워요.

x86_64 호스트에서 arm 컨테이너를 빌드하는 방법이 또 다른 솔루션이 있습니까? 아니면 최소한 이 경우 빌드 시 볼륨을 허용할 수 있습니까?

jneuhauser 에 2019년 10월 16일

@jneuhauser 최신 커널을 사용하면 이러한 바이너리를 정적으로 로드할 수 있으므로 매번 구성할 필요가 없습니다. 예를 들어 부팅 후 권한 모드에서 linuxkit/binfmt 이미지를 실행하여 이를 달성할 수 있습니다.

alehaa 에 2019년 10월 16일

최신 커널을 사용하면 이러한 바이너리를 정적으로 로드할 수 있으므로 매번 구성할 필요가 없습니다.

@alehaa 그래도 컨테이너 내에 정적 qemu 에뮬레이터 바이너리가 필요하지 않습니까?

cybe 에 2019년 10월 20일

@cybe F -flag가 사용되면 더 이상 필요하지 않습니다( linuxkit/binfmt 패키지가 수행하는 작업). 이에 대한 자세한 정보는 여기에서 찾을 수 있습니다.

alehaa 에 2019년 10월 20일

👍1

누군가 빌드킷을 시험해 볼 수 있는 작동 설정을 제공할 수 있습니까? 우분투에서 작동하지 않습니다. 내 설정은 다음과 같습니다.

cat /etc/docker/daemon.json

{
  "experimental": true
}

Dockerfile

# syntax=docker/dockerfile:experimental

FROM ruby:2.6.3

RUN --mount=type=cache,target=/bundle/vendor

sudo docker -v

Docker 버전 19.03.1, 빌드 74b1e89

DOCKER_BUILDKIT=1 sudo docker build .

데몬의 오류 응답: Dockerfile 구문 분석 오류 라인 12: 알 수 없는 플래그: 마운트

thisismydesign 에 2019년 10월 29일

sudo 는 sudo -E 로 지시하거나 sudo 내에서 변수를 선언하지 않는 한 env vars를 포함하지 않습니다.

cpuguy83 에 2019년 10월 29일

❤2

~~이 기능에 대해 몇 마디 썼고 캐시하는 방법을 보여주는 몇 가지 최소한의 예를 만들었습니다.~~

편집: 아래 참조

@cpuguy83 감사합니다!

thisismydesign 에 2019년 10월 29일

@thisismydesign 당신의 흥분을 망쳐서 죄송하지만 --cache node_modules 할 수 없습니다. 최종 이미지에 표시되지 않으므로 앱이 손상됩니다.

glensc 에 2019년 10월 29일

@glensc 젠장, 당신 말이 맞아.. 빌드 타임 캐시를 최종 이미지의 일부로 만드는 방법이 있나요?

솔직히, 나는 이것이 다음과 같이 광고되는 기능에 대해 고려될 것이라고 생각했습니다.

빌드 컨테이너가 컴파일러 및 패키지 관리자용 디렉터리를 캐시할 수 있습니다.

thisismydesign 에 2019년 10월 30일

대신 ~/.npm을 매핑할 수 있어야 합니다. https://docs.npmjs.com/files/folders.html#cache

@thisismydesign

clintmod 에 2019년 10월 30일

👍1

하지만 다른 이미지를 캐시로 사용할 수 있습니다. Dockerfile에 빌드하거나 어딘가에 레지스트리에 저장된 리터럴 이미지를 만들고 COPY --from 를 사용하면 됩니다.

FROM example/my_node_modules:latest AS node_modules

FROM nodejs AS build
COPY --from=/node_modules node_modules 
...

이것은 다양한 용도로 사용할 수 있는 예시일 뿐입니다.

cpuguy83 에 2019년 10월 30일

Ugh 나는 이것을 가지고 여기에 관여하는 것을 싫어합니다 (또한 안녕 친구)

하지만 이에 대한 사용 사례가 있습니다.

참여할 수 있는 좋은 곳이 있습니까? 여기에서 요약을 얻기 위해 참여할 수 있는 전화나 목록이 있습니까?

또한 우리가 이것에 약간의 자원을 투입할 누군가가 필요하다면 나는 1명의 크리스 노바와 소규모 팀이 있어 아마도 이것을 보도록 설득할 수 있을 것입니다.

TLDR 코딩해도 될까요? 이 문제에 대해 이야기할 수 있는 사람이 있습니까?

kris-nova 에 2020년 06월 12일

_TLDR_ 코딩해도 될까요? 이 문제에 대해 이야기할 수 있는 사람이 있습니까?

나는 Docker에 대해 말할 수 없지만 내 인상은 그들이 빌드에 볼륨 마운팅을 추가하는 데 열려 있지 않다는 것입니다(그리고 아마도 이 문제를 닫아야 할 것입니다)

buildtime -v의 많은 사용 사례가 이제 buildkit에서 다룹니다. 그것은 적어도 나를 위해 그것을 해결했습니다.

unilynx 에 2020년 06월 12일

👍1

그런 다음 빌드킷을 확인하겠습니다. 관심 있는 사람이 있으면 작업을 완료하는 hacky bash도 있습니다.

@unilynx 감사합니다

kris-nova 에 2020년 06월 12일

이 문제를 종료할 때 @unilynx 에 +1, buildkit이 저를 위해 빌드 시간 볼륨 문제도 해결했습니다.

frezbo 에 2020년 06월 12일

누군가가 링크 몇 개와 예제를 드롭하면 친구들이 빛나는 닫기 버튼을 누르도록 설득할 수 있을 것입니다.

(나도 그들로부터 혜택을 받을 것이다)

kris-nova 에 2020년 06월 12일

캐싱의 사용 사례는 빌드킷이 있는 빌드 시간 볼륨이 최종 이미지에 존재하지 않기 때문에 나와 다른 많은 사람들을 위해 해결되지 않았습니다.

thisismydesign 에 2020년 06월 12일

따라서 build 시간에 사용된 임시 볼륨에서 모든 빌드 아티팩트를 끌어올 수 있었고 위에서 언급한 이 bash를 사용하여 이전 캐시로 이미지를 다시 재구성할 수 있었습니다.

오버레이 파일 시스템이 작은 델타만 가져오도록 이미지 자체를 다시 빌드할 수 있었습니다.

빌드 시 다른 이미지의 볼륨을 재사용할 수도 있었습니다.

다른 사람들은 이것을 할 수 없습니까?

kris-nova 에 2020년 06월 12일

(캐시) 마운트는 "실험적" 프런트 엔드에 있습니다. https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md 에 설명되어 있습니다(회의에 참석하려고 하지만 더 확장된 예제를 연결할 수 있음).

thaJeztah 에 2020년 06월 12일

👍3 😕1

@thaJeztah LMK 감사합니다. 여기에서 어떤 식으로든 도울 수 있다면 :)

kris-nova 에 2020년 06월 12일

https://github.com/moby/moby/issues/14080#issuecomment -547662701

@thisismydesign 당신의 흥분을 망쳐서 죄송하지만 --cache node_modules 할 수 없습니다. 최종 이미지에 표시되지 않으므로 앱이 손상됩니다.

@thaJeztah 위의 문제가 해결되었다고 생각하지 않습니다. 결과 이미지가 캐시된 설치를 사용할 수 있도록 하는 빌드 시간 동안 예를 들어 npm install 를 캐시할 수 있는 몇 가지 예를 살펴보고 싶습니다.

@kris-nova 이 문제를 해결하지 못했지만 다시 bash 스크립트를 사용하려고 하지 않습니다. 아마도 우리는 새로운 문제가 필요하지만 이것은 AFAIK가 아직 해결되지 않은 꽤 일반적인 사용 사례입니다.

thisismydesign 에 2020년 06월 12일

@thaJeztah 다음은 최종 이미지에 마운트가 포함되지 않고 빌드 타임 캐싱의 많은 사용 사례를 다루지 않는 방법을 보여주는 캐시 마운트를 사용하는 몇 가지 예입니다.

thisismydesign 에 2020년 06월 12일

npm의 경우: npm 캐시 디렉토리에 대한 캐시 마운트를 사용하지 않습니까(https://docs.npmjs.com/cli-commands/cache.html, 일반적으로 ~/.npm 참조)?

ankon 에 2020년 06월 12일

@ankon 작동할 수 있습니다. 감사합니다. 시도해 보겠습니다. 확실하지 않은 또 다른 사용 사례는 Bundler와 Ruby입니다.

thisismydesign 에 2020년 06월 12일

따라서 Bundler의 경우 $BUNDLE_PATH 에서 빌드 볼륨을 사용한 다음 빌드 중에 네트워크 종속성을 제거할 수 있다고 생각합니다(아직 테스트하지 않음).

bundle install
bundle package
bundle install --standalone --local

이것은 기본적으로 캐시된 번들 설치 디렉토리가 있음을 의미합니다. 거기에서 gem을 ./vendor/cache 에 패키징하고 ./bundle 에 다시 설치합니다. 그러나 이것은 gem을 설치하고 빌드하는 데 시간을 아끼지 않으며 실제로 빌드 단계를 더 길게 만들 수 있습니다.

thisismydesign 에 2020년 06월 12일

👍1

캐시된 데이터를 이미지에 저장하려면 캐시에서 이미지로 복사합니다.

cpuguy83 에 2020년 06월 12일

😄1

감사합니다. 그러나 여전히 해결 방법이 더 많습니다.

추가 복사를 해야 합니다
빌드 환경과 실행 환경 사이에 다른 디렉토리가 있어야 한다고 가정합니다(빌드 중에 볼륨을 마운트한 디렉토리는 사용할 수 없겠죠?) 그래서 추가 설정이 필요합니다

동일한 볼륨을 최종 이미지에 탑재하기 위한 기본 옵션을 갖는 것이 얼마나 많은 노력을 들일지 모르지만 사용을 더 쉽게 만들 것이라고 확신합니다. 이것들은 이 캐시를 사용하는 방법이 명확하지 않은 스크립트 언어의 2가지 예일 뿐입니다. 나는 이것이 다른 맥락에서도 나타날 것이라고 가장 확실히 상상할 수 있습니다.

thisismydesign 에 2020년 06월 12일

@thisismydesign 당신이 원하는 것은 빌드와 실행 사이에 캐시를 공유할 수 있는 것 같습니까?

cpuguy83 에 2020년 06월 12일

buildkit은 Linux 전용 솔루션입니다. Windows에서 무엇을 하나요?

isanych 에 2020년 06월 12일

@thisismydesign 왜 (캐시) 마운트가 최종 이미지에 남을 것으로 예상하는지 잘 모르겠습니다. 나는 이것을 기대하지 않을 것이고 다운로드 캐시 마운트를 사용하기 때문에 내 이미지에 ~1GB를 갖고 싶지 않습니다.

Bessonov 에 2020년 06월 12일

😕1

buildkit은 Linux 전용 솔루션입니다. Windows에서 무엇을 하나요?

Windows에서 빌드킷을 사용할 수 있습니다.

https://docs.docker.com/develop/develop-images/build_enhancements/

실행하기 전에 환경 변수를 설정하는 것보다 Windows UI용 Docker를 통해 데몬 설정을 지정하는 것이 더 쉬울 수 있습니다.

nigelgbanks 에 2020년 06월 13일

링크 상단의 @nigelgbanks :

Only supported for building Linux containers

isanych 에 2020년 06월 13일

아 죄송합니다. Windows에서 Linux 컨테이너를 구축하고 있다고 가정하겠습니다.

nigelgbanks 에 2020년 06월 13일

@thisismydesign 당신이 원하는 것은 빌드와 실행 사이에 캐시를 공유할 수 있는 것 같습니까?

그러면 캐싱과 관련된 사용 사례가 해결됩니다.

thisismydesign 에 2020년 06월 13일

이를 쉽게 하면 CI에서 수백만 건의 패키지 재다운로드를 줄일 수 있습니다.
연간 빌드.

실험적 빌드킷 기능을 지원하는 CI 서비스가 있습니까?

2020년 6월 13일 토요일 오후 2:08 Csaba Apagyi [email protected] 작성:

@thisismydesign https://github.com/thisismydesign
빌드와 실행 간에 캐시를 공유할 수 있기를 원하십니까?
그러면 캐싱과 관련된 사용 사례가 해결됩니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/14080#issuecomment-643657987 또는
구독 취소
https://github.com/notifications/unsubscribe-auth/AAAMNS6IEQDCO5F3LNHJK5TRWO6AJANCNFSM4BJB2OOA
.

westurner 에 2020년 06월 13일

실험적 빌드킷 기능을 지원하는 CI 서비스가 있습니까?

명시적으로 지원해야 합니까? 저는 buildkit과 함께 gitlab-ci를 사용하고 있으며 제대로 작동합니다. 결국 '도커 빌드'를 호출하는 다른 방법일 뿐입니다.

물론 자신의 러너를 gitlab에 가져오지 않는 한 빌드 중에 캐시 적중을 받을 확률은 어쨌든 낮습니다.

unilynx 에 2020년 06월 14일

다단계 빌드의 명명된 단계에서 복사하는 것이 또 다른 솔루션입니다.
FROM golang:1.7.3 AS builder
COPY --from=builder
그러나 컨테이너 이미지 지역성은 여전히 CI 작업 일정에 대해 대부분 해결되지 않은 문제입니다.

실행자는 (지속적으로 자금이 부족한) 패키지 저장소에 대한 불필요한 요청을 최소화하기 위해 더 끈끈하고 공통 파일 시스템에서 (중간) 이미지를 공유해야 합니다.

westurner 에 2020년 06월 14일

방금 buildkit 를 시도했지만 "실제" 볼륨이나 호스트에 마운트를 바인딩하면 100% 도움이 되는 워크플로가 약간만 향상됩니다.

docker build 를 사용하여 이전 glibc 버전을 교차 컴파일한 다음 이 glibc 아래에 빌드하고 링크할 새 빌드 컨테이너의 일부가 되어야 합니다.

이제 반복된 glibc 소스 다운로드가 바인드 마운트( buildkit 에서)로 해결되었으며 아카이브는 문제 없이 읽기 전용으로 가능합니다. 그러나 컨테이너가 오류로 인해 폭파되기 때문에 실패한 빌드 후 분석을 위해 빌드 디렉토리에 액세스할 방법이 없습니다. (액세스하기 위해 다시 시작하면 빌드가 다시 시작되므로 도움이 되지 않습니다.)

또한 빌드 디렉토리를 제거하기 위해 이전 컨테이너에서 새 컨테이너를 빌드하는 것과 같이 왜 후프를 뛰어넘어야 하는지 알지 못합니다. 빌드 디렉토리가 처음에 마운트였더라면 너무 쉽게. (빌드 후 make install 하면 빌드 디렉토리와 다운로드한 소스가 없는 깨끗한 컨테이너가 있습니다.)

그래서 저는 이것이 매우 유효한 기능 요청이며 우리의 삶을 훨씬 더 쉽게 만들어 줄 것이라고 믿습니다. 어떤 기능이 남용될 수 있고 사용하는 경우 다른 기능이 중단될 수 있다고 해서 모든 비용을 들여 구현하는 것을 피해야 한다는 의미는 아닙니다. 더 강력한 도구를 위한 추가 용도로 생각하십시오.

ppenguin 에 2020년 06월 22일

👍4

하지만 빌드 실패 후 분석을 위해 빌드 디렉토리에 액세스할 방법이 없습니다.

빌드킷에 대한 기능 요청처럼 들립니다. 이것은 확실히 알려진 누락된 부분입니다.

"빌드 디렉토리"를 가져오기 위한 대상이 있으면 오늘 이 작업을 수행할 수 있습니다. 실행이 실패한 후 실행하면 모든 것이 여전히 캐시되어야 하며 데이터를 가져오기 위한 마지막 단계만 필요합니다.
이것은 약간의 해결 방법이라는 것을 이해하십시오.

또한 빌드 디렉토리를 제거하기 위해 이전 컨테이너에서 새 컨테이너를 빌드하는 것과 같이 농구를 뛰어넘어야 하는 이유를 알지 못합니다.

여기에서 원하는/기대하는 것을 더 설명할 수 있습니까?

cpuguy83 에 2020년 06월 22일

여기에서 원하는/기대하는 것을 더 설명할 수 있습니까?

이 경우에는 1개의 돌로 2마리의 새를 죽이고자 합니다.

호스트에서 중간 결과에 쉽게 액세스할 수 있는 방법이 있습니다(여기서는 "빌드 디렉토리 분석").
이 저장 공간이 새로 구축된 이미지를 오염시키지 않는지 확인하십시오.

이것과 빌드 컨테이너("컨테이너 빌드" 포함)가 빌드 를 가능한 한 고통 없이 만들어야 하는 다른 모든 경우는 -v 기능을 제공함으로써 훨씬 더 우아하게 해결될 것입니다. 이 기능을 제공하기 위해 저항을 이해하는 데 어려움을 겪습니다. buildkit 가 분명히 제공하는 "캐시 인식" 기능을 제외하고는 이 기능을 부분적으로만 달성하기 위한 복잡하고 성가신 방법으로만 볼 수 있습니다. (그리고 캐싱이 주요 목표인 많은 경우에 -v 에 의해 해결될 것입니다. 마운트된 볼륨이 실행되는 한 특정 컨테이너에 고정되어야 하지만 캐시는 buildkit 에는 동일한 제한 사항이 적용됩니다.)

ppenguin 에 2020년 06월 22일

👍4

여기에서 원하는/기대하는 것을 더 설명할 수 있습니까?

빌드 환경 자체가 컨테이너화되고 최종 결과는 애플리케이션과 런타임 환경(빌드 도구 없이)만 포함하는 이미지가 되는 다단계 빌드 프로세스를 사용하고 있습니다.

내가 원하는 것은 중간 Docker 빌드 컨테이너가 빌드 출력 이미지에 전달할 필요 없이 성공적인 빌드와 실패한 빌드 모두의 이벤트에서 호스트 시스템에 단위 테스트 및 코드 검사 결과 파일을 출력하는 방법입니다. 추출을 위해 (단위 테스트가 이전 단계에서 통과하지 못하면 전체 빌드 프로세스가 단락되므로 해당 상황에서 출력 이미지가 없을 것이므로 단위 테스트 결과가 가장 필요한 때) . 호스트 볼륨을 Docker 빌드 프로세스에 탑재할 수 있으면 내부 테스트 명령이 출력을 탑재된 폴더로 보낼 수 있다고 생각합니다.

mcattle 에 2020년 06월 27일

👍2

@mcattle
내가 필요로 하는 기능 중 하나와 실제로 매우 유사합니다.
며칠 전에 buildah 로 이사한 이후로 필요한 모든 기능과 그 이상을 얻었습니다. 내 빌드 컨테이너를 디버깅하는 것은 종료된 컨테이너와 호스트에 대한 링크를 유연하게 입력할 수 있는 가능성이 없었다면 완전히 불가능했을 것입니다. 이제 나는 행복한 캠핑카입니다. (파티를 "경쟁자"와 충돌시켜 유감입니다. 불쾌감을 느끼면 이 댓글을 삭제하겠습니다. 하지만 이 스레드에 제시된 사용 사례에 대한 효과적인 솔루션이어서 언급해야 한다고 생각했습니다.) .

ppenguin 에 2020년 06월 27일

👍4

다른 도구가 귀하의 필요에 더 잘 맞는다고 말하는 것은 기분이 좋지 않습니다.

당신에게 효과가 있는 것이 있다면 그것은 훌륭합니다.

Docker의 v1 빌더와 빌드킷 빌더 모두의 단점은 이 맥락에서 꽤 잘 이해되고 있으며, 클라이언트에서 마운트를 바인딩하지 않고도 이러한 단점을 해결하는 방법을 찾고 있습니다.
GitHub 알림 @github.com은 다음과 같이 썼습니다.
"@mcattle
내가 필요로 하는 기능 중 하나와 실제로 매우 유사합니다.
며칠 전 buildah로 이사한 이후로 필요한 모든 기능과 그 이상을 얻었습니다. 내 빌드 컨테이너를 디버깅하는 것은 종료된 컨테이너와 호스트에 대한 링크를 유연하게 입력할 수 있는 가능성이 없었다면 완전히 불가능했을 것입니다. 이제 나는 행복한 캠핑카입니다. (파티를 "경쟁자"와 충돌시켜 유감입니다. 불쾌감을 느끼면 이 댓글을 삭제하겠습니다. 하지만 이 스레드에 제시된 사용 사례에 대한 효과적인 솔루션이어서 언급해야 한다고 생각했습니다.) .”

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 구독을 취소하세요.

cpuguy83 에 2020년 06월 27일

👍2

클라이언트에서 마운트를 바인드할 필요 없이

여기에서는 빌드 시간 -v 옵션이 빌드 시간에 네트워크 리소스에 의존하는 것 이상으로 재현성 에 의존 하거나 희생하지 않는 이유를 설명합니다.

https://github.com/moby/moby/issues/14080#issuecomment -484314314 :

복사 || REMOTE_FETCH || 읽다()
다음 중 재현성이 가장 높은 것은 무엇입니까?

빌드 시간 -v (및 cgroupsv2)에도 buildah를 사용합니다.

westurner 에 2020년 06월 27일

👍3

@mcattle 나는 같은 요구 사항을 가지고 있습니다. 라벨링으로 해결했습니다.

xellsys 에 2020년 06월 28일

👍1

빌드 시간 -v (및 cgroupsv2)에도 buildah를 사용합니다.

"-v" 지원 때문에 빌드 서버에서 Ubuntu(도커만 있음)에서 Fedora(docker를 podman/buildah로 대체)로 전환하는 것을 진지하게 고려하고 있습니다.

ㅋ Podman은 루트 없는 모드도 지원하며 지금까지는 Docker와 완전히 호환되는 것으로 보입니다(Docker 데몬처럼 루트로 실행하는 대신 루트 없는 모드를 사용하여 발생하는 --user/USER 영향 및 이미지 캐싱의 차이점 제외).

추신. 루트 없는 작업에는 cgroups v2가 필요하지만, 이에 대한 지원은 도커보다 컨테이너 런타임에 관한 것입니다. RunC 대신 CRun을 사용하는 경우(Fedora처럼) cgroup v2를 지원하게 됩니다. RunC는 Git에서 일부 v2 및 rootless 지원을 제공하지만 몇 달 전에 Fedora(31)에서 테스트할 때 몇 가지 문제가 있었습니다.

편집: Ubuntu에는 최신 20.04 LTS가 아니라 Groovy에 podman/buildah/etc가 있습니다. Debian에서 불안정하게 가져온 것 같습니다. 적어도 아직까지는 LTS로 백포트되지 않았습니다. 2018년부터 Fedora에 있었던 반면, 제 생각에는 그렇습니다.

eero-t 에 2020년 08월 27일

@eero-t 아마도 당신은 당신의 사용 사례를 설명할 수 있고 BuildKit이 현재 제공하는 옵션에서 누락된 것은 이에 대해 해결되지 않았습니다.

thaJeztah 에 2020년 08월 27일

Moby: 빌드 시간 전용 -v 옵션

컨테이너 런타임 배포 가능한 아티팩트에서 선언적 빌드 프로세스(코드로서의 인프라)를 분리하고 싶습니다. 나에게 필요하지 않은 1.5GB의 자중을 처리하고 싶지 않습니다.

가장 유용한 댓글

모든 258 댓글

문제

가능한 해결책

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

내 사용 사례

정황

옵션

0. 현상 유지

가. 사본

B. 업스트림에서 모든 Dockerfile을 분기하고 수정하여 `RUN --mount=type=cache` 를 추가하고 환경 변수를 설정합니다.

C. 빌드 시 마운트되는 볼륨 지정

C.1. 빌다

C.2. docker(이 문제가 요구하는 것)

C.2.1 도커 CLI

C.2.2 도커 작성

...

관련 문제

Moby: 빌드 시간 전용 -v 옵션

컨테이너 런타임 배포 가능한 아티팩트에서 선언적 빌드 프로세스(코드로서의 인프라)를 분리하고 싶습니다. 나에게 필요하지 않은 1.5GB의 자중을 처리하고 싶지 않습니다.

가장 유용한 댓글

모든 258 댓글

문제

가능한 해결책

스콧 매카티스콧. [email protected]http://crunchtools.com@fatherlinux

스콧 매카티스콧. [email protected]http://crunchtools.com@fatherlinux

스콧 매카티스콧. [email protected]http://crunchtools.com@fatherlinux

스콧 매카티스콧. [email protected]http://crunchtools.com@fatherlinux

내 사용 사례

정황

옵션

0. 현상 유지

가. 사본

B. 업스트림에서 모든 Dockerfile을 분기하고 수정하여 RUN --mount=type=cache 를 추가하고 환경 변수를 설정합니다.

C. 빌드 시 마운트되는 볼륨 지정

C.1. 빌다

C.2. docker(이 문제가 요구하는 것)

C.2.1 도커 CLI

C.2.2 도커 작성

...

관련 문제

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

스콧 매카티
스콧. [email protected]
http://crunchtools.com
@fatherlinux

B. 업스트림에서 모든 Dockerfile을 분기하고 수정하여 `RUN --mount=type=cache` 를 추가하고 환경 변수를 설정합니다.