Что такое многоступенчатые сборки и почему их использовать?

Question

Accepted Answer

**Многоступенчатые сборки** используют несколько этапов `FROM` в одном Dockerfile — приложение собирается на одном этапе (со всеми инструментами сборки), а затем только финальные артефакты копируются в чистый, минимальный финальный этап. Это создает **намного меньшие, более безопасные** production-образы.

## Проблема: инструменты сборки раздувают образ

```text
Building an app needs build tools (compilers, dev dependencies, SDKs), but the
FINAL image shouldn't include them:
  → they bloat the image (larger size, slower deploys)
  → they increase the attack surface (more software = more vulnerabilities)
→ You want only the built artifact + its runtime in the final image.
```

## Многоступенчатая сборка

```dockerfile
# STAGE 1: "build" — has all the build tools (compile/bundle the app)
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install              # includes dev dependencies, build tools
COPY . .
RUN npm run build            # produces /app/dist

# STAGE 2: final — a clean, minimal image with ONLY the built artifact
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html   # copy ONLY the build output
# → the final image has NO build tools, no dev dependencies — just nginx + the built files
```

`--from=build` копирует артефакты из этапа сборки в финальный образ. Финальный образ **исключает все из этапа сборки, кроме того, что вы явно скопировали** — поэтому инструменты сборки, dev-зависимости и исходный код не попадают в production.

## Преимущества

```text
✓ SMALLER images — only the runtime + artifacts (often 10x+ smaller)
✓ More SECURE — fewer packages = smaller attack surface (no compilers/build tools)
✓ Faster deploys/pulls (smaller images transfer faster)
✓ One Dockerfile — build and final image together (no separate build scripts)
→ Common for compiled languages (Go, Rust, Java) and Node/frontend builds.
```

## Почему это важно

Понимание многоступенчатых сборок ценно для **создания небольших, безопасных production-образов**, поэтому это важное практическое знание для создания Docker-образов production-качества.

Проблема, которую она решает, реальна и распространена: сборка приложения требует **инструментов сборки** (компиляторы, SDK, dev-зависимости), которые **финальный production-образ не должен содержать** — их включение раздувает образ (больший размер, медленнее развертывание и загрузка) и увеличивает **поверхность атаки** (больше установленного ПО означает больше потенциальных уязвимостей). **Многоступенчатые сборки** решают эту проблему элегантно, используя несколько этапов `FROM`: приложение собирается на этапе со всеми инструментами, затем **копируются только финальные артефакты** (`--from=build`) в чистый, минимальный финальный этап, который исключает все остальное.

Это создает образы, которые **значительно меньше** (часто в 10 раз и больше — только runtime и артефакты) и **более безопасны** (нет инструментов сборки или ненужных пакетов для эксплуатации), при этом сохраняя все в одном Dockerfile (без отдельных скриптов сборки).

Этот паттерн стандартен для компилируемых языков (Go, Rust, Java, где компилятор не нужен во время выполнения) и для frontend/Node сборок (где инструменты сборки и исходный код не нужны в production).

Поскольку маленькие, безопасные production-образы важны для скорости развертывания, хранилища и безопасности, и поскольку многоступенчатые сборки — это стандартная, эффективная техника для их достижения (разделение среды сборки от худого runtime-образа), понимание многоступенчатых сборок — проблемы раздувания/безопасности, которые они решают, как они работают и их преимущества — это ценное, часто применяемое знание для создания Docker-образов production-качества, best practice, широко используемая в реальных Dockerfile'ах, и ключевой навык для создания эффективных, безопасных контейнеризованных приложений.