В наше время в каждом доме по кластеру kubernetes, выкатка приложений в кластер осуществляется по тегу. Образ выкатываемого приложения отправляется тегом в репозиторий проекта Registry GitLab, которое постепенно распухает до невероятных размеров.
Поэтому рекомендую вставить в расписание сron команду для удаления образов, не имеющих тегов
sudo gitlab-ctl registry-garbage-collect
Можно освободить еще больше места удалив не используемые слои образов
sudo gitlab-ctl registry-garbage-collect -m
ВНИМАНИЕ: Во время чистки мусора останавливается служба registry, как следствие пользователи не смогут делать push, pull.
Опытные джедаи могут сократить время простоя путем временного перевода registry в режим readonly.
sudo vi /etc/gitlab/gitlab.rb
registry['storage'] = {
'maintenance' => {
'readonly' => {
'enabled' => true
}
}
}
sudo gitlab-ctl reconfigure
по окончанию работ устанавливаем enabled в false и снова sudo gitlab-ctl reconfigure.
Для работы с GitLab нам понадобится GitLab API и токен с правами api + если хотим проверять и чистить приватные репозитории понадобится read_repository и write_registry.
Для получения образов, хранимых в registry GitLab, нужны id проекта и id репозитория в registry.
GitLab pagination
{
"location": "mygitlab.abc.ru:3000/dev/my-awsome-app/base:deploy_123",
"name": "deploy_123",
"path": "dev/my-awsome-app/base:deploy_123"
}
Я туда сразу вбрасываю поле del_url, как можно догадаться в нем URL для удаления данного образа.
Итог - список всех тегов с образами и ссылками на удаление тега, за исключением тех проектов которые мы изначально решили не трогать.
Kubernetes
Для взаимодействия с Kubernetes используется модуль kubernetes. Если вы, также как и я, хотите заново изобрести велосипед - список пользовательских библиотек для разных языков лежит здесь.
Kubernetes хранит историю всех, работающих в нем приложений ее можно посмотреть командой kubectl rollout history <указание на объект>, либо собрать ReplicaSetы и по номеру ревизии определить кто за кем идет. Я использовал второй вариант он также позволит нам забирать любые интересующие нас поля. Из полученной информации я забирал образ, номер ревизии и идентификатор. В качестве идентификатора приложения к которому принадлежит данный replicaset я использовал имя namespace + label app либо для служебных приложений replica_set.spec.template.spec.service_account. Получаем объект поля - идентификаторы приложения, содержимое - образы с ревизиями. Дальше все просто, оставляем по каждому приложению N образов из последних ревизий и оставшиеся образы сбрасываем в одну кучу.
Итог - список образов из Kubernetes, если эти образы есть в GitLab их теги чистить не нужно.
ВНИМАНИЕ: В список не попадут Job и CronJob так как они не имеют ReplicaSet. Чтобы их сохранить можно ручками внести проекты в исключения либо автоматически отфильтровать.
Унифицированного подхода я не придумал, а наша реализация этой фичи останется секретом фирмы
"Отделяем зерна от плевел" точнее наоборот...
Из множества образов GitLab, вычитаем множество Кубернячих образов и получаем то, что можно удалить. Ниже картинка для наглядности.
Для полной автоматизации все это можно запихнуть в контейнер, создать на это дело CronJob или Job. Только не забудьте добавить этот проект в исключения.
Автоматизация написана на python, но это не столь принципиально. Можно значительно сократить размер кода и затраты памяти, если чуть чуть подумать.
Источник статьи: https://habr.com/ru/post/553054/
Существующие решения
- Решение из коробки
Идем в проект Settings → CI/CD → CleanUp policy for tags. Тут можно создать некий шаблон, который под капотом использует Bulk Delete и, в принципе, все не плохо ЕСЛИ у вас куча тегов ссылающихся на один и тот же образ. Но если у вас идет активная разработка и каждый второй тег - это новый образ, этот способ не поможет. - Решения от community
- "Сжечь и перевыкатить"
- Ручная либо полу ручная сортировка образов и тегов.
Подготовка
Любая разумная деятельность должна начинаться со сбора информации. Поэтому первым делом сканим или проводим опрос всех до кого можем дотянуться, не хранит ли кто-нибудь в проектах образов, которые не работают в постоянном режиме (образы от Job, CronJob или просто склад полезных образов). Внимательно записываем в книжечку проекты, которые лучше не трогать.Настраиваем сборщик мусора GitLab
Теги в GitLab registry ссылаются на образы, а образы используют слои.Если почистить только теги, сильного прироста свободного места мы не получим.Поэтому рекомендую вставить в расписание сron команду для удаления образов, не имеющих тегов
sudo gitlab-ctl registry-garbage-collect
Можно освободить еще больше места удалив не используемые слои образов
sudo gitlab-ctl registry-garbage-collect -m
ВНИМАНИЕ: Во время чистки мусора останавливается служба registry, как следствие пользователи не смогут делать push, pull.
Опытные джедаи могут сократить время простоя путем временного перевода registry в режим readonly.
sudo vi /etc/gitlab/gitlab.rb
registry['storage'] = {
'maintenance' => {
'readonly' => {
'enabled' => true
}
}
}
sudo gitlab-ctl reconfigure
по окончанию работ устанавливаем enabled в false и снова sudo gitlab-ctl reconfigure.
Алгоритм чистки
GitLabДля работы с GitLab нам понадобится GitLab API и токен с правами api + если хотим проверять и чистить приватные репозитории понадобится read_repository и write_registry.
Для получения образов, хранимых в registry GitLab, нужны id проекта и id репозитория в registry.
GitLab pagination
- Забираем информацию о проектах через /api/v4/projects, endpoint возвращает список объектов. Полей много, но нас интересует поле id.
- Фильтруем проекты, которые необходимо исключить.
- Зная project[id] собираем информацию о репозиториях через /api/v4/projects/{project[id]}/registry/repositories. Тут мы получим список объектов из которых заберем id репозиториев.
- И, наконец, собираем теги /api/v4/projects/{repo['project_id']}/registry/repositories/{repo['id']}/tags
{
"location": "mygitlab.abc.ru:3000/dev/my-awsome-app/base:deploy_123",
"name": "deploy_123",
"path": "dev/my-awsome-app/base:deploy_123"
}
Я туда сразу вбрасываю поле del_url, как можно догадаться в нем URL для удаления данного образа.
Итог - список всех тегов с образами и ссылками на удаление тега, за исключением тех проектов которые мы изначально решили не трогать.
Kubernetes
Для взаимодействия с Kubernetes используется модуль kubernetes. Если вы, также как и я, хотите заново изобрести велосипед - список пользовательских библиотек для разных языков лежит здесь.
Kubernetes хранит историю всех, работающих в нем приложений ее можно посмотреть командой kubectl rollout history <указание на объект>, либо собрать ReplicaSetы и по номеру ревизии определить кто за кем идет. Я использовал второй вариант он также позволит нам забирать любые интересующие нас поля. Из полученной информации я забирал образ, номер ревизии и идентификатор. В качестве идентификатора приложения к которому принадлежит данный replicaset я использовал имя namespace + label app либо для служебных приложений replica_set.spec.template.spec.service_account. Получаем объект поля - идентификаторы приложения, содержимое - образы с ревизиями. Дальше все просто, оставляем по каждому приложению N образов из последних ревизий и оставшиеся образы сбрасываем в одну кучу.
Итог - список образов из Kubernetes, если эти образы есть в GitLab их теги чистить не нужно.
ВНИМАНИЕ: В список не попадут Job и CronJob так как они не имеют ReplicaSet. Чтобы их сохранить можно ручками внести проекты в исключения либо автоматически отфильтровать.
Унифицированного подхода я не придумал, а наша реализация этой фичи останется секретом фирмы
"Отделяем зерна от плевел" точнее наоборот...
Из множества образов GitLab, вычитаем множество Кубернячих образов и получаем то, что можно удалить. Ниже картинка для наглядности.
Для полной автоматизации все это можно запихнуть в контейнер, создать на это дело CronJob или Job. Только не забудьте добавить этот проект в исключения.
Автоматизация написана на python, но это не столь принципиально. Можно значительно сократить размер кода и затраты памяти, если чуть чуть подумать.
Источник статьи: https://habr.com/ru/post/553054/