🥇Проблем "паметног" чишћења слика контејнера и његово решење у верф

У чланку се разматрају проблеми чишћења слика које се акумулирају у регистрима контејнера (Доцкер Регистри и његови аналози) у стварности савремених ЦИ/ЦД цевовода за клауд изворне апликације које се испоручују у Кубернетес. Дати су главни критеријуми за релевантност слика и настале потешкоће у аутоматизацији чишћења, уштеди простора и задовољавању потреба тимова. На крају, користећи пример конкретног пројекта отвореног кода, рећи ћемо вам како се ове потешкоће могу превазићи.

Увод

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

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

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

Међутим, овај приступ у великој мери ограничава развој и ретко је применљив на модерне ЦИ/ЦД пројекте. Саставни део развоја био је аутоматизација, што вам омогућава да тестирате, примените и испоручите нове функционалности корисницима много брже. На пример, у свим нашим пројектима, ЦИ цевовод се аутоматски креира са сваким урезивањем. У њему се слика склапа, тестира, развлачи у разна Кубернетес кола за отклањање грешака и преостале провере, и ако је све у реду, промене стижу до крајњег корисника. И ово више није ракетна наука, већ свакодневна појава за многе - највероватније за вас, пошто читате овај чланак.

Пошто се исправљање грешака и развој нове функционалности одвијају паралелно, а издања се могу изводити неколико пута дневно, очигледно је да процес развоја прати значајан број урезивања, што значи велики број слика у регистру. Као резултат тога, намеће се питање организовања ефикасног чишћења регистра, тј. уклањање небитних слика.

Али како уопште одредити да ли је слика релевантна?

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

У великој већини случајева, главни критеријуми ће бити:

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

2. Друго (мање очигледно, али и веома важно и опет се односи на експлоатацију) – слике које потребно за враћање уназад у случају откривања озбиљних проблема у тренутној верзији. На пример, у случају Хелма, ово су слике које се користе у сачуваним верзијама издања. (Успут, подразумевано у Хелм-у ограничење је 256 ревизија, али је мало вероватно да неко заиста треба да штеди таква велики број верзија?..) Уосталом, ми, посебно, чувамо верзије да бисмо их касније користили, тј. „вратити се“ на њих ако је потребно.

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

4. Четврто – слике које одговарају верзијама наше апликације, тј. су финални производ: в1.0.0, 20.04.01/XNUMX/XNUMX, сиерра, итд.

Напомена: Овде дефинисани критеријуми су формулисани на основу искуства у интеракцији са десетинама развојних тимова из различитих компанија. Међутим, наравно, у зависности од специфичности развојних процеса и коришћене инфраструктуре (на пример, Кубернетес се не користи), ови критеријуми могу да се разликују.

Подобност и постојећа решења

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

* Зависи од специфичних имплементација регистра контејнера. Размотрили смо могућности следећих решења: Азуре ЦР, Доцкер Хуб, ЕЦР, ГЦР, ГитХуб пакети, ГитЛаб Регистар контејнера, Харбор Регистри, ЈФрог Артифацтори, Куаи.ио – од септембра 2020.

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

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

Ситуација са прва два критеријума је слична: они се не могу задовољити без примања података из екстерног система – оног где су апликације распоређене (у нашем случају Кубернетес).

Илустрација тока посла у Гиту

Рецимо да радите нешто овако у Гиту:

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

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

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

Шта ће се променити ако смернице дозвољавају да се слике не бришу? према датом временском интервалу / броју последњих урезивања?

Резултат је постао много бољи, али је и даље далеко од идеалног. На крају крајева, још увек имамо програмере којима су потребне слике у регистру (или чак распоређене у К8с) за отклањање грешака...

Да сумирамо тренутну ситуацију на тржишту: функције доступне у регистрима контејнера не нуде довољно флексибилности приликом чишћења, а главни разлог за то је нема начина за интеракцију са спољним светом. Испоставило се да су тимови којима је потребна таква флексибилност принуђени да независно имплементирају брисање слике „споља“, користећи Доцкер Регистри АПИ (или изворни АПИ одговарајуће имплементације).

Међутим, тражили смо универзално решење које ће аутоматизовати чишћење слике за различите тимове користећи различите регистре...

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

Одакле долази ова потреба? Чињеница је да ми нисмо посебна група програмера, већ тим који истовремено служи многима од њих, помажући да се свеобухватно реши проблем ЦИ/ЦД. А главни технички алат за ово је услужни програм отвореног кода верф. Његова посебност је у томе што не обавља једну функцију, већ прати континуиране процесе испоруке у свим фазама: од склапања до постављања.

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

* Иако се сами регистри могу разликовати (Доцкер Регистри, ГитЛаб Цонтаинер Регистри, Харбор, итд.), њихови корисници се суочавају са истим проблемима. Универзално решење у нашем случају не зависи од имплементације регистра, јер ради ван самих регистара и нуди исто понашање за све.

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

Тако да смо били заузети спољни имплементација механизма за чишћење слика – уместо оних могућности које су већ уграђене у регистре за контејнере. Први корак је био коришћење Доцкер Регистри АПИ-ја за креирање истих примитивних смерница за број ознака и време њиховог креирања (горе поменуто). Додато им листа дозвола заснована на сликама које се користе у распоређеној инфраструктури, тј. Кубернетес. За ово друго, било је довољно користити Кубернетес АПИ за понављање кроз све распоређене ресурсе и добијање листе вредности image.

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

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

За почетак, изабрали смо приступ у којем би коначна слика требало да чува потребне информације за чишћење и изградили процес на шемама означавања. Приликом објављивања слике, корисник је изабрао одређену опцију означавања (git-branch, git-commit или git-tag) и користио одговарајућу вредност. У ЦИ системима, ове вредности су постављене аутоматски на основу променљивих окружења. заправо коначна слика је била повезана са одређеним Гит примитивом, чувајући потребне податке за чишћење у етикетама.

Овај приступ је резултирао скупом смерница које су омогућиле да се Гит користи као једини извор истине:

Приликом брисања гране/ознаке у Гиту, повезане слике у регистру су аутоматски избрисане.
Број слика повезаних са Гит ознакама и урезима може се контролисати бројем ознака које се користе у изабраној шеми и временом у којем је повезано урезивање креирано.

Све у свему, резултирајућа имплементација је задовољила наше потребе, али нас је ускоро чекао нови изазов. Чињеница је да смо приликом коришћења шема за означавање заснованих на Гит примитивима наишли на низ недостатака. (Пошто њихов опис излази из оквира овог чланка, свако се може упознати са детаљима овде.) Стога, након што смо одлучили да пређемо на ефикаснији приступ означавању (означавање засновано на садржају), морали смо да преиспитамо примену чишћења слике.

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

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

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

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

Другим речима, обезбеђено је повезивање објављених ознака са урезима у Гиту.

Коначна конфигурација и општи алгоритам

Када конфигуришу чишћење, корисници сада имају приступ смерницама које бирају тренутне слике. Свака таква политика је дефинисана:

многе референце, тј. Гит ознаке или Гит гране које се користе током скенирања;
и ограничење тражених слика за сваку референцу из скупа.

Да илуструјемо, овако је почела да изгледа подразумевана конфигурација политике:

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

Ова конфигурација садржи три смернице које су у складу са следећим правилима:

Сачувајте слику за последњих 10 Гит ознака (према датуму креирања ознаке).
Сачувајте не више од 2 слике објављене прошле недеље за највише 10 нити са активностима у последњој недељи.
Сачувајте 10 слика за гране main, staging и production.

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

Преузимање манифеста из регистра контејнера.
Изузимајући слике које се користе у Кубернетесу, јер Већ смо их унапред изабрали анкетирањем К8с АПИ-ја.
Скенирање Гит историје и изузимање слика на основу одређених смерница.
Уклањање преосталих слика.

Да се вратимо на нашу илустрацију, ево шта се дешава са верф-ом:

Међутим, чак и ако не користите верф, сличан приступ напредном чишћењу слике – у једној или другој имплементацији (према преферираном приступу означавању слика) – може се применити на друге системе/услужне програме. Да бисте то урадили, довољно је запамтити проблеме који се појављују и пронаћи оне могућности у свом низу које вам омогућавају да интегришете њихово решење што је лакше могуће. Надамо се да ће вам пут који смо прешли помоћи да сагледате свој случај са новим детаљима и размишљањима.

Закључак

Пре или касније, већина тимова се сусреће са проблемом прекорачења регистра.
Приликом тражења решења најпре је потребно утврдити критеријуме релевантности слике.
Алати које нуде популарне услуге регистра контејнера омогућавају вам да организујете врло једноставно чишћење које не узима у обзир „спољни свет“: слике које се користе у Кубернетес-у и посебности токова рада тима.
Флексибилан и ефикасан алгоритам мора да разуме ЦИ/ЦД процесе и да ради не само са подацима Доцкер слике.

ПС

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

Извор: ввв.хабр.цом

Проблем "паметног" чишћења слика контејнера и његово решење у верф-у