Registry, immutable tags, SBOM и проверка цепочки поставки

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

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

Полётное повторение. В прошлом уроке была опора liveness: перезапустить? | readiness: дать трафик? | limits: сколько можно?. Не подглядывая, назовите её четыре звена и только затем сравните с записью.

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

Связываем образ с commit SHA, получаем SBOM и сканируем содержимое до публикации. Не переходите дальше, пока не можете объяснить, что проверяет каждая команда и какой отказ она обнаруживает.

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

Склад принимает коробки, но сам факт хранения не доказывает качество содержимого. Registry — склад образов. Digest похож на пломбу конкретной коробки, SBOM — опись деталей внутри, сканер — сверка описи со списком известных проблем.

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

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

commit → image → digest → registry → SBOM/scan → deploy

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

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

• Registry — Сервис хранения и раздачи контейнерных образов.
• Immutable — Неизменяемый после публикации; новая версия получает новую идентичность.
• SBOM — Перечень программных компонентов и версий внутри артефакта.
• Vulnerability — Известная слабость, применимость которой нужно проверить в контексте.

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

Registry хранит и раздаёт образы, но доверие не появляется от самого факта загрузки. Версия должна быть неизменяемой, происхождение — прослеживаемым, зависимости — видимыми. SBOM перечисляет компоненты; сканер сопоставляет их с известными уязвимостями, но не доказывает отсутствие всех ошибок.

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

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

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

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

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

sha=$(git rev-parse --short=12 HEAD)
docker build --build-arg VERSION="$sha" -t "cloudlab:$sha" .
docker image inspect "cloudlab:$sha" --format '{{.Id}}'
printf 'release=%s\n' "$sha"

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

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

Команды называют образ коротким SHA, получают его digest и создают опись. Если инструмент сканирования отсутствует, урок не притворяется успешным: сначала поймите ожидаемый артефакт и установите инструмент отдельно.

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

• Тег равен исходному commit SHA.
• Команда завершается предсказуемым кодом.
• Результат можно повторить на чистой среде.

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

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

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

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

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

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

Задание

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

Обязательное. Напишите POSIX sh-скрипт, который строит тег из 12 символов Git SHA, собирает образ и печатает его локальный image ID; latest использовать нельзя. Отправьте только команды или скрипт POSIX sh без реальных ключей и токенов.

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

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

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

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

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

Следующий урок добавит новую опору: CI/CD как система обратной связи.

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