Что произойдет, если в Dockerfile будет только инструкция FROM

Краткий ответ

Если в Dockerfile будет только инструкция FROM, Docker успешно создаст образ, который будет идентичной копией базового образа, указанного в FROM. Это абсолютно валидный, хотя и тривиальный, Dockerfile, который часто используется как основа для многоэтапных сборок или когда требуется немодифицированный базовый образ.

Подробное объяснение и последствия

Dockerfile — это пошаговая инструкция по сборке образа. Инструкция FROM является обязательной и должна быть первой (за исключением parser directives). Она задает базовый образ, от которого будет наследоваться сборка.

Что именно происходит

1. Скачивание базового образа: Docker ищет указанный образ локально. Если его нет, он загружает его из реестра (по умолчанию Docker Hub).
2. Инициализация нового слоя образа: Создается новый образ, история и файловая система которого начинаются с образа, указанного в FROM.
3. Установка метаданных: В метаданные нового образа записывается информация о базовом образе и команда FROM.
4. Фиксация образа: Поскольку других инструкций нет, процесс сборки завершается, и созданный образ помечается тегом, указанным в команде docker build.

Фактически, вы создаете "алиас" или точную копию исходного базового образа под новым именем (тегом).

Практический пример

Создадим файл Dockerfile с единственной строкой:

FROM alpine:latest

Теперь соберем образ:

docker build -t my-alpine .

Лог сборки будет очень кратким:

Sending build context to Docker daemon   2.56kB
Step 1/1 : FROM alpine:latest
latest: Pulling from library/alpine
Digest: sha256:c5b1261d6d3e43071626931fc004f70149baeba2c8ec672bd4f27761f8e1ad6b
Status: Downloaded newer image for alpine:latest
 ---> e66264b98777
Successfully built e66264b98777
Successfully tagged my-alpine:latest

Если сравнить идентификаторы образов, можно убедиться, что my-alpine и alpine:latest указывают на один и тот же слой (e66264b98777). Проверим:

docker images --digests | grep -E "(alpine|my-alpine)"

Сценарии использования такого Dockerfile

Несмотря на кажущуюся бесполезность, такая практика имеет применение:

1. Многоэтапные сборки (Multi-stage builds): Часто первый этап — это просто FROM для копирования артефактов.

   # Этап сборки (builder)
   FROM golang:1.21 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o myapp .
   
   # Финальный этап — используем только базовый образ и копируем бинарник
   FROM alpine:latest  # <-- Это "тривиальный" Dockerfile внутри многоэтапного
   COPY --from=builder /app/myapp /usr/local/bin/
   CMD ["myapp"]
   

2. Создание кастомного тега для базового образа: Для фиксации конкретной версии или использования во внутреннем реестре.

   FROM ubuntu:22.04@sha256:abc123...  # Фиксация по хэшу
   # Далее можно:
   # docker build -t mycompany/ubuntu-base:22.04 .
   

3. Тестирование "чистого" базового образа: Удобно для проверки поведения стандартного окружения.

4. Основа для автоматизированных сборок: CI/CD система может ожидать Dockerfile в репозитории. Простой FROM удовлетворяет этому требованию, позволяя в будущем легко добавлять инструкции.

Важные технические аспекты

• Размер образа: Размер итогового образа будет в точности равен размеру базового образа, так как не добавляется новых слоев.
• Кэширование: Docker отлично кэширует такую сборку, так как она состоит из одного неизменяемого шага.
• Контекст сборки: Контекст (папка с Dockerfile) все равно отправляется демону Docker, но не используется. Это можно считать небольшим издержками.
• Наследование: Итоговый образ наследует все метаданные базового:

    *   Переменные окружения (`ENV`)
    *   Рабочую директорию (`WORKDIR`)
    *   Точку входа (`ENTRYPOINT`/`CMD`)
    *   Открытые порты (`EXPOSE`)
    *   Метки (`LABEL`)
    *   И, конечно, всю файловую систему.

Вывод

Инструкция FROM в одиночестве формирует **ва