day-log

CI에서 Docker 빌드 시간이 아깝다는 얘기를 최근에도 팀에서 몇 번 들었다. 로컬에선 5초 만에 끝나는데 GitHub Actions에서만 3분씩 걸리는, 그 짜증나는 상황. 오늘 알게 된 건 아니지만 의외로 모르는 분들 꽤 많더라. 짧게 정리해둔다.문제는 러너가 매번 새거라는 점BuildKit의 RUN --mount=type=cache는 원래 로컬에서 잘 돈다. 예를 들면 이런 식.# syntax=docker/dockerfile:1.7FROM node:20WORKDIR /appCOPY package*.json ./RUN --mount=type=cache,target=/root/.npm \ npm ciCOPY . .RUN --mount=type=cache,target=/app/node_modul..

CI에서 이미지 빌드가 답답할 때가 있다. Dockerfile에 COPY . . 한 줄 아래에 npm ci나 pip install을 넣어놨는데, 소스 하나만 바뀌어도 매번 의존성을 처음부터 다시 받는다. 결국 5분씩 걸리던 빌드가 CI 러너 열댓 대에서 동시에 돌면서 팀 전체 개발 흐름을 갉아먹는다. 이 글은 BuildKit의 --mount=type=cache를 CI 파이프라인에 어떻게 붙이는지, 그리고 ephemeral 러너 환경에서 캐시를 어떻게 살려두는지 정리한 가이드다. 실제로 우리 팀에서 프론트/백엔드 이미지 30여 개에 이걸 굴려보고 정리한 내용이다.왜 layer cache만으로는 부족한가BuildKit 없이도 Docker는 layer cache를 쓴다. RUN npm ci 라인이 바뀌지 않으..

지난 주 화요일 아침에 백엔드 팀장이 슬랙 DM으로 물어봤다. "요즘 CI가 왜 이렇게 느려요? 예전에는 8분이면 됐는데 요새는 20분 넘게 걸리는 것 같은데." 확인해보니 정말 그랬다. Go 서비스 하나의 build job이 12분에서 19분으로 늘어나 있었다. 뭐 변경한 것도 없는데.내가 저 CI를 마지막으로 만진 게 6월 초였다. --mount=type=cache를 붙여서 Go module 다운로드를 캐싱하도록 바꿨다. 그때는 확실히 빨라졌다. 첫 빌드가 14분, 두 번째부터는 5분대. 팀 슬랙에 자랑까지 했다. 그런데 한 달 반이 지난 지금은 20분이 나오고 있었다.처음엔 러너 탓인 줄 알았다첫 번째 추측은 GitHub Actions runner가 지역별로 느려졌나 하는 것이었다. 요새 self-..

BuildKit을 쓰기 시작한 지 꽤 됐다. DOCKER_BUILDKIT=1 넣는 건 이제 반사적으로 나온다. 그런데 얼마 전 팀 내부에서 "왜 RUN apt-get install이 캐시된 건 알겠는데, --mount=type=cache를 걸었을 때 도대체 뭐가 저장되고 뭐가 재사용되는 거냐"는 질문을 받고 답을 얼버무렸다. 그날 저녁에 소스와 문서를 뒤져가며 정리한 내용을 여기 남긴다.이 글은 실행 가이드는 아니다. BuildKit이 캐시를 어떻게 표현하고, 어디에 저장하고, 어떤 기준으로 재사용을 판단하는지 흐름을 따라간다. docker buildx build --cache-to=type=registry 를 쳤을 때 그 뒤에서 일어나는 일이 궁금한 사람이 대상이다.LLB — 캐시의 진짜 단위먼저 알아..

이거 모르는 분 꽤 많더라. RUN --mount=type=cache 한 줄로 npm/pip install 시간을 절반 이하로 줄일 수 있다. 그런데 실무에서 제대로 세팅한 걸 보기는 의외로 드물다.뭐가 문제냐기본 Dockerfile로 이미지 빌드하면, COPY package*.json ./ 다음에 RUN npm ci 하는 패턴을 쓸 거다. 여기서 lock 파일이 바뀌면 그 아래 레이어 캐시가 전부 무효화되고, npm ci가 처음부터 다시 돈다. 패키지 하나 추가했을 뿐인데 400개 다운로드를 다시 하는 셈이다.우리 팀은 프론트 모노레포에 workspace 20개가 물려 있는데, 어떤 워크스페이스 하나만 라이브러리 하나 올려도 CI 이미지 빌드가 3분 넘게 걸렸다. 노드 하나 이슈면 그러려니 하는데 매번..

COPY --link 얘기는 한 2년 전부터 컨퍼런스마다 단골 메뉴였다. "그냥 다 붙여라, 캐시 효율이 미친다"는 식의 글도 많고. 우리 팀도 어느 순간부터 거의 자동 반사처럼 모든 COPY 앞에 --link를 박아 넣고 있었다. 근데 최근에 좀 다른 얘기가 돌더라.올해 2월에 Depot 블로그에서 "왜 COPY --link 쓰지 말아야 하는지"라는 글이 올라와서 한 번 더 시끌시끌했다. 한 줄로 요약하면 "BuildKit이 --link 레이어를 다루는 방식 때문에 오히려 빌드가 느려지는 케이스가 꽤 있다"는 거. 우리 팀에서도 비슷한 케이스를 한 번 만난 적이 있어서 정리해둔다.--link가 손해 보는 케이스가장 흔한 패턴이 이거다.FROM node:20-alpine AS buildWORKDIR /a..

우리 팀은 Python/Node 기반 마이크로서비스를 20개 가까이 굴리고 있다. GitHub Actions에서 평일 기준 하루 PR 빌드가 200건 정도 도는데, 빌드 한 번에 평균 6~7분이 걸렸다. PR 하나 머지하려면 빌드 큐에서 한참 기다리는 게 일상이었고, 러너 비용은 매달 슬금슬금 올라갔다.근데 솔직히 빌드 로그를 들여다보면 절반 이상이 pip install, npm ci, apt-get install 단계였다. 매 빌드마다 pypi 미러에서 똑같은 패키지를 다시 받고 있던 거다. 결국 BuildKit cache mount을 제대로 깔고 나서 빌드 시간이 7분에서 평균 40초로 줄었다. 이 글은 그 과정에서 정리한 패턴이다.왜 일반 레이어 캐시로는 부족했나원래 Dockerfile에서 pip ..

오늘 PR 리뷰하다가 Dockerfile에서 발견한 게 있어서 짧게 적어둔다. CI 빌드 시간 길다고 투덜대는 동료가 있는데, 정작 Dockerfile에는 RUN apt-get install -y ... 한 줄만 덩그러니 있더라. cache mount를 안 쓰고 있었다.이게 좀 의외였다. Docker 18.09에서 BuildKit 들어온 게 한참 됐고, cache mount도 새 기능이 아닌데, 의외로 실무에서 안 쓰는 사람이 많다. 한번 적용하면 빌드 시간이 절반 이하로 떨어지는 걸 자주 본다.그래서 뭐하는 건데RUN --mount=type=cache,target=... 한 줄을 RUN 명령에 붙이면, BuildKit이 그 디렉토리를 빌드 간에 영속화해준다. 캐시 레이어가 깨져서 RUN을 다시 돌려도,..