Реестры образов и хранение артефактов

Как реестр экономит и время, и место

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

Мой замер это и показывает: первая публикация 416 миллисекунд, вторая - 103, потому что тяжёлый слой с данными не изменился и повторно не поехал. Ровно та же экономия работает и в обратную сторону, при скачивании на машины: свежая версия приложения на общей базе тянет только свой верхний слой.

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

реестр

хранилище образов; хранит слои по их хэшу и не дублирует их

слой

неизменяемый набор изменений файлов со своим именем-хэшем

Тег двигается, отпечаток нет

Тег - это имя, которое можно перевесить на другой образ в любой момент. Отпечаток - хэш содержимого, и он меняется вместе с содержимым. Я взял отпечаток первой версии, удалил её локально и скачал обратно ПО ОТПЕЧАТКУ - получил ровно то, что публиковал, независимо от того, куда с тех пор переехал тег.

Отсюда правило для прода: либо ссылаться на отпечаток, либо давать каждой сборке свой неповторяющийся тег, например с датой и коротким именем коммита. Плавающие имена вроде latest или stable на нескольких машинах разъезжаются: где-то стоит вчерашняя сборка, где-то позавчерашняя, и на вопрос «что сейчас в проде» ответить нечем.

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

тег

подвижное имя образа; сегодня одно содержимое, завтра другое

отпечаток

хэш содержимого образа; ссылка, которая не переедет

секрет сборки

значение, доступное шагу сборки, но не попадающее в слой

Хранение и уборка

Артефакты копятся быстрее, чем кажется. Каждая сборка каждой ветки оставляет образ, а образ тянет за собой слои. Смотрел на своей машине: образов 41 общим весом 11,68 гигабайта, и 78% этого веса не используется ни одним контейнером. Плюс кэш сборки, то есть сохранённые промежуточные шаги прошлых сборок, на 3,97 гигабайта, и тома - хранилища данных, живущие отдельно от контейнеров, - ещё на 2,78, из которых 93% ни к чему не подключено.

Поэтому у артефактов должна быть политика хранения: сколько держать сборки веток, сколько релизные, что удалять автоматически. Обычно ветки чистят агрессивно (дни), релизы держат долго, а то, что помечено как выкаченное в прод, не трогают вовсе - иначе однажды окажется, что откатываться некуда.

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

политика хранения

правило, сколько и какие артефакты держать, остальное удалять

неиспользуемый образ

тот, на который не ссылается ни один живой контейнер

Как отвечать: «Чем тег отличается от отпечатка и что использовать в проде?»

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

Ответ различает механику и практику и заканчивается настройкой реестра. Последнее показывает, что человек хранилище настраивал руками, а не читал про отпечатки.

На чём валятся

• −Катят плавающий тег в прод и не могут сказать, что именно работает на каждой машине.
• −Кладут ключи внутрь образа и полагаются на удаление следующей строкой сборки.
• −Не заводят политику хранения и упираются в кончившееся место на машине сборки.
• −Чистят артефакты одной командой по расписанию и уносят то, к чему собирались откатываться.
• −Считают, что публичные образы всегда доступны, и получают вставшую сборку из-за чужого лимита.