Reg Organizer: Автоматическая очистка реестра и оптимизация реестра в Windows 7

На примере недавно вышедшей новой версии Reg Organizer я начинаю серию обзоров по работе с реестром. В течение 6 недель я познакомлю вас со всеми возможностями программы и расскажу о плюсах каждой функции, имеющейся в ней. Как видно из названия, сегодня речь пойдёт об автоматизированных опциях по очистке и оптимизации системного реестра Windows, которые помогут избавиться от лишнего мусора в системной реестре.

Напомню, 5 версия Reg Organizer обладает поддержкой Windows 7 как 32-битной версии, так и 64-битной.

Итак, первая функция «Автоматическая чистка реестра» для удаления и исправления нерабочих ярлыков, ключей и прочего. Программа пробегается по 20 разделам реестра в поисках мусора, указывает на количество ошибок и на финише предлагает исправить найденные проблемы. Для исправления в Reg Organizer вам понадобится лицензионный ключ, проверка же проходит в демонстрационном режиме.

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

Исправив все ошибки, Reg Organizer предупредит вас о созданной резервной копии удалённых и исправленных ярлыков, которую всегда можно восстановить через «Команды» — «Резервные копии», там же можно их и удалить.

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

Для опытных пользователей представлены настройки по отключению проверки нескольких разделов, внесению дополнительных исключений и отключению игнорирования ссылок на CD-rom. RAM-диски, несуществующие устройства, гибкие или иные съёмные диски и удалённые (сетевые) ссылки.

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

Функция позволяет разложить всё «по полочкам», на финише показать место освободившееся после оптимизации, а далее программа предложит перезагрузиться с целью применения изменений.

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

Скачать Reg Organizer 5.0

Реестр Windows — что это и нужно ли его чистить?

1. ЧТО ТАКОЕ РЕЕСТР WINDOWS?
2. ПРИМЕР ИСПОЛЬЗОВАНИЯ РЕЕСТРА
3. ЗАЧЕМ И ОТ ЧЕГО ОЧИЩАТЬ РЕЕСТР?
4. КАК ЧАСТО НУЖНО ЧИСТИТЬ РЕЕСТР?
5. АВТОМАТИЧЕСКАЯ ОЧИСТКА РЕЕСТРА WINDOWS
6. РУЧНАЯ ЧИСТКА РЕЕСТРА WINDOWS
7. КАК ВЫПОЛНИТЬ ЧИСТКУ РЕЕСТРА ПРИ ПОМОЩИ ПРОГРАММЫ?
8. КАК ВЫПОЛНИТЬ ОЧИСТКУ РЕЕСТРА ВРУЧНУЮ?

Любая опубликованная в интернете статья или инструкция, посвященная оптимизации компьютера и операционной системы, непременно затрагивает реестр Windows. Устранение различных системных неполадок, ручная перенастройка каких-либо параметров системы и многие другие вопросы также связаны с реестром. Что же это такое? Нужно ли периодически чистить реестр?

ЧТО ТАКОЕ РЕЕСТР WINDOWS?

Вы будете правы, если сравните реестр Windows с любым другим реестром из реальной жизни. Возьмем для примера библиотеку. Все имеющиеся в ее распоряжении книги хранятся в отведенных специально для них отделах. Чтобы быстро найти ту или иную книгу, библиотекарь заглядывает в реестр, в который занесена вся необходимая информация — год издания, автор, отдел хранения или даже номер стойки/полки.

Реестр Windows — практически то же самое, но куда более сложный по своей структуре и архитектуре. По сути, он является базой данных, состоящей из тысяч записей. Все они (по крайней мере, те, что были внесены первоначально при установке Windows) необходимы системе для функционирования. К примеру, в реестре хранятся:

• Параметры практически всех ключевых системных компонентов, например — настройки брандмауэра, сетевых подключений, учетных записей пользователей и многое другое.
• Список установленных драйверов и программ, включая их собственные параметры.
• Имена и пути к файлам и папкам, хранящимся на жестком диске.
• Ассоциации типов файлов с приложениями, использующимися для их открытия (благодаря этому мы можем, к примеру, запустить воспроизведение фильма в проигрывателе, просто кликнув пару раз по ассоциированному с ним файлу).
• Параметры и информация о физических устройствах, подключенных к компьютеру, и многое-многое другое.

Мы не будем рассматривать, каким именно образом организуются записи в реестре, какого типа и формата они бывают, т.к. это отдельная большая тема.

ПРИМЕР ИСПОЛЬЗОВАНИЯ РЕЕСТРА

Для лучшего понимания предназначения реестра Windows достаточно заглянуть в него:

• Нажмите на клавиатуре комбинацию клавиш Win + R
  , затем скопируйте в открывшееся окно «Выполнить» команду regedit, после — нажмите «ОК».

• Запустится системное приложение «Редактор реестра». Обращаем внимание, что данная программа не является самим реестром, она просто используется для его просмотра и редактирования. Сам же реестр физически хранится на жестком диске в системном разделе, и состоит он из нескольких взаимосвязанных файлов.

• Давайте посмотрим список программ, загружающихся при старте операционной системы (т. е. программ, занесенных в список автозагрузок). Для этого, используя древо каталогов в левой части окна, последовательно откройте следующие разделы реестра:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

• Все записи реестра, расположенные в разделе «Run», носят информацию о программах, которые система будет запускать при старте. В нашем случае это всего одна запись (не считая запись «(По умолчанию)», присутствующая в любом разделе):

• Кликните мышкой два раза по любой из записей. Откроется окно редактирования этой записи:

• Обратите внимание на поле «Значение». В нем указан путь до программы, помещенной в список автозагрузки. Если изменить хотя бы 1 символ в этой записи или вовсе удалить ее, то приложение перестанет запускаться при загрузке Windows.

Если вернуться в раздел:

HKEY_CURRENT_USER\SOFTWARE

Тогда можно будет увидеть вообще весь список установленных (и даже уже удаленных) на компьютер программ:

На изображении выше мы перешли в раздел реестра, посвященный программе-архиватору 7-Zip. В корневом каталоге хранится информация о расположении исполнимых EXE-файлов архиватора. Эти и им подобные записи требуются для запуска 7-Zip (или другой программы) при открытии ассоциированных с ним файлов.

ЗАЧЕМ И ОТ ЧЕГО ОЧИЩАТЬ РЕЕСТР?

Недостаток это или нет, но в реестре Windows могут вечно храниться данные, которые более уже не нужны. Например, в том же разделе «HKEY_CURRENT_USER\SOFTWARE» можно найти каталоги с названиями давно удаленных программ. И таких «мертвых» записей в реестре могут быть сотни. Запущенная один раз программа, может сделать в реестре кучу записей, вторая такая куча делается и самой системой для своих нужд.

Удаляя приложение, далеко не всегда удаляются и связанные с ней записи. Даже при повторной установки этой же программы и при повторной ее деинсталляции в реестр вновь и вновь будет заноситься информация. Со временем записей в реестре станет настолько много, что для обнаружения нужной будет затрачиваться все больше времени. И это не только причина снижения производительности системы, но и причина системных сбоев и возникновения всевозможных ошибок в работе тех или иных программ, драйверов, устройств и т. д.

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

КАК ЧАСТО НУЖНО ЧИСТИТЬ РЕЕСТР?

Универсального ответа на данный вопрос не существует. Все зависит от того, какими темпами системный реестр заполняется всевозможными мусорными данными. Если пользователь использует компьютер только для выполнения узкого спектра задач (например, работает с офисными документами в рамках профессиональной деятельности), то реестр, скорее всего, не придется чистить никогда.

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

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

АВТОМАТИЧЕСКАЯ ОЧИСТКА РЕЕСТРА WINDOWS

Данный способ наиболее простой и быстрый. Несмотря на заявления разработчиков таких утилит о 100% безопасности использования их продукта, существует риск удаления из реестра нужных системе или каким-либо программам записей.

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

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

РУЧНАЯ ЧИСТКА РЕЕСТРА WINDOWS

Чистить реестр вручную — довольно кропотливое мероприятие. Процесс сводится к тому, что пользователь сначала ищет удаляемые записи или разделы реестра, затем по одной/одному удаляет их. В приложении «Редактор реестра» предусмотрена функция поиска записей/разделов/содержимое записей только по их названию/тексту. Т.е. найти мусорные записи, не зная заранее их названия или содержимое, никак не получится.

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

КАК ВЫПОЛНИТЬ ЧИСТКУ РЕЕСТРА ПРИ ПОМОЩИ ПРОГРАММЫ?

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

Возьмем, к примеру, популярную программу CCleaner. Одной из функций программы является как раз чистка реестра. Так выглядит соответствующая вкладка CCleaner:

В левой части окна можно выбрать параметры сканирования системного реестра. Мы оставили все как есть, и выполнили сканирование. Результат получился следующим:

В списке «Проблем» указаны сотни записей — ошибки, неверные пути, неиспользуемые расширения файлов и т.д. и т.п. Остается кликнуть по кнопке «Исправить выбранное…», и через несколько секунд CCleaner очистит реестр от мусора (по его мнению). Желательно, конечно, предварительно изучить все, что утилита отнесла к мусорным записям, а только потом отдавать программе команду на удаление.

Рассмотрим еще одну программу — Advanced SystemCare. Так выглядит основное окно утилиты перед запуском функции сканирования реестра (обратите внимание, что сняты все галочки, кроме нужной нам одной):

А вот и результат сканирования:

Довольно много, по мнению Advanced SystemCare, ошибочных/мусорных записей накопилось на отсканированном компьютере. К сожалению, CCleaner не показывает количество мусора, потому результаты сканирования точно сравнить не удалось, но на первый взгляд Advanced SystemCare нашел больше мусора. Т.е. то, что последняя программа считает мусором, CCleaner таковым не считает. Что и требовалось доказать — каких-либо универсальных средств очистки реестра не существует.

КАК ВЫПОЛНИТЬ ОЧИСТКУ РЕЕСТРА ВРУЧНУЮ?

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

Делается это следующим образом:

• Запустите «Редактор реестра» вышеописанным способом.
• В окне редактора нажмите клавиши «Ctrl + F» или откройте меню «Правка» и выберите в нем пункт «Найти». Откроется окно поиска:

• Введите в поле «Найти» название программы или хотя бы ее часть, затем кликните кнопку «Найти далее». В качестве примера мы введем в окно поиска запрос «pcloud».

• Через несколько секунд найденная в реестре запись отобразится в правой части окна редактора.

• Выделите эту запись и нажмите клавишу «Delete». Согласитесь с удалением.

• Теперь нажмите клавишу «F3» или выберите в меню «Правка» пункт «Найти далее…».

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

• Выделите ее, удалите, вновь нажмите «F3». Повторяйте эти действия, пока после очередного нажатия «F3» на экране не отобразится сообщение о завершении поиска.

Теперь вся информация об удаленной ранее программе будет стерта из реестра, и можно будет устанавливать ее вновь.

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

Очистить теги и манифесты — Реестр контейнеров Azure

• Статья
• 30.03.2023
• 7 минут на чтение

Когда вы используете реестр контейнеров Azure как часть рабочего процесса разработки, реестр может быстро заполниться изображениями или другими артефактами, которые не нужны через короткий промежуток времени. Возможно, вы захотите удалить все теги, которые старше определенной продолжительности или соответствуют указанному фильтру имен. Чтобы быстро удалить несколько артефактов, в этой статье представлены 9Команда 0015 acr purge , которую можно запустить как задачу ACR по запросу или по расписанию.

Команда acr purge в настоящее время распространяется в общедоступном образе контейнера ( mcr. microsoft.com/acr/acr-cli:0.5 ), созданном из исходного кода в репозитории acr-cli на GitHub. acr Purge в настоящее время находится в предварительной версии.

Вы можете использовать Azure Cloud Shell или локальную установку Azure CLI для выполнения примеров задач ACR в этой статье. Если вы хотите использовать его локально, требуется версия 2.0.76 или более поздняя. Выполнить az --version , чтобы найти версию. Если вам нужно установить или обновить, см. раздел Установка Azure CLI.

Предупреждение

Используйте команду acr purge с осторожностью — удаленные данные изображения НЕВОССТАНОВИМЫ. Если у вас есть системы, которые извлекают образы по дайджесту манифеста (а не по имени образа), вам не следует очищать непомеченные образы. Удаление непомеченных образов не позволит этим системам извлекать образы из вашего реестра. Вместо того, чтобы вытягивать по манифесту, рассмотрите возможность принятия 9Схема уникальной маркировки 0035

, рекомендованная передовая практика.

Если вы хотите удалить теги или манифесты отдельных образов с помощью команд Azure CLI, см. раздел Удаление образов контейнеров в Реестре контейнеров Azure.

Используйте команду очистки

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

Примечание

Очистка acr не удаляет тег изображения или репозиторий, если для атрибута

с возможностью записи установлено значение false . Дополнительные сведения см. в разделе Блокировка образа контейнера в реестре контейнеров Azure.

acr purge предназначен для запуска в качестве контейнерной команды в задаче ACR, поэтому он автоматически аутентифицируется в реестре, в котором выполняется задача, и выполняет там действия. В примерах задач в этой статье используется продувка acr 9.Псевдоним команды 0016 вместо полной команды образа контейнера.

Important

• Стандартная команда для выполнения очистки acr : az acr run --registry <ВАШ_РЕГИСТР> --cmd 'acr purge -- необязательный параметр' /dev/null .
• Мы рекомендуем выполнить полную команду acr purge , чтобы использовать очистку ACR. Например, запустите
  acr purge --help as az acr run --registry <ВАШ_РЕГИСТР> --cmd 'acr purge --help' /dev/null 91.*" соответствует тегам, начинающимся с 1 в репозитории hello-world , а --filter ".*/cache:.*" соответствует всем тегам в репозиториях, заканчивающихся на /cache . Вы также может передавать несколько параметров --filter .
• --ago — Строка длительности в стиле Go для указания продолжительности, после которой изображения удаляются. Продолжительность состоит из последовательности одного или нескольких десятичных чисел, каждое из которых имеет суффикс единицы. Допустимые единицы времени включают «д» для дней, «ч» для часов и «м» для минут. Например, --ago 2d3h6m выбирает все отфильтрованные изображения, которые последний раз изменялись более двух дней, 3 часов и 6 минут назад, а --ago 1.5h выбирает изображения, которые последний раз изменялись более 1,5 часов назад.

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

• --untagged — указывает, что все манифесты, не имеющие связанных тегов ( манифесты без тегов ), удаляются. Этот параметр также удаляет непомеченные манифесты в дополнение к тегам, которые уже удаляются.
• --dry-run — Указывает, что данные не удаляются, но вывод такой же, как если бы команда выполнялась без этого флага. Этот параметр полезен для тестирования команды очистки, чтобы убедиться, что она не удалит непреднамеренно данные, которые вы хотите сохранить.
• --keep — Указывает, что последние x тегов, подлежащих удалению, сохраняются.
• --concurrency — указывает количество задач очистки для одновременной обработки. Если этот параметр не указан, используется значение по умолчанию.

Примечание

Фильтр --untagged не отвечает фильтру --ago . Для получения дополнительных параметров запустите acr purge --help .

acr purge поддерживает другие функции команд задач ACR, включая переменные выполнения и журналы выполнения задач, которые передаются в потоковом режиме, а также сохраняются для последующего извлечения.

Запуск задачи по запросу

В следующем примере команда az acr run используется для запуска команды acr purge по запросу. В этом примере удаляются все теги изображений и манифесты в 9Репозиторий 0015 hello-world в myregistry , который был изменен более 1 дня назад, и все непомеченные манифесты. Команда контейнера передается с использованием переменной среды. Задача выполняется без исходного контекста.

 # Переменная среды для командной строки контейнера
PURGE_CMD="acr purge --filter 'hello-world:.*' \
  --untagged --ago 1d"
аз акр бег \
  --cmd "$PURGE_CMD" \
  --registry myregistry \
  /dev/ноль
 

Запуск запланированной задачи

В следующем примере команда создания задачи az acr используется для создания ежедневной запланированной задачи ACR. Задача удаляет теги, измененные более 7 дней назад в репозиторий hello-world . Команда контейнера передается с использованием переменной среды. Задача выполняется без исходного контекста.

 # Переменная среды для командной строки контейнера
PURGE_CMD="acr purge --filter 'hello-world:.*' \
  --назад 7д"
создать задачу az acr --name purgeTask \
  --cmd "$PURGE_CMD" \
  --schedule "0 0 * * *" \
  --registry myregistry \
  --контекст /dev/null
 

Запустите команду az acr task show, чтобы убедиться, что триггер таймера настроен.

Удаление большого количества тегов и манифестов

Очистка большого количества тегов и манифестов может занять несколько минут или больше. Чтобы очистить тысячи тегов и манифестов, команде может потребоваться больше времени ожидания, чем время ожидания по умолчанию, составляющее 600 секунд для задачи по требованию или 3600 секунд для запланированной задачи. Если время ожидания превышено, удаляется только подмножество тегов и манифестов. Чтобы убедиться, что крупномасштабная очистка завершена, передайте параметр --timeout , чтобы увеличить значение.

Например, следующая задача по запросу устанавливает время ожидания 3600 секунд (1 час):

 # Переменная среды для командной строки контейнера
PURGE_CMD="acr purge --filter 'hello-world:.*' \
  --назад 1д --без тегов"
аз акр бег \
  --cmd "$PURGE_CMD" \
  --registry myregistry \
  --тайм-аут 3600 \
  /dev/ноль
 

Пример: запланированная очистка нескольких репозиториев в реестре

В этом примере показано использование acr purge для периодической очистки нескольких репозиториев в реестре. Например, у вас может быть конвейер разработки, который отправляет изображения на сервер 9.0015 сэмплов/devimage1 и сэмплов/devimage2 репозиториев. Вы периодически импортируете образы для разработки в производственный репозиторий для своих развертываний, поэтому образы для разработки вам больше не нужны. Еженедельно вы очищаете репозитории Samples/devimage1 и Samples/devimage2 , готовясь к работе на следующей неделе.

Предварительный просмотр очистки

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

В следующем примере фильтр в каждом репозитории выбирает все теги. Параметр --ago 0d сопоставляет изображения всех возрастов в репозиториях, соответствующих фильтрам. Измените критерии выбора в соответствии с вашим сценарием. Параметр --untagged указывает на удаление манифестов в дополнение к тегам. Команда container передается команде запуска az acr с использованием переменной среды.

 # Переменная среды для командной строки контейнера
PURGE_CMD="очистка ACR \
  --filter 'samples/devimage1:.*' --filter 'samples/devimage2:.*' \
  --ago 0d --untagged --dry-run"
аз акр бег \
  --cmd "$PURGE_CMD" \
  --registry myregistry \
  /dev/ноль
 

Просмотрите выходные данные команды, чтобы увидеть теги и манифесты, соответствующие параметрам выбора. Поскольку команда запускается с параметром --dry-run , данные не удаляются.

Пример вывода:

 [...]
Удаление тегов для репозитория: Samples/devimage1
myregistry.azurecr.io/samples/devimage1:232889б
myregistry.azurecr.io/samples/devimage1:a21776a
Удаление манифестов для репозитория: Samples/devimage1
myregistry.azurecr.io/samples/devimage1@sha256:81b6f9c92844bbbb5d0a101b22f7c2a7949e40f8ea90c8b3bc396879d95e788b
myregistry. azurecr.io/samples/devimage1@sha256:3ded859790e68bd02791a972ab0bae727231dc8746f233a7949e40f8ea90c8b3
Удаление тегов для репозитория: Samples/devimage2
myregistry.azurecr.io/samples/devimage2:5e788ba
myregistry.azurecr.io/samples/devimage2:f336b7c
Удаление манифестов для репозитория: Samples/devimage2
myregistry.azurecr.io/samples/devimage2@sha256:8d2527cde610e1715ad095cb12bc7ed169b60c495e5428eefdf336b7cb7c0371
myregistry.azurecr.io/samples/devimage2@sha256:ca86b078f89607bc03ded859790e68bd02791a972ab0bae727231dc8746f233a
Количество удаленных тегов: 4
Количество удаленных манифестов: 4
[...]
 

Запланируйте очистку

После проверки пробного прогона создайте запланированное задание для автоматизации очистки. В следующем примере еженедельная задача запланирована на воскресенье в 1:00 UTC для запуска предыдущей команды очистки:

 # Переменная среды для командной строки контейнера
PURGE_CMD="очистка ACR \
  --filter 'samples/devimage1:.*' --filter 'samples/devimage2:. *' \
  --назад 0d --без тегов"
создать задачу az acr --name weeklyPurgeTask \
  --cmd "$PURGE_CMD" \
  --schedule "0 1 * * Вс" \
  --registry myregistry \
  --контекст /dev/null
 

Запустите команду az acr task show, чтобы убедиться, что триггер таймера настроен.

Следующие шаги

Узнайте о других вариантах удаления данных изображения в Реестре контейнеров Azure.

Дополнительные сведения о хранилище образов см. в разделе Хранилище образов контейнеров в Реестре контейнеров Azure.

Уменьшить хранилище реестра контейнеров | GitLab

• Проверить использование хранилища реестра контейнеров
• Политика очистки
  • Включить политику очистки
  • Как работает Политика очистки
    • Пример политики очистки. Рабочий процесс
  • Создайте политику очистки
  • Примеры картины режима
  • Установите лимиты очистки для сохранения ресурсов
  • Использование политики очистки
  • Использование с внешними контейнерами
• . Дополнительные варианты сокращения хранилища Container Registry
• Устранение неполадок политик очистки
  • Произошла ошибка при обновлении политики очистки.
  • Политика очистки не удаляет никакие теги

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

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

Вам следует удалить ненужные изображения и теги и настроить политику очистки для автоматического управления использованием реестра контейнеров.

Проверка использования хранилища реестра контейнеров

На странице «Квоты на использование» ( Настройки > Квоты на использование > Хранилище ) отображается использование хранилища для пакетов. На этой странице показано использование Container Registry, которое доступно только на GitLab. com. Измерение использования возможно только в новой версии GitLab Container Registry, поддерживаемой база данных метаданных. Поддержка улучшений предлагается в эпике 5523. В самоуправляемых экземплярах вы не можете использовать Container Registry с базой данных метаданных. План по изменению этого поведения см. в эпике 5521.

Слои изображений, хранящиеся в реестре контейнеров, дедуплицируются на уровне корневого пространства имен.

Изображение считается только один раз, если:

• Вы помечаете одно и то же изображение более одного раза в одном репозитории.
• Вы помечаете одно и то же изображение в разных репозиториях в одном и том же корневом пространстве имен.

Слой изображения учитывается только один раз, если:

• Вы используете слой изображения совместно с несколькими изображениями в одном репозитории контейнера, проекте или группе.
• Вы делитесь слоем изображения с разными репозиториями.

Учитываются только слои, на которые ссылаются изображения с тегами. Изображения без тегов и любые слои на которые ссылаются исключительно они, подлежат онлайн-сборке мусора. Изображения без тегов автоматически удаляются через 24 часа, если в течение этого периода на них не ссылались.

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

Политика очистки

История версий

• В GitLab 13.2 переименован с «политики срока действия» на «политику очистки».
• Требуемые разрешения изменены с разработчика на сопровождающего в GitLab 15.0.

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

Чтобы удалить нижележащие слои и изображения, не связанные ни с какими тегами, администраторы могут использовать сбор мусора с -м переключатель.

Включить политику очистки

Вы можете запускать политики очистки для всех проектов, за исключением следующих:

• Для самоуправляемых экземпляров GitLab проект должен быть создан в GitLab 12.8 или новее. Однако администратор может включить политику очистки. для всех проектов (даже созданных до GitLab 12.8) в Настройки приложения GitLab установив для container_expiration_policies_enable_historic_entries значение true. Кроме того, вы можете выполнить следующую команду в консоли Rails:

   ApplicationSetting.last.update (container_expiration_policies_enable_historic_entries: true)
   

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

предупреждение

Из соображений производительности включенные политики очистки автоматически отключаются для проектов на GitLab. com, у которых нет образа контейнера.

Как работает политика очистки

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

Политика очистки ищет изображения на основе имени тега. Поддержка полного сопоставления путей отслеживается в выпуске 281071.

Политика очистки:

1. Собирает все теги для данного репозитория в список.
2. Исключает тег с именем последний .
3. Оценивает name_regex (теги со сроком действия), исключая несовпадающие имена.
4. Исключает все теги, соответствующие значению name_regex_keep (теги, которые необходимо сохранить).
5. Исключает любые теги, не имеющие манифеста (не являющиеся частью параметров пользовательского интерфейса).
6. Заказывает остальные теги до created_date .
7. Исключает N тегов на основе значения keep_n (Количество сохраняемых тегов).
8. Исключает более поздние теги, чем значение old_than (интервал срока действия).
9. Удаляет оставшиеся теги в списке из реестра контейнеров.

Внимание

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

осторожность

Самоуправляемые установки GitLab поддерживают сторонние реестры контейнеров, соответствующие HTTP-API реестра Docker V2 Спецификация. Однако эта спецификация не включает операцию удаления тега. Поэтому GitLab использует обходной путь для удаления тегов при взаимодействии со сторонними реестрами контейнеров. Ссылаться на выпуск 15737 Чтобы получить больше информации. Из-за возможных вариаций реализации этот обходной путь не гарантируется. одинаково предсказуемо работать со всеми сторонними реестрами. Если вы используете контейнер GitLab Registry, этот обходной путь не требуется, поскольку мы реализовали специальную операцию удаления тега. В В этом случае можно ожидать, что политики очистки будут последовательными и предсказуемыми.

Пример рабочего процесса политики очистки

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

• Сохранить самые последние : 1 тег на имя изображения.
• Сохранить соответствие тегов : production-.*
• Удалить теги старше : 7 дней.
• Удалить теги, соответствующие : .* .

И репозиторий контейнеров с этими тегами:

• последний , опубликованный 2 часа назад.
• production-v44 , опубликовано 3 дня назад.
• production-v43 , опубликовано 6 дней назад.
• production-v42 , опубликовано 11 дней назад.
• dev-v44 , опубликовано 2 дня назад.
• dev-v43 , опубликовано 5 дней назад.
• dev-v42 , опубликовано 10 дней назад.
• v44 , опубликовано вчера.
• v43 , опубликовано 12 дней назад.
• v42 , опубликовано 20 дней назад.

В этом примере при следующем запуске очистки будут удалены теги dev-v42 , v43 и v42 . Вы можете интерпретировать правила как применяемые с таким приоритетом:

1. Правила хранения имеют наивысший приоритет. Теги должны быть сохранены, если они соответствуют любому правилу .
   • Необходимо сохранить последний тег , поскольку последних тегов сохраняются всегда.
   • Теги production-v44 , production-v43 и production-v42 должны быть сохранены, потому что они соответствуют правилу «Сохранить теги, соответствующие правилу ».
   • Тег v44 необходимо сохранить, поскольку он является самым последним и соответствует правилу Сохранить самое последнее .
2. Правила удаления имеют более низкий приоритет, а теги удаляются, только если все правила совпадают. Для тегов, не соответствующих правилам сохранения ( dev-44 , dev-v43 , dev-v42 , v43 и v42 ):
   • dev-44 и dev-43 делают не соответствуют Удалить теги старше и сохранить.
   • dev-v42 , v43 и v42 соответствуют обоим Удалить теги старше и Удалить теги, соответствующие правил, поэтому эти три тега можно удалить.

Создать политику очистки

Политику очистки можно создать в API или пользовательском интерфейсе.

Чтобы создать политику очистки в пользовательском интерфейсе:

1. Для вашего проекта перейдите к Настройки > Пакеты и реестры .
2. Разверните раздел Очистить теги изображений .

3. Заполните поля.

   Поле	Описание
   Переключатель	Включение или отключение политики.
   Выполнить очистку	Как часто должна выполняться политика.
   Сохранить самые последние	Сколько тегов до всегда держать для каждого изображения.
   Сохранить соответствие тегов	Шаблон регулярного выражения, который определяет, какие теги следует сохранить. Всегда сохраняется последний тег . Для всех тегов используйте .* . См. другие примеры шаблонов регулярных выражений.
   Удалить теги старше	Удалить только теги старше X дней.
   Удалить теги, соответствующие	Шаблон регулярного выражения, который определяет, какие теги следует удалить. Это значение не может быть пустым. Для всех тегов используйте .* . См. другие примеры шаблонов регулярных выражений.

4. Выберите Сохранить .

Политика запускается через выбранный вами интервал времени.

примечание

Если отредактировать политику и выбрать 9 или токенов $ в шаблонах регулярных выражений.

Вот несколько примеров шаблонов регулярных выражений, которые вы можете использовать:

• Совпадение со всеми тегами:

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

• Соответствие тегам, начинающимся с и :

• Соответствует только тегу с именем main :

• Соответствие тегам, которые либо названы, либо начинаются с версии :

   версии.*
   

• Теги соответствия, которые либо начинаются с v , называются main , либо начинаются с release :

   (?:v. +|main|release.*)
   

Установите пределы очистки для экономии ресурсов

История версий

• Представлен в GitLab 13.9 с флагом container_registry_expiration_policies_throttling . Отключено по умолчанию.
• Включено по умолчанию в GitLab 14.9.
• Удален флаг функции container_registry_expiration_policies_throttling в GitLab 15.0.

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

Вы можете использовать следующие параметры приложения, чтобы предотвратить нехватку ресурсов сервера:

• container_registry_expiration_policies_worker_capacity : максимальное количество рабочих процессов очистки работает одновременно. Это значение должно быть больше или равно 0 . Вы должны начать с низкого число и увеличить его после мониторинга ресурсов, используемых фоновыми работниками. Удалять все рабочие и не выполнять политики очистки, установите для этого параметра значение 0 . Значение по умолчанию: 4 .
• container_registry_delete_tags_service_timeout : максимальное время (в секундах), в течение которого выполняется очистка Процесс может занять удаление пакета тегов. Значение по умолчанию — 250 .
• container_registry_cleanup_tags_service_max_list_size : максимальное количество тегов, которое может быть удалены в одном исполнении. Дополнительные теги должны быть удалены в другом исполнении. Вам следует начните с меньшего числа и увеличьте его после проверки правильности образов контейнеров удален. Значение по умолчанию — 200 .
• container_registry_expiration_policies_caching : включить или отключить кэширование метки времени создания тега во время выполнения политик. Кэшированные метки времени хранятся в Redis. Включено по умолчанию.

Для самоуправляемых экземпляров эти настройки можно обновить в консоли Rails:

 ApplicationSetting. last.update(container_registry_expiration_policies_worker_capacity: 3)
 

Они также доступны в области администратора:

1. На верхней панели выберите Главное меню > Администратор .
2. Перейдите к Настройки > CI/CD > Реестр контейнеров .

Использовать API политики очистки

Вы можете устанавливать, обновлять и отключать политики очистки с помощью GitLab API.

Примеры:

• Выбрать все теги, оставить не менее 1 тега на изображение, очистить все теги старше 14 дней, запускать раз в месяц, сохранять любые изображения с именем main и политика включена:

   curl --request PUT --header 'Content-Type: application/json;charset=UTF-8' --header "PRIVATE-TOKEN: " \
       --data-binary '{"container_expiration_policy_attributes":{"cadence":"1month","enabled":true,"keep_n":1,"старше_чем":"14d","name_regex":".*"," name_regex_keep":".*-main"}}' \
       "https://gitlab. example.com/api/v4/projects/2"
   

Допустимые значения для частоты вращения педалей при использовании API:

• 1 день (ежедневно)
• 7 дней (каждую неделю)
• 14 дней (каждые две недели)
• 1 месяц (каждый месяц)
• 3 месяца (каждый квартал)

Допустимые значения для keep_n (количество тегов, сохраняемых для каждого имени изображения) при использовании API:

• 1
• 5
• 10
• 25
• 50
• 100

Достоверные значения для Старшего_THAN . 7d

14d

30d

90d

Дополнительные сведения см. в документации по API: Редактировать API проекта.

Использование с внешними реестрами контейнеров

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

Дополнительные параметры сокращения хранилища реестра контейнеров

Вот некоторые другие параметры, которые вы можете использовать для уменьшения хранилища Container Registry, используемого вашим проектом:

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

Устранение неполадок политик очистки

Что-то пошло не так при обновлении политики очистки.

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

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

Политика очистки не удаляет теги

Этому могут быть разные причины:

• В GitLab 13.6 и более ранних версиях при запуске политики очистки можно ожидать, что она удалит теги и Это не. Это происходит, когда политика очистки сохраняется без редактирования значения в Удалить теги, соответствующие полю . Это поле имеет затененное значение .* в качестве заполнителя. Пока не .* (или другой шаблон регулярного выражения) явно вводится в поле, отправляется значение nil . Это значение предотвращает сопоставление сохраненной политики очистки с какими-либо тегами. В качестве обходного пути отредактируйте политика очистки. В поле Удалить теги, соответствующие , введите .* и сохраните. Это значение указывает что все теги должны быть удалены.

• Если вы используете самоуправляемые инстансы GitLab и у вас более 1000 тегов в репозитории контейнеров, вы может столкнуться с проблемой истечения срока действия токена Container Registry, с ошибкой контекст авторизации: неверный токен в логах.

  Чтобы исправить это, есть два обходных пути:

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

  • Увеличьте задержку истечения срока действия токенов аутентификации Container Registry. По умолчанию это 5 минут. Вы можете установить пользовательское значение, запустив ApplicationSetting. last.update(container_registry_token_expire_delay: ) в Rails console, где — желаемое количество минут. Для справки, задержка истечения на GitLab.com установлено значение 15 минут. Если вы увеличиваете это значение, вы увеличиваете время, необходимое для отзыва разрешений.

Кроме того, вы можете создать список тегов для удаления и использовать этот список для удаления теги. Чтобы создать список и удалить теги:

1. Запустите следующий сценарий оболочки. Команда непосредственно перед циклом for гарантирует, что list_o_tags.out всегда повторно инициализируется при запуске цикла. После выполнения этой команды все имена тегов записываются в файл list_o_tags.out :

    # Получить список всех тегов в определенном репозитории контейнера с учетом [pagination](../../../api/rest/index. md#разбиение на страницы)
   echo -n "" > list_o_tags.out; для i в {1..N}; do curl --header 'PRIVATE-TOKEN: ' "https://gitlab. .\(.*\).$:\1:' >> list_o_tags.out; сделанный
    

   Если у вас есть доступ к консоли Rails, вы можете ввести следующие команды для получения списка тегов, ограниченных датой:

    output = File.open( "/tmp/list_o_tags.out","w" )
   Project.find().container_repositories.find().tags.each do |tag|
     output << tag.name + "\n", если tag.created_at < 1.month.ago
   конец; ноль
   выход.закрыть
    

   Этот набор команд создает файл /tmp/list_o_tags.out со списком всех тегов с created_at 9Av/d' list_o_tags.out # Удалите теги, оканчивающиеся на `_v3`, из файла sed -i .bak '/_v3$/d' list_o_tags.out

2. Дважды проверьте файл list_o_tags.out , чтобы убедиться, что он содержит только те теги, которые вы хотите удалить.

3. Запустите этот сценарий оболочки, чтобы удалить теги в файле list_o_tags.out :

    # цикл по list_o_tags.out для удаления одного тега за раз
   при чтении -r СТРОКА || [[ -n $LINE ]]; сделать эхо ${LINE}; curl --request DELETE --header 'PRIVATE-TOKEN: ' "https://gitlab.