https://depot.dev/blog/differences-between-qemu-and-cloud-hypervisor

Docker Build Cache 핵심 정리

1. 레이어 구조 기본 개념

Dockerfile의 각 instruction은 빌드 시 순서대로 실행되며, 결과물은 두 가지로 나뉩니다.

각 레이어는 이전 레이어 대비 변경된 부분만 저장 depot하고, 컨테이너 실행 시 이 레이어들을 순서대로 쌓아 하나의 통합 파일시스템을 만듭니다.


2. Build Cache 동작 원리

첫 빌드에서는 모든 작업을 수행하고 캐시에 기록하며, 이후 빌드에서는 이전 빌드와 비교하여 변경이 없으면 재사용, 변경이 있으면 해당 지점부터 재실행 depot합니다.


3. Cache Invalidation (핵심!)

변경된 instruction이 발견되면, 그 이후의 모든 instruction도 전부 재빌드됩니다. 레이어가 이전 레이어에 의존하는 구조이기 때문입니다.

instruction 타입별 캐시 판단 기준이 다릅니다:

Instruction 타입 캐시 판단 기준
ENV, CMD, WORKDIR instruction 문자열 변경 여부
COPY, ADD 대상 파일의 체크섬 (mtime 변경은 무시)
RUN instruction 문자열만 확인, 외부 리소스 변경은 감지 못함

RUN 관련 주의점: RUN apt-get update는 instruction 문자열이 동일하면 캐시를 재사용하므로, 새 패키지가 릴리즈되어도 반영되지 않습니다. depot 이를 해결하려면 --build-arg로 캐시 무효화하거나, apt-get update && apt-get install을 한 줄로 합치는 방식을 씁니다.


4. 최적화 Best Practices

① Dockerfile instruction 순서: 변경 빈도 낮은 것 → 높은 것