Проблемот на „паметно“ чистење на слики од контејнери и негово решение во верф

Написот ги разгледува проблемите со чистењето на сликите што се акумулираат во регистрите на контејнери (Docker Registry и неговите аналози) во реалноста на современите CI/CD цевководи за облак мајчин апликации доставени до Kubernetes. Дадени се главните критериуми за релевантноста на сликите и тешкотиите што произлегуваат од автоматизирањето на чистењето, заштедата на простор и задоволувањето на потребите на тимовите. Конечно, користејќи го примерот на одреден проект со отворен код, ќе ви кажеме како може да се надминат овие тешкотии.

Вовед

Бројот на слики во регистарот на контејнери може брзо да расте, заземајќи повеќе простор за складирање и со тоа значително зголемување на неговата цена. За контрола, ограничување или одржување на прифатлив раст на просторот зафатен во регистарот, прифатено е:

1. користете фиксен број на ознаки за слики;
2. исчистете ги сликите на некој начин.

Првото ограничување понекогаш е прифатливо за мали тимови. Ако програмерите имаат доволно постојани ознаки (latest, main, test, boris итн.), регистарот нема да отече во големина и долго време нема да морате воопшто да размислувате за негово чистење. На крајот на краиштата, сите небитни слики се бришат, а едноставно не останува работа за чистење (се работи од обичен собирач на ѓубре).

Сепак, овој пристап во голема мера го ограничува развојот и ретко е применлив за современи проекти за CI/CD. Составен дел од развојот беше автоматизација, што ви овозможува многу побрзо да тестирате, распоредите и доставувате нова функционалност до корисниците. На пример, во сите наши проекти, CI гасоводот автоматски се креира со секое извршување. Во него, сликата се составува, тестира, се префрла на различни кола на Кубернетс за дебагирање и преостанати проверки, и ако се е во ред, промените стигнуваат до крајниот корисник. И ова веќе не е ракетна наука, туку секојдневна појава за многумина - најверојатно за вас, бидејќи ја читате оваа статија.

Бидејќи поправање грешки и развивање на нова функционалност се врши паралелно, а изданија може да се вршат неколку пати на ден, очигледно е дека процесот на развој е придружен со значителен број на обврски, што значи голем број на слики во регистарот. Како резултат на тоа, се поставува прашањето за организирање ефективно чистење на регистарот, т.е. отстранување на ирелевантни слики.

Но, како воопшто да одредите дали сликата е релевантна?

Критериуми за релевантноста на сликата

Во огромното мнозинство на случаи, главните критериуми ќе бидат:

1. Првата (најочигледна и најкритична од сите) се сликите кои моментално се користи во Kubernetes. Отстранувањето на овие слики може да резултира со значителни трошоци за прекин на производството (на пример, сликите може да бидат потребни за репликација) или да ги негира напорите на тимот што дебагира на која било од циклусите. (Поради оваа причина направивме дури и специјална Прометеј извозник, кој го следи отсуството на такви слики во кој било кластер Кубернет.)

2. Второ (помалку очигледно, но исто така многу важно и повторно се однесува на експлоатација) - слики кои потребни за враќање во случај на откривање на сериозни проблеми во тековната верзија. На пример, во случајот на Helm, ова се слики што се користат во зачуваните верзии на изданието. (Патем, стандардно во Helm границата е 256 ревизии, но малку е веројатно дека некој навистина треба да заштеди како голем број верзии?..) На крајот на краиштата, ние, особено, складираме верзии за да можеме подоцна да ги користиме, т.е. „вратете се“ на нив доколку е потребно.

3. Трето - потребите на програмерите: Сите слики кои се поврзани со нивната тековна работа. На пример, ако размислуваме за ПР, тогаш има смисла да оставиме слика што одговара на последното обврзување и, да речеме, претходното извршување: на овој начин развивачот може брзо да се врати на која било задача и да работи со најновите промени.

4. Четврто - слики кои одговараат на верзиите на нашата апликација, т.е. се финалниот производ: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, итн.

Забелешка: Критериумите дефинирани овде беа формулирани врз основа на искуство во интеракција со десетици развојни тимови од различни компании. Сепак, се разбира, во зависност од спецификите во развојните процеси и користената инфраструктура (на пример, Kubernetes не се користи), овие критериуми може да се разликуваат.

Подобност и постоечки решенија

Популарните услуги со регистри на контејнери, по правило, нудат свои политики за чистење на сликата: во нив можете да ги дефинирате условите под кои ознаката се отстранува од регистарот. Сепак, овие услови се ограничени со параметри како што се имиња, време на создавање и број на ознаки*.

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

Овој сет на параметри е сосема доволен за да го задоволи четвртиот критериум - односно да изберете слики што одговараат на верзиите. Меѓутоа, за сите други критериуми, треба да се избере некакво компромисно решение (построга или, обратно, поблага политика) - во зависност од очекувањата и финансиските можности.

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

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

Илустрација на работниот тек во Git

Да речеме дека работите нешто како ова во Git:

Иконата со глава на дијаграмот означува слики од контејнери кои моментално се распоредени во Kubernetes за сите корисници (крајни корисници, тестери, менаџери итн.) или се користат од развивачите за дебагирање и слични цели.

Што ќе се случи ако политиките за чистење дозволуваат само да се задржат сликите (не да се избришат) со дадени имиња на ознаки?

Очигледно, ваквото сценарио никого нема да израдува.

Што ќе се промени ако политиките дозволуваат сликите да не се бришат? според даден временски интервал / број на последни обврски?

Резултатот стана многу подобар, но се уште е далеку од идеален. На крајот на краиштата, сè уште имаме програмери на кои им требаат слики во регистарот (или дури и распоредени во K8s) за отстранување грешки...

Да ја сумираме моменталната состојба на пазарот: функциите достапни во регистрите на контејнери не нудат доволно флексибилност при чистењето, а главната причина за тоа е нема начин за интеракција со надворешниот свет. Излегува дека тимовите кои бараат таква флексибилност се принудени самостојно да спроведуваат бришење слики „однадвор“, користејќи го Docker Registry API (или мајчин API на соодветната имплементација).

Сепак, баравме универзално решение кое ќе го автоматизира чистењето на сликите за различни тимови кои користат различни регистри...

Нашиот пат до универзално чистење на сликата

Од каде доаѓа оваа потреба? Факт е дека ние не сме посебна група на програмери, туку тим кој опслужува многу од нив одеднаш, помагајќи во сеопфатно решавање на проблемите со CI/CD. И главната техничка алатка за ова е алатката со отворен код верф. Неговата особеност е тоа што не извршува една функција, туку ги придружува процесите на континуирана испорака во сите фази: од склопување до распоредување.

Објавувањето слики во регистарот* (веднаш откако ќе бидат изградени) е очигледна функција на таквата алатка. И бидејќи сликите се поставени таму за складирање, тогаш - ако вашето складирање не е неограничено - треба да бидете одговорни за нивното последователно чистење. Како постигнавме успех во ова, задоволувајќи ги сите наведени критериуми, ќе се дискутира понатаму.

* Иако самите регистри може да бидат различни (Docker Registry, GitLab Container Registry, Harbor итн.), нивните корисници се соочуваат со истите проблеми. Универзалното решение во нашиот случај не зависи од спроведувањето на регистарот, бидејќи работи надвор од самите регистри и нуди исто однесување за сите.

Иако користиме werf како пример за имплементација, се надеваме дека користените пристапи ќе бидат корисни за другите тимови кои се соочуваат со слични тешкотии.

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

Ова тривијално решение го реши најкритичниот проблем (критериум бр. 1), но беше само почеток на нашето патување за подобрување на механизмот за чистење. Следниот - и многу поинтересен - чекор беше одлуката поврзете ги објавените слики со историјата на Git.

Шеми за означување

За почеток, избравме пристап во кој конечната слика треба да ги складира потребните информации за чистење и го изградивме процесот на шеми за означување. Кога објавува слика, корисникот избрал одредена опција за означување (git-branch, git-commit или git-tag) и ја искористи соодветната вредност. Во CI системите, овие вредности се поставуваа автоматски врз основа на променливите на околината. Всушност конечната слика беше поврзана со специфичен примитив Git, складирање на потребните податоци за чистење во етикети.

Овој пристап резултираше со збир на политики што овозможија Git да се користи како единствен извор на вистината:

• Кога бришете гранка/ознака во Git, поврзаните слики во регистарот беа автоматски избришани.
• Бројот на слики поврзани со Git ознаки и заложби може да се контролира со бројот на ознаки што се користат во избраната шема и времето во кое е креиран поврзаниот commit.

Севкупно, имплементацијата што резултираше ги задоволи нашите потреби, но наскоро не чекаше нов предизвик. Факт е дека додека ги користевме шемите за означување базирани на примитивите на Git, наидовме на голем број недостатоци. (Бидејќи нивниот опис е надвор од опсегот на овој напис, секој може да се запознае со деталите тука.) Затоа, откако решивме да се префрлиме на поефикасен пристап за означување (означување базирано на содржина), моравме да ја преиспитаме имплементацијата на чистење на слики.

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

Зошто? Со означување базирано на содржина, секоја ознака може да задоволи повеќекратни обврски во Git. Кога чистите слики, повеќе не можете да претпоставувате само од commit каде што е додадена новата ознака во регистарот.

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

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

Со други зборови, тоа беше обезбедено поврзување објавени ознаки со обврски во 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.

Конечниот алгоритам се сведува на следните чекори:

• Враќање манифести од регистарот на контејнери.
• Исклучувајќи ги сликите што се користат во Кубернетес, бидејќи Веќе ги избравме однапред со анкетирање на K8s API.
• Скенирање на историјата на Git и исклучување на слики врз основа на наведените правила.
• Отстранување на преостанатите слики.

Враќајќи се на нашата илустрација, еве што се случува со верф:

Сепак, дури и ако не користите werf, сличен пристап за напредно чистење на слики - во една или друга имплементација (според претпочитаниот пристап за означување на слики) - може да се примени и на други системи/услужни програми. За да го направите ова, доволно е да се потсетите на проблемите што се појавуваат и да ги пронајдете оние можности во вашиот оџак што ви дозволуваат да го интегрирате нивното решение што е можно понепречено. Се надеваме дека патот што го поминавме ќе ви помогне да го разгледате вашиот конкретен случај со нови детали и размислувања.

Заклучок

• Порано или подоцна, повеќето тимови се соочуваат со проблем со прелевање на регистарот.
• Кога барате решенија, прво е неопходно да се утврдат критериумите за релевантноста на сликата.
• Алатките што ги нудат популарните услуги за регистар на контејнери ви овозможуваат да организирате многу едноставно чистење што не го зема предвид „надворешниот свет“: сликите што се користат во Kubernetes и особеностите на работните текови на тимот.
• Флексибилен и ефикасен алгоритам мора да има разбирање за процесите на CI/CD и да работи не само со податоците за сликите на Docker.

PS

Прочитајте и на нашиот блог:

• «Означување засновано на содржина во колекторот werf: зошто и како функционира?";
• «3-насочно спојување до верф: распоредување во Кубернетис со Хелм „на стероиди“";
• «Поддршка за monorepo и multirepo во werf и каква врска има Docker Registry со тоа";
• «Верф 1.1 издание: подобрувања на градителот денес и планови за иднината".

Извор: www.habr.com