“Doğma bulud” və ya sadəcə “bulud” proqramları bulud infrastrukturlarında işləmək üçün xüsusi olaraq yaradılmışdır. Onlar adətən konteynerlərdə qablaşdırılan, öz növbəsində bulud platforması tərəfindən idarə olunan bir sıra sərbəst bağlanmış mikroservislər kimi qurulur. Bu cür proqramlar defolt olaraq uğursuzluqlar üçün hazırlanır, yəni infrastruktur səviyyəsində ciddi nasazlıqlar halında belə etibarlı işləyir və miqyas alır. Sikkənin digər tərəfi bulud platformasının konteyner tətbiqlərini avtomatik idarə edə bilmək üçün tətbiq etdiyi məhdudiyyətlər (müqavilələr) dəstləridir.
Bulud əsaslı tətbiqlərə keçməyin zərurətini və əhəmiyyətini tam dərk etməsinə baxmayaraq, bir çox təşkilat hələ də haradan başlayacağını bilmir. Bu yazıda biz bir sıra prinsiplərə baxacağıq ki, bunlara konteynerləşdirilmiş proqramlar hazırlayarkən əməl olunarsa, İT infrastrukturunda ciddi nasazlıqlar halında belə, bulud platformalarının potensialını reallaşdırmağa və etibarlı işləməyə və tətbiqlərin miqyasına nail olmağa imkan verəcəkdir. səviyyə. Burada göstərilən prinsiplərin son məqsədi Kubernetes kimi bulud platformaları tərəfindən avtomatik idarə oluna bilən tətbiqlərin necə qurulacağını öyrənməkdir.
Proqram təminatının dizayn prinsipləri
Proqramlaşdırma dünyasında prinsiplər proqram təminatı hazırlayarkən əməl edilməli olan kifayət qədər ümumi qaydalara istinad edir. Onlar istənilən proqramlaşdırma dili ilə işləyərkən istifadə edilə bilər. Hər bir prinsipin öz məqsədləri var, nail olmaq üçün alətlər adətən şablonlar və təcrübələrdir. Yüksək keyfiyyətli proqram təminatının yaradılması üçün bir sıra fundamental prinsiplər də mövcuddur ki, bunların hamısından başqaları çıxır. Əsas prinsiplərə bəzi nümunələr:
- (Sadə saxlayın, axmaq) – çətinləşdirməyin;
- (Özünü təkrarlama) - özünü təkrar etmə;
- (Buna ehtiyacınız olmayacaq) - dərhal lazım olmayan bir şey yaratmayın;
- Narahatlıqların ayrılması – məsuliyyətlərin bölüşdürülməsi.
Göründüyü kimi, bu prinsiplər heç bir xüsusi qaydalar təyin etmir, lakin bir çox tərtibatçılar tərəfindən paylaşılan və müntəzəm olaraq istinad etdikləri praktik təcrübəyə əsaslanan ümumi mənalı mülahizələr kateqoriyasına aiddir.
Bundan əlavə, var – Robert Martin tərəfindən tərtib edilmiş obyekt yönümlü proqramlaşdırma və dizaynın ilk beş prinsipinin toplusu. SOLID-ə geniş, açıq, tamamlayıcı prinsiplər daxildir ki, bunlar birlikdə tətbiq olunduqda daha yaxşı proqram sistemləri yaratmağa və onları uzun müddət ərzində daha yaxşı saxlamağa kömək edir.
SOLID prinsipləri OOP sahəsinə aiddir və siniflər, interfeyslər və miras kimi anlayış və anlayışların dilində tərtib edilmişdir. Bənzətmə ilə, inkişaf prinsipləri bulud tətbiqləri üçün də tərtib edilə bilər, burada yalnız əsas element sinif deyil, konteyner olacaqdır. Bu prinsiplərə əməl etməklə siz Kubernetes kimi bulud platformalarının məqsəd və məqsədlərinə daha yaxşı cavab verən konteynerləşdirilmiş proqramlar yarada bilərsiniz.
Buludlu konteynerlər: Red Hat yanaşması
Bu gün demək olar ki, hər hansı bir tətbiq konteynerlərə nisbətən asanlıqla qablaşdırıla bilər. Lakin tətbiqlərin Kubernetes kimi bulud platformasında effektiv şəkildə avtomatlaşdırılması və təşkili üçün əlavə səy tələb olunur.
Aşağıda qeyd olunan fikirlərin əsasını metodologiya təşkil edirdi və mənbə kodunun idarə edilməsindən tutmuş miqyaslı modellərə qədər veb proqramların qurulmasının müxtəlif aspektləri üzrə bir çox başqa işlər. Təsvir edilən prinsiplər yalnız mikroservislər üzərində qurulan və Kubernetes kimi bulud platformaları üçün nəzərdə tutulmuş konteynerləşdirilmiş proqramların inkişafına aiddir. Müzakirəmizin əsas elementi konteyner şəklidir və hədəf konteynerin işləmə müddəti konteynerin orkestrasiya platformasıdır. Təklif olunan prinsiplərin məqsədi planlaşdırma, miqyaslaşdırma və monitorinq tapşırıqlarının əksər orkestr platformalarında avtomatlaşdırıla biləcəyi konteynerlər yaratmaqdır. Prinsiplər heç bir xüsusi ardıcıllıqla təqdim edilmir.
Vahid narahatlıq prinsipi (SCP)
Bu prinsip bir çox cəhətdən Vahid Məsuliyyət Prinsipinə bənzəyir. ), SOLID dəstinin bir hissəsidir və hər bir obyektin bir məsuliyyət daşımalı olduğunu və bu məsuliyyətin sinifdə tamamilə əhatə edilməli olduğunu bildirir. SRP-nin məqsədi ondan ibarətdir ki, hər bir məsuliyyət dəyişiklik üçün bir səbəbdir və bir sinfin dəyişiklik üçün bir və yalnız bir səbəbi olmalıdır.
SCP-də biz OOP sinfi ilə müqayisədə konteynerin daha yüksək abstraksiya səviyyəsini və daha geniş məqsədini göstərmək üçün “məsuliyyət” sözü əvəzinə “narahatlıq” sözündən istifadə edirik. Əgər SRP-nin məqsədi dəyişiklik üçün yalnız bir səbəbə sahib olmaqdırsa, CQBK-nın arxasında konteynerlərin təkrar istifadəsi və dəyişdirilməsi imkanlarını genişləndirmək istəyi dayanır. SRP-yə əməl etməklə və vahid problemi həll edən və onu funksional olaraq tam şəkildə yerinə yetirən konteyner yaratmaqla siz həmin konteyner şəklini müxtəlif tətbiq kontekstlərində təkrar istifadə etmək şanslarını artırmış olursunuz.
CQBK prinsipi bildirir ki, hər konteyner bir problemi həll etməli və bunu yaxşı etməlidir. Üstəlik, konteyner dünyasında CQBK-ya nail olmaq OOP dünyasındakı SRP-dən daha asandır, çünki konteynerlər adətən bir prosesi həyata keçirir və çox vaxt bu proses bir vəzifəni həll edir.
Konteyner mikroservisi eyni anda bir neçə problemi həll etməlidirsə, o zaman o, tək vəzifəli konteynerlərə bölünə və yan araba və init konteyner şablonlarından istifadə edərək bir pod (konteyner platformasının yerləşdirilməsi vahidi) daxilində birləşdirilə bilər. Bundan əlavə, SCP köhnə konteyneri (məsələn, veb-server və ya mesaj brokeri) eyni problemi həll edən, lakin genişləndirilmiş funksionallığı və ya miqyası daha yaxşı olan yenisi ilə əvəz etməyi asanlaşdırır.
Yüksək müşahidə prinsipi (HOP)
Konteynerlər proqramları paketləmək və işə salmaq üçün vahid üsul kimi istifadə edildikdə, proqramların özləri qara qutu kimi qəbul edilir. Bununla belə, əgər bunlar bulud konteynerləridirsə, o zaman konteynerlərin sağlamlığına nəzarət etmək və lazım gələrsə, müvafiq tədbirlər görmək üçün iş müddətinə xüsusi API təqdim etməlidirlər. Bunsuz, konteynerlərin yenilənməsi və onların həyat dövrünün idarə edilməsinin avtomatlaşdırılmasını unifikasiya etmək mümkün olmayacaq, bu da öz növbəsində proqram təminatı sisteminin dayanıqlığını və yararlılığını pisləşdirəcək.
Təcrübədə konteynerləşdirilmiş proqram, ən azı, müxtəlif növ sağlamlıq yoxlamaları üçün API-yə malik olmalıdır: canlılıq testləri və hazırlıq testləri. Tətbiq daha çox iş gördüyünü iddia edirsə, onun vəziyyətini izləmək üçün başqa vasitələr təqdim etməlidir. Məsələn, Fluentd, Logstash və digər oxşar vasitələrdən istifadə edərək logların birləşdirilməsi üçün STDERR və STDOUT vasitəsilə mühüm hadisələrin qeyd edilməsi. Həmçinin OpenTracing, Prometheus və s. kimi izləmə və metrik kolleksiya kitabxanaları ilə inteqrasiya.
Ümumiyyətlə, tətbiq hələ də qara qutu kimi qəbul edilə bilər, lakin onu ən yaxşı şəkildə izləmək və idarə etmək üçün platformanın ehtiyac duyduğu bütün API-lərlə təmin edilməlidir.
Həyat dövrünə uyğunluq prinsipi (LCP)
LCP HOP-un əksidir. HOP, konteynerin oxunan API-ləri platformaya təqdim etməli olduğunu bildirsə də, LCP tətbiqin platformadan məlumat qəbul edə bilməsini tələb edir. Üstəlik, konteyner təkcə hadisələri qəbul etməməli, həm də uyğunlaşmalıdır, başqa sözlə, onlara reaksiya verməlidir. Platformanı yazı API-ləri ilə təmin etmək tələbi kimi qəbul edilə bilən prinsipin adı belədir.
Platformalarda konteynerin həyat dövrünü idarə etməyə kömək etmək üçün müxtəlif növ hadisələr var. Ancaq onlardan hansının qəbul ediləcəyi və necə reaksiya veriləcəyi tətbiqin özündən asılıdır.
Aydındır ki, bəzi hadisələr digərlərindən daha vacibdir. Məsələn, əgər proqram qəzalara yaxşı dözmürsə, o, siqnalı qəbul etməlidir: SIGTERM-dən sonra gələn siqnalı tutmaq üçün (SIGTERM) mesajlarını dayandırmalı və onun dayandırma rejiminə mümkün qədər tez başlamalıdır: öldür (SIGKILL).
Bundan əlavə, PostStart və PreStop kimi hadisələr tətbiqin həyat dövrü üçün vacib ola bilər. Məsələn, tətbiqi işə saldıqdan sonra onun sorğulara cavab verməsi üçün bir az isinmə vaxtı tələb oluna bilər. Və ya proqram bağlanarkən resursları hansısa xüsusi şəkildə buraxmalıdır.
Təsvirin dəyişməzliyi prinsipi (IIP)
Ümumiyyətlə qəbul edilir ki, konteynerləşdirilmiş proqramlar müxtəlif mühitlərdə işlədilsə belə, qurulduqdan sonra dəyişməz qalmalıdır. Bu, hər bir mühit üçün unikal konteynerləri dəyişdirmək və ya yaratmaqdansa, iş zamanı məlumatların saxlanmasını xaricə çevirmək (başqa sözlə, bunun üçün xarici alətlərdən istifadə etmək) və xarici, iş vaxtı üçün xüsusi konfiqurasiyalara etibar etmək ehtiyacını tələb edir. Tətbiqdə hər hansı dəyişiklik edildikdən sonra konteyner şəkli yenidən qurulmalı və istifadə olunan bütün mühitlərə yerləşdirilməlidir. Yeri gəlmişkən, İT sistemlərini idarə edərkən serverlərin və infrastrukturun dəyişməzliyi prinsipi kimi tanınan oxşar prinsipdən istifadə olunur.
IIP-nin məqsədi müxtəlif iş vaxtı mühitləri üçün ayrı-ayrı konteyner şəkillərinin yaradılmasının qarşısını almaq və ətraf mühitə uyğun uyğun konfiqurasiya ilə birlikdə eyni təsviri hər yerdə istifadə etməkdir. Bu prinsipə riayət etmək, bulud sistemlərinin avtomatlaşdırılması baxımından proqram yeniləmələrinin geri qaytarılması və irəli çəkilməsi kimi mühüm təcrübələri həyata keçirməyə imkan verir.
Prosesin Birdəfəlik İstifadəsi Prinsipi (PDP)
Konteynerin ən vacib xüsusiyyətlərindən biri onun efemerliyidir: konteyner nümunəsini yaratmaq və məhv etmək asandır, ona görə də istənilən vaxt asanlıqla başqa bir nümunə ilə əvəz edilə bilər. Belə bir dəyişdirmə üçün bir çox səbəb ola bilər: xidmət qabiliyyəti testinin uğursuzluğu, tətbiqin miqyası, başqa bir hosta ötürülməsi, platforma resurslarının tükənməsi və ya digər vəziyyətlər.
Nəticədə, konteynerləşdirilmiş proqramlar bəzi xarici vasitələrdən istifadə edərək öz vəziyyətini saxlamalı və ya bunun üçün artıqlığı olan daxili paylanmış sxemlərdən istifadə etməlidir. Bundan əlavə, proqram tez başlamalı və tez bağlanmalı və ani ölümcül hardware nasazlığına hazır olmalıdır.
Bu prinsipi həyata keçirməyə kömək edən təcrübələrdən biri qabları kiçik saxlamaqdır. Bulud mühitləri konteyner nümunəsini işə salmaq üçün avtomatik olaraq host seçə bilər, beləliklə, konteyner nə qədər kiçik olsa, o, daha sürətli işə düşəcək - o, sadəcə olaraq şəbəkə üzərindən hədəf hosta daha sürətli köçürəcək.
Özünü tutma Prinsipi (S-CP)
Bu prinsipə əsasən, montaj mərhələsində bütün lazımi komponentlər konteynerə daxil edilir. Konteyner sistemin yalnız təmiz Linux nüvəsinə malik olduğu fərziyyəsi üzərində qurulmalıdır, buna görə də bütün lazımi əlavə kitabxanalar konteynerin özündə yerləşdirilməlidir. O, həmçinin müvafiq proqramlaşdırma dili üçün iş vaxtı, proqram platforması (lazım olduqda) və konteyner tətbiqi işləyərkən tələb olunacaq digər asılılıqları ehtiva etməlidir.
İstisnalar mühitdən mühitə dəyişən konfiqurasiyalar üçün edilir və iş vaxtında təmin edilməlidir, məsələn, Kubernetes ConfigMap vasitəsilə.
Tətbiq bir neçə konteynerləşdirilmiş komponentdən ibarət ola bilər, məsələn, konteynerləşdirilmiş veb proqram daxilində ayrıca DBMS konteyneri. S-CP prinsipinə görə, bu konteynerlər bir yerə birləşdirilməməlidir, lakin elə edilməlidir ki, DBMS konteynerində verilənlər bazasının işləməsi üçün lazım olan hər şey, veb proqram konteynerində isə internetin işləməsi üçün lazım olan hər şey var. proqram, eyni web server . Nəticə olaraq, iş vaxtında veb proqram konteyneri DBMS konteynerindən asılı olacaq və lazım olduqda ona daxil olacaq.
Runtime Confinement Principle (RCP)
S-CP prinsipi konteynerin necə qurulacağını və görüntü binarının nəyi ehtiva etməsini müəyyənləşdirir. Ancaq konteyner yalnız bir xüsusiyyəti olan bir "qara qutu" deyil - fayl ölçüsü. İcra zamanı konteyner başqa ölçülər alır: istifadə olunan yaddaşın miqdarı, CPU vaxtı və digər sistem resursları.
Və burada RCP prinsipi əlverişlidir, buna görə konteyner sistem resurslarına olan tələblərini kəsməli və platformaya köçürməlidir. Hər bir konteynerin resurs profilləri (nə qədər CPU, yaddaş, şəbəkə və disk resurslarına ehtiyacı var) ilə platforma optimal şəkildə planlaşdırma və avtomatik ölçmə həyata keçirə, İT tutumunu idarə edə və konteynerlər üçün SLA səviyyələrini saxlaya bilər.
Konteynerin resurs tələblərinə cavab verməklə yanaşı, tətbiqin öz hüdudlarından kənara çıxmaması da vacibdir. Əks halda, resurs çatışmazlığı yarandıqda, platformanın onu dayandırılması və ya köçürülməsi lazım olan proqramlar siyahısına daxil etmə ehtimalı daha yüksəkdir.
Buluddan birinci olmaq haqqında danışarkən, işimizdən danışırıq.
Yuxarıda, biz bulud mühitləri üçün yüksək keyfiyyətli konteyner proqramlarının qurulması üçün metodoloji əsası təyin edən bir sıra ümumi prinsipləri tərtib etdik.
Qeyd edək ki, bu ümumi prinsiplərə əlavə olaraq, konteynerlərlə işləmək üçün əlavə qabaqcıl üsul və üsullara da ehtiyacınız olacaq. Bundan əlavə, daha konkret olan və vəziyyətdən asılı olaraq tətbiq edilməli (və ya tətbiq edilməməli) bir neçə qısa tövsiyəmiz var:
- Şəkillərin ölçüsünü azaltmağa çalışın: müvəqqəti faylları silin və lazımsız paketləri quraşdırmayın - konteynerin ölçüsü nə qədər kiçik olsa, o, şəbəkə üzərindən hədəf hosta bir o qədər tez yığılır və kopyalanır.
- İxtiyari İstifadəçi ID-lərinə diqqət yetirin: konteynerlərinizi işə salmaq üçün sudo əmrindən və ya hər hansı xüsusi istifadəçi identifikatorundan istifadə etməyin.
- Vacib portları qeyd edin: Siz port nömrələrini iş vaxtı təyin edə bilərsiniz, lakin EXPOSE əmrindən istifadə edərək onları müəyyən etmək daha yaxşıdır - bu, digər insanların və proqramların şəkillərinizdən istifadə etməsini asanlaşdıracaq.
- Davamlı məlumatları həcmlərdə saxlayın: Konteyner məhv edildikdən sonra qalmalı olan məlumatlar cildlərə yazılmalıdır.
- Şəkil metadatasını yazın: teqlər, etiketlər və annotasiyalar şəkillərdən istifadəni asanlaşdırır - digər tərtibatçılar sizə təşəkkür edəcəklər.
- Host və şəkilləri sinxronlaşdırın: Bəzi konteynerləşdirilmiş proqramlar konteynerin vaxt və ya maşın ID kimi müəyyən atributlarda host ilə sinxronizasiyasını tələb edir.
- Yekun olaraq, yuxarıda sadalanan prinsipləri daha effektiv şəkildə həyata keçirməyə kömək edəcək şablonları və ən yaxşı təcrübələri paylaşırıq:
11 iyun saat 11.00
Nə öyrənəcəksiniz:
- Dəyişməz Red Hat Enterprise Linux CoreOS
- OpenShift xidmət şəbəkəsi
- Operator çərçivəsi
- Knative çərçivə
Mənbə: www.habr.com