day-log

Dockerfile COPY --link, 다들 쓴다는데 진짜 좋을까

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 ..

지난 한 달 반 동안 우리 팀 컨테이너 이미지 베이스를 alpine에서 Wolfi로 거의 다 갈아치웠다. 처음엔 한 주 잡고 시작한 일이었는데, 막상 들어가보니 musl/glibc 차이부터 시작해서 빌드 캐시, CI 시간, 배포 호환성까지 줄줄이 엮여 있어서 결국 6주 가까이 걸렸다. 솔직히 시작할 때 알았으면 일정을 더 넉넉하게 잡았을 거다.이 글은 그 과정에서 마주친 문제들과 해결한 방법, 그리고 아직 풀지 못한 것들에 대한 기록이다.왜 옮겼나원래 우리는 거의 모든 서비스 베이스가 alpine:3.19 였다. 30MB도 안 되는 사이즈가 매력적이었고, 5년 가까이 큰 문제 없이 잘 써왔다. 근데 작년 4분기부터 보안팀이 들고 온 Trivy 리포트가 점점 두꺼워지기 시작했다. 특히 CVE 누적 속도가 ..

오늘 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을 다시 돌려도,..