Сборка и сопровождение контейнерных образов

Контейнеризация становится практически полезной не в тот момент, когда среда исполнения умеет запускать изолированные процессы, а тогда, когда приложение можно упаковать в воспроизводимый и управляемый артефакт. Таким артефактом в экосистеме Docker является образ (image). Именно образ фиксирует состав файлов, системных библиотек, прикладных зависимостей и параметры запуска, которые затем используются при создании контейнера. Поэтому качество сопровождения контейнерной среды напрямую зависит от того, насколько дисциплинированно организован процесс сборки образов.

На начальном этапе изучения контейнеров образ иногда воспринимают как «снимок» работающей системы. Такое представление отчасти полезно интуитивно, но методически оно недостаточно. Современная практика исходит не из ручного сохранения состояния, а из декларативного описания сборки. Образ должен получаться не в результате последовательности нефиксируемых действий администратора, а на основе формального сценария, который можно повторить, проверить и встроить в цепочку поставки программного обеспечения. В этой связи сборка контейнерного образа является не только технической процедурой, но и элементом инженерной дисциплины.

В рамках данной темы важно различать две взаимосвязанные задачи. Первая состоит в конструировании образа как исполнимого артефакта. Вторая связана с его сопровождением: версионированием, повторной сборкой, публикацией, обновлением и контролем состава. Если эти задачи решаются несистемно, контейнеризация теряет одно из своих главных преимуществ — предсказуемость поведения приложения в разных средах. Поэтому дальнейшее изложение сосредоточено не только на синтаксисе Dockerfile, но и на принципах, которые делают образ пригодным для учебной и производственной эксплуатации.

Dockerfile как декларативное описание образа

Основным средством описания процесса сборки в Docker является файл Dockerfile. Он задаёт последовательность инструкций, на основе которых система сборки формирует новый образ. Каждая инструкция изменяет состояние промежуточной файловой системы или задаёт метаданные, необходимые для последующего запуска контейнера. В этом смысле Dockerfile выполняет роль спецификации: он не просто перечисляет команды, а фиксирует, каким должен быть результат сборки.

Декларативный характер Dockerfile не означает отсутствия пошаговой логики. Напротив, порядок инструкций имеет принципиальное значение. Сборка обычно начинается с инструкции FROM, которая определяет базовый образ (base image). Базовый образ задаёт исходную среду: тип дистрибутива, набор системных библиотек, иногда интерпретатор языка программирования или среду выполнения. Выбор базового образа влияет на размер итогового артефакта, совместимость приложения, доступность инструментов диагностики и поверхность потенциальных уязвимостей. Поэтому выбор «самого маленького» образа не всегда является лучшим решением: чрезмерное упрощение может затруднить сопровождение и отладку.

После выбора базового образа в Dockerfile задаются операции подготовки среды. Инструкции RUN используются для выполнения команд в процессе сборки, например для установки пакетов, компиляции исходного кода или формирования каталогов приложения. Инструкция COPY переносит файлы из контекста сборки внутрь образа, а ADD выполняет сходную функцию, но обладает дополнительными возможностями, которые без необходимости часто использовать не рекомендуется, поскольку это усложняет предсказуемость сборки. Инструкции ENV, WORKDIR, EXPOSE, CMD и ENTRYPOINT определяют параметры окружения, рабочий каталог, сетевые намерения и поведение контейнера при запуске. Важно понимать, что Dockerfile объединяет как операции подготовки файловой системы, так и описание будущего режима исполнения.

Это различие удобно свести в таблицу. Одни инструкции изменяют файловую систему и порождают новый слой, другие лишь записывают поле в конфигурацию образа — JSON-документ, который среда выполнения читает при создании контейнера ¹⁷.

Пример базового Dockerfile для веб-приложения

Рассмотрим упрощённый пример Dockerfile для небольшого приложения на Python:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

ENV PORT=8000
EXPOSE 8000

CMD ["python", "app.py"]

В этом примере инструкция FROM задаёт базовую среду с интерпретатором Python. Инструкция WORKDIR определяет рабочий каталог внутри образа и в дальнейшем делает каталог /app текущей рабочей директорией для последующих инструкций. Это означает, что относительные пути в COPY, RUN и CMD далее интерпретируются уже с учётом каталога /app, если не указан иной абсолютный путь.

Для правильного понимания примера необходимо пояснить, что такое контекст сборки. Когда пользователь запускает команду вида docker build ., точка в конце означает, что контекстом сборки становится текущий каталог на машине пользователя. Именно из этого каталога Docker может брать файлы для инструкций COPY и ADD. Следовательно, Docker не копирует файлы произвольно из всей файловой системы хоста, а работает только с тем набором данных, который был передан ему как контекст. Если нужный файл находится вне контекста, инструкция COPY не сможет его использовать без изменения структуры проекта или явного выбора другого контекста.

Инструкция COPY requirements.txt . читается слева направо: сначала указывается источник в контексте сборки, затем назначение внутри образа. В данном случае Docker берёт файл requirements.txt из корня контекста сборки на хостовой машине и копирует его в текущий рабочий каталог внутри образа, то есть в /app/requirements.txt. После этого инструкция RUN pip install --no-cache-dir -r requirements.txt выполняется уже внутри промежуточного контейнера сборки и использует только что скопированный файл зависимостей. Такое разбиение имеет практический смысл: если исходный код приложения изменится, но файл requirements.txt останется прежним, Docker сможет повторно использовать уже собранный слой с установленными пакетами.

Инструкция COPY . . требует отдельного пояснения, поскольку запись с двумя точками часто интерпретируется неверно. Первая точка обозначает источник, то есть весь текущий контекст сборки на стороне хоста, за исключением файлов, исключённых через .dockerignore. Вторая точка обозначает каталог назначения внутри образа, то есть текущий рабочий каталог /app. Иными словами, после выполнения этой инструкции файлы проекта из локального каталога пользователя переносятся внутрь файловой системы образа в каталог /app. Если в проекте присутствуют, например, app.py, каталог templates/ и файл config.yaml, то при отсутствии исключений они будут скопированы в /app/app.py, /app/templates/ и /app/config.yaml.

Наконец, CMD задаёт команду, которая будет выполнена при запуске контейнера по умолчанию. В рассматриваемом случае это команда python app.py, выполняемая в каталоге /app, где уже находятся скопированные файлы приложения и установленные зависимости.

Этот пример также показывает типичное ограничение Dockerfile. Инструкция EXPOSE не публикует порт во внешнюю сеть сама по себе, а лишь документирует намерение приложения использовать соответствующий порт внутри контейнера. Реальный проброс порта на хост задаётся уже при запуске контейнера. Если смешивать эти два уровня, можно ошибочно считать Dockerfile средством полного описания развертывания, хотя он описывает только образ и типовой режим его исполнения.

Разницу легко наблюдать. Образ из примера выше содержит EXPOSE 8000, но после запуска без ключа -p порт хоста не открыт; ключ -p 8080:8000 публикует порт 8000 контейнера на порту 8080 хоста, а ключ -P публикует все объявленные через EXPOSE порты на случайные свободные порты хоста — это единственное место, где EXPOSE влияет на поведение ¹:

docker run -d --name a demo:1.0             # порт 8000 доступен только изнутри сети Docker
docker run -d --name b -p 8080:8000 demo:1.0
docker run -d --name c -P demo:1.0
docker port c

8000/tcp -> 0.0.0.0:32768
8000/tcp -> [::]:32768

Сама переменная ENV PORT=8000 тоже не связана с EXPOSE: приложение слушает тот порт, который прочитало из окружения, а EXPOSE лишь сообщает об этом читателю образа. Если изменить одно, не изменив другое, документация разойдётся с поведением. Устройство публикации портов (правила NAT, мост docker0) рассматривается в теме 6.

Пример минимального Dockerfile для статического содержимого

Если приложение не требует собственной среды выполнения, Dockerfile может быть значительно проще. Например, для публикации статического сайта достаточно использовать готовый веб-сервер:

FROM nginx:1.28-alpine

COPY site/ /usr/share/nginx/html/

EXPOSE 80

Здесь образ не содержит этапов установки прикладных зависимостей, потому что они не нужны. Используется готовый сервер nginx, а задача сборки сводится к копированию статических файлов в каталог, из которого сервер отдаёт содержимое. Этот пример полезен методически, поскольку показывает: Dockerfile должен описывать только те действия, которые действительно необходимы для конкретного артефакта. Попытка сделать любой Dockerfile одинаково сложным приводит не к универсальности, а к избыточности.

С методической точки зрения существенна разница между образом как продуктом сборки и контейнером как объектом времени выполнения. Dockerfile описывает образ, но не фиксирует все аспекты будущего запуска. Например, ограничения ресурсов, сетевые подключения и подключение томов обычно задаются на этапе создания контейнера, а не на этапе сборки. Если смешивать эти уровни, возникает неверная интерпретация назначения Dockerfile. Он должен содержать только те сведения, которые характеризуют сам артефакт и его типовое поведение, а не частную конфигурацию конкретного развертывания.

Практический смысл Dockerfile состоит также в том, что он превращает упаковку приложения в повторяемую процедуру. Вместо того чтобы вручную устанавливать зависимости и копировать файлы на сервер, разработчик или инженер сопровождения описывает эти действия в явном виде. Затем одна и та же инструкция сборки может быть выполнена локально, в системе непрерывной интеграции и в учебной лаборатории. Отсюда вытекает локальный вывод: Dockerfile следует рассматривать как часть исходного кода проекта, а не как вспомогательный побочный файл.

Контекст сборки и структура входных данных

Корректность образа определяется не только содержимым Dockerfile, но и тем набором файлов, который передаётся системе сборки. Этот набор называется контекстом сборки (build context). Когда запускается сборка, Docker получает доступ к каталогу проекта или другой указанной директории и может использовать находящиеся в ней файлы в инструкциях COPY и ADD. Если в контекст включены лишние данные, например локальные артефакты сборки, временные файлы, каталоги зависимостей или секреты, они могут не только увеличить размер передаваемых данных, но и случайно попасть в образ.

По этой причине важную роль играет файл .dockerignore. Его назначение сходно с назначением .gitignore, но задача иная: исключить из контекста сборки всё, что не должно участвовать в формировании образа. Типичная ошибка начинающих состоит в том, что они копируют в образ весь каталог проекта без анализа его состава. В результате в образ попадают тестовые данные, журналы, кэши пакетных менеджеров, конфиденциальные файлы среды разработки и иные объекты, не относящиеся к приложению. Такая практика противоречит принципу минимально необходимого состава артефакта.

Синтаксис .dockerignore — по одному шаблону в строке, с подстановками *, ** и отрицанием !; шаблоны применяются к путям относительно корня контекста, а более поздняя строка перекрывает более раннюю ⁶. Для Python-проекта типичный файл выглядит так:

# служебные каталоги и кэши
.git
__pycache__/
**/*.pyc
.venv/
.pytest_cache/
# локальные артефакты и данные
dist/
*.log
data/
# секреты среды разработки
.env
*.pem
# исключение из исключения: пример конфигурации нужен в образе
!config.example.yaml

Исключение через .dockerignore действует до копирования: исключённый файл не передаётся системе сборки вообще, поэтому никакая инструкция COPY его не увидит. Это принципиально надёжнее, чем удаление файла поздней инструкцией RUN rm, которое, как будет показано в следующем разделе, не убирает данные из нижних слоёв.

BuildKit и передача контекста

Начиная с Docker Engine 23.0 сборку по умолчанию выполняет BuildKit — подсистема сборки, заменившая прежний встроенный сборщик (англ. legacy builder); команда docker build в современных версиях является псевдонимом docker buildx build ². BuildKit не исполняет Dockerfile строка за строкой. Сначала Dockerfile переводится в граф низкоуровневых операций LLB (англ. low-level build), в котором вершины — шаги сборки, а рёбра — зависимости между ними. Затем граф исполняется: независимые вершины (например, две стадии многоэтапной сборки, не зависящие друг от друга) выполняются параллельно, а стадии, от которых не зависит итоговая, вообще пропускаются.

Изменился и порядок передачи контекста. Прежний сборщик перед первой инструкцией упаковывал весь каталог в архив и отправлял его демону, сообщая об этом строкой Sending build context to Docker daemon. BuildKit передаёт контекст синхронизацией файлов: при повторной сборке отправляются только изменившиеся файлы, а в выводе передача видна как шаг [internal] load build context. Для каталога, в котором лежит лишний файл размером 50 МиБ, вывод в режиме --progress=plain выглядит так:

docker build --progress=plain -t demo:1.0 .

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 213B done
#1 DONE 0.0s
...
#4 [internal] load .dockerignore
#4 transferring context: 2B done
#4 DONE 0.0s
...
#6 [internal] load build context
#6 transferring context: 52.43MB 0.6s done
#6 DONE 0.7s
...
#8 [3/5] COPY requirements.txt .
#8 CACHED

Строка transferring context: 52.43MB — это 50 МиБ (52 428 800 байт) лишнего файла плюс несколько килобайт исходного кода. После добавления файла в .dockerignore она сокращается до сотен байт. Метка CACHED у шага означает, что результат взят из кэша сборки; механизм кэша разобран в разделе о кэшировании. Первая строка Dockerfile вида # syntax=docker/dockerfile:1 указывает BuildKit, какую версию синтаксического анализатора (фронтенда) использовать; она нужна, чтобы новые возможности вроде RUN --mount работали одинаково на разных версиях Docker ¹.

Контекст сборки имеет и эксплуатационный аспект. Чем больше его объём, тем медленнее сборка и тем выше вероятность, что несущественные изменения в одном из файлов нарушат кэширование последующих шагов. Следовательно, сопровождение образа начинается ещё до выполнения первой инструкции Dockerfile: инженер должен определить, какие именно исходные материалы являются частью поставки, а какие должны оставаться вне её границ. Этот вопрос связывает процесс контейнеризации с общей культурой управления проектом и конфигурацией репозитория.

Слои образа и логика пошаговой сборки

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

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

Следует учитывать, что слой не является независимым контейнером или самостоятельной файловой системой в полном смысле. Он представляет собой набор различий по отношению к предыдущему состоянию. Поэтому удаление файла на позднем этапе не означает, что соответствующие данные физически не присутствуют в нижележащих слоях. Этот момент особенно важен для безопасности и оптимизации. Если секретный файл был скопирован в образ на одном шаге, а затем удалён на следующем, его след может сохраниться в истории слоёв. Из этого вытекает важное ограничение: нежелательные данные нельзя сначала включать в сборку с расчётом на их последующее удаление.

Понимание слоистой структуры позволяет корректно интерпретировать и размер образа. Итоговый объём определяется не только «видимым» содержимым файловой системы контейнера, но и историей изменений, накопленных в слоях. Поэтому рациональная организация шагов сборки является одновременно вопросом производительности, безопасности и эксплуатационной ясности.

Кэширование и воспроизводимость сборки

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

Более фундаментальным требованием является воспроизводимость. Под воспроизводимостью в данном контексте понимается способность получить функционально эквивалентный образ при повторном выполнении одной и той же процедуры сборки. Абсолютная двоичная идентичность в практических условиях достигается не всегда, поскольку на результат могут влиять временные метки, внешние источники пакетов и детали компиляции. Тем не менее инженерная цель состоит в том, чтобы минимизировать число нефиксированных факторов, от которых зависит результат.

Нарушение воспроизводимости часто связано с несколькими типичными причинами. Во-первых, используются плавающие версии зависимостей, когда при каждой сборке пакетный менеджер получает потенциально новый состав библиотек. Во-вторых, в Dockerfile включаются операции, зависящие от текущего времени, внешнего состояния сети или изменяющихся удалённых ресурсов без фиксации конкретных версий. В-третьих, сборка опирается на локальные, неформализованные предпосылки: существование файла в рабочем каталоге, который не включён в репозиторий, особенности конфигурации хоста или неявные секреты среды. Подобные зависимости особенно опасны в учебных и командных проектах, поскольку делают результат неустойчивым к переносу.

Следовательно, при проектировании Dockerfile необходимо стремиться к явной фиксации входных условий. Версии базового образа должны задаваться осмысленно, зависимости приложения должны устанавливаться на основе контролируемых описаний, а контекст сборки должен содержать только то, что действительно требуется для получения результата. Практическое значение этого принципа проявляется при сопровождении: если образ можно собрать только на одном рабочем месте и только у одного участника команды, такой артефакт нельзя считать надёжно сопровождаемым.

Кэширование и воспроизводимость связаны между собой, но не совпадают. Инструкция, максимально оптимизированная для повторного использования кэша, может оставаться плохо воспроизводимой, если она опирается на изменчивый внешний ресурс. И наоборот, воспроизводимая сборка может выполняться медленнее, если её шаги организованы нерационально. Поэтому инженер должен учитывать оба критерия одновременно и принимать компромиссные решения осознанно.

Как BuildKit решает, можно ли взять шаг из кэша

Ключ кэша шага вычисляется из ключа предыдущего шага и из собственных входных данных шага ³. Отсюда главное правило: как только один шаг выполнен заново, все последующие шаги той же стадии тоже выполняются заново, даже если их собственные входные данные не изменились. Что именно считается входными данными, зависит от инструкции.

Рассмотрим числовой пример. Пусть в Dockerfile пять шагов: FROM (из кэша), COPY requirements.txt ., RUN pip install (45 с, 30 пакетов), COPY . . (0,1 с) и метаданные. Разработчик меняет одну строку в app.py. При порядке «сначала зависимости, потом код» ключи шагов 2 и 3 не изменились, заново выполняется только COPY . ., и пересборка занимает около секунды. Если же поставить COPY . . перед pip install, изменившийся app.py меняет ключ копирования, а за ним и ключ установки зависимостей: каждая правка кода стоит 45 с. За рабочий день из 40 пересборок это 30 минут ожидания против одной минуты. Схема на рисунке ниже показывает, на каком шаге в каждом из вариантов обрывается цепочка попаданий в кэш.

Кэш сборки хранится там, где работает BuildKit, — на хосте Docker. Новая машина системы непрерывной интеграции начинает с пустым кэшем; BuildKit умеет экспортировать кэш в реестр или в каталог и импортировать его при следующей сборке (--cache-to, --cache-from) ³.

Монтирования на время шага: RUN --mount

Слой фиксирует всё, что шаг RUN оставил в файловой системе. Из-за этого возникают две противоположные проблемы: кэш пакетного менеджера раздувает образ, если его не удалить, и скачивается заново при каждой сборке, если удалить. Секрет, нужный для доступа к закрытому репозиторию, нельзя ни скопировать в образ, ни передать через ARG или ENV — значения последних остаются в истории и конфигурации образа. BuildKit решает обе задачи монтированиями, которые существуют только во время выполнения одного шага и не попадают в слой ¹⁵:

# syntax=docker/dockerfile:1
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt requirements-private.txt ./
# кэш pip живёт между сборками на хосте сборки, но не попадает в слой
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt
# секрет доступен как файл /run/secrets/pip_index только во время этого шага
RUN --mount=type=secret,id=pip_index \
    PIP_INDEX_URL="$(cat /run/secrets/pip_index)" pip install -r requirements-private.txt

docker build --secret id=pip_index,src=$HOME/.config/pip_index_url -t demo:1.1 .

Кэш-монтирование ускоряет пересборку, но не участвует в ключе кэша: если шаг RUN взят из кэша сборки, монтирование не понадобится вовсе. Поэтому оно не заменяет правильный порядок инструкций, а дополняет его — ускоряет именно те пересборки, которые всё-таки пришлось выполнить.

Практика написания Dockerfile и типичные ошибки

Несмотря на кажущуюся простоту синтаксиса, Dockerfile легко превращается в набор механически перенесённых команд из локальной инструкции развертывания. Такой подход ошибочен, потому что контейнерная сборка требует проектирования. Необходимо различать этапы, которые относятся к подготовке приложения, и этапы, которые должны выполняться уже после запуска контейнера. Например, миграции схемы базы данных, если они зависят от доступности внешнего сервиса, не всегда корректно помещать в стадию сборки образа. Сборка должна давать переносимый артефакт, а не пытаться решать все задачи будущей эксплуатации заранее.

Одна из распространённых ошибок связана с созданием чрезмерно универсального образа, который содержит инструменты разработки, компиляторы, тестовые утилиты и средства диагностики, хотя в реальном запуске требуется только приложение и его минимальные зависимости. Такой образ удобен на коротком отрезке обучения, но в долгосрочной перспективе он увеличивает размер поставки, расширяет поверхность атаки и затрудняет анализ состава. Противоположная крайность также нежелательна: чрезмерно «обрезанный» образ может затруднить диагностику ошибок и сопровождение. Отсюда следует, что выбор состава образа должен учитывать назначение среды: разработка, тестирование, обучение или эксплуатация.

Ещё одна типичная ошибка состоит в объединении несвязанных команд в одну длинную инструкцию RUN исключительно ради уменьшения числа слоёв. Формально это может уменьшить историю изменений, но ухудшает читаемость, затрудняет сопровождение и делает диагностику сбоев менее прозрачной. Сокращение числа слоёв не должно становиться самоцелью. Более правильный подход заключается в логическом группировании действий: в пределах одного шага объединяются тесно связанные операции, а между шагами сохраняется понятная структура.

Есть случай, когда объединение обязательно, и его следует отличать от объединения ради числа слоёв. Это установка системных пакетов ⁴:

RUN apt-get update \
 && apt-get install -y --no-install-recommends curl ca-certificates \
 && rm -rf /var/lib/apt/lists/*

Три команды здесь связаны механизмом слоёв и кэша. Если вынести apt-get update в отдельный RUN, его результат будет взят из кэша при следующих сборках, и добавленный через месяц пакет установится по устаревшему индексу — версия окажется старой или пакет не найдётся вовсе. Если вынести rm -rf /var/lib/apt/lists/* в отдельный RUN, индекс размером в десятки мегабайт останется в нижнем слое и размер образа не уменьшится. Ключ --no-install-recommends отключает установку рекомендуемых, но не обязательных пакетов. Таким образом, правило звучит так: в одном RUN объединяются команды, которые должны выполняться вместе ради корректности или ради того, чтобы временные файлы не попали в слой.

Следует также избегать помещения конфиденциальных данных непосредственно в Dockerfile или в контекст сборки. Пароли, токены доступа и приватные ключи не должны становиться частью образа, поскольку это нарушает базовые требования безопасности и создаёт долговременный риск утечки. Если в процессе сборки требуется доступ к закрытому ресурсу, должны использоваться специальные механизмы безопасной передачи секретов, а не их явное включение в текст сценария. В BuildKit таким механизмом является монтирование RUN --mount=type=secret, рассмотренное в разделе о кэшировании.

Пользователь процесса: USER и числовой идентификатор

Если в Dockerfile нет инструкции USER, процесс контейнера работает от имени root (UID 0). Без пространства имён пользователей, которое Docker по умолчанию не включает, это тот же UID 0, что и у root хоста: ограничивают его capabilities, seccomp и изоляция пространств имён, но при уязвимости среды выполнения или неосторожно смонтированном каталоге хоста последствия будут последствиями для root ¹². Поэтому приложение следует запускать от непривилегированного пользователя, а задавать его — числом:

FROM python:3.12-slim
RUN groupadd --gid 10001 app \
 && useradd --no-log-init --uid 10001 --gid 10001 --no-create-home --shell /usr/sbin/nologin app
WORKDIR /app
COPY --chown=10001:10001 . .
USER 10001:10001
CMD ["python", "app.py"]

Числовая форма важна по двум причинам. Во-первых, имя app превращается в UID только через /etc/passwd внутри образа, а среда выполнения, проверяющая «не root ли это», файлов образа не читает. В Kubernetes поле runAsNonRoot: true для образа с USER app приводит к отказу запуска контейнера с ошибкой о том, что нечисловой пользователь не может быть проверен; с USER 10001 проверка проходит ¹⁰. Подробно контекст безопасности пода рассматривается в теме 11. Во-вторых, права на файлы в томах и смонтированных каталогах хоста сравниваются по числам, а не по именам (тема 5). Значения выше 10000 выбирают, чтобы не совпасть с системными пользователями хоста и дистрибутива.

Статический анализ Dockerfile

Многие ошибки этого раздела обнаруживаются автоматически. Анализатор hadolint разбирает Dockerfile и проверяет его по набору правил, а команды внутри RUN — встроенным ShellCheck ¹¹. Он запускается из собственного образа и читает Dockerfile со стандартного ввода:

docker run --rm -i hadolint/hadolint:v2.12.0 < Dockerfile

Для Dockerfile, в третьей строке которого стоит RUN apt-get update && apt-get install -y curl, а в девятой — USER root, отчёт выглядит так (текст первого сообщения сокращён):

-:3 DL3008 warning: Pin versions in apt get install. ...
-:3 DL3015 info: Avoid additional packages by specifying `--no-install-recommends`
-:3 DL3009 info: Delete the apt-get lists after installing something
-:9 DL3002 warning: Last USER should not be root

Каждое правило имеет код (DL3009 — не удалены списки apt, DL3002 — последний USER равен root, DL3007 — использован тег latest), и любое из них можно отключить комментарием # hadolint ignore=DL3008 с обоснованием. Анализ Dockerfile проверяет описание сборки; проверку готового образа на известные уязвимости выполняют сканеры, о которых говорится в разделе о цепочке поставки.

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

Оптимизация образов и многоэтапная сборка

После того как базовая процедура сборки становится корректной и воспроизводимой, возникает задача оптимизации образа. Чаще всего оптимизация понимается как уменьшение размера. Это действительно важный показатель: более компактный образ быстрее передаётся по сети, быстрее загружается в среду исполнения и обычно содержит меньше лишних компонентов. Однако размер не является единственным критерием. Оптимизация должна сохранять функциональную полноту, ясность состава и сопровождаемость.

Наиболее важным инструментом оптимизации является многоэтапная сборка (multi-stage build). Её идея состоит в том, что разные стадии Dockerfile выполняют разные роли. На одной стадии могут устанавливаться компиляторы и инструменты сборки, на другой — выполняться компиляция или упаковка приложения, а в итоговый образ переносятся только результаты, необходимые для запуска. Такой подход позволяет отделить среду построения артефакта от среды его исполнения. Практическое следствие очевидно: в финальном образе не остаются лишние инструменты, которые увеличивали бы размер и расширяли бы потенциальную поверхность атаки.

Рассмотрим многоэтапный Dockerfile для Python-приложения, зависимость которого содержит расширение на C и собирается из исходного кода. Чтобы опыт был показательным, сборка из исходников задана явно ключом --no-binary: для популярных пакетов на PyPI обычно есть готовые колёса (англ. wheel), но для редких архитектур, для дистрибутивов на musl и для внутренних пакетов компиляция при установке — обычная ситуация ¹³:

# syntax=docker/dockerfile:1

# стадия 1: компилятор и заголовки нужны только здесь
FROM python:3.12-slim AS builder
RUN apt-get update \
 && apt-get install -y --no-install-recommends gcc libc6-dev \
 && rm -rf /var/lib/apt/lists/*
WORKDIR /build
COPY requirements.txt .
RUN pip install --no-cache-dir --no-binary=psutil --prefix=/install -r requirements.txt

# стадия 2: тот же базовый образ, но без компилятора
FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /install /usr/local
COPY app.py .
# записи в /etc/passwd нет: для запуска процесса достаточно числового UID
USER 10001:10001
CMD ["python", "app.py"]

Обе стадии начинаются с одного и того же базового образа, поэтому разница в размере между этим образом и однофазным вариантом (тот же Dockerfile без второй стадии) объясняется ровно одним: в однофазном образе остаются gcc, binutils, libc6-dev и их зависимости — порядка сотни мегабайт, — а в многоэтапном только скомпилированная библиотека размером около 2 МБ. Если же сравнивать однофазную сборку на полном образе python:3.12 с многоэтапной на python:3.12-slim, основная часть разницы будет обусловлена сменой базового образа, а не многоэтапностью, и вывод из такого сравнения окажется неверным. Команда docker build --target builder собирает только первую стадию, что удобно для отладки; при обычной сборке BuildKit выполняет лишь те стадии, от которых зависит итоговая.

Многоэтапная сборка особенно полезна для компилируемых языков, однако её значение не исчерпывается ими. Даже в интерпретируемых средах она помогает отделить подготовительные шаги, тестовые зависимости и служебные файлы от финальной поставки. Вместе с тем следует учитывать ограничения. Слишком агрессивная оптимизация, ориентированная только на уменьшение размера, может привести к тому, что образ станет неудобным для диагностики, а процесс сборки — слишком сложным для сопровождения. Следовательно, инженер должен выбирать такую степень оптимизации, которая соответствует назначению конкретного артефакта.

Оптимизация затрагивает и выбор базового образа. Существуют полноценные дистрибутивные образы, минимальные варианты и специализированные среды исполнения. Полноценный образ часто проще в сопровождении, поскольку содержит стандартные инструменты и ожидаемую структуру системы. Минимальный образ уменьшает размер и снижает число потенциально уязвимых компонентов, но может осложнить разбор сбоев и потребовать более аккуратной настройки зависимостей. Выбор между этими вариантами нельзя делать абстрактно: он зависит от требований к безопасности, наблюдаемости, переносимости и удобству сопровождения.

Таким образом, оптимизация не сводится к механическому «сжатию» образа. Она предполагает инженерный анализ того, какие компоненты действительно необходимы в среде выполнения, какие шаги должны остаться на стадии сборки и какие компромиссы приемлемы для конкретного сценария использования.

Версионирование образов и управление изменениями

Образ становится полноценным артефактом поставки только тогда, когда им можно управлять как версией программного продукта. Для этого используются теги (tags), позволяющие различать варианты образа по версии, назначению или каналу поставки. Однако использование тегов нередко сопровождается методической ошибкой: тег воспринимается как абсолютная и неизменная сущность. На практике тег является лишь именованной ссылкой на конкретный образ и может быть переназначен. Поэтому теги вида latest удобны для демонстрации, но плохо подходят для управляемого сопровождения.

С инженерной точки зрения предпочтительно, чтобы версия образа была связана с версией исходного кода, конфигурации сборки и, при необходимости, с состоянием цепочки поставки. Это не означает, что в учебном курсе требуется вводить сложную схему релизного управления, но важно сформировать правильный принцип: образ должен быть однозначно соотнесён с тем исходным состоянием проекта, из которого он получен. Тогда появляется возможность анализировать изменения, воспроизводить прежние версии, выполнять откат и проверять, какой именно артефакт был развернут.

Управление изменениями включает не только присвоение имени версии, но и пересборку образов при обновлении базовых компонентов. Даже если исходный код приложения не менялся, может измениться базовый образ, исправиться уязвимость в системной библиотеке или обновиться среда исполнения. Следовательно, сопровождение контейнерного образа не заканчивается в момент первой успешной сборки. Образ требует периодического пересмотра, повторной сборки и контроля актуальности своих зависимостей.

Теги и дайджесты

Тег изменяем, но у образа есть и неизменяемый идентификатор. По спецификации формата образов OCI образ в реестре описывается манифестом (англ. manifest) — JSON-документом, который перечисляет конфигурацию образа и его слои, ссылаясь на каждый из них по дайджесту (англ. digest), то есть по SHA-256 от содержимого ⁷. Дайджест самого манифеста и есть идентификатор образа в реестре: python@sha256:… всегда указывает на одни и те же байты, потому что изменение любого слоя меняет дайджест слоя, а с ним — содержимое и дайджест манифеста. Такая адресация по содержимому (англ. content addressing) делает подмену образа под тем же дайджестом невозможной без нарушения SHA-256.

docker pull python:3.12-slim
docker image inspect --format '{{index .RepoDigests 0}}' python:3.12-slim

python@sha256:<64 шестнадцатеричных символа>

Полученную строку можно записать в Dockerfile, и тогда базовый образ закреплён по дайджесту (англ. digest pinning):

FROM python:3.12-slim@sha256:<дайджест из вывода выше>

Если указаны и тег, и дайджест, используется дайджест, а тег остаётся для читателя. Закрепление делает сборку воспроизводимой по базовому слою, но у него есть цена: исправления безопасности, выпущенные в теге 3.12-slim, не придут сами. Поэтому закреплённые дайджесты обновляют осознанно — вручную или ботом, который открывает запрос на изменение с новым дайджестом, — и после обновления пересобирают образ.

Аргументы сборки и метки: ARG и LABEL

Прослеживаемость образа обеспечивается метками. Инструкция LABEL записывает пары «ключ — значение» в конфигурацию образа, а спецификация OCI определяет набор стандартных ключей с префиксом org.opencontainers.image. ⁷. Значения, известные только в момент сборки (номер версии, хеш коммита), передаются через ARG:

FROM python:3.12-slim
ARG VERSION=dev
ARG GIT_SHA=unknown
LABEL org.opencontainers.image.version="${VERSION}" \
      org.opencontainers.image.revision="${GIT_SHA}" \
      org.opencontainers.image.source="https://example.org/notes/backend"

docker build --build-arg VERSION=1.4.0 --build-arg GIT_SHA=$(git rev-parse --short HEAD) -t notes-backend:1.4.0 .
docker image inspect --format '{{json .Config.Labels}}' notes-backend:1.4.0

ARG, объявленный до FROM, виден только в строке FROM (например, FROM python:${PY_VERSION}-slim); чтобы использовать его внутри стадии, его объявляют повторно. Значения ARG не попадают в окружение контейнера, но видны в docker history для шагов RUN, которые их используют, поэтому для секретов ARG непригоден.

Мультиплатформенные образы

Образ содержит исполняемые файлы под конкретную архитектуру процессора, а машины разработчиков (Apple Silicon — arm64) и серверы (amd64) часто различаются. Для этого спецификация OCI предусматривает индекс образа (англ. image index): один тег указывает на список манифестов, по одному на платформу, и клиент при загрузке выбирает подходящий ⁷. Такой образ собирается командой docker buildx build с ключом --platform ⁹:

docker buildx build --platform linux/amd64,linux/arm64 \
    -t registry.example.org/notes-backend:1.4.0 --push .

Чужую архитектуру BuildKit исполняет через эмуляцию QEMU, что для компиляции в десятки раз медленнее; альтернатива — кросс-компиляция в стадии, запущенной на родной платформе (FROM --platform=$BUILDPLATFORM), с использованием предопределённых аргументов TARGETOS и TARGETARCH ⁹. Для интерпретируемых языков, как в примерах этой темы, обычно достаточно мультиплатформенного базового образа: официальные образы python публикуются для нескольких архитектур.

Это обстоятельство особенно важно в облачной среде, где образы часто используются многократно и автоматически распространяются по нескольким средам. Если организация или учебная группа не контролирует происхождение и актуальность образов, она фактически теряет прозрачность поставки. Локальный вывод таков: версионирование образов должно поддерживать не только удобство использования, но и прослеживаемость жизненного цикла артефакта.

Публикация образов и роль реестров

Собранный образ приносит практическую пользу лишь тогда, когда его можно передать в среду исполнения или другой участник процесса может его получить. Для этого используются реестры контейнерных образов (registry). Реестр выполняет роль централизованного хранилища, где образам присваиваются имена, версии и правила доступа. С точки зрения архитектуры поставки реестр является связующим звеном между сборкой и развертыванием.

Публикация образа в реестр позволяет перейти от локального, разового использования к повторяемому сценарию. Один и тот же артефакт может быть собран в системе непрерывной интеграции, затем опубликован в утверждённое хранилище и оттуда использован при развертывании на тестовом или эксплуатационном контуре. Этот подход принципиально отличается от практики «собирать на каждом сервере отдельно». Локальная сборка на целевом узле увеличивает вариативность результата и делает сопровождение менее контролируемым.

Реестры могут быть публичными и частными. Публичные реестры удобны как источник типовых базовых образов и как средство распространения открытых приложений. Частные реестры важны тогда, когда требуется ограничить доступ, обеспечить контроль состава поставляемых артефактов или встроить публикацию в корпоративный контур разработки. Независимо от типа реестра, инженер должен учитывать политику именования, правила аутентификации, сроки хранения образов и процедуры удаления устаревших версий.

Протокол обмена с реестром стандартизован спецификацией распространения OCI (англ. OCI Distribution Specification): это HTTP API с путями вида /v2/<имя>/manifests/<тег или дайджест> и /v2/<имя>/blobs/<дайджест> ⁸. Из этого следует практическое свойство: при docker push клиент сначала проверяет, есть ли слой с данным дайджестом в реестре, и не передаёт уже имеющиеся слои, а при docker pull не скачивает слои, которые уже есть локально. Полное имя образа складывается из адреса реестра, пути репозитория и тега или дайджеста: в имени registry.example.org:5000/team/notes-backend:1.4.0 реестр — registry.example.org:5000, репозиторий — team/notes-backend, тег — 1.4.0. Если адрес реестра опущен, подразумевается Docker Hub (docker.io), а для официальных образов — ещё и префикс library/: python:3.12-slim означает docker.io/library/python:3.12-slim.

Публикация связана и с вопросами доверия. Образ, полученный из внешнего источника, не следует автоматически считать безопасным или корректным. Требуется понимать, кто его опубликовал, как он был собран и насколько прозрачен его состав. В учебном процессе этот вопрос особенно полезен методически: он показывает, что контейнеризация не отменяет необходимость критически оценивать происхождение программных компонентов, а, напротив, требует ещё большей дисциплины в управлении артефактами.

Сопровождение образов в цепочке поставки

На зрелом уровне контейнерный образ рассматривается как объект цепочки поставки программного обеспечения, а не как разовый технический продукт. Это означает, что сборка образа должна быть встроена в процессы проверки исходного кода, автоматического тестирования, анализа состава зависимостей и публикации результатов. Чем меньше ручных действий требуется для получения и размещения образа, тем ниже риск человеческой ошибки и тем выше воспроизводимость.

Сопровождение образов включает несколько повторяющихся операций: пересборку при изменении кода, обновление базовых компонентов, проверку корректности Dockerfile, контроль размера и состава образа, а также удаление устаревших или неподдерживаемых версий из хранилища. Эти задачи не являются внешними по отношению к контейнеризации; они составляют её нормальный эксплуатационный контур. Ошибочно считать, что после упаковки приложения в контейнер проблема сопровождения исчезает. Меняется не наличие этой проблемы, а форма её решения.

Одна из таких операций — сканирование образа на известные уязвимости. Сканер (в курсе используется Trivy) раскладывает образ на слои, определяет установленные пакеты дистрибутива и библиотеки языков и сопоставляет их версии с базами уязвимостей ¹²:

trivy image --severity HIGH,CRITICAL python:3.12-slim

Результат сканирования относится к моменту проверки: образ, в котором вчера не было известных уязвимостей, завтра может их получить, хотя не изменился ни один байт, — изменилась база. Поэтому сканирование выполняется не только при сборке, но и периодически по уже опубликованным образам. Сканирование, перечень компонентов (SBOM), подпись образов и политики допуска в кластер подробно рассматриваются в теме 11.

Для учебного курса принципиально важно усвоить следующее: контейнерный образ должен быть прослеживаемым, воспроизводимым и управляемым. Прослеживаемость означает возможность понять происхождение артефакта. Воспроизводимость означает возможность получить сопоставимый результат повторно. Управляемость означает возможность осознанно обновлять, публиковать, отзывать и заменять версии. Именно сочетание этих свойств превращает контейнерный образ в полноценный объект инженерной практики и подготавливает переход к дальнейшим темам курса, связанным с запуском, композицией сервисов и облачной эксплуатацией.

Итоги темы

Сборка контейнерного образа является не вспомогательной технической процедурой, а центральным элементом контейнерной модели поставки приложения. Dockerfile задаёт формальное описание артефакта, а качество этого описания определяет воспроизводимость, переносимость и сопровождаемость результата. По этой причине образ следует проектировать так же внимательно, как и само приложение.

Слоистая структура образов, кэширование и организация контекста сборки требуют осознанной инженерной логики. Нерациональный порядок шагов, включение лишних файлов и использование нефиксированных зависимостей приводят к росту размера образа, ухудшению предсказуемости и снижению безопасности. Напротив, аккуратная структура Dockerfile, применение .dockerignore и фиксация входных условий делают сборку устойчивой и объяснимой. BuildKit добавляет к этому монтирования на время шага: кэш пакетного менеджера и секреты используются при сборке, не оставаясь в слоях.

Оптимизация, многоэтапная сборка, версионирование и публикация в реестры показывают, что образ должен сопровождаться на всём протяжении жизненного цикла. Его необходимо не только однажды собрать, но и регулярно пересматривать, обновлять и связывать с контролируемой цепочкой поставки. Это создаёт основу для следующего этапа изучения: управления контейнерами в среде выполнения и организации повторяемого развертывания приложений.

Литература

1. Docker Documentation. Dockerfile reference. — https://docs.docker.com/reference/dockerfile/ (дата обращения: 22.10.2026).
2. Docker Documentation. BuildKit. — https://docs.docker.com/build/buildkit/ (дата обращения: 22.10.2026).
3. Docker Documentation. Docker build cache. — https://docs.docker.com/build/cache/ (дата обращения: 22.10.2026).
4. Docker Documentation. Building best practices. — https://docs.docker.com/build/building/best-practices/ (дата обращения: 22.10.2026).
5. Docker Documentation. Build secrets. — https://docs.docker.com/build/building/secrets/ (дата обращения: 22.10.2026).
6. Docker Documentation. Build context. — https://docs.docker.com/build/concepts/context/ (дата обращения: 22.10.2026).
7. Open Container Initiative. Image Format Specification v1.1. — https://github.com/opencontainers/image-spec (дата обращения: 22.10.2026).
8. Open Container Initiative. Distribution Specification v1.1. — https://github.com/opencontainers/distribution-spec (дата обращения: 22.10.2026).
9. Docker Documentation. Multi-platform builds. — https://docs.docker.com/build/building/multi-platform/ (дата обращения: 22.10.2026).
10. Kubernetes Documentation. Configure a Security Context for a Pod or Container. — https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ (дата обращения: 22.10.2026).
11. Hadolint: Dockerfile linter. — https://github.com/hadolint/hadolint (дата обращения: 22.10.2026).
12. Rice L. Container Security: Fundamental Technology Concepts that Protect Containerized Applications. — O'Reilly Media, 2020.
13. Docker Documentation. Multi-stage builds. — https://docs.docker.com/build/building/multi-stage/ (дата обращения: 22.10.2026).

Дополнительные материалы

Вопросы для самопроверки

1. Какие инструкции Dockerfile создают слой файловой системы, а какие только поле в конфигурации образа? К какой группе относятся WORKDIR и USER?
2. Чем передача контекста в BuildKit отличается от передачи в прежнем сборщике и почему при повторной сборке строка transferring context показывает лишь десятки байт?
3. Из чего складывается ключ кэша шага RUN и шага COPY? Почему изменение README.md может заставить заново установить все зависимости?
4. Почему apt-get update нельзя выносить в отдельную инструкцию RUN, а rm -rf /var/lib/apt/lists/* — в последующую?
5. Чем RUN --mount=type=cache отличается от кэша сборки и почему кэш-монтирование не заменяет правильного порядка инструкций?
6. Почему секрет, переданный через ARG, нельзя считать скрытым, а секрет, переданный через RUN --mount=type=secret, — можно?
7. Файл с ключом скопирован в образ инструкцией COPY, а следующей инструкцией удалён. Как его восстановить из образа и почему?
8. Почему при сравнении однофазной сборки на python:3.12 и многоэтапной на python:3.12-slim нельзя сделать вывод о пользе многоэтапности?
9. Почему в Kubernetes runAsNonRoot: true отвергает образ с USER app, но принимает образ с USER 10001?
10. Что такое дайджест образа, от чего он вычисляется и почему образ, закреплённый по дайджесту, нельзя подменить, не изменив дайджест?
11. Какие плюсы и минусы у закрепления базового образа по дайджесту и как организовать его обновление?
12. Что такое индекс образа и как один тег может указывать на образы для amd64 и arm64 одновременно?
13. Почему docker image rm с одним тегом может не освободить место на диске?
14. Почему результат сканирования образа на уязвимости меняется со временем, хотя сам образ не меняется?

Глоссарий темы

Шпаргалка по инструментам

# сборка
docker build -t app:1.0 .                         # контекст — текущий каталог
docker build --progress=plain -t app:1.0 .        # подробный вывод BuildKit
docker build -f Dockerfile.dev --target builder . # другой файл, только стадия builder
docker build --build-arg VERSION=1.0 .            # значение ARG
docker build --secret id=token,src=./token.txt .  # секрет для RUN --mount=type=secret
docker build --no-cache -t app:1.0 .              # игнорировать кэш сборки

# анализ образа
docker history app:1.0                            # слои и создавшие их инструкции
docker image inspect --format '{{json .Config}}' app:1.0
docker image inspect --format '{{index .RepoDigests 0}}' app:1.0
docker image ls --digests

# реестр
docker tag app:1.0 localhost:5001/app:1.0
docker push localhost:5001/app:1.0
docker pull localhost:5001/app@sha256:...
curl http://localhost:5001/v2/_catalog
curl http://localhost:5001/v2/app/tags/list

# мультиплатформенная сборка
docker buildx ls
docker buildx build --platform linux/amd64,linux/arm64 -t reg/app:1.0 --push .
docker buildx imagetools inspect python:3.12-slim

# кэш и место на диске
docker builder du                                 # размер кэша сборки
docker builder prune -f                           # очистить кэш сборки
docker image prune -f                             # удалить висячие образы (<none>)

# проверка качества
docker run --rm -i hadolint/hadolint:v2.12.0 < Dockerfile
trivy image --severity HIGH,CRITICAL app:1.0

Что почитать и посмотреть

1. Docker Documentation. Dockerfile reference — https://docs.docker.com/reference/dockerfile/. Полный справочник инструкций, включая все варианты RUN --mount, взаимодействие CMD и ENTRYPOINT и директиву # syntax. Первое место, куда смотреть при сомнении в поведении инструкции.
2. Docker Documentation. Building best practices — https://docs.docker.com/build/building/best-practices/. Официальные рекомендации: выбор базового образа, порядок инструкций, канон apt-get, многоэтапность, USER. Короткий текст, который полезно перечитать после темы.
3. Docker Documentation. Docker build cache — https://docs.docker.com/build/cache/ и раздел Cache invalidation. Точные правила вычисления ключа кэша для каждой инструкции и способы экспорта кэша в реестр для систем непрерывной интеграции.
4. Репозиторий BuildKit — https://github.com/moby/buildkit. Описание архитектуры, LLB, фронтендов и бэкендов кэша; полезно, чтобы понять, почему сборка теперь граф, а не скрипт.
5. Open Container Initiative. Image Format Specification — https://github.com/opencontainers/image-spec. Спецификация манифеста, индекса, конфигурации и слоёв; раздел о дескрипторах объясняет адресацию по дайджесту. Читается за вечер.
6. Rice L. Container Security. — O'Reilly Media, 2020. Главы об образах и цепочке поставки: что внутри образа, почему важен непривилегированный пользователь, как работают сканеры. Книга короткая и написана для инженеров.
7. Hadolint — https://github.com/hadolint/hadolint. Список правил с пояснениями; каждое правило — сжатая формулировка одной типичной ошибки Dockerfile.
8. GoogleContainerTools distroless — https://github.com/GoogleContainerTools/distroless. Образы без оболочки и пакетного менеджера: пример крайней точки в споре «минимальный против удобного для отладки» и инструкции по многоэтапной сборке под них.
9. Reproducible Builds. SOURCE_DATE_EPOCH — https://reproducible-builds.org/docs/source-date-epoch/. Почему одинаковый исходный код даёт разные байты и как от этого избавляются; BuildKit поддерживает эту переменную.
10. Trivy — https://github.com/aquasecurity/trivy. Сканер, используемый в курсе; документация описывает, какие источники уязвимостей и какие типы пакетов он понимает (подробно — тема 11).

Углубление (по желанию)

От docker commit к декларативной сборке

Первые версии Docker (2013) позволяли получить образ командой docker commit: запустить контейнер, выполнить в нём команды вручную и сохранить слой записи как новый слой образа. Dockerfile появился почти сразу как способ автоматизировать ту же последовательность, и прежний сборщик буквально так и работал: для каждой инструкции запускал промежуточный контейнер, выполнял команду и делал commit. Отсюда и устаревшая интуиция «одна инструкция — один контейнер — один слой», и строка Sending build context to Docker daemon: демону нужен был весь контекст до начала работы. BuildKit, ставший сборщиком по умолчанию в Docker Engine 23.0, порвал с этой моделью: Dockerfile стал лишь одним из возможных фронтендов, переводящих описание в граф LLB, а исполнение графа — параллельным, с ленивой передачей контекста и с кэшем, адресуемым по содержимому. Параллельно в 2015–2017 годах формат образа был стандартизован в OCI, что позволило собирать образы и другими инструментами (Buildah, Kaniko, ko) и запускать их любыми совместимыми средами выполнения.

Воспроизводимые сборки

Две сборки одного и того же Dockerfile почти никогда не дают одинаковый дайджест, даже если все версии закреплены. Причины прозаичны: в слоях записано время изменения файлов, в конфигурации — время создания образа, а пакетные менеджеры добавляют в файлы журналы и кэши со временем установки. Проект Reproducible Builds предложил соглашение — переменную SOURCE_DATE_EPOCH, задающую «время сборки» (обычно время последнего коммита), которое инструменты подставляют вместо текущего. BuildKit умеет применять её и к метаданным образа, и к времени файлов в слоях. Побитная воспроизводимость нужна не ради эстетики: она позволяет независимо проверить, что опубликованный образ действительно собран из заявленного исходного кода, — это один из уровней требований SLSA к цепочке поставки, о которой говорится в теме 11.

Лабораторная работа 4. Сборка и сопровождение контейнерных образов

• Раздел курса: тема 4 «Сборка и сопровождение контейнерных образов»

Введение

В лабораторной работе 3 контейнеры запускались из готовых образов. Теперь образ собирается самостоятельно, и на первый план выходят вопросы, которые не видны при работе с чужими образами: из чего состоит образ, что попадает в него из рабочего каталога, почему одна правка пересобирается за секунду, а другая — за минуту, и как доставить образ на другую машину так, чтобы там запустилось ровно то же самое.

Работа состоит из базовой и продвинутой частей. Базовая часть (части 1–5) — основа работы: первый Dockerfile, слои и контекст сборки, кэш BuildKit и порядок инструкций, многоэтапная сборка зависимости с расширением на C, публикация в локальный реестр и загрузка по дайджесту. Продвинутая часть (часть 6) углублённая и выполняется по желанию: непривилегированный пользователь с числовым UID, кэш-монтирование RUN --mount=type=cache и статический анализ Dockerfile анализатором hadolint.

Цель работы

Научиться собирать воспроизводимые образы с помощью Dockerfile и BuildKit, объяснять результат сборки через слои и ключи кэша и публиковать образы в реестр с адресацией по тегу и по дайджесту.

После выполнения работы можно будет:

• написать Dockerfile для Python-приложения и объяснить, какие инструкции создают слои, а какие только метаданные;
• измерить объём контекста сборки по выводу BuildKit и уменьшить его с помощью .dockerignore;
• предсказать по тексту Dockerfile, какие шаги будут взяты из кэша после правки исходного кода, и проверить предсказание по меткам CACHED;
• собрать многоэтапный образ и показать, за счёт чего он меньше однофазного на той же базе;
• опубликовать образ в реестр, получить его дайджест и загрузить образ по дайджесту;
• найти и исправить ошибку сборки по сообщению компилятора;
• (продвинутая часть) запустить приложение от пользователя с числовым UID и проверить Dockerfile анализатором hadolint.

Теоретический минимум

Теория — в теме 4: разделы «Dockerfile как декларативное описание образа», «Контекст сборки и структура входных данных» (BuildKit и .dockerignore), «Кэширование и воспроизводимость сборки», «Оптимизация образов и многоэтапная сборка», «Версионирование образов и управление изменениями» (теги и дайджесты), «Публикация образов и роль реестров».

Две особенности вывода BuildKit понадобятся с первой части. Передача контекста показывается шагом [internal] load build context со строкой transferring context: <объём>; строки Sending build context to Docker daemon, которую можно встретить в старых руководствах, в BuildKit нет. Шаг, взятый из кэша, помечается CACHED. В режиме по умолчанию BuildKit сворачивает вывод завершённых шагов, поэтому для наблюдений в этой работе удобнее ключ --progress=plain.

Перечень оснащения

• ОС: Ubuntu 24.04 (физическая машина, виртуальная машина или WSL2) либо macOS или Windows с Docker Desktop.
• Docker Engine 27 или новее с плагином buildx 0.17 или новее (BuildKit включён по умолчанию); проверка — docker version и docker buildx version. Установка в Ubuntu — по инструкции https://docs.docker.com/engine/install/ubuntu/.
• Образы: python:3.12-slim, registry:3; для продвинутой части — hadolint/hadolint:v2.12.0.
• Утилита curl, текстовый редактор.
• Ресурсы: 2 ядра, 2 ГБ свободной оперативной памяти, 3 ГБ свободного места на диске, доступ к Docker Hub и PyPI.

Архив окружения не нужен: все файлы создаются по ходу работы.

Порядок выполнения работы

Все части выполняются последовательно в каталоге ~/lab04. Перед началом выберите вариант и задайте переменные окружения — они используются во всех командах ниже, поэтому выполняйте работу в одном окне терминала (или повторите export в новом):

export APP_PORT=8081 REG_PORT=5001 APP_UID=10001   # значения из своего варианта

Порт 5000, который часто используют для реестра в примерах, на macOS занят службой AirPlay Receiver, поэтому в вариантах выбраны порты 5001–5010. Docker разрешает работать без TLS с реестром по адресу localhost на любом порту, дополнительная настройка не требуется.

Перед каждым экспериментом запишите предсказание результата, затем выполните команды и сравните. Расхождения — самое ценное в журнале работы. В конце каждой части удаляйте созданные контейнеры; итоговая очистка — в конце части 5. Если сервер в контейнере не отвечает сразу после docker run -d, это нормально: процессу нужно около секунды на запуск, поэтому в командах перед curl стоит sleep 2.

Часть 1. Подготовка учебного приложения и первый Dockerfile

Задание

1. Создайте каталог проекта:

   mkdir -p ~/lab04/app
   cd ~/lab04/app
   

2. Создайте файл app.py:

   from http.server import HTTPServer, SimpleHTTPRequestHandler
   import os
   
   port = int(os.environ.get("PORT", 8000))
   
   class Handler(SimpleHTTPRequestHandler):
       def do_GET(self):
           self.send_response(200)
           self.send_header("Content-Type", "text/plain; charset=utf-8")
           self.end_headers()
           self.wfile.write(f"Учебное приложение, порт {port}\n".encode())
   
   HTTPServer(("0.0.0.0", port), Handler).serve_forever()
   

3. Создайте файл requirements.txt:

   # Зависимости отсутствуют: приложение использует только стандартную библиотеку.
   # Файл сохранён для демонстрации типовой структуры проекта.
   

4. Создайте Dockerfile в каталоге ~/lab04/app:

   FROM python:3.12-slim
   
   WORKDIR /app
   
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   
   COPY . .
   
   ENV PORT=8000
   EXPOSE 8000
   
   CMD ["python", "app.py"]
   

5. Соберите образ и запустите контейнер:

   docker build -t lab04-app:v1 .
   docker run -d --name lab04-test -p $APP_PORT:8000 lab04-app:v1
   sleep 2
   curl http://localhost:$APP_PORT
   

6. Предскажите, изменится ли ответ, если запустить тот же образ с -e PORT=9000 -p $APP_PORT:8000, и проверьте предсказание. Затем остановите и удалите контейнеры:

   docker run -d --name lab04-port -e PORT=9000 -p $((APP_PORT+100)):8000 lab04-app:v1
   sleep 2
   curl -s http://localhost:$((APP_PORT+100)) || echo "нет ответа"
   docker logs lab04-port
   docker rm -f lab04-test lab04-port
   

7. Для каждой инструкции Dockerfile запишите в журнал одной строкой, что она делает и создаёт ли слой (сверьтесь с таблицей в разделе теории «Dockerfile как декларативное описание образа»).

Что должно получиться

Сборка завершается строкой вида naming to docker.io/library/lab04-app:v1 done, а приложение отвечает:

Учебное приложение, порт 8000

Во втором опыте приложение слушает порт 9000, а публикация -p ...:8000 ведёт на порт 8000, где никто не слушает: curl получает обрыв соединения и печатает «нет ответа». Это наглядно показывает, что EXPOSE 8000 и ключ -p не задают порт приложения — его задаёт только переменная PORT, которую читает код.

Часть 2. Анализ слоёв образа и контекста сборки

Задание

1. Исследуйте слоистую структуру собранного образа:

   docker history lab04-app:v1
   

   Зафиксируйте количество строк, относящихся к вашему Dockerfile (они созданы секунды назад, базовые слои — дни или недели назад), их размер и соответствие инструкциям. Определите, какие инструкции создают новые слои, а какие добавляют только метаданные (размер 0B).

2. Создайте в каталоге проекта лишние файлы:

   dd if=/dev/zero of=dummy-large-file.bin bs=1M count=50
   mkdir -p test-data
   echo "тестовые данные" > test-data/notes.txt
   

3. Предскажите объём передаваемого контекста и размер нового образа. Выполните сборку с построчным выводом:

   docker build --progress=plain -t lab04-app:v1-no-ignore . 2>&1 | grep -A2 "load build context"
   

   Зафиксируйте строку transferring context из вывода BuildKit.

4. Создайте файл .dockerignore:

   dummy-large-file.bin
   test-data/
   .dockerignore
   Dockerfile
   

5. Выполните сборку повторно и сравните размеры образов:

   docker build --progress=plain -t lab04-app:v1-with-ignore . 2>&1 | grep -A2 "load build context"
   docker image ls lab04-app --format 'table {{.Repository}}:{{.Tag}}\t{{.Size}}'
   

   Объясните, каким образом .dockerignore влияет на состав образа и на объём передаваемых данных.

6. Выполните ещё одну сборку без изменений (docker build --progress=plain -t lab04-app:v1-with-ignore .) и посмотрите, какой объём контекста передаётся теперь и почему.

7. Удалите лишние файлы и промежуточные образы:

   rm dummy-large-file.bin
   rm -rf test-data
   docker image rm lab04-app:v1-no-ignore lab04-app:v1-with-ignore
   

Что должно получиться

docker history выводит строки вида (размеры зависят от версии Docker и хранилища образов):

IMAGE          CREATED          CREATED BY                                      SIZE      COMMENT
...            10 seconds ago   CMD ["python" "app.py"]                         0B        buildkit.dockerfile.v0
<missing>      10 seconds ago   EXPOSE map[8000/tcp:{}]                         0B        buildkit.dockerfile.v0
<missing>      10 seconds ago   ENV PORT=8000                                   0B        buildkit.dockerfile.v0
<missing>      10 seconds ago   COPY . . # buildkit                             ...kB     buildkit.dockerfile.v0
<missing>      12 seconds ago   RUN /bin/sh -c pip install --no-cache-dir -r…   ...       buildkit.dockerfile.v0
<missing>      12 seconds ago   COPY requirements.txt . # buildkit              ...B      buildkit.dockerfile.v0
<missing>      12 seconds ago   WORKDIR /app                                    0B        buildkit.dockerfile.v0
<missing>      2 weeks ago      CMD ["python3"]                                 0B        buildkit.dockerfile.v0
...

Слои с ненулевым размером создают RUN и COPY; ENV, EXPOSE, CMD записывают только метаданные. Строка RUN /bin/sh -c ... показывает, что команда в shell-форме выполняется через оболочку.

Без .dockerignore BuildKit передаёт около 52 МБ:

#5 [internal] load build context
#5 transferring context: 52.43MB 0.6s done
#5 DONE 0.7s

а образ v1-no-ignore примерно на 52 МБ больше v1, потому что COPY . . скопировал файл в слой. С .dockerignore строка сокращается до сотен байт, а размер образа совпадает с v1. При повторной сборке без изменений контекст тоже передаётся за десятки байт: BuildKit синхронизирует только изменившиеся файлы, поэтому большой объём виден лишь при первой передаче нового файла. Номера шагов #5 у разных версий Docker могут отличаться.

Часть 3. Кэширование и порядок инструкций

Задание

1. Внесите изменение в файл app.py, заменив строку ответа:

   self.wfile.write(f"Учебное приложение v2, порт {port}\n".encode())
   

2. Предскажите, какие шаги будут взяты из кэша. Выполните повторную сборку:

   docker build --progress=plain -t lab04-app:v2 . 2>&1 | grep -E "^#[0-9]+ (\[|CACHED)"
   

   Зафиксируйте, какие шаги использовали кэш (отмечены CACHED), а какие были выполнены заново. Объясните, почему шаг RUN pip install был взят из кэша, хотя исходный код приложения изменился.

3. Создайте альтернативный Dockerfile.bad с нерациональным порядком инструкций:

   FROM python:3.12-slim
   
   WORKDIR /app
   
   COPY . .
   
   RUN pip install --no-cache-dir -r requirements.txt
   
   ENV PORT=8000
   EXPOSE 8000
   
   CMD ["python", "app.py"]
   

4. Соберите образ из этого Dockerfile:

   docker build -f Dockerfile.bad -t lab04-app:v2-bad .
   

5. Внесите ещё одно изменение в app.py — замените v2 в строке ответа на v3 — и выполните сборку обоих вариантов:

   docker build --progress=plain -t lab04-app:v3 . 2>&1 | grep -E "^#[0-9]+ (\[|CACHED)"
   docker build --progress=plain -f Dockerfile.bad -t lab04-app:v3-bad . 2>&1 | grep -E "^#[0-9]+ (\[|CACHED)"
   

   Зафиксируйте, в каком случае шаг установки зависимостей использовал кэш, а в каком был выполнен заново. Объясните связь между порядком инструкций COPY и эффективностью кэширования.

6. Ответьте в журнале без эксперимента: если в app.py изменить значение по умолчанию 8000 на 9000 и пересобрать образ, на каком порту будет слушать приложение в контейнере? Почему?

7. Удалите промежуточные образы:

   rm Dockerfile.bad
   docker image rm lab04-app:v2-bad lab04-app:v3-bad
   

Что должно получиться

Для правильного Dockerfile после правки app.py из кэша берутся шаги до COPY . ., а сам COPY . . выполняется заново (фрагмент, строки [internal] опущены):

#6 [2/5] WORKDIR /app
#6 CACHED
#7 [3/5] COPY requirements.txt .
#7 CACHED
#8 [4/5] RUN pip install --no-cache-dir -r requirements.txt
#8 CACHED
#9 [5/5] COPY . .

Для Dockerfile.bad после той же правки строка CACHED есть только у WORKDIR, а COPY . . и RUN pip install выполняются заново. В учебном приложении зависимостей нет, поэтому разница во времени мала; в проекте с десятками зависимостей она составит десятки секунд на каждую правку (числовой пример — в теории, раздел о кэшировании). Ответ на вопрос шага 6: порт останется 8000, потому что ENV PORT=8000 в Dockerfile задаёт переменную окружения, и os.environ.get("PORT", 9000) вернёт её значение; значение по умолчанию в коде используется, только если переменной нет.

Часть 4. Многоэтапная сборка

Цель части — показать разделение стадии сборки и стадии исполнения на примере Python-приложения, зависимость которого содержит расширение на C и компилируется при установке. Используется библиотека psutil. На PyPI для неё есть готовые колёса под распространённые платформы, поэтому сборка из исходного кода включается явно ключом --no-binary=psutil — так моделируется зависимость без готового колеса (редкая архитектура, внутренний пакет, образ на musl). Чтобы сравнение было честным, все три Dockerfile этой части используют одну и ту же базу python:3.12-slim.

Задание

1. Создайте каталог приложения:

   mkdir -p ~/lab04/multi-app
   cd ~/lab04/multi-app
   

2. Создайте файл app.py:

   from http.server import HTTPServer, SimpleHTTPRequestHandler
   import os
   import psutil
   
   port = int(os.environ.get("PORT", 8000))
   
   class Handler(SimpleHTTPRequestHandler):
       def do_GET(self):
           rss = psutil.Process().memory_info().rss // 1024
           self.send_response(200)
           self.send_header("Content-Type", "text/plain; charset=utf-8")
           self.end_headers()
           self.wfile.write(f"Многоэтапная сборка, порт {port}, RSS {rss} КиБ\n".encode())
   
   HTTPServer(("0.0.0.0", port), Handler).serve_forever()
   

3. Создайте файл requirements.txt:

   psutil==7.0.0
   

4. Сломайте и почините. Создайте Dockerfile.nogcc — однофазную сборку без компилятора — и попробуйте собрать образ. Предскажите, на каком шаге и с каким сообщением сборка остановится:

   FROM python:3.12-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir --no-binary=psutil -r requirements.txt
   COPY . .
   ENV PORT=8000
   CMD ["python", "app.py"]
   

   docker build -f Dockerfile.nogcc -t lab04-multi:nogcc . 2>&1 | grep -iE "error|gcc" | head
   

   Найдите в выводе причину ошибки и исправьте её в однофазном Dockerfile.single, установив компилятор и заголовки C:

   FROM python:3.12-slim
   RUN apt-get update \
    && apt-get install -y --no-install-recommends gcc libc6-dev \
    && rm -rf /var/lib/apt/lists/*
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir --no-binary=psutil -r requirements.txt
   COPY . .
   ENV PORT=8000
   CMD ["python", "app.py"]
   

5. Создайте многоэтапный Dockerfile:

   FROM python:3.12-slim AS builder
   RUN apt-get update \
    && apt-get install -y --no-install-recommends gcc libc6-dev \
    && rm -rf /var/lib/apt/lists/*
   WORKDIR /build
   COPY requirements.txt .
   RUN pip install --no-cache-dir --no-binary=psutil --prefix=/install -r requirements.txt
   
   FROM python:3.12-slim
   WORKDIR /app
   COPY --from=builder /install /usr/local
   COPY app.py .
   ENV PORT=8000
   EXPOSE 8000
   CMD ["python", "app.py"]
   

   Обратите внимание на ключевые элементы: на стадии builder зависимости устанавливаются с флагом --prefix=/install в отдельный каталог; финальная стадия начинается с того же python:3.12-slim, но без компилятора, а результат установки переносится инструкцией COPY --from=builder.

6. Соберите оба варианта и сравните размеры. Перед этим запишите предсказание: на сколько примерно отличаются размеры и из-за чего.

   docker build -f Dockerfile.single -t lab04-multi:single .
   docker build -t lab04-multi:multi .
   docker image ls lab04-multi --format 'table {{.Repository}}:{{.Tag}}\t{{.Size}}'
   

7. Проверьте работоспособность образа, собранного многоэтапной сборкой, и отсутствие компилятора в нём:

   docker run -d --name lab04-multi-test -p $APP_PORT:8000 lab04-multi:multi
   sleep 2
   curl http://localhost:$APP_PORT
   docker exec lab04-multi-test sh -c 'command -v gcc || echo "gcc отсутствует"'
   docker rm -f lab04-multi-test
   

8. Исследуйте слои обоих образов:

   docker history lab04-multi:single
   docker history lab04-multi:multi
   

   Зафиксируйте, какие слои остались в финальном образе при многоэтапной сборке. Объясните, почему компилятор и заголовочные файлы отсутствуют в итоговом образе и почему в его истории нет шага apt-get install.

Что должно получиться

Сборка Dockerfile.nogcc останавливается на шаге RUN pip install; в выводе есть строки вида:

error: command 'gcc' failed: No such file or directory
...
ERROR: Failed building wheel for psutil

После установки gcc и libc6-dev сборка проходит. Образ single больше образа multi примерно на объём компилятора с зависимостями — порядка сотни мегабайт (точное число зависит от версии Debian в базовом образе), а multi больше голого python:3.12-slim лишь на 2–3 МБ скомпилированной библиотеки. В истории multi нет слоя apt-get install: он принадлежит стадии builder, а в итоговый образ попадают только слои его собственной стадии. Приложение отвечает строкой вида Многоэтапная сборка, порт 8000, RSS 21000 КиБ, а docker exec печатает gcc отсутствует.

Часть 5. Версионирование и публикация в локальный реестр

Задание

1. Разверните локальный реестр контейнерных образов и убедитесь, что он работает:

   docker run -d -p $REG_PORT:5000 --name registry registry:3
   sleep 2
   curl http://localhost:$REG_PORT/v2/_catalog
   

2. Присвойте образу учебного приложения теги для публикации:

   cd ~/lab04/app
   docker build -t lab04-app:v3 .
   docker tag lab04-app:v3 localhost:$REG_PORT/lab04-app:v3
   docker tag lab04-app:v3 localhost:$REG_PORT/lab04-app:latest
   docker image ls --format '{{.Repository}}:{{.Tag}} {{.ID}}' | grep lab04-app
   

   Объясните, почему у трёх имён один и тот же идентификатор образа и почему тег latest не рекомендуется использовать как единственный идентификатор версии.

3. Опубликуйте образ и зафиксируйте дайджест из вывода docker push:

   docker push localhost:$REG_PORT/lab04-app:v3
   docker push localhost:$REG_PORT/lab04-app:latest
   

4. Убедитесь, что образ доступен в реестре:

   curl http://localhost:$REG_PORT/v2/_catalog
   curl http://localhost:$REG_PORT/v2/lab04-app/tags/list
   

5. Удалите локальную копию образа и загрузите его из реестра. Предскажите, какие слои будут скачаны, а какие нет. Команда docker image rm снимает тег, а данные образа удаляются, только когда снят последний тег, поэтому удаляются все три имени:

   docker image rm lab04-app:v3 localhost:$REG_PORT/lab04-app:v3 localhost:$REG_PORT/lab04-app:latest
   docker image ls --format '{{.Repository}}:{{.Tag}}' | grep "lab04-app:v3" || echo "образа v3 нет"
   docker pull localhost:$REG_PORT/lab04-app:v3
   

6. Загрузите тот же образ по дайджесту и запустите его:

   DIGEST=$(docker image inspect --format '{{index .RepoDigests 0}}' localhost:$REG_PORT/lab04-app:v3)
   echo $DIGEST
   docker pull $DIGEST
   docker run -d --name lab04-from-registry -p $APP_PORT:8000 $DIGEST
   sleep 2
   curl http://localhost:$APP_PORT
   

7. Выполните очистку:

   docker rm -f lab04-from-registry registry
   docker image rm $(docker image ls --format '{{.Repository}}:{{.Tag}}' | grep -E "lab04-(app|multi)")
   docker image prune -f
   

Что должно получиться

Пустой реестр отвечает {"repositories":[]}. Три имени в шаге 2 имеют один идентификатор: тег — это ссылка на образ, а не копия. Вывод docker push заканчивается строкой вида:

v3: digest: sha256:4c6f...e1a2 size: 1234

При публикации тега latest слои не передаются повторно (Layer already exists): реестр уже хранит их по дайджестам. После публикации:

{"repositories":["lab04-app"]}
{"name":"lab04-app","tags":["latest","v3"]}

При docker pull слои базового образа python:3.12-slim помечаются Already exists — они остались локально, потому что на них ссылаются другие образы, — а скачиваются только слои, созданные инструкциями вашего Dockerfile. Дайджест в переменной DIGEST имеет вид localhost:5001/lab04-app@sha256:... и совпадает с напечатанным при push; повторная загрузка по нему ничего не скачивает. Приложение отвечает строкой Учебное приложение v3, порт 8000.

Часть 6. Продвинутая: пользователь, кэш-монтирование и hadolint

Задание

1. В каталоге ~/lab04/app создайте Dockerfile.v4, запускающий приложение от непривилегированного пользователя с числовым UID из вашего варианта и использующий кэш-монтирование для pip:

   # syntax=docker/dockerfile:1
   FROM python:3.12-slim
   ARG APP_UID=10001
   RUN groupadd --gid ${APP_UID} app \
    && useradd --no-log-init --uid ${APP_UID} --gid ${APP_UID} --no-create-home --shell /usr/sbin/nologin app
   WORKDIR /app
   COPY requirements.txt .
   RUN --mount=type=cache,target=/root/.cache/pip \
       pip install -r requirements.txt
   COPY . .
   ENV PORT=8000
   EXPOSE 8000
   USER ${APP_UID}:${APP_UID}
   CMD ["python", "app.py"]
   

2. Добавьте в requirements.txt строку requests==2.32.3, соберите образ дважды, между сборками добавив вторую зависимость idna==3.10, и сравните вывод шага pip install во второй сборке:

   docker build --progress=plain --build-arg APP_UID=$APP_UID -f Dockerfile.v4 -t lab04-app:v4 . 2>&1 | grep -E "Downloading|Using cached"
   echo "idna==3.10" >> requirements.txt
   docker build --progress=plain --build-arg APP_UID=$APP_UID -f Dockerfile.v4 -t lab04-app:v4 . 2>&1 | grep -E "Downloading|Using cached"
   

3. Проверьте пользователя процесса и то, что кэш pip не попал в образ:

   docker run --rm lab04-app:v4 id
   docker run --rm --user 0 lab04-app:v4 sh -c 'ls /root/.cache/pip 2>/dev/null || echo "кэша pip в образе нет"'
   docker image inspect --format '{{.Config.User}}' lab04-app:v4
   

4. Проверьте анализатором hadolint Dockerfile.v4 и намеренно плохой вариант, в котором есть apt-get install без --no-install-recommends и без очистки списков, а CMD записан в shell-форме:

   docker run --rm -i hadolint/hadolint:v2.12.0 < Dockerfile.v4
   printf 'FROM python:3.12-slim\nRUN apt-get update && apt-get install -y curl\nCOPY . /app\nCMD python /app/app.py\n' > Dockerfile.lint
   docker run --rm -i hadolint/hadolint:v2.12.0 < Dockerfile.lint
   

   Для каждого замечания по Dockerfile.lint запишите, какое правило из теории оно отражает, и исправьте файл так, чтобы замечаний не осталось.

5. Очистка: docker image rm lab04-app:v4, rm Dockerfile.v4 Dockerfile.lint, кэш сборки при желании удаляется командой docker builder prune -f.

Что должно получиться

В первой сборке pip скачивает пакеты (Downloading requests-2.32.3-...whl), во второй — берёт ранее скачанные из кэш-монтирования (Using cached requests-2.32.3-...whl) и скачивает только новый idna, если он ещё не был загружен как зависимость requests. При этом каталога /root/.cache/pip в образе нет. Команда id печатает uid=10001(app) gid=10001(app) groups=10001(app) (с UID вашего варианта), поле .Config.User содержит число.

По Dockerfile.v4 hadolint может выдать замечание DL3042 (pip без --no-cache-dir): при кэш-монтировании оно ложное, и его отключают комментарием # hadolint ignore=DL3042 над строкой RUN. Если убрать из useradd ключ --no-log-init, появится DL3046: без него useradd с большим UID создаёт разреженный файл /var/log/lastlog, который при копировании в слой может занять много места. По Dockerfile.lint ожидаются замечания DL3008, DL3009, DL3015 и DL3025 (shell-форма CMD; почему это важно для сигналов — в теме 5).

Журнал работы

Ведите журнал для себя: для каждого эксперимента записывайте предсказание, команду, фактический вывод (достаточно ключевых строк) и объяснение расхождения. Особенно полезны записи о строках transferring context и CACHED, о размерах образов из части 4 и о дайджесте из части 5. Сохраните итоговые Dockerfile — они пригодятся в курсовом проекте при контейнеризации приложения «Заметки».

Контрольные вопросы

1. Какую роль выполняет инструкция FROM в Dockerfile? Что произойдёт, если указать несуществующий базовый образ, и на каком шаге сборки это обнаружится?
2. Чем отличаются инструкции COPY и ADD? В каких случаях предпочтительна COPY?
3. Объясните по ключам кэша BuildKit, почему файл requirements.txt копируется отдельно от остального кода приложения.
4. Что такое контекст сборки? Почему при повторной сборке BuildKit передаёт лишь десятки байт контекста, а лишний файл всё равно оказывается в образе, если нет .dockerignore?
5. В части 4 обе стадии используют python:3.12-slim. Почему сравнение однофазной сборки на python:3.12 с многоэтапной на python:3.12-slim не доказывало бы пользу многоэтапности?
6. Почему apt-get update, apt-get install и rm -rf /var/lib/apt/lists/* записываются одной инструкцией RUN, хотя объединять команды ради числа слоёв не рекомендуется?
7. В чём опасность использования тега latest как единственного идентификатора образа? Что даёт закрепление базового образа по дайджесту и какую цену за это приходится платить?
8. Почему секреты нельзя передавать в сборку через COPY, ARG или ENV? Каким образом удалённый на следующем слое файл может быть восстановлен из образа и как эту задачу решает RUN --mount=type=secret?
9. Почему после docker image rm localhost:5001/lab04-app:v3 образ мог остаться на диске, а последующий docker pull ничего не скачать?
10. Почему в Kubernetes с runAsNonRoot: true образ с USER app не запустится, а с USER 10001 запустится?
11. Какие преимущества даёт использование реестра образов по сравнению с локальной сборкой на каждом целевом сервере?