Bloqumuza texniki direktorumuzun son çıxışlarına əsaslanan nəşrlərlə başlayacağıq (Dmitri Stolyarov). Onların hamısı 2016-cı ildə müxtəlif peşəkar tədbirlərdə baş tutub və DevOps və Docker mövzusuna həsr olunub. Badoo ofisində Docker Moskva görüşündən bir video, bizdə artıq var Onlayn. Yeniləri hesabatların mahiyyətini çatdıran məqalələrlə müşayiət olunacaq. Belə ki…
31 may konfransında , “Rus İnternet Texnologiyaları” (RIT++ 2016) festivalı çərçivəsində keçirilən “Davamlı yerləşdirmə və yerləşdirmə” bölməsi “Docker ilə davamlı çatdırılmanın ən yaxşı təcrübələri” hesabatı ilə açıldı. O, Docker və digər Açıq Mənbə məhsullarından istifadə edərək Davamlı Çatdırılma (CD) prosesinin qurulması üçün ən yaxşı təcrübələri ümumiləşdirdi və sistemləşdirdi. Biz istehsalatda bu həllərlə işləyirik ki, bu da bizə praktik təcrübəyə güvənməyə imkan verir.
Bir saat sərf etmək imkanınız varsa , tam olaraq izləməyi tövsiyə edirik. Əks halda, mətn şəklində əsas xülasə aşağıdadır.
Docker ilə Davamlı Çatdırılma
Altında Davamlı Çatdırılma hadisələr zəncirini başa düşürük ki, bunun nəticəsində Git deposundan tətbiq kodu əvvəlcə istehsala gəlir, sonra isə arxivə daxil olur. Bu belə görünür: Git → Yarat → Test → Buraxıl → İşlət.
Hesabatın çox hissəsi qurma mərhələsinə (tətbiq montajı) həsr olunub və buraxılış və fəaliyyət göstərən mövzulara qısaca toxunulub. Onları həll etməyə imkan verən problemlər və nümunələr haqqında danışacağıq və bu nümunələrin xüsusi tətbiqləri fərqli ola bilər.
Docker ümumiyyətlə burada niyə lazımdır? Bu Açıq Mənbə aləti kontekstində Davamlı Çatdırılma təcrübələri haqqında danışmaq qərarına gəlməyimiz əbəs deyil. Bütün hesabat onun istifadəsinə həsr olunsa da, tətbiq kodunun yayılmasının əsas nümunəsini nəzərdən keçirərkən bir çox səbəblər aşkar edilir.
Əsas yayma nümunəsi
Beləliklə, tətbiqin yeni versiyalarını təqdim edərkən, şübhəsiz ki, qarşılaşırıq dayanma problemi, istehsal serverinin keçidi zamanı yaranır. Tətbiqin köhnə versiyasından yenisinə trafik dərhal keçə bilməz: əvvəlcə yeni versiyanın yalnız uğurla yükləndiyinə deyil, həm də "istidildiyinə" əmin olmalıyıq (yəni, sorğulara xidmət etməyə tamamilə hazırdır).
Beləliklə, bir müddət tətbiqin hər iki versiyası (köhnə və yeni) eyni vaxtda işləyəcək. Hansı ki, avtomatik olaraq gətirib çıxarır paylaşılan resurs münaqişəsi: şəbəkə, fayl sistemi, IPC və s. Docker ilə bu problem, eyni host (server/virtual maşın) daxilində resursun izolyasiyasına zəmanət verilən ayrı-ayrı konteynerlərdə tətbiqin müxtəlif versiyalarını işlətməklə asanlıqla həll olunur. Əlbəttə ki, heç bir izolyasiya olmadan bəzi hiylələrlə əldə edə bilərsiniz, amma hazır və rahat bir vasitə varsa, əks səbəb var - onu laqeyd etməmək.
Konteynerləşdirmə yerləşdirildikdə bir çox başqa üstünlüklər təmin edir. İstənilən tətbiqdən asılıdır xüsusi versiya (və ya versiya diapazonu) tərcüməçi, modulların/uzantıların və s., eləcə də onların versiyalarının mövcudluğu. Və bu, yalnız dərhal icra edilə bilən mühitə deyil, həm də daxil olmaqla bütün ətraf mühitə aiddir sistem proqram təminatı və onun versiyası (istifadə olunan Linux paylanmasına qədər). Konteynerlərdə təkcə proqram kodu deyil, həm də əvvəlcədən quraşdırılmış sistem və tələb olunan versiyaların tətbiqi proqramları olduğu üçün siz asılılıqlarla bağlı problemləri unuda bilərsiniz.
Gəlin ümumiləşdirək əsas buraxılış nümunəsi aşağıdakı amillər nəzərə alınmaqla yeni versiyalar:
- Əvvəlcə tətbiqin köhnə versiyası birinci konteynerdə işləyir.
- Sonra yeni versiya yuvarlanır və ikinci konteynerdə "qızdırılır". Maraqlıdır ki, bu yeni versiyanın özü təkcə yenilənmiş proqram kodunu deyil, həm də onun hər hansı asılılığını, həmçinin sistem komponentlərini (məsələn, OpenSSL-in yeni versiyası və ya bütün paylama) daşıya bilər.
- Yeni versiya sorğulara xidmət etməyə tam hazır olduqda, trafik birinci konteynerdən ikinciyə keçir.
- Köhnə versiya indi dayandırıla bilər.
Tətbiqin müxtəlif versiyalarını ayrı-ayrı konteynerlərdə yerləşdirməyə bu yanaşma başqa bir rahatlıq təmin edir - sürətli geri dönmə köhnə versiyaya (axı, trafiki istədiyiniz konteynerə keçirmək kifayətdir).
Son ilk tövsiyə hətta kapitanın belə səhv tapa bilmədiyi bir şey kimi səslənir: "[Docker ilə Davamlı Çatdırılma təşkil edərkən] Docker istifadə edin [və bunun nə verdiyini anlayın]" Unutmayın ki, bu, hər problemi həll edəcək bir gümüş güllə deyil, gözəl bir təməl təmin edən bir vasitədir.
Təkrarlanma qabiliyyəti
“Reproduktivlik” dedikdə, proqramları işləyərkən rast gəlinən ümumiləşdirilmiş problemləri nəzərdə tuturuq. Belə hallardan danışırıq:
- Keyfiyyət şöbəsi tərəfindən səhnələşdirmə üçün yoxlanılan skriptlər istehsalda dəqiq şəkildə təkrarlanmalıdır.
- Proqramlar müxtəlif depo güzgülərindən paketləri qəbul edə bilən serverlərdə dərc olunur (zamanla onlar yenilənir və onlarla birlikdə quraşdırılmış proqramların versiyaları).
- "Yerli olaraq hər şey mənim üçün işləyir!" (...və tərtibatçılara istehsala icazə verilmir.)
- Köhnə (arxivləşdirilmiş) versiyada nəyisə yoxlamaq lazımdır.
- ...
Onların ümumi mahiyyəti ondan ibarətdir ki, istifadə olunan mühitlərə tam uyğunluq (həmçinin insan amilinin olmaması) zəruridir. Təkrarlanmaya necə zəmanət verə bilərik? Docker şəkilləri yaradın Git-dən kod əsasında və sonra onları istənilən tapşırıq üçün istifadə edin: test saytlarında, istehsalda, proqramçıların yerli maşınlarında... Eyni zamanda, həyata keçirilən hərəkətləri minimuma endirmək vacibdir. sonra şəklin yığılması: nə qədər sadədirsə, səhvlərin olma ehtimalı bir o qədər azdır.
İnfrastruktur koddur
İnfrastruktur tələbləri (server proqram təminatının mövcudluğu, onun versiyası və s.) rəsmiləşdirilməmiş və “proqramlaşdırılmış” deyilsə, hər hansı proqram yeniləməsinin yayılması fəlakətli nəticələrlə nəticələnə bilər. Məsələn, səhnələşdirmə zamanı siz artıq PHP 7.0-a keçmisiniz və kodu müvafiq olaraq yenidən yazmısınız - onda onun bəzi köhnə PHP (5.5) ilə istehsalda görünməsi şübhəsiz kiməsə təəccüblənəcək. Tərcüməçi versiyasında böyük bir dəyişikliyi unutmaya bilərsiniz, amma "şeytan təfərrüatlardadır": sürpriz hər hansı bir asılılığın kiçik bir yeniləməsində ola bilər.
Bu problemi həll etmək üçün bir yanaşma kimi tanınır IaC (Infrastructure as Code, “infrastructure as code”) və proqram kodu ilə birlikdə infrastruktur tələblərinin saxlanmasını nəzərdə tutur. Bundan istifadə edərək, tərtibatçılar və DevOps mütəxəssisləri eyni Git proqram repozitoriyası ilə işləyə bilər, lakin onun müxtəlif hissələrində. Bu koddan Git-də Docker təsviri yaradılır, burada tətbiq infrastrukturun bütün xüsusiyyətləri nəzərə alınmaqla yerləşdirilir. Sadə dillə desək, şəkillərin yığılması üçün skriptlər (qaydalar) mənbə kodu ilə eyni depoda olmalı və bir-birinə birləşdirilməlidir.
Çox qatlı proqram arxitekturası vəziyyətində - məsələn, artıq Docker konteynerində işləyən tətbiqin qarşısında duran nginx var - Docker şəkilləri hər bir təbəqə üçün Git-də koddan yaradılmalıdır. Sonra birinci təsvirdə tərcüməçi və digər “yaxın” asılılıqlar olan proqram, ikinci şəkil isə yuxarı nginx-dən ibarət olacaq.
Docker şəkilləri, Git ilə əlaqə
Git-dən toplanmış bütün Docker şəkillərini iki kateqoriyaya ayırırıq: müvəqqəti və buraxılış. Müvəqqəti şəkillər Git-də filialın adı ilə işarələnmiş, növbəti öhdəliyin üzərinə yazıla bilər və yalnız önizləmə üçün təqdim olunur (istehsal üçün deyil). Bu, onların buraxılışlardan əsas fərqidir: onlarda hansı xüsusi öhdəlik olduğunu heç vaxt bilmirsiniz.
Müvəqqəti şəkillərə toplamaq mənasızdır: master filialı (masterin cari versiyasını daim görmək üçün onu avtomatik olaraq ayrıca sayta köçürə bilərsiniz), buraxılışları olan filiallar, xüsusi yeniliklərin filialları.
Müvəqqəti şəkillərə baxışdan sonra istehsala tərcümə ehtiyacı yaranır, tərtibatçılar müəyyən bir etiket qoyurlar. Avtomatik olaraq etiketlə toplanır şəkli buraxın (onun etiketi Git-dən olan etiketə uyğundur) və səhnələşdirməyə çıxarılır. Keyfiyyət şöbəsi tərəfindən uğurla yoxlanılırsa, istehsala gedir.
dapp
Təsvir edilən hər şey (çəkiliş, təsvirin yığılması, sonrakı texniki xidmət) Bash skriptləri və digər "doğrulanmış" vasitələrdən istifadə edərək müstəqil şəkildə həyata keçirilə bilər. Ancaq bunu etsəniz, nə vaxtsa həyata keçirilməsi böyük mürəkkəbliyə və zəif nəzarətə səbəb olacaqdır. Bunu başa düşərək, biz CI/CD yaratmaq üçün öz xüsusi iş axını yardım proqramını yaratmağa gəldik - dapp.
Onun mənbə kodu Ruby-də yazılır, açıq mənbə və dərc olunur . Təəssüf ki, sənədləşdirmə hazırda alətin ən zəif nöqtəsidir, lakin biz bunun üzərində işləyirik. Və biz dapp haqqında bir dəfədən çox yazıb danışacağıq, çünki... Biz səmimi şəkildə onun imkanlarını bütün maraqlı icma ilə bölüşmək üçün səbirsizlənirik, lakin bu vaxt problemlərinizi göndərin və sorğularınızı göndərin və/yaxud GitHub-da layihənin inkişafını izləyin.
13 avqust 2019-cu il tarixində yenilənib: hazırda layihədir dapp olaraq adlandırıldı , onun kodu Go-da tamamilə yenidən yazılmış və sənədləri əhəmiyyətli dərəcədə təkmilləşdirilmişdir.
Kubernetes
Peşəkar mühitdə artıq əhəmiyyətli dərəcədə tanınan başqa bir hazır Açıq Mənbə alətidir Kubernetes, Docker idarəetmə klasteri. Docker-də qurulmuş layihələrin işində onun istifadəsi mövzusu hesabatın əhatə dairəsindən kənardadır, buna görə də təqdimat bəzi maraqlı xüsusiyyətlərin icmalı ilə məhdudlaşır.
Yayım üçün Kubernetes təklif edir:
- hazırlıq zondu — tətbiqin yeni versiyasının hazırlığının yoxlanılması (trafiği ona keçmək üçün);
- yuvarlanan yeniləmə - konteynerlər çoxluğunda ardıcıl görüntü yeniləməsi (bağlama, yeniləmə, işə salınmağa hazırlıq, trafikin dəyişdirilməsi);
- sinxron yeniləmə - fərqli bir yanaşma ilə bir çoxluqdakı bir görüntünün yenilənməsi: əvvəlcə konteynerlərin yarısında, sonra qalan hissəsində;
- kanareyka buraxılışları - anomaliyaları izləmək üçün məhdud (kiçik) sayda konteynerdə yeni təsvirin işə salınması.
Davamlı Çatdırılma təkcə yeni versiyanın buraxılışı olmadığı üçün Kubernetes infrastrukturun sonrakı təmiri üçün bir sıra imkanlara malikdir: bütün konteynerlər üçün quraşdırılmış monitorinq və giriş, avtomatik miqyaslama və s. Bütün bunlar artıq işləyir və sadəcə lazımi vaxtı gözləyir. proseslərinizdə tətbiq.
Yekun tövsiyələr
- Docker istifadə edin.
- Bütün ehtiyaclarınız üçün tətbiqlərin Docker şəkillərini yaradın.
- “İnfrastruktur koddur” prinsipinə əməl edin.
- Git-i Docker ilə əlaqələndirin.
- Yayım sırasını tənzimləyin.
- Hazır platformadan istifadə edin (Kubernetes və ya başqa).
Videolar və slaydlar
Tamaşadan video (təxminən bir saat) (hesabatın özü 5-ci dəqiqədən başlayır - bu andan oynamaq üçün keçidə daxil olun).
Hesabat təqdimatı:
PS
Bloqumuzda mövzu ilə bağlı digər hesabatlar:
- «» (Dmitri Stolyarov; 27 may 2019-cu il DevOpsConf-da);
- «» (Dmitri Stolyarov; 8 noyabr 2018-ci il HighLoad++ ilə);
- «» (Dmitri Stolyarov; 7 noyabr 2017-ci il HighLoad++ ilə);
- «» (Dmitri Stolyarov; 6 iyun 2017-ci ildə RootConf-da).
Mənbə: www.habr.com