ilovalarni yaratish va Kubernetesga yetkazib berish uchun ochiq manbali GitOps CLI yordamchi dasturimiz. Va'da qilinganidek, werfga yangi xususiyatlar qo'shish va an'anaviy yondashuvlarni qayta ko'rib chiqish boshlanishini belgiladi. Endi biz rivojlanishdagi katta qadam va kelajak uchun poydevor bo'lgan v1.1 versiyasini taqdim etishdan mamnunmiz kollektor werf. Versiya hozirda mavjud .
Chiqarishning asosi - sahnani saqlashning yangi arxitekturasi va ikkala kollektorning ishini optimallashtirish (Stapel va Dockerfile uchun). Yangi saqlash arxitekturasi bir nechta xostlardan taqsimlangan yig'ilishlarni va bir xil xostda parallel yig'ilishlarni amalga oshirish imkoniyatini ochadi.
Ishni optimallashtirish bosqichli imzolarni hisoblash bosqichida keraksiz hisob-kitoblardan xalos bo'lishni va fayl nazorat summalarini hisoblash mexanizmlarini yanada samaraliroqlarga o'zgartirishni o'z ichiga oladi. Ushbu optimallashtirish werf yordamida loyihani qurishning o'rtacha vaqtini qisqartiradi. Va barcha bosqichlar keshda mavjud bo'lganda bo'sh tuzilmalar bosqichlari - saqlash, hozir juda tez. Ko'pgina hollarda, qurilishni qayta boshlash 1 soniyadan kamroq vaqtni oladi! Bu, shuningdek, jamoalar ishi jarayonining bosqichlarini tekshirish tartiblariga ham tegishli. werf deploy и werf run.
Shuningdek, ushbu nashrda tasvirlarni kontent bo'yicha belgilash strategiyasi paydo bo'ldi - kontentga asoslangan teglash, bu endi sukut bo'yicha yoqilgan va yagona tavsiya etilgan.
Keling, werf v1.1-dagi asosiy yangiliklarni batafsil ko'rib chiqamiz va shu bilan birga kelajak uchun rejalar haqida gapiramiz.
werf v1.1 da nima o'zgardi?
Yangi bosqich nomlash formati va keshdan bosqichlarni tanlash algoritmi
Yangi sahna nomini yaratish qoidasi. Endi har bir bosqich qurilishi 2 qismdan iborat noyob sahna nomini yaratadi: imzo (v1.0 da bo'lgani kabi) va noyob vaqtinchalik identifikator.
Masalan, sahna tasvirining toʻliq nomi quyidagicha koʻrinishi mumkin:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... yoki umuman:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Bu erda:
-
SIGNATUREsahna imzosi bo'lib, u sahna tarkibining identifikatorini ifodalaydi va Git-da ushbu tarkibga olib kelgan tahrirlar tarixiga bog'liq; -
TIMESTAMP_MILLISECyangi tasvirni yaratish vaqtida hosil bo'ladigan kafolatlangan noyob tasvir identifikatoridir.
Keshdan bosqichlarni tanlash algoritmi Git topshiriqlarining munosabatlarini tekshirishga asoslangan:
- Werf ma'lum bir bosqichning imzosini hisoblab chiqadi.
- В bosqichlari - saqlash Belgilangan imzo uchun bir necha bosqichlar bo'lishi mumkin. Werf imzoga mos keladigan barcha bosqichlarni tanlaydi.
- Agar joriy bosqich Git bilan bog'langan bo'lsa (git-arxiv, Git yamoqlari bilan maxsus bosqich:
install,beforeSetup,setup; yoki git-latest-patch), keyin werf faqat joriy commitning ajdodi bo'lgan majburiyat bilan bog'liq bo'lgan bosqichlarni tanlaydi (buning uchun qurilish deyiladi). - Qolgan mos bosqichlardan biri tanlanadi - yaratilgan sana bo'yicha eng qadimgi.
Turli Git filiallari uchun sahna bir xil imzoga ega bo'lishi mumkin. Ammo werf, imzolar mos bo'lsa ham, turli filiallar bilan bog'langan keshni ushbu filiallar o'rtasida ishlatishni oldini oladi.
.
Sahnani saqlashda bosqichlarni yaratish va saqlash uchun yangi algoritm
Agar keshdan bosqichlarni tanlashda werf mos bosqichni topmasa, yangi bosqichni yig'ish jarayoni boshlanadi.
E'tibor bering, bir nechta jarayonlar (bir yoki bir nechta xostlarda) taxminan bir vaqtning o'zida bir xil bosqichni qurishni boshlashi mumkin. Werf optimistik blokirovka algoritmidan foydalanadi bosqichlari - saqlash yangi to'plangan tasvirni saqlash vaqtida bosqichlari - saqlash. Shunday qilib, yangi bosqich qurilishi tayyor bo'lganda, werf bloklari bosqichlari - saqlash va yangi to'plangan tasvirni u yerda faqat mos tasvir mavjud bo'lmasagina saqlaydi (imzo va boshqa parametrlar bo'yicha - keshdan bosqichlarni tanlash uchun yangi algoritmga qarang).
Yangi yig'ilgan rasm noyob identifikatorga ega bo'lishi kafolatlanadi TIMESTAMP_MILLISEC (sahna nomlashning yangi formatiga qarang). In bo'lsa bosqichlari - saqlash mos rasm topiladi, werf yangi tuzilgan tasvirni o'chiradi va keshdagi tasvirni ishlatadi.
Boshqacha qilib aytadigan bo'lsak: tasvirni yaratishni tugatishning birinchi jarayoni (eng tez) uni bosqichma-bosqich saqlash huquqiga ega bo'ladi (va keyin bu yagona rasm barcha tuzilmalar uchun ishlatiladi). Sekin qurish jarayoni hech qachon tezroq jarayonni joriy bosqichning qurish natijalarini saqlash va keyingi qurishga o'tishga to'sqinlik qilmaydi.
.
Dockerfile quruvchisining ishlashi yaxshilandi
Hozirgi vaqtda Dockerfile-dan qurilgan tasvir uchun bosqichlar liniyasi bir bosqichdan iborat - dockerfile. Imzoni hisoblashda fayllarning nazorat summasi hisoblanadi context, yig'ish paytida foydalaniladi. Ushbu yaxshilanishdan oldin werf barcha fayllarni rekursiv ravishda aylanib chiqdi va har bir faylning konteksti va rejimini yig'ish orqali nazorat summasini oldi. V1.1 dan boshlab, werf Git omborida saqlangan hisoblangan nazorat summalaridan foydalanishi mumkin.
Algoritm shunga asoslanadi . Algoritm yozuvlarni hisobga oladi .dockerignore va faqat kerak bo'lganda fayl daraxtini rekursiv ravishda kesib o'tadi. Shunday qilib, biz fayl tizimini o'qishdan va algoritmning o'lchamga bog'liqligini ajratdik. context ahamiyatli emas.
Algoritm, shuningdek, kuzatilmagan fayllarni tekshiradi va agar kerak bo'lsa, ularni nazorat summasida hisobga oladi.
Fayllarni import qilishda ishlash yaxshilandi
werf v1.1 versiyalari qachon rsync serveridan foydalanadi . Ilgari import qilish xost tizimidan katalog o'rnatish yordamida ikki bosqichda amalga oshirildi.
MacOS operatsion tizimida import unumdorligi endi Docker hajmlari bilan cheklanmaydi va import Linux va Windows bilan bir xil vaqt ichida yakunlanadi.
Kontentga asoslangan teglash
Werf v1.1 tasvir mazmuni bo'yicha teglashni qo'llab-quvvatlaydi - kontentga asoslangan teglash. Olingan Docker tasvirlarining teglari ushbu tasvirlarning mazmuniga bog'liq.
Buyruqni bajarayotganda werf publish --tags-by-stages-signature yoki werf ci-env --tagging-strategy=stages-signature deb atalmish tasvirlarni chop etdi sahna imzosi tasvir. Har bir rasm ushbu rasmning bosqichlarining o'ziga xos imzosi bilan etiketlanadi, bu har bir bosqichning odatiy imzosi bilan bir xil qoidalarga muvofiq hisoblab chiqiladi, lekin rasmning umumiy identifikatori hisoblanadi.
Rasm bosqichlarining imzosi quyidagilarga bog'liq:
- ushbu rasmning mazmuni;
- Ushbu tarkibga olib kelgan Git o'zgarishlari tarixi.
Git omborida har doim rasm fayllari tarkibini o'zgartirmaydigan soxta majburiyatlar mavjud. Misol uchun, faqat sharhlar yoki birlashtirish majburiyatlari yoki Git-da rasmga import qilinmaydigan fayllarni o'zgartiradigan majburiyatlar.
Kontentga asoslangan teglashdan foydalanganda, rasmning mazmuni o'zgarmagan bo'lsa ham, rasm nomidagi o'zgarishlar tufayli Kubernetes-da dastur podkastlarini keraksiz qayta ishga tushirish muammolari hal qilinadi. Aytgancha, bu bitta dasturning ko'plab mikroservislarini bitta Git omborida saqlashga xalaqit beradigan sabablardan biridir.
Bundan tashqari, kontentga asoslangan teglash Git filiallarida teglashdan ko'ra ishonchliroq teglash usuli hisoblanadi, chunki natijada olingan tasvirlarning mazmuni bir xil filialning bir nechta majburiyatlarini yig'ish uchun CI tizimida quvurlarni bajarish tartibiga bog'liq emas.
Muhim: hozirdan boshlab bosqichlari - imzo Ismi? yagona tavsiya etilgan teglash strategiyasi. U buyruqda sukut bo'yicha ishlatiladi werf ci-env (agar siz boshqa teglash sxemasini aniq ko'rsatmasangiz).
. Bu xususiyatga alohida nashr ham bag'ishlanadi. YANGILANGAN (3 aprel): Tafsilotlar bilan maqola .
Jurnal darajalari
Endi foydalanuvchi chiqishni boshqarish, jurnalga yozish darajasini belgilash va disk raskadrovka ma'lumotlari bilan ishlash imkoniyatiga ega. Variantlar qo'shildi --log-quiet, --log-verbose, --log-debug.
Odatiy bo'lib, chiqish minimal ma'lumotlarni o'z ichiga oladi:
Batafsil chiqishdan foydalanilganda (--log-verbose) werf qanday ishlashini ko'rishingiz mumkin:
Batafsil chiqish (--log-debug), werf disk raskadrovka ma'lumotlaridan tashqari, ishlatilgan kutubxonalar jurnallarini ham o'z ichiga oladi. Masalan, siz Docker Registry bilan o'zaro aloqa qanday sodir bo'lishini ko'rishingiz mumkin, shuningdek, muhim vaqt sarflangan joylarni yozib olishingiz mumkin:
Kelajak rejalari
E'tibor bering! Quyida tavsiflangan variantlar belgilangan v1.1 Ushbu versiyada mavjud bo'ladi, ularning aksariyati yaqin kelajakda. Yangilanishlar avtomatik yangilanishlar orqali keladi . Bu xususiyatlar v1.1 funksiyalarining barqaror qismiga ta'sir qilmaydi; ularning ko'rinishi mavjud konfiguratsiyalarda qo'lda foydalanuvchi aralashuvini talab qilmaydi.
Har xil Docker Registry ilovalarini to'liq qo'llab-quvvatlash (YANGI)
- Versiya: v1.1
- Sanalar: mart
Maqsad - foydalanuvchi werf-dan foydalanishda cheklovlarsiz maxsus dasturdan foydalanishi.
Hozirgi vaqtda biz to'liq qo'llab-quvvatlashni kafolatlaydigan quyidagi echimlar to'plamini aniqladik:
- Standart (kutubxona/registr)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- GitHub paketlari
- GitLab registri*,
- Port*,
- Quay.
Hozirda werf tomonidan to'liq qo'llab-quvvatlanadigan yechimlar yulduzcha bilan belgilangan. Boshqalar uchun qo'llab-quvvatlash bor, lekin cheklovlar bilan.
Ikki asosiy muammoni aniqlash mumkin:
- Ba'zi echimlar Docker Registry API yordamida teglarni olib tashlashni qo'llab-quvvatlamaydi, bu esa foydalanuvchilarning werf-ning avtomatik tozalashidan foydalanishiga to'sqinlik qiladi. Bu AWS ECR, Docker Hub va GitHub paketlari uchun amal qiladi.
- Ba'zi echimlar ichki o'rnatilgan omborlarni (Docker Hub, GitHub paketlari va Quay) qo'llab-quvvatlamaydi yoki qo'llab-quvvatlamaydi, lekin foydalanuvchi ularni UI yoki API (AWS ECR) yordamida qo'lda yaratishi kerak.
Biz ushbu va boshqa muammolarni yechimlarning mahalliy API-laridan foydalangan holda hal qilamiz. Bu vazifa shuningdek, ularning har biri uchun testlar bilan werf ishlashining to'liq tsiklini qamrab olishni o'z ichiga oladi.
Taqsimlangan tasvir yaratish (↑)
- Versiya: v1.2 v1.1 (ushbu xususiyatni amalga oshirish uchun ustuvorlik oshirildi)
- Sanalar: mart-aprel mart
Ayni paytda werf v1.0 va v1.1 dan faqat bitta maxsus xostda tasvirlarni yaratish va nashr qilish hamda Kubernetes ilovasiga ilovani joylashtirish operatsiyalari uchun foydalanish mumkin.
Kubernetes-da ilovalarni yaratish va joylashtirish bir nechta ixtiyoriy xostlarda ishga tushirilganda va bu xostlar o'z holatini tuzilmalar (vaqtinchalik ishlaydiganlar) o'rtasida saqlamasa, werf-ning taqsimlangan ish imkoniyatlarini ochish uchun werf-dan foydalanish qobiliyatini amalga oshirish talab qilinadi. Docker Registry sahna do'koni sifatida.
Ilgari, werf loyihasi hali dapp deb atalganida, unda bunday imkoniyat bor edi. Biroq, biz werf-da ushbu funksiyani amalga oshirishda e'tiborga olinishi kerak bo'lgan bir qator muammolarga duch keldik.
nota. Bu xususiyat kollektordan Kubernetes podslari ichida ishlashini talab qilmaydi, chunki Buning uchun siz mahalliy Docker serveriga bog'liqlikdan xalos bo'lishingiz kerak (Kubernetes podida mahalliy Docker serveriga kirish imkoni yo'q, chunki jarayonning o'zi konteynerda ishlaydi va werf qo'llab-quvvatlamaydi va qo'llab-quvvatlamaydi. tarmoq orqali Docker serveri bilan ishlash). Kubernetes-ni ishga tushirishni qo'llab-quvvatlash alohida amalga oshiriladi.
GitHub Actions uchun rasmiy yordam (YANGI)
- Versiya: v1.1
- Sanalar: mart
werf hujjatlarini o'z ichiga oladi (bo'limlar ma'lumotnoma и hidoyat), shuningdek, werf bilan ishlash uchun rasmiy GitHub Action.
Bundan tashqari, u werfga efemer yuguruvchilarda ishlashga imkon beradi.
Foydalanuvchining CI tizimi bilan o'zaro aloqasi mexanikasi ilovani yaratish/chiqarish uchun muayyan harakatlarni boshlash uchun tortish so'rovlariga teglar joylashtirishga asoslanadi.
werf bilan ilovalarni mahalliy ishlab chiqish va joylashtirish (↓)
- Versiya: v1.1
- Sanalar: yanvar-fevral aprel
Asosiy maqsad - ilovalarni mahalliy va ishlab chiqarishda, murakkab harakatlarsiz, qutidan tashqarida joylashtirish uchun yagona yagona konfiguratsiyaga erishishdir.
werf shuningdek, dastur kodini tahrirlash va disk raskadrovka uchun ishlayotgan ilovadan bir zumda fikr-mulohazalarni qabul qilish uchun qulay bo'lgan ish rejimiga ega bo'lishi kerak.
Yangi tozalash algoritmi (YANGI)
- Versiya: v1.1
- Sanalar: aprel
Protsedurada werf v1.1 ning joriy versiyasida cleanup Kontentga asoslangan teglash sxemasi uchun tasvirlarni tozalash uchun hech qanday shart yo'q - bu tasvirlar to'planadi.
Shuningdek, werf ning joriy versiyasi (v1.0 va v1.1) teglash sxemalari ostida chop etilgan tasvirlar uchun turli xil tozalash siyosatlaridan foydalanadi: Git filiali, Git tegi yoki Git commit.
Barcha teglash sxemalari uchun birlashtirilgan Git-dagi topshiriqlar tarixiga asoslangan tasvirlarni tozalashning yangi algoritmi ixtiro qilindi:
- Har bir git HEAD (filiallar va teglar) uchun eng oxirgi N1 topshiriqlari bilan bog'langan N2 dan ortiq bo'lmagan rasmlarni saqlang.
- Har bir git HEAD (filiallar va teglar) uchun N1 eng soʻnggi majburiyatlari bilan bogʻliq boʻlgan N2 bosqichli tasvirlardan koʻp boʻlmagan holda saqlang.
- Har qanday Kubernetes klaster manbalarida ishlatiladigan barcha rasmlarni saqlang (konfiguratsiya faylining barcha kube kontekstlari va nomlar bo'shliqlari skanerdan o'tkaziladi; bu xatti-harakatni maxsus variantlar bilan cheklashingiz mumkin).
- Helm nashrlarida saqlangan resurs konfiguratsiyasi manifestlarida ishlatiladigan barcha rasmlarni saqlang.
- Tasvir git-dan hech qanday HEAD bilan bog'lanmagan bo'lsa (masalan, tegishli HEADning o'zi o'chirilganligi sababli) va Kubernetes klasteridagi hech qanday manifestlarda va Helm relizlarida ishlatilmasa, o'chirilishi mumkin.
Parallel tasvir yaratish (↓)
- Versiya: v1.1
- Sanalar: yanvar-fevral aprel*
Werfning joriy versiyasida tasvirlangan tasvirlar va artefaktlar to'plangan werf.yaml, ketma-ket. Tasvirlar va artefaktlarning mustaqil bosqichlarini yig'ish jarayonini parallellashtirish, shuningdek, qulay va informatsion chiqishni ta'minlash kerak.
* Eslatma: belgilangan muddat koʻproq gorizontal masshtablash imkoniyatlarini qoʻshadigan, shuningdek, GitHub Actions bilan werf-dan foydalanishni taʼminlaydigan taqsimlangan yigʻishni amalga oshirish ustuvorligi oshishi sababli oʻzgartirildi. Parallel yig'ish - bu bitta loyihani yig'ishda vertikal o'lchovni ta'minlovchi navbatdagi optimallashtirish bosqichidir.
3-rulga o‘tish (↓)
- Versiya: v1.2
- Sanalar: fevral-mart may*
Yangi kod bazasiga ko'chirishni o'z ichiga oladi va mavjud o'rnatishlarni ko'chirishning tasdiqlangan, qulay usuli.
* Eslatma: Helm 3-ga o'tish werf-ga muhim xususiyatlarni qo'shmaydi, chunki Helm 3-ning barcha asosiy xususiyatlari (3 tomonlama birlashma va tillersiz) allaqachon werf-da amalga oshirilgan. Bundan tashqari, werf bor ko'rsatilganlarga qo'shimcha ravishda. Biroq, bu o'tish bizning rejalarimizda qolmoqda va amalga oshiriladi.
Kubernetes konfiguratsiyasini tavsiflash uchun Jsonnet (↓)
- Versiya: v1.2
- Sanalar: yanvar-fevral aprel-may
Werf Jsonnet formatidagi Kubernetes uchun konfiguratsiya tavsiflarini qo'llab-quvvatlaydi. Shu bilan birga, werf Helm bilan mos bo'lib qoladi va tavsif formatini tanlash imkoniyati mavjud.
Sababi, Go shablonlari, ko'pchilikning fikriga ko'ra, yuqori kirish to'sig'iga ega va bu andozalar kodining tushunarliligi ham yomonlashadi.
Kubernetesning boshqa konfiguratsiya tavsif tizimlarini (masalan, Kustomize) joriy etish imkoniyati ham ko'rib chiqilmoqda.
Kubernetes ichida ishlash (↓)
- Versiya: v1.2
- Sanalar: aprel-may-may-iyun
Maqsad: Tasvirlar yaratilganiga va ilova Kubernetes-dagi yuguruvchilar yordamida yetkazib berilishiga ishonch hosil qiling. Bular. Yangi tasvirlarni toʻgʻridan-toʻgʻri Kubernetes podslaridan yaratish, chop etish, tozalash va joylashtirish mumkin.
Ushbu imkoniyatni amalga oshirish uchun siz avval taqsimlangan tasvirlarni yaratishingiz kerak (yuqoridagi nuqtaga qarang).
Shuningdek, u Docker serverisiz quruvchining ish rejimini qo'llab-quvvatlashni talab qiladi (ya'ni, Kanikoga o'xshash qurilish yoki foydalanuvchilar maydonida qurish).
Werf nafaqat Dockerfile bilan, balki asta-sekin qayta qurish va Ansible bilan Stapel quruvchisi bilan Kubernetes-da qurishni qo'llab-quvvatlaydi.
Ochiq rivojlanish sari qadam
Biz jamoamizni yaxshi ko'ramiz (, ) va biz tobora ko'proq odamlar werfni yaxshilashga yordam berishini, biz harakat qilayotgan yo'nalishni tushunishini va rivojlanishda ishtirok etishini xohlaymiz.
Yaqinda unga o'tishga qaror qilindi jamoamizning ish jarayonini ochib berish uchun. Endi siz yaqin kelajakdagi rejalarni, shuningdek, quyidagi yo'nalishlar bo'yicha joriy ishlarni ko'rishingiz mumkin:
- ;
- ;
- ;
- .
Muammolar bo'yicha ko'p ishlar qilindi:
- Ahamiyatsizlari olib tashlandi.
- Mavjudlari etarli miqdordagi tafsilotlar va tafsilotlar bilan yagona formatga keltiriladi.
- Fikr va takliflar bilan yangi masalalar qo‘shildi.
v1.1 versiyasini qanday yoqish mumkin
Versiya hozirda mavjud (kanallarda barqaror и tosh barqarorlashuv sodir bo'lganda relizlar paydo bo'ladi, ammo ea o'zi allaqachon foydalanish uchun etarlicha barqaror, chunki kanallardan o'tdi alfa и beta). Faollashtirilgan quyidagi tarzda:
source $(multiwerf use 1.1 ea)
werf COMMAND ...xulosa
Stapel va Dockerfile quruvchilari uchun yangi bosqichli saqlash arxitekturasi va quruvchi optimallashtirishlari werfda taqsimlangan va parallel tuzilmalarni amalga oshirish imkoniyatini ochadi. Bu funksiyalar tez orada o'sha v1.1 versiyasida paydo bo'ladi va avtomatik yangilash mexanizmi orqali avtomatik ravishda mavjud bo'ladi (foydalanuvchilar uchun) ).
Ushbu nashrda tasvir tarkibiga asoslangan teglash strategiyasi qo'shildi - kontentga asoslangan teglash, bu standart strategiyaga aylandi. Asosiy buyruqlar jurnali ham qayta ishlandi: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Keyingi muhim qadam taqsimlangan yig'ilishlarni qo'shishdir. Tarqatilgan tuzilmalar v1.0 dan boshlab parallel tuzilmalarga qaraganda ustuvor ahamiyatga ega boʻldi, chunki ular werfga koʻproq qiymat qoʻshadi: quruvchilarning vertikal miqyosi va turli CI/CD tizimlarida vaqtinchalik quruvchilarni qoʻllab-quvvatlash, shuningdek, GitHub Actions uchun rasmiy yordam koʻrsatish qobiliyati. . Shu sababli, parallel yig'ilishlarni amalga oshirish muddatlari o'zgartirildi. Biroq, biz ikkala imkoniyatni ham imkon qadar tezroq amalga oshirishga harakat qilmoqdamiz.
Yangiliklarni kuzatib boring! Va bizga tashrif buyurishni unutmang muammo yaratish, mavjudni toping va ortiqcha qo'shing, PR yarating yoki shunchaki loyihaning rivojlanishini tomosha qiling.
PS
Shuningdek, bizning blogimizda o'qing:
- «»
- «";
- Werf-dagi innovatsiyalar haqida bir qator eslatmalar:
- «";
- «";
- «";
- «".
Manba: www.habr.com