Qeyd. tərcümə.: Son nəşrdən sonra GitOps-da çəkmə və itələmə üsulları haqqında, ümumiyyətlə, bu modelə maraq gördük, lakin bu mövzuda rusdilli nəşrlər çox az idi (Sadəcə Habré-də heç biri yoxdur). Buna görə də, demək olar ki, bir il əvvəl də olsa, başqa bir məqalənin tərcüməsini diqqətinizə təqdim etməkdən məmnunuq! — Weaveworks şirkətindən, onun rəhbəri “GitOps” terminini işlətdi. Mətn yanaşmanın mahiyyətini və mövcud olanlardan əsas fərqlərini izah edir.
Bir il əvvəl dərc etmişdik . O vaxt biz Weaveworks komandasının tamamilə Kubernetes-ə əsaslanan SaaS-i necə işə saldığını və bulud mühitində yerləşdirmə, idarə etmə və monitorinq üçün bir sıra ən yaxşı təcrübələr hazırladığını paylaşmışdıq.
Məqalə məşhur oldu. Digər insanlar GitOps haqqında danışmağa başladılar və yeni alətlər dərc etməyə başladılar , , , , və s. Saytımızda göründü nəşrlər və GitOps istifadə halları. Ancaq bəzi insanların hələ də sualları var. Model ənənəvi modeldən nə ilə fərqlənir? və davamlı çatdırılma ()? Kubernetes istifadə etmək lazımdırmı?
Tezliklə başa düşdük ki, yeni təsvirə ehtiyac var, təklif edirik:
- Çox sayda nümunə və hekayə;
- GitOps-un xüsusi tərifi;
- Ənənəvi davamlı çatdırılma ilə müqayisə.
Bu yazıda bütün bu mövzuları əhatə etməyə çalışdıq. O, GitOps-a yenilənmiş girişi və tərtibatçı və CI/CD perspektivini təqdim edir. Model ümumiləşdirilə bilsə də, biz ilk növbədə Kubernetes-ə diqqət yetiririk.
GitOps ilə tanış olun
Təsəvvür edin Alice. O, müqavilələrin incəliklərini özləri anlamaq üçün çox məşğul olan insanlara sağlamlıq, avtomobil, ev və səyahət sığortası təklif edən Ailə Sığortasını idarə edir. Onun işi, Alice bir bankda data alimi kimi işləyərkən yan layihə kimi başladı. Bir gün o, məlumatları daha effektiv təhlil etmək və sığorta paketlərini formalaşdırmaq üçün qabaqcıl kompüter alqoritmlərindən istifadə edə biləcəyini başa düşdü. İnvestorlar layihəni maliyyələşdirdilər və indi onun şirkəti ildə 20 milyon dollardan çox gəlir gətirir və sürətlə böyüyür. Hazırda burada 180 nəfər müxtəlif vəzifələrdə çalışır. Buraya vebsaytı, verilənlər bazasını inkişaf etdirən, saxlayan və müştəri bazasını təhlil edən texnologiya komandası daxildir. 60 nəfərdən ibarət komandaya şirkətin texniki direktoru Bob rəhbərlik edir.
Bob komandası istehsal sistemlərini buludda yerləşdirir. Onların əsas tətbiqləri Google Cloud-da Kubernetes-dən istifadə edərək GKE-də işləyir. Bundan əlavə, onlar öz işlərində müxtəlif məlumat və analitik vasitələrdən istifadə edirlər.
Ailə Sığortası konteynerlərdən istifadə etməyi planlaşdırmadı, lakin Docker həvəsinə qapıldı. Şirkət tezliklə GKE-nin yeni xüsusiyyətləri sınamaq üçün klasterləri yerləşdirməyi asanlaşdırdığını aşkar etdi. Konteyner reyestrini təşkil etmək üçün CI və Quay üçün Jenkins əlavə edildi, Jenkins üçün yeni konteynerlər və konfiqurasiyaları GKE-yə itələyən skriptlər yazılmışdır.
Bir müddət keçdi. Alice və Bob seçdikləri yanaşmanın performansından və onun biznesə təsirindən məyus oldular. Konteynerlərin tətbiqi məhsuldarlığı komandanın gözlədiyi qədər yaxşılaşdırmadı. Bəzən yerləşdirmələr pozulurdu və kod dəyişikliklərinin günahkar olub-olmadığı aydın deyildi. Konfiqurasiya dəyişikliklərini izləmək də çətin oldu. Çox vaxt yeni bir klaster yaratmaq və tətbiqləri ona köçürmək lazım idi, çünki bu, sistemin yaratdığı qarışıqlığı aradan qaldırmağın ən asan yolu idi. Alice proqram inkişaf etdikcə vəziyyətin daha da pisləşəcəyindən qorxurdu (əlavə olaraq, maşın öyrənməsinə əsaslanan yeni layihə hazırlanırdı). Bob işin çox hissəsini avtomatlaşdırmışdı və boru kəmərinin niyə hələ də qeyri-sabit olduğunu, yaxşı miqyas almadığını və vaxtaşırı əl ilə müdaxilə tələb etdiyini başa düşmürdü?
Sonra GitOps haqqında öyrəndilər. Bu qərar onların inamla irəliləmək üçün lazım olan şey olduğu ortaya çıxdı.
Alice və Bob illərdir kod iş axını kimi Git, DevOps və infrastruktur haqqında eşidirlər. GitOps-un unikal cəhəti odur ki, o, Kubernetes kontekstində bu ideyaları həyata keçirmək üçün həm qəti, həm də normativ ən yaxşı təcrübələr toplusunu gətirir. Bu mövzu , daxil olmaqla .
Ailə Sığortası GitOps tətbiq etməyə qərar verir. Şirkət indi Kubernetes və kombinlərlə uyğun gələn avtomatlaşdırılmış əməliyyat modelinə malikdir sürət ilə sabitlikÇünki onlar:
- heç kimin ağlını itirmədən komandanın məhsuldarlığının ikiqat artdığını aşkar etdi;
- skriptlərə xidmət göstərməyi dayandırdı. Bunun əvəzinə, onlar indi diqqəti yeni xüsusiyyətlərə yönəldə və mühəndislik üsullarını təkmilləşdirə bilərlər - məsələn, kanareykaların təqdim edilməsi və sınaqların təkmilləşdirilməsi;
- yerləşdirmə prosesini təkmilləşdirmişik ki, o, nadir hallarda pozulsun;
- əl müdaxiləsi olmadan qismən nasazlıqlardan sonra yerləşdirmələri bərpa etmək imkanı əldə etdi;
- alınıb istifadə olunubоÇatdırılma sistemlərinə daha çox inam. Alice və Bob kəşf etdilər ki, onlar komandanı paralel işləyən mikroservis qruplarına bölmək olar;
- hər bir qrupun səyi ilə layihədə hər gün 30-50 dəyişiklik edə və yeni texnikaları sınaya bilər;
- bir neçə saat ərzində çəkmə sorğularından istifadə edərək istehsala yeniləmələri yaymaq imkanı olan yeni tərtibatçıları layihəyə cəlb etmək asandır;
- SOC2 çərçivəsində auditdən asanlıqla keçin (xidmət təminatçılarının məlumatların təhlükəsiz idarə edilməsi tələblərinə uyğunluğu üçün; daha çox oxuyun, məsələn, - təqribən. tərcümə.).
Nə oldu?
GitOps iki şeydir:
- Kubernetes və bulud üçün əməliyyat modeli. O, konteynerləşdirilmiş klasterlərin və proqramların yerləşdirilməsi, idarə edilməsi və monitorinqi üçün ən yaxşı təcrübələr toplusunu təqdim edir. Formada zərif tərif etibarən :
- Tərtibatçı mərkəzli proqram idarəetmə mühitinin yaradılması yolu. Biz Git iş prosesini həm əməliyyatlara, həm də inkişafa tətbiq edirik. Nəzərə alın ki, bu, təkcə Git push ilə bağlı deyil, CI/CD və UI/UX alətlərinin bütün dəstini təşkil etməkdir.
Git haqqında bir neçə kəlmə
Əgər versiyaya nəzarət sistemləri və Git əsaslı iş axını ilə tanış deyilsinizsə, onlar haqqında öyrənməyi çox tövsiyə edirik. Budaqlarla işləmək və istəkləri çəkmək əvvəlcə qara sehr kimi görünə bilər, lakin faydalar səyə dəyər. Budur başlamaq.
Kubernetes necə işləyir
Hekayəmizdə Alice və Bob bir müddət Kubernetes ilə işlədikdən sonra GitOps-a müraciət etdilər. Həqiqətən, GitOps Kubernetes ilə sıx bağlıdır - bu, Kubernetes-ə əsaslanan infrastruktur və tətbiqlər üçün əməliyyat modelidir.
Kubernetes istifadəçilərə nə verir?
Burada bəzi əsas xüsusiyyətlər var:
- Kubernetes modelində hər şey deklarativ formada təsvir edilə bilər.
- Kubernetes API serveri bu bəyannaməni giriş kimi qəbul edir və sonra davamlı olaraq klasteri bəyannamədə təsvir olunan vəziyyətə gətirməyə çalışır.
- Bəyannamələr müxtəlif iş yüklərini – “tətbiqləri” təsvir etmək və idarə etmək üçün kifayətdir.
- Nəticədə, tətbiqdə və klasterdə dəyişikliklər aşağıdakılara görə baş verir:
- konteyner şəkillərində dəyişikliklər;
- deklarativ spesifikasiyada dəyişikliklər;
- ətraf mühitdəki səhvlər - məsələn, konteyner qəzaları.
Kubernetes'in Böyük Konvergensiya Qabiliyyətləri
Administrator konfiqurasiya dəyişiklikləri etdikdə, Kubernetes orkestratoru vəziyyəti olduğu müddətcə onları klasterə tətbiq edəcək. yeni konfiqurasiyaya yaxınlaşmayacaq. Bu model istənilən Kubernetes resursu üçün işləyir və Xüsusi Resurs Tərifləri (CRD) ilə genişləndirilə bilər. Buna görə də, Kubernetes yerləşdirmələri aşağıdakı gözəl xüsusiyyətlərə malikdir:
- Avtomatlaşdırma: Kubernetes yeniləmələri dəyişikliklərin zərif və vaxtında tətbiqi prosesini avtomatlaşdırmaq mexanizmini təmin edir.
- Konvergensiya: Kubernetes müvəffəqiyyətli olana qədər yeniləmələrə cəhd etməyə davam edəcək.
- Qüsursuzluq: Konvergensiyanın təkrar tətbiqləri eyni nəticəyə gətirib çıxarır.
- Determinizm: Resurslar kifayət qədər olduqda, yenilənmiş klasterin vəziyyəti yalnız istədiyiniz vəziyyətdən asılıdır.
GitOps necə işləyir
GitOps-un necə işlədiyini izah etmək üçün Kubernetes haqqında kifayət qədər məlumat əldə etdik.
Gəlin Ailə Sığortasının mikroservis qruplarına qayıdaq. Onlar adətən nə etməlidirlər? Aşağıdakı siyahıya baxın (əgər orada hər hansı element qəribə və ya tanış deyilsə, lütfən, tənqidi dayandırın və bizimlə qalın). Bunlar Jenkins əsaslı iş axınlarının sadəcə nümunələridir. Digər alətlərlə işləyərkən bir çox başqa proseslər var.
Əsas odur ki, hər yeniləmənin konfiqurasiya fayllarına və Git depolarına edilən dəyişikliklərlə başa çatdığını görürük. Git-ə edilən bu dəyişikliklər "GitOps operatorunun" klasteri yeniləməsinə səbəb olur:
1.İş prosesi: "Jenkins build - master filialı.
Tapşırıq siyahısı:
- Jenkins etiketlənmiş şəkilləri Quay-a itələyir;
- Jenkins konfiqurasiya və Helm diaqramlarını əsas yaddaş qutusuna itələyir;
- Bulud funksiyası konfiqurasiya və diaqramları master yaddaş qutusundan master Git repozitoriyasına köçürür;
- GitOps operatoru klasteri yeniləyir.
2. Jenkins build - buraxılış və ya düzəliş filialı:
- Jenkins etiketsiz şəkilləri Quay-a itələyir;
- Jenkins konfiqurasiya və Helm diaqramlarını quruluş saxlama qutusuna itələyir;
- Bulud funksiyası konfiqurasiyanı və diaqramları quruluş saxlama qutusundan hazırlama Git repozitoriyasına köçürür;
- GitOps operatoru klasteri yeniləyir.
3. Jenkins build - inkişaf və ya xüsusiyyət filialı:
- Jenkins etiketsiz şəkilləri Quay-a itələyir;
- Jenkins konfiqurasiya və Helm diaqramlarını inkişaf saxlama qutusuna itələyir;
- Bulud funksiyası konfiqurasiya və diaqramları inkişaf etdirmə saxlama qutusundan inkişaf etdirmə Git deposuna köçürür;
- GitOps operatoru klasteri yeniləyir.
4. Yeni müştəri əlavə olunur:
- Menecer və ya administrator (LCM/ops) ilkin olaraq şəbəkə yükü balanslaşdırıcılarını (NLB) yerləşdirmək və konfiqurasiya etmək üçün Gradle-a zəng edir;
- LCM/ops yerləşdirməni yeniləmələrə hazırlamaq üçün yeni konfiqurasiya edir;
- GitOps operatoru klasteri yeniləyir.
GitOps-un qısa təsviri
- Hər bir mühit üçün deklarativ spesifikasiyalardan istifadə edərək bütün sistemin istənilən vəziyyətini təsvir edin (hekayəmizdə Bobun komandası Git-də bütün sistem konfiqurasiyasını müəyyən edir).
- Git deposu bütün sistemin arzu olunan vəziyyəti ilə bağlı yeganə həqiqət mənbəyidir.
- İstədiyiniz vəziyyətə edilən bütün dəyişikliklər Git-də öhdəliklər vasitəsilə edilir.
- Bütün arzu olunan klaster parametrləri klasterin özündə də müşahidə olunur. Bu yolla onların üst-üstə düşüb-düşmədiyini müəyyən edə bilərik (birləşir, converges) və ya fərqli (diversiya, ayrılmaq) arzu olunan və müşahidə olunan vəziyyətlər.
- İstənilən və müşahidə olunan vəziyyətlər fərqlidirsə, onda:
- Hədəf və müşahidə vəziyyətlərini gec-tez avtomatik sinxronlaşdıran bir yaxınlaşma mexanizmi var. Klaster daxilində Kubernetes bunu edir.
- Proses dərhal “tədbir edilən dəyişiklik” xəbərdarlığı ilə başlayır.
- Bəzi konfiqurasiya edilə bilən müddətdən sonra vəziyyətlər fərqli olarsa, "fərq" xəbərdarlığı göndərilə bilər.
- Beləliklə, Git-dəki bütün öhdəliklər klasterdə yoxlanıla bilən və idempotent yeniləmələrə səbəb olur.
- Geri qaytarma əvvəllər arzu olunan vəziyyətə yaxınlaşmadır.
- Konvergensiya sondur. Onun meydana gəlməsi ilə göstərilir:
- Müəyyən bir müddət üçün fərq siqnalları yoxdur.
- "birləşmiş" xəbərdarlıq (məsələn, webhook, Git writeback hadisəsi).
Divergensiya nədir?
Yenidən təkrar edək: bütün arzu olunan klaster xassələri klasterin özündə müşahidə oluna bilməlidir.
Ayrılığa bəzi nümunələr:
- Git-də filialların birləşməsi səbəbindən konfiqurasiya faylında dəyişiklik.
- GUI müştərisi tərəfindən edilən Git öhdəliyi səbəbindən konfiqurasiya faylında dəyişiklik.
- Git-də PR səbəbiylə istədiyiniz vəziyyətə çoxsaylı dəyişikliklər, ardınca konteyner şəklinin qurulması və konfiqurasiya dəyişiklikləri.
- Səhv, "pis davranış" ilə nəticələnən resurs münaqişəsi və ya sadəcə orijinal vəziyyətdən təsadüfi sapma səbəbindən klasterin vəziyyətindəki dəyişiklik.
Konvergensiya mexanizmi nədir?
Bir neçə nümunə:
- Konteynerlər və klasterlər üçün yaxınlaşma mexanizmi Kubernetes tərəfindən təmin edilir.
- Eyni mexanizm Kubernetes əsaslı tətbiqləri və dizaynları (məsələn, Istio və Kubeflow) idarə etmək üçün istifadə edilə bilər.
- Kubernetes, görüntü anbarları və Git arasında operativ qarşılıqlı əlaqəni idarə etmək mexanizmi təmin edir hissəsi olan .
- Əsas maşınlar üçün yaxınlaşma mexanizmi deklarativ və avtonom olmalıdır. Öz təcrübəmizdən bunu deyə bilərik bu tərifə ən yaxın, lakin yenə də insan nəzarəti tələb edir. Bu mənada GitOps İnfrastruktur ənənəsini Kod kimi genişləndirir.
GitOps istismar üçün bir model təmin etmək üçün Git-i Kubernetes-in əla konvergensiya mühərriki ilə birləşdirir.
GitOps bizə deməyə imkan verir: Yalnız təsvir edilə bilən və müşahidə oluna bilən sistemlər avtomatlaşdırıla və idarə oluna bilər.
GitOps bütün yerli bulud yığını üçün nəzərdə tutulub (məsələn, Terraform və s.)
GitOps təkcə Kubernetes deyil. Biz istəyirik ki, bütün sistem deklorativ şəkildə idarə olunsun və konvergensiyadan istifadə etsin. Bütün sistem dedikdə biz Kubernetes ilə işləyən mühitlər toplusunu nəzərdə tuturuq - məsələn, “dev cluster 1”, “istehsal” və s. Hər bir mühitə maşınlar, klasterlər, proqramlar, həmçinin məlumat, monitorinq təmin edən xarici xidmətlər üçün interfeyslər daxildir. və s.
Bu halda Terraformun yükləmə problemi üçün nə qədər vacib olduğuna diqqət yetirin. Kubernetes haradasa yerləşdirilməlidir və Terraform istifadə edərək, biz Kubernetes və tətbiqləri dəstəkləyən nəzarət qatını yaratmaq üçün eyni GitOps iş axınlarını tətbiq edə bilərik. Bu faydalı ən yaxşı təcrübədir.
GitOps konsepsiyalarını Kubernetes-in üstündəki təbəqələrə tətbiq etməyə güclü diqqət yetirilir. Hal-hazırda, Istio, Helm, Ksonnet, OpenFaaS və Kubeflow üçün GitOps tipli həllər, həmçinin, məsələn, bulud üçün yerli proqramlar hazırlamaq üçün təbəqə yaradan Pulumi üçün həllər mövcuddur.
Kubernetes CI/CD: GitOps-u digər yanaşmalarla müqayisə etmək
Qeyd edildiyi kimi, GitOps iki şeydir:
- Yuxarıda təsvir edilən Kubernetes və bulud yerli üçün əməliyyat modeli.
- Tərtibatçı mərkəzli proqram idarəetmə mühitinə gedən yol.
Bir çoxları üçün GitOps ilk növbədə Git təkanlarına əsaslanan iş axınıdır. Biz də onu bəyənirik. Ancaq bu, hamısı deyil: indi CI/CD boru kəmərlərinə baxaq.
GitOps Kubernetes üçün davamlı yerləşdirməyə (CD) imkan verir
GitOps, ayrıca “yerləşdirmə idarəetmə sistemlərinə” ehtiyacı aradan qaldıran davamlı yerləşdirmə mexanizmi təklif edir. Kubernetes sizin üçün bütün işləri görür.
- Tətbiqin yenilənməsi Git-də yenilənmə tələb edir. Bu, istənilən vəziyyətə əməliyyat yeniləməsidir. "Yerləşdirmə" daha sonra yenilənmiş təsvirə əsasən Kubernetes tərəfindən klaster daxilində həyata keçirilir.
- Kubernetes-in işləmə xüsusiyyətinə görə, bu yeniləmələr konvergentdir. Bu, bütün yeniləmələrin atomik olduğu davamlı yerləşdirmə mexanizmini təmin edir.
- Qeyd: Git və Kubernetes-i birləşdirən GitOps operatorunu təklif edir və klasterin istənilən və cari vəziyyətini uzlaşdıraraq CD-nin yerinə yetirilməsinə imkan verir.
Kubectl və skriptlər olmadan
Klasterinizi yeniləmək üçün Kubectl istifadə etməməli və xüsusilə kubectl əmrlərini qruplaşdırmaq üçün skriptlərdən istifadə etməməlisiniz. Bunun əvəzinə, GitOps boru kəməri ilə istifadəçi Git vasitəsilə Kubernetes klasterini yeniləyə bilər.
Üstünlüklərə aşağıdakılar daxildir:
- Sağ. Bir qrup yeniləmə tətbiq oluna, birləşdirilə və nəhayət təsdiqlənə bilər ki, bu da bizi atom yerləşdirmə məqsədinə yaxınlaşdırır. Bunun əksinə olaraq, skriptlərdən istifadə konvergensiyaya heç bir zəmanət vermir (aşağıda bu barədə ətraflı).
- təhlükəsizlik. Kelsey Hightower: "Kubernetes klasterinizə girişi onun sazlanması və ya saxlanmasına cavabdeh olan avtomatlaşdırma alətləri və idarəçilərlə məhdudlaşdırın." həmçinin bax təhlükəsizlik və texniki şərtlərə uyğunluq, habelə ehtiyatsız yazılmış Jenkins skriptindən etimadnamələri oğurlamaqla.
- İstifadəçi təcrübəsi. Kubectl kifayət qədər mürəkkəb olan Kubernetes obyekt modelinin mexanikasını ifşa edir. İdeal olaraq, istifadəçilər sistemlə daha yüksək abstraksiya səviyyəsində qarşılıqlı əlaqədə olmalıdırlar. Burada yenə Kelsiyə müraciət edəcəyəm və baxmağı tövsiyə edəcəyəm .
CI və CD arasındakı fərq
GitOps mövcud CI/CD modellərini təkmilləşdirir.
Müasir CI serveri orkestrasiya vasitəsidir. Xüsusilə, CI boru kəmərlərini təşkil etmək üçün bir vasitədir. Bunlara qurmaq, sınaqdan keçirmək, magistrala birləşdirmək və s. daxildir. CI serverləri mürəkkəb çoxmərhələli boru kəmərlərinin idarə edilməsini avtomatlaşdırır. Ümumi bir cazibə Kubernetes yeniləmələri toplusunu skript etmək və dəyişiklikləri klasterə təkan vermək üçün onu boru kəmərinin bir hissəsi kimi işə salmaqdır. Həqiqətən, bir çox mütəxəssis bunu edir. Ancaq bu optimal deyil və bunun səbəbi budur.
CI yenilənmələri magistrala köçürmək üçün istifadə edilməlidir və Kubernetes klasteri CD-ni daxildən idarə etmək üçün həmin yeniləmələrə əsasən özünü dəyişməlidir. Biz onu çağırırıq , CI təkan modelindən fərqli olaraq. CD hissəsidir icra vaxtı orkestri.
Niyə CI Serverləri Kubernetes-də Birbaşa Yeniləmələr vasitəsilə CD-lər etməməlidir
Bir sıra CI işləri kimi Kubernetes-ə birbaşa yeniləmələri təşkil etmək üçün CI serverindən istifadə etməyin. Bu, haqqında danışdığımız anti-naxışdır blogumda.
Alice və Bob-a qayıdaq.
Onlar hansı problemlərlə üzləşdilər? Bobun CI serveri dəyişiklikləri klasterə tətbiq edir, lakin bu prosesdə qəza baş verərsə, Bob klasterin hansı vəziyyətdə olduğunu (və ya olması lazım olduğunu) və ya onu necə düzəltməyi bilməyəcək. Müvəffəqiyyət halında da belədir.
Tutaq ki, Bobun komandası yeni bir görüntü yaratdı və sonra təsviri yerləşdirmək üçün yerləşdirmələrini düzəltdi (hamısı CI boru kəmərindən).
Təsvir normal qurulursa, lakin boru kəməri uğursuz olarsa, komanda aşağıdakıları başa düşməlidir:
- Yeniləmə yayılıb?
- Yeni bir quruluşa başlayırıq? Bu, lazımsız yan təsirlərə səbəb olacaq - eyni dəyişməz görüntünün iki quruluşuna sahib olmaq imkanı ilə?
- Quraşdırmanı işə salmazdan əvvəl növbəti yeniləməni gözləməliyikmi?
- Tam olaraq nə səhv oldu? Hansı addımları təkrarlamaq lazımdır (və hansıları təkrarlamaq təhlükəsizdir)?
Git əsaslı iş axınının qurulması Bob komandasının bu problemlərlə qarşılaşmayacağına zəmanət vermir. Onlar hələ də commit push, teq və ya başqa bir parametrlə səhv edə bilərlər; lakin, bu yanaşma hələ də açıq-aşkar ya hər şey, ya da heç bir yanaşmaya daha yaxındır.
Xülasə etmək üçün, CI serverlərinin CD ilə işləməməsinin səbəbi budur:
- Yeniləmə skriptləri həmişə deterministik olmur; Onlarda səhv etmək asandır.
- CI serverləri deklarativ klaster modelinə birləşmir.
- İdempotentliyə zəmanət vermək çətindir. İstifadəçilər sistemin dərin semantikasını başa düşməlidirlər.
- Qismən uğursuzluqdan sonra bərpa etmək daha çətindir.
Helm haqqında qeyd: Əgər Helm-dən istifadə etmək istəyirsinizsə, onu GitOps operatoru ilə birləşdirməyi məsləhət görürük, məsələn . Bu, konvergensiyanı təmin etməyə kömək edəcəkdir. Helmin özü nə determinist, nə də atomikdir.
GitOps Kubernetes üçün Davamlı Çatdırmağı həyata keçirməyin ən yaxşı yolu kimi
Alice və Bob-un komandası GitOps-u tətbiq edir və aşkar edir ki, proqram məhsulları ilə işləmək, yüksək performans və sabitliyi saxlamaq xeyli asanlaşıb. Gəlin bu məqaləni onların yeni yanaşmasının necə göründüyünü göstərən illüstrasiya ilə bitirək. Nəzərə alın ki, biz əsasən proqramlar və xidmətlər haqqında danışırıq, lakin GitOps bütün platformanı idarə etmək üçün istifadə edilə bilər.
Kubernetes üçün əməliyyat modeli
Aşağıdakı diaqrama baxın. O, Git və konteyner təsviri anbarını iki təşkil edilmiş həyat dövrü üçün paylaşılan resurslar kimi təqdim edir:
- Git-də faylları oxuyan və yazan və konteyner şəkillərinin anbarını yeniləyə bilən davamlı inteqrasiya kəməri.
- Yerləşdirməni idarəetmə və müşahidə qabiliyyəti ilə birləşdirən Runtime GitOps boru kəməri. Git-də faylları oxuyur və yazır və konteyner şəkillərini yükləyə bilir.
Əsas tapıntılar hansılardır?
- Narahatlıqların ayrılması: Nəzərə alın ki, hər iki boru kəməri yalnız Git və ya şəkil anbarını yeniləməklə əlaqə saxlaya bilər. Başqa sözlə, CI və iş vaxtı mühiti arasında bir firewall var. Biz buna "dəyişməzlik təhlükəsizlik divarı" deyirik (dəyişməz firewall), çünki bütün depo yeniləmələri yeni versiyalar yaradır. Bu mövzu haqqında ətraflı məlumat üçün 72-87-ci slaydlara baxın .
- İstənilən CI və Git serverindən istifadə edə bilərsiniz: GitOps istənilən komponentlə işləyir. Sevimli CI və Git serverlərinizdən, şəkil anbarlarından və test paketlərindən istifadə etməyə davam edə bilərsiniz. Bazardakı demək olar ki, bütün digər Davamlı Çatdırılma alətləri öz CI/Git serverini və ya şəkil anbarını tələb edir. Bu, bulud yerlisinin inkişafında məhdudlaşdırıcı amil ola bilər. GitOps ilə siz tanış alətlərdən istifadə edə bilərsiniz.
- Hadisələr inteqrasiya vasitəsi kimi: Git-dəki məlumatlar yenilənən kimi Weave Flux (və ya Weave Cloud operatoru) iş vaxtı barədə məlumat verir. Kubernetes hər dəfə dəyişiklik dəstini qəbul etdikdə Git yenilənir. Bu, aşağıda göstərildiyi kimi GitOps üçün iş axınlarının təşkili üçün sadə inteqrasiya modelini təqdim edir.
Nəticə
GitOps istənilən müasir CI/CD alətinin tələb etdiyi güclü yeniləmə zəmanətlərini təmin edir:
- avtomatlaşdırma;
- yaxınlaşma;
- gücsüzlük;
- determinizm.
Bu vacibdir, çünki bulud yerli tərtibatçıları üçün əməliyyat modeli təklif edir.
- Sistemlərin idarə edilməsi və monitorinqi üçün ənənəvi alətlər runbook çərçivəsində fəaliyyət göstərən əməliyyat qruplarına bağlıdır. (bir sıra rutin prosedurlar və əməliyyatlar - təqribən tərcümə.), xüsusi yerləşdirmə ilə bağlıdır.
- Bulud yerli idarəetməsində müşahidə alətləri inkişaf komandasının tez cavab verə bilməsi üçün yerləşdirmənin nəticələrini ölçməyin ən yaxşı yoludur.
Öz komandaları və yerləşdirmə planları ilə müxtəlif buludlara və bir çox xidmətlərə səpələnmiş çoxlu klasterləri təsəvvür edin. GitOps bütün bu bolluğu idarə etmək üçün miqyasda dəyişməz bir model təklif edir.
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «.
Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. xahiş edirəm.
Bu iki tərcümə Habré-də görünməzdən əvvəl GitOps haqqında bilirdinizmi?
-
Bəli, mən hər şeyi bilirdim
-
Yalnız səthi olaraq
-
Heç bir
35 istifadəçi səs verib. 10 istifadəçi bitərəf qalıb.
Mənbə: www.habr.com