Inventos-dan Alexander Sigachevin "Docker + Gitlab CI ilə inkişaf və sınaq prosesi" hesabatının stenoqramını oxumağı təklif edirəm.
Docker + Gitlab CI əsasında inkişaf və sınaq prosesini yenicə həyata keçirməyə başlayanlar tez-tez əsas suallar verirlər. Haradan başlamaq lazımdır? Necə təşkil etmək olar? Necə test etmək olar?
Bu hesabat yaxşıdır, çünki Docker və Gitlab CI istifadə edərək inkişaf və sınaq prosesi haqqında strukturlaşdırılmış şəkildə danışır. Hesabatın özü 2017-ci ilə aiddir. Düşünürəm ki, bu hesabatdan siz əsasları, metodologiyanı, ideyanı, istifadə təcrübəsini öyrənə bilərsiniz.
Kimin vecinə deyil, zəhmət olmasa pişiyin altında.
Mənim adım Alexander Sigachev. Mən Inventos üçün işləyirəm. Mən sizə Docker-dən istifadə təcrübəmdən və onu şirkətdəki layihələrdə tədricən necə tətbiq etdiyimizdən danışacağam.
Təqdimat mövzusu: Docker və Gitlab CI istifadə edərək inkişaf prosesi.
Bu mənim Docker haqqında ikinci söhbətimdir. İlk hesabat zamanı biz yalnız Developer maşınlarında Docker in Development istifadə etdik. Docker-dən istifadə edən işçilərin sayı təxminən 2-3 nəfər idi. Yavaş-yavaş təcrübə toplandı və bir az da irəli getdik. Linkimizə .
Bu hesabatda nə olacaq? Hansı dırmıq topladığımız, hansı problemləri həll etdiyimiz barədə təcrübəmizi bölüşəcəyik. Hər yerdə gözəl deyildi, amma irəliləməyə icazə verildi.
Şüarımız budur: əlimizə çata biləcəyimiz hər şeyi yerləşdirin.
Hansı problemləri həll edirik?
Şirkətdə bir neçə komanda olduqda, proqramçı ortaq resursdur. Elə mərhələlər var ki, bir proqramçı bir layihədən çıxarılır və bir müddət başqa bir layihəyə verilir.
Proqramçının tez başa düşməsi üçün layihənin mənbə kodunu endirməli və ətraf mühiti mümkün qədər tez işə salmalıdır ki, bu da ona bu layihənin problemlərinin həllində daha da irəliləməyə imkan verəcəkdir.
Adətən, sıfırdan başlasanız, layihədə sənədləşmə çox azdır. Necə qurulacağına dair məlumat yalnız köhnə istifadəçilər üçün mövcuddur. İşçilər bir-iki günə öz iş yerlərini qururlar. Bunu sürətləndirmək üçün Docker-dən istifadə etdik.
Növbəti səbəb İnkişafda parametrlərin standartlaşdırılmasıdır. Təcrübəmə görə, tərtibatçılar həmişə təşəbbüs göstərirlər. Hər beşinci halda, xüsusi bir domen daxil edilir, məsələn, vasya.dev. Onun yanında domeni petya.dev olan qonşusu Petya oturur. Onlar bu domen adından istifadə edərək vebsayt və ya sistemin bəzi komponentlərini inkişaf etdirirlər.
Sistem böyüdükdə və bu domen adları konfiqurasiyaya daxil olmağa başlayanda, İnkişaf mühiti münaqişəsi yaranır və sayt yolu yenidən yazılır.
Eyni şey verilənlər bazası parametrləri ilə baş verir. Kimsə təhlükəsizliklə məşğul olmur və boş kök parolu ilə işləyir. Quraşdırma mərhələsində MySQL kimdənsə parol istədi və parol 123 oldu. Çox vaxt belə olur ki, verilənlər bazası konfiqurasiyası tərtibatçının öhdəliyindən asılı olaraq daim dəyişir. Kimsə düzəltdi, kimsə konfiqurasiyanı düzəltmədi. Bir növ test konfiqurasiyasını çıxaranda hiylələr oldu .gitignore və hər bir tərtibatçı verilənlər bazasını quraşdırmalı idi. Bu işə başlamağı çətinləşdirdi. Digər şeylər arasında verilənlər bazası haqqında xatırlamaq lazımdır. Verilənlər bazası işə salınmalı, parol daxil edilməli, istifadəçi qeydiyyatdan keçməli, cədvəl yaradılmalı və s.
Digər problem kitabxanaların müxtəlif versiyalarıdır. Tez-tez olur ki, tərtibatçı müxtəlif layihələrlə işləyir. Beş il əvvəl (2017-ci ildən - red. qeyd) başlayan Legacy layihəsi var. Başlanğıc zamanı biz MySQL 5.5 ilə başladıq. Müasir layihələr də var ki, biz MySQL-in daha müasir versiyalarını, məsələn, 5.7 və ya daha köhnə versiyalarını tətbiq etməyə çalışırıq (2017-ci ildə - red. qeyd)
MySQL ilə işləyən hər kəs bilir ki, bu kitabxanalar özləri ilə asılılıqlar gətirir. 2 bazanı birlikdə idarə etmək olduqca problemlidir. Ən azından köhnə müştərilər yeni verilənlər bazasına qoşulmaqda problemlidirlər. Bu da öz növbəsində bir sıra problemlər yaradır.
Növbəti problem, bir tərtibatçının yerli maşında işlədiyi zaman yerli resurslardan, yerli fayllardan, yerli RAM-dan istifadə edir. Problemlərin həlli zamanı bütün qarşılıqlı əlaqə onun bir maşında işləməsi çərçivəsində həyata keçirilir. Məsələn, İstehsal 3-də backend serverlərimiz var və tərtibatçı faylları kök kataloqda saxlayır və oradan nginx sorğuya cavab vermək üçün faylları götürür. Belə bir kod İstehsalata daxil olduqda, faylın 3 serverdən birində olduğu ortaya çıxır.
Mikroservislər istiqaməti hazırda inkişaf edir. Böyük tətbiqlərimizi bir-biri ilə qarşılıqlı əlaqədə olan bəzi kiçik komponentlərə böldükdə. Bu, müəyyən bir tapşırıq yığını üçün texnologiyaları seçməyə imkan verir. O, həmçinin tərtibatçılar arasında iş və məsuliyyətləri bölüşməyə imkan verir.
JS-də inkişaf edən Frondend-developer, Backend-ə demək olar ki, heç bir təsiri yoxdur. Backend developer, öz növbəsində, bizim vəziyyətimizdə, Ruby on Rails-i inkişaf etdirir və Frondend-ə müdaxilə etmir. Qarşılıqlı əlaqə API istifadə edərək həyata keçirilir.
Bonus olaraq, Docker-in köməyi ilə biz Staging-də resursları təkrar emal edə bildik. Hər bir layihə öz xüsusiyyətlərinə görə müəyyən parametrlər tələb edirdi. Fiziki olaraq, ya virtual server ayırmaq və onları ayrıca konfiqurasiya etmək, ya da kitabxanaların versiyasından asılı olaraq bir-birinə təsir edə biləcək bir növ dəyişən mühiti və layihələri paylaşmaq lazım idi.
Alətlər. Nə istifadə edirik?
- Docker özü. Dockerfile bir tətbiqin asılılıqlarını təsvir edir.
- Docker-compose bir neçə Docker proqramlarımızı birləşdirən paketdir.
- Mənbə kodunu saxlamaq üçün GitLab-dan istifadə edirik.
- Sistem inteqrasiyası üçün GitLab-CI istifadə edirik.
Hesabat iki hissədən ibarətdir.
Birinci hissədə Docker-in tərtibatçıların maşınlarında necə işlədilməsi haqqında danışılacaq.
İkinci hissə GitLab ilə necə qarşılıqlı əlaqə quracağımız, testləri necə həyata keçirdiyimiz və Staging-ə necə keçəcəyimiz haqqında danışacaq.
Docker lazımi komponentləri təsvir etməyə imkan verən texnologiyadır (deklarativ yanaşmadan istifadə etməklə). Bu Dockerfile nümunəsidir. Burada rəsmi Ruby:2.3.0 Docker təsvirindən miras qaldığımızı bildiririk. O, quraşdırılmış Ruby 2.3 versiyasını ehtiva edir. Biz tələb olunan qurma kitabxanalarını və NodeJS-ni quraşdırırıq. Bir kataloq yaratdığımızı təsvir edirik /app. Proqram qovluğunu işçi qovluğu kimi təyin edin. Bu kataloqda biz tələb olunan minimal Gemfile və Gemfile.lock yerləşdiririk. Sonra bu asılılıq şəklini quraşdıran layihələri qururuq. Biz konteynerin xarici port 3000-də dinləməyə hazır olacağını bildiririk. Sonuncu əmr bizim tətbiqimizi birbaşa işə salan əmrdir. Layihənin başlanğıc əmrini yerinə yetirsək, proqram müəyyən edilmiş əmri işə salmağa və işə salmağa çalışacaq.
Bu docker-compose faylının minimal nümunəsidir. Bu halda iki konteyner arasında əlaqənin olduğunu göstəririk. Bu, birbaşa verilənlər bazası xidmətinə və veb xidmətinə aiddir. Veb proqramlarımız əksər hallarda verilənlərin saxlanması üçün bir növ verilənlər bazası tələb edir. MySQL-dən istifadə etdiyimiz üçün misal MySQL-dədir - lakin heç bir başqa verilənlər bazasından (PostgreSQL, Redis) istifadə etməyimizə mane olmur.
Docker hub-dan rəsmi mənbədən MySQL 5.7.14 şəklini dəyişmədən götürürük. Veb tətbiqimizə cavabdeh olan şəkli cari kataloqdan toplayırıq. İlk buraxılış zamanı bizim üçün bir şəkil toplayır. Sonra burada icra etdiyimiz əmri işlədir. Geri dönsək, Puma vasitəsilə işə salma əmrinin müəyyən edildiyini görərik. Puma Ruby-də yazılmış bir xidmətdir. İkinci halda, biz üstələyirik. Bu əmr ehtiyaclarımızdan və ya tapşırıqlarımızdan asılı olaraq ixtiyari ola bilər.
Biz həmçinin inkişaf etdirici host maşınımızda konteyner portunda 3000-dən 3000-ə qədər bir portu yönləndirməmiz lazım olduğunu təsvir edirik. Bu, birbaşa Docker-ə daxil edilmiş iptables və onun mexanizmi ilə avtomatik olaraq həyata keçirilir.
Tərtibatçı, əvvəlki kimi, istənilən mövcud IP ünvanına daxil ola bilər, məsələn, 127.0.0.1 maşının yerli və ya xarici IP ünvanıdır.
Son sətir veb konteynerinin db konteynerindən asılı olduğunu söyləyir. Veb konteynerinin başlanğıcını çağırdığımız zaman docker-compose ilk olaraq bizim üçün verilənlər bazasını işə salacaq. Artıq verilənlər bazasının başlanğıcında (əslində, konteyner işə salındıqdan sonra! Bu, verilənlər bazasının hazırlığına zəmanət vermir) bizim arxa planımız olan tətbiqi işə salacaq.
Bu, verilənlər bazası açılmayan zaman xətaların qarşısını alır və verilənlər bazası konteynerini dayandırdıqda resurslara qənaət edir, beləliklə, digər layihələr üçün resursları azad edir.
Layihədə verilənlər bazası dokerizasiyasından istifadə etməyi bizə nə verir. Biz bütün tərtibatçılar üçün MySQL versiyasını düzəldirik. Bu, versiyalar fərqli olduqda, sintaksis, konfiqurasiya, standart parametrlər dəyişdikdə baş verə biləcək bəzi səhvlərin qarşısını alır. Bu, verilənlər bazası, giriş, parol üçün ümumi host adını təyin etməyə imkan verir. Biz əvvəllər sahib olduğumuz konfiqurasiya fayllarında adlar və ziddiyyətlər zooparkından uzaqlaşırıq.
İnkişaf mühiti üçün standartdan fərqli olan daha optimal konfiqurasiyadan istifadə etmək imkanımız var. MySQL defolt olaraq zəif maşınlar üçün konfiqurasiya edilmişdir və qutudan kənarda onun performansı çox zəifdir.
Docker sizə istədiyiniz versiyanın Python, Ruby, NodeJS, PHP tərcüməçisindən istifadə etməyə imkan verir. Bir növ versiya menecerindən istifadə etmək ehtiyacından xilas oluruq. Əvvəllər Ruby layihədən asılı olaraq versiyanı dəyişməyə imkan verən rpm paketindən istifadə edirdi. O, həmçinin Docker konteyneri sayəsində kodu asanlıqla köçürməyə və asılılıqlarla birlikdə versiyaya çevirməyə imkan verir. Həm tərcüməçinin, həm də kodun versiyasını başa düşməkdə heç bir problemimiz yoxdur. Versiyanı yeniləmək üçün köhnə konteyneri aşağı salın və yeni konteyneri qaldırın. Bir şey səhv olarsa, yeni konteyneri endirə, köhnə konteyneri qaldıra bilərik.
Təsviri qurduqdan sonra həm İnkişaf, həm də İstehsaldakı konteynerlər eyni olacaq. Bu xüsusilə böyük qurğular üçün doğrudur.
Frontend-də JavaScipt və NodeJS-dən istifadə edirik.
İndi ReacJS-də son layihəmiz var. Tərtibatçı konteynerdəki hər şeyi işlətdi və isti yenidən yükləmə istifadə edərək inkişaf etdirdi.
Sonra, JavaScipt montaj tapşırığı işə salınır və statika daxil edilmiş kod nginx qənaət resursları vasitəsilə verilir.
Burada sonuncu layihəmizin sxemini vermişəm.
Hansı vəzifələr həll edildi? Mobil cihazların qarşılıqlı əlaqədə olduğu bir sistem qurmağa ehtiyacımız var idi. Onlar məlumat alırlar. Ehtimallardan biri bu cihaza təkan bildirişləri göndərməkdir.
Bunun üçün nə etmişik?
Biz proqrama aşağıdakı komponentləri ayırdıq: JS-də idarəetmə hissəsi, Ruby on Rails altında REST interfeysi vasitəsilə işləyən arxa hissə. Backend verilənlər bazası ilə qarşılıqlı əlaqədə olur. Yaranan nəticə müştəriyə verilir. İdarəetmə paneli REST interfeysi vasitəsilə backend və verilənlər bazası ilə qarşılıqlı əlaqədə olur.
Bizim də push bildirişləri göndərməyə ehtiyacımız var idi. Bundan əvvəl mobil platformalara bildirişlərin çatdırılmasına cavabdeh olan bir mexanizm tətbiq edən bir layihəmiz var idi.
Biz aşağıdakı sxemi işləyib hazırlamışıq: brauzerdən olan operator admin paneli ilə qarşılıqlı əlaqədə olur, idarəetmə paneli backend ilə qarşılıqlı əlaqədə olur, vəzifə Push bildirişləri göndərməkdir.
Push bildirişləri NodeJS-də həyata keçirilən digər komponentlə qarşılıqlı əlaqədə olur.
Növbələr qurulur və sonra onların mexanizminə uyğun olaraq bildirişlər göndərilir.
Burada iki verilənlər bazası çəkilir. Hazırda Docker-in köməyi ilə bir-biri ilə heç bir əlaqəsi olmayan 2 müstəqil verilənlər bazasından istifadə edirik. Bundan əlavə, onların ümumi virtual şəbəkəsi var və fiziki məlumatlar tərtibatçının maşınında müxtəlif kataloqlarda saxlanılır.
Eyni, lakin rəqəmlərdə. Burada kodun təkrar istifadəsi vacibdir.
Əgər əvvəllər kodun kitabxanalar şəklində təkrar istifadəsi haqqında danışmışdıqsa, bu nümunədə Push bildirişlərinə cavab verən xidmətimiz tam server kimi təkrar istifadə olunur. API təmin edir. Bizim yeni inkişafımız artıq onunla qarşılıqlı əlaqədədir.
O zaman biz NodeJS-in 4-cü versiyasından istifadə edirdik. İndi (2017-ci ildə - red. qeyd) son inkişaflarda biz NodeJS-in 7 versiyasından istifadə edirik. Kitabxanaların yeni versiyalarını cəlb etmək üçün yeni komponentlərdə heç bir problem yoxdur.
Lazım gələrsə, Push bildiriş xidmətindən NodeJS versiyasını yenidən düzəldə və yüksəldə bilərsiniz.
Əgər API uyğunluğunu qoruya bilsək, onu əvvəllər istifadə edilmiş digər layihələrlə əvəz etmək mümkün olacaq.
Docker əlavə etmək üçün nə lazımdır? Depozitimizə lazımi asılılıqları təsvir edən Dockerfile əlavə edirik. Bu nümunədə komponentlər məntiqi olaraq parçalanır. Bu, backend tərtibatçısının minimum dəstidir.
Yeni layihə yaradarkən biz Dockerfile yaradırıq, istədiyiniz ekosistemi (Python, Ruby, NodeJS) təsvir edirik. Docker-compose-də lazımi asılılığı - verilənlər bazasını təsvir edir. Biz təsvir edirik ki, bizə filan versiyanın verilənlər bazası lazımdır, məlumatları orada və orada saxlayır.
Statikə xidmət etmək üçün nginx ilə ayrıca üçüncü konteynerdən istifadə edirik. Şəkilləri yükləmək mümkündür. Backend onları əvvəlcədən hazırlanmış həcmə qoyur, bu da nginx ilə konteynerə quraşdırılır, bu da statik verir.
Nginx, mysql konfiqurasiyasını saxlamaq üçün biz lazımi konfiqurasiyaları saxladığımız Docker qovluğunu əlavə etdik. Tərtibatçı öz maşınında bir anbarın git klonunu etdikdə, onun artıq yerli inkişaf üçün hazır bir layihəsi var. Hansı portun və ya hansı parametrlərin tətbiq olunacağına dair heç bir sual yoxdur.
Sonra, bir neçə komponentimiz var: admin, məlumat-API, push bildirişləri.
Bütün bunlara başlamaq üçün biz dockerized-app adlandırdığımız başqa bir repozitoriya yaratdıq. Hazırda hər bir komponentdən əvvəl bir neçə repozitoriyadan istifadə edirik. Onlar sadəcə məntiqi olaraq fərqlidirlər - GitLab-da o, bir qovluğa bənzəyir, lakin tərtibatçının maşınında, müəyyən bir layihə üçün bir qovluq. Bir səviyyə aşağı birləşdiriləcək komponentlərdir.
Bu, yalnız dockerized-app məzmununa bir nümunədir. Biz bütün komponentlərin qarşılıqlı əlaqəsi üçün tələb olunan konfiqurasiyaları doldurduğumuz Docker kataloqunu da buraya gətiririk. Layihənin necə icra olunacağını qısaca təsvir edən README.md var.
Burada iki docker-compose faylı tətbiq etdik. Bu, addımlarla qaça bilmək üçün edilir. Tərtibatçı nüvə ilə işləyərkən ona təkan bildirişləri lazım deyil, o, sadəcə olaraq docker-compose faylını işə salır və müvafiq olaraq resurs saxlanılır.
Push bildirişləri ilə inteqrasiyaya ehtiyac varsa, o zaman docker-compose.yaml və docker-compose-push.yaml işə salınır.
docker-compose.yaml və docker-compose-push.yaml qovluqda olduğundan avtomatik olaraq tək virtual şəbəkə yaradılır.
Komponentlərin təsviri. Bu, komponentlərin toplanmasına cavabdeh olan daha inkişaf etmiş bir fayldır. Burada diqqət çəkən nədir? Burada balanslaşdırıcı komponenti təqdim edirik.
Bu, nginx ilə işləyən hazır Docker təsviri və Docker yuvasında dinləyən proqramdır. Dinamik, konteynerlər açılıb-söndükcə nginx konfiqurasiyasını bərpa edir. Biz üçüncü səviyyəli domen adları ilə komponentlərin işlənməsini paylayırıq.
İnkişaf mühiti üçün biz .dev domenindən istifadə edirik - api.informer.dev. .dev domeni olan proqramlar tərtibatçının yerli maşınında mövcuddur.
Bundan əlavə, konfiqurasiyalar hər bir layihəyə köçürülür və bütün layihələr eyni vaxtda birlikdə işə salınır.
Qrafik olaraq, müştərinin bizim brauzerimiz və ya balanslaşdırıcıya sorğu göndərdiyimiz bir alət olduğu ortaya çıxır.
Domen adı balanslaşdırıcısı hansı konteynerlə əlaqə saxlamağı müəyyən edir.
Bu admin JS verən nginx ola bilər. Bu, API verən nginx və ya şəkil yükləmələri şəklində nginx-ə verilən statik fayllar ola bilər.
Diaqram, konteynerlərin virtual şəbəkə ilə birləşdirildiyini və bir proxy arxasında gizləndiyini göstərir.
Tərtibatçının maşınında, IP-ni bilməklə konteynerə daxil ola bilərsiniz, lakin prinsipcə biz bundan istifadə etmirik. Birbaşa girişə praktiki olaraq ehtiyac yoxdur.
Tətbiqinizi dokerləşdirmək üçün hansı nümunəyə baxmaq lazımdır? Mənim fikrimcə, yaxşı bir nümunə MySQL üçün rəsmi docker görüntüsüdür.
Bu olduqca çətin. Çoxlu versiyalar var. Lakin onun funksionallığı gələcək inkişaf prosesində yarana biləcək bir çox ehtiyacları ödəməyə imkan verir. Əgər vaxt sərf etsəniz və bunların hamısının necə qarşılıqlı əlaqədə olduğunu anlasanız, o zaman düşünürəm ki, özünüzü həyata keçirməkdə heç bir probleminiz olmayacaq.
Hub.docker.com adətən github.com-a keçidləri ehtiva edir ki, bu da birbaşa təsviri özünüz yarada biləcəyiniz xam məlumatları ehtiva edir.
Bundan əlavə, bu depoda ilkin işə salınma və tətbiqin işə salınmasının sonrakı işlənməsi üçün cavabdeh olan docker-endpoint.sh skripti var.
Həmçinin bu nümunədə mühit dəyişənlərindən istifadə edərək konfiqurasiya etmək imkanı var. Tək bir konteyner işlədərkən və ya docker-compose vasitəsilə mühit dəyişənini təyin etməklə deyə bilərik ki, docker-in MySQL-də kök salması və ya istədiyimiz hər şey üçün boş parol təyin etməliyik.
Təsadüfi parol yaratmaq üçün bir seçim var. Deyirik ki, bizə istifadəçi lazımdır, istifadəçi üçün parol təyin etməliyik və məlumat bazası yaratmalıyıq.
Layihələrimizdə başlanğıc üçün cavabdeh olan Dockerfile-ni bir az birləşdirdik. Orada biz onu ehtiyaclarımıza uyğunlaşdırdıq ki, onu sadəcə tətbiqin istifadə etdiyi istifadəçi hüquqlarının genişləndirilməsinə çevirdik. Bu, bizə sonradan proqram konsolundan sadəcə verilənlər bazası yaratmağa imkan verdi. Ruby proqramlarında verilənlər bazası yaratmaq, dəyişdirmək və silmək əmri var.
Bu, MySQL-in xüsusi versiyasının github.com saytında necə göründüyünə bir nümunədir. Dockerfile-i aça və orada quraşdırmanın necə getdiyini görə bilərsiniz.
docker-endpoint.sh giriş nöqtəsinə cavabdeh olan skriptdir. İlkin başlatma zamanı bəzi hazırlıq addımları tələb olunur və bütün bu hərəkətlər yalnız başlanğıc skriptində həyata keçirilir.
İkinci hissəyə keçək.
Mənbə kodları saxlamaq üçün gitlab-a keçdik. Bu vizual interfeysi olan kifayət qədər güclü bir sistemdir.
Gitlab-ın komponentlərindən biri Gitlab CI-dir. Bu, daha sonra kodun çatdırılması sistemini təşkil etmək və ya avtomatik sınaqdan keçirmək üçün istifadə ediləcək əmrlər ardıcıllığını təsvir etməyə imkan verir.
Gitlab CI 2 söhbəti - Ruby Russia klubundan reportaj - kifayət qədər ətraflı və bəlkə də sizi maraqlandıracaq.
İndi Gitlab CI-ni aktivləşdirmək üçün nə tələb olunduğuna baxacağıq. Gitlab CI-ni işə salmaq üçün sadəcə olaraq layihənin kökünə .gitlab-ci.yml faylını qoymalıyıq.
Burada biz bir test, yerləşdirmə kimi vəziyyətlərin ardıcıllığını yerinə yetirmək istədiyimizi təsvir edirik.
Tətbiqimizi qurmaq üçün birbaşa docker-compose çağıran skriptləri icra edirik. Bu, sadəcə bir arxa plan nümunəsidir.
Sonra deyirik ki, verilənlər bazasını dəyişdirmək və testlər aparmaq üçün miqrasiyaları həyata keçirmək lazımdır.
Skriptlər düzgün yerinə yetirilibsə və səhv kodu qaytarmırsa, sistem yerləşdirmənin ikinci mərhələsinə keçir.
Yerləşdirmə mərhələsi hazırda səhnələşdirmə üçün həyata keçirilir. Biz sıfır fasilə ilə yenidən işə salma təşkil etməmişik.
Biz bütün qabları zorla söndürürük, sonra sınaq zamanı ilk mərhələdə yığılan bütün qabları yenidən qaldırırıq.
Biz hazırkı mühit dəyişəni üçün tərtibatçılar tərəfindən yazılmış verilənlər bazası köçürmələri üçün çalışırıq.
Bunun yalnız master filialına aid olduğu qeydi var.
Digər filialları dəyişdirərkən icra edilmir.
Filiallar üzrə satışların təşkili mümkündür.
Bunu daha da təşkil etmək üçün Gitlab Runner-ı quraşdırmalıyıq.
Bu yardım proqramı Golang dilində yazılmışdır. Bu, heç bir asılılıq tələb etməyən Golang dünyasında olduğu kimi tək bir fayldır.
Başlanğıcda biz Gitlab Runner-ı qeydiyyatdan keçiririk.
Açarı Gitlab veb interfeysində alırıq.
Sonra komanda xəttində başlatma əmrini çağırırıq.
Gitlab Runner-ı interaktiv şəkildə qurun (Shell, Docker, VirtualBox, SSH)
Gitlab Runner-dakı kod .gitlab-ci.yml parametrindən asılı olaraq hər bir tapşırıqda yerinə yetiriləcək.
Veb interfeysində Gitlab-da vizual olaraq necə görünür. GItlab CI-ni birləşdirdikdən sonra hazırkı quruluş vəziyyətini göstərən bir bayraq var.
Görürük ki, 4 dəqiqə əvvəl bütün sınaqlardan keçmiş və heç bir problem yaratmayan öhdəlik götürülüb.
Quruluşlara daha yaxından baxa bilərik. Burada görürük ki, artıq iki dövlət keçib. Səhnədə sınaq vəziyyəti və yerləşdirmə statusu.
Müəyyən bir quruluşa klikləsək, .gitlab-ci.yml-ə uyğun olaraq prosesdə icra edilən əmrlərin konsol çıxışı olacaq.
Məhsul tariximiz belə görünür. Uğurlu cəhdlərin olduğunu görürük. Testlər təqdim edildikdə, o, növbəti mərhələyə keçmir və mərhələ kodu yenilənmir.
Docker tətbiq edərkən quruluşda hansı vəzifələri həll etdik? Sistemimiz komponentlərdən ibarətdir və bütün sistemi deyil, repozitoriyada yenilənmiş komponentlərin yalnız bir hissəsini yenidən başlatmağa ehtiyacımız var idi.
Bunun üçün hər şeyi ayrı-ayrı qovluqlara parçalamalı olduq.
Bunu etdikdən sonra Docker-compose-un hər bir ata üçün öz şəbəkə sahəsi yaratması və qonşunun komponentlərini görməməsi ilə bağlı problemimiz var idi.
Ətrafda olmaq üçün Docker-də şəbəkəni əl ilə yaratdıq. Docker-compose-da yazılmışdı ki, siz bu layihə üçün belə bir şəbəkədən istifadə edirsiniz.
Beləliklə, bu şəbəkə ilə başlayan hər bir komponent sistemin digər hissələrindəki komponentləri görür.
Növbəti məsələ səhnələşdirmənin çoxsaylı layihələr arasında bölünməsidir.
Bütün bunların gözəl görünməsi və istehsala mümkün qədər yaxın olması üçün WEB-də hər yerdə istifadə olunan 80 və ya 443 portundan istifadə etmək yaxşıdır.
Bunu necə həll etdik? Biz bütün böyük layihələrə bir Gitlab Runner təyin etdik.
Gitlab sizə bir neçə paylanmış Gitlab Runners-ı işə salmağa imkan verir ki, bu da bütün tapşırıqları növbə ilə xaotik şəkildə yerinə yetirəcək və onları idarə edəcək.
Evimiz olmaması üçün layihələrimizi bir Gitlab Runner ilə məhdudlaşdırdıq ki, bu da həcmlərimizlə problemsiz mübarizə aparır.
Biz nginx-proxy-ni ayrıca başlanğıc skriptinə köçürdük və içindəki bütün layihələr üçün şəbəkələr əlavə etdik.
Layihəmizdə bir şəbəkə var və balanslaşdırıcıda layihə adlarına görə bir neçə şəbəkə var. Daha sonra domen adları ilə proxy edə bilər.
Sorğularımız 80 nömrəli portdakı domen vasitəsilə gəlir və bu domenə xidmət edən konteyner qrupunda həll olunur.
Başqa hansı problemlər var idi? Defolt olaraq bütün konteynerlərin kök kimi işlədiyi budur. Bu, sistemin kök sahibinə bərabər olmayan kökdür.
Bununla belə, konteynerə daxil olsanız, o, kök olacaq və bu konteynerdə yaratdığımız fayl kök hüquqlarını əldə edir.
Tərtibatçı konteynerə giribsə və orada fayl yaradan bəzi əmrləri yerinə yetiribsə, sonra konteyneri tərk edibsə, deməli, onun iş kataloqunda girişi olmayan bir fayl var.
Bunu necə həll etmək olar? Konteynerdə olacaq istifadəçiləri əlavə edə bilərsiniz.
İstifadəçini əlavə etdikdə hansı problemlər yarandı?
İstifadəçi yaradarkən çox vaxt eyni qrup ID (UID) və istifadəçi ID (GID) olmur.
Konteynerdə bu problemi həll etmək üçün biz ID 1000 olan istifadəçilərdən istifadə edirik.
Bizim vəziyyətimizdə bu, demək olar ki, bütün tərtibatçıların Ubuntu OS-dən istifadə etməsi ilə üst-üstə düşdü. Ubuntuda isə ilk istifadəçinin identifikatoru 1000-dir.
Planlarımız varmı?
Docker sənədlərini oxuyun. Layihə fəal şəkildə inkişaf edir, sənədlər dəyişir. İki-üç ay əvvəl alınan məlumatlar artıq yavaş-yavaş köhnəlir.
Bizim həll etdiyimiz problemlərin bəziləri, yəqin ki, standart vasitələrlə artıq həll olunub.
Buna görə də birbaşa orkestrə getmək üçün daha da irəli getmək istəyirəm.
Bir nümunə, qutudan çıxan Docker Swarm adlı Docker-in daxili mexanizmidir. Mən Docker Swarm texnologiyasına əsaslanan istehsalda bir şey işlətmək istəyirəm.
Kürü tökmə qabları loglarla işləməyi əlverişsiz edir. İndi loglar təcrid olunub. Onlar konteynerlər arasında səpələnmişdir. Tapşırıqlardan biri də veb-interfeysi vasitəsilə qeydlərə rahat girişi təmin etməkdir.
Mənbə: www.habr.com