[Open source, DevOps, Kubernetes] Чистка GitLab Registry для Kubernetes админов
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В наше время в каждом доме по кластеру kubernetes, выкатка приложений в кластер осуществляется по тегу. Образ выкатываемого приложения отправляется тегом в репозиторий проекта Registry GitLab, которое постепенно распухает до невероятных размеров. 
Существующие решения
- Решение из коробкиИдем в проект 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 paginationGitLab выдает информацию страницами, размер страницы про умолчанию 20 элементов, максимальный размер страницы 100 элементов. Также в заголовке передается поле X-Total, а в нем общее количество элементов его можно использовать для того, чтобы сразу генерировать список страниц и опрашивать их параллельно.
- Забираем информацию о проектах через /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, но это не столь принципиально. Можно значительно сократить размер кода и затраты памяти, если чуть чуть подумать.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Законодательство в IT, IT-компании] Проект Debian выбрал нейтральную позицию по итогам голосования по поводу отношения к Столлману
- [ERP-системы] OpenSAP или чему можно учиться бесплатно в мире SAP
- [Open source, Разработка для Office 365, Лайфхаки для гиков] Получится ли сэкономить, отказавшись от Microsoft Office?
- [Управление разработкой, Управление проектами, Управление продуктом, DevOps] Практика создания единого шаблона проектов на базе Azure DevOps (TFS)
- [Open source, Законодательство в IT, Биографии гиков, IT-компании] Очередная акция противников RMS, на этот раз против фонда GNU
- [Системное администрирование, Kubernetes] 29 апреля состоится Online Monitoring Meetup, Kubernetes: мониторинг c помощью Prometheus
- [Open source, Разработка под Linux, Софт] Линус Торвальдс остался недоволен рядом моментов в использовании Rust для Linux
- [Программирование, DevOps] 20 лучших практик по работе с Docker-файлами (перевод)
- [Open source, Разработка под Linux, Софт] Вышел FreeBSD 13.0
- [Open source, Программирование, Dart, Flutter] Повышаем качество кода с Dart Code Metrics
Теги для поиска: #_open_source, #_devops, #_kubernetes, #_gitlab, #_kubernetes, #_registry, #_opensourse, #_open_source, #_devops, #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:08
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В наше время в каждом доме по кластеру kubernetes, выкатка приложений в кластер осуществляется по тегу. Образ выкатываемого приложения отправляется тегом в репозиторий проекта Registry GitLab, которое постепенно распухает до невероятных размеров.  Существующие решения
 ПодготовкаЛюбая разумная деятельность должна начинаться со сбора информации. Поэтому первым делом сканим или проводим опрос всех до кого можем дотянуться, не хранит ли кто-нибудь в проектах образов, которые не работают в постоянном режиме (образы от Job, CronJob или просто склад полезных образов). Внимательно записываем в книжечку проекты, которые лучше не трогать. Настраиваем сборщик мусора GitLab Теги в GitLab registry ссылаются на образы, а образы используют слои.Если почистить только теги, сильного прироста свободного места мы не получим.Поэтому рекомендую вставить в расписание сron команду для удаления образов, не имеющих тегов sudo gitlab-ctl registry-garbage-collect
sudo gitlab-ctl registry-garbage-collect -m
sudo vi /etc/gitlab/gitlab.rb
registry['storage'] = {
'maintenance' => { 'readonly' => { 'enabled' => true } } } sudo gitlab-ctl reconfigure
{
"location": "mygitlab.abc.ru:3000/dev/my-awsome-app/base:deploy_123", "name": "deploy_123", "path": "dev/my-awsome-app/base:deploy_123" }  Для полной автоматизации все это можно запихнуть в контейнер, создать на это дело CronJob или Job. Только не забудьте добавить этот проект в исключения.Автоматизация написана на python, но это не столь принципиально. Можно значительно сократить размер кода и затраты памяти, если чуть чуть подумать. =========== Источник: habr.com =========== Похожие новости:
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:08
Часовой пояс: UTC + 5