Moby: 새로운 기능 요청: Dockerfile에서 특정 RUN 명령에 대한 캐싱을 선택적으로 비활성화

이 문제를 해결하는 방법은 캐시하려는 Dockerfile의 요점을 취하고 이를 미래의 Dockerfile의 FROM 에서 사용할 이미지로 태그 지정하는 것입니다. 그러면 -no-cache 로 빌드할 수 있습니다. 기본 이미지가 다시 빌드되지 않으므로 결과 없이

하지만 이렇게 하면 캐시된 명령과 캐시되지 않은 명령을 쉽게 인터리빙하는 것이 제한되지 않을까요?

예를 들어 서버에서 내 repo 및 wget 파일을 업데이트하고 그 사이에 여러 단계를 수행하고 싶다고 가정해 보겠습니다. 예를 들어 repo에서 소프트웨어 설치(업데이트되었을 수 있음) - 다운로드한 파일에 대한 작업 수행( 서버) 등

이상적인 것은 Dockerfile에서 도커를 지정하여 매번 캐시 없이 특정 명령을 실행하고 변경 사항이 없는 경우(예: 리포지토리에 업데이트가 없는 경우) 이전 이미지만 재사용하도록 지정하는 방법입니다.

있으면 유용하지 않을까요?

Dockerfile의 CACHE ON 및 CACHE OFF는 어떻습니까? 각 명령은 후속 명령에 영향을 미칩니다.

예, 내 Dockerfile에서 git clone 명령을 사용하고 있으며 업데이트로 다시 복제하려면 줄 끝에 주석을 추가하여 다시 빌드를 트리거해야 합니다. 라인. 이 단계에서는 완전히 새로운 기본 컨테이너를 만들 필요가 없습니다.

컨테이너 ID를 "이 ID를 지나 캐시하지 않음" 명령으로 '도커 빌드'에 전달할 수 있습니까? '도커 빌드'가 Dockerfile의 변경된 라인까지 모든 단계를 캐시하는 방식과 유사합니까?

빌드 캐시에 대한 보다 강력하고 세분화된 제어가 필요하다는 데 동의합니다. 현재로서는 이것을 사용자에게 어떻게 노출해야 하는지 정확히 모르겠습니다.

앞으로 출시될 API 확장, 특히 이름 지정 및 내성을 사용하면 이것이 더 쉬워질 것이라고 생각합니다.

훌륭한 기능이 될 것입니다. 현재 나는 RUN a=a some-command 와 같은 어리석은 것을 사용하고 있으며 캐시를 깨기 위해 RUN a=b some-command

캐시를 더 잘 제어하면 CI의 docker를 훨씬 더 행복하게 사용할 수 있습니다.

@샤이크스

--no-cache 를 bool에서 문자열로 변경하고 도커에서 캐시를 파괴하려는 위치에 대해 정규식을 사용하도록 하는 것은 어떻습니까?

docker build --no-cache "apt-get install" .

IRC에서 이 정확한 기능에 동의하고 제안했습니다.

역 호환성을 유지하기 위해 새 플래그(예: "--uncache")를 만들어야 한다고 생각하는 경우를 제외하고는 --cached를 "--uncache .*"로 해석되는 (더 이상 사용되지 않는) bool 플래그로 유지할 수 있습니다.

2014년 2월 7일 금요일 오전 9시 17분, Michael Crosby 알림 @github.com
썼다:

@샤이크스
--no-cache 를 bool에서 문자열로 변경하고 도커에서 캐시를 파괴하려는 위치에 대해 정규식을 사용하도록 하는 것은 어떻습니까?

docker build --no-cache "apt-get install" .

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/dotcloud/docker/issues/1996#issuecomment -34474686

다른 사람들은 이것에 대해 어떻게 생각합니까? 기능을 구현할 사람이 있습니까?

다른 사람이 시작하지 않은 경우 오늘 이것을 구현하려고 합니다.

나는 그것에 대한 작업 을

• noCache 필드 buildfile a가됩니다 *regexp.Regexp .
  
  
  
  • nil 값은 utilizeCache = true 사용했던 것을 의미합니다.
  
  
• docker build --no-cache 문자열을 전달하면 이제 유효성 검증 정규식 문자열이 서버에 전송됩니다.
• --no-cache 호출하면 기본값은 .*
• 그런 다음 정규식은 새 메서드 buildfile.utilizeCache(cmd []string) bool 에서 사용되어 캐시를 무시하는 명령을 확인합니다.

한 가지: 내가 볼 수 있는 한 flag/mflag 패키지는 값이 없는 문자열 플래그를 지원하지 않으므로 --no-cache 및 --no-cache some-regex 모두 지원하려면 추가 작업을 수행해야 합니다

나는 이것이 별도의 새로운 깃발이 되어야 한다고 생각합니다. --no-cache 의 동작과 구문은 이미 잘 정의되어 있으며 많은 사람들이 많은 곳에서 사용하고 있습니다. 나는 --break-cache 또는 이와 유사한 것에 투표하고 --no-cache 가 오늘날 하는 일을 정확히 하도록 할 것입니다(많은 사람들이 의존하고 여전히 원하는 매우 유용한 행동이기 때문에).

어쨌든, IANTM(저는 관리자가 아닙니다)이므로 이것은 제 개인적인 생각일 뿐입니다. :)

@tianon --no-cache 는 현재 bool이므로 단순히 기존 동작을 확장합니다.

• docker build --no-cache - 이전과 동일한 동작: 캐시 무시
• docker build --no-cache someRegex - someRegex 와 일치하는 RUN 또는 ADD 명령을 무시합니다.

네, 괜찮아요. 문제는 --no-cache 가 bool이므로 기존 동작이 실제로 다음과 같다는 것입니다.

• --no-cache=true - 캐시를 명시적으로 비활성화
• --no-cache=false - 명시적으로 캐시 활성화
• --no-cache - --no-cache=true 약어

또한 이 문제를 해결하기 위해 "true" 및 "false" 특수 케이스 정규식 문자열을 만들어 우리 스스로에게 해가 될 것이라고 생각합니다. 그렇게 하면 향후 사용자에게 잠재적으로 놀라운 동작이 생성될 것이기 때문입니다. ("정규식 'true' 또는 'false'와 함께 --no-cache 사용하면 예상대로 작동하지 않습니다!")

@tianon 네 맞습니다. 빠르게 살펴보고 사람들은 =true/false를 사용하고 있습니다.

귀하가 제안한 대로 새 플래그를 추가하도록 PR 을 수정하게 되어 기쁩니다 . 유지 관리자는 어떻게 생각합니까(

@wagerlabs 접근 방식의 경우 +1

@crosbymichael , @timruffles Dockerfile 작성자가 캐시해야 할 빌드 단계와 캐시하지 말아야 할 빌드 단계를 결정하면 더

일부 종속성을 업데이트하기 위해 기존 이미지 계층을 재구축하려는 기업 환경을 고려하십시오. 기존 Dockerfile 트리는 몇 년 전에 다른 사람이 만들 수 있습니다.

@wagerlabs 접근 방식의 경우 +1

@wagerlabs 접근 방식의 경우 +1이지만 시간 간격에 버스트를 캐시하는 방법이 있으면 훨씬 더 좋을 것입니다. 예를 들어

CACHE [interval | OFF]
RUN apt-get update
CACHE ON

이것이 컨테이너가 비결정적이라는 개념에 어긋날 수 있다는 점에 감사드립니다. 그러나 파이프라인에 자동화된 테스트가 잘 되어 있는 연속 배포 시나리오에서 하고 싶은 일과 정확히 일치합니다.

해결 방법으로 현재 도커 빌드를 실행하는 데 사용하는 스크립트에서 캐시 버스터를 생성하고 캐시 버스트를 강제 실행하기 위해 dockerfile에 추가합니다.

FROM ubuntu:13.10
ADD ./files/cachebusters/per-day /root/cachebuster
...
ADD ./files/cachebusters/per-build /root/cachebuster
RUN git clone [email protected]:cressie176/my-project.git /root/my-project

지속적인 통합을 위해 컨테이너를 사용하려고 하며 캐시의 특정 요소에 시간 초과를 설정하는 기능은 정말 유용할 것입니다. 이것이 없으면 배포할 수 없습니다. 매번 전체 재구축을 강제하는 것은 너무 느립니다.

이 문제를 해결하기 위한 나의 현재 계획은 반올림된 숫자가 점프할 때 캐시 요소를 무효화하기 위해 마지막 15분으로 반올림된 생성된 행과 함께 RUN echo 2014-04-17-00:15:00 와 같은 명령을 동적으로 주입하는 것입니다. 15분마다. 매번 dockerfile을 생성하는 스크립트가 있기 때문에 이것은 저에게 효과적이지만 해당 스크립트 없이는 작동하지 않습니다.

기능에 대해 +1입니다.

저도 이 기능에 투표하고 싶습니다. 마스터 브랜치에서만 업데이트되는 git 리포지토리에서 컨테이너의 일부를 빌드할 때 캐시는 성가신 일입니다.
:+1:

@hiroprotagonist 갖는 git pull 당신의 ENTRYPOINT 힘의 도움을?

@amarnus 나는 가지고 있던 아이디어 @tfoote에이 유사한 해결했습니다. 저는 jenkins 작업에서 빌드를 실행하고 있으며 docker build 명령을 직접 실행하는 대신 템플릿에서 Dockerfile을 생성하고 git 명령 위에 'RUN echo currentsMillies' 줄을 추가하는 빌드 스크립트를 시작합니다. sed와 파이프 덕분에 이것은 몇 분 만에 끝났습니다. 어쨌든 나는 여전히 Dockerfile 자체의 일부로 이 기능을 선호합니다.

@wagerlabs 접근 방식에 대한 내 +1 추가. CI에도 이 문제가 있습니다. 당분간은 단순히 동적 에코 RUN 문을 사용하고 있지만 이 기능이 마음에 듭니다.

캐시 ON/OFF의 경우 +1입니다. 제 사용 사례도 CI 자동화입니다.

+1, 특히 @cressie176 의 예에서와 같이 실행 명령 캐시 간격을 설정하는 기능

"예: 저장소 업데이트 또는 원격 파일 다운로드"

+1

누군가에게 도움이된다면 다음은 Jenkins 빌드에서 사용하는 코드입니다.

echo "Using build $BUILD_NUMBER for docker cachebusting"
sed -i s/cachebust_[0-9]*/cachebust_"$BUILD_NUMBER"/g Dockerfile

캐시 ON/OFF의 경우 +1

CACHE ON/OFF 접근 방식의 가능한 대안으로 "ALWAYS"와 같은 추가 키워드는 어떻습니까? 키워드는 기존 명령(예: "ALWAYS RUN" 또는 "ALWAYS ADD")과 함께 사용됩니다. 의도적으로 "ALWAYS" 키워드는 인접 명령을 완료하기 위해 캐시로 이동하지 않습니다. 그러나 결과를 CACHE(암시적으로 동일한 행이 실행된 다른 시간에 대한 캐시)와 비교하여 ALWAYS 명령의 결과가 변경되지 않은 경우 캐시된 이미지에 연결합니다.

근본적인 필요성은 "멱등성이 아닌 명령" 을 식별하는 것이라고 생각합니다. ALWAYS 명령은 이를 매우 명시적으로 수행합니다. 내 인상은 CACHE ON/OFF 접근 방식이 똑같이 잘 작동할 수 있지만 코드 블록을 많이 전환해야 할 수도 있다는 것입니다(사용자가 실제로 필요한 것보다 더 많은 줄을 차단하도록 권장할 수 있음).

나는 또한 ALWAYS 또는 CACHE 1 WEEK ADD와 같은 명령 접두사에 더 가깝습니다 ...

그래서 나는 잠시 동안 이 문제로 어려움을 겪었고 이 문제가 해결되는 동안 도움이 될 수 있도록 내 작업을 공유하고 싶었습니다. 빌드 호출에 도커 파일 외부에 아무것도 추가하거나 매번 파일을 변경하고 싶지는 않았습니다. 어쨌든 이것은 어리석은 예이지만 추가 메커니즘을 사용하여 캐시를 파괴하고 파일 조작이 필요하지 않습니다.

From ubuntu:14.04

RUN apt-get -yqq update
RUN apt-get -yqq install git
RUN git clone https://github.com/coreos/fleet
ADD http://www.random.org/strings/?num=10&len=8&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new uuid
RUN cd fleet && git pull

분명히 자신의 사용 사례와 네트워크 임의 생성을 선택할 수 있습니다. 어쨌든 그것은 일부 사람들에게 도움이 될 것입니다.

@wagerlabs 접근 방식에 대한 또 다른 +1

기능에 또 다른 +1. 한편 @cruisibesarescondev 해결 방법을 사용합니다.

기능 요청에 대해 한 번 더 +1합니다. 해결 방법에 대해 @cruisibesarecondev 에게 감사드립니다.

기능에 대한 또 다른 +1입니다.

해결 방법에 대해 @cruisibesarescondev 를

ALWAYS 키워드는 특히 단순하고 명확한 의미를 가지고 있기 때문에 좋은 접근 방식이라고 생각합니다. 약간 더 복잡한 접근 방식은 최소 시간을 추가하는 것입니다(buildfarm 또는 지속적 통합과 같은 작업에 유용함). 이를 위해 XXX가 시간 초과인 "EVERY XXX" 구문을 제안합니다. 그리고 해당 명령의 캐시가 빌드된 이후로 XXX보다 길면 명령을 다시 실행해야 합니다. 그리고 출력이 변경되었는지 확인하십시오. 변경 사항이 없으면 마지막 업데이트 시간을 기록하여 캐시된 결과를 재사용합니다. 이것은 EVERY 0이 ALWAYS와 동일함을 의미합니다.

현재 해결 방법을 위해 파이썬에서 빈 템플릿을 사용하여 Dockerfile을 생성하고 두 번의 연속 실행에서 동일한 결과를 감지하지 못하지만 매 XXX초마다 재트리거를 강제 실행한다는 점을 제외하고 위와 같이 작동하는 다음 스니펫을 포함합니다. 상단:

@{
import time
def cache_buster(seconds):
    ts = time.time()
    return ts - ts % seconds
}@

재실행을 강제하고 싶은 곳:

RUN echo @(cache_buster(60))

Dockerfile에서 다음과 같이 표시됩니다.

RUN echo 1407705360.0

보시다시피 가장 가까운 60으로 반올림되므로 60초가 지나갈 때마다 다음 실행은 다음 명령을 모두 다시 실행합니다.

ALWAYS 구문의 경우 +1입니다. CACHE ON/CACHE OFF의 경우 +.5.

ALWAYS 구문의 경우 +1입니다.

예, ALWAYS 구문은 매우 직관적으로 보입니다.

저는 CACHE ON/OFF가 마음에 들지 않습니다. 왜냐하면 라인은 "자체 포함"되어야 하고 Dockerfiles에 블록을 추가하면 많은 "문제"가 발생하기 때문입니다(예: 병합할 때 "이 라인이 캐시로 덮여 있습니까?"를 확인해야 하는 것과 같은). .).

@kuon USER 및 WORKDIR 와 같이 후속 명령에 영향을 주는 명령이 이미 많이 있다고 생각합니다.

네, 맞습니다. 하지만 같은 이유로 사용하지 않습니다. 나는 항상 RUN cd ... && 또는 RUN su -c ...&& 합니다.

블록 표기법을 선호합니다.

CACHE OFF {
    RUN ...
}

이것은 더 명시적이며 실수로 CACHE OFF 행을 삽입하는 것을 방지합니다(구문 오류가 발생함).

내가 지나치게 생각할 수도 있지만 Dockerfile은 실제로 프로덕션에서 실행되지 않으므로(이미지를 빌드할 때만) 빌드할 때 캐시를 비활성화해도 실제로 많은 해를 끼치지 않습니다. 그러나 Dockerfiles가 정말 제한적이라고 생각합니다(수 많은 이미지를 생성하지 않고 변수를 사용할 수 없도록 하기 위해 단일 RUN에서 &&를 사용하여 모든 명령을 연결해야 함...).

이 문제는 새로운 Dockerfile 형식의 기회일 수 있습니다.

방금 말한 내용으로 돌아가고 싶습니다. 나는 @shykes 가 다른 문제 https://github.com/docker/docker/pull/2266 에서 말한 것을 읽었고 그에게도 동의합니다(Dockerfile은 언어와 같은 정말 간단한 어셈블리를 유지해야 함).

나는 변수나 그와 비슷한 것을 원한다고 말했지만 그것은 다른 언어로 다룰 수 있지만 이 경우 Dockerfile의 각 줄은 자체 포함되어야 합니다. 예:

NOIMAGE ALWAYS RUN USER:jon  apt-get update

항상 명령(캐시 없음)을 실행하지만 이미지를 생성하지 않고 사용자 jon을 사용합니다.

이러한 종류의 자체 포함 라인은 다른 언어에서 훨씬 쉽게 생성할 수 있습니다. 컨텍스트(사용자, 캐시, 작업 디렉터리)에 대해 걱정해야 하는 경우 오류가 발생하기 쉽습니다.

편의를 위해 RUN! 할 수 있습니까?

이것에 대한 상태 업데이트가 있습니까?

캐시를 선택적으로 비활성화하면 매우 유용합니다. awscli 명령(amazon AWS 툴킷에서)을 통해 원격 amazon s3 리포지토리에서 파일을 가져오고 ADD 명령을 통해 캐시를 버스트하는 쉬운 방법이 없습니다(적어도 Dockerfile을 편집하지 않고는 방법을 생각할 수 없습니다. 트리거). RUN을 사용할 때 캐시를 선택적으로 버스트하기 위해 사용자에게 제어권을 돌려주어야 하는 강력한 경우가 있다고 생각합니다. 누구든지 나에게 제안이 있으면 기꺼이 듣겠습니다.

우리가 크게 필요로 하는 문제이기 때문에 이 문제를 조금 더 올려보고 싶었습니다.

여전히 ALWAYS 구문이 이상적이라고 확신합니다.

간단한 BREAK 문은 어떻습니까?

@cpuguy83 은 내 특정 사용 사례에서도 작동합니다.

기술적으로 하나의 명령만 캐시하지 않고 나머지 명령은 캐시할 수 있는지 확실하지 않습니다. docker가 증분 diff를 기반으로 하기 때문에 아마 아닐 것입니다.

BREAK 를 지원하면 @CheRuisiBesares의 제안을 기반으로 하는 현재 해결 방법과 기능 패리티가 동일합니다.

내 이전 게시물과 관련하여 실제로 스크립트의 해당 지점부터 캐시를 파괴하는 것으로 충분하고 나머지는 지능형 스크립트 설계에 달려 있습니다(대부분의 사람들의 요구 사항을 해결할 것이라고 믿습니다). 캐시 버스트를 선택적으로 비활성화하는 대신 이것이 가능합니까?

@orrery 해당 빌드 단계 _전에_ COPY 를 추가하여 캐시를 " 파괴 "할 수 있습니다. 복사된 파일이 다른 경우 그 이후의 모든 단계는 더 이상 캐시를 사용하지 않아야 합니다( 이 섹션 참조 ). 더러운 속임수지만 문제를 해결할 수 있습니다.

ALWAYS (또는 EVERY # DAYS 와 같은 유사한 개념)의 핵심은 첨부된 명령 이후의 캐시 비교입니다. 나 자신을 위해(그리고 다른 많은 사람들도 가정), 목표는 캐시 자체를 파괴하는 것이 아닙니다.

• 목표는 명령의 결과(즉, "최신 버전으로 업그레이드")가 변경되는 경우 캐시 사용을 중지하는 것입니다.
• 반대로 결과가 캐시된 버전과 일치하면 캐시를 활용 하려고 합니다.

이것은 ALWAYS 의 출력이 캐시된 버전과 일치하는 경우에만 후속 명령에 대한 캐시를 활용할 수 있기 때문에 @hellais 의 주석을 처리합니다(대부분의 경우 쉽게 발생할 수 있음).

당연히 동일한 논리가 CACHE ON/OFF 모델에 _포함될_ 수 있습니다. 캐시와의 비교는 모든 후속 명령을 다시 실행하는 것보다 저렴할 수 있지만 여전히 비용이 많이 들 수 있습니다. CACHE ON/OFF 블록이 사용자가 OFF 블록에 추가 명령을 포함하도록 권장하는 경우( ALWAYS 에서는 발생할 수 없는 작업) 성능에 상당한 차이가 발생할 수 있습니다.

@tfoote 와 정확히 같은 상황에

EVERY 구문의 경우 +1입니다. ALWAYS 구문도 작업을 완료합니다.

@claytondaley 좋은 지적입니다. 그러나 명령에 대한 캐싱을 완전히 비활성화하는 기능을 갖는 것은 여전히 ​​중요합니다. Docker에는 본질적으로 보이지 않는 숨겨진 상태가 항상 있습니다. 예를 들어 명령을 실행하면 원격 서버의 상태가 변경될 수 있습니다.

@mkoval , ALWAYS 를 사용하는 중요한 시간으로 _숨김 상태를 _ 생성하는 것에 대한 좋은 점을 지적 하셨지만 캐시 재개에 대한 제 논리에는 영향을 미치지 않는다고 생각합니다. 예제를 구체적으로 만들기 위해(다소 사소하더라도) 타사 시스템을 업그레이드하는 명령은 다음과 같습니다.

• 숨겨진 상태를 만들고( ALWAYS 실행해야 함)
• 현재 컨테이너를 변경하지 않음

다음 명령에 숨겨진 상태가 포함되지 않은 경우(사소하게는 컨테이너의 mv 명령) 캐시는 100% 신뢰할 수 있습니다. 동일한 컨테이너, 동일한 명령, 숨겨진 정보에 대한 종속성이 없습니다.

다음 명령(또는 후속 명령)에 숨겨진 정보가 포함된 경우 결과 컨테이너가 캐시와 일치하는 경우에만 캐시를 재개하고 ALWAYS 키워드를 사용해야 합니다.

@claytondaley 귀하의 솔루션은 나에게 매우 우아하고 효율적으로 보입니다. 이것이 구현된다면 매우 감사하겠습니다. :+1: :문어:

ALWAYS 및 EVERY X 제안된 구문을 사용하여 이 기능에 대해 +1입니다. CACHE ON/OFF는 약간 어색하지만 사용하겠습니다. 나는 또한 가능한 경우 캐시를 재개하자는 @claytondaley 의 제안을 정말 좋아합니다.

ALWAYS 구문의 경우 +1입니다. 특히 git repo의 풀 코드에 대해.

+1 이러한 솔루션에 대해.

조금 혼란스럽습니다. 캐싱이 꺼진 후 다시 켜려면 어떻게 해야 합니까? 일단 그것을 끄고 컨테이너에서 어떤 종류의 변경을 수행하면 캐싱을 다시 켜면 기본적으로 캐싱이 꺼진 동안 실행된 Dockerfile 명령에 의해 변경된 사항이 사라지지 않을까요? 우리가 캐싱을 할 수 있었던 이유는 실행된 이전 명령의 전체 목록을 정확히 알고 있고 컨테이너에 있는 내용이 정확히 동일하다는 것을 보장할 수 있기 때문이라고 생각했습니다. 캐싱을 끄면 (그리고 나는 그것의 조회 측면에 대해 이야기하고 있습니다) 그 보장을 날려 버리지 않습니까? 아니면 캐시를 채우지 않는 것에 관한 것입니까?

제안 사항에 대한 나의 이해는 Dockerfile 명령의 일부로 "항상"을 지정하여 항상 단계를 다시 실행할 수 있다는 것입니다. 예를 들어 "RUN ALWAYS git clone https://example.com/myrepo.git "은 항상 실행됩니다(따라서 항상 리포지토리 복제). 그런 다음 @claytondaley 가 제안하는 것은 이 명령이 다시 실행된 후 Docker가 캐시에 대해 변경 사항을 확인한다는 것입니다. 체크섬이 동일하면(즉, 복제된 저장소에 변경 사항이 없어 최신 계층이 캐시의 동일한 계층과 동일한 경우) 캐시를 계속 사용할 수 있습니다. 캐시가 무효화되면 이후의 모든 단계에서 캐시를 사용할 수 없다는 말이 맞습니다. 이러한 제안을 통해 캐시를 사용할 시기를 더 세밀하게 제어할 수 있으며 가능한 경우 캐시에서 다시 시작하는 것이 현명합니다.

@curtiszimmerman... 정확히

@duglin... 수학적 프록시를 사용하면 아이디어가 더 명확해질 수 있습니다. 캐시 (이 맥락에서)의 결과에 불과 메모리입니다 action B 에 적용 할 때 state A 당신이 그것을 다시 처리 할 필요가 없습니다. 일련의 명령을 실행한다고 가정합니다.

• 6
• 항상 실행 * x 의 가치 x 자식의의 repo에서 다운로드 (따라서 변경 될 수 있습니다)를
• + 12

명령을 처음 실행할 때 x 는 8이므로 다음 시퀀스를 얻습니다.

• 6
• 48 ( * x 가 6 적용된 결과)
• 60 ( + 12 가 48 적용된 결과)

내 시스템이 48 다시 도달하면(순서에 관계없이)... 그리고 + 12 명령이 주어지면 처리를 다시 수행할 필요가 없습니다. 내 캐시는 이 명령의 결과가 60 임을 알고 있습니다.

어려운 부분은 동일한 상태( 48 )에 다시 있을 때를 알아내는 것입니다.

• 이론적으로 모든 명령 후 시스템을 다른 모든 캐시된 이미지와 비교할 수 있지만 이는 리소스를 많이 사용하고 일치 항목을 찾을 가능성이 매우 낮습니다.
• 내 제안은 간단하게 유지하는 것입니다. 상태(예: 6 )에 있고 명령(예: * x )을 칠 때마다 우리는 결과를 동일한 상태에 있었던 마지막 시간(또는 여러 번)의 캐시와 비교합니다. 같은 명령을 실행합니다. 이 프로세스 이후의 시스템 상태가 동일하면(예: 여전히 48 ) 캐시를 다시 시작합니다. 다음 명령이 여전히 + 12 이면 처리하는 대신 캐시에서 결과를 가져옵니다.

@claytondaley 하지만 현재 상태를 어떻게 결정하는지 이해할 수 없습니다. 당신이 말했듯이 우리는 컨테이너에 있는 모든 파일을 비교하지 않습니다. 이제 캐시가 작동하는 방식은 기본적으로 현재 컨테이너의 알려진 모든 자식 컨테이너에 대해 실행하려는 다음 명령을 strcmp하는 것입니다. 흐름에서 컨테이너를 건너뛰는 순간 현재 컨테이너가 파일 시스템의 모든 파일을 확인하지 않고 캐시된 다른 컨테이너와 같다고 가정하는 방법을 알 수 없습니다. 하지만 아마도 나는 당신이 하는 일에 불만을 품지 않을 것입니다.

다시 말하겠습니다. 임의의 컨테이너(캐시를 사용하지 않는 경우 기본적으로 보유하는 것)가 주어지면 캐시에서 모든 파일을 비교하지 않고 일치하는 컨테이너를 캐시에서 어떻게 찾을 수 있습니까? 컨테이너?

@claytondaley @duglin "캐시 없음" 작업이 변경되지 않아 캐시될 수 있는지 여부를 결정하는 것은 설명 했듯이 어려운 문제입니다. 또한 꼭 필요한 것보다 있으면 좋은 것입니다.

개인적으로 명령이 항상 실행되도록 할 수 있는 기능만 있다면 더할 나위 없이 기쁠 것입니다. 다음과 같은 Dockerfile을 가져옵니다.

RUN install_stuff_take_forever
RUN always_do_it   #will not run every time
RUN more_stuff

현재 always_do_it 행은 캐시 버스트를 강제 실행하도록 텍스트를 편집하지 않는 한 처음에만 실행됩니다. 나는 우리 대부분이 more_stuff 가 때때로 불필요하게 실행된다는 것을 기꺼이 받아들일 것이라고 생각합니다( always_do_it 가 변경되지 않은 경우 install_stuff_take_forever 대한 캐시를 유지할 수 있다면).

RUN install_stuff_take_forever
NOCACHE
RUN always_do_it
RUN more_stuff

@pikeas 나는 NOCACHE 명령을 완전히

나는 다음을 의미하는 Docker 의

• Docker는 각 명령에 대해 "계층"을 만듭니다.
• 해당 계층에는 해당 명령에 의해 변경된(또는 변경 또는 변경되지 않은 "저장"된) 파일만 포함됩니다.
• 파일 시스템의 현재 상태는 특정 파일의 (가장 최근에 업데이트된) 버전을 찾을 때까지 각 계층을 순서대로 검사하여 논리적으로(작동적으로는 그렇지 않은 경우) 달성됩니다.

이 경우 동일한 명령의 두 인스턴스를 비교하는 것이 상대적으로 저렴합니다. 맨 위 레이어만 비교하면 됩니다(모든 기본 레이어가 공유되기 때문에). 명령에 의해 변경된 특정 파일 목록이 있습니다. 해당 파일만 레이어에 포함됩니다. 물론... 해당 계층의 모든 파일을 비교해야 하지만... 전체 파일 시스템은 비교하지 않아도 됩니다.

명령이 마지막으로 실행된 시간과 새 레이어만 비교할 수도 있습니다(완전한 것은 아니지만).

• 대부분의 경우(git pull 또는 소프트웨어 업그레이드) 현재 버전은 (1) 마지막 버전과 같거나 (2) 새 버전이 됩니다. 그러나 결코 -- 최소한 드물게 -- 이전 버전으로 롤백되지 않습니다. 버전.
• 드문 경우지만(예: dev-master로 업그레이드한 다음 안정적인 버전으로 되돌리기) 이전 버전으로 다시 전환할 수 있습니다. 그러나 이것은 매우 드물기 때문에 대부분의 사람들은 (자주) 가장 최근 버전만 확인하고 드물게 롤백하는 경우에 명령을 다시 실행하는 것이 좋습니다.

물론 모든 이전 버전에 대해 해시 검사를 수행할 수도 있습니다... 전체 파일 검사가 뒤따르는... 오버헤드 없이 완전한 지원을 제공할 수 있습니다.

https://github.com/docker/docker/pull/9934 의 하단을 보면 Dockerfile 명령에 대한 지원 옵션에 대한 논의를 볼 수 있습니다. 이 명령에 대해 "캐시를 사용하지 않음"을 의미하는 --no-cache 옵션이 모두(또는 단지 RUN)에 사용 가능하다면 어떻게 될까요? 예:
RUN --no-cache apt-get install -y my-favorite-tool
그러면 나머지 명령에 대해서도 캐시가 자동으로 비활성화됩니다(제 생각에는).
이렇게 하면 문제가 해결됩니까?

의미적으로 동일한 "RUN ALWAYS"와 "RUN --no-cache" 중에서 저는 개인적으로 더 자연스러운 "RUN ALWAYS" 구문을 선호합니다. 나는 그 PR에 대한 마지막 의견에 동의합니다. --option이 가독성을 깨고 Dockerfiles를 보기 흉하게 만들 것입니다. 또한 Dockerfile 명령은 뒤에 오는 실제 명령과 매우 구별되어야 한다고 생각합니다. "RUN --no-cache myapp --enable-cache"와 같은 옵션을 사용하여 빠르게 표현하기 시작하는 복잡한 구문의 예를 상상해 보십시오.

@curtiszimmerman 당신의 예는 나에게 매우 분명합니다. --no-cache는 RUN용이고 --enable-cache는 myapp용입니다. 배치가 중요합니다. 예를 들어 다음을 보십시오.
도커 실행 -ti 우분투 ls -la
사람들은 -ti가 '실행'을 위한 것이고 '-la'가 'ls'를 위한 것임을 이해합니다. 이것은 사람들이 편안해 보이는 구문입니다.
RUN ALWAYS와 같은 문제 중 하나는 확장성입니다. 모든 Dockerfile 명령에 대해 작동하고 값 전달을 지원할 수 있는 구문이 필요합니다. 예를 들어, 사람들은 특정 명령에 대해 USER를 지정하는 데 관심을 표명했습니다.
사용자 실행=foo myapp
기술적으로 env var USER를 myapp의 셸 내에서 'foo'로 설정하고 있습니다. 그래서 우리는 여기서 모호합니다.
동안: RUN --user=foo myapp에는 이 문제가 없습니다.
Is: RUN var=foo myapp
설정 및 env var 'var' 또는 일부 RUN 옵션을 가져오려는 오타가 있습니까?
IOW, 기존의 유효한 명령 IMO와 겹칠 확률은 우리가 일을 시작할 때 단어를 허용하는 것보다 훨씬 적습니다.

저는 실제로 역순 EVERY <options> COMMAND 합니다. 몇 가지 이유:

• "user"와 "cache"(적어도)의 경우, 그것들은 어떤 COMMAND라도 감쌀 수 있는 환경적 특성입니다.
• RUN ALWAYS 구문은 RUN 명령 인터프리터를 변경하는 것을 의미하며 불필요하게 들립니다.
• RUN EVERY 5 days 경우 이 문제가 더 심각합니다. EVERY에 첨부된 옵션이 더 많은 모호성을 생성하기 때문입니다. EVERY 5 days RUN 옵션이 영향을 미치는 명령에 대해 명확합니다. RUN USER usr 대 USER usr RUN 와 동일한 문제가 있습니다. (1) 명령 키워드가 절대 옵션이 아니거나 (2) 키워드를 이스케이프하는 쉬운 방법이 있는 한 이것은 분명합니다.

명령에 옵션( ALWAYS AS user RUN ... )을 접두사로 추가하여 사용할 수 있습니다. 옵션에 GNU 스타일의 longopts를 사용하는 것에 대해 정말로 걱정하고 있습니다. 왜냐하면 그것들은 늙거나 유약을 바른 눈과 매우 분리되어 있지 않기 때문입니다. 나는 20시간 후에 wtf가 진행되고 있는지 궁금해하면서 복잡한 Dockerfile 명령을 응시하고 있다고 상상할 수 있습니다. 그러나 나는 예측합니다 -- 선택권은 관계없이 일어날 것입니다.

그러나 나는 예측합니다 -- 선택권은 관계없이 일어날 것입니다.

반대로 아직 결정된 것은 없습니다. @duglin 이 제안하는 구문은 이전에 제안/결정된 구문에 대한 _반대 제안_입니다. 이에 대한 자세한 내용은 #9934를 참조하십시오.

또한 @duglin 은 그 결정을 내리는 사람이

가독성에 대한 우려를 공유하지만 여러 옵션을 지정해야 하는 경우 제안된 다른 구문에서도 동일한 문제가 발생할 수 있다고 생각합니다.

이 문제는 가독성을 위해 Dockerfile 형식을 지정하여 극복할 수 있습니다. 적절한 형식을 지정할 때 가독성이 문제인지 테스트/확인하기 위해 몇 가지 더 많은 예제를 작성하는 것이 좋을 것이라고 생각합니다.

네, 이에 대한 귀하의 의견을 환영합니다.

나는 Dockerfile 자체가 캐시 위치를 정의하도록 하는 것에 대해 여전히 매우 -1입니다.
적용해야 하고 적용해서는 안 됩니다. 나는 아직 좋은 예를 보지 못했다.
캐시 버스트로 적절하게 다시 작성할 수 없는 Dockerfile 및
기본 리소스를 업데이트해야 할 때 자연스럽게.

특정 위치에서 캐시를 중지하기 위해 "도커 빌드"에 플래그가 있음
훨씬 더 유연하고 IMO(캐시 제어를 다시
어쨌든 해당 캐시를 관리하는 시스템 운영자의 손에 넘어갑니다.)

@tianon 의 -1에 +1(따라서 -1이 됩니다!)이고 N 단계에서 중단할 플래그를 추가하는 것이 합리적으로 보입니다. 캐시가 손상되면 어쨌든 나머지 Dockerfile에 대해 손상된다는 점을 고려하면 이것이 의미가 있다고 생각합니다.

이에 대한 주요 요구 사항은 docker의 캐싱 메커니즘이 이미지의 저장 및 전송과 직접 연결되어 효율적인 캐싱이 가능하지만 훨씬 더 큰 이미지의 단점이 있기 때문입니다. 그래서 그것을 수정하자!

이 기능에 대해 내가 어떻게 느끼는지 말할 필요가 없습니다. 아직 확실하지 않습니다. 솔직히 말해서 누군가가 ("docker 빌드"에서) N 단계에서 멈추라고 말하는 것을 어떻게 상상하십니까? 오늘 N 단계가 내일 N+1 단계가 될 때 부서지기 쉬운 것 같습니다.
사람들이 빌드 cmd 행에서 해당 레이블을 참조할 수 있도록 Dockerfile 내에 일종의 "레이블"을 추가하는 방법이 필요한 것 같습니다.
우리가 그것을 가지고 있다면 Dockerfile에 나타나는 "STOP-CACHING"명령을 추가하는 것과 많은 차이가 있는지 잘 모르겠습니다.
매번 캐시를 파괴하는 Dockerfile cmd의 좋은 예는 무엇입니까?

글쎄, 그것이 실제로 원래 그것을 만들기 위해 논의 된 이유입니다.
line-content-based regexp도 괜찮을 것입니다 (특히
어느 단계 번호를 정확히 아는 것보다 스크립트를 작성하는 것이 훨씬 쉽습니다.
캐시되는 것을 원하지 않습니다 -- 현재의 전체 사본을 쓰고 있는 방법은 없습니다.
Bash의 Dockerfile 파서, 감사합니다. D).

Tianon Gravi [email protected] 은 다음과 같이 썼습니다.

글쎄, 그것이 실제로 원래 그것을 만들기 위해 논의 된 이유입니다.
line-content-based regexp도 괜찮을 것입니다 (특히
~부터
정확히 어떤 단계 번호를 아는 것보다 스크립트를 작성하는 것이 훨씬 쉽습니다.
너
캐시되는 것을 원하지 않습니다 -- 현재의 전체 사본을 쓰고 있는 방법은 없습니다.
Bash의 Dockerfile 파서, 감사합니다. D).

항상/캐시 파괴라는 이전 제안을 다시 말하고 싶습니다.
"RUN"은 "RUN!"이어야 합니다. 1단어 명령 구조(?)를 유지합니다.

특정 단계에서 캐시를 깨뜨리기 위해 Dockerfile을 편집해야 하는 것(자리 표시자이기 때문에 기본적으로 임의의 것을 추가하여)을 수정해야 합니다. 나는 항상 특정 단계를 실행하는 docker build CLI 옵션을 사용할 것이지만, 명령에 이를 제공하기 위해 특정 라인 번호를 추적해야 하는 것은 다루기 힘들다 는 git clone 바로 앞에 Dockerfile에 임의의 문자(!)를 추가하는 추가 단계를 수행하고 싶지 않습니다.

@curtiszimmerman 영어로 긴박함과 유사한 것을 나타내기 때문에 (!) 제안했습니다. ("이렇게 해야지!")

Dockerfile은 어떤 명령이 캐시 해제/캐시 가능해야 하는지를 정의하기 위한 최소한 하나의 적절한 장소라고 생각합니다. "--no-cache=git"으로 빌드해야 하는 것(이것이 당신이 제안한 것이 아니라는 것을 알고 있지만 당신은 내가 인용/비교할 것을 제안하지 않았습니다)가 더 투박해 보입니다.

왜 RUN에 초점을 맞추는가? 모든 명령에 대해 캐시가 버스트되는 것을 허용하지 않는 이유는 무엇입니까?
다음을 추가하는 것 같습니다.
흉상 캐시
Dockerfile 명령의 유형은 훨씬 더 유연합니다. 그리고 실제로 유연성을 추가하기 위해 선택적으로 플래그를 허용할 수 있습니다.
버스트 캐시 $doit
여기서 $doit이 정의된 경우에만 적용됩니다. 빌드 시 -e 옵션에 대한 지원을 추가하면( https://github.com/docker/docker/pull/9176 ) 사람들은 다음을 수행할 수 있습니다.
도커 빌드 -e doit=true ...

@zamabe 아, 완전히 RUN! 사용하겠습니다. 죄송합니다. 여기서 나는 "이건 이상해!"라고 말하기 위해 (!)를 사용했습니다. 특정 단계에서 캐시를 깨고 싶을 때마다 Dockerfile을 편집하는 방법. 어쨌든 특정 단계가 유용하기 전에 Dockerfile 내부의 캐시를 파괴할 수 있습니다(그리고 추가 승리를 위해 캐시 무효화 명령 이후의 단계가 캐시에 있는 것과 동일한 결과인 경우 캐시에서 계속할 수 있을 만큼 똑똑해야 합니다. ). BUST-CACHE or ALWAYS RUN (or RUN ALWAYS ) or RUN! ... 이 기능을 지원하는 어떤 메커니즘이든 사용하겠습니다.

@duglin 죄송합니다? 버그 제목은 RUN으로 표시되어 있어 예를 들어 설명하기가 더 쉽습니다.

@curtiszimmerman 아.

여담으로; 나는 캐시 재검증(?)이 이 버그가 찾고 있는 캐시 무효화를 약간 넘어선 것이라고 생각합니다. 나는 당신이 제안한 것이 마음에 들지만, 캐시 무효화 명령을 가능한 한 끝에 넣기 위해 Dockerfile을 재정렬할 것입니다. 이것은 필요한 계산/비교를 _항상_ 수행하기 때문에 _가능한_ 캐시 적중에서 얻은 이점을 무효화합니다. 이는 캐시 버스팅을 사용하는 사람들이 아마도 캐시 미스를 기대/예상하기 때문에 일반적으로 Dockerfile 빌드를 완료하는 것보다 더 무거운 패널티일 것입니다.

@zamabe 동의합니다. 구현이 매우 간단하다면 캐시 버스팅 식별자와 별개인 캐시에서 계속하는 특수 명령이 필요할 수 있습니다. 매번 캐시를 비활성화하기 위해 특정 지점에서 DISABLE-CACHE 와 같은 것, 그리고 나머지 Dockerfile이 캐시에서 계속하는 것보다 비용이 많이 드는 사용 사례가 있는 경우 DISABLE-CACHE? 와 같은 것은 가능하면 캐시에서 계속하십시오. 그것은 제안이 아니라 내가 말하는 것을 전달하기 위한 시연일 뿐입니다.

git repo의 풀 코드에 대해 +1

+1

이것은 엄청날 것입니다! 지금 당장은 git 클론에 대한 캐시를 끊기 위해 git commit 해시를 Dockerfile에 쓰는(자리 표시자 덮어쓰기) 지속적인 통합의 일부가 있습니다.

이 문제를 해결하기 위해 https://github.com/docker/docker/pull/10682 PR을 제출했습니다.
캐싱을 다시 켜는 것을 지원하지 않지만 오늘날에는 가능하지 않다고 생각합니다.

+1

Dockerfile에서 임의의 숫자를 생성하고 있는데 캐시됩니다...
NOCACHERUN 명령의 경우 +1

+1
모든 것을 다시 빌드하지 않고 매번 수행해야 하는 일부 RUN에 정말 유용해야 합니다.

git clone 는 캐시에 도달하지만 go get -d 는 그렇지 않습니다. 왜 어떤 아이디어?

_ @LK4D4 @calavera @jfrazelle @crosbymichael @tiborvass_의

실제 사용 사례가 많지 않으므로 닫습니다(자세한 내용은 관련 #10682 참조).

실행에 대해 +1입니다. 좋은 것.

+1

docker 1.9에는 빌드 시간 변수가 도입되었습니다. 캐시를 강제로 깨기 위해 그것들을 (잘못) 사용하는 것이 가능합니다. 자세한 내용은 https://github.com/docker/docker/issues/15182를 참조

이것이 아직 기능이 아닌 이유는 무엇입니까?

@hacksaw6 여기에서 말한 내용을 볼 수 있습니다. https://github.com/docker/docker/pull/10682

+1

+1

+1 이게 아직 아무것도 아닌데!!!!!

+1 건물을 보다 세밀하게 제어하려면 이 기능이 필요합니다.

+1

+1

+1

+1

+1 매우 유용합니다
(지금은 @timruffles 해결 방법 사용)

+1

+1

+1

사람들이 이것이 단지 필요한 기능인 이유를 알 수 있도록 사람들이 +1 대신 사용 사례를 게시하는 것이 유용할 수 있습니다.

+1, 캐시된 git 클론에 대한 솔루션을 찾기 위해 Google을 통해 여기에 도착했습니다.

내 사용 사례:
빌드하는 동안 gradle을 통해 테스트 실행 모드에서 groovy 마이크로 서비스 앱을 호출하는 도커 구성이 있습니다. 그러면 모든 종속 Java 라이브러리(원격 mvn 저장소에서)가 로컬 docker mvn 저장소로 다운로드됩니다. 테스트 실행은 앱을 실행하고 즉시 반환되지만 모든 Java 라이브러리 종속성이 로드되도록 합니다.
도커 실행 단계에서 동일한 앱이 gradle --offline 모드를 통해 실행됩니다. 즉, 마이크로 서비스 앱은 로컬 mvn 저장소 디렉토리에서 로드됩니다. 비싸고 시간이 많이 걸리는 원격 라이브러리 가져오기가 발생하지 않습니다. 이제 이러한 라이브러리의 새 스냅샷 버전을 릴리스할 때 docker 디렉토리를 수정하지 않는 한 docker는 빌드 중에 원격 가져오기를 트리거하지 않습니다(즉, 그는 내 gradle dryrun cmd를 호출하지 않음).

내 사용 사례: 이미지에 사용할 라이브러리의 최신 타사 버전을 가져옵니다. 나는 그것을 위해 도커 허브를 사용하고 있으며 AFAIK는 아무 것도 캐시하지 않습니다. 그러나 그것이 언제 바뀔지 누가 알겠습니까.
docker에 NOCACHE와 같은 명령 플래그가 있으면 이미지가 빌드되는 위치에 관계없이 보장됩니다.

최신 버전인 IMHO보다 빌드 시스템 "기능"에 의존하는 것이 더 나쁩니다.

새 구문을 추가하는 것은 어떻습니까: FORCE RUN git clone .... ?

지금은 RUN _=$(date) git clone ... 를 사용하여 캐시를 무효화하고 있습니다.

@c9s 실제로 작동합니까? 나는 그렇게 생각하지 않는다.

@duglin 설정 환경 변수가 저에게 효과적입니다. "FORCE RUN"은 제안일 뿐입니다.]

@c9s Dockerfile 처리가 아닌 컨테이너의 셸에서 수행되기 때문에 env var 설정이 어떻게 작동하는지 알 수 없습니다. RUN _=$(date) echo hi 시도하면 두 번째 빌드에서 캐시를 사용합니다.

@duglin 당신 말이 맞아요 :| 캐시를 무효화하지 않습니다

@ c9 대신

FROM foo
ARG CACHE_DATE=2016-01-01
RUN git clone ...

docker build --build-arg CACHE_DATE=$(date) ....

@thaJeztah 감사합니다! 효과가있다!

+1 git repos 복제(사용 사례)

너무 많은 +1, 도커 파일에서 git repo를 가져오면 캐시가 이미지가 빌드되지 않도록 합니다. CI를 통해 빌드를 푸시하기가 어렵습니다.

+1 git repos 복제(git repo에서 약간의 편집이 이루어질 때마다 이미지를 처음부터 새로 빌드해야 하는 것은 매우 성가신 일입니다)

@Vingtoft 리포지토리 의 파일을 업데이트하는 경우 캐시가 무효화됩니다.

@itsprdp 그건 몰랐는데 명확히 해주셔서 감사합니다.

@itsprdp 방금 테스트했습니다. 리포지토리를 업데이트하고 이미지를 빌드할 때 Docker는 여전히 캐시를 사용하고 있습니다.
내가 뭔가를 오해하고 있는 건 아닐까?

@itsprdp 내 경험상 정확하지 않습니다. 나는 테스트하기 위해 repo에 새로운 커밋을했고 다시 빌드 할 때 동일한 캐시를 사용합니다.

리포지토리 이전에 도커 파일을 변경하면 물론 캐시 버스트가 발생하지만 단순히 리포지토리를 업데이트해도 이 문제가 해결되지 않는 것 같습니다.

@RyanHartje 혼란을 드려 죄송합니다. 저장소가 업데이트되면 캐시를 무효화해야 하며 이는 기여자가 고려해야 할 사항입니다.
@Vingtoft가 예상하는 사용 사례는 저장소를 캐시하고 저장소에서 변경된 파일만 업데이트하는 것입니다. 구현하기가 복잡할 수 있습니다.

@itsprdp 리포지토리 에서 변경된 파일을 업데이트하는 것만으로 굉장하지만 더 적은(또는 더 많이 말해야 할까요?) 또한 할 수 있습니다.
내 유스 케이스(및 많은 다른 사람들)에서 실제 git pull은 오랜 시간이 걸리지 않습니다. 개발 흐름을 죽이는 다른 모든 것을 구축하는 것입니다.

+1, git clone 중 캐시 사용 :(

통합 솔루션이 있으면 좋겠지만 그 동안 ARG 를 사용하여 특정 Dockerfile 명령에서 캐시를 파괴할 수 있습니다.

Dockerfile에서:

ARG CACHEBUST=1
RUN git clone https://github.com/octocat/Hello-World.git

명령줄에서:

docker build -t your-image --build-arg CACHEBUST=$(date +%s) .

CACHEBUST 를 현재 시간으로 설정하면 항상 고유하며 Dockerfile에서 ARG 선언 이후의 명령은 캐시되지 않습니다. CACHEBUST build-arg를 지정하지 않고 빌드할 수도 있습니다. 이렇게 하면 기본값 1을 사용하고 캐시를 보존합니다. 이것은 항상 git repos의 새로운 복사본을 확인하고 최신 SNAPSHOT 종속성을 가져오는 데 사용할 수 있습니다.

편집: 어, @thaJeztah가 말한 것입니다. 나는 이것을 그의 솔루션에 대한 추가 설명으로 남겨두겠습니다.

@shane-axiom CACHEBUST 값으로 git commit hash를 사용하는 것은 어떻습니까?

export CACHEBUST=`git ls-remote https://[email protected]/username/myRepo.git | grep refs/heads/develop | cut -f 1` && \
echo $CACHEBUST && \
docker build -t myDockerUser/myDockerImage \
   --build-arg blah=blue \
   --build-arg CACHEBUST=$CACHEBUST \
   .

http://stackoverflow.com/questions/15677439/how-to-get-latest-git-commit-hash-command#answer -15679887의 단서를 기반으로 합니다.

@pulkitsinghal git repos에 대한 캐시를 파괴하는 데 멋지게 보입니다. 다른 용도(예: SNAPSHOT 종속성 가져오기 등)의 경우 항상 버스팅 타임스탬프 접근 방식이 잘 작동합니다.

캐시 ON에 대해 +1 | 끄다

+1

+1

@CheRuisiBesares 접근 방식 에 대해 기억하십시오. 캐시 문제에 대한 해결 방법으로 항상 ADD https://www.random.org/strings/?num=16&len=16&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new uuid 를 사용할 수 있습니다.

추가 사용 사례를 게시하려면 ....

COPY package.json /usr/src/
RUN npm install

package.json 우리는 일반적으로 일부 비공개 github 종속성에 대해 master 태그를 가리킵니다. 이것은 우리가 package.json 파일을 변경하지 않는 한 실제로 최신 master 얻지 못한다는 것을 의미합니다(일반적으로 설명에 - 를 설명에 추가한 다음 테스트하는 동안 제거).

A는 RUN NO CACHE 대신 취할 RUN 그것이 좋은 솔루션이 될 것처럼 보인다.

+1

캐시를 사용하고 npm에서 내 새 게시 라이브러리를 사용하지 않는 npm 설치에 대해 비슷한 문제가 있습니다.

도커 파일에서 RUN 명령당 캐시를 비활성화할 수 있다면 좋을 것입니다.

@brycereynolds @mmobini 캐시를 수동으로 https://github.com/docker/docker/issues/1996#issuecomment -172606763을 참조

캐시를 무효화할 수 없어 문제가 발생하는 사용 사례가 있습니다. Docker에서 Dropwizard 애플리케이션(Maven으로 빌드된 Java REST Services)을 실행 중이고 자동화된 시스템이 모든 컨테이너 빌드 및 배포를 수행하고 있습니다. 내 저장소에 Dockerfile을 포함하고 나머지는 수행합니다. 시스템은 내 애플리케이션의 프로덕션 버전과 하나 이상의 개발 버전을 실행합니다. 개발 빌드는 문제가 있는 곳입니다.

개발 중에 일부 프로젝트 종속성의 버전 번호에는 SNAPSHOT이 있습니다. 이것은 버전이 개발 중이며 모든 빌드와 함께 새 버전을 내려야 함을 Maven에 지시합니다. 결과적으로 동일한 파일 구조로 인해 두 개의 별개 빌드가 생성될 수 있습니다. 버그가 SNAPSHOT 종속성에서 수정되었을 수 있으므로 이는 바람직한 동작입니다. 이를 지원하려면 파일 시스템의 현재 상태를 기반으로 명령의 효과를 결정할 방법이 없기 때문에 Docker가 특정 명령을 실행하도록 하는 것이 도움이 될 것입니다. Maven 스타일의 SNAPSHOT 종속성이 여러 다른 빌드 시스템에서 사용되기 때문에 대부분의 Java 프로젝트가 이에 실행됩니다.

@ctrimble --no-cache 또는 --build-arg 를 사용하여 캐시를 무효화할 수 있습니다.
캐시 가능한 모든 명령이 포함된 기본 이미지를 사용하여 --no-cache 의 영향을 최소화할 수 있습니다.

@cpuguy83 답변 감사합니다. 스레드를 읽고 현재 옵션을 이해합니다. 캐시 무효화 인수를 제공하기 위해 사용 중인 빌드 시스템으로 티켓을 열었습니다. 단일 애플리케이션에 대해 두 개의 개별 이미지를 생성하는 것은 빌드 속도를 높이기 위해 거쳐야 할 많은 과정처럼 보입니다. 다음과 같이 지정하는 것이 훨씬 쉬울 것입니다.

1. 파일 시스템이 동일한 경우 캐시할 수 있는 작업 수행
2. 실행 시점에 따라 파일 시스템을 변경할 수 있는 작업 수행
3. 이전 단계에서 파일 시스템이 변경되지 않은 경우 캐시될 수 있는 몇 가지 작업을 더 수행합니다.

이 패턴은 개발 빌드에서 자주 나타납니다. Dockerfile에 의미 체계가 있으면 좋을 것입니다.

@ctrimble 한 단계에서 캐시를 버스트 됩니다.

@cpuguy83 정확히. 내 빌드 시스템의 의미는 개발 빌드에 대해 일시적입니다. 캐싱보다 올바른 빌드를 선택해야 합니다. 정말 둘 다 받고 싶습니다.

여기에 상당한 토론이 있습니다. 이미 제안된 경우 사과드립니다. 그러나 다음과 같은 것이 있다면 어떻게 될까요?

CHECK [FILE_PATH]

모든 도커는 파일의 MD5(또는 다른 해시가 힙한 모든 것)를 저장하고 파일이 변경되면 이후의 모든 단계가 무효화됩니다.

나는 아마도 다음과 같이 할 것입니다.

CHECK Gemfile
CHECK package.json
CHECK composter.json
CHECK project.json

일정 기간이 지난 후 시간이 얼마나 흘렀는지 확인할 수도 있습니다. apt 플러그인에 대한 Ansible의 cache_valid_time 매개변수는 영감을 줄 수 있습니다. http://docs.ansible.com/ansible/apt_module.html

이를 위해 구문은 다음과 같습니다.

EXPIRE 1234567 
RUN apt-get update
RUN bundle install

Docker는 마지막 실행 시간을 알고 "지금"을 기준으로 시간이 경과했는지 계산합니다.

@atrauzzi 1.13의 빌드에서 --squash 를 지원합니다(지금은 실험용).

@cpuguy83 내가 읽을 수 있는 --squash 에 대한 문서나 설명이 있습니까? 처음에는 이름이 내 생각과 일치하는 것처럼 들리지 않습니다. 그러나 나는 틀릴 수 있습니다.

@atrauzzi 예, 빌드 참조에서.

기본적으로 --squash 둘 다 계층 캐시를 보존하고 Dockerfile의 모든 것이 단일 계층에서 발생한 것처럼 두 번째 이미지를 생성합니다.

파일 캐시가 여전히 개별적으로 유효한지 확인해야 하는 이유를 모르겠습니다. ADD 및 COPY 는 복사되는 모든 항목에 대해 이미 이 작업을 수행합니다.

@cpuguy83 좋은 점, 생각도 못했는데, 물론 이미 사용 중입니다.

타임스탬프/기간 접근 방식은 어떻습니까? 이미 사용 가능한 것으로 가능한가요?

타임스탬프/기간 접근 방식은 어떻습니까? 이미 사용 가능한 것으로 가능한가요?

빌드 인수를 통해;

ARG expire_after=never
RUN do some thing

docker build --build-arg expire_after=2016-12-01 -t foo .

캐시를 파괴하도록 빌드 인수를 변경하십시오.

더 깨끗한 방법을 위해 +1

더 깨끗한 방법을 위해 +1

캐시 읽기를 비활성화하고 캐시에 쓰기를 비활성화하는 별도의 옵션도 있어야 합니다. 예를 들어 이미지를 처음부터 새로 만들고 캐시된 레이어를 모두 무시하면서 결과 새 레이어를 캐시에 기록할 수 있습니다.

+1

빌드 명령에 단계 번호를 전달하는 것이 좋습니다.

이 같은:
docker build --step 5 .

빌드 중 5단계를 포함하여 이후의 모든 캐시를 무시합니다.

+1
제발.

캐시 켜기|끄기 +1

이러한 CACHE ON|OFF 명령의 문제는 캐시가 꺼진 단계에서 추가 단계를 캐시할 방법이 없다는 것입니다. 유일하게 합리적인 명령은 ENDCACHE 입니다.

그것은 유효한 생각/정신입니다. 이 명령은 캐시가 다시 켜질 때 캐시되지 않은 모든 레이어를 단일 레이어로 통합해야 합니다. 물론 당신은 여전히 ​​최고의 명명/의미론의 정확성/기능의 선호하는 구문에 대해 논쟁할 수 있습니다.

+1

+1 필수 기능

CACHE ON|OFF +1 동의

+1 놀랍습니다.

Docker가 이전에 단계를 캐시하는 방식을 실제로 이해하지 못했고 내 시스템이 올바르게 빌드되지 않는 이유를 조사하는 데 반나절을 보냈습니다. "git clone" 캐싱이었습니다.

ALWAYS 키워드를 갖고 싶습니다.

어떻게 닫혀?

가장 좋은 해결 방법은 무엇입니까?

https://github.com/moby/moby/issues/1996#issuecomment -185872769 시도했는데 작동했습니다.
Dockerfile에서:

ARG CACHEBUST=1
RUN git clone https://github.com/octocat/Hello-World.git

명령줄에서:

docker build -t your-image --build-arg CACHEBUST=$(date +%s)

RUN과 유사한 새 명령을 생성하지 않지만 RUN NO CACHE에 대해 RUNNC를 캐시하지 않는 이유는 무엇입니까?

@habeebr (https://github.com/moby/moby/issues/1996#issuecomment-295683518) - https://github.com/moby/moby/issues/1996# 과 함께 사용합니다.

+1

RUNNC는 좋은 아이디어입니다!

이 문제가 종료된 이유는 무엇입니까? 본질적으로 동일한 것을 요구하는 무수한 중복과 이러한 중복 중 하나 이상의 긴 댓글 기록 사이에서 이 기능을 사용할 수 있는 것을 보는 데 건전한 관심이 있다는 것은 _분명한 것 같습니다_.

나는 그것이 어렵고 아마도 아무도 요구 사항을 충족하고 매력적인 Docker 추가 기능을 충분히 깨끗한 충분히 우아한 솔루션을 제안하지 않았다는 것을 알았습니다. 그러나 그것이 _필요하지 않다는 것을 의미하지는 않습니다.

이것을 끝내는 것에 찬성하여 내가 들은 유일한 다른 주장은 이것을 달성할 수 있는 다른 방법이 있다는 것입니다...그러나 그 주장도 소집을 통과하지 못합니다. 캐시 제어 부족을 해결하기 위한 유일한 목적으로 여러 기본 이미지를 만드는 것은 다루기 힘들고 ARG를 통해 무효화를 시도하는 것은 둔하고 직관적이지 않습니다. Docker 개발자가 공식적으로 도구에 조잡한 해킹을 통합하려는 만큼 사용자가 이러한 "해결 방법"을 활용하기를 원한다고 상상합니다.

어렵지 않습니다: https://github.com/moby/moby/pull/10682
쉬운 솔루션, 쉬운 UX. 수행해야 하는지 여부에 대한 명확한 합의가 없습니다.

와우 그냥 와우...

나는 그것에 대해 듣지 않기 위해 이미 그것을 구현했을 것입니다. 사용자 기반이 그것을 원한다는 분명한 합의가 있다는 것을 신경 쓰지 마십시오. 저는 그런 큰 오픈 소스 프로젝트의 개발자 측이 아니라 훨씬 더 작은 프로젝트였기 때문에 아마도 제가 뭔가를 놓치고 있는 것 같습니다.

+1

합리적인 보안과 더 나은 성능을 위해 +1

+1

+1

+1

+1

+1

+1

+1 스팸을 그만 둘 수 있습니까? 반응 기능을 사용하여 투표하세요.

변경 사항이 있습니까?
이 문제가 닫힌 이유를 아직 모릅니다.
제 생각에는 원격 git 저장소에서 버전 가져오기를 완벽하게 처리하는 필수 기능입니다.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

왜 이것을 닫습니까? 유용한 것 같아요

+1

+1

+1

현재 레이어(및 다음)에 대한 캐시를 비활성화하는 가장 간단한 방법:

도커파일

ARG CACHE_DATE
RUN wget https://raw.githubusercontent.com/want/lastest-file/master/install.sh -O - | bash

그리고 이미지를 빌드할 때 --build-arg 를 추가해야 합니다.

docker build  --build-arg CACHE_DATE="$(date)"

그러면 캐시를 사용하지 않고 이미지를 빌드할 때마다 wget 명령이 실행됩니다.

RUNNC 또는 CACHE OFF 가 좋을 것입니다.

그 동안 이것은 유망해 보입니다.
http://dev.im-bot.com/docker-select-caching/

그건:

나는 침착하게 가서 무리에 합류할 것이다.

+1

예, 명령에 선택적 캐싱이 필요합니다. 구성 파일에서 한 단어만 변경하면 내 COPY 가 80% 실패합니다. 내 COPY 캐시하지 않고 다른 모든 것을 캐시하고 싶습니다. CACHE ON 및 CACHE OFF 가 있으면 좋습니다.

RUN X
RUN X
CACHE OFF
COPY /config /etc/myapp/config
CACHE ON

@shadycuz 어떤 방법으로도 캐시를 비활성화/무효화한 후에는 캐시를 "다시 활성화"할 수 없습니다. 빌드는 캐시되지 않은 레이어가 새로운 레이어에서 고려해야 할 파일 시스템의 다른 것을 변경하지 않았는지 (합리적인 양의 리소스로 합리적인 시간 내에) 확인할 수 없습니다. 항상 외부 구성 파일을 가져와야 하는 영향을 최소화하려면 COPY 지시문을 Dockerfile에서 최대한 아래에 놓아야 합니다(Docker가 빌드 캐시를 최대한 많이 사용할 수 있도록 캐시가 무효화되기 전에 가능한 한 빌드 프로세스).

빌드 프로세스의 특정 지점에서 캐시를 무효화하려면 앞에서 언급한 --build-arg 및 ARG 사용에 대한 다른 의견을 참조할 수 있습니다.

@shadycuz @curtiszimmerman 예, CACHE OFF 만 보존할 수 있지만 CACHE ON 보존하지 않을 수 있습니다. 이전 레이어가 변경되면 다음 레이어를 다시 빌드해야 하기 때문입니다.

나는 CACHE ON 이 기술적인 관점에서 의미가 없다는 데 동의합니다. 그러나 실제로 어떤 레이어가 무효화되어야 하는지 의도를 보다 명확하게 표현하는 데 도움이 됩니다.

좀 더 유연한 솔루션은 RUN 와 유사한 명령으로 일부 셸 코드에서 캐시를 무효화해야 하는지 여부를 결정할 수 있습니다. 종료 코드 0은 "캐시 사용"을 의미하고 1은 "캐시 무효화"를 의미할 수 있습니다. 쉘 코드가 제공되지 않으면 기본값은 여기서부터 캐시를 무효화하는 것일 수 있습니다. 예를 들어 명령을 INVALIDATE라고 할 수 있습니다.

왜 댓글도 없이 닫혔지?

댓글이 있었지만 github에 숨겨져 있습니다.
https://github.com/moby/moby/issues/1996#issuecomment -93592837

+1

이 기능은 지금 저에게 생명의 은인이 될 것입니다.

+1

실제 사용 사례가 많지 않으므로 이것을 닫습니다.

212개의 댓글과 계산이 있지만 아직 사용 사례가 없습니까? 꽤 무지한 것 같습니다.

+1

+1

+1

+1

+1

문제는 여전히 여기에 있으며 여전히 솔루션이 필요합니다. 아직 실제 사용되는 경우가 많이 있습니다.

+1

Docker 개발자는 캐시 없음 요청으로 인해 중앙 집중식 건물 인프라가 DDsS되지 않도록 보호하기 위해 이것을 구현할 인센티브가 없다고 생각합니다.

또한 캐시 없는 빌드를 용이하게 하는 병렬 인프라가 엔터프라이즈 사용자에게 흥미로울 것이라고 생각합니다.

전반적으로 이 문제는 소프트웨어 기능에 관한 것이 아니라 서비스 확장 문제입니다.

@jaromil 자체 호스팅 리포지토리에서도 가능하지 않기 때문에 완전히 사실이 아닙니다.

자체 호스팅 리포지토리를 실행하기 위한 소프트웨어는 무엇입니까? 나는 당신이 무엇을 언급하는지 잘 모르겠습니다.
간단한 자체 호스팅 솔루션은 cron cloning git repos 및 runnig docker build --no-cache일 수 있습니다. 이 문제는 오픈 소스 소프트웨어에서 발생할 수 없습니다. 그러면 누구나 docker 빌드 명령줄을 수정할 수 있습니다.

@jaromil 나는 그것이 문제라고 생각하지 않습니다. DockerHub의 오픈 소스 프로젝트에 사용하는 것이 더 효율적입니다(유료 프로젝트는 물론 빌드 수에 대해 비용을 청구하지 않음). 빌드가 빈번한 CI/CD 환경에서는 더욱 악화됩니다.

그렇게 해야 하는 한(docker 및 git을 사용하고 있고 공유 볼륨을 실행하는 5개의 컨테이너를 원하지 않음), 새 버전을 업로드할 때마다 컨테이너를 다시 빌드하고 업로드해야 합니다. 전체 컨테이너입니다.
인코드 캐시 없음 플래그를 사용하면 빌드를 실행할 때마다 버전 업데이트를 위해 전체 컨테이너 대신 해당 단일 레이어를 빌드하고 교체합니다.

자체 호스팅 담당자에 대해서는 놀랄 것입니다. @bluzi 의견을 이해합니다. 자체 호스팅(또는 aws ecr 사용)하는 경우 ddos ​​영향이 없습니다.

좋아, 이것은 확실히 내가 상상했던 더 복잡한 시나리오입니다. 이제 제 생각에는... 일종의 nocache 단일 레이어 해시로 업로드하는 것... 푸시 및 재정의, 이름을 지정합니다. 잘 모르겠어

TLDR: Docker 문서에 대한 몇 가지 개선 사항이 많은 도움이 될 수 있다고 생각합니다.

캐싱에 대한 내 자신의 문제/혼란이 발생한 후 여기에서 끝났습니다. 여기와 https://github.com/moby/moby/pull/10682에서 모든 의견을 읽은 후 내 특정 사용 사례에 사용할 수 있는 솔루션을 찾았습니다. 그러나 어떻게든 나는 이에 대한 Docker의 응답에 여전히 좌절감을 느꼈고 많은 다른 사람들도 같은 생각을 하고 있는 것 같습니다.

왜요? 여러 다른 각도에서 이에 대해 생각해 본 결과 여기의 문제는 모호한 사용 사례, 제안된 변경 사항에 대한 지나치게 일반화된 주장(유효할 수 있지만 제시된 사용 사례를 직접적으로 다루지 않음), 몇 가지 일반적인 사용 사례에 대한 Docker 권장 사항에 대한 설명서. 아마도 나는 상황을 명확히 하고 이 상황을 돕기 위해 개선할 수 있는 문서를 식별하는 데 도움을 줄 수 있습니다.

줄 사이를 읽으면 이 기능 요청에 대한 초기 댓글 작성자 대부분이 docker image build 대한 추가 인수를 사용하여 Dockerfile의 특정 지점에서 캐시를 비활성화하는 솔루션에 만족할 것 같습니다. 이에 대한 Docker의 현재 솔루션(https://github.com/moby/moby/issues/1996#issuecomment-172606763에 설명됨)은 이러한 대부분의 경우에 충분해야 하며 많은 사용자가 이에 만족하는 것처럼 들립니다. . (누군가 docker image build 대한 추가 인수를 제공할 수 있는 사용 사례가 있지만 이 솔루션이 여전히 부적절하다면 이것이 부적절한 이유를 설명하는 주석을 추가하는 것이 도움이 될 것입니다.)

남아 있는 모든 좌절감은 캐싱 동작을 제어하기 위해 docker image build 에 추가 인수를 전달해야 하는 요구 사항과 관련된 것으로 보입니다. 그러나 이와 관련된 사용 사례는 잘 설명되지 않았습니다.

줄 사이를 다시 읽으면 이러한 모든 사용 사례가 사용자를 대신하여 docker image build 를 실행하는 서비스와 관련되거나 docker image build 를 실행하는 다른 사용자에게 배포되는 Dockerfile과 관련된 것으로 보입니다. docker image build 추가 인수를 전달하는 것이 문제인 다른 사용 사례가 있는 경우 사용 사례를 자세히 설명하는 설명을 추가하는 것이 도움이 될 것입니다.)

이러한 많은 경우에 사용 사례에는 Dockerfile의 특정 지점(이 기능 요청의 원래 지점)에서 캐싱을 비활성화하는 기능이 실제로 필요하지 않은 것처럼 들립니다. 대신, 많은 사용자가 docker image build "--no-cache" 인수를 사용하지 않고 각 작업 전에 Dockerfile을 수동으로 수정할 필요 없이 Dockerfile 내에서 캐싱을 완전히 비활성화하는 기능에 만족할 것 같습니다. 짓다. (사용 사례를 설명할 때 부분 캐싱이 실제로 필요한지 또는 캐시를 완전히 비활성화해도 사용 사례에 충분한지 여부를 언급하는 것이 도움이 될 것입니다.)

서비스가 사용자를 대신하여 docker image build 를 실행하는 경우 Docker는 이러한 모든 서비스가 캐시를 무조건 비활성화하거나 사용자에게 캐시 비활성화 옵션을 제공하기를 기대하는 것처럼 들립니다. https://github.com/moby/moby/pull/10682#issuecomment-73777822 에 따르면 Docker Hub는 캐시를 무조건 비활성화합니다. 서비스가 아직 이를 수행하지 않는 경우 Docker는 https://github.com/moby/moby/pull/10682#issuecomment-159255451에 대해 서비스 제공업체에 불만을 제기할 것을 제안했습니다.

이것은 docker image build 를 실행하는 서비스와 관련하여 Docker가 취하는 합리적인 입장인 것 같습니다. 그러나 이 입장은 서비스 제공자와 사용자 모두가 무엇을 기대해야 하는지 알 수 있도록 눈에 잘 띄는 곳에 공식적으로 문서화해야 합니다. 이 위치 또는 Docker Hub 캐싱 동작은 현재 그 거대/고대/닫힌 풀 요청 깊숙이 묻힌 비공식 댓글이 아닌 다른 곳에서는 문서화되지 않은 것으로 보입니다. 따라서 서비스 제공업체와 사용자 모두가 일상적으로 이것을 잘못 이해하십시오. 빌드 서비스의 캐싱 사용에 대한 Docker의 의견을 설명하는 docker build 참조 에 정보를 추가하고 Docker Hub 캐싱 동작에 대한 정보를 Docker Hub 자동화 빌드 문서 에 추가하면 이 문제가 제거될 수 있습니까?

Dockerfile이 docker image build 직접 실행하는 다른 사용자에게 배포되는 경우 일부 사람들은 간단한 docker build . 명령(추가 인수 없이)을 사용하는 것이 너무 일반적이어서 다음과 같이 될 것이라고 주장했습니다. Dockerfile 빌더가 사용자에게 인수를 추가하도록 요구하는 동안 비합리적입니다(예: https://github.com/moby/moby/issues/1996#issuecomment-72238673 https://github.com/moby/moby/pull /10682#issuecomment-73820913 https://github.com/moby/moby/pull/10682#issuecomment-73992301)는 사용자가 Dockerfile에 캐시 재정의를 하드 코딩하여 캐싱을 사용하지 못하도록 무조건 막는 것은 부적절하다고 주장했습니다. 이에 대한 상세/강력한 사용 사례가 없는 상황에서 Docker는 캐싱을 제어하기 위해 추가 명령줄 인수를 요구하기로 결정했으며, 이것이 계속되는 좌절의 원인인 것 같습니다. (이와 관련된 강력한 사용 사례가 있는 사람이 있다면 자세히 설명하는 주석을 추가하는 것이 도움이 될 것입니다.)

그러나 Docker는 추가 인수 없이 docker build . 를 실행하는 사용자의 습관을 깨뜨리는 것만으로도 모두를 행복하게 할 수 있을 것 같습니다. 캐싱 동작 및 "--no-cache" 인수는 관련 Docker 자습서(예: this 또는 this
또는 이 ). 또한 docker build 문서 에는 "--no-cache" 인수가 나열되어 있지만 그 중요성을 설명하거나 많은 일반적인 사용 사례에서 중요하다는 사실을 강조하지 않습니다. (또한 docker image build 문서 는 비어 있습니다. 최소한 docker build 문서를 참조해야 Dockerfile 참조 및 모범 사례 문서만 실제로 캐싱 동작을 설명하고 역할을 언급하는 것으로 보입니다. "--no-cache" 인수. 그러나 이러한 문서는 고급 Dockerfile 작성자만 읽을 수 있습니다. 따라서 고급 사용자만 "--no-cache" 인수에 익숙하고 대부분의 사용자가 추가 인수 없이 docker build . 만 실행한 다음 작동하지 않을 때 혼란스러워한다는 것은 놀라운 일이 아닙니다. 그들이 또는 Dockerfile 작성자가 기대하는/원하는 방법. "--no-cache" 인수와 그 중요성을 언급하기 위해 튜토리얼과 docker build 문서를 업데이트하면 이 문제를 해결할 수 있을까요?

+1

+1

docker의 공식 도구 bashbrew를 사용 하면 이미지를 빌드할 때 인수를 추가할 수 없으므로 "공식적으로 지원되는" 답변이 작동하지 않습니다.

+1

+1

내가 지금 적중하고 있는 사용 사례는 개인 패키지를 설치하기 위한 빌드 인수로 일시적이고 단기적인 비밀을 전달하려는 것입니다. 비밀이 변경될 때마다(기본적으로 모든 빌드) 캐시가 손상되고 패키지가 다시 다시 설치되기 때문에 캐싱이 완전히 중단됩니다.

ARG를 지정하기 전에 COPY된 스크립트에서 ARG를 사용하여 이를 우회하려고 시도했지만 ARG 입력이 변경된 경우 ARG가 선언된 후 Docker가 모든 것을 무효화하는 것으로 보입니다.

내가 보고 싶은 동작은 빌드를 호출할 때 Dockerfile 또는 CLI에서 ARG에 항상 캐싱으로 플래그를 지정할 수 있는 것입니다. 비밀과 같은 사용 사례의 경우 종종 그것이 원하는 것입니다. 패키지 목록의 내용은 ARG에 전달된 인수가 아니라 캐시가 무효화된 시점을 지정해야 합니다.

이 섹션이 기본 이미지로 사용되는 두 번째 이미지로 추출될 수 있다는 이론을 이해하지만 package.json, requirements.txt, Gemfile 등과 같이 프로젝트에서 패키지를 사용할 때는 다소 어색합니다. 그 기본 이미지도 계속해서 재구축될 것입니다.

이 라인 지시문에서 CACHE OFF 로 +1 - 나는 이것을 문자 그대로 몇 년 동안 기다려 왔습니다.

도커 허브/도커 클라우드에서 캐시를 비활성화해야 했으며 큰 레이어를 캐시한 다음 dockerfile 끝 부분에서 nocache 업데이트 명령을 실행할 수 있다면 엄청난 시간과 빌드를 절약할 수 있습니다.

내가 보고 싶은 동작은 빌드를 호출할 때 Dockerfile 또는 CLI에서 ARG에 항상 캐싱으로 플래그를 지정할 수 있는 것입니다. 비밀과 같은 사용 사례의 경우 종종 그것이 원하는 것입니다. 패키지 목록의 내용은 ARG에 전달된 인수가 아니라 캐시가 무효화된 시점을 지정해야 합니다.

--build-arg PASSWORD=<wrong> 는 --build-arg PASSWORD=<correct> 와 다른 결과를 생성할 수 있으므로 패키지 목록의 내용을 보는 것만으로도 효과가 있을지 확신할 수 없습니다. 빌더는 실행되는 단계( make DEBUG=1 foo 와 make DEBUG=0 foo 가 동일합니까?)에 환경 변수 설정/변경이 어떤 영향을 미칠지 자체적으로 예측할 수 없습니다. 현재 유일한 예외는 xx_PROXY 환경 변수에 대한 것입니다. 여기서 네트워크 연결에는 프록시가 필요할 수 있지만 다른 프록시로 전환하면 동일한 결과가 생성되어야 한다고 가정합니다. 따라서 이것이 작동하려면 캐싱을 위해 무시할 특정 환경 변수(/build arg)를 나타내는 방법이 필요합니다.

BuildKit은 이제 RUN --mount=type=secret 및 RUN --mount=type=ssh 대한 실험적 지원을 제공합니다. 이는 비밀/자격 증명을 전달하는 데 도움이 될 수 있지만 이러한 비밀이 변경되면 캐시를 무효화할 수 있습니다(확실하지 않음, 빌드킷 문제 추적기(https://github.com/moby/buildkit/issues)에서 불러옵니다.

도커 허브/도커 클라우드에서 캐시를 비활성화해야 했습니다.

Docker Hub/Cloud는 실제로 캐싱을 _사용_합니까? 캐싱이 사용되지 않는다고 생각합니다(예: 임시 빌드 환경을 사용하고 있음).

DockerHub는 빌드 캐싱을 사용하지 않았던 것으로 기억합니다. 하지만 이 티켓 직전에 Docker Cloud에서 자동화된 빌드를 살펴보고 있었고 기본적으로 꺼져 있지만 각 분기의 Autobuild 슬라이더 옆에 현재 Building Caching 슬라이더가 있습니다.

git clone 와 같은 단계는 변경되지 않을 지시문 문자열만 비교하기 때문에 최신 repo 다운로드를 얻지 못하기 때문에 빌드 캐싱을 활성화할 수 없습니다. 오늘 이 문제를 우리 편에서 몇 년 동안 가시처럼 지내온 동료에게 설명하면서 많은 사용 사례에서 큰 불완전한 것처럼 보이기 때문에 놀랐습니다.

내가 많이 선호 초기 git clone && make build 캐시 된 후 바로 할 수 NO CACHE A의 git pull && make build 단계를 이미 마지막으로 설치뿐만 아니라 훨씬 작은 코드 업데이트 + 종속성을 얻을 수 있습니다 따라서 빌드뿐만 아니라 지금 당장 수백 MB의 레이어를 다시 다운로드하고 교체해야 하는 모든 클라이언트를 위해 대량의 이미지를 효율적으로 캐싱하므로 매우 비효율적입니다.

크기는 많은 프로젝트에 많은 종속성이 있기 때문입니다. 시스템 패키지 + Perl CPAN 모듈 + Python PyPI 모듈 등

Alpine을 사용해도 시스템 패키지 종속성과 CPAN 및 PyPI 종속성을 추가하면 더 작은 이미지를 만들 수 있는지 확인하기 위해 수년 동안 Alpine을 사용해 왔지만 일단 종속성이 많으면 그렇지 않습니다. 시스템 패키지를 추가하면 대부분이 바로 다시 추가되기 때문에 기본이 더 작게 시작하면 많은 차이가 있습니다.

모든 시스템 패키지 + CPAN + PyPI 모듈을 포함하는 이전 계층을 캐싱한다는 것은 대부분의 경우 설치된 작동하는 모듈을 업데이트하지 않기 때문에 업데이트의 마지막 계층에서 거의 변경되지 않아야 함을 의미합니다(내 bash-tools의 스크립트를

한동안 ARG를 변경하는 것과 같은 트릭을 사용하는 방법을 찾고 있었습니다(http://dev.im-bot.com/docker-select-caching/과 같은 블로그를 검색하여 얻은 아이디어).

Dockerfile에서:

ARG NOCACHE=0

그런 다음 다음과 같이 도커 빌드를 실행합니다.

docker build --build-arg NOCACHE=$(date +%s) ...

하지만 Docker Cloud에서는 이것이 가능하지 않다고 생각합니다.

환경 변수가 있지만 위의 epoch와 같은 동적 내용을 사용하는 것이 불가능한 것 같습니다(또는 적어도 내가 찾을 수 있는 문서화되지 않음). 환경 변수를 사용하면 해당 지시문 행에 대한 캐싱을 무효화할지 확신할 수 없습니다.

@thaJeztah 예, 이러한 종류의 행동은 잘못 ​​이해되거나 남용되면 쉽게 부정적인 결과를 초래할 수 있지만 특정 사용 사례를 매우 훌륭하게 해결할 수 있습니다.

--build-arg PASSWORD=<wrong> 는 --build-arg PASSWORD=<correct> 와 다른 결과를 생성할 수 있으므로 패키지 목록의 내용을 보는 것만으로도 효과가 있는지 확실하지 않습니다.

다른 결과를 생성한다는 것은 맞지만 패키지 목록이 변경되지 않았다면 암호가 맞든 틀리든 상관하지 않습니다. 패키지는 이미 이전 이미지에 있으므로 이를 실행하는 사용자는 이미 액세스 권한이 있으며(즉, 보안 문제가 아님) 이전에 암호가 잘못된 경우 Dockerfile 작성자가 설치에 실패할 부담이 있을 것으로 예상됩니다. 필요한 경우 비밀번호를 수정한 후에도 패키지를 올바르게 설치할 수 있는 기회가 계속 주어집니다.

예, docker build --force-cache-build-arg SECRET=supersecret 와 같은 것을 그리고 있었습니다. 그것은 꽤 투박합니다. 누군가가 더 나은 것을 생각해 낼 수 있다고 확신합니다.

@HariSekhon 당신의 유스 케이스는 실제로 나와 반대인 것처럼 들리지만 맞습니까? 당신은 선택적으로 힘이 캐시를 공격하기보다는, 선택적으로 힘 미스에 캐시 싶어?

이것을 추가하면 저에게 효과적이었습니다.

ADD http://date.jsontest.com/ /tmp/bustcache

하지만 그 사이트는 지금 다운되어 있습니다. 이것은 작동해야합니다

ADD http://api.geonames.org/timezoneJSON?formatted=true&lat=47.01&lng=10.2&username=demo&style=full /tmp/bustcache

@itdependsnetworks

완벽합니다. 좋은 해결 방법이며 사이트가 지금 백업되었습니다. 이미지의 빌드 날짜를 기록하는 것도 유용합니다.

나는 이것을 시도했고 유사한 다른 특수 파일이 매번 변경되어야 합니다.

COPY /dev/random ...

그러나 RUN ls -l -R /etc 가 그러한 파일이 존재한다고 표시했지만 항상 발견되지 않았음에도 작동하지 않았습니다. 특수 파일 사용에 대한 보호 장치가 있다고 생각합니다.

이제 DockerHub/Docker Cloud에 대해 더 많이 생각합니다. 사전 빌드 후크를 사용하여 날짜 스탬프가 포함된 파일을 생성한 다음 캐시 버스트하려는 레이어 바로 앞의 이미지에 복사하여 비슷한 결과를 얻을 수도 있습니다. 위에 표시된 것이 로컬 도커 및 클라우드 빌드에 더 이식성이 있다고 생각합니다.

우리는 이 캐시 무효화 해결 방법을 위해 더 안정적인 날짜 인쇄 사이트를 찾아야 합니다. 위의 두 가지 모두 데모인 것처럼 보이며 할당량이 있으므로 신뢰할 수 없고 빌드를 무작위로 중단합니다.

첫 번째 것은 항상 일일 할당량을 깨고 두 번째 것은 이제이 오류를 제공합니다.

{"status": {
  "message": "the daily limit of 20000 credits for demo has been exceeded. Please use an application specific account. Do not use the demo account for your application.",
  "value": 18
}}

모든 빌드에서 실행되고 출력이 마지막 빌드와 다른 경우 후속 레이어가 다시 빌드되는 도커 파일에 넣을 수 있는 지침을 갖는 것이 좋을 것이라고 생각합니다.

사용 예는 다음과 같습니다.

FROM something
... 
CACHE_BUST git ls-remote my-git-repo HEAD
RUN git clone --depth=1 my-git-repo ...
...
CMD ["my-cmd"]

위의 CACHE_BUST 명령에 있는 명령은 지정된 리포지토리의 HEAD에서 SHA를 출력합니다. 이렇게 하면 내 dockerfile이 리포지토리의 변경 사항에 따라 복제할지 여부를 알 수 있습니다.

여기의 모든 사용 사례는 위에서 볼 수 있듯이 비결정적 네트워크 관련 계층과 관련이 있습니다. 현재 여기에서 모든 요구 사항에 대해 ARG를 사용할 수 있지만 이는 dockerfile 자체만 유지 관리하는 것이 좋을 때 dockerfile을 사용하는 빌드 스크립트가 종종 필요하다는 것을 의미합니다. (게다가 일부 도구는 인수를 허용하지 않음)

현재 워크플로는 다음과 같습니다.

ARG SHA_TO_BUILD
RUN echo SHA_TO_BUILD
RUN git clone ...
...everything else reliant on that clone

$> ./build-my-image.sh $(get-latest-sha)

각 명령에 대해 캐싱을 켜고 끄는 것은 나쁜 생각이라고 생각합니다. 한 레이어를 다시 빌드해야 하는 경우 나머지 레이어도 다시 빌드해야 하는 방식으로 파일을 작성해야 합니다. 하지만 파일의 특정 지점에서 강제로 다시 빌드할 수 있는 것이 좋을 것이라고 생각합니다.

훌륭한 기능인데 왜 아직 보류 중입니까?

또 다른 사용 사례는 파일의 내용이 변경되었지만 Dockerfile 가 변경되지 않은 경우입니다.

예를 들어 COPY file.txt . 있고 file.txt 수정하면 Docker는 캐시된 이전 버전을 계속 사용합니다.

Docker가 복사한 파일의 체크섬을 수행하고 다음 번에 이를 사용하여 문제를 해결할 캐시된 계층을 사용해야 하는지 여부를 결정합니다.

지금 당장은 --no-cache 를 사용해야 하며 다운로드하고 필요한 것보다 더 많이 수행합니다(시간과 대역폭 낭비).

@brennancheung 그렇다면 버그입니다. 재현 가능한 단계가 있는 별도의 문제를 자유롭게 여십시오.

@brennancheung의 요점이라고 생각합니다.
https://github.com/brennancheung 은 예를 들어 다음과 같이 말합니다.
구성 파일(또는 이와 유사한 것)을 로드합니다. 당신은 할 필요가 없습니다
전체 응용 프로그램을 다시 설치하고 이러한 파일과 명령을 업데이트하기만 하면 됩니다.
그것과 관련된, 도커를 실행하고 짜잔, 시스템이 설정됩니다.
물론 종종 구성 파일을 끝 부분에 더 가깝게 둘 수 있습니다.
하지만 항상 그런 것은 아닙니다.

Am Mi., 20. März 2019 um 00:10 Uhr schrieb Tibor Vass <
알림@github.com>:

@brennancheung https://github.com/brennancheung 그렇다면,
그것은 버그입니다. 재현 가능한 단계가 있는 별도의 문제를 자유롭게 여십시오.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/1996#issuecomment-474666893 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ALBon0edO9m5BU3C5Ik2i__9eogZc1Jiks5vYaaNgaJpZM4BB_sR
.

--
티아고 로드리게스

이것을 시도했습니다 https://github.com/moby/moby/issues/1996#issuecomment -185872769

그러나 캐시의 정의뿐만 아니라 처음 사용 시/후 캐시에만 영향을 미칩니다.

https://docs.docker.com/engine/reference/builder/#impact -on-build-caching

Dockerfile이 이전 빌드와 값이 다른 ARG 변수를 정의하는 경우 정의가 아니라 처음 사용할 때 "캐시 누락"이 발생합니다.

@samstav "처음 사용" RUN 1 RUN ARG ( ARG 가 빌드 단계에 있는 경우).

ARG FOO=bar

FROM something
RUN echo "this won't be affected if the value of FOO changes"
ARG FOO
RUN echo "this step will be executed again if the value of FOO changes"

FROM something-else
RUN echo "this won't be affected because this stage doesn't use the FOO build-arg"

위의 내용은 차세대 빌더(BuildKit)를 사용하는 경우 약간 달라지므로 DOCKER_BUILDKIT=1 활성화하면 BuildKit이 최종 단계에 필요하지 않은 경우 빌드 단계를 건너뛸 수 있기 때문에(또는 빌드 단계를 건너뛸 수 있습니다) 완전히 캐시될 수 있는 경우)