Для чего используется несколько инструкций FROM в Dockerfile?

Назначение нескольких инструкций FROM в Dockerfile

Использование нескольких инструкций FROM в одном Dockerfile стало возможным с внедрением функции мультистадийных сборок (multi-stage builds) в Docker версии 17.05. Это одна из наиболее важных и полезных возможностей в современных практиках контейнеризации, которая решает несколько ключевых проблем.

Решаемые проблемы

Основная цель — создание оптимизированных по размеру итоговых образов, устраняя при этом сложности в процессе сборки:

• Сокращение размера финального образа. Раньше приходилось использовать один базовый образ со всеми инструментами сборки (компиляторы, SDK, менеджеры пакетов), что приводило к огромным образам в сотни мегабайт, даже если само приложение весило мегабайты. Мультистадийная сборка позволяет отделить этап сборки от этапа выполнения.
• Повышение безопасности. В финальном образе остаются только необходимые для запуска артефакты и их зависимости. Удаляются инструменты сборки, промежуточные файлы, исходный код, что уменьшает поверхность для потенциальных атак.
• Упрощение Dockerfile. Исчезает необходимость в сложных сценариях очистки и объединения команд RUN для минимизации слоев в рамках одного образа.

Принцип работы и синтаксис

Каждая инструкция FROM начинает новую стадию сборки. Вы можете копировать артефакты из одной стадии в другую с помощью инструкции COPY --from.

# Первая стадия: "builder" — сборка приложения
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o myapp ./cmd

# Вторая стадия: финальный, минимальный образ
FROM alpine:latest
WORKDIR /root/
RUN addgroup -S appuser && adduser -S appuser -G appuser
USER appuser
# Копируем скомпилированный бинарник из стадии "builder"
COPY --from=builder /app/myapp .
CMD ["./myapp"]

В этом примере:

1. Первая стадия (builder) использует полный образ Go с компилятором и всеми инструментами. Здесь происходит загрузка зависимостей и компиляция приложения.
2. Вторая стадия использует минимальный образ alpine. В него копируется только готовый исполняемый файл myapp из первой стадии. Весь инструментарий Go (весом ~300-400 МБ) в финальный образ не попадает.

Дополнительные возможности использования

• Именование стадий. С помощью ключевого слова AS (как в примере выше: AS builder) стадиям присваиваются имена, что упрощает ссылки на них.
• Использование артефактов из любого предыдущего образа. Можно копировать файлы не только из именованных стадий текущего Dockerfile, но и из любых существующих образов:

  COPY --from=nginx:alpine /etc/nginx/nginx.conf /etc/nginx/nginx.conf
  

• Параллельная сборка независимых стадий. Docker может параллельно собирать стадии, которые не зависят друг от друга, ускоряя процесс.
• Использование разных базовых образов для разных задач. Например, одна стадия может использовать образ с Node.js для сборки фронтенда, а другая — образ с Python для бэкенда, а финальный образ будет объединять статические файлы и Python-приложение.

Важные аспекты

• Каждая стадия независима. Установленные пакеты, переменные окружения, рабочие каталоги из одной стадии не наследуются в следующую, если явно не скопированы.
• По умолчанию при сборке образа создается только последняя стадия. Чтобы сохранить промежуточный образ, его нужно явно тегировать при сборке (docker build -t myapp:builder --target builder .), указав целевую стадию через флаг --target.
• Это лучшая практика для производства. Мультистадийные сборки фактически стали стандартом для создания эффективных и безопасных образов производственного уровня.

Таким образом, несколько инструкций FROM — это не просто синтаксическая возможность, а мощный механизм, который кардинально улучшает жизненный цикл образов Docker, делая их легковесными, безопасными и удобными в сопровождении. Он отделяет "кухню" (процесс сборки) от "ресторана" (среды выполнения), поставляя клиенту только готовое "блюдо" (артефакт приложения).