Docker 빌드 시간을 40% 단축한 방법 (번역)

docker에서 최초로 빌드를 할 때에 오랜 시간이 걸린 경험이 있었습니다. 이후 추가로 이미지를 빌드하면 레이어가 쌓이면서 속도가 처음 보다는 줄기는 합니다. 다수의 베이스 이미지를 사용하다 보면 속도와 용량이 기하급수적으로 커지기도 했었습니다. 이번 글에서는 medium에서 Niels Claeys의 How we reduced our docker build times by 40% 를 읽고 정리해 보았습니다. 빌드 캐시 정보를 원격으로 저장하고, link 옵션을 활용해서 빌드 시간을 40% 가까이 단축했다는 흥미로운 이야기입니다!
 

배경

• 제품에 사용되는 모든 구성요소에 대한 도커 이미지 구축
• CI 빌드 시간이 5분 이상 걸리지 않는 것이 목표(커피 한 잔 할 정도의 이상적 길이)
• 5분 이상 걸리면 생산성이 저하

생산성 저하의 원인

• 개발자는 빌드가 완료될 때까지 기다려야 하는 시간 낭비
• 새로운 작업을 시작했다가 나중에 다시 돌아오는 것은 컨텍스트 전환에 비효율 초래

 
개선 사항에 대해 알아보기 전에 best practices for writing Dockerfile 내용을 이미 따르고 있는지 확인하세요.

• minimize the number of layers
• use multistage builds
• use a minimal base image
• …

Buildkit과 Buildx

Buildkit

기존 Docker Builder를 대체하는 개선된 백엔드. (도커 엔진 23.0부터 기본 빌더)

• 개선된 캐싱 기능
• 레이어 병렬 빌드 기능
• 기본 이미지의 lazy pulling (≥ Buildkit 0.9)

Builkit을 사용하면 docker build 명령의 출력이 깔끔하고 구조적으로 보입니다.
 
버전 23.0 이전의 Docker를 사용하는 경우 Buildkit을 사용하기 위해 아래와 같이 Buildkit 파라미터를 아래처럼 설정하세요

DOCKER_BUILDKIT=1 docker build --platform linux/amd64 . -t someImage:someVersion
DOCKER_BUILDKIT=1 docker push someImage:someVersion

Buildx 

Buildx는 Docker의 플러그인으로 Buildkit의 모든 잠재력을 활용할 수 있게 합니다. 새로운 configuration option들이 Buildkit에서 지원되지만, 이전 버전의 docker build 명령어에 역호환 방식으로 통합되기 어려워서 개발된 플러그인입니다.
 
이미지를 빌드하는 것 외에도 Buildx는 여러 빌더를 관리하는 기능을 지원합니다. (CI에서 스코프가 지정된 환경을 정의하는 데 유용) 공유 Docker 데몬을 수정하지 않고도 여러 빌더를 관리할 수 있습니다.
 
Buildx를 사용하기 위해서는 아래와 같이 사용하세요.

docker buildx create --bootstrap --name builder
docker buildx use builder

 

remote cache의 이점

이미지를 원격 레지스트리에 캐시하여 빌드 속도를 높입니다. CI에서 다른 컴퓨터 환경에서 빌드를 실행할 때에도 빌드 캐시 활용이 가능합니다. 이미지의 최신 버전을 가져와서 로컬에 캐시해서 빌드 프로세스를 가속화합니다. (새로운 이미지를 빌드할 때 변경되지 않은 레이어를 다시 다운로드하지 않고도 로컬에서 캐시 사용)

docker pull someImage:latest || true
docker build --platform linux/amd64 . \
-t someImage:someVersion \
-f Dockerfile \
--cache-from someImage:latest

 
Buildx를 사용하면 캐시 정보를 원격 저장소에 저장 가능 합니다.(ex. container registry, blob storage, ..)
빌더는 특정 레이어의 존재 여부를 확인하고, 존재한다면 재사용합니다.
  → 이 작업은 로컬로 레이어를 가져오지 않고도 수행 가능.
 
`--push` 부분부터 변경된 명령어를 살펴봅니다.

docker buildx build --platform linux/amd64 . \
-t someImage:someVersion --push \
--cache-to type=registry,ref=someCachedImage:someVersion,mode=max \
--cache-from type=registry,ref=someCachedImage:someVersion

 
`max` 모드는 최종 이미지에 사용되지 않는 레이어를 포함해서, 모든 레이어에 대한 빌드 정보를 저장합니다.(ex. multi stage build)
  → 기본적으로는 'min' 모드를 사용해서 최종 이미지에 필요한 레이어에 대한 빌드 정보 저장
 
캐싱의 특별한 경우는 캐시 데이터를 이미지와 함께 `inline`으로 저장하는 옵션입니다. Buildx 없이 Buildkit을 사용할 때에도 지원합니다. 다중 스테이지 빌드를 사용할때 더 복잡하고, 아티팩트 출력과 캐시간에 명확한 분리를 제공하지 않습니다. inline 옵션으로 사용하고 싶다면 아래 명령어를 사용합니다.

docker buildx build - platform linux/amd64 . \
-t someImage:someVersion --push \
--cache-to type=inline,mode=max \
--cache-from someImage:somePreviousVersion

Docker 이미지에 파일을 추가하는 새로운 방법

도커에서는 도커 파일을 작성하기 위한 새로운 문법을 소개했습니다.`#syntax=docker/dockerfile:1.4`
COPY, ADD 명령에 대한 추가 옵션을 지원합니다.
 
이전에는 COPY 또는 ADD 명령을 사용하면 빌더가 새 스냅샷을 생성하여 새 파일을 기존 파일 시스템과 병합합니다.

• 이 작업을 수행하려면 상위 레이어가 모두 존재해야 함
• 이미지(빌드 명령의 결과)는 각 스냅샷 간의 차이점을 포함하는 레이어당 tarball 파일들로 구성

FROM baseImage:version
COPY binary /opt/

 
link 옵션을 사용하면 이전 레이어에 의존하지 않고 새 파일이 자체 스냅샷에 저장합니다.
링크된 파일은 자체 tarball에 저장되고, 아래처럼 기존 파일 시스템에 의존하지 않고 다른 tarball이 함께 링크 됩니다.

https://www.docker.com/blog/image-rebase-and-improved-remote-cache-support-in-new-buildkit/

# syntax=docker/dockerfile:1.4
FROM baseImage:version
COPY [--chown=<user>:<group>] [--chmod=<perms>] --link binary /opt/

이 방식의 가장 큰 장점은 파일이 더 이상 이전 레이어에 종속되지 않는다는 점입니다.
(상위 레이어가 변경 되더라도 파일이 변경되지 않는 한 레이어 재사용 가능)
또한 데이터를 복사하는 여러 레이어를 병렬로 실행할 수 있기 때문에 빌드 속도의 향상도 기대할 수 있습니다.

결론

CI 파이프라인 최적화를 하며 얻은 몇 가지 통찰에 대해 이야기 했습니다. 전체 도커 빌드 시간을 40% 단축하는 데에 도움이 되었던 적용 내용들은 아래와 같습니다.

• 빌드 캐시 정보를 원격 저장
• Docker 이미지에 파일 추가, 복사할 때 link 옵션 사용