werf cleanup глубоко

Что нужно знать перед уроком

M3 урок 7 — базовая модель keepPolicies. Этот урок разбирает werf cleanup полностью — точную структуру политик, дефолты и стратегию настройки под реальный релизный цикл Application-пакета.

Теория

Дефолтные политики, если werf.yaml их не определяет

Если в werf.yaml не задан явный раздел cleanup.keepPolicies, werf применяет встроенные дефолты:

• Хранить последние 10 git-тегов.
• Хранить до двух версий за последнюю неделю для 10 наиболее активных git-веток.
• Хранить две версии для веток main, master, staging, production (особое, более строгое правило именно для «стабильных» веток).

Полная структура keepPolicies

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

cleanup:
  keepPolicies:
    - references:
        tag: /^v.*$/
      imagesPerReference:
        last: 10
    - references:
        branch: /^features\/.*/
      imagesPerReference:
        last: 10
        in: 168h
        operator: And
    - references:
        branch: /^(main|master|staging|production)$/
      imagesPerReference:
        last: 2

references.tag/references.branch — конкретное имя или регулярное выражение (обратите внимание: имена веток указываются без префикса origin/). Для git-тегов проверяется только HEAD-коммит тега — значение last > 1 для тегов не имеет смысла (тег указывает на один конкретный коммит, а не на историю коммитов, как ветка).

imagesPerReference — ограничение числа версий образов на одну ссылку (тег/ветку): last — количество (дефолт 1), in — период времени поиска версий (например, 168h = 7 дней), operator — как комбинировать last и in (And — версия должна попадать под ОБА условия, Or — достаточно одного).

Стратегия: как настроить политику под реальный релизный цикл Application-пакета

Для Application-пакета типична следующая логика приоритетов:

1. Продовые семверные теги (v1.2.3 и подобные) — хранить максимально долго (высокий last, например 20-30), поскольку откат на конкретную опубликованную версию — стандартный сценарий эксплуатации, и удаление старого продового тега может сломать возможность отката.
2. Feature/dev-ветки — хранить недолго и немного версий (например, последние 2-3 версии за последнюю неделю), поскольку это временные артефакты разработки, теряющие ценность после мержа/удаления ветки.
3. main/production — отдельное строгое правило (дефолтные 2 версии часто разумны как есть — последняя стабильная + предыдущая, для быстрого отката без пересборки).

Что не должно быть удалено никогда

Помимо keepPolicies, важно учитывать: образы, на которые ссылаются опубликованные и всё ещё используемые ApplicationPackageVersion (M5 урок 6), не должны попадать под агрессивную очистку — если версия пакета, доступная пользователям через каталог Deckhouse, ссылается на конкретный content-based тег, а этот тег был удалён cleanup, установка или обновление Application до этой версии станет невозможным. Здесь релизный процесс (M9 урок 5) и политика cleanup должны быть согласованы — например, через отдельную, максимально консервативную политику для тегов, соответствующих опубликованным версиям пакета.

Частые ошибки и подводные камни

• Использовать одну общую политику для всех типов веток/тегов без разделения на продовые/dev. Дефолтная политика — разумная отправная точка, но для реального Application-пакета обычно требуется явное разделение приоритетов хранения между продовыми тегами и временными dev-ветками.
• Указывать last > 1 для git-тегов. Тег ссылается на один конкретный коммит, поэтому imagesPerReference.last для тега имеет смысл только как 1 — для истории версий одного и того же тега (что нетипично) нужна другая модель организации версий.
• Не согласовывать политику cleanup с релизным процессом каталога Application-пакетов. Удаление образа, на который всё ещё ссылается опубликованная и используемая версия пакета в каталоге Deckhouse, ломает возможность установки/обновления для конечных пользователей.

Практика в кластере

Практики в кластере в этом уроке нет — материал относится к политике хранения образов в registry, а не к состоянию кластера.

Практика разработки

Настройте в werf.yaml пакета Vikunja явную политику cleanup.keepPolicies, отражающую трёхуровневую стратегию из теории (продовые теги / feature-ветки / main), и проверьте dry-run очистки:

1

werf cleanup --dry-run --repo $CI_REGISTRY_IMAGE

Шпаргалка команд урока

1
2

werf cleanup --repo <repo>
werf cleanup --dry-run --repo <repo>    # предпросмотр без реального удаления

Полная сводная таблица — 📋 werf .

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

Рекомендуемая литература

Официальная документация

• werf — Cr_Cleanup

Статьи и блоги

• Вышла werf 2.0: новый движок развёртывания Nelm — Flant на Habr.
• werf v1.2 — Stapel и инкрементальная сборка — Flant на Habr.
• GitLab + K8s + Werf — Habr.

Книги

• Nigel Poulton. Docker Deep Dive. 2023. ISBN 978-1916585206.

Связанные материалы

• Предыдущий урок: M8.04 — werf bundle publish/apply.
• Следующий урок: M8.06 — Distroless и минимизация размера.

✓ Урок пройден — все вопросы самопроверки отвечены верно