Dockerfile 생성기

멀티스테이지 빌드의 이유

단순한 Dockerfile은 컴파일러 툴체인 전체를 최종 이미지에 설치합니다. 멀티스테이지 빌드는 컴파일을 담당하는 “builder” 스테이지와 컴파일된 산출물만 담는 최종 스테이지로 나눠 줍니다:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

최종 이미지에서 모든 개발 의존성, 소스 파일, 빌드 캐시가 빠져 이미지 크기가 60-80퍼센트 줄어드는 경우가 많습니다.

기본 이미지 종류

템플릿은 가능한 slim 또는 alpine 이미지를 사용합니다. 기본 이미지를 직접 조정한다면 대표적인 선택지는 다음과 같습니다:

레이어 캐시 규칙

Docker는 각 줄을 캐시하며, 레이어가 바뀌면 그 아래는 전부 다시 빌드됩니다. 변경 빈도가 낮은 순서는 다음과 같습니다:

1. FROM 기본 이미지 (거의 안 바뀜).
2. 시스템 패키지(apt-get install), 드물게 변경.
3. 의존성 매니페스트(package.json, requirements.txt, composer.json).
4. 의존성 설치 단계. 매니페스트가 바뀔 때만 실행.
5. 소스 코드 복사. 가장 바쁜 레이어로, 이후는 커밋마다 다시 빌드.
6. 컴파일과 최종 CMD.

이 순서를 어기는 것은 CI 빌드가 느려지는 가장 흔한 원인입니다.

보안 체크리스트

• 비루트로 실행하기. 끝부분에 USER appuser(또는 USER 1000)를 지정.
• 버전 고정하기. python:3.12.7-slim이 python:3.12보다 낫고, 이는 python:latest보다 낫습니다.
• /에 의존하지 말고 명시적 WORKDIR 설정하기.
• 로컬 파일에는 ADD가 아닌 COPY 사용하기. ADD는 자동 압축 해제 부작용이 있습니다.
• HEALTHCHECK를 추가해 오케스트레이터가 멈춘 프로세스를 감지하게 하기.
• 패키지 캐시는 같은 RUN 줄에서 정리하기: apt-get install ... && rm -rf /var/lib/apt/lists/*.