Сборка и публикация одного проверенного образа

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

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

Полётное повторение. В прошлом уроке была опора event → workflow → job → runner → steps → evidence. Не подглядывая, назовите её четыре звена и только затем сравните с записью.

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

Настраиваем публикацию в registry только после тестов и переносим один digest между средами. Не переходите дальше, пока не можете объяснить, что проверяет каждая команда и какой отказ она обнаруживает.

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

Образец лекарства проверяют, а затем распространяют именно проверенную партию. Если для каждой аптеки изготовить новую партию, прежняя проверка уже не доказывает её состав. Так же один образ строят один раз и переносят между средами по digest.

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

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

test once → build once → sign/scan → push digest → promote same digest

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

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

• Artifact — Собранный результат pipeline: бинарник, образ или пакет.
• Release — Идентифицированный набор изменений и артефактов, готовый к использованию.
• Promotion — Перевод того же артефакта в следующую среду без пересборки.
• Provenance — Запись, откуда и каким процессом получен артефакт.

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

Повторная сборка для production может дать иной артефакт, чем тот, который тестировался. Надёжнее собрать один раз, проверить, опубликовать и продвигать его digest. Registry credentials нужны только job публикации и не должны быть доступны pull request из недоверенного fork.

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

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

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

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

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

sha=$(git rev-parse --short=12 HEAD)
image=ghcr.io/OWNER/cloudlab:$sha
printf 'would publish %s\n' "$image"
printf 'production must record a sha256 digest, not latest\n'

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

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

Упражнение строит образ, связывает его с commit SHA и извлекает digest. Скопируйте digest в журнал выпуска. Именно его должен получить следующий этап, а не новое локальное содержимое под тем же тегом.

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

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

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

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

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

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

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

Ошибка: «Пересобрать тот же commit в production — то же самое». Исправление: зависимости, base image или builder могли измениться; продвигайте проверенный digest.

Задание

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

Обязательное. Напишите POSIX sh-проверку переменных REGISTRY, IMAGE и GIT_SHA, которая строит полное имя образа и отказывается публиковать тег latest. Отправьте только команды или скрипт POSIX sh без реальных ключей и токенов.

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

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

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

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

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

Следующий урок добавит новую опору: Секреты, конфигурация и среды без утечки.

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