Генератор 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"]

Финальный образ избавляется от всех dev-зависимостей, исходников и кэша сборки, часто уменьшая размер на 60-80 процентов.

Варианты базового образа

Шаблоны используют slim или alpine, где это возможно. Если вы настраиваете базовый образ сами, типичные варианты такие:

Правила кэширования слоёв

Docker кэширует каждую строку; когда слой меняется, всё, что ниже, пересобирается. Порядок от редко меняющегося к часто меняющемуся:

1. Базовый образ FROM (меняется редко).
2. Системные пакеты (apt-get install), редкие изменения.
3. Манифесты зависимостей (package.json, requirements.txt, composer.json).
4. Шаг установки зависимостей. Выполняется только при изменении манифеста.
5. Копирование исходников. Самый активный слой; всё после него пересобирается при каждом коммите.
6. Компиляция и финальный CMD.

Нарушение этого порядка - самая частая причина медленных сборок в CI.

Чек-лист безопасности

• Запускайте не от root. Поставьте USER appuser (или USER 1000) ближе к концу.
• Фиксируйте версии. python:3.12.7-slim лучше python:3.12, которое лучше python:latest.
• Задавайте явный WORKDIR вместо расчёта на /.
• Используйте COPY, а не ADD для локальных файлов; у ADD есть побочные эффекты автораспаковки.
• Добавляйте HEALTHCHECK, чтобы оркестраторы могли заметить зависший процесс.
• Очищайте кэш пакетов в той же строке RUN: apt-get install ... && rm -rf /var/lib/apt/lists/*.