Hammaga salom! Mening ismim Pavel Agaletskiy. Men Lamoda yetkazib berish tizimini ishlab chiquvchi jamoada guruh rahbari sifatida ishlayman. 2018 yilda men HighLoad++ konferensiyasida nutq so‘zladim va bugun men o‘z hisobotimning stenogrammasini taqdim qilmoqchiman.

Mening mavzuim kompaniyamizning tizimlar va xizmatlarni turli muhitlarga joylashtirish tajribasiga bag'ishlangan. Tarixdan oldingi davrlarimizdan boshlab, biz barcha tizimlarni oddiy virtual serverlarga joylashtirganimizda, Nomaddan asta-sekin Kubernetesda joylashtirishga o'tish bilan yakunlanadi. Men sizga nima uchun buni qilganimizni va bu jarayonda qanday muammolarga duch kelganimizni aytib beraman.

Ilovalarni VMga joylashtirish

Keling, 3 yil oldin kompaniyaning barcha tizimlari va xizmatlari oddiy virtual serverlarga joylashtirilganligidan boshlaylik. Texnik jihatdan, u shunday tashkil etilganki, bizning tizimlarimiz uchun barcha kodlar jenkins yordamida avtomatik yig'ish vositalari yordamida saqlanadi va yig'iladi. Ansible-dan foydalanib, u versiyani boshqarish tizimimizdan virtual serverlarga chiqarildi. Bundan tashqari, kompaniyamizda mavjud bo'lgan har bir tizim kamida ikkita serverga joylashtirilgan: ulardan biri boshida, ikkinchisi quyruqda. Ushbu ikki tizim barcha sozlamalari, quvvati, konfiguratsiyasi va boshqalarda bir-biriga mutlaqo o'xshash edi. Ularning orasidagi yagona farq shundaki, bosh foydalanuvchi trafikini qabul qildi, quyruq esa hech qachon foydalanuvchi trafigini olmadi.

Bu nima uchun qilingan?

Ilovamizning yangi relizlarini tarqatganimizda, biz uzluksiz, ya'ni foydalanuvchilar uchun sezilarli oqibatlarsiz chiqarilishini ta'minlashni xohladik. Bunga Ansible yordamida keyingi kompilyatsiya qilingan relizning oxirigacha chiqarilishi tufayli erishildi. U erda joylashtirishda ishtirok etgan odamlar hamma narsa yaxshi ekanligini tekshirishlari va ishonch hosil qilishlari mumkin edi: barcha o'lchovlar, bo'limlar va ilovalar ishlagan; kerakli skriptlar ishga tushiriladi. Hammasi joyida ekanligiga ishonch hosil qilgandan keyingina transport harakati o'zgartirildi. Ilgari quyruq bo'lgan serverga borishni boshladi. Ilgari bosh bo'lgan dastur hali ham bizning ilovamizning oldingi versiyasiga ega bo'lgan holda, foydalanuvchi trafigisiz qoldi.

Shunday qilib, foydalanuvchilar uchun muammosiz edi. Chunki kommutatsiya bir zumda amalga oshiriladi, chunki u shunchaki balanslagichni almashtiradi. Balanslashtiruvchini orqaga almashtirish orqali siz avvalgi versiyaga osongina qaytishingiz mumkin. Shuningdek, dastur foydalanuvchi trafigini olishdan oldin ham ishlab chiqarishga qodirligini tekshirishimiz mumkin edi, bu juda qulay edi.

Bularning barchasida qanday afzalliklarni ko'rdik?

1. Birinchidan, bu etarli u shunchaki ishlaydi. Bunday joylashtirish sxemasi qanday ishlashini hamma tushunadi, chunki ko'pchilik oddiy virtual serverlarga o'rnatgan.
2. Bu yetarli ishonchli, chunki joylashtirish texnologiyasi oddiy, minglab kompaniyalar tomonidan sinovdan o'tgan. Millionlab serverlar shu tarzda joylashtirilgan. Biror narsani buzish qiyin.
3. Va nihoyat, biz erisha oldik atomlarni joylashtirish. Eski versiya va yangi versiya o'rtasida o'tishning sezilarli bosqichisiz foydalanuvchilar uchun bir vaqtning o'zida amalga oshiriladigan joylashtirishlar.

Ammo biz bularning barchasida bir qator kamchiliklarni ham ko'rdik:

1. Ishlab chiqarish muhiti, rivojlanish muhiti bilan bir qatorda, boshqa muhitlar ham mavjud. Masalan, qa va preproduction. O'sha paytda bizda ko'plab serverlar va 60 ga yaqin xizmatlar mavjud edi. Shu sababli kerak edi har bir xizmat uchun uning eng so'nggi versiyasini saqlang virtual mashina. Bundan tashqari, agar siz kutubxonalarni yangilamoqchi bo'lsangiz yoki yangi bog'liqliklarni o'rnatmoqchi bo'lsangiz, buni barcha muhitlarda qilishingiz kerak. Shuningdek, ilovangizning keyingi yangi versiyasini joylashtirmoqchi bo'lgan vaqtni devops zarur muhit sozlamalarini bajaradigan vaqt bilan sinxronlashtirishingiz kerak edi. Bunday holda, bizning muhitimiz bir vaqtning o'zida barcha muhitlarda biroz boshqacha bo'ladigan vaziyatga tushish oson. Masalan, QA muhitida kutubxonalarning ba'zi versiyalari bo'ladi, ishlab chiqarish muhitida esa har xil bo'ladi, bu esa muammolarga olib keladi.
2. Bog'liqlarni yangilash qiyinligi arizangiz. Bu sizga emas, balki boshqa jamoaga bog'liq. Ya'ni, serverlarga xizmat ko'rsatadigan devops jamoasidan. Siz ularga tegishli topshiriq va nima qilishni xohlayotganingizning tavsifini berishingiz kerak.
3. O'sha paytda biz ham mavjud bo'lgan katta yirik monolitlarni alohida kichik xizmatlarga bo'lishni xohladik, chunki biz ularning soni tobora ko'payib borishini tushungan edik. O'sha paytda bizda ularning 100 dan ortig'i bor edi.Har bir yangi xizmat uchun alohida yangi virtual mashina yaratish kerak edi, uni ham saqlab turish va joylashtirish kerak edi. Bundan tashqari, sizga bitta mashina emas, balki kamida ikkitasi kerak. Bularning barchasiga QA muhiti qo'shiladi. Bu muammolarni keltirib chiqaradi va yangi tizimlarni yaratish va ishga tushirishni qiyinlashtiradi. murakkab, qimmat va uzoq jarayon.

Shuning uchun biz odatiy virtual mashinalarni joylashtirishdan ilovalarimizni docker konteyneriga joylashtirishga o'tish qulayroq bo'ladi, deb qaror qildik. Agar sizda docker bo'lsa, dasturni klasterda ishga tushiradigan tizim kerak, chunki siz shunchaki konteynerni ko'tarolmaysiz. Odatda siz qancha konteyner ko'tarilishini kuzatib borishni xohlaysiz, shunda ular avtomatik ravishda ko'tariladi. Shuning uchun biz boshqaruv tizimini tanlashimiz kerak edi.

Qaysi birini olishimiz mumkinligi haqida uzoq o'yladik. Gap shundaki, o'sha paytda oddiy virtual serverlarda ushbu joylashtirish stekasi biroz eskirgan edi, chunki ularda operatsion tizimlarning so'nggi versiyalari yo'q edi. Bir nuqtada, hatto qo'llab-quvvatlash uchun juda qulay bo'lmagan FreeBSD ham mavjud edi. Biz dockerga imkon qadar tezroq o'tishimiz kerakligini tushundik. Bizning devoplar o'zlarining mavjud tajribalarini turli xil echimlar bilan ko'rib chiqdilar va Nomad kabi tizimni tanladilar.

Nomad-ga o'tish

Nomad - HashiCorp mahsuloti. Ular boshqa yechimlari bilan ham mashhur:

"Konsul" xizmatlarni aniqlash vositasidir.

"Terraforma" - serverlarni boshqarish tizimi, ularni konfiguratsiya orqali sozlash imkonini beradi, ya'ni kod sifatida infratuzilma.

"Vagrant" ma'lum konfiguratsiya fayllari orqali virtual mashinalarni mahalliy yoki bulutda joylashtirish imkonini beradi.

O'sha paytda Nomad butun infratuzilmani o'zgartirmasdan tezda o'tish mumkin bo'lgan juda oddiy echimga o'xshardi. Bundan tashqari, o'rganish juda oson. Shuning uchun biz uni idishimiz uchun filtrlash tizimi sifatida tanladik.

Nomad-ga tizimingizni joylashtirish uchun nima kerak?

1. Avvalo sizga kerak docker tasviri arizangiz. Siz uni qurishingiz va docker tasvirlar omboriga joylashtirishingiz kerak. Bizning holatda, bu artefakt - unga har xil turdagi turli artefaktlarni surish imkonini beradigan tizim. U arxivlarni, docker tasvirlarini, kompozitor PHP paketlarini, NPM paketlarini va hokazolarni saqlashi mumkin.
2. Shuningdek, kerak konfiguratsiya fayli, bu Nomadga nimani, qayerda va qancha miqdorda joylashtirmoqchi ekanligingizni aytadi.

Nomad haqida gapiradigan bo'lsak, u HCL tilidan ma'lumot fayl formati sifatida foydalanadi, ya'ni HashiCorp konfiguratsiya tili. Bu Yaml ning yuqori to'plami bo'lib, u sizga xizmatingizni Nomad so'zlari bilan tavsiflash imkonini beradi.

Bu sizga qancha konteynerni joylashtirmoqchi ekanligingizni, qaysi rasmlardan joylashtirish paytida ularga turli parametrlarni o'tkazish kerakligini aytish imkonini beradi. Shunday qilib, siz ushbu faylni Nomad-ga berasiz va u konteynerlarni unga muvofiq ishlab chiqarishga boshlaydi.

Bizning holatda, biz har bir xizmat uchun mutlaqo bir xil HCL fayllarini yozish juda qulay bo'lmasligini tushundik, chunki juda ko'p xizmatlar mavjud va ba'zida siz ularni yangilashni xohlaysiz. Shunday bo'ladiki, bitta xizmat bir instansiyada emas, balki turli xillarida joylashtiriladi. Misol uchun, biz ishlab chiqarishda mavjud bo'lgan tizimlardan biri ishlab chiqarishda 100 dan ortiq nusxalarga ega. Ular bir xil tasvirlardan ishlaydi, lekin konfiguratsiya sozlamalari va konfiguratsiya fayllarida farqlanadi.

Shuning uchun biz barcha konfiguratsiya fayllarimizni bitta umumiy omborda joylashtirish uchun qulay bo'lishiga qaror qildik. Shu tarzda ular ko'rinardi: ularga xizmat ko'rsatish oson edi va biz qanday tizimlar mavjudligini ko'ra oldik. Agar kerak bo'lsa, biror narsani yangilash yoki o'zgartirish ham oson. Yangi tizimni qo'shish ham qiyin emas - faqat yangi katalog ichida konfiguratsiya faylini yaratishingiz kerak. Uning ichida quyidagi fayllar mavjud: xizmatimiz tavsifini o'z ichiga olgan service.hcl va ishlab chiqarishda qo'llaniladigan ushbu xizmatni sozlash imkonini beruvchi ba'zi env fayllari.

Biroq, bizning ba'zi tizimlarimiz ishlab chiqarishda bir nusxada emas, balki bir vaqtning o'zida bir nechta nusxada joylashtirilgan. Shuning uchun biz konfiguratsiyalarni sof shaklda emas, balki shablon shaklida saqlash biz uchun qulay bo'ladi, deb qaror qildik. Va biz tanladik jinja 2. Ushbu formatda biz xizmatning konfiguratsiyasini ham, unga kerak bo'lgan env fayllarini ham saqlaymiz.

Bundan tashqari, biz omborga barcha loyihalar uchun umumiy bo'lgan joylashtirish skriptini joylashtirdik, bu sizning xizmatingizni ishlab chiqarishga, kerakli muhitga, kerakli maqsadga yo'naltirish imkonini beradi. Agar biz HCL konfiguratsiyasini shablonga aylantirgan bo'lsak, ilgari oddiy Nomad konfiguratsiyasi bo'lgan HCL fayli bu holda biroz boshqacha ko'rinishni boshladi.

Ya'ni, biz ba'zi konfiguratsiya joylashuvi o'zgaruvchilarini env fayllari yoki boshqa manbalardan olingan kiritilgan o'zgaruvchilar bilan almashtirdik. Bundan tashqari, biz HCL fayllarini dinamik ravishda yig'ish imkoniyatiga ega bo'ldik, ya'ni biz nafaqat oddiy o'zgaruvchan qo'shimchalardan foydalanishimiz mumkin. Jinja looplar va shartlarni qo'llab-quvvatlaganligi sababli, siz u erda konfiguratsiya fayllarini ham yaratishingiz mumkin, ular ilovalaringizni aynan qayerda joylashtirganingizga qarab o'zgaradi.

Misol uchun, siz o'z xizmatingizni ishlab chiqarishdan oldingi va ishlab chiqarishga yo'naltirmoqchisiz. Aytaylik, ishlab chiqarishdan oldin siz cron skriptlarini ishga tushirishni xohlamaysiz, lekin u ishlayotganiga ishonch hosil qilish uchun xizmatni alohida domenda ko'rishni xohlaysiz. Xizmatni ishlatadigan har bir kishi uchun jarayon juda oddiy va shaffof ko'rinadi. Sizga kerak bo'lgan narsa deploy.sh faylini ishga tushirish, qaysi xizmatni o'rnatmoqchi va qaysi maqsadni belgilash. Masalan, siz ma'lum bir tizimni Rossiya, Belarus yoki Qozog'istonga joylashtirmoqchisiz. Buni amalga oshirish uchun faqat parametrlardan birini o'zgartiring va siz to'g'ri konfiguratsiya fayliga ega bo'lasiz.

Nomad xizmati sizning klasteringizga allaqachon o'rnatilgan bo'lsa, u shunday ko'rinadi.

Birinchidan, sizga barcha foydalanuvchi trafigini qabul qiladigan tashqarida qandaydir balanser kerak. U konsul bilan birgalikda ishlaydi va undan ma'lum bir domen nomiga mos keladigan ma'lum bir xizmat qayerda, qaysi tugunda, qaysi IP-manzilda joylashganligini aniqlaydi. Konsuldagi xizmatlar Nomadning o'zidan keladi. Ular bir kompaniyaning mahsulotlari bo'lgani uchun ular bir-biriga juda bog'liq. Aytishimiz mumkinki, Nomad qutidan tashqari unda ishga tushirilgan barcha xizmatlarni Konsul ichida ro'yxatdan o'tkazishi mumkin.

Sizning oldingi yuk balanslagichingiz qaysi xizmatga trafik jo'natish kerakligini bilgandan so'ng, uni tegishli konteynerga yoki ilovangizga mos keladigan bir nechta konteynerga yo'naltiradi. Tabiiyki, xavfsizlik haqida ham o'ylash kerak. Garchi barcha xizmatlar konteynerlarda bir xil virtual mashinalarda ishlayotgan bo'lsa ham, bu odatda har qanday xizmatdan boshqasiga bepul kirishni oldini olishni talab qiladi. Biz bunga segmentatsiya orqali erishdik. Har bir xizmat o'zining virtual tarmog'ida ishga tushirildi, unda marshrutlash qoidalari va boshqa tizimlar va xizmatlarga kirishga ruxsat berish / rad etish qoidalari belgilangan. Ular ushbu klaster ichida ham, uning tashqarisida ham joylashishi mumkin edi. Misol uchun, agar siz xizmatning ma'lum bir ma'lumotlar bazasiga ulanishini oldini olishni istasangiz, bu tarmoq darajasidagi segmentatsiya orqali amalga oshirilishi mumkin. Ya'ni, xato bo'lsa ham, siz tasodifan sinov muhitidan ishlab chiqarish ma'lumotlar bazasiga ulana olmaysiz.

O‘tish davri bizga inson resurslari nuqtai nazaridan qanchaga tushdi?

Butun kompaniyaning Nomadga o'tishi taxminan 5-6 oy davom etdi. Biz xizmat ko'rsatish asosida harakat qildik, lekin juda tez sur'atda. Har bir jamoa xizmatlar uchun o'z konteynerlarini yaratishi kerak edi.

Biz shunday yondashuvni qabul qildikki, har bir jamoa o'z tizimlarining docker tasvirlari uchun mustaqil ravishda javobgar bo'ladi. Devops joylashtirish uchun zarur bo'lgan umumiy infratuzilmani ta'minlaydi, ya'ni klasterning o'zini qo'llab-quvvatlaydi, CI tizimini qo'llab-quvvatlaydi va hokazo. Va o'sha paytda bizda Nomadga 60 dan ortiq tizim ko'chirildi, bu taxminan 2 ming konteynerni tashkil etdi.

Devops joylashtirish va serverlar bilan bog'liq barcha narsalarning umumiy infratuzilmasi uchun javobgardir. Va har bir ishlab chiqish guruhi, o'z navbatida, o'ziga xos tizim uchun konteynerlarni amalga oshirish uchun javobgardir, chunki u odatda ma'lum bir konteynerda nima kerakligini biladigan jamoadir.

Nomaddan voz kechish sabablari

Boshqalar qatorida Nomad va docker-dan foydalangan holda joylashtirishga o'tish orqali qanday afzalliklarga erishdik?

1. Biz shundaymiz teng sharoit yaratib berdi barcha muhitlar uchun. Rivojlanishda QA muhiti, oldindan ishlab chiqarish, ishlab chiqarish, bir xil bog'liqliklar bilan bir xil konteyner tasvirlari ishlatiladi. Shunga ko'ra, ishlab chiqarishda yakunlanadigan narsa siz avval mahalliy yoki sinov muhitida sinab ko'rgan narsangiz emasligiga deyarli hech qanday imkoniyatingiz yo'q.
2. Biz ham yetarli ekanligini aniqladik yangi xizmatni qo'shish oson. Joylashtirish nuqtai nazaridan har qanday yangi tizimlar juda sodda tarzda ishga tushiriladi. Faqat konfiguratsiyalar saqlanadigan omborga o'ting, u erda tizimingiz uchun boshqa konfiguratsiyani qo'shing va hamma narsa tayyor. Siz devoplardan hech qanday qo'shimcha harakatlarsiz tizimingizni ishlab chiqarishga joylashtirishingiz mumkin.
3. hamma konfiguratsiya fayllari bitta umumiy omborda ko‘rib chiqilayotgani ma’lum bo‘ldi. Tizimlarimizni virtual serverlar yordamida joylashtirganimizda, konfiguratsiyalar bir xil omborda joylashgan Ansible-dan foydalanganmiz. Biroq, ko'pchilik ishlab chiquvchilar uchun bu bilan ishlash biroz qiyinroq edi. Bu erda xizmatni o'rnatish uchun qo'shishingiz kerak bo'lgan konfiguratsiyalar va kodlar hajmi ancha kichik bo'ldi. Bundan tashqari, devoplar uni tuzatishi yoki o'zgartirishi juda oson. Masalan, Nomad-ning yangi versiyasiga o'tish holatlarida ular bir joyda joylashgan barcha operatsion fayllarni olib, ommaviy yangilashlari mumkin.

Ammo biz bir qator kamchiliklarga ham duch keldik:

Ma'lum bo'ldiki, biz uzluksiz joylashtirishga erisha olmadi Nomad misolida. Konteynerlarni turli sharoitlarda ishlab chiqarishda u ishlayotgan bo'lib chiqishi mumkin edi va Nomad uni trafikni qabul qilishga tayyor konteyner sifatida qabul qildi. Bu uning ichidagi ilova ishga tushirish imkoniyatiga ega bo'lmasdan oldin sodir bo'ldi. Shu sababli, tizim qisqa vaqt ichida 500 ta xato ishlab chiqara boshladi, chunki transport hali uni qabul qilishga tayyor bo'lmagan konteynerga keta boshladi.

Biz ba'zilariga duch keldik botqoqlar tomonidan. Eng muhim xato shundaki, agar sizda ko'plab tizim va konteynerlar mavjud bo'lsa, Nomad katta klasterni yaxshi ishlamaydi. Nomad klasteriga kiritilgan serverlardan birini texnik xizmat ko'rsatish uchun olib tashlamoqchi bo'lsangiz, klaster o'zini juda yaxshi his qilmasligi va parchalanib ketishi ehtimoli juda yuqori. Ba'zi konteynerlar, masalan, tushishi va ko'tarilmasligi mumkin - agar sizning barcha ishlab chiqarish tizimlaringiz Nomad tomonidan boshqariladigan klasterda joylashgan bo'lsa, bu sizga juda qimmatga tushadi.

Shunday qilib, biz keyingi qayerga borishimiz haqida o'ylashga qaror qildik. O'sha paytda biz nimaga erishmoqchi ekanligimizni ko'proq anglab yetdik. Ya'ni: biz ishonchlilik, Nomad taqdim etganidan bir oz ko'proq funktsiyalar va yanada etukroq, barqarorroq tizimni xohlaymiz.

Shu munosabat bilan bizning tanlovimiz klasterlarni ishga tushirish uchun eng mashhur platforma sifatida Kubernetesga tushdi. Ayniqsa, konteynerlarimiz hajmi va soni etarlicha katta bo'lganini hisobga olsak. Bunday maqsadlar uchun Kubernetes biz ko'rib chiqishimiz mumkin bo'lgan eng mos tizim bo'lib tuyuldi.

Kubernetesga o'tish

Men sizga Kubernetesning asosiy tushunchalari va ular Nomaddan qanday farq qilishlari haqida bir oz aytib beraman.

Birinchidan, Kubernetesdagi eng asosiy tushuncha pod tushunchasi. Podkast har doim birga ishlaydigan bir yoki bir nechta konteynerlar guruhidir. Va ular har doim xuddi bitta virtual mashinada ishlaydilar. Ular turli portlarda IP 127.0.0.1 orqali bir-biriga kirishlari mumkin.

Faraz qilaylik, sizda nginx va php-fpm - klassik sxemadan iborat PHP ilovasi bor. Katta ehtimol bilan siz nginx va php-fpm konteynerlarini har doim birga saqlashni xohlaysiz. Kubernetes ularni bitta umumiy pod sifatida tasvirlash orqali bunga erishishga imkon beradi. Aynan shu narsa biz Nomad bilan erisha olmadik.

Ikkinchi tushuncha tarqatish. Gap shundaki, podaning o'zi vaqtinchalik narsa, u boshlanadi va yo'qoladi. Avval barcha oldingi konteynerlaringizni o‘chirib, so‘ngra birdaniga yangi versiyalarni ishga tushirishni xohlaysizmi yoki ularni bosqichma-bosqich chiqarishni xohlaysizmi? Bu joylashtirish kontseptsiyasi uchun javobgar bo‘lgan jarayondir. Unda podkastlaringizni qanday joylashtirishingiz, qancha miqdorda va ularni qanday yangilash kerakligi tasvirlangan.

Uchinchi tushuncha xizmat. Sizning xizmatingiz aslida sizning tizimingiz bo'lib, u bir oz trafikni qabul qiladi va keyin uni xizmatingizga mos keladigan bir yoki bir nechta podkalarga yo'naltiradi. Ya'ni, u falon xizmatga falon nom bilan kiruvchi barcha trafikni mana shu aniq podkastlarga yuborish kerakligini aytishga imkon beradi. Va shu bilan birga u sizga trafik balansini ta'minlaydi. Ya'ni, siz ilovangizning ikkita podkastini ishga tushirishingiz mumkin va barcha kiruvchi trafik ushbu xizmatga tegishli bo'laklar o'rtasida teng ravishda muvozanatlanadi.

Va to'rtinchi asosiy tushuncha Kirish. Bu Kubernetes klasterida ishlaydigan xizmat. U barcha so'rovlarni qabul qiladigan tashqi yuk balansi vazifasini bajaradi. Kubernetes API-dan foydalanib, Ingress ushbu so'rovlar qayerga yuborilishi kerakligini aniqlay oladi. Bundan tashqari, u buni juda moslashuvchan qiladi. Aytishingiz mumkinki, ushbu xost va falon URL manziliga barcha so'rovlar ushbu xizmatga yuboriladi. Va bu xostga va boshqa URL manziliga kelgan bu so'rovlar boshqa xizmatga yuboriladi.

Ilovani ishlab chiqadigan odam nuqtai nazaridan eng zo'r narsa shundaki, siz uni o'zingiz boshqarishingiz mumkin. Ingress konfiguratsiyasini o'rnatish orqali siz falon APIga keladigan barcha trafikni, masalan, Go'da yozilgan alohida konteynerlarga yuborishingiz mumkin. Ammo bir xil domenga kelgan, ammo boshqa URL manziliga keladigan bu trafik PHP-da yozilgan konteynerlarga yuborilishi kerak, bu erda juda ko'p mantiq bor, lekin ular juda tez emas.

Agar biz ushbu tushunchalarning barchasini Nomad bilan solishtiradigan bo'lsak, birinchi uchta tushunchaning barchasi birgalikda Xizmat ekanligini aytishimiz mumkin. Va oxirgi tushuncha Nomadning o'zida yo'q. Biz tashqi balanslagichdan foydalandik: u haproxy, nginx, nginx+ va boshqalar bo'lishi mumkin. Kub holatida ushbu qo'shimcha kontseptsiyani alohida kiritishingiz shart emas. Ammo, agar siz Ingress-ga ichki tomondan qarasangiz, u nginx, haproksi yoki traefik, ammo Kubernetes-ga o'rnatilgan.

Men ta'riflagan barcha tushunchalar, aslida, Kubernetes klasterida mavjud bo'lgan resurslardir. Ularni kub shaklida tasvirlash uchun yaml formati qo'llaniladi, bu Nomad misolida HCL fayllariga qaraganda ko'proq o'qilishi va tanish. Ammo tizimli ravishda ular xuddi shu narsani, masalan, pod holatida tasvirlaydi. Ular aytadilar - men u erda falon podkastlarni, falon tasvirlar bilan, falon miqdorda joylashtirmoqchiman.

Bundan tashqari, biz har bir alohida resursni qo'lda yaratishni xohlamasligimizni angladik: joylashtirish, xizmatlar, kirish va hk. Buning o'rniga, biz barcha kerakli resurs bog'liqliklarini to'g'ri tartibda qo'lda qayta yaratishga majbur bo'lmasligimiz uchun joylashtirish paytida har bir tizimimizni Kubernetes nuqtai nazaridan tavsiflashni xohladik. Buni amalga oshirishga imkon beradigan tizim sifatida Helm tanlangan.

Helm tilidagi asosiy tushunchalar

Rulda paket menejeri Kubernetes uchun. Bu dasturlash tillarida paket menejerlari qanday ishlashiga juda o'xshaydi. Ular sizga, masalan, nginx deployment, deployment php-fpm, Config for Ingress, configmaplardan (bu sizning tizimingiz uchun env va boshqa parametrlarni o'rnatishga imkon beruvchi ob'ekt) xizmat ko'rsatishni quyidagi shaklda saqlashga imkon beradi. diagrammalar deb ataladi. Shu bilan birga Helm Kubernetes tepasida ishlaydi. Ya'ni, bu bir chetda turgan tizim emas, balki kub ichida ishga tushirilgan yana bir xizmat. Siz u bilan API orqali konsol buyrug'i orqali o'zaro aloqada bo'lasiz. Uning qulayligi va go'zalligi shundaki, rul sindirilsa yoki uni klasterdan olib tashlasangiz ham, sizning xizmatlaringiz yo'qolmaydi, chunki rul mohiyatan faqat tizimni ishga tushirish uchun xizmat qiladi. Kubernetesning o'zi xizmatlarning ishlashi va holati uchun javobgardir.

Biz ham buni angladik shablonlashtirish, biz ilgari konfiguratsiyalarimizga jinjani kiritish orqali o'zimiz qilishga majbur bo'lgan edik, bu rulning asosiy xususiyatlaridan biridir. Tizimlaringiz uchun yaratgan barcha konfiguratsiyalar jinjaga biroz o'xshash shablonlar ko'rinishida rulda saqlanadi, lekin aslida Kubernetes kabi rul yozilgan Go tilining shablonlaridan foydalangan holda.

Helm biz uchun yana bir nechta tushunchalarni qo'shadi.

sxema - bu sizning xizmatingiz tavsifi. Boshqa paket menejerlarida u paket, to'plam yoki shunga o'xshash narsa deb ataladi. Bu erda u diagramma deb ataladi.

Qadriyatlar shablonlardan konfiguratsiyalaringizni yaratish uchun foydalanmoqchi bo'lgan o'zgaruvchilar.

ozod qilish. Har safar rul yordamida o'rnatiladigan xizmat nashrning qo'shimcha versiyasini oladi. Helm avvalgi versiyada xizmat konfiguratsiyasi nima ekanligini, undan oldingi versiyani va hokazolarni eslaydi. Shuning uchun, agar siz orqaga qaytishingiz kerak bo'lsa, shunchaki oldingi versiyaga ishora qilib, rulni qayta chaqirish buyrug'ini bajaring. Qayta tiklash vaqtida sizning omboringizdagi tegishli konfiguratsiya mavjud bo'lmasa ham, helm uning nima ekanligini eslab qoladi va tizimingizni oldingi versiyadagi holatiga qaytaradi.

Agar biz ruldan foydalansak, Kubernetes uchun odatiy konfiguratsiyalar ham o'zgaruvchilar, funktsiyalardan foydalanish va shartli bayonotlarni qo'llash mumkin bo'lgan shablonlarga aylanadi. Shu tarzda siz atrof-muhitga qarab xizmat konfiguratsiyasini to'plashingiz mumkin.

Amalda, biz Nomad bilan qilganimizdan ko'ra biroz boshqacha yo'l tutishga qaror qildik. Agar Nomad-da xizmatimizni joylashtirish uchun zarur bo'lgan ikkala joylashtirish konfiguratsiyasi va n-o'zgaruvchilari bitta omborda saqlangan bo'lsa, biz ularni ikkita alohida omborga bo'lishga qaror qildik. "O'rnatish" ombori faqat joylashtirish uchun zarur bo'lgan n-o'zgaruvchilarni saqlaydi va "rul" ombori konfiguratsiyalar yoki diagrammalarni saqlaydi.

Bu bizga nima berdi?

Biz konfiguratsiya fayllarida hech qanday nozik ma'lumotlarni saqlamasligimizga qaramay. Masalan, ma'lumotlar bazalariga parollar. Ular Kubernetesda sir sifatida saqlanadi, ammo shunga qaramay, u erda hali ham ba'zi narsalar mavjud, biz hammaga kirishga ruxsat berishni xohlamaymiz. Shuning uchun, "joylashtirish" omboriga kirish cheklanganroq va "rul" ombori shunchaki xizmat tavsifini o'z ichiga oladi. Shu sababli, unga kengroq odamlar tomonidan xavfsiz kirish mumkin.

Bizda nafaqat ishlab chiqarish, balki boshqa muhitlar ham borligi sababli, ushbu ajratish tufayli biz xizmatlarni nafaqat ishlab chiqarishga, balki, masalan, QA muhitiga ham joylashtirish uchun rul jadvallarimizdan qayta foydalanishimiz mumkin. Hatto ularni mahalliy sifatida ishlatish uchun Minikube - bu Kubernetes-ni mahalliy sifatida ishlatish uchun bir narsa.

Har bir ombor ichida biz har bir xizmat uchun alohida kataloglarga bo'linma qoldirdik. Ya'ni, har bir katalog ichida tegishli diagramma bilan bog'liq va tizimimizni ishga tushirish uchun ishlatilishi kerak bo'lgan resurslarni tavsiflovchi shablonlar mavjud. Biz "joylashtirish" omborida faqat envlarni qoldirdik. Bunday holda, biz jinja yordamida shablonni ishlatmadik, chunki helmning o'zi shablonni qutidan tashqarida ta'minlaydi - bu uning asosiy funktsiyalaridan biridir.

Biz tarqatish skriptini qoldirdik - deploy.sh, u rul yordamida ishga tushirishni soddalashtiradi va standartlashtiradi. Shunday qilib, joylashtirmoqchi bo'lgan har bir kishi uchun joylashtirish interfeysi Nomad orqali tarqatishda bo'lgani kabi ko'rinadi. Xuddi shu deploy.sh, xizmatingiz nomi va uni joylashtirmoqchi bo'lgan joy. Bu rulni ichki ishga tushirishga olib keladi. U, o'z navbatida, shablonlardan konfiguratsiyalarni to'playdi, ularga kerakli qiymatlar fayllarini kiritadi, keyin ularni Kubernetes-ga ishga tushiradi.

topilmalar

Kubernetes xizmati Nomadga qaraganda murakkabroq ko'rinadi.

Bu erda chiquvchi trafik Ingressga keladi. Bu barcha so'rovlarni qabul qiladigan va keyinchalik ularni so'rov ma'lumotlariga mos keladigan xizmatlarga yuboradigan oldingi boshqaruvchi. U ularni ruldagi ilovangiz tavsifining bir qismi bo'lgan va ishlab chiquvchilar o'zlari o'rnatgan konfiguratsiyalar asosida aniqlaydi. Xizmat so'rovlarni o'z podslariga, ya'ni ma'lum konteynerlarga yuboradi, bu xizmatga tegishli barcha konteynerlar o'rtasida kiruvchi trafikni muvozanatlashtiradi. Va, albatta, biz tarmoq darajasida xavfsizlikdan hech qaerga bormasligimiz kerakligini unutmasligimiz kerak. Shuning uchun segmentatsiya teglarga asoslangan Kubernetes klasterida ishlaydi. Barcha xizmatlarda xizmatlarning klaster ichidagi yoki tashqarisidagi ma'lum tashqi/ichki resurslarga kirish huquqlari bog'langan ma'lum teglar mavjud.

O'tishni amalga oshirar ekanmiz, Kubernetes biz ilgari ishlatgan Nomadning barcha imkoniyatlariga ega ekanligini va ko'plab yangi narsalarni qo'shganini ko'rdik. U plaginlar orqali va aslida maxsus resurs turlari orqali kengaytirilishi mumkin. Ya'ni, sizda nafaqat Kubernetes bilan birga keladigan narsadan foydalanish, balki sizning manbangizni o'qiy oladigan o'z resurs va xizmatingizni yaratish imkoniyati mavjud. Bu sizga Kubernetes-ni qayta o'rnatmasdan va o'zgartirishlarni talab qilmasdan tizimingizni kengaytirish uchun qo'shimcha imkoniyatlar beradi.

Bunday foydalanishga misol qilib Kubernetes klasterimiz ichida ishlaydigan Prometeyni keltirish mumkin. U ma'lum bir xizmatdan ko'rsatkichlarni yig'ishni boshlashi uchun xizmat tavsifiga xizmat monitori deb ataladigan qo'shimcha manba turini qo'shishimiz kerak. Prometey, Kubernetes-da ishga tushirilganda maxsus resurs turini o'qiy olishi sababli, avtomatik ravishda yangi tizimdan o'lchovlarni yig'ishni boshlaydi. Bu juda qulay.

Kubernetes-ga birinchi joylashtirishimiz 2018 yil mart oyida bo'lgan. Va bu vaqt ichida biz u bilan hech qanday muammoga duch kelmadik. U sezilarli xatolarsiz juda barqaror ishlaydi. Bundan tashqari, biz uni yanada kengaytirishimiz mumkin. Bugun bizda uning imkoniyatlari yetarli va bizga Kubernetesning rivojlanish sur'ati juda yoqadi. Hozirda Kubernetesda 3000 dan ortiq konteyner mavjud. Klaster bir nechta tugunlarni egallaydi. Shu bilan birga, u xizmat ko'rsatishga yaroqli, barqaror va juda boshqariladigan.

Manba: www.habr.com