🥇Konteyner tasvirlarini “aqlli” tozalash muammosi va uni werf

Maqolada Kubernetes-ga etkazib beriladigan bulutli mahalliy ilovalar uchun zamonaviy CI/CD quvurlari haqiqatida konteyner registrlarida (Docker Registry va uning analoglari) to'plangan tasvirlarni tozalash muammolari muhokama qilinadi. Tasvirlarning dolzarbligining asosiy mezonlari va natijada tozalashni avtomatlashtirish, joyni tejash va jamoalarning ehtiyojlarini qondirishdagi qiyinchiliklar keltirilgan. Va nihoyat, ma'lum bir Open Source loyihasi misolidan foydalanib, biz sizga bu qiyinchiliklarni qanday engish mumkinligini aytib beramiz.

kirish

Konteynerlar registridagi tasvirlar soni tez sur'atlar bilan o'sib, ko'proq saqlash joyini egallashi va shu bilan uning narxini sezilarli darajada oshirishi mumkin. Ro'yxatga olish kitobida egallagan maydonning maqbul o'sishini nazorat qilish, cheklash yoki ushlab turish uchun quyidagilar qabul qilinadi:

tasvirlar uchun belgilangan miqdordagi teglardan foydalaning;
tasvirlarni qandaydir tarzda tozalang.

Birinchi cheklov ba'zan kichik jamoalar uchun maqbuldir. Agar ishlab chiquvchilar etarli doimiy teglarga ega bo'lsa (latest, main, test, boris va hokazo), ro'yxatga olish kitobi kattalashmaydi va uzoq vaqt davomida uni tozalash haqida o'ylamasligingiz kerak. Axir, barcha ahamiyatsiz tasvirlar o'chiriladi va tozalash uchun hech qanday ish qolmaydi (hamma narsa oddiy axlat yig'uvchi tomonidan amalga oshiriladi).

Biroq, bu yondashuv rivojlanishni sezilarli darajada cheklaydi va kamdan-kam hollarda zamonaviy CI/CD loyihalarida qo'llaniladi. Rivojlanishning ajralmas qismi edi avtomatlashtirish, bu sizga yangi funksiyalarni sinab koʻrish, oʻrnatish va foydalanuvchilarga tezroq yetkazib berish imkonini beradi. Masalan, barcha loyihalarimizda har bir majburiyat bilan CI quvuri avtomatik ravishda yaratiladi. Unda tasvir yig'iladi, sinovdan o'tkaziladi, disk raskadrovka va qolgan tekshiruvlar uchun turli Kubernetes sxemalariga chiqariladi va agar hamma narsa yaxshi bo'lsa, o'zgarishlar oxirgi foydalanuvchiga etib boradi. Va bu endi raketa ilmi emas, balki ko'pchilik uchun kundalik hodisa - ehtimol siz uchun, chunki siz ushbu maqolani o'qiyapsiz.

Xatolarni tuzatish va yangi funksiyalarni ishlab chiqish parallel ravishda amalga oshirilganligi va relizlar kuniga bir necha marta amalga oshirilishi mumkinligi sababli, ishlab chiqish jarayoni juda ko'p miqdordagi majburiyatlar bilan birga bo'lishi aniq. ro'yxatga olish kitobida ko'p sonli tasvirlar. Natijada, ro'yxatga olish kitobini samarali tozalashni tashkil etish masalasi paydo bo'ladi, ya'ni. ahamiyatsiz tasvirlarni olib tashlash.

Ammo tasvirning tegishli ekanligini qanday aniqlash mumkin?

Tasvirning dolzarbligi mezonlari

Aksariyat hollarda asosiy mezonlar quyidagilar bo'ladi:

1. Birinchisi (eng aniq va eng tanqidiy) tasvirlardir hozirda Kubernetesda qo'llaniladi. Ushbu rasmlarni olib tashlash ishlab chiqarishda katta to'xtab qolish xarajatlariga olib kelishi mumkin (masalan, tasvirlar replikatsiya uchun talab qilinishi mumkin) yoki har qanday tsiklda disk raskadrovka qilish bo'yicha jamoaning sa'y-harakatlarini inkor etishi mumkin. (Shuning uchun biz hatto maxsus qildik Prometey eksportchisi, bu har qanday Kubernetes klasterida bunday tasvirlar yo'qligini kuzatib boradi.)

2. Ikkinchidan (kamroq aniq, lekin ayni paytda juda muhim va yana ekspluatatsiya bilan bog'liq) - tasvirlar jiddiy muammolar aniqlangan taqdirda orqaga qaytarish uchun talab qilinadi joriy versiyada. Masalan, Helm misolida, bu nashrning saqlangan versiyalarida ishlatiladigan tasvirlar. (Aytgancha, Helm-da sukut bo'yicha chegara 256 ta tahrirni tashkil qiladi, ammo kimdir haqiqatan ham saqlashi kerak emas. bunday ko'p sonli versiyalar?..) Axir, biz, xususan, versiyalarni keyinchalik ulardan foydalanishimiz uchun saqlaymiz, ya'ni. Agar kerak bo'lsa, ularga "orqaga qayting".

3. Uchinchi - dasturchi ehtiyojlari: Ularning joriy ishlariga tegishli barcha rasmlar. Misol uchun, agar biz PR haqida o'ylayotgan bo'lsak, unda oxirgi va, aytaylik, oldingi majburiyatga mos keladigan rasmni qoldirish mantiqan to'g'ri keladi: shu tarzda ishlab chiquvchi tezda istalgan vazifaga qaytishi va so'nggi o'zgarishlar bilan ishlashi mumkin.

4. To'rtinchidan - tasvirlar ilovamiz versiyalariga mos keladi, ya'ni. yakuniy mahsulotdir: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra va boshqalar.

Eslatma: Bu erda belgilangan mezonlar turli kompaniyalarning o'nlab ishlab chiqish guruhlari bilan hamkorlik qilish tajribasiga asoslangan holda tuzilgan. Biroq, albatta, rivojlanish jarayonlaridagi o'ziga xosliklarga va foydalaniladigan infratuzilmaga qarab (masalan, Kubernetes ishlatilmaydi), bu mezonlar farq qilishi mumkin.

Muvofiqlik va mavjud echimlar

Konteyner registrlari bo'lgan mashhur xizmatlar, qoida tariqasida, o'zlarining tasvirlarni tozalash siyosatlarini taklif qiladilar: ularda siz tegni ro'yxatga olish kitobidan olib tashlash shartlarini belgilashingiz mumkin. Biroq, bu shartlar nomlar, yaratilish vaqti va teglar soni* kabi parametrlar bilan cheklangan.

* Muayyan konteyner registrlarini amalga oshirishga bog'liq. Biz quyidagi yechimlarning imkoniyatlarini ko‘rib chiqdik: Azure CR, Docker Hub, ECR, GCR, GitHub paketlari, GitLab konteyner registrlari, Harbor Registry, JFrog Artifactory, Quay.io – 2020-yil sentabr holatiga ko‘ra.

Ushbu parametrlar to'plami to'rtinchi mezonni qondirish uchun etarli - ya'ni versiyalarga mos keladigan tasvirlarni tanlash uchun. Biroq, boshqa barcha mezonlar uchun, umidlar va moliyaviy imkoniyatlarga qarab, qandaydir murosa yechimini (qattiqroq yoki aksincha, yumshoqroq siyosat) tanlash kerak.

Masalan, ishlab chiquvchilarning ehtiyojlari bilan bog'liq bo'lgan uchinchi mezonni jamoalar ichidagi jarayonlarni tashkil qilish orqali hal qilish mumkin: tasvirlarni maxsus nomlash, maxsus ruxsatnomalar va ichki kelishuvlarni saqlash. Lekin oxir-oqibat u hali ham avtomatlashtirilishi kerak. Va agar tayyor echimlarning imkoniyatlari etarli bo'lmasa, siz o'zingizning biror narsa qilishingiz kerak.

Birinchi ikkita mezon bilan bog'liq vaziyat o'xshash: ularni tashqi tizimdan ma'lumot olmasdan qondirish mumkin emas - ilovalar joylashtirilgan tizim (bizning holatda, Kubernetes).

Git-da ish jarayonining tasviri

Aytaylik, siz Gitda shunday ishlayapsiz:

Diagrammadagi boshli belgi hozirda Kubernetes-da har qanday foydalanuvchilar (oxirgi foydalanuvchilar, testerlar, menejerlar va boshqalar) uchun joylashtirilgan yoki ishlab chiquvchilar tomonidan disk raskadrovka va shunga o'xshash maqsadlarda foydalaniladigan konteyner tasvirlarini bildiradi.

Tozalash qoidalari faqat rasmlarni saqlashga ruxsat bersa nima bo'ladi (o'chirilmasa) berilgan teg nomlari bo'yicha?

Shubhasiz, bunday stsenariy hech kimni xursand qilmaydi.

Agar qoidalar tasvirlarni oʻchirib tashlamaslikka ruxsat bersa, nima oʻzgaradi? ma'lum vaqt oralig'iga / oxirgi topshiriqlar soniga ko'ra?

Natija ancha yaxshilandi, lekin hali ham idealdan uzoq. Axir, bizda hali ham xatolarni tuzatish uchun ro'yxatga olish kitobida (yoki hatto K8-da joylashtirilgan) tasvirlarga muhtoj bo'lgan ishlab chiquvchilar bor ...

Bozorning joriy holatini sarhisob qilish uchun: konteyner registrlarida mavjud bo'lgan funktsiyalar tozalashda etarli darajada moslashuvchanlikni ta'minlamaydi va buning asosiy sababi. tashqi dunyo bilan aloqa qilishning imkoni yo'q. Ma'lum bo'lishicha, bunday moslashuvchanlikni talab qiladigan jamoalar Docker Registry API (yoki tegishli dasturning mahalliy API) yordamida tasvirni "tashqaridan" o'chirishni mustaqil ravishda amalga oshirishga majbur.

Biroq, biz turli registrlardan foydalangan holda turli jamoalar uchun tasvirni tozalashni avtomatlashtiradigan universal echim izlayotgan edik...

Bizning universal tasvirni tozalash yo'li

Bu ehtiyoj qayerdan kelib chiqadi? Gap shundaki, biz alohida ishlab chiquvchilar guruhi emas, balki bir vaqtning o'zida ularning ko'pchiligiga xizmat ko'rsatadigan, CI/CD bilan bog'liq muammolarni har tomonlama hal qilishga yordam beradigan jamoamiz. Buning uchun asosiy texnik vosita - Open Source yordam dasturi werf. Uning o'ziga xosligi shundaki, u bitta funktsiyani bajarmaydi, balki barcha bosqichlarda uzluksiz etkazib berish jarayonlariga hamroh bo'ladi: montajdan tortib to joylashtirishgacha.

Rasmlarni ro'yxatga olish kitobiga* nashr qilish (ular qurilganidan so'ng darhol) bunday yordamchi dasturning aniq vazifasidir. Va tasvirlar saqlash uchun u erda joylashtirilganligi sababli, agar sizning saqlashingiz cheksiz bo'lmasa, ularni keyingi tozalash uchun javobgar bo'lishingiz kerak. Belgilangan barcha mezonlarga javob beradigan muvaffaqiyatga qanday erishganimiz haqida keyinroq muhokama qilinadi.

* Garchi registrlarning o'zi har xil bo'lishi mumkin (Docker Registry, GitLab Container Registry, Harbor va boshqalar), ularning foydalanuvchilari bir xil muammolarga duch kelishadi. Bizning holatimizda universal yechim ro'yxatga olish kitobini amalga oshirishga bog'liq emas, chunki registrlardan tashqarida ishlaydi va hamma uchun bir xil xatti-harakatni taklif qiladi.

Garchi biz werf dan namuna sifatida foydalanayotgan bo'lsak-da, ishlatilgan yondashuvlar shunga o'xshash qiyinchiliklarga duch kelgan boshqa jamoalar uchun foydali bo'ladi deb umid qilamiz.

Shunday qilib, biz band bo'ldik tashqi tasvirlarni tozalash mexanizmini amalga oshirish - konteynerlar uchun registrlarga allaqachon kiritilgan imkoniyatlar o'rniga. Birinchi qadam teglar soni va ularni yaratish vaqti (yuqorida aytib o'tilgan) uchun bir xil ibtidoiy siyosatlarni yaratish uchun Docker Registry API-dan foydalanish edi. Ularga qo'shilgan o'rnatilgan infratuzilmada ishlatiladigan tasvirlar asosida ruxsat berish ro'yxati, ya'ni. Kubernetes. Ikkinchisi uchun barcha joylashtirilgan resurslarni takrorlash va qiymatlar ro'yxatini olish uchun Kubernetes API-dan foydalanish kifoya edi. image.

Ushbu ahamiyatsiz yechim eng muhim muammoni hal qildi (1-mezon), lekin tozalash mexanizmini takomillashtirish bo'yicha sayohatimizning boshlanishi edi. Keyingi va bundan ham qiziqroq qadam bu qaror edi nashr etilgan rasmlarni Git tarixi bilan bog'lash.

Belgilash sxemalari

Boshlash uchun biz yakuniy tasvirni tozalash uchun kerakli ma'lumotlarni saqlashi kerak bo'lgan yondashuvni tanladik va jarayonni teg sxemalari bo'yicha qurdik. Tasvirni nashr qilishda foydalanuvchi ma'lum bir teglash opsiyasini tanladi (git-branch, git-commit yoki git-tag) va tegishli qiymatdan foydalangan. CI tizimlarida bu qiymatlar atrof-muhit o'zgaruvchilari asosida avtomatik ravishda o'rnatildi. Aslida yakuniy tasvir ma'lum bir Git primitiv bilan bog'langan, teglarda tozalash uchun kerakli ma'lumotlarni saqlash.

Ushbu yondashuv Git-dan haqiqatning yagona manbai sifatida foydalanishga imkon beradigan bir qator siyosatlarga olib keldi:

Git-da filial/yorliq o'chirilganda, ro'yxatga olish kitobidagi bog'langan rasmlar avtomatik ravishda o'chiriladi.
Git teglari va majburiyatlari bilan bog'langan tasvirlar soni tanlangan sxemada ishlatiladigan teglar soni va tegishli majburiyat yaratilgan vaqt bilan boshqarilishi mumkin.

Umuman olganda, natijada amalga oshirish bizning ehtiyojlarimizni qondirdi, ammo tez orada bizni yangi sinov kutmoqda. Gap shundaki, Git primitivlari asosidagi teglash sxemalaridan foydalanishda biz bir qator kamchiliklarga duch keldik. (Ularning tavsifi ushbu maqola doirasidan tashqarida bo'lganligi sababli, hamma tafsilotlar bilan tanishishi mumkin shu yerda.) Shuning uchun, teglashning yanada samarali yondashuviga (kontentga asoslangan teglash) o'tishga qaror qilib, biz tasvirni tozalashni amalga oshirishni qayta ko'rib chiqishga majbur bo'ldik.

Yangi algoritm

Nega? Kontentga asoslangan teglar bilan har bir teg Git-da bir nechta majburiyatlarni qondirishi mumkin. Tasvirlarni tozalashda siz endi taxmin qila olmaysiz faqatgina reestrga yangi teg qo'shilgan majburiyatdan.

Yangi tozalash algoritmi uchun teglash sxemalaridan voz kechishga va qurishga qaror qilindi meta-tasvir jarayoni, ularning har biri bir nechta narsalarni saqlaydi:

nashr qilingan majburiyat (tasvir qo'shilganmi, o'zgartirilganmi yoki konteyner registrida o'zgarmaganligi muhim emas);
va yig'ilgan tasvirga mos keladigan ichki identifikatorimiz.

Boshqacha aytganda, u taqdim etildi nashr etilgan teglarni Gitdagi majburiyatlar bilan bog'lash.

Yakuniy konfiguratsiya va umumiy algoritm

Tozalashni sozlashda foydalanuvchilar endi joriy tasvirlarni tanlaydigan siyosatlarga kirishlari mumkin. Har bir bunday siyosat belgilanadi:

ko'p havolalar, ya'ni. Skanerlash paytida ishlatiladigan Git teglari yoki Git shoxlari;
va to'plamdagi har bir mos yozuvlar uchun qidirilgan tasvirlar chegarasi.

Tasavvur qilish uchun, standart siyosat konfiguratsiyasi shunday ko'rinishni boshladi:

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

Ushbu konfiguratsiya quyidagi qoidalarga mos keladigan uchta siyosatni o'z ichiga oladi:

Rasmni oxirgi 10 Git tegi uchun saqlang (teg yaratilish sanasi bo'yicha).
Oxirgi haftada chop etilgan 2 tadan koʻp boʻlmagan rasmni oxirgi haftadagi faolligi boʻlgan 10 ta mavzudan koʻp boʻlmagan holda saqlang.
Filiallar uchun 10 ta rasmni saqlang main, staging и production.

Yakuniy algoritm quyidagi bosqichlarga to'g'ri keladi:

Konteyner registridan manifestlar olinmoqda.
Kubernetesda ishlatiladigan tasvirlar bundan mustasno, chunki Biz allaqachon K8s API so'rovi orqali ularni oldindan tanlab oldik.
Git tarixini skanerlash va belgilangan siyosatlar asosida tasvirlarni istisno qilish.
Qolgan rasmlarni olib tashlash.

Bizning misolimizga qaytsak, werf bilan shunday sodir bo'ladi:

Biroq, agar siz werf dan foydalanmasangiz ham, tasvirni ilg'or tozalashga o'xshash yondashuv - u yoki bu dasturda (tasvirni teglashning afzal yondashuviga ko'ra) - boshqa tizimlar/utilitalar uchun ham qo'llanilishi mumkin. Buni amalga oshirish uchun yuzaga keladigan muammolarni eslab qolish va ularning echimini iloji boricha muammosiz birlashtirishga imkon beradigan stekingizdagi imkoniyatlarni topish kifoya. Umid qilamizki, biz bosib o'tgan yo'l sizning shaxsiy ishingizga yangi tafsilotlar va fikrlar bilan qarashingizga yordam beradi.

xulosa

Ertami-kechmi, aksariyat jamoalar ro'yxatga olish kitobining to'lib ketishi muammosiga duch kelishadi.
Yechimlarni izlashda, birinchi navbatda, tasvirning dolzarbligi mezonlarini aniqlash kerak.
Mashhur konteyner ro'yxatga olish xizmatlari tomonidan taqdim etilgan vositalar sizga "tashqi dunyo" ni hisobga olmaydigan juda oddiy tozalashni tashkil qilish imkonini beradi: Kubernetesda ishlatiladigan tasvirlar va jamoaning ish oqimlarining o'ziga xos xususiyatlari.
Moslashuvchan va samarali algoritm CI/CD jarayonlarini tushunishi va nafaqat Docker tasvir ma'lumotlari bilan ishlashi kerak.

PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

Konteyner tasvirlarini "aqlli" tozalash muammosi va uni werfda hal qilish