Hech qachon kech bo'lgan yaxshiroqdir. Yoki dastur tasvirlarini yaratish uchun oddiy Dockerfiles-ni qo'llab-quvvatlamasdan, qanday qilib deyarli jiddiy xatoga yo'l qo'ydik.
haqida gaplashamiz β GitOps yordam dasturi har qanday CI/CD tizimi bilan integratsiyalashgan va ilovaning butun hayotiy tsiklini boshqarish imkonini beradi:
- rasmlarni to'plash va nashr etish,
- Kubernetes-da ilovalarni joylashtirish,
- maxsus siyosatlar yordamida foydalanilmagan rasmlarni o'chirish.
Loyihaning falsafasi past darajadagi vositalarni DevOps muhandislariga ilovalar ustidan nazorat qilish imkonini beruvchi yagona yagona tizimga to'plashdan iborat. Iloji bo'lsa, mavjud yordamchi dasturlardan (masalan, Helm va Docker) foydalanish kerak. Agar muammoning yechimi bo'lmasa, biz buning uchun zarur bo'lgan hamma narsani yaratishimiz va qo'llab-quvvatlashimiz mumkin.
Fon: o'zingizning rasm kollektoringiz
Werf-dagi tasvir yig'uvchi bilan shunday bo'ldi: biz uchun odatiy Dockerfile etarli emas edi. Agar siz loyiha tarixiga tez nazar tashlasangiz, bu muammo werf ning birinchi versiyalarida allaqachon paydo bo'lgan (keyin hali ham ).
Docker tasvirlariga ilovalar yaratish vositasini yaratishda biz Dockerfile ba'zi juda aniq vazifalar uchun biz uchun mos emasligini tezda angladik:
- Quyidagi standart sxema bo'yicha odatiy kichik veb-ilovalarni yaratish zarurati:
- tizim bo'ylab ilovalarga bog'liqliklarni o'rnatish,
- ilovalarga bog'liqlik kutubxonalari to'plamini o'rnating,
- aktivlarni yig'ish,
- va eng muhimi, tasvirdagi kodni tez va samarali yangilash.
- Loyiha fayllariga o'zgartirishlar kiritilganda, quruvchi o'zgartirilgan fayllarga yamoqni qo'llash orqali tezda yangi qatlam yaratishi kerak.
- Agar ma'lum fayllar o'zgargan bo'lsa, unda tegishli bog'liq bosqichni qayta tiklash kerak.
Bugungi kunda bizning kollektorimiz boshqa ko'plab imkoniyatlarga ega, ammo bular dastlabki istak va istaklar edi.
Umuman olganda, ikki marta o'ylamasdan, biz foydalanadigan dasturlash tili bilan qurollandik (pastga qarang) va amalga oshirish uchun yo'lga tushdi shaxsiy DSL! Maqsadlarga muvofiq, yig'ish jarayonini bosqichma-bosqich tasvirlash va ushbu bosqichlarning fayllarga bog'liqligini aniqlash ko'zda tutilgan. Va uni to'ldirdi o'z kollektori, bu DSLni yakuniy maqsadga aylantirdi - yig'ilgan tasvir. Avvaliga DSL Ruby-da edi, lekin shunday β kollektorimizning konfiguratsiyasi YAML faylida tasvirlana boshladi.
Ruby-da dapp uchun eski konfiguratsiya
YAML da werf uchun joriy konfiguratsiya
Vaqt o'tishi bilan kollektorning mexanizmi ham o'zgardi. Avvaliga biz konfiguratsiyamizdan tezda vaqtinchalik Dockerfile-ni yaratdik, keyin esa vaqtinchalik konteynerlarda yig'ish ko'rsatmalarini ishga tushirishni va majburiyatlarni bajarishni boshladik.
NB: Hozirgi vaqtda o'z konfiguratsiyasi bilan ishlaydigan (YAMLda) va Stapel kollektori deb ataladigan kollektorimiz allaqachon ancha kuchli vositaga aylangan. Uning batafsil tavsifi alohida maqolalarga loyiqdir va asosiy ma'lumotlarni maqolada topish mumkin .
Muammodan xabardorlik
Lekin biz bir xatoga yo'l qo'yganimizni darhol anglab yetdik: qobiliyatni qo'shmadik standart Dockerfile orqali tasvirlarni yaratish va ularni bir xil uchdan-end ilovalarni boshqarish infratuzilmasiga integratsiyalash (ya'ni, tasvirlarni to'plash, ularni joylashtirish va tozalash). Qanday qilib Kubernetes-da joylashtirish uchun vosita yaratish va Dockerfile-ni qo'llab-quvvatlamaslik mumkin, ya'ni. Ko'pgina loyihalar uchun tasvirlarni tasvirlashning standart usuli?
Bu savolga javob berish o'rniga biz yechim taklif qilamiz. Agar sizda allaqachon Dockerfile (yoki Dockerfiles to'plami) bo'lsa va werf dan foydalanmoqchi bo'lsangiz-chi?
NB: Aytgancha, nega siz werf dan foydalanmoqchisiz? Asosiy xususiyatlar quyidagilarga to'g'ri keladi:
- to'liq ilovalarni boshqarish tsikli, shu jumladan tasvirni tozalash;
- bitta konfiguratsiyadan bir vaqtning o'zida bir nechta tasvirlarni yig'ishni boshqarish imkoniyati;
- Helm-mos diagrammalar uchun takomillashtirilgan joylashtirish jarayoni.
Ularning to'liq ro'yxatini quyidagi manzilda topishingiz mumkin .
Shunday qilib, agar ilgari biz o'z konfiguratsiyamizda Dockerfile-ni qayta yozishni taklif qilgan bo'lsak, endi biz mamnuniyat bilan aytamiz: "Werf sizning Docker-fayllaringizni yaratsin!"
Qanday foydalanish kerak?
Ushbu xususiyatning to'liq amalga oshirilishi relizda paydo bo'ldi . Umumiy printsip oddiy: foydalanuvchi werf konfiguratsiyasida mavjud Dockerfilega yo'lni belgilaydi va keyin buyruqni ishga tushiradi. werf build... va hammasi - werf tasvirni yig'adi. Keling, mavhum misolni ko'rib chiqaylik.
Keyingisini e'lon qilamiz Dockerfile loyiha ildizida:
FROM ubuntu:18.04
RUN echo Building ...
Va biz e'lon qilamiz werf.yamlbundan foydalanadi Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Hammasi! Chapga yugurish werf build:
Bundan tashqari, siz quyidagilarni e'lon qilishingiz mumkin werf.yaml bir vaqtning o'zida turli xil Docker fayllaridan bir nechta tasvirlarni yaratish uchun:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Va nihoyat, u qo'shimcha qurilish parametrlarini o'tkazishni ham qo'llab-quvvatlaydi, masalan --build-arg ΠΈ --add-host - werf konfiguratsiyasi orqali. Dockerfile tasvir konfiguratsiyasining toΚ»liq tavsifi bu yerda mavjud .
U qanday ishlaydi?
Qurilish jarayonida Docker-dagi mahalliy qatlamlarning standart keshi ishlaydi. Biroq, muhimi, bu werf ham Dockerfile konfiguratsiyasini o'z infratuzilmasiga birlashtiradi. Bu nimani anglatadi?
- Dockerfile-dan qurilgan har bir tasvir bir bosqichdan iborat
dockerfile(werfda qanday bosqichlar borligi haqida ko'proq o'qishingiz mumkin ). - Sahna uchun
dockerfilewerf Dockerfile konfiguratsiyasi tarkibiga bog'liq imzoni hisoblab chiqadi. Dockerfile konfiguratsiyasi o'zgarganda, bosqich imzosi o'zgaradidockerfileva werf bu bosqichni yangi Dockerfile konfiguratsiyasi bilan qayta qurishni boshlaydi. Agar imzo o'zgarmasa, u holda werf tasvirni keshdan oladi (werf-da imzolardan foydalanish haqida batafsil ma'lumot maqolada tasvirlangan ). - Keyinchalik, to'plangan tasvirlar buyruq bilan nashr etilishi mumkin
werf publish(yokiwerf build-and-publish) va uni Kubernetes-ga joylashtirish uchun foydalaning. Docker registriga chop etilgan tasvirlar standart werf tozalash vositalari yordamida tozalanadi, ya'ni. Eski rasmlar (N kundan eski), mavjud bo'lmagan Git filiallari bilan bog'liq rasmlar va boshqa siyosatlar avtomatik ravishda tozalanadi.
Bu erda tasvirlangan fikrlar haqida batafsil ma'lumotni hujjatlarda topishingiz mumkin:
- ;
- ;
- .
Eslatmalar va ehtiyot choralari
1. ADD da tashqi URL qoβllab-quvvatlanmaydi
Hozirda direktivda tashqi URL manzilidan foydalanish qo'llab-quvvatlanmaydi ADD. Belgilangan URL manzilidagi resurs o'zgarganda Werf qayta qurishni boshlamaydi. Tez orada ushbu xususiyatni qo'shishni rejalashtirmoqdamiz.
2. Tasvirga .git qo'sha olmaysiz
Umuman olganda, katalog qo'shish .git rasmda - yomon yomon amaliyot va nima uchun:
- agar
.gityakuniy tasvirda qoladi, bu tamoyillarni buzadi : Yakuniy rasm bitta majburiyat bilan bog'lanishi kerakligi sababli, buni amalga oshirish mumkin bo'lmasligi kerakgit checkouto'zboshimchalik bilan majburiyat. -
.gittasvir hajmini oshiradi (ombor katta bo'lishi mumkin, chunki unga bir marta katta fayllar qo'shilgan va keyin o'chirilgan). Faqat ma'lum bir majburiyat bilan bog'liq bo'lgan ish daraxtining o'lchami Gitdagi operatsiyalar tarixiga bog'liq bo'lmaydi. Bunday holda, qo'shish va keyinchalik olib tashlash.gityakuniy rasmdan ishlamaydi: tasvir hali ham qo'shimcha qatlamga ega bo'ladi - Docker shunday ishlaydi. - Docker keraksiz qayta qurishni boshlashi mumkin, hatto bir xil majburiyat qurilayotgan bo'lsa ham, lekin turli xil ishchi daraxtlardan. Masalan, GitLab alohida klonlangan kataloglarni yaratadi
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectparallel yig'ish yoqilganda. Qo'shimcha qayta yig'ish katalogi tufayli bo'ladi.gitbir xil omborning turli klonlangan versiyalarida, hatto bir xil majburiyat qurilgan bo'lsa ham, farq qiladi.
Oxirgi nuqta werfdan foydalanganda ham oqibatlarga olib keladi. Werf ba'zi buyruqlarni ishga tushirishda o'rnatilgan kesh mavjudligini talab qiladi (masalan. werf deploy). Ushbu buyruqlar bajarilganda, werf ko'rsatilgan tasvirlar uchun bosqich imzolarini hisoblab chiqadi werf.yaml, va ular montaj keshida bo'lishi kerak - aks holda buyruq ishlashni davom ettira olmaydi. Sahna imzosi tarkibga bog'liq bo'lsa .git, keyin biz ahamiyatsiz fayllardagi o'zgarishlarga beqaror bo'lgan keshni olamiz va werf bunday nazoratni kechira olmaydi (batafsil ma'lumot uchun qarang. ).
Umuman faqat ba'zi kerakli fayllarni qo'shish ko'rsatmalar orqali ADD har qanday holatda yozma ish samaradorligi va ishonchliligini oshiradi Dockerfile, shuningdek, buning uchun to'plangan keshning barqarorligini yaxshilaydi Dockerfile, Gitdagi ahamiyatsiz o'zgarishlarga.
Xulosa
Muayyan ehtiyojlar uchun o'z quruvchimizni yozishning dastlabki yo'li qiyin, halol va sodda edi: standart Dockerfile ustidagi tayoqchalardan foydalanish o'rniga, biz o'z yechimimizni maxsus sintaksis bilan yozdik. Va bu o'zining afzalliklariga ega edi: Stapel kollektori o'z vazifasini a'lo darajada bajara oladi.
Biroq, o'z quruvchimizni yozish jarayonida biz mavjud Dockerfiles-ni qo'llab-quvvatlashni yo'qotdik. Bu kamchilik tuzatildi va kelajakda biz tarqatilgan tuzilmalar va Kubernetes-dan (ya'ni kanikoda bo'lgani kabi Kubernetes ichidagi yuguruvchilarga quriladi) maxsus Stapel quruvchimiz bilan birgalikda Dockerfile yordamini ishlab chiqishni rejalashtirmoqdamiz.
Shunday qilib, agar sizda to'satdan bir nechta Docker fayli bo'lsa ... harakat qilib ko'ring !
PS Mavzu bo'yicha hujjatlar ro'yxati
- ;
- ;
- ;
- ;
- ;
- ;
- .
Bizning blogimizda ham o'qing: "".
Manba: www.habr.com