Siz İT-də işləyərkən sistemlərin öz xarakterinə malik olduğunu görməyə başlayırsınız. Onlar çevik, səssiz, eksantrik və sərt ola bilər. Onlar cəlb edə və ya dəf edə bilərlər. Bu və ya digər şəkildə siz onlarla "danışıqlar" aparmalı, "tələbələr" arasında manevr etməli və onların qarşılıqlı əlaqə zəncirlərini qurmalısınız.
Beləliklə, biz bulud platforması qurmaq şərəfinə nail olduq və bunun üçün bir neçə alt sistemi bizimlə işləməyə “inanmalı” olduq. Xoşbəxtlikdən, bizim "API dilimiz", birbaşa əllərimiz və çoxlu həvəsimiz var.
Bu məqalə texniki cəhətdən çətin olmayacaq, lakin bulud qurarkən qarşılaşdığımız problemləri təsvir edəcək. Yolumuzu sistemlərlə ortaq dil axtardığımız və ondan nə çıxdığı haqqında yüngül texniki fantaziya şəklində təsvir etmək qərarına gəldim.
Pişiyə xoş gəldiniz.
Bir səfər başlanğıcı
Bir müddət əvvəl komandamıza müştərilərimiz üçün bulud platformasını işə salmaq tapşırılmışdı. Xidmətin proqram hissəsini həyata keçirmək üçün texnologiyaları seçməkdə idarəetmə dəstəyi, resurslar, aparat yığını və azadlığımız var idi.
Bir sıra tələblər də var idi:
- xidmət üçün rahat şəxsi hesab lazımdır;
- platforma mövcud billinq sisteminə inteqrasiya edilməlidir;
- proqram və avadanlıq: OpenStack + Volfram Parçası (Open Contrail), bizim mühəndislərimiz “bişirməyi” çox yaxşı öyrənmişlər.
Habra icması maraqlanarsa, komandanın necə yığıldığı, şəxsi hesab interfeysinin işlənib hazırlanması və dizayn qərarlarının verildiyi barədə sizə başqa dəfə məlumat verəcəyik.
İstifadə etməyə qərar verdiyimiz vasitələr:
- Python + Flask + Swagger + SQLAlchemy - tamamilə standart Python dəsti;
- Frontend üçün Vue.js;
- Biz AMQP üzərindən Kərəvizdən istifadə edərək komponentlər və xidmətlər arasında qarşılıqlı əlaqə yaratmağa qərar verdik.
Python seçimi ilə bağlı sualları gözləyərək izah edəcəyəm. Dil bizim şirkətdə öz yerini tapdı və onun ətrafında kiçik, lakin hələ də mədəniyyət formalaşdı. Ona görə də onun üzərində xidmətin qurulmasına başlamaq qərara alınıb. Üstəlik, bu cür problemlərdə inkişaf sürəti çox vaxt həlledici olur.
Beləliklə, tanışlığımıza başlayaq.
Səssiz Bill - faktura
Biz bu adamı çoxdan tanıyırıq. Həmişə yanımda oturub, səssizcə nəyisə sayırdı. Bəzən o, istifadəçi sorğularını bizə yönləndirir, müştəri hesab-fakturalarını verir və xidmətləri idarə edirdi. Adi zəhmətkeş oğlan. Düzdür, çətinliklər var idi. O, susur, bəzən fikirləşir və çox vaxt öz fikrindədir.
Billing dostluq etməyə çalışdığımız ilk sistemdir. Və qarşılaşdığımız ilk çətinlik xidmətlərin işlənməsi zamanı oldu.
Məsələn, yaradıldıqda və ya silindikdə tapşırıq daxili faktura növbəsinə keçir. Beləliklə, xidmətlərlə asinxron iş sistemi həyata keçirilir. Xidmət növlərimizi emal etmək üçün tapşırıqlarımızı bu növbəyə "qoymalı" idik. Və burada bir problemlə qarşılaşdıq: sənədlərin olmaması.
Proqram API-nin təsvirinə əsasən, hələ də bu problemi həll etmək mümkündür, lakin tərs mühəndislik etməyə vaxtımız yox idi, ona görə də məntiqi kənara çıxarıb RabbitMQ-nun üstündə tapşırıq növbəsi təşkil etdik. Xidmət üzrə əməliyyat müştəri tərəfindən şəxsi hesabından başlanır, arxa tərəfdə Kərəviz “tapşırığına” çevrilir və hesablaşma və OpenStack tərəfində həyata keçirilir. Kərəviz tapşırıqları idarə etmək, təkrarları təşkil etmək və vəziyyətə nəzarət etmək üçün olduqca rahat edir. Siz "kərəviz" haqqında daha çox oxuya bilərsiniz, məsələn, .
Həmçinin, hesablaşma pulu tükənmiş bir layihəni dayandırmadı. Tərtibatçılarla əlaqə saxlayaraq, statistikanı hesablayarkən (və biz məhz bu cür məntiqi həyata keçirməliyik) dayandırma qaydalarının mürəkkəb qarşılıqlı əlaqəsinin olduğunu bildik. Amma bu modellər bizim reallıqlarımıza uyğun gəlmir. Biz də onu Kərəvizdəki tapşırıqlar vasitəsilə həyata keçirdik, xidmət idarəetmə məntiqini arxa tərəfə keçirdik.
Yuxarıda göstərilən problemlərin hər ikisi kodun bir az şişməsinə səbəb oldu və gələcəkdə tapşırıqlarla işləmək üçün məntiqi ayrıca bir xidmətə köçürmək üçün refaktor etməli olacağıq. Biz də bu məntiqi dəstəkləmək üçün istifadəçilər və onların xidmətləri haqqında bəzi məlumatları cədvəllərimizdə saxlamalıyıq.
Başqa bir problem səssizlikdir.
Billy bəzi API sorğularına səssizcə “Ok” cavabını verir. Bu, məsələn, sınaq zamanı vəd edilmiş ödənişlərin ödənişlərini etdikdə belə idi (bu barədə daha sonra). Sorğular düzgün yerinə yetirildi və heç bir səhv görmədik.
UI vasitəsilə sistemlə işləyərkən qeydləri öyrənməli oldum. Məlum oldu ki, faktura özü oxşar sorğuları yerinə yetirir, əhatə dairəsini müəyyən bir istifadəçiyə dəyişdirir, məsələn, admin, onu su parametrinə keçir.
Ümumiyyətlə, sənədlərdəki boşluqlara və kiçik API qüsurlarına baxmayaraq, hər şey olduqca yaxşı keçdi. Qeydlər, onların necə qurulduğunu və nə axtarmaq lazım olduğunu başa düşsəniz, hətta ağır yük altında da oxuna bilər. Verilənlər bazasının strukturu bəzəkli, lakin kifayət qədər məntiqli və bəzi mənalarda hətta cəlbedicidir.
Beləliklə, ümumiləşdirsək, qarşılıqlı əlaqə mərhələsində qarşılaşdığımız əsas problemlər müəyyən bir sistemin tətbiqi xüsusiyyətləri ilə bağlıdır:
- bizə bu və ya digər şəkildə təsir edən sənədsiz “xüsusiyyətlər”;
- qapalı mənbə (faktura C++ dilində yazılır), nəticədə - 1-ci problemi “sınaq və səhv”dən başqa heç bir şəkildə həll etmək mümkün deyil.
Xoşbəxtlikdən, məhsul kifayət qədər geniş API-yə malikdir və biz aşağıdakı alt sistemləri şəxsi hesabımıza inteqrasiya etdik:
- texniki dəstək modulu - şəxsi hesabınızdan sorğular xidmət müştəriləri üçün şəffaf şəkildə hesablaşmaya “proksiləşdirilir”;
- maliyyə modulu - cari müştərilərə hesab-fakturalar verməyə, hesab-fakturaları silməyə və ödəniş sənədləri yaratmağa imkan verir;
- xidmət idarəetmə modulu - bunun üçün öz işləyicimizi həyata keçirməli olduq. Sistemin genişlənməsi bizim əlimizdə oynadı və biz Billiyə yeni xidmət növünü “öyrətdik”.
Bir az çətin idi, amma bu və ya digər şəkildə, düşünürəm ki, Billy və mən anlaşacağıq.
Volfram sahələrində gəzinti - Volfram Parçası
Volfram sahələri yüzlərlə naqillə dotlanmış, onlardan minlərlə bit məlumat keçir. Məlumat sanki sehrli şəkildə "paketlərə" toplanır, təhlil edilir, mürəkkəb marşrutlar qurur.
Bu, dostluq etməli olduğumuz ikinci sistemin sahəsidir - əvvəllər OpenContrail olan Volfram Parçası (TF). Onun vəzifəsi istifadəçilər kimi bizə proqram abstraksiyasını təmin edən şəbəkə avadanlıqlarını idarə etməkdir. TF - SDN, şəbəkə avadanlığı ilə işləməyin mürəkkəb məntiqini əhatə edir. Texnologiyanın özü haqqında yaxşı bir məqalə var, məsələn, .
Sistem Neytron plagini vasitəsilə OpenStack (aşağıda müzakirə olunur) ilə inteqrasiya olunub.
OpenStack xidmətlərinin qarşılıqlı əlaqəsi.
Əməliyyat şöbəsinin oğlanları bizi bu sistemlə tanış etdilər. Xidmətlərimizin şəbəkə yığınını idarə etmək üçün sistemin API-dən istifadə edirik. Bu, hələ bizə heç bir ciddi problem və ya narahatlıq yaratmadı (OE-dən olan uşaqlar üçün danışa bilmərəm), lakin qarşılıqlı əlaqədə bəzi qəribəliklər var.
Birincisi belə görünürdü: SSH vasitəsilə qoşulduqda nümunə konsoluna böyük miqdarda məlumatın çıxarılmasını tələb edən əmrlər sadəcə olaraq əlaqəni “asdırdı”, VNC vasitəsilə isə hər şey düzgün işləyirdi.
Problemlə tanış olmayanlar üçün olduqca gülməli görünür: ls /root düzgün işləyir, məsələn, yuxarı tamamilə "donur". Xoşbəxtlikdən əvvəllər də oxşar problemlərlə qarşılaşmışıq. Hesablama qovşaqlarından marşrutlaşdırıcılara gedən marşrutda MTU-nu tənzimləməklə qərar verildi. Yeri gəlmişkən, bu TF problemi deyil.
Növbəti problem az qala küncdə idi. Bir "gözəl" anda, marşrutlaşdırma sehri yox oldu, eynilə belə. TF avadanlıqda marşrutlaşdırmanı idarə etməyi dayandırdı.
Openstack ilə admin səviyyəsindən işlədik və bundan sonra tələb olunan istifadəçi səviyyəsinə keçdik. SDN, hərəkətlərin yerinə yetirildiyi istifadəçinin əhatə dairəsini “oğurlayır”. Fakt budur ki, TF və OpenStack-i birləşdirmək üçün eyni admin hesabı istifadə olunur. İstifadəçiyə keçid mərhələsində "sehrli" yox oldu. Sistemlə işləmək üçün ayrıca hesab yaradılması qərara alınıb. Bu, inteqrasiya funksionallığını pozmadan işləməyə imkan verdi.
Silicon Lifeforms - OpenStack
Qəribə formalı silikon məxluq volfram sahələrinin yaxınlığında yaşayır. Ən çox da bizi bir yelləncəklə əzməyə qadir uşağa bənzəyir, amma ondan açıq-aşkar aqressiya gəlmir. Qorxu yaratmır, lakin ölçüsü qorxu yaradır. Ətrafda baş verənlərin mürəkkəbliyi kimi.
OpenStack platformamızın əsasını təşkil edir.
OpenStack-in bir neçə alt sistemi var, onlardan hazırda Nova, Glance və Cinder istifadə edirik. Onların hər birinin öz API var. Nova hesablama resursları və nümunələrin yaradılması üçün cavabdehdir, Cinder həcmlərin və onların anlıq görüntülərinin idarə edilməsinə cavabdehdir, Glance OS şablonlarını və onlarda metainformasiyanı idarə edən görüntü xidmətidir.
Hər bir xidmət bir konteynerdə işləyir və mesaj brokeri “ağ dovşan” - RabbitMQ.
Bu sistem bizə ən gözlənilməz bəla verdi.
Və serverə əlavə bir həcm qoşmağa çalışdığımız zaman ilk problem çox keçmədi. Cinder API bu tapşırığı yerinə yetirməkdən qəti şəkildə imtina etdi. Daha doğrusu, OpenStack-in özünə inanırsınızsa, əlaqə qurulur, lakin virtual server daxilində disk cihazı yoxdur.
Biz dolama yolu seçməyə qərar verdik və eyni hərəkəti Nova API-dən tələb etdik. Nəticə odur ki, cihaz düzgün qoşulur və server daxilində əlçatandır. Görünür, problem blok saxlama Cinder-ə cavab vermədikdə baş verir.
Disklərlə işləyərkən bizi daha bir çətinlik gözləyirdi. Sistem həcmini serverdən ayırmaq mümkün olmadı.
Yenə də OpenStack özü əlaqəni məhv etdiyinə “and içir” və indi siz ayrı-ayrılıqda həcmlə düzgün işləyə bilərsiniz. Lakin API qəti şəkildə diskdə əməliyyatlar aparmaq istəmədi.
Burada xüsusi olaraq mübarizə aparmaq deyil, xidmətin məntiqinə baxışımızı dəyişmək qərarına gəldik. Bir nümunə varsa, sistem həcmi də olmalıdır. Buna görə də, istifadəçi hələ "server"i silmədən sistem "diskini" silə və ya söndürə bilməz.
OpenStack, öz qarşılıqlı əlaqə məntiqi və zərif API ilə kifayət qədər mürəkkəb sistemlər toplusudur. Bizə kifayət qədər ətraflı sənədlər və əlbəttə ki, sınaq və səhvlər kömək edir (onsuz harada olardıq).
Test qaçışı
Keçən ilin dekabrında sınaq sınaqları keçirdik. Əsas vəzifə layihəmizi texniki tərəfdən və UX tərəfdən döyüş rejimində sınaqdan keçirmək idi. Tamaşaçılar seçmə şəkildə dəvət edildi və sınaq bağlandı. Bununla belə, biz veb saytımızda testə giriş tələb etmək seçimini də tərk etmişik.
Testin özü, əlbəttə ki, gülməli məqamlardan da məhrum deyildi, çünki burada macəralarımız yeni başlayır.
Birincisi, biz layihəyə marağı bir qədər səhv qiymətləndirdik və test zamanı dərhal hesablama qovşaqlarını əlavə etməli olduq. Bir çoxluq üçün ümumi bir vəziyyət, lakin burada da bəzi nüanslar var idi. TF-nin xüsusi versiyası üçün sənədlər vRouter ilə işin sınaqdan keçirildiyi nüvənin xüsusi versiyasını göstərir. Daha yeni nüvələri olan qovşaqları işə salmaq qərarına gəldik. Nəticədə TF qovşaqlardan marşrutlar almadı. Mən təcili olaraq ləpələri geri çevirməli oldum.
Başqa bir maraq şəxsi hesabınızdakı “parolun dəyişdirilməsi” düyməsinin funksionallığı ilə bağlıdır.
Seanslarla işləməmək üçün şəxsi hesabımıza girişi təşkil etmək üçün JWT-dən istifadə etmək qərarına gəldik. Sistemlər müxtəlif və geniş şəkildə səpələnmiş olduğundan, biz öz tokenimizi idarə edirik, orada seansları hesablaşmadan və OpenStack-dən bir tokendən “sarırıq”. Parol dəyişdirildikdə, işarə, əlbəttə ki, "pis olur", çünki istifadəçi məlumatları artıq etibarlı deyil və yenidən buraxılmalıdır.
Biz bu məqamı unutduq və bu əsəri tez bitirmək üçün kifayət qədər resurs yox idi. Testə başlamazdan əvvəl funksionallığı kəsməli olduq.
Hazırda parol dəyişdirildiyi təqdirdə istifadəçidən çıxış edirik.
Bu nüanslara baxmayaraq, sınaq yaxşı keçdi. Bir neçə həftə ərzində 300-ə yaxın adam dayandı. Məhsula istifadəçilərin gözü ilə baxa, onu hərəkətdə sınaqdan keçirə və yüksək keyfiyyətli rəy toplaya bildik.
Davam etmək
Bir çoxlarımız üçün bu, bu miqyasda ilk layihədir. Biz komanda şəklində işləmək, memarlıq və dizayn qərarları verməklə bağlı bir sıra dəyərli dərslər öyrəndik. Az resursla mürəkkəb sistemləri necə inteqrasiya etmək və onları istehsala yaymaq olar.
Əlbəttə ki, həm kod baxımından, həm də sistem inteqrasiyasının interfeyslərində işləmək üçün bir şey var. Layihə kifayət qədər gəncdir, lakin biz onu etibarlı və rahat xidmətə çevirmək ambisiyalarımızla doluyuz.
Biz artıq sistemləri razı sala bilmişik. Bill öz şkafında hesablama, hesablaşma və istifadəçi sorğularını diqqətlə idarə edir. Volfram sahələrinin “sehrliliyi” bizi sabit rabitə ilə təmin edir. Və yalnız OpenStack bəzən şıltaq olur, "'WSREP hələ proqram istifadəsi üçün node hazırlamayıb" kimi bir şey qışqırır. Amma bu tamam başqa hekayədir...
Bu yaxınlarda xidməti istifadəyə verdik.
Bütün təfərrüatları səhifəmizdə öyrənə bilərsiniz .
CLO inkişaf qrupu
Faydalı linklər
OpenStack
Volfram parça
Mənbə: www.habr.com