Generator Dockerfile

Dlaczego budowanie wieloetapowe

Naiwny Dockerfile instaluje cały toolchain kompilatora w finalnym obrazie. Budowanie wieloetapowe daje etap “builder”, który kompiluje, oraz etap końcowy niosący tylko skompilowany artefakt:

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"]

Obraz końcowy pozbywa się wszystkich zależności programistycznych, plików źródłowych i cache budowania, często zmniejszając swój rozmiar o 60-80 procent.

Warianty obrazu bazowego

Szablony używają obrazów slim lub alpine, gdzie to możliwe. Jeśli samodzielnie dostosowujesz obraz bazowy, typowe opcje to:

Zasady cache warstw

Docker buforuje każdą linię; gdy zmienia się jedna warstwa, wszystko poniżej jest przebudowywane. Kolejność od najmniej do najbardziej zmiennej:

1. Obraz bazowy FROM (rzadko się zmienia).
2. Pakiety systemowe (apt-get install), rzadkie zmiany.
3. Manifesty zależności (package.json, requirements.txt, composer.json).
4. Etap instalacji zależności. Uruchamia się tylko, gdy zmienia się manifest.
5. Kopiowanie kodu źródłowego. Najbardziej obciążona warstwa; wszystko po niej jest przebudowywane przy każdym commicie.
6. Kompilacja i końcowy CMD.

Złamanie tej kolejności to najczęstsza przyczyna wolnych buildów CI.

Lista kontrolna bezpieczeństwa

• Uruchamiaj jako nie-root. Ustaw USER appuser (lub USER 1000) blisko końca.
• Przypinaj wersje. python:3.12.7-slim bije python:3.12, które bije python:latest.
• Ustaw jawny WORKDIR zamiast polegać na /.
• Używaj COPY, nie ADD do plików lokalnych; ADD ma skutki uboczne automatycznego rozpakowywania.
• Dodaj HEALTHCHECK, aby orkiestratorzy mogli wykryć zablokowany proces.
• Czyść cache pakietów w tej samej linii RUN: apt-get install ... && rm -rf /var/lib/apt/lists/*.