Docker va Kubernetes bilan eng yaxshi arxitektura - afsona yoki haqiqatmi?

Doker va Kubernetes davrida dasturiy ta'minotni rivojlantirish dunyosi qanday o'zgargan? Ushbu texnologiyalardan foydalangan holda bir marta arxitekturani qurish mumkinmi? Hamma narsa idishlarga "qadoqlangan" bo'lsa, rivojlanish va integratsiya jarayonlarini birlashtirish mumkinmi? Bunday qarorlarga qanday talablar qo'yiladi? Ular qanday cheklovlarni keltirib chiqarmoqda? Ular ishlab chiquvchilarning hayotini osonlashtiradimi yoki buning o'rniga unga keraksiz asoratlarni qo'shadimi?

Ushbu va boshqa savollarga oydinlik kiritish vaqti keldi! (Matnda va asl rasmlarda.)

Ushbu maqola sizni haqiqiy hayotdan rivojlanish jarayonlariga, arxitekturaga va haqiqiy hayotga qaytishga safar qiladi, ushbu to'xtash joylarida har bir muhim savollarga javob beradi. Arxitekturaning bir qismi bo'lishi kerak bo'lgan bir qancha komponentlar va tamoyillarni aniqlashga harakat qilamiz va ularni amalga oshirish doirasiga kirmasdan bir nechta misollarni namoyish etamiz.

Maqolaning xulosasi sizni xafa qilishi yoki sizni xursand qilishi mumkin. Bularning barchasi sizning tajribangizga, ushbu uch bobli hikoyani idrok etishingizga va ehtimol o'qish paytida sizning kayfiyatingizga bog'liq. Quyidagi sharhlar yoki savollarni joylashtirish orqali fikringizni bildiring!

Haqiqiy hayotdan rivojlanish ish oqimlarigacha

Ko'pincha men ko'rgan yoki ko'rgan sharafli rivojlanish jarayonlari bitta oddiy maqsadga xizmat qildi - g'oyaning tug'ilishi va uni ishlab chiqarishga etkazib berish o'rtasidagi vaqtni qisqartirish, shu bilan birga ma'lum darajadagi kod sifatini saqlab qolish.

Fikr yaxshi yoki yomon bo'lishining ahamiyati yo'q. Yomon g'oyalar tezda keladi va siz ularni sinab ko'rasiz va parchalanish uchun pastga tushasiz. Bu erda aytib o'tadigan narsa shundaki, yomon g'oyadan voz kechish sizning ishingizni avtomatlashtiradigan robotning yelkasiga tushadi.

Doimiy integratsiya va etkazib berish dasturiy ta'minotni ishlab chiqarish dunyosida hayotni saqlab qoluvchiga o'xshaydi. Bundan oddiy nima bo'lishi mumkin? Sizda fikr bor, sizda kod bor, shuning uchun unga o'ting! Agar unchalik katta bo'lmagan muammoni hal qilsangiz, benuqson bo'lar edingiz - sizning kompaniyangizga xos bo'lgan texnologiya va biznes-jarayonlardan ajralgan holda integratsiya va etkazib berish jarayonini rasmiylashtirish ancha qiyin.

Biroq, vazifaning murakkabligi ko'rinishiga qaramay, hayot bizga har doim ham har qanday holatda foydali bo'lishi mumkin bo'lgan benuqson mexanizmni yaratishga ozgina yaqinroq olib keladigan ajoyib g'oyalarni to'playdi. Men uchun bunday mexanizmga qilingan eng so'nggi qadam Doker va Kubernetes bo'ldi, uning mavhumlik darajasi va mafkuraviy yondashuv meni 80% muammolar deyarli bir xil usullardan foydalangan holda hal qilish mumkin deb o'ylashga majbur qildi.

Qolgan 20% aniq hech qaerga ketmadi. Ammo takrorlanuvchi odatiy vazifalarni hal qilishdan ko'ra, o'zingizning ichki ijodiy dahoingizni qiziqarli ishlarga qaratishingiz mumkin. "Me'moriy ramka" ga bir marta g'amxo'rlik qilish sizga hal qilingan muammolarning 80% ni unutishga imkon beradi.

Bularning barchasi nimani anglatadi va Docker ish jarayonidagi muammolarni qanday aniq hal qiladi? Keling, ko'pgina ish muhitida etarli bo'lgan oddiy jarayonni ko'rib chiqaylik:

Tegishli yondashuv bilan siz quyida keltirilgan ketma-ketlikdan hamma narsani avtomatlashtirishingiz va birlashtirishingiz mumkin va kelgusi oylar davomida bu haqda unutishingiz mumkin.

Rivojlanish muhitini yaratish

Loyiha docker-compose.yml faylini o'z ichiga olishi kerak, bu sizga mahalliy kompyuterda dastur / xizmatni ishga tushirish uchun nima va qanday qilish kerakligi haqida o'ylashda qiynaladi. Oddiy docker-up up buyrug'i sizning barcha qaramliklaringiz bilan dasturingizni ishga tushirishi, ma'lumotlar bazasini armatura bilan to'ldirishi, konteyner ichiga mahalliy kodni yuklashi, tezkor ravishda kompilyatsiya qilish uchun kod qidiruvini yoqishi va natijada kutilgan portda javob berishni boshlashi kerak. Yangi xizmatni o'rnatayotganda ham, qanday boshlash kerakligi, o'zgarishlarni qaerdan boshlash kerakligi yoki qanday asoslardan foydalanish haqida tashvishlanmaslik kerak. Bularning barchasi oldindan standart ko'rsatmalarda oldindan tavsiflangan bo'lishi kerak va har xil sozlashlar uchun xizmat andozalari bilan belgilanadi: old tomon, orqa va ishchi.

Avtomatik sinov

"Qora quti" haqida bilishni xohlaganingiz (nima uchun men uni konteyner deb ataganim haqida keyinroq matnda aytaman), unda hamma narsa yaxshi. Ha yoki yo'q. 1 yoki 0. Idishning ichida bajarilishi mumkin bo'lgan sonli buyruqlarga va uning barcha bog'liqliklarini tavsiflovchi docker-compose.yml-ga ega bo'lgan holda, siz testlarni amalga oshirish tafsilotlariga ko'p e'tibor qaratmasdan osongina avtomatlashtirishingiz va birlashtirishingiz mumkin.

Masalan, shunga o'xshash!

Bu erda test deganda nafaqat birlikni sinash, balki funktsional sinov, integratsiya testi, kodni takrorlash, nusxa ko'chirish, eskirgan bog'liqlikni tekshirish, ishlatilgan paketlar uchun litsenziyalarni buzish va boshqa ko'plab narsalar tushuniladi. Gap shundaki, bularning barchasi sizning Docker obrazingiz ichiga o'ralgan bo'lishi kerak.

Tizimlarni etkazib berish

Loyihangizni qachon va qaerda o'rnatishni xohlamasligingiz muhim emas. Natija, o'rnatish jarayoni kabi, har doim bir xil bo'lishi kerak. Butun ekotizimning qaysi qismini o'rnatmoqchi ekanligingiz yoki uni qaysi git repo bilan olish haqida hech qanday farq yo'q. Bu erda eng muhim tarkibiy qism - bu beparvolik. Siz ko'rsatishingiz kerak bo'lgan yagona narsa - bu o'rnatishni boshqaradigan parametrlarga bog'liq.

Menga ushbu muammoni hal qilishda juda samarali bo'lgan algoritm:

  1. Barcha Dockerfayllaringizdan rasmlarni to'plang (masalan, shu kabi)
  2. Meta-loyihadan foydalanib, ushbu rasmlarni Kube API orqali Kubernetesga etkazing. Etkazib berishni boshlash odatda bir necha kirish parametrlarini talab qiladi:
  • Kube API tugash nuqtasi
  • turli xil kontekstlarda farq qiluvchi "yashirin" ob'ekt (mahalliy / ko'rgazma zali / sahna ko'rinishi / ishlab chiqarish)
  • ko'rsatiladigan tizimlarning nomlari va ushbu tizimlar uchun Docker tasvirlarining teglari (oldingi bosqichda olingan)
Barcha tizimlar va xizmatlarni o'z ichiga oladigan meta-loyihaning misoli sifatida (boshqacha qilib aytganda, ekotizim qanday tashkil qilinganligini va unga qanday yangilanishlar berilishini tasvirlaydigan loyiha) Kube bilan integratsiya qilish uchun ushbu modul bilan Ansible playbooks-dan foydalanishni afzal ko'raman. API. Biroq, murakkab avtomatlashtirilgan mashinalar boshqa variantlarga murojaat qilishlari mumkin va men keyinroq o'z tanlovlarimga to'xtalib o'taman. Biroq, siz arxitekturani boshqarishning markazlashtirilgan / birlashtirilgan usuli haqida o'ylashingiz kerak. Bularning barchasi sizga barcha xizmatlarni / tizimlarni qulay va bir xilda boshqarishga imkon beradi va shunga o'xshash funktsiyalarni bajaradigan texnologiyalar va tizimlarning yaqinlashib kelayotgan chakalakzorlari sizga etkazishi mumkin bo'lgan asoratlarni bartaraf qiladi.

Odatda, atrof-muhitni o'rnatish quyidagilarda talab qilinadi:

  • "ShowRoom" - tizimni qo'lda tekshirish yoki disk raskadrovka uchun
  • "Sahna" - yaqin atrof-muhit va tashqi tizimlar bilan integratsiya uchun (odatda ShowRoom-dan farqli ravishda DMZ-da joylashgan)
  • "Ishlab chiqarish" - bu oxirgi foydalanuvchi uchun haqiqiy muhit

Integratsiya va etkazib berishda doimiylik

Agar siz Docker rasmlarini yoki "qora qutilarni" sinab ko'rishning yagona usuliga ega bo'lsangiz, taxmin qilishingiz mumkinki, bunday sinovlar natijalari sizga (va vijdonan) funktsiyalar tarmog'ini oqimning yuqori qismida yoki magistral tarmoqlarida birlashtirishga imkon beradi. omborxona.

Ehtimol, bu erda yagona sotuvchi bu integratsiya va etkazib berish ketma-ketligidir. Agar relizlar bo'lmasa, qanday qilib parallel tizimlar tarmog'iga ega bo'lgan bitta tizimdagi "poyga holati" ni oldini olasiz?

Shuning uchun, bu jarayon faqat raqobat bo'lmaganda boshlanishi kerak, aks holda "poyga holati" sizning fikringizni hayratda qoldiradi:

  1. Yuqori oqim uchun xususiyatlar tarmog'ini yangilashga harakat qiling (git rebase / birlashtirish)
  2. Dockerfiles-dan rasmlar yarating
  3. O'rnatilgan barcha rasmlarni sinab ko'ring
  4. Boshlang va 2-bosqich rasmlari bo'lgan tizimlar etkazib berilishini kuting
  5. Agar oldingi qadam muvaffaqiyatsiz bo'lsa, ekotizimni oldingi holatga qaytaring
  6. Inputstream-ichiga kiruvchi xususiyatlar tarmog'ini birlashtiring va ularni omborga yuboring

Har qanday bosqichdagi har qanday nosozlik etkazib berish jarayonini to'xtatishi va xatoni tuzatish uchun ishlab chiqaruvchiga topshirishi kerak, bu muvaffaqiyatsiz sinovmi yoki birlashma ziddiyati.

Siz ushbu jarayonni bir nechta omborxonalar bilan ishlashda ishlatishingiz mumkin. Har bir ombor uchun butun jarayonni bir necha marta takrorlash o'rniga, bir vaqtning o'zida barcha omborlar uchun har bir qadamni bajaring (A va B omborlari uchun 2-qadam, A va B omborlari uchun 2-qadam va boshqalar) (A-repo uchun 1-6-qadamlar). , repo B uchun 1-6 bosqichlar va boshqalar).

Bundan tashqari, Kubernetes sizga turli xil AB testlari va xavflarni tahlil qilish uchun qismlarni yangilashni amalga oshirishga imkon beradi. Kubernetes buni xizmatlarni (kirish joylari) va ilovalarni ajratish orqali amalga oshiradi. Siz har doim muammoning tahlilini osonlashtirish va potentsial orqaga qaytarish uchun tarkibiy qismning yangi va eski versiyalarini kerakli nisbatda muvozanatlashingiz mumkin.

Orqaga qaytarish tizimlari

Arxitektura doirasiga qo'yiladigan majburiy talablardan biri bu har qanday joylashtirishni bekor qilish qobiliyatidir. Bu, o'z navbatida, bir qator aniq va yashirin nuanslarni keltirib chiqaradi. Mana, ulardan eng muhimlari:

  • Xizmat o'z atrof-muhitini, shuningdek, orqaga qaytarishni o'zgartirishi kerak. Masalan, ma'lumotlar bazasini ko'chirish, RabbitMQ sxemasi va boshqalar.
  • Agar atrof-muhitni orqaga qaytarish imkoni bo'lmasa, xizmat polimorfik bo'lishi kerak va kodning eski va yangi versiyalarini qo'llab-quvvatlashi kerak. Masalan: ma'lumotlar bazasi ko'chirilishi xizmatning eski versiyalariga xalaqit bermasligi kerak (odatda, avvalgi 2 yoki 3 versiyalari).
  • Har qanday xizmat yangilanishining orqaga qarab mosligi. Odatda, bu API mosligi, xabar formatlari va boshqalar.
Kubernetes klasterida holatni qaytarish juda oddiy (Kubectlout ishga tushirishni qaytarish / ba'zi joylashtirishlar va Kubernetes oldingi "surat" -ni tiklaydi), ammo bu ishlashi uchun sizning meta-loyihangiz ushbu surat haqida ma'lumotga ega bo'lishi kerak. Qaytishning algoritmlarini yanada murakkab etkazib berish, ba'zida zarur bo'lsa ham, juda tushkunlikka uchraydi.

Orqaga qaytarish mexanizmini qo'zg'atadigan narsa:

  • Bo'shatishdan keyin dastur xatolarining yuqori foizi
  • Monitoringning asosiy nuqtalaridan signallar
  • Muvaffaqiyatsiz tutun sinovlari
  • Qo'l rejimi - inson omili

Axborot xavfsizligi va auditni ta'minlash

O'qdan himoyalanishni sehrli ravishda "quradigan" va ekotizimni tashqi va ichki tahdidlardan himoya qiladigan yagona ish oqimi yo'q, shuning uchun sizning me'moriy asosingiz har birida kompaniyaning standartlari va xavfsizlik siyosatini hisobga olgan holda bajarilganligiga ishonch hosil qilishingiz kerak. darajasida va barcha quyi tizimlarda.

Men keyinroq tizimning yaxlitligi uchun muhim bo'lgan kuzatuv va ogohlantirish bo'limida taklif qilingan echimning har uch bosqichini ko'rib chiqaman.

Kubernetes-da kirishni boshqarish, tarmoq siyosati, voqealar auditi va axborot xavfsizligi bilan bog'liq boshqa kuchli vositalar to'plami mavjud bo'lib, ular hujumlar va ma'lumotlarning tarqalishiga qarshi tura oladigan va himoya qiladigan mukammal himoya perimetrini yaratishda ishlatilishi mumkin. .

Rivojlanish jarayonidan arxitekturaga qadar

Rivojlanish jarayonlari va ekotizim o'rtasida qattiq integratsiyani o'rnatish urinishlariga jiddiy qarash kerak. Arxitekturaga an'anaviy talablar to'plamiga (moslashuvchanlik, o'lchovlilik, mavjudlik, ishonchlilik, tahdidlardan himoya qilish va hokazo) bunday integratsiyalashuvga bo'lgan talabni qo'shib, sizning me'moriy doirangizning ahamiyatini sezilarli darajada oshirish mumkin. Bu shu qadar muhim jihatki, u "DevOps" (Development Operation) kontseptsiyasining paydo bo'lishiga olib keldi, bu umumiy avtomatlashtirish va infratuzilmani optimallashtirish uchun mantiqiy qadamdir. Biroq, yaxshi mo'ljallangan arxitektura va ishonchli quyi tizimlarga ega bo'lgan holda, DevOps vazifalarini minimallashtirish mumkin.

Mikro servis arxitekturasi

Xizmatga yo'naltirilgan arxitektura - SOA ning afzalliklari haqida batafsil ma'lumot olishning hojati yo'q, shu sababli xizmatlar nima uchun "mikro" bo'lishi kerak. Men faqat shuni aytamanki, agar siz Docker va Kubernetes-dan foydalanishga qaror qilgan bo'lsangiz, monolit arxitekturaga ega bo'lish qiyin va hatto mafkuraviy jihatdan ham noto'g'ri ekanligini tushunasiz (va qabul qilasiz). Yagona jarayonni boshqarish va qat'iyat bilan ishlash uchun yaratilgan Docker bizni DDD (Domain-Drive-Development) doirasida ishlashga majbur qiladi. Docker-da, qadoqlangan kod ba'zi ochiq portlarga ega qora quti sifatida muomala qilinadi.

Ekotizimning muhim tarkibiy qismlari va echimlari

Mavjudligi va ishonchliligi oshgan tizimlarni loyihalashtirish tajribamdan kelib chiqqan holda, mikro xizmatlarning ishlashi uchun muhim bo'lgan bir nechta tarkibiy qismlar mavjud. Keyinchalik men ushbu tarkibiy qismlarning har birini ro'yxatlashtiraman va gaplashaman, garchi Kubernetes muhiti kontekstida ularga murojaat qilsam ham, siz mening ro'yxatimga boshqa har qanday platforma uchun nazorat ro'yxati sifatida murojaat qilishingiz mumkin.

Agar siz (men kabi) ushbu tarkibiy qismlarning har birini muntazam Kubernetes xizmati sifatida boshqarish juda yaxshi degan xulosaga kelsangiz, ularni "ishlab chiqarish" dan tashqari alohida klasterlarda boshqarishingizni tavsiya qilaman. Masalan, "ishlab chiqarish" klasteri, chunki u ishlab chiqarish muhiti beqaror bo'lganida sizning hayotingizni saqlab qolishi mumkin va siz uning tasviri, kodi yoki nazorat qilish manbasiga juda muhtojsiz. Shunday qilib, tovuq va tuxum muammosini hal qiladi.

Identifikatsiya xizmati

Odatdagidek, barchasi kirishdan boshlanadi - serverlarga, virtual mashinalarga, ilovalarga, ofis pochtasiga va boshqalarga. Agar siz yirik korxona platformalaridan biri (IBM, Google, Microsoft) mijozi bo'lsangiz yoki kirishni xohlasangiz, kirish muammosi sotuvchi xizmatlaridan biri tomonidan hal qilinadi. Ammo, agar siz o'zingizning echimingizni topishni xohlasangiz, uni faqat o'zingiz va sizning byudjetingiz doirasida boshqarasizmi?

Ushbu ro'yxat sizga tegishli echimni tanlashga yordam beradi va uni sozlash va saqlash uchun zarur bo'lgan kuchni baholaydi. Albatta, sizning tanlovingiz kompaniyaning xavfsizlik siyosatiga muvofiq bo'lishi va axborot xavfsizligi bo'limi tomonidan tasdiqlanishi kerak.

Avtomatlashtirilgan xizmat ko'rsatish

Kubernetes jismoniy mashinalarda / bulutli VM-larda (docker, kubelet, kube proksi, etcd klaster) faqat bir nechta qismlarga ega bo'lishni talab qilsa-da, siz hali ham yangi mashinalarni qo'shishni va klasterlarni boshqarishni avtomatlashtirishingiz kerak. Buning bir necha oddiy usullari:

  • KOPS - ushbu vosita ikkita bulutli provayderlardan biriga - AWS yoki GCEga klasterni o'rnatishga imkon beradi
  • Teraform - bu sizga har qanday atrof-muhit uchun infratuzilmani boshqarishga imkon beradi va IAC (Infrastructure code code) mafkurasiga amal qiladi
  • Ansible - har qanday avtomatlashtirish uchun ko'p qirrali vosita
Shaxsan men uchinchi variantni afzal ko'raman (bir oz Kubernetes integratsiya moduli bilan), chunki bu ikkala server va k8s ob'ektlari bilan ishlashga va har qanday avtomatlashtirishni amalga oshirishga imkon beradi. Biroq, Teraform va uning Kubernetes modulidan foydalanishingizga hech narsa xalaqit bermaydi. KOPS "yalang'och metall" bilan yaxshi ishlamaydi, ammo u hali ham AWS / GCE-da foydalanish uchun juda yaxshi vosita!

Git ombori va vazifalarni kuzatuvchi

Ishlab chiquvchilar va boshqa tegishli rollarning to'liq huquqli ishlashini ta'minlash uchun, jamoada ishlash va kodni saqlash bo'yicha muhokamalar uchun joy bo'lishi kerak. Buning uchun qaysi xizmat eng yaxshisi ekanligini aniqlash uchun zo'rg'a zo'rg'a bosardim, ammo mening vazifamni kuzatish uchun shaxsiy oltin standartim - bu bepul (bepul) yoki Jira (pullik), va kodlar ombori uchun - "eski maktab" [gerrit] ( https://www.gerritcodereview.com/) (bepul) yoki bitbucket (pullik).

Korxona sharoitida birgalikda ishlash uchun ikkita eng izchil (tijorat bo'lsa ham) ustunlikka e'tibor qaratish lozim: Atlassian va Jetbrains. Siz ulardan ikkitasini mustaqil echimdan foydalanishingiz yoki har ikkalasining turli qismlarini birlashtira olasiz.

Tracker va omborxonadan maksimal darajada foydalanish uchun ularning integratsiya strategiyasi haqida o'ylang. Masalan, kod va tegishli vazifalarning yaxlitligini ta'minlash bo'yicha bir nechta maslahatlar (albatta siz o'zingizning yondashuvingizni tanlashingiz mumkin):

  • Masofaviy omborga "itarish" qobiliyati faqat uni bosishga harakat qilayotgan filial tegishli vazifa raqamiga ega bo'lgandagina yoqilishi kerak (TASK-1 / xususiyat-34)
  • Har qanday filial faqat ma'lum miqdordagi ijobiy kodlarni tekshirgandan so'ng birlashtirilishi mumkin
  • Agar tegishli vazifa "Jarayon" yoki shunga o'xshash holat bo'lmasa, kelajakdagi yangilanishlar uchun har qanday filial bloklanishi va o'chirilishi kerak
  • Avtomatlashtirish uchun mo'ljallangan har qanday qadamlar to'g'ridan-to'g'ri ishlab chiquvchilarga berilmasligi kerak
  • Faqat vakolatli ishlab chiquvchilar to'g'ridan-to'g'ri magistral tarmog'ini o'zgartirishlari kerak - avtomatlashtirish roboti tomonidan boshqariladigan barcha narsalar
  • Agar tegishli vazifa "Yetkazib berish" yoki shunga o'xshash holatdan boshqa holatlarda bo'lsa, filialni birlashtirish uchun mavjud bo'lmasligi kerak

Docker reyestri

Docker rasmlarni boshqarish tizimiga alohida e'tibor berilishi kerak, chunki bu xizmatlarni saqlash va etkazib berish uchun juda muhimdir. Bundan tashqari, ushbu tizim foydalanuvchilar va foydalanuvchilar guruhlariga kirishni qo'llab-quvvatlashi, eski va keraksiz rasmlarni o'chirib tashlashi, GUI va RESTful API bilan ta'minlashi kerak.

Siz bulutli echimdan foydalanishingiz mumkin (masalan, hub.docker.com) yoki hattoki o'zingizning Kubernetes klasteringizda o'rnatilishi mumkin bo'lgan xususiy xizmatdan. Docker Registry uchun korporativ echim sifatida belgilangan Vmware Harbor, ikkinchisining yaxshi namunasidir. Eng yomoni, siz hatto rasmlarni saqlashni xohlasangiz va murakkab tizimga ehtiyojingiz bo'lmasa, eski eski Docker Registry-dan ham foydalanishingiz mumkin.

CI / CD va xizmatlarni etkazib berish tizimi

Biz ilgari muhokama qilgan tarkibiy qismlarning hech biri (git repo, vazifalarni nazorat qilish moslamasi, Ansible Playbooks bilan meta loyihasi, tashqi bog'liqliklar) vakuumda to'xtatilgandek bir-biridan ajralib turolmaydi. Ularni bog'laydigan narsa bu doimiy integratsiya va etkazib berish xizmati.

CI - uzluksiz integratsiya CD - uzluksiz etkazib berish

Xizmat juda sodda va tizimlarni etkazib berish yoki sozlash bilan bog'liq har qanday mantiqdan mahrum bo'lishi kerak. CI / CD xizmati bajarishi kerak bo'lgan narsa tashqi olamdagi voqealarga (rezervordagi o'zgarishlar, vazifalarni kuzatuvchisi atrofida harakatlanish) reaktsiya berish va meta loyihasida tasvirlangan harakatlarni amalga oshirishdir. Bundan tashqari, servicecice barcha omborxonalarni nazorat qilish nuqtasi va ularni boshqarish vositasi (filiallarni birlashtirish, yuqoriga / masterdan yangilanishlar).

Men tarixan Jetbrains-dan juda kuchli, ammo juda oddiy vositani - TeamCity-dan foydalanganman, lekin agar biron bir narsani sinab ko'rishga qaror qilsangiz, masalan, bepul Jenkinsni ko'rmaysiz.

Biz yuqorida bayon qilgan sxema bo'yicha integratsiya xizmati asosan to'rtta asosiy va yordamchi jarayonlarni ishga tushirish uchun javobgardir:

  • Avtomatik xizmatni sinovdan o'tkazish - odatda, bitta holat ombori uchun, filial holati o'zgarganda yoki maqomi "Kutish avtotestlari" (yoki shunga o'xshash) ga o'zgartirilganda.
  • Xizmatlarni etkazib berish - odatda, meta-loyihadan va bir qator xizmatlardan (tegishli ravishda bir qator omborxonalar), QA va ishlab chiqarish muhitini joylashtirish uchun maqom "Kutish zalini" yoki "Etkazib berishni kutish" ga o'zgarganda.
  • Orqaga qaytarish - qoida tariqasida, meta loyihasidan va bitta xizmatning yoki butun xizmatning ma'lum bir qismi uchun, tashqi voqea yoki etkazib berish muvaffaqiyatsiz bo'lgan taqdirda.
  • Xizmatni o'chirish - bu In QA holati muddati tugagan yoki atrof-muhit endi kerak bo'lmagan holatlarda butun ekotizimni bitta sinov muhitidan (ko'rgazma zalidan) butunlay olib tashlash uchun talab qilinadi.
  • Tasvir quruvchisi (yordamchi jarayon) - xizmatlarni etkazib berish jarayonida birlashtirilishi yoki Docker rasmlarini kompilyatsiya qilish va Docker Registriga yuborish uchun mustaqil ravishda ishlatilishi mumkin. Ko'pincha keng ishlatiladigan tasvirlar bilan ishlov beradi (MB, umumiy xizmatlar yoki tez-tez o'zgartirishni talab qilmaydigan xizmatlar).

Jurnal to'plash va tahlil qilish tizimi

Har qanday Docker konteynerining jurnallarini ochiq qilishning yagona usuli bu ularni konteynerda ishlaydigan ildiz jarayonining STDOUT yoki STDERR-ga yozishdir. Servisni ishlab chiquvchisi jurnallar ma'lumotlari bilan nima bo'lishini umuman o'ylamaydi, asosiysi, ular kerak bo'lganda mavjud bo'lishi va o'tmishda biron bir joyga yozuvlar kiritishi kerak. Ushbu taxminlarni amalga oshirish uchun barcha javobgarlik Kubernetes va ekotizimni qo'llab-quvvatlaydigan muhandislar zimmasiga tushadi.

Rasmiy hujjatlarda siz jurnallar bilan ishlashning asosiy (va yaxshi variantini) tavsifini topishingiz mumkin, bu sizga katta matnli ma'lumotlarni to'plash va saqlash xizmatini tanlashingizga yordam beradi.

Jurnal tizimiga kirish uchun tavsiya etiladigan xizmatlar orasida, xuddi shu hujjat ma'lumotlarni yig'ish uchun oqilona ma'lumotni (klasterning har bir tuguniga agent sifatida ishga tushirilganda) va ma'lumotlarni saqlash va indekslash uchun Elasticsearch-ga tegishli. Ikkala tomonning samaradorligi Siz ushbu echimning samaradorligiga rozi bo'lmasligingiz mumkin, ammo ulardan foydalanish ishonchli va oson, shuning uchun hech bo'lmaganda yaxshi boshlanish deb o'ylayman.

Elasticsearch - bu resurslarni talab qiladigan echim, ammo u juda katta hajmga ega va individual tugunni va kerakli hajmdagi klasterni boshqarish uchun tayyor Docker rasmlariga ega.

Kuzatish tizimi

Kodingiz qanchalik mukammal bo'lsa, muvaffaqiyatsizliklar yuz beradi va keyin siz ularni ishlab chiqarishda ingichka tishli taroq bilan o'rganishni xohlaysiz va "agar mahalliy mashinamda hamma narsa yaxshi ishlangan bo'lsa, nima yomon bo'ldi?" Ma'lumotlar bazasining sekin so'rovlari, noto'g'ri keshlash, sekin manbalar yoki tashqi manbaga ulanish, ekotizimdagi operatsiyalar, kam ta'minlanganlik va hisob-kitob xizmatlari - bu sizning kodingizni bajarishga sarflangan vaqtni kuzatib, hisoblashingizga majbur qilishning sabablari. haqiqiy yuk.

Opentracing va Zipkin ushbu dasturni eng zamonaviy dasturlash tillari uchun bajaradilar va kodni qo'llaganidan keyin ortiqcha yuklamasdan. Albatta, barcha to'plangan ma'lumotlar tarkibiy qismlardan biri sifatida ishlatiladigan tegishli joyda saqlanishi kerak.

Kodni ishlatishda va "Trace Id" ni barcha xizmatlar, xabarlar navbatlari, ma'lumotlar bazalari va boshqalar orqali yo'naltirishda yuzaga keladigan murakkabliklar yuqorida aytib o'tilgan ishlab chiqish standartlari va shablonlari bilan hal qilinadi. Ikkinchisi, shuningdek, yondashuvning bir xilligiga e'tibor beradi.

Monitoring va ogohlantirish

Prometey zamonaviy tizimlarda amalda standartga aylandi va bundan ham muhimi, Kubernetesda deyarli mavjud emas. Monitoring va ogohlantirish haqida ko'proq ma'lumot olish uchun rasmiy Kubernetes hujjatlariga murojaat qilishingiz mumkin.

Monitoring klaster ichida o'rnatilishi kerak bo'lgan bir nechta yordamchi tizimlardan biridir. Va klaster - bu nazorat qilinadigan ob'ekt. Ammo monitoring tizimining monitoringi (tautologiyani afv etish) faqat tashqi tomondan amalga oshirilishi mumkin (masalan, xuddi shu "bosqich" muhitidan). Bunday holda, o'zaro taqqoslash har qanday taqsimlangan muhit uchun qulay echim sifatida yordam beradi, bu sizning yuqori darajada birlashtirilgan ekotizimingiz arxitekturasini murakkablashtirmaydi.

Monitoringning butun diapazoni to'liq mantiqiy ajratilgan uchta darajaga bo'linadi. Menimcha, har bir darajadagi nazorat nuqtalarining eng muhim namunalari:

  • Fizik darajasi: - Tarmoq manbalari va ularning mavjudligi - Disklar (i / o, bo'sh joy) - Shaxsiy tugunlarning asosiy manbalari (CPU, RAM, LA)
  • Klaster darajasi: - Har bir tugunda asosiy klaster tizimlarining mavjudligi (kubelet, kubeAPI, DNS, va hokazo) - bo'sh resurslar soni va ularning bir tekis taqsimlanishi - xizmatlar tomonidan ruxsat etilgan va haqiqiy resurslarni sarflanishini monitoring qilish - Qayta yuklash podalar
  • Xizmat darajasi: - Istalgan dastur monitoringi - ma'lumotlar bazasi tarkibidan API qo'ng'iroqlari chastotasigacha - API shlyuzidagi HTTP xatolar soni - Navbatlar hajmi va ishchilar tomonidan ishlatilishi - Ma'lumotlar bazasi uchun bir nechta ko'rsatkichlar (replikatsiya vaqti, vaqti) va tranzaktsiyalar soni, sekin so'rovlar va boshqalar) - HTTP bo'lmagan jarayonlar uchun xatolar tahlili - Jurnal tizimiga yuborilgan so'rovlarning monitoringi (istalgan so'rovlarni metrikaga o'zgartirishingiz mumkin).

Har bir darajadagi ogohlantirish xabarlariga kelsak, elektron pochta, SMS yoki mobil raqamga qo'ng'iroqlarni amalga oshiradigan son-sanoqsiz tashqi xizmatlardan foydalanishni tavsiya qilaman. Prometeyning ogohlantirish boshqaruvchisi bilan yaqin integratsiyalashgan boshqa tizim - OpsGenie-ni ham eslatib o'taman.

OpsGenie - ogohlantirishning moslashuvchan vositasi bo'lib, u eskalatsiyalar, kechayu-kunduz navbatchilik, ogohlantirish kanallarini tanlash va boshqa muammolarni hal qilishga yordam beradi. Ogohlantirishlarni jamoalar o'rtasida tarqatish ham oson. Masalan, monitoringning turli darajalari turli guruhlar / bo'limlarga bildirishnomalarni yuborishi kerak: jismoniy - Infra + Devops, klaster - Devops, ilovalar - har biri tegishli jamoaga.

API shlyuzi va yagona kirish

Avtorizatsiya, autentifikatsiya, foydalanuvchilarni ro'yxatdan o'tkazish (tashqi foydalanuvchilar-kompaniyaning mijozlari) va kirishni boshqarishning boshqa turlari kabi vazifalarni hal qilish uchun sizga API shlyuzingiz bilan moslashuvchan integratsiyani ushlab tura oladigan yuqori darajadagi ishonchli xizmat kerak bo'ladi. «Identifikatsiya xizmati» ga o'xshash echimdan foydalanganda hech qanday zarar bo'lmaydi, ammo siz turli xil mavjudlik va ishonchlilik darajasiga erishish uchun ikkita manbani ajratib qo'yishingiz mumkin.

Xizmatlararo integratsiya murakkab bo'lmasligi kerak va sizning xizmatlaringiz foydalanuvchilarni va bir-birlarini avtorizatsiya qilish va autentifikatsiya qilish haqida tashvishlanmasligi kerak. Buning o'rniga arxitektura va ekotizim barcha aloqalarni va HTTP-trafikni boshqaradigan proksi xizmatiga ega bo'lishi kerak.

API shlyuzi, shu bilan butun ekotizimingiz - tokenlar bilan integratsiyaning eng maqbul usulini ko'rib chiqaylik. Ushbu usul barcha uchta kirish stsenariylari uchun mos keladi: UI, xizmatdan xizmatga va tashqi tizim uchun. Keyin tokenni olish vazifasi (login va parol asosida) UI o'zi yoki xizmatni ishlab chiqaruvchiga yuklanadi. UIda foydalanilgan tokenlarning umrini (qisqaroq TTL) va boshqa holatlarda (uzoqroq va odatiy TTL) farqlash mantiqiy.

Bu erda API shluzi hal qiladigan ba'zi muammolar mavjud:

  • Ekotizim xizmatlariga tashqi va ichki tomondan kirish (xizmatlar bir-biri bilan bevosita aloqa qilmaydi)
  • Yagona kirish xizmati bilan integratsiya: - Tenderlarni o'zgartirish va so'ralgan xizmat uchun foydalanuvchi identifikatsiya ma'lumotlarini (ID, rollar, boshqa ma'lumotlar) o'z ichiga olgan sarlavhalar bilan HTTPS so'rovlarini qo'shish - Rollarga ko'ra so'ralgan xizmatga kirishni boshqarishni yoqish / o'chirish. Yagona kirish xizmatidan olingan
  • HTTP trafikni kuzatishning yagona nuqtasi
  • Turli xizmatlarning API hujjatlarini birlashtirish (masalan, Swaggerning json / yml fayllarini birlashtirish)
  • Domenlar va so'ralgan URIlar asosida butun ekotizim uchun marshrutlashni boshqarish imkoniyati
  • Tashqi trafik uchun bitta kirish nuqtasi va kirish provayderi bilan integratsiya

Tadbir avtobusi va korxonalarni integratsiya qilish / xizmat ko'rsatish avtobusi

Agar sizning ekotizimingizda bitta so'l domenda ishlaydigan yuzlab xizmatlar mavjud bo'lsa, siz xizmatlar bilan aloqa qilishning minglab mumkin bo'lgan usullarini hal qilishingiz kerak bo'ladi. Ma'lumotlar oqimini soddalashtirish uchun, voqealarning kontekstidan qat'i nazar, ma'lum bir voqea sodir bo'lganida, xabarlarni ko'plab qabul qiluvchilarga tarqatish imkoniyati haqida o'ylashingiz kerak. Boshqacha qilib aytganda, standart protokol asosida tadbirlarni nashr qilish va ularga obuna bo'lish uchun sizga voqea avtobusi kerak bo'ladi.

Voqealar avtobusi sifatida siz broker deb nomlangan har qanday tizimdan foydalanishingiz mumkin: RabbitMQ, Kafka, ActiveMQ va boshqalar. Umuman olganda, ma'lumotlarning yuqori darajada mavjudligi va uyg'unligi mikro xizmatlar uchun juda muhimdir, ammo CAP teoremasi tufayli avtobusni to'g'ri taqsimlash va klasterlash uchun biron bir narsani sarflashingiz kerak bo'ladi.

Tabiiyki, voqea avtobusi turli xil xizmatlarni taqdim etadigan muammolarni hal qila olishi kerak, ammo xizmatlarning soni yuz mingdan o'n minglargacha o'sib borishi bilan, hatto eng yaxshi tadbir avtobusiga asoslangan arxitektura ham muvaffaqiyatsiz bo'ladi va siz boshqa yechim izlash kerak. Yuqorida tavsiflangan "soqov trubkasi - aqlli iste'molchi" taktikasining imkoniyatlarini kengaytiradigan integratsiyalashgan avtobusga yondoshish bunga yaxshi misol bo'lishi mumkin.

Xizmatga yo'naltirilgan arxitekturaning murakkabligini kamaytirishga qaratilgan "Enterprise Integration / Service Bus" yondashuvidan foydalanishning o'nlab sabablari mavjud. Mana shu sabablarning ba'zilari:

  • Bir nechta xabarlarni birlashtirish
  • Bitta hodisani bir nechta tadbirlarga bo'lish
  • Tizimning hodisaga javobini sinxron / tranzaktsion tahlil qilish
  • Tashqi tizimlar bilan integratsiya uchun ayniqsa muhim bo'lgan interfeyslarni muvofiqlashtirish
  • Voqealarni yo'naltirishning rivojlangan mantig'i
  • Bir xil xizmatlarga bir nechta integratsiya (tashqi va ichkaridan)
  • Ma'lumotlar avtobusini kengaytirmaydigan markazlashtirish
Korxonalarni integratsiyalashgan avtobus uchun ochiq manbali dastur sifatida siz ushbu turdagi SOAni loyihalash va rivojlantirish uchun zarur bo'lgan bir nechta tarkibiy qismlarni o'z ichiga olgan Apache ServiceMix-ni ko'rib chiqishingiz mumkin.

Ma'lumotlar bazalari va boshqa davlat xizmatlari

Kubernetes singari, Docker ham o'yin qoidalarini bir marotaba o'zgartirdi va ma'lumotlar qat'iyatliligini va disk bilan yaqin ishlashni talab qiladigan xizmatlar uchun. Ba'zilarning ta'kidlashicha, xizmatlar jismoniy serverlarda yoki virtual mashinalarda eski tarzda "yashashi" kerak. Men ushbu fikrni hurmat qilaman va men uning ijobiy va salbiy tomonlari haqida bahslashmayman, ammo bu kabi bayonotlar faqat Docker muhitida davlat xizmatlarini boshqarish bo'yicha vaqtincha bilim, echimlar va tajriba yo'qligi sababli mavjudligiga ishonchim komil.

Shuni ham ta'kidlash kerakki, ma'lumotlar bazasi ko'pincha saqlash dunyosida markaziy o'rinni egallaydi va shuning uchun siz tanlagan echim Kubernetes muhitida ishlashga to'liq tayyor bo'lishi kerak.

Mening tajribam va bozordagi vaziyatdan kelib chiqqan holda, men har biri uchun eng mos keladigan Docker-ga mos echimlarning namunalarini va quyidagi davlat xizmatlarining guruhlarini ajratib ko'rsatishim mumkin:

  • Ma'lumotlar bazasini boshqarish tizimlari - PostDock har qanday Docker muhitida PostgreSQL uchun sodda va ishonchli echimdir
  • Navbat / xabar vositachilari - RabbitMQ bu xabarlar navbatini tuzish va xabarlarni yo'naltirish uchun klassik dastur. RabbitMQ konfiguratsiyasidagi klaster_formatsiya parametri klasterni sozlash uchun zarur
  • Keshlash xizmatlari - ma'lumotlarni keshlashning eng ishonchli va moslashuvchan echimlaridan biri hisoblanadi
  • To'liq matnli qidiruv - Men yuqorida aytib o'tgan Elasticsearch stack, dastlab to'liq matnli qidiruv uchun ishlatilgan, ammo jurnallarni saqlashda va katta hajmdagi matnli ma'lumotlar bilan har qanday ish uchun juda yaxshi.
  • Fayllarni saqlash xizmatlari - fayllarni saqlash va etkazib berishning har qanday turiga (ftp, sftp va hokazo) xizmatlarning umumlashtiruvchi guruhi.

Bog'lanish nometalllari

Agar siz hali ham zarur bo'lgan paketlar yoki qaramliklar olib tashlangan yoki umumiy serverdan vaqtincha foydalana olmagan vaziyatga duch kelmagan bo'lsangiz, bu hech qachon bo'lmaydi deb o'ylamang. Keraksiz mavjud bo'lmaslik va ichki tizimlarning xavfsizligini ta'minlash uchun xizmatlarni qurish yoki etkazib berish Internetga ulanishni talab qilmasligiga ishonch hosil qiling. Ko'zgularni aks ettirish va ichki tarmoqdagi barcha bog'liqliklarni nusxalashni sozlang: Docker rasmlari, rpm to'plami, manba ombori, python / go / js / php modullari.

Ushbu va har qanday boshqa qaramlik turlarining har biri o'z echimiga ega. Eng keng tarqalganini "... uchun shaxsiy qaramlik oynasi" so'rovi orqali aniqlash mumkin.

Arxitekturadan haqiqiy hayotga

Yoqadimi yoki yo'qmi, ertami-kechmi sizning butun arxitekturangiz ishdan chiqadi. Har doim shunday bo'ladi: texnologiyalar tez eskiradi (1–5 yil), usul va yondashuvlar - biroz sekinroq (5–10 yil), dizayn tamoyillari va asoslari - vaqti-vaqti bilan (10–20 yil), ammo muqarrar.

Texnologiyalarning eskirganligini yodda tutib, har doim ekotizimingizni texnologik innovatsiyalar cho'qqisida ushlab turishga harakat qiling, ishlab chiquvchilar, biznes va oxirgi foydalanuvchilarning ehtiyojlarini qondirish uchun yangi xizmatlarni rejalashtiring va ishlab chiqing, manfaatdor tomonlarga yangi yordam dasturlarini targ'ib qiling, bilimingizni etkazing. jamoa va kompaniya oldinga.

Professional jamoaga qo'shilish, tegishli adabiyotlarni o'qish va hamkasblar bilan suhbatlashish orqali o'yinning yuqori qismida turing. O'zingizning imkoniyatlaringiz va loyihangizdagi yangi tendentsiyalardan to'g'ri foydalanishni biling. Tadqiqot natijalarini tahlil qilish uchun ilmiy usullarni sinab ko'ring va qo'llang yoki o'zingiz ishonadigan va hurmat qiladigan boshqa odamlarning xulosalariga tayaning.

O'zingizni tub o'zgarishlarga tayyorlash qiyin, ammo agar siz o'z sohangizning mohir mutaxassisi bo'lsangiz. Barchamiz hayotimiz davomida faqat bir nechta katta texnologik o'zgarishlarga guvoh bo'lamiz, ammo bu bizning bilimlarimiz darajasi emas, balki bizni professional qiladi va bizni eng yuqori darajaga olib chiqadi, bu bizning g'oyalarimizga ochiqlik va metamorfozni qabul qilish qobiliyatidir.

Sarlavhadan savolga qaytib, "yaxshiroq arxitekturani qurish mumkinmi?" Yo'q, "bir marotaba va umuman" emas, balki bunga intiling va qandaydir bir vaqtda "qisqa vaqtga", siz albatta muvaffaqiyat qozonadi!

PS:

Asl maqola rus tilida yozilgan, shuning uchun Lazadadagi hamkasbim Sergey Rodinga uni tarjima qilishda ko'rsatgan ajoyib yordami uchun tashakkur!