При масштабировании инфраструктуры расходы на хранение образов и слоёв в registry заметно выросли. Как подойти к управлению этой статьёй расходов без потери возможности откатов и аудита??

Короткий ответ

Нет единственного решения: обычно сочетают дедупликацию за счёт единых базовых образов между сервисами, garbage collection непромотированных/временных тегов, перенос редко используемых архивных образов в более дешёвое холодное хранилище, и явный аудит того, какие образы реально нужны по требованиям compliance, а не только по текущему бюджету.

Как это работает подробнее

большая часть затрат на хранение образов в реестре обычно приходится не на уникальный код приложений, а на повторяющиеся базовые слои (системные библиотеки, runtime языка), если разные команды используют разные версии или источники базовых образов — унификация базовых образов снижает количество уникальных крупных слоёв, которые реестр должен хранить отдельно. Garbage collection непромотированных тегов (временных CI-сборок, dev-веток) убирает заведомо ненужный со временем объём. Холодное хранилище (например, объектное хранилище с более низким классом доступности/стоимости) подходит для образов, которые должны формально сохраняться для аудита/compliance, но практически никогда не используются для реального pull.

Пример кода

compose.yamlКопировать

# Пример многоуровневой lifecycle-политики (концептуально)
rules:
  - name: archive-old-non-release
    tag_pattern: "*"
    exclude_pattern: "release-*"
    action: move_to_cold_storage
    older_than_days: 90
  - name: delete-unreferenced
    action: delete
    condition: "no_tag_references"
    older_than_days: 180

Что использовать на практике

• Практика. перед любой оптимизацией стоимости нужно провести инвентаризацию — какие образы и теги реально тянутся за последние N месяцев (метрики реестра обычно это показывают), какие обязаны храниться по требованиям безопасности/compliance независимо от частоты использования, и только после этого проектировать многоуровневую политику хранения.

Подводные камни

• Риск. сокращают расходы агрессивной единой retention-политикой без разделения на категории, рискуя удалить образ, нужный аудитору или для восстановления легаси-версии у конкретного клиента; переносят в холодное хранилище образы, для которых время восстановления (retrieval time) холодного класса хранения неприемлемо долго в случае реального экстренного rollback.