Поиск по сайту:

Как собрать мусор в реестре контейнеров GitLab, чтобы освободить хранилище


Реестр контейнеров GitLab предоставляет удобное место для хранения образов Docker. Со временем Container Registry может занять место на диске по мере добавления дополнительных слоев. Вот как можно освободить хранилище, удалив избыточный материал.

Реестр контейнеров позволяет хранить образы Docker вместе с исходным кодом вашего проекта. Если вы храните большие образы в своем реестре, вы можете обнаружить, что стоимость хранения быстро превышает ваши ожидания. GitLab сохраняет каждый слой на неопределенный срок, даже после того, как он станет избыточным.

Настройка политики очистки

Первым шагом в восстановлении места для хранения является настройка политики очистки реестра контейнеров. Политики очистки применяются индивидуально к каждому проекту. Это означает, что вы можете настроить период хранения в соответствии с каждой кодовой базой.

Зайдите в свой проект в GitLab и нажмите ссылку «Настройки» на боковой панели. Перейдите в категорию «CI/CD» и разверните раздел «Очистить теги изображений» в нижней части страницы.

Переключите кнопку «Включено» во включенное положение, чтобы активировать политику очистки. Затем выберите, когда запускать политику — «каждый день» — хороший вариант по умолчанию.

Следующий раздел «Сохранить эти теги» позволяет вам определить теги, которые политика очистки оставит в покое. Два параметра «сохранить самые последние» и «сохранить совпадение тегов» не зависят друг от друга. Вы можете сохранить теги dev и nightly, дополненные пятью последними тегами. Тег latest всегда включается в дополнение к любым установленным тегам.

Следующий раздел «Удалить эти теги» определяет белый список тегов, которые необходимо удалить. Теги, которые не соответствуют шаблону регулярного выражения, не будут затронуты. Настройте значение «Удалить теги старше», чтобы установить максимальное время жизни каждого тега, прежде чем он будет очищен. Когда закончите, нажмите зеленую кнопку «Сохранить».

Использование API

Применение политик очистки через веб-интерфейс может быстро стать утомительным. Вместо этого используйте API, если вы меняете несколько проектов.

curl --request PUT --header 'Content-Type: application/json;charset=UTF-8' --header "PRIVATE-TOKEN: <access_token>" --data-binary '{"container_expiration_policy_attributes":{"cadence":"1month","enabled":true,"keep_n":1,"older_than":"14d","name_regex":"","name_regex_delete":".*","name_regex_keep":"latest' "https://gitlab.example.com/api/v4/projects/<project_id>"

Вам нужно будет сгенерировать токен доступа к API, перейдя на страницу своего профиля в GitLab. Используйте токен как в приведенной выше команде. Настройте URL-адрес так, чтобы он указывал на ваш проект — его идентификатор можно найти на странице проекта в GitLab.

Выполнение приведенной выше команды применит политику очистки реестра, которая запускается каждый месяц и очищает образы старше 14 дней. Тег latest и самый последний тег (keep_n) будут сохранены; все остальные могут быть удалены (.*).

Эффекты политики очистки

Политика очистки обрабатывает снятие тегов с изображений на основе заданных вами критериев. Теги будут удалены из вашего реестра контейнеров. Они больше не будут отображаться на экране Container Registry вашего проекта и не будут доступны клиентам Docker.

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

Это связано с тем, что слои изображений остаются на вашем сервере GitLab в кэше для дальнейшего использования. Чтобы удалить данные навсегда, вы должны затем запустить процедуру сборки мусора Container Registry.

Вывоз мусора

Запуск сборки мусора удалит все слои изображений, которые не связаны с тегом. Это приведет к удалению изображений, не помеченных вашей политикой очистки. Он также может удалять старые слои, которые стали избыточными, когда вы добавили новую версию тега.

Сборку мусора необходимо запускать вручную через интерфейс командной строки GitLab. Подключитесь к серверу GitLab через SSH и выполните следующую команду:

sudo gitlab-ctl registry-garbage-collect

Будет запущен процесс сборки мусора. Любые неиспользуемые теги в вашем реестре контейнеров будут переработаны. Garbage Collection ищет непомеченные изображения во всем экземпляре GitLab.

Предполагая, что вы разрешили сначала запустить политику очистки, теперь вы должны увидеть здоровое сокращение использования хранилища. Если вы впервые запускаете сборку мусора в часто используемой установке GitLab, возможно, вы освободили несколько гигабайт места.

Удаление непомеченных манифестов и слоев

Вы можете освободить еще больше места, указав сборщику мусора также удалять непомеченные манифесты изображений и слои, на которые нет ссылок. Это более разрушительная операция, хотя обычно это то, что вы ожидаете увидеть.

sudo gitlab-ctl registry-garbage-collect -m

Добавление флага -m удалит любой слой, не связанный напрямую с теговым манифестом изображения. Это приводит к потере кэшированных слоев и промежуточных этапов сборки.

По умолчанию Docker и реестр контейнеров GitLab сохраняют все созданные слои, даже если на них больше нет ссылок. Это означает, что вы всегда можете получить ранее известный слой, используя его уникальный идентификатор с адресацией по содержимому, даже если он больше не имеет тега.

Вот почему удаление этих слоев не включено по умолчанию. Вы должны знать о последствиях перед запуском команды, так как это может иметь серьезные последствия в некоторых рабочих процессах. Тем не менее, использование ключа -m часто бывает желательным — это освободит гораздо больше места на диске и не должно иметь никаких побочных эффектов, если вы ссылаетесь на изображения только с помощью имен тегов.

Запуск сборки мусора по расписанию

Политики очистки запускаются автоматически с настроенной вами периодичностью. Сборка мусора не настроена по умолчанию, поэтому первый запуск может значительно сократить использование хранилища.

Чтобы запустить сборку мусора по расписанию, вам нужно добавить команду в crontab вашей системы. Создайте файл /etc/cron.d/registry-garbage-collection со следующим содержимым, чтобы запускать сборку мусора каждый понедельник в 2 часа ночи:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 2 * * 1  root gitlab-ctl registry-garbage-collect

Ограничения сборки мусора

Время, затрачиваемое на сборку мусора, будет зависеть от объема данных, которые необходимо удалить. Сборка мусора требует, чтобы служба Container Registry была остановлена во время ее работы. Это означает, что ваши пользователи не смогут извлекать или отправлять изображения, пока процесс не завершится.

Вы можете уменьшить влияние простоя, переключив реестр в режим только для чтения, выполнив команду, а затем переключившись обратно в режим чтения-записи. Реестр может продолжать работать, но пользователи не смогут отправлять изображения. Кроме того, переключение режимов требует «перенастройки» GitLab (sudo gitlab-ctl reconfigure), что само по себе может привести к простою в зависимости от того, как настроена ваша установка.

Вам нужно отредактировать следующие строки в /etc/gitlab/gitlab.rb:

registry['storage'] = {
    'maintenance' => {
      'readonly' => {
        'enabled' => true
      }
    }
  }

Запустите sudo gitlab-ctl reconfigure, затем используйте одну из команд сборки мусора. Как только это будет сделано, отключите режим только для чтения, изменив строку enabled в вашем gitlab.rb обратно на false, а затем снова перенастройте GitLab.