Biz True Engineering olaraq müştəri serverlərinə davamlı yeniləmələrin çatdırılması üçün bir proses qurmuşuq və bu təcrübəni bölüşmək istəyirik.
Başlamaq üçün biz müştəri üçün onlayn sistem hazırladıq və onu öz Kubernetes klasterimizdə yerləşdirdik. İndi yüksək yüklü həllimiz müştəri platformasına keçdi, bunun üçün biz tam avtomatik Davamlı Yerləşdirmə prosesini qurmuşuq. Bunun sayəsində biz bazara çıxarılma müddətini - məhsul mühitinə dəyişikliklərin çatdırılmasını sürətləndirdik.
Bu yazıda Davamlı Yerləşdirmə (CD) prosesinin bütün mərhələləri və ya müştəri platformasına yeniləmələrin çatdırılması haqqında danışacağıq:
- Bu proses necə başlayır?
- müştərinin Git deposu ilə sinxronizasiya,
- arxa və ön hissənin montajı,
- sınaq mühitində avtomatik proqram yerləşdirilməsi,
- Prod-a avtomatik yerləşdirmə.
Quraşdırma təfərrüatlarını yol boyu paylaşacağıq.
1. CD-ni işə salın
Davamlı Yerləşdirmə, tərtibatçının Git repozitorumuzun buraxılış filialına dəyişiklikləri itələməsi ilə başlayır.
Tətbiqimiz mikroservis arxitekturasında işləyir və onun bütün komponentləri bir depoda saxlanılır. Bunun sayəsində, onlardan biri dəyişsə belə, bütün mikroservislər toplanır və quraşdırılır.
Bir neçə səbəbə görə bir depo vasitəsilə işi təşkil etdik:
- İnkişafın asanlığı - tətbiq aktiv şəkildə inkişaf edir, buna görə bir anda bütün kodlarla işləyə bilərsiniz.
- Tək sistem olaraq tətbiqin bütün sınaqlardan keçməsinə və müştərinin istehsal mühitinə çatdırılmasına zəmanət verən tək CI/CD boru kəməri.
- Biz versiyalarda çaşqınlığı aradan qaldırırıq - biz mikroservis versiyalarının xəritəsini saxlamalı və Helm skriptlərində hər bir mikroservis üçün onun konfiqurasiyasını təsvir etməli deyilik.
2. Müştərinin mənbə kodunun Git deposu ilə sinxronizasiya
Edilən dəyişikliklər avtomatik olaraq müştərinin Git deposu ilə sinxronlaşdırılır. Orada filialı yenilədikdən sonra işə salınan tətbiq montajı konfiqurasiya edilir və davamına yerləşdirilir. Hər iki proses öz mühitlərində Git deposundan yaranır.
Biz müştərinin deposu ilə birbaşa işləyə bilmərik, çünki inkişaf və sınaq üçün öz mühitlərimizə ehtiyacımız var. Bu məqsədlər üçün Git depomuzdan istifadə edirik - o, onların Git repozitoriyası ilə sinxronlaşdırılır. Tərtibatçı repozitorumuzun müvafiq şöbəsinə dəyişiklikləri göndərən kimi GitLab dərhal bu dəyişiklikləri müştəriyə çatdırır.
Bundan sonra montajı etməlisiniz. O, bir neçə mərhələdən ibarətdir: arxa və ön hissənin yığılması, sınaqdan keçirilməsi və istehsala çatdırılması.
3. Arxa və ön hissənin yığılması
Backend və frontend qurmaq GitLab Runner sistemində yerinə yetirilən iki paralel tapşırıqdır. Onun orijinal montaj konfiqurasiyası eyni depoda yerləşir.
.
GitLab Runner kodu tələb olunan depodan götürür, onu Java proqram qurma əmri ilə yığır və Docker reyestrinə göndərir. Burada backend və frontend yığırıq, Docker şəkillərini əldə edirik və onları müştərinin tərəfindəki depoya yerləşdiririk. Docker şəkillərini idarə etmək üçün istifadə edirik .
Şəkillərimizin versiyalarını Docker-də dərc olunacaq buraxılış versiyası ilə sinxronlaşdırırıq. Rahat işləmək üçün bir neçə düzəliş etdik:
1. Konteynerlər sınaq mühiti ilə istehsal mühiti arasında yenidən qurulmur. Parametrləşdirmələr etdik ki, eyni konteyner həm sınaq mühitində, həm də istehsalda yenidən qurulmadan bütün parametrlər, mühit dəyişənləri və xidmətlərlə işləyə bilsin.
2. Helm vasitəsilə proqramı yeniləmək üçün onun versiyasını göstərməlisiniz. Biz backend, frontend qururuq və tətbiqi yeniləyirik - bunlar üç fərqli vəzifədir, ona görə də hər yerdə tətbiqin eyni versiyasından istifadə etmək vacibdir. Bu tapşırıq üçün biz Git tarixçəsindəki məlumatlardan istifadə edirik, çünki K8S klaster konfiqurasiyamız və tətbiqlərimiz eyni Git deposundadır.
Əmr icrasının nəticələrindən proqram versiyasını alırıq
git describe --tags --abbrev=7.
4. Test mühitində bütün dəyişikliklərin avtomatik yerləşdirilməsi (UAT)
Bu qurma skriptində növbəti addım K8S klasterini avtomatik yeniləməkdir. Bu, bütün tətbiqin qurulması və bütün artefaktların Docker Registry-də dərc edilməsi şərtilə baş verir. Bundan sonra test mühitinin yeniləməsi başlayır.
Klaster yeniləməsi istifadə olunmağa başladı . Nəticədə bir şey plana uyğun getməsə, Helm avtomatik olaraq və müstəqil olaraq bütün dəyişikliklərini geri qaytaracaq. Onun işinə nəzarət etmək lazım deyil.
Biz montajla birlikdə K8S klaster konfiqurasiyasını təqdim edirik. Buna görə də, növbəti addım onu yeniləməkdir: konfiqurasiya xəritələri, yerləşdirmələr, xidmətlər, sirrlər və dəyişdirdiyimiz hər hansı digər K8S konfiqurasiyaları.
Helm daha sonra test mühitində tətbiqin özünün RollOut yeniləməsini həyata keçirir. Tətbiq istehsala yerləşdirilməzdən əvvəl. Bu, istifadəçilərin test mühitinə qoyduğumuz biznes xüsusiyyətlərini əl ilə sınaqdan keçirməsi üçün edilir.
5. Prod-a bütün dəyişikliklərin avtomatik yerləşdirilməsi
İstehsal mühitinə yeniləmə yerləşdirmək üçün GitLab-da bir düyməni sıxmağınız kifayətdir - və konteynerlər dərhal istehsal mühitinə çatdırılır.
Eyni proqram yenidən qurulmadan müxtəlif mühitlərdə - sınaq və istehsalda işləyə bilər. Tətbiqdə heç nəyi dəyişmədən eyni artefaktlardan istifadə edirik və parametrləri xaricdən təyin edirik.
Tətbiq parametrlərinin çevik parametrləşdirilməsi proqramın icra olunacağı mühitdən asılıdır. Biz bütün mühit parametrlərini xaricə köçürdük: hər şey K8S konfiqurasiyası və Helm parametrləri vasitəsilə parametrləşdirilir. Helm montajı sınaq mühitinə yerləşdirdikdə, sınaq parametrləri ona, məhsul parametrləri isə istehsal mühitinə tətbiq edilir.
Ən çətini ətraf mühitdən asılı olan bütün istifadə olunan xidmətləri və dəyişənləri parametrləşdirmək və onları Helm üçün mühit dəyişənlərinə və ətraf mühit parametrlərinin təsviri-konfiqurasiyalarına çevirmək idi.
Tətbiq parametrləri mühit dəyişənlərindən istifadə edir. Onların dəyərləri Go şablonlarından istifadə edərək şablonlaşdırılan K8S konfiqurasiyasından istifadə edərək konteynerlərə qoyulur. Məsələn, domen adına mühit dəyişənini təyin etmək bu şəkildə edilə bilər:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Dəyərlər.qlobal.env – bu dəyişən mühitin adını saxlayır (məhsul, mərhələ, UAT).
.Values.app.properties.app_external_domain – bu dəyişəndə biz .Values.yaml faylında istədiyiniz domeni təyin etdik
Proqramı yeniləyərkən Helm şablonlardan configmap.yaml faylı yaradır və proqram yeniləməsinin başladığı mühitdən asılı olaraq APP_EXTERNAL_DOMAIN dəyərini istədiyiniz dəyərlə doldurur. Bu dəyişən artıq konteynerdə quraşdırılıb. Ona proqramdan daxil olmaq olar, buna görə də hər bir tətbiq mühiti bu dəyişən üçün fərqli dəyərə malik olacaq.
Nisbətən bu yaxınlarda K8S dəstəyi Spring Cloud-da, o cümlədən configMaps ilə işləmək üçün ortaya çıxdı: . Layihə aktiv şəkildə inkişaf edərkən və köklü şəkildə dəyişsə də, biz ondan istehsalda istifadə edə bilmirik. Amma biz onun vəziyyətini fəal şəkildə izləyirik və onu DEV konfiqurasiyalarında istifadə edirik. Sabitləşən kimi mühit dəyişənlərindən istifadə etməyə keçəcəyik.
Ümumi
Beləliklə, Davamlı Yerləşdirmə konfiqurasiya edilir və işləyir. Bütün yeniləmələr bir düyməni basmaqla baş verir. Məhsul mühitinə dəyişikliklərin çatdırılması avtomatikdir. Və ən əsası, yeniləmələr sistemi dayandırmır.
Gələcək planlar: verilənlər bazasının avtomatik miqrasiyası
Biz verilənlər bazasını təkmilləşdirmək və bu dəyişiklikləri geri qaytarmaq imkanını düşündük. Axı, tətbiqin iki müxtəlif versiyası eyni vaxtda işləyir: köhnəsi işləyir, yenisi isə hazırdır. Və köhnəsini yalnız yeni versiyanın işlədiyinə əmin olduqda söndürəcəyik. Verilənlər bazasının miqrasiyası sizə proqramın hər iki versiyası ilə işləməyə imkan verməlidir.
Buna görə də, biz sadəcə sütun adını və ya digər məlumatları dəyişə bilmərik. Ancaq biz yeni bir sütun yarada, köhnə sütundan məlumatları ona köçürə və məlumatları yeniləyərkən eyni vaxtda başqa bir sütuna köçürəcək və yeniləyəcək tetikleyiciler yaza bilərik. Tətbiqin yeni versiyasının uğurla yerləşdirilməsindən sonra, başlanğıcdan sonrakı dəstək müddətindən sonra köhnə sütunu və lazımsız hala gələn tətiyi silə biləcəyik.
Tətbiqin yeni versiyası düzgün işləməsə, verilənlər bazasının əvvəlki versiyası da daxil olmaqla, əvvəlki versiyaya geri qayıda bilərik. Bir sözlə, dəyişikliklərimiz sizə tətbiqin bir neçə versiyası ilə eyni vaxtda işləməyə imkan verəcək.
Biz K8S işi vasitəsilə verilənlər bazası miqrasiyasını avtomatlaşdırmağı, onu CD prosesinə inteqrasiya etməyi planlaşdırırıq. Və biz mütləq bu təcrübəni Habré-də paylaşacağıq.
Mənbə: www.habr.com