🥇Контейнер сүрөттөрүн “акылдуу” тазалоо маселеси жана аны werf

Макалада Кубернетеске жеткирилген булуттук тиркемелер үчүн заманбап CI/CD түтүкчөлөрүнүн реалдуулуктарында контейнер реестрлеринде (Docker Registry жана анын аналогдору) топтолгон сүрөттөрдү тазалоо көйгөйлөрү талкууланат. Сүрөттөрдүн актуалдуулугунун негизги критерийлери жана натыйжада тазалоону автоматташтыруу, мейкиндикти үнөмдөө жана командалардын керектөөлөрүн канааттандыруудагы кыйынчылыктар келтирилген. Акырында, конкреттүү Open Source долбоорунун мисалында биз бул кыйынчылыктарды кантип жеңсе болорун айтып беребиз.

тааныштыруу

Контейнер реестриндеги сүрөттөрдүн саны тездик менен өсүп, көбүрөөк сактоо мейкиндигин ээлеп, ошону менен анын баасын бир топ жогорулатат. Реестрде ээлеген мейкиндиктин алгылыктуу өсүшүн көзөмөлдөө, чектөө же колдоо үчүн төмөнкүлөр кабыл алынат:

сүрөттөр үчүн белгилердин белгиленген санын колдонуу;
кандайдыр бир жол менен сүрөттөрдү тазалоо.

Биринчи чектөө кээде чакан командалар үчүн алгылыктуу болуп саналат. Эгерде иштеп чыгуучулардын туруктуу теги жетиштүү болсо (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, ж.б.

Эскертүү: Бул жерде аныкталган критерийлер ар кандай компаниялардын ондогон өнүктүрүү командалары менен өз ара аракеттенүү тажрыйбасынын негизинде түзүлгөн. Бирок, албетте, иштеп чыгуу процесстериндеги өзгөчөлүктөргө жана колдонулган инфраструктурага жараша (мисалы, Kubernetes колдонулбайт), бул критерийлер ар кандай болушу мүмкүн.

Жарамдуулук жана учурдагы чечимдер

Контейнер реестрлери бар популярдуу кызматтар, эреже катары, сүрөттү тазалоонун өзүнүн саясатын сунуштайт: аларда тег реестрден алынып салынуучу шарттарды аныктай аласыз. Бирок, бул шарттар аттары, түзүү убактысы жана тегдердин саны* сыяктуу параметрлер менен чектелет.

* Контейнер реестринин конкреттүү ишке ашырылышына көз каранды. Биз төмөнкү чечимдердин мүмкүнчүлүктөрүн карап чыктык: Azure CR, Docker Hub, ECR, GCR, GitHub пакеттери, GitLab контейнер реестри, Харбор реестри, JFrog Artifactory, Quay.io - 2020-жылдын сентябрына карата.

Параметрлердин бул топтому төртүнчү критерийди канааттандыруу үчүн жетиштүү - башкача айтканда, версияларга туура келген сүрөттөрдү тандоо. Бирок, башка бардык критерийлер үчүн кандайдыр бир компромисстик чечимди (катаалыраак же тескерисинче, жумшак саясат) тандоо керек - күтүүлөргө жана финансылык мүмкүнчүлүктөргө жараша.

Мисалы, үчүнчү критерий - иштеп чыгуучулардын муктаждыктарына байланыштуу - командалардын ичиндеги процесстерди уюштуруу менен чечилиши мүмкүн: сүрөттөрдүн өзгөчө аталышы, атайын уруксат тизмелерин жана ички макулдашууларды сактоо. Бирок акырында дагы эле автоматташтыруу керек. Ал эми даяр чечимдердин мүмкүнчүлүктөрү жетишсиз болсо, анда өз алдынча бир нерсе кылышыңыз керек.

Биринчи эки критерийдин абалы окшош: аларды тышкы системадан - тиркемелер орнотулган системадан (биздин учурда, Kubernetes) маалыматтарды алуусуз канааттандыруу мүмкүн эмес.

Гитте иштөө процессинин иллюстрациясы

Сиз Gitте ушул сыяктуу бир нерсе иштеп жатасыз дейли:

Диаграммадагы башы бар сөлөкөт учурда Kubernetes'те каалаган колдонуучулар үчүн (акыркы колдонуучулар, сыноочулар, менеджерлер ж.б.) орнотулган же иштеп чыгуучулар тарабынан мүчүлүштүктөрдү оңдоо жана ушул сыяктуу максаттар үчүн колдонулган контейнер сүрөттөрүн көрсөтөт.

Тазалоо саясаттары сүрөттөрдү сактоого гана уруксат берсе эмне болот (жок кылынбайт) берилген тег аттары менен?

Мындай сценарий эч кимди кубантпай турганы анык.

Саясат сүрөттөрдү өчүрбөөгө жол берсе, эмне өзгөрөт? берилген убакыт аралыгына / акыркы милдеттенмелердин санына ылайык?

Натыйжа бир топ жакшырды, бирок идеалдан дагы эле алыс. Кантсе да, бизде каталарды оңдоо үчүн реестрге (же ал тургай K8sде орнотулган) сүрөттөр керек болгон иштеп чыгуучулар бар...

Учурдагы рыноктук кырдаалды жалпылоо үчүн: контейнер реестрлериндеги функциялар тазалоодо жетиштүү ийкемдүүлүктү сунуштабайт жана мунун негизги себеби - тышкы дүйнө менен өз ара аракеттенүүгө жол жок. Көрсө, мындай ийкемдүүлүктү талап кылган командалар Docker Registry API (же тиешелүү ишке ашыруунун жергиликтүү API) аркылуу сүрөттү жок кылууну "сырттан" өз алдынча ишке ашырууга мажбур болушат.

Бирок, биз ар кандай реестрлерди колдонуп, ар кандай командалар үчүн сүрөттү тазалоону автоматташтыра турган универсалдуу чечимди издеп жатканбыз...

Биздин универсалдуу сүрөттү тазалоо жолу

Бул муктаждык кайдан келип чыгат? Чындыгында биз иштеп чыгуучулардын өзүнчө тобу эмеспиз, бирок CI/CD маселелерин комплекстүү чечүүгө жардам берип, алардын көбүнө бир убакта кызмат кылган командабыз. Ал эми бул үчүн негизги техникалык курал Open Source утилитасы болуп саналат werf. Анын өзгөчөлүгү, ал бир эле функцияны аткарбастан, бардык этаптарда үзгүлтүксүз жеткирүү процесстерин коштоп турат: монтаждоодон баштап жайылтууга чейин.

Сүрөттөрдү реестрге жарыялоо* (алар курулгандан кийин дароо) мындай утилитанын ачык милдети. Ал эми сүрөттөр ошол жерге сактоо үчүн коюлгандыктан, анда - сиздин сактагычыңыз чексиз болбосо, сиз аларды кийинки тазалоо үчүн жооптуу болушуңуз керек. Бардык көрсөтүлгөн критерийлерге жооп берүү менен, биз бул ийгиликке кантип жетиштик, мындан ары да талкууланат.

* Реестрлердин өзүлөрү ар кандай болушу мүмкүн болсо да (Docker Registry, GitLab Container Registry, Harbor ж.б.), алардын колдонуучулары бирдей көйгөйлөргө туш болушат. Биздин учурда универсалдуу чечим реестрди ишке ашыруудан көз каранды эмес, анткени реестрлерден тышкары иштейт жана бардыгы үчүн бирдей жүрүм-турумду сунуштайт.

Биз мисал катары werf колдонуп жатканыбызга карабастан, колдонулган ыкмалар ушул сыяктуу кыйынчылыктарга туш болгон башка командалар үчүн пайдалуу болот деп үмүттөнөбүз.

Ошентип бош болбой калдык тышкы сүрөттөрдү тазалоо механизмин ишке ашыруу - контейнерлер үчүн реестрлерге мурунтан эле орнотулган мүмкүнчүлүктөрдүн ордуна. Биринчи кадам тегдердин саны жана аларды түзүү убактысы (жогоруда айтылган) үчүн бирдей примитивдик саясаттарды түзүү үчүн Docker Registry API колдонуу болду. Аларга кошулду жайгаштырылган инфраструктурада колдонулган сүрөттөрдүн негизинде тизмеге уруксат берүү, б.а. Kubernetes. Акыркысы үчүн, бардык жайгаштырылган ресурстарды кайталоо жана баалуулуктардын тизмесин алуу үчүн Kubernetes API колдонуу жетиштүү болду. 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

Бул конфигурация төмөнкү эрежелерге ылайык келген үч саясатты камтыйт:

Сүрөттү акыркы 10 Гит тегине сактаңыз (тег түзүлгөн күнү боюнча).
Акыркы жумада жарыяланган 2ден ашык эмес сүрөттү акыркы жумадагы активдүүлүгү бар 10 жиптен ашык эмес сактаңыз.
Бутактарга 10 сүрөттү сактаңыз main, staging и production.

Акыркы алгоритм төмөнкү кадамдарга чейин төмөндөйт:

Контейнер реестринен манифесттерди алуу.
Kubernetes колдонулган сүрөттөрдү кошпогондо, анткени Биз аларды K8s API сурамжылоосу менен алдын ала тандап алганбыз.
Git таржымалын сканерлөө жана көрсөтүлгөн саясаттын негизинде сүрөттөрдү кошпогондо.
Калган сүрөттөрдү алып салуу.

Биздин мисалга кайрылсак, werf менен мындай болот:

Бирок, сиз werf колдонбосоңуз да, өнүккөн сүрөттү тазалоого окшош мамиле - тигил же бул ишке ашырууда (сүрөттөрдү белгилөөнүн артыкчылыктуу ыкмасына ылайык) - башка системаларга/утилиттерге колдонулушу мүмкүн. Бул үчүн, пайда болгон көйгөйлөрдү эстеп калуу жана сиздин стекиңизден аларды чечүү жолдорун мүмкүн болушунча оңой интеграциялоого мүмкүндүк берген мүмкүнчүлүктөрдү табуу жетиштүү. Биз басып өткөн жол сиздин конкреттүү ишиңизди жаңы деталдар жана ойлор менен кароого жардам берет деп ишенебиз.

жыйынтыктоо

Эртеби-кечпи, көпчүлүк командалар реестр толуп кетүү көйгөйүнө туш болушат.
Чечимдерди издөөдө биринчи кезекте сүрөттүн актуалдуулугунун критерийлерин аныктоо зарыл.
Популярдуу контейнердик реестр кызматтары сунуш кылган куралдар "сырткы дүйнөнү" эске албаган өтө жөнөкөй тазалоону уюштурууга мүмкүндүк берет: Kubernetesте колдонулган сүрөттөр жана команданын иштөө процесстеринин өзгөчөлүктөрү.
Ийкемдүү жана эффективдүү алгоритм CI/CD процесстерин түшүнүшү керек жана Докер сүрөтүнүн маалыматтары менен гана иштеши керек.

PS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Контейнер сүрөттөрүн "акылдуу" тазалоо маселеси жана аны werfте чечүү