Docker: багатоступеневі збірки для зменшення образів

Проблема важких образів

Якщо збирати і запускати застосунок в одному й тому самому образі, в продакшен разом із застосунком їдуть компілятор, dev-залежності та кеш збирача — десятки, а іноді сотні зайвих мегабайтів, які збільшують час деплою і розширюють поверхню атаки.

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

FROM node:20-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/main.js"]
``` Детальніше про суміжний підхід можна прочитати в матеріалі [«Kubernetes: основні об'єкти і коли він потрібен»](/devops/kubernetes-osnovni-ob-yekty-i-koly-vin-potriben).

![Від стадії збірки до фінального образу](/images/content/devops/docker-multistage-builds/diagram.png)

## Що переносити у фінальний образ

Багатоступенева збірка вирішує проблему розділенням на етапи: перший `FROM` збирає застосунок з усіма інструментами розробки, а фінальний `FROM` бере лише потрібні артефакти через `COPY --from=builder`, залишаючи компілятор і проміжні файли позаду.

Додатково варто використовувати `.dockerignore`, щоб не копіювати в контекст збірки папку `node_modules` чи `.git`, та слім-версії базових образів (`slim`, `alpine`) там, де це не конфліктує з потрібними системними бібліотеками. Ці ідеї перегукуються з темами [«Helm charts: пакування застосунків для Kubernetes»](/devops/helm-charts-pakuvannya-zastosunkiv-dlya-kubernetes) та [«Оптимізація N+1 запитів в ORM»](/databases/orm-n-plus-one).