Dockerfile: небольшая, проверяемая и непривилегированная сборка

Этот урок начинается с нуля. Незнакомое слово здесь не считается вашим пробелом: мы сначала создадим образ, затем дадим точное значение и только потом применим его.

Где мы находимся

Полётное повторение. В прошлом уроке была опора Dockerfile → слои → image@digest → container → stop/remove. Не подглядывая, назовите её четыре звена и только затем сравните с записью.

Результат урока

Собираем CloudLab в multi-stage образ, запускаем тесты при сборке и проверяем непривилегированного пользователя. Не переходите дальше, пока не можете объяснить, что проверяет каждая команда и какой отказ она обнаруживает.

Сначала знакомый образ

В производственный чемодан кладут только то, что понадобится в поездке, а не всю мастерскую. Multi-stage Dockerfile сначала использует большую мастерскую для сборки, затем переносит готовый бинарный файл в маленький чистый образ.

Аналогия помогает начать рассуждение, но не заменяет устройство технологии. Ниже мы уточним каждое слово.

Опорный сигнал урока

source → test → build → copy binary → non-root runtime

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

Новые слова простыми словами

• Dockerfile — Текстовый рецепт сборки образа по шагам.
• Build stage — Временная среда с компилятором и исходным кодом.
• Runtime stage — Минимальная среда, в которой работает готовая программа.
• Non-root — Запуск от пользователя без полномочий суперпользователя.

Разбираем без спешки

Multi-stage сборка оставляет компилятор в строительном слое, а в итог переносит только бинарные файлы. Это уменьшает поверхность атаки и размер. USER 65532 ограничивает процесс, а статический healthcheck не требует shell внутри образа.

Сейчас не нужно запоминать формулировку дословно. Найдите в ней причинную связь и привяжите её к опорному сигналу выше.

Сначала предскажите результат

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

Опыт маленькими шагами

Выполните команды из корня course/cloud-devops-lab. Команды рассчитаны на учебную среду. Перед командой, меняющей сервер или данные, прочитайте её целиком и проверьте текущий каталог. Запускайте блок по одной смысловой группе. После каждой остановитесь и сопоставьте результат со своим прогнозом.

docker build --build-arg VERSION=lesson-09 -t cloudlab:lesson-09 .
docker image inspect cloudlab:lesson-09 --format 'user={{.Config.User}} size={{.Size}}'
docker run --rm --entrypoint /cloudlab-healthcheck cloudlab:lesson-09 || true

Эталонные файлы проекта.

Что именно делает этот опыт

Сборка сперва выполняет тесты, потом компилирует CloudLab и переносит только нужные файлы. inspect проверяет пользователя, а health-запрос доказывает запуск. Малый размер сам по себе не доказывает безопасность.

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

• Образ собирается только после тестов.
• Команда завершается предсказуемым кодом.
• Результат можно повторить на чистой среде.

Соберите целое по опорной схеме

Проведите пальцем или карандашом по четырём блокам и расскажите весь урок одним связным объяснением.

Воспроизведите без подсказки

1. Закройте схему и нарисуйте четыре блока по памяти.
2. Объясните каждый переход словами «потому что».
3. Дайте определение одному новому термину, не повторяя текст дословно.
4. Назовите один сигнал, который доказывает результат.

Найдите и исправьте ошибку

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

Задание

Теперь соберите тот же смысл самостоятельно. Можно смотреть на опорную схему; цель — не экзамен на память, а воспроизводимый результат.

Обязательное. Напишите команды сборки cloudlab:practice и проверку через docker image inspect, которая завершается ошибкой, если пользователь образа равен 0 или пуст. Отправьте только команды или скрипт POSIX sh без реальных ключей и токенов.

Критерии готовности

• Вы понимаете каждую запускаемую строку.
• Повторный запуск даёт ожидаемый результат или безопасно объяснённое отличие.
• В выводе нет настоящих ключей, токенов и паролей.
• Вы можете показать факт, который подтверждает успех.

Если проверка не прошла, зафиксируйте ожидаемое и фактическое, вернитесь к одному разорванному звену опоры и повторите. Ошибка не отнимает у вас право продолжать обучение.

По желанию. Запишите один возможный отказ и сигнал, по которому вы его заметите.

Открытая перспектива

Следующий урок добавит новую опору: Тома, bind mounts и доказательство сохранности данных.

Оглавление курса