Skriptlərdən öz platformamıza: CIAN-da inkişafı necə avtomatlaşdırdıq

RIT 2019-da həmkarımız Alexander Korotkov etdi hesabat CIAN-da inkişafın avtomatlaşdırılması haqqında: həyatı və işi sadələşdirmək üçün biz öz Integro platformamızdan istifadə edirik. O, tapşırıqların həyat dövrünü izləyir, tərtibatçıları adi əməliyyatlardan azad edir və istehsalda səhvlərin sayını əhəmiyyətli dərəcədə azaldır. Bu yazıda biz İskəndərin hesabatını tamamlayacağıq və sadə skriptlərdən açıq mənbəli məhsulları öz platformamız vasitəsilə birləşdirməyə necə keçdiyimizi və ayrıca avtomatlaşdırma komandamızın nə etdiyini sizə xəbər verəcəyik.
 

Sıfır səviyyə

“Sıfır səviyyə deyə bir şey yoxdur, mən belə bir şey bilmirəm”
"Kung Fu Panda" filmindən usta Şifu

CIAN-da avtomatlaşdırma şirkət qurulduqdan 14 il sonra başladı. O zaman inkişaf komandasında 35 nəfər var idi. İnanmaq çətindir, elə deyilmi? Əlbəttə ki, avtomatlaşdırma müəyyən formada mövcud idi, lakin 2015-ci ildə davamlı inteqrasiya və kodun çatdırılması üçün ayrıca bir istiqamət formalaşmağa başladı. 

O zaman bizdə Linux/Windows serverlərində yerləşdirilmiş böyük Python, C# və PHP monolitinə malik idik. Bu canavarı yerləşdirmək üçün əllə işlətdiyimiz bir sıra skriptlərimiz var idi. Budaqları birləşdirərkən, qüsurları düzəltməkdə və "tikintidə fərqli tapşırıqlar dəsti ilə" yenidən qurarkən münaqişələr səbəbindən ağrı və iztirab gətirən monolitin montajı da var idi. Sadələşdirilmiş proses belə görünürdü:

Biz bundan məmnun deyildik və təkrarlana bilən, avtomatlaşdırılmış və idarə oluna bilən qurma və yerləşdirmə prosesi qurmaq istədik. Bunun üçün bizə CI/CD sistemi lazım idi və biz Teamcity-nin pulsuz versiyası ilə Jenkins-in pulsuz versiyası arasında seçim etdik, çünki onlarla işlədik və funksiyalar dəsti baxımından hər ikisi bizə uyğun gəlirdi. Biz daha yeni bir məhsul olaraq Teamcity-ni seçdik. O zaman biz hələ mikroservis arxitekturasından istifadə etməmişdik və çoxlu sayda tapşırıq və layihələr gözləmirdik.

Biz öz sistemimizin ideyasına gəlirik

Teamcity-nin tətbiqi əl işinin yalnız bir hissəsini aradan qaldırdı: Pull Sorğularının yaradılması, Jira-da statusa görə məsələlərin təşviqi və buraxılış üçün məsələlərin seçilməsi qalır. Teamcity sistemi artıq bunun öhdəsindən gələ bilməzdi. Gələcək avtomatlaşdırma yolunu seçmək lazım idi. Teamcity-də skriptlərlə işləmək və ya üçüncü tərəfin avtomatlaşdırma sistemlərinə keçmək variantlarını nəzərdən keçirdik. Ancaq sonda qərara gəldik ki, bizə maksimum çeviklik lazımdır, bunu yalnız öz həllimiz təmin edə bilər. Integro adlı daxili avtomatlaşdırma sisteminin ilk versiyası belə ortaya çıxdı.

Teamcity qurma və yerləşdirmə proseslərinin işə salınması səviyyəsində avtomatlaşdırma ilə məşğul olur, Integro isə inkişaf proseslərinin yüksək səviyyəli avtomatlaşdırılmasına diqqət yetirir. Bitbucket-də əlaqəli mənbə kodunun işlənməsi ilə Jira-dakı məsələlərlə işi birləşdirmək lazım idi. Bu mərhələdə Integro müxtəlif növ tapşırıqlarla işləmək üçün öz iş axınlarına sahib olmağa başladı. 

Biznes proseslərində avtomatlaşdırmanın artması ilə əlaqədar Teamcity-də layihələrin və qaçışların sayı artıb. Beləliklə, yeni bir problem ortaya çıxdı: bir pulsuz Teamcity nümunəsi kifayət etmədi (3 agent və 100 layihə), biz başqa bir nümunə əlavə etdik (daha 3 agent və 100 layihə), sonra başqa. Nəticədə, idarə etmək çətin olan bir neçə klasterdən ibarət bir sistem əldə etdik:

4-cü instansiya sualı ortaya çıxanda başa düşdük ki, biz belə yaşamağa davam edə bilməyəcəyik, çünki 4 instansiyanın dəstəklənməsi üçün ümumi xərclər artıq heç bir məhdudiyyət daxilində deyildi. Ödənişli Teamcity almaq və ya pulsuz Jenkins seçməklə bağlı sual yarandı. Nümunələr və avtomatlaşdırma planları üzərində hesablamalar apardıq və Jenkins üzərində yaşayacağımıza qərar verdik. Bir neçə həftədən sonra biz Jenkins-ə keçdik və çoxsaylı Teamcity instansiyalarının saxlanması ilə bağlı baş ağrılarının bir hissəsini aradan qaldırdıq. Buna görə də, Integro-nu inkişaf etdirməyə və Jenkins-i özümüz üçün fərdiləşdirməyə diqqət yetirə bildik.

Əsas avtomatlaşdırmanın böyüməsi ilə (Çəkmə İstəklərinin avtomatik yaradılması, Kod əhatəsinin toplanması və nəşri və digər yoxlamalar şəklində) əl ilə buraxılışlardan mümkün qədər imtina etmək və bu işi robotlara vermək güclü istək var. Bundan əlavə, şirkət tez-tez buraxılış tələb edən şirkət daxilində və bir-birindən ayrı olaraq mikroservislərə keçməyə başladı. Beləliklə, biz tədricən mikroservislərimizin avtomatik buraxılışlarına gəldik (biz hazırda prosesin mürəkkəbliyinə görə monoliti əl ilə buraxırıq). Ancaq həmişə olduğu kimi, yeni bir mürəkkəblik yarandı. 

Testi avtomatlaşdırırıq

Buraxılışların avtomatlaşdırılması sayəsində bəzi sınaq mərhələlərinin atlanması səbəbindən inkişaf prosesləri sürətləndi. Bu da keyfiyyətin müvəqqəti itkisinə səbəb oldu. Bu, mənasız səslənir, lakin buraxılışların sürətlənməsi ilə yanaşı, məhsulun inkişaf metodologiyasını dəyişdirmək lazım idi. Testin avtomatlaşdırılması, buraxılmış kod və ondakı səhvlərə görə tərtibatçının şəxsi məsuliyyətini (burada söhbət pul cərimələrindən deyil, “fikri başda qəbul etməkdən” gedir) aşılamaq, habelə qərar vermək barədə düşünmək lazım idi. avtomatik yerləşdirmə vasitəsilə tapşırığı buraxın/buraxmayın. 

Keyfiyyət problemlərini aradan qaldıraraq iki vacib qərara gəldik: kanareyka testini aparmağa başladıq və səhv fonunun artıqlığına avtomatik cavab verməklə avtomatik monitorinqini tətbiq etdik. Birinci həll kodun istehsala tam buraxılmasından əvvəl aşkar səhvləri tapmağa imkan verdi, ikincisi istehsaldakı problemlərə cavab müddətini azaldıb. Səhvlər, əlbəttə ki, olur, lakin biz vaxtımızın və səyimizin çoxunu onları düzəltməyə deyil, minimuma endirməyə sərf edirik. 

Avtomatlaşdırma qrupu

Hazırda 130 tərtibatçıdan ibarət heyətimiz var və biz davam edirik böyümək. Davamlı inteqrasiya və kodun çatdırılması üzrə komanda (bundan sonra Yerləşdirmə və İnteqrasiya və ya DI komandası adlandırılacaq) 7 nəfərdən ibarətdir və 2 istiqamətdə işləyir: Integro avtomatlaşdırma platformasının və DevOps-un inkişafı. 

DevOps CIAN saytının Dev/Beta mühitinə, Integro mühitinə cavabdehdir, tərtibatçılara problemləri həll etməyə kömək edir və mühitlərin miqyasına yeni yanaşmalar hazırlayır. Integro inkişaf istiqaməti həm Integro-nun özü, həm də əlaqəli xidmətlərlə, məsələn, Jenkins, Jira, Confluence üçün plaginlərlə məşğul olur, həmçinin inkişaf qrupları üçün köməkçi kommunal və proqramlar hazırlayır. 

DI komandası daxili olaraq memarlıq, kitabxanalar və inkişaf yanaşmalarını inkişaf etdirən Platforma komandası ilə əməkdaşlıq edir. Eyni zamanda, CIAN daxilindəki istənilən tərtibatçı avtomatlaşdırmaya öz töhfəsini verə bilər, məsələn, komandanın ehtiyaclarına uyğun olaraq mikro avtomatlaşdırma edə bilər və ya avtomatlaşdırmanın daha da yaxşılaşdırılmasına dair gözəl ideyanı paylaşa bilər.

CIAN-da avtomatlaşdırmanın təbəqə tortu

Avtomatlaşdırmada iştirak edən bütün sistemləri bir neçə təbəqəyə bölmək olar:

1. Xarici sistemlər (Jira, Bitbucket və s.). İnkişaf qrupları onlarla işləyir.
2. Integro platforması. Çox vaxt tərtibatçılar onunla birbaşa işləmir, lakin bütün avtomatlaşdırmanın işləməsini təmin edən budur.
3. Çatdırılma, orkestrləşdirmə və kəşf xidmətləri (məsələn, Jeknins, Consul, Nomad). Onların köməyi ilə biz serverlərdə kodu yerləşdiririk və xidmətlərin bir-biri ilə işləməsini təmin edirik.
4. Fiziki səviyyə (serverlər, OS, əlaqəli proqram təminatı). Kodumuz bu səviyyədə işləyir. Bu ya fiziki server, ya da virtual server ola bilər (LXC, KVM, Docker).

Bu konsepsiya əsasında biz DI komandası daxilində məsuliyyət sahələrini bölürük. İlk iki səviyyə Integro inkişaf istiqamətinin məsuliyyəti sahəsində, son iki səviyyə isə artıq DevOps-un məsuliyyəti sahəsindədir. Bu ayrılma bizə tapşırıqlara diqqət yetirməyə imkan verir və qarşılıqlı əlaqəyə mane olmur, çünki biz bir-birimizə yaxınıq və daim bilik və təcrübə mübadiləsi aparırıq.

Bütöv

Gəlin diqqəti Integroya yönəldək və texnologiya yığını ilə başlayaq:

• CentOS 7
• Docker + Nomad + Konsul + Vault
• Java 11 (köhnə Integro monolit Java 8-də qalacaq)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• RabbitMQ 
• Apache Ignite
• Camunda (quraşdırılmış)
• Grafana + Qrafit + Prometey + Jaeger + ELK
• Veb UI: Reaksiya (CSR) + MobX
• SSO: Açar paltarı

Integro-nun ilkin versiyasının monolit şəklində mirasımız olmasına baxmayaraq, biz mikroservis inkişafı prinsipinə sadiqik. Hər bir mikroservis öz Docker konteynerində işləyir və xidmətlər HTTP sorğuları və RabbitMQ mesajları vasitəsilə bir-biri ilə əlaqə qurur. Mikroservislər Konsul vasitəsilə bir-birlərini tapır və SSO (Keycloak, OAuth 2/OpenID Connect) vasitəsilə icazə keçərək ona sorğu göndərirlər.

Real həyat nümunəsi olaraq, aşağıdakı addımlardan ibarət olan Jenkins ilə qarşılıqlı əlaqəni nəzərdən keçirin:

1. İş axınının idarə edilməsi mikroservisi (bundan sonra Flow mikroxidməti adlandırılacaq) Jenkins-də quruluşu işə salmaq istəyir. Bunun üçün o, Jenkins (bundan sonra Jenkins mikroservisi adlandırılacaq) ilə inteqrasiya üçün mikroservisin IP:PORT-unu tapmaq üçün Konsuldan istifadə edir və ona Jenkins-də qurmağa başlamaq üçün asinxron sorğu göndərir.
2. Sorğunu aldıqdan sonra Jenkins mikroservisi İş ID-si yaradır və ona cavab verir, bundan sonra işin nəticəsini müəyyən etmək üçün istifadə oluna bilər. Eyni zamanda, REST API çağırışı vasitəsilə Jenkins-də qurulmasını tetikler.
3. Jenkins qurmağı həyata keçirir və tamamlandıqdan sonra icra nəticələri ilə veb-qancanı Jenkins mikroservisinə göndərir.
4. Jenkins mikroservisi veb kancanı qəbul edərək sorğunun işlənməsinin başa çatması haqqında mesaj yaradır və icra nəticələrini ona əlavə edir. Yaradılmış mesaj RabbitMQ növbəsinə göndərilir.
5. RabbitMQ vasitəsilə dərc edilmiş mesaj Flow mikro xidmətinə çatır, o, sorğudan və qəbul edilən mesajdan İş ID-sini uyğunlaşdırmaqla öz tapşırığının işlənməsinin nəticəsini öyrənir.

İndi bir neçə qrupa bölünə bilən 30-a yaxın mikroservisimiz var:

1. Konfiqurasiyanın idarə edilməsi.
2. Məlumat və istifadəçilərlə qarşılıqlı əlaqə (messencerlər, poçt).
3. Mənbə kodu ilə işləmək.
4. Yerləşdirmə alətləri ilə inteqrasiya (jenkins, nomad, konsul və s.).
5. Monitorinq (buraxılışlar, səhvlər və s.).
6. Veb yardım proqramları (test mühitlərini idarə etmək, statistika toplamaq və s. üçün UI).
7. Tapşırıq izləyiciləri və oxşar sistemlərlə inteqrasiya.
8. Müxtəlif vəzifələr üçün iş axınının idarə edilməsi.

İş axını tapşırıqları

Integro tapşırığın həyat dövrü ilə əlaqəli fəaliyyətləri avtomatlaşdırır. Sadələşdirilmiş dillə desək, bir tapşırığın həyat dövrü Jira-da tapşırığın iş axını kimi başa düşüləcəkdir. İnkişaf proseslərimiz layihədən, tapşırığın növündən və müəyyən tapşırıqda seçilmiş seçimlərdən asılı olaraq bir neçə iş axını dəyişikliyinə malikdir. 

Ən çox istifadə etdiyimiz iş prosesinə baxaq:

Diaqramda dişli keçidin Integro tərəfindən avtomatik olaraq çağırıldığını, insan fiquru isə keçidin bir şəxs tərəfindən əl ilə çağırıldığını göstərir. Gəlin bu iş prosesində tapşırığın keçə biləcəyi bir neçə yola baxaq.

DEV+BETA-da kanareyka testləri olmadan tamamilə əllə sınaq (adətən monoliti belə buraxırıq):

Digər keçid birləşmələri də ola bilər. Bəzən problemin keçəcəyi yol Jira-dakı seçimlər vasitəsilə seçilə bilər.

Tapşırıq hərəkəti

Tapşırıq “DEV Testi + Canary Tests” iş prosesindən keçərkən yerinə yetirilən əsas addımlara nəzər salaq:

1. Tərtibatçı və ya PM tapşırığı yaradır.

2. Tərtibatçı işləmək üçün tapşırığı götürür. Tamamlandıqdan sonra o, ŞƏRHLƏR vəziyyətinə keçir.

3. Jira Jira mikroservisinə Webhook göndərir (Jira ilə inteqrasiyaya cavabdehdir).

4. Jira mikroservisi iş axınına başlamaq üçün Flow xidmətinə (işin yerinə yetirildiyi daxili iş axınlarına cavabdehdir) sorğu göndərir.

5. Flow xidmətinin daxilində:

• Rəyçilər tapşırığa təyin edilir (İstifadəçilər haqqında hər şeyi bilən mikroservis + Jira mikroservisi).
• Mənbə mikroservisi vasitəsilə (repozitoriyalar və filiallar haqqında bilir, lakin kodun özü ilə işləmir) məsələmizin bir qolunu ehtiva edən depolar üçün axtarış aparılır (axtarışı sadələşdirmək üçün filialın adı məsələ ilə üst-üstə düşür Jiradakı nömrə). Çox vaxt tapşırığın bir depoda yalnız bir filialı olur; bu, yerləşdirmə növbəsinin idarə edilməsini asanlaşdırır və depolar arasında əlaqəni azaldır.
• Tapılan hər bir filial üçün aşağıdakı hərəkətlər ardıcıllığı yerinə yetirilir:

  i) Əsas filialın yenilənməsi (kodla işləmək üçün Git mikroservisi).
  ii) Filial tərtibatçı tərəfindən dəyişikliklərdən bloklanır (Bitbucket mikroservisi).
  iii) Bu filial üçün Pull Sorğu yaradılır (Bitbucket mikroservisi).
  iv) Tərtibatçı çatlarına yeni Pull Sorğu haqqında mesaj göndərilir (Bildirişlərlə işləmək üçün mikroservisə bildirin).
  v) DEV-də (Jenkins ilə işləmək üçün Jenkins mikroservisi) tapşırıqların qurulması, sınaqdan keçirilməsi və yerləşdirilməsi işə salınır.
  vi) Əgər bütün əvvəlki addımlar uğurla tamamlanıbsa, onda Integro Təsdiqini Pull Sorğuda (Bitbucket mikroservisi) qoyur.

• Integro təyin edilmiş rəyçilərdən Pull Sorğunun Təsdiqini gözləyir.
• Bütün lazımi təsdiqlər alındıqdan sonra (o cümlədən avtomatlaşdırılmış testlər müsbət keçdi), Integro tapşırığı Dev üzərində Test (Jira mikroservisi) statusuna köçürür.

6. Sınaqçılar tapşırığı sınaqdan keçirirlər. Heç bir problem yoxdursa, tapşırıq Quraşdırılmaya Hazır statusuna keçirilir.

7. Integro tapşırığın buraxılmağa hazır olduğunu “görür” və onu kanareyka rejimində (Jenkins mikroservisi) yerləşdirməyə başlayır. Buraxılış üçün hazırlıq bir sıra qaydalarla müəyyən edilir. Məsələn, tapşırıq tələb olunan vəziyyətdədir, digər tapşırıqlarda heç bir kilid yoxdur, hazırda bu mikroservisin aktiv yükləmələri yoxdur və s.

8. Tapşırıq Canary statusuna köçürülür (Jira mikroservisi).

9. Cenkins Kanar rejimində (adətən 1-3 instansiya) Nomad vasitəsilə yerləşdirmə tapşırığını işə salır və yerləşdirmə haqqında buraxılış monitorinqi xidmətini (DeployWatch mikroservisi) xəbərdar edir.

10. DeployWatch mikroservisi xətanın fonunu toplayır və lazım gəldikdə ona reaksiya verir. Səhv fonu keçərsə (fon norması avtomatik olaraq hesablanır), tərtibatçılara Notify mikroservisi vasitəsilə məlumat verilir. Əgər 5 dəqiqədən sonra tərtibatçı cavab vermədisə (Geri Dön və ya Qalın düyməsini klikləyin), o zaman kanareyka nümunələrinin avtomatik geri qaytarılması işə salınır. Əgər fon həddi keçmirsə, onda tərtibatçı tapşırığın yerləşdirilməsini İstehsalda əl ilə işə salmalıdır (UI-də düyməni klikləməklə). Əgər 60 dəqiqə ərzində tərtibatçı istehsala yerləşdirməni başlamazsa, o zaman təhlükəsizlik səbəbi ilə kanareyka nümunələri də geri çəkiləcək.

11. İstehsalata yerləşdirmə işə salındıqdan sonra:

• Tapşırıq İstehsal statusuna (Jira mikroservisi) köçürülür.
• Jenkins mikroservisi yerləşdirmə prosesinə başlayır və DeployWatch mikroservisinə yerləşdirmə haqqında məlumat verir.
• DeployWatch mikroxidməti İstehsaldakı bütün konteynerlərin yeniləndiyini yoxlayır (hamının yenilənmədiyi hallar olub).
• Notify mikroxidməti vasitəsilə yerləşdirmənin nəticələri haqqında bildiriş İstehsalata göndərilir.

12. Yanlış mikroservis davranışı aşkar edilərsə, tərtibatçılara tapşırığı İstehsaldan geri qaytarmağa başlamaq üçün 30 dəqiqə vaxtı olacaq. Bu müddətdən sonra tapşırıq avtomatik olaraq master (Git microservice) ilə birləşdiriləcək.

13. Ustada uğurlu birləşmədən sonra tapşırıq statusu Qapalı (Jira mikroservisi) olaraq dəyişdiriləcək.

Diaqram özünü tam təfərrüatlı kimi göstərmir (əslində daha çox addımlar var), lakin proseslərə inteqrasiya dərəcəsini qiymətləndirməyə imkan verir. Biz bu sxemi ideal hesab etmirik və avtomatik buraxılış və yerləşdirmə dəstəyi proseslərini təkmilləşdiririk.

Nədir?

Avtomatlaşdırmanın inkişafı üçün böyük planlarımız var, məsələn, monolit buraxılışları zamanı əl əməliyyatlarının aradan qaldırılması, avtomatik yerləşdirmə zamanı monitorinqin təkmilləşdirilməsi və tərtibatçılarla qarşılıqlı əlaqənin yaxşılaşdırılması.

Ancaq hələlik burada dayanaq. Avtomatlaşdırma icmalında bir çox mövzuları səthi əhatə etdik, bəzilərinə ümumiyyətlə toxunulmadı, ona görə də suallara cavab verməkdən məmnun olarıq. Nəyi ətraflı əhatə edəcəyimiz barədə təkliflər gözləyirik, şərhlərdə yazın.

Mənbə: www.habr.com