🥇Контейнер кескіндерін «ақылды» тазалау мәселесі және оны werf

Мақалада Kubernetes-ке жеткізілетін бұлтты қосымшалар үшін қазіргі заманғы 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-тегі жұмыс үрдісінің иллюстрациясы

Сіз Git-те осындай жұмыс істеп жатырсыз делік:

Диаграммадағы басы бар белгіше қазіргі уақытта кез келген пайдаланушылар (соңғы пайдаланушылар, тестерлер, менеджерлер және т.б.) үшін Kubernetes жүйесінде орналастырылған немесе әзірлеушілер отладтау және ұқсас мақсаттар үшін пайдаланатын контейнер кескіндерін көрсетеді.

Тазалау саясаттары тек кескіндерді сақтауға рұқсат берсе не болады (жоймайды) берілген тег атаулары бойынша?

Мұндай сценарий ешкімді қуанта қоймасы анық.

Саясат кескіндерді жоймауға рұқсат берсе, не өзгереді? берілген уақыт аралығына/соңғы міндеттемелер санына сәйкес?

Нәтиже әлдеқайда жақсы болды, бірақ әлі де идеалдан алыс. Ақыр соңында, бізде қателерді түзету үшін тізілімде (немесе тіпті K8-де орналастырылған) кескіндерді қажет ететін әзірлеушілер бар...

Ағымдағы нарықтық жағдайды қорытындылау үшін: контейнер тізілімдерінде қол жетімді функциялар тазалау кезінде жеткілікті икемділікті ұсынбайды және оның негізгі себебі сыртқы әлеммен әрекеттесу мүмкіндігі жоқ. Мұндай икемділікті қажет ететін командалар Docker Registry API (немесе сәйкес іске асырудың жергілікті API) көмегімен кескінді жоюды «сырттан» дербес жүзеге асыруға мәжбүр екені белгілі болды.

Дегенмен, біз әртүрлі тізілімдерді қолданатын әртүрлі командалар үшін кескінді тазалауды автоматтандыратын әмбебап шешім іздедік...

Біздің әмбебап кескінді тазалау жолымыз

Бұл қажеттілік қайдан пайда болды? Біз әзірлеушілердің жеке тобы емеспіз, бірақ олардың көпшілігіне бірден қызмет көрсететін, CI/CD мәселелерін кешенді шешуге көмектесетін командамыз. Ал бұл үшін негізгі техникалық құрал Open Source утилитасы болып табылады верф. Оның ерекшелігі, ол бір ғана функцияны орындамайды, бірақ барлық кезеңдердегі үздіксіз жеткізу процестерімен бірге жүреді: құрастырудан бастап орналастыруға дейін.

Суреттерді тізілімге жариялау* (олар салынғаннан кейін бірден) мұндай қызметтік бағдарламаның айқын функциясы болып табылады. Суреттер сол жерде сақтау үшін орналастырылғандықтан, егер сіздің сақтау орныңыз шексіз болмаса - олардың кейінгі тазалауына жауапты болуыңыз керек. Барлық көрсетілген критерийлерді қанағаттандыра отырып, біз бұл жетістікке қалай қол жеткіздік, әрі қарай талқыланады.

* Тізілімдердің өзі әртүрлі болуы мүмкін болса да (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 тегтерімен және міндеттемелерімен байланысты кескіндер санын таңдалған схемада пайдаланылған тегтер саны және байланысты міндеттеме жасалған уақыт арқылы басқаруға болады.

Тұтастай алғанда, нәтиже біздің қажеттіліктерімізді қанағаттандырды, бірақ көп ұзамай бізді жаңа сынақ күтіп тұрды. 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 Git тегтері үшін сақтаңыз (тегті жасау күні бойынша).
Соңғы аптада жарияланған 2 суреттен артық емес соңғы аптадағы белсенділігі бар 10 ағыннан аспайтындай етіп сақтаңыз.
Филиалдар үшін 10 суретті сақтаңыз main, staging и production.

Соңғы алгоритм келесі қадамдарға дейін төмендейді:

Контейнер тізілімінен манифесттерді шығарып алу.
Kubernetes қолданбасында пайдаланылған кескіндерді қоспағанда, себебі Біз оларды K8s API сұрау арқылы алдын ала таңдап алдық.
Git тарихын сканерлеу және көрсетілген саясаттарға негізделген кескіндерді қоспау.
Қалған кескіндерді жою.

Біздің иллюстрацияға оралсақ, werf-пен осылай болады:

Дегенмен, егер сіз werf қолданбасаңыз да, кеңейтілген кескінді тазалауға ұқсас тәсіл - бір немесе басқа іске асыруда (суретті тегтеудің қолайлы тәсіліне сәйкес) - басқа жүйелерге/утилиттерге қолданылуы мүмкін. Мұны істеу үшін туындайтын мәселелерді еске түсіру және олардың шешімін мүмкіндігінше тегіс біріктіруге мүмкіндік беретін стектегі мүмкіндіктерді табу жеткілікті. Біз жүріп өткен жол нақты ісіңізге жаңа мәліметтермен және ойлармен қарауға көмектеседі деп үміттенеміз.

қорытынды

Ерте ме, кеш пе, командалардың көпшілігі тізілімнің толып кету мәселесіне тап болады.
Шешімдерді іздестіру кезінде ең алдымен суреттің өзектілігінің критерийлерін анықтау қажет.
Танымал контейнерлік тізілім қызметтері ұсынатын құралдар «сыртқы әлемді» ескермейтін өте қарапайым тазалауды ұйымдастыруға мүмкіндік береді: Kubernetes-те қолданылатын кескіндер және команданың жұмыс үрдісінің ерекшеліктері.
Икемді және тиімді алгоритм CI/CD процестерін түсінуі керек және тек Docker кескін деректерімен ғана жұмыс істемейді.

PS

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

Контейнер кескіндерін «ақылды» тазалау мәселесі және оны werf-те шешу