Проблемът с "интелигентното" почистване на изображения на контейнери и неговото решение в werf

Статията обсъжда проблема с почистването на изображения, които се натрупват в регистрите на контейнери (Docker Registry и неговите аналози) в реалностите на съвременните CI/CD тръбопроводи за облачни приложения, доставени на Kubernetes. Дадени са основните критерии за уместност на изображенията и произтичащите от това трудности при автоматизирането на почистването, спестяването на място и задоволяването на нуждите на екипите. Накрая, използвайки примера на конкретен проект с отворен код, ще ви кажем как тези трудности могат да бъдат преодолени.

въведение

Броят на изображенията в регистъра на контейнерите може да нараства бързо, заемайки повече място за съхранение и по този начин значително увеличавайки цената му. За да се контролира, ограничи или поддържа приемливо нарастване на пространството, заето в регистъра, се приема:

1. използвайте фиксиран брой тагове за изображения;
2. почистете изображенията по някакъв начин.

Първото ограничение понякога е приемливо за малки екипи. Ако разработчиците имат достатъчно постоянни тагове (latest, main, test, boris и т.н.), регистърът няма да набъбне по размер и за дълго време изобщо няма да се налага да мислите за почистването му. В края на краищата всички неподходящи изображения се изтриват и просто няма работа за почистване (всичко се извършва от обикновен събирач на боклук).

Въпреки това, този подход значително ограничава развитието и рядко е приложим за модерни CI/CD проекти. Неразделна част от разработката беше автоматизация, което ви позволява да тествате, внедрявате и доставяте нова функционалност на потребителите много по-бързо. Например, във всички наши проекти, CI тръбопровод се създава автоматично с всеки ангажимент. В него изображението се сглобява, тества, разгръща към различни вериги на Kubernetes за отстраняване на грешки и оставащи проверки и ако всичко е наред, промените достигат до крайния потребител. И това вече не е ракетна наука, а ежедневие за мнозина - най-вероятно за вас, тъй като четете тази статия.

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

Но как изобщо определяте дали едно изображение е подходящо?

Критерии за релевантност на изображението

В по-голямата част от случаите основните критерии ще бъдат:

1. Първият (най-очевидният и най-критичен от всички) са изображенията, които в момента се използва в Kubernetes. Премахването на тези изображения може да доведе до значителни производствени разходи за престой (например изображенията може да са необходими за репликация) или да отхвърли усилията на екипа за отстраняване на грешки на който и да е от циклите. (По тази причина дори направихме специален Прометей износители, който проследява липсата на такива изображения във всеки клъстер на Kubernetes.)

2. Второ (по-малко очевидно, но също много важно и отново се отнася до експлоатацията) - изображения, които необходимо за връщане назад в случай на откриване на сериозни проблеми в текущата версия. Например, в случая на Helm, това са изображения, които се използват в запазени версии на изданието. (Между другото, по подразбиране в Helm ограничението е 256 ревизии, но е малко вероятно някой наистина да има нужда да запазва това голям брой версии?..) В крайна сметка ние, по-специално, съхраняваме версии, за да можем да ги използваме по-късно, т.е. „връщане“ към тях, ако е необходимо.

3. Трето - нуждите на разработчиците: Всички изображения, които са свързани с текущата им работа. Например, ако обмисляме PR, тогава има смисъл да оставим изображение, съответстващо на последния комит и, да речем, на предишния комит: по този начин разработчикът може бързо да се върне към всяка задача и да работи с най-новите промени.

4. Четвърто - изображения, които отговарят на версиите на нашето приложение, т.е. са крайният продукт: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra и др.

NB: Дефинираните тук критерии са формулирани въз основа на опит във взаимодействие с десетки екипи за разработка от различни компании. Разбира се обаче, в зависимост от спецификата в процесите на разработка и използваната инфраструктура (например не се използва Kubernetes), тези критерии могат да се различават.

Допустимост и съществуващи решения

Популярните услуги с регистри на контейнери като правило предлагат свои собствени правила за почистване на изображения: в тях можете да определите условията, при които етикетът се премахва от регистъра. Тези условия обаче са ограничени от параметри като имена, време на създаване и брой тагове*.

* Зависи от специфични внедрявания на регистър на контейнери. Разгледахме възможностите на следните решения: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbour Registry, JFrog Artifactory, Quay.io - към септември'2020.

Този набор от параметри е напълно достатъчен, за да удовлетвори четвъртия критерий - да изберете изображения, които отговарят на версиите. За всички останали критерии обаче трябва да се избере някакво компромисно решение (по-твърда или, обратно, по-мека политика) - в зависимост от очакванията и финансовите възможности.

Например, третият критерий - свързан с нуждите на разработчиците - може да бъде решен чрез организиране на процеси в рамките на екипи: специфично именуване на изображения, поддържане на специални списъци с разрешени и вътрешни споразумения. Но в крайна сметка все още трябва да се автоматизира. И ако възможностите на готовите решения не са достатъчни, трябва да направите нещо свое.

Ситуацията с първите два критерия е подобна: те не могат да бъдат удовлетворени без получаване на данни от външна система - тази, в която са разположени приложенията (в нашия случай Kubernetes).

Илюстрация на работен процес в Git

Да приемем, че работите нещо подобно в Git:

Иконата с глава в диаграмата показва изображения на контейнери, които в момента са внедрени в Kubernetes за всички потребители (крайни потребители, тестери, мениджъри и т.н.) или се използват от разработчици за отстраняване на грешки и подобни цели.

Какво се случва, ако правилата за почистване позволяват само запазване на изображения (не изтриване) по дадени имена на тагове?

Очевидно подобен сценарий няма да зарадва никого.

Какво ще се промени, ако правилата позволяват изображенията да не се изтриват? според даден интервал от време / брой последни ангажименти?

Резултатът стана много по-добър, но все още е далеч от идеалния. В крайна сметка все още имаме разработчици, които се нуждаят от изображения в регистъра (или дори внедрени в K8s), за да отстраняват грешки...

За да обобщим текущата пазарна ситуация: наличните функции в регистрите на контейнерите не предлагат достатъчно гъвкавост при почистване и основната причина за това е няма начин за взаимодействие с външния свят. Оказва се, че екипи, които изискват такава гъвкавост, са принудени самостоятелно да прилагат изтриване на изображения „отвън“, използвайки API на Docker Registry (или собствения API на съответната реализация).

Ние обаче търсихме универсално решение, което да автоматизира почистването на изображения за различни екипи, използващи различни регистри...

Нашият път към универсално почистване на изображения

Откъде идва тази нужда? Факт е, че ние не сме отделна група разработчици, а екип, който обслужва много от тях едновременно, помагайки за цялостното решаване на проблемите с CI/CD. И основният технически инструмент за това е помощната програма Open Source werf. Неговата особеност е, че той не изпълнява една единствена функция, а съпътства непрекъснатите процеси на доставка на всички етапи: от монтажа до внедряването.

Публикуването на изображения в регистъра* (непосредствено след изграждането им) е очевидна функция на такава помощна програма. И тъй като изображенията се поставят там за съхранение, тогава - ако вашето хранилище не е неограничено - трябва да носите отговорност за последващото им почистване. Как постигнахме успех в това, отговаряйки на всички зададени критерии, ще бъде обсъдено допълнително.

* Въпреки че самите регистри може да са различни (Docker Registry, GitLab Container Registry, Harbor и т.н.), техните потребители се сблъскват със същите проблеми. Универсалното решение в нашия случай не зависи от внедряването на регистъра, т.к работи извън самите регистри и предлага едно и също поведение за всички.

Въпреки че използваме werf като примерна реализация, надяваме се, че използваните подходи ще бъдат полезни за други екипи, изправени пред подобни трудности.

Така че се заехме външен внедряване на механизъм за почистване на изображения - вместо тези възможности, които вече са вградени в регистрите за контейнери. Първата стъпка беше да се използва API на Docker Registry, за да се създадат същите примитивни политики за броя на таговете и времето на тяхното създаване (споменати по-горе). Добавен към тях разрешен списък въз основа на изображения, използвани в разгърната инфраструктура, т.е. Kubernetes. За последното беше достатъчно да използвате API на Kubernetes, за да преминете през всички внедрени ресурси и да получите списък със стойности image.

Това тривиално решение разреши най-критичния проблем (критерий № 1), но беше само началото на нашето пътуване за подобряване на механизма за почистване. Следващата - и много по-интересна - стъпка беше решението асоциирайте публикувани изображения с историята на Git.

Схеми за етикетиране

Като начало избрахме подход, при който крайното изображение трябва да съхранява необходимата информация за почистване, и изградихме процеса върху схеми за маркиране. При публикуване на изображение потребителят е избрал конкретна опция за маркиране (git-branch, git-commit или git-tag) и използва съответната стойност. В CI системите тези стойности бяха зададени автоматично въз основа на променливите на средата. Всъщност крайното изображение беше свързано с конкретен Git примитив, съхранявайки необходимите данни за почистване в етикети.

Този подход доведе до набор от политики, които позволиха Git да се използва като единствен източник на истина:

• При изтриване на клон/етикет в Git, свързаните изображения в регистъра се изтриват автоматично.
• Броят на изображенията, свързани с Git тагове и ангажименти, може да се контролира от броя на таговете, използвани в избраната схема, и времето, в което е създаден асоциираният комит.

Като цяло, получената реализация задоволи нуждите ни, но скоро ни очакваше ново предизвикателство. Факт е, че докато използвахме схеми за маркиране, базирани на примитиви на Git, се натъкнахме на редица недостатъци. (Тъй като тяхното описание е извън обхвата на тази статия, всеки може да се запознае с подробностите тук.) Ето защо, след като решихме да преминем към по-ефективен подход за маркиране (маркиране, базирано на съдържание), трябваше да преразгледаме внедряването на почистване на изображения.

Нов алгоритъм

Защо? С маркиране, базирано на съдържание, всеки етикет може да удовлетвори множество ангажименти в Git. Когато почиствате изображения, вече не можете да предполагате само от ангажимента, където новият етикет е добавен към регистъра.

За новия алгоритъм за почистване беше решено да се отдалечи от схемите за маркиране и да се изгради процес на мета-изображение, всеки от които съхранява куп от:

• ангажиментът, на който е извършена публикацията (няма значение дали изображението е добавено, променено или е останало същото в регистъра на контейнера);
• и нашия вътрешен идентификатор, съответстващ на сглобеното изображение.

С други думи, беше осигурено свързване на публикувани тагове с ангажименти в Git.

Крайна конфигурация и общ алгоритъм

Когато конфигурират почистването, потребителите вече имат достъп до политики, които избират текущи изображения. Всяка такава политика е дефинирана:

• много препратки, т.е. Git тагове или Git разклонения, които се използват по време на сканиране;
• и ограничението на търсените изображения за всяка референция от набора.

За илюстрация, ето как започна да изглежда конфигурацията на правилата по подразбиране:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

Тази конфигурация съдържа три правила, които отговарят на следните правила:

1. Запазете изображението за последните 10 Git тагове (по дата на създаване на тагове).
2. Запазете не повече от 2 изображения, публикувани през последната седмица за не повече от 10 теми с активност през последната седмица.
3. Запазете 10 изображения за клонове main, staging и production.

Крайният алгоритъм се свежда до следните стъпки:

• Извличане на манифести от регистъра на контейнерите.
• С изключение на изображенията, използвани в Kubernetes, защото Вече сме ги избрали предварително чрез проучване на K8s API.
• Сканиране на Git история и изключване на изображения въз основа на определени правила.
• Премахване на останалите изображения.

Връщайки се към нашата илюстрация, ето какво се случва с werf:

Въпреки това, дори и да не използвате werf, подобен подход за разширено почистване на изображения - в една или друга реализация (според предпочитания подход за маркиране на изображения) - може да се приложи към други системи/помощни програми. За да направите това, достатъчно е да запомните проблемите, които възникват, и да намерите онези възможности във вашия стек, които ви позволяват да интегрирате тяхното решение възможно най-гладко. Надяваме се, че пътят, който извървяхме, ще ви помогне да погледнете конкретния си случай с нови подробности и мисли.

Заключение

• Рано или късно повечето екипи се сблъскват с проблема с препълването на регистъра.
• При търсенето на решения е необходимо първо да се определят критериите за уместност на изображението.
• Инструментите, предлагани от популярните услуги за регистър на контейнери, ви позволяват да организирате много просто почистване, което не взема предвид „външния свят“: изображенията, използвани в Kubernetes, и особеностите на работните процеси на екипа.
• Гъвкавият и ефективен алгоритъм трябва да има разбиране за CI/CD процесите и да работи не само с данни за изображения на Docker.

PS

Прочетете също в нашия блог:

• «Тагване, базирано на съдържание в werf builder: защо и как работи?»;
• «3-посочно сливане към werf: внедряване в Kubernetes с Helm „на стероиди“»;
• «Поддръжка за monorepo и multirepo в werf и какво общо има Docker Registry с това»;
• «Версия на werf 1.1: подобрения в създателя днес и планове за бъдещето".

Източник: www.habr.com