Qeyd. tərcümə.: Kubernetes icmasında, şəxsən gördüyümüz kimi, GitOps adlı bir tendensiya açıq-aşkar populyarlıq qazanır. KubeCon Europe 2019. Bu termin nisbətən yeni idi Weaveworks-in rəhbəri - Alexis Richardson - və əməliyyat problemlərini həll etmək üçün tərtibatçılara tanış olan alətlərin (ilk növbədə Git, buna görə də adı) istifadəsini nəzərdə tutur. Xüsusilə, biz Kubernetes-in konfiqurasiyalarını Git-də saxlamaq və avtomatik olaraq klasterə dəyişiklikləri yaymaqla işləməsindən danışırıq. Matthias Jg bu məqalədə bu yayıma iki yanaşma haqqında danışır.
Keçən il (əslində bu, rəsmi olaraq 2017-ci ilin avqustunda baş verdi - təqribən tərcümə.) Kubernetes-də tətbiqlərin yerləşdirilməsi üçün yeni bir yanaşma var. Bu, GitOps adlanır və yerləşdirmə versiyalarının Git deposunun təhlükəsiz mühitində izlənilməsi ilə bağlı əsas fikrə əsaslanır.
Bu yanaşmanın əsas üstünlükləri aşağıdakılardır::
- Yerləşdirmə versiyası və dəyişiklik tarixçəsi. Bütün klasterin vəziyyəti Git deposunda saxlanılır və yerləşdirmələr yalnız tapşırıqlar vasitəsilə yenilənir. Bundan əlavə, bütün dəyişikliklər öhdəliyin tarixçəsindən istifadə etməklə izlənilə bilər.
- Tanış Git əmrlərindən istifadə edərək geri qaytarma. Sadə
git resetyerləşdirmələrdə dəyişiklikləri yenidən qurmağa imkan verir; keçmiş dövlətlər həmişə mövcuddur. - Hazır giriş nəzarəti. Tipik olaraq, Git sistemi çoxlu həssas məlumatları ehtiva edir, buna görə də əksər şirkətlər onun qorunmasına xüsusi diqqət yetirirlər. Müvafiq olaraq, bu qoruma yerləşdirmə ilə əməliyyatlara da aiddir.
- Yerləşdirmə üçün siyasətlər. Əksər Git sistemləri yerli olaraq filiallar üzrə siyasətləri dəstəkləyir - məsələn, yalnız çəkmə sorğuları masterı yeniləyə bilər və dəyişikliklər başqa komanda üzvü tərəfindən nəzərdən keçirilməli və qəbul edilməlidir. Giriş nəzarətində olduğu kimi, eyni siyasətlər yerləşdirmə yeniləmələrinə də tətbiq edilir.
Gördüyünüz kimi, GitOps metodunun bir çox üstünlükləri var. Son bir il ərzində iki yanaşma xüsusi populyarlıq qazandı. Biri təkan, digəri isə çəkmə əsaslıdır. Onlara baxmazdan əvvəl gəlin əvvəlcə tipik Kubernetes yerləşdirmələrinin necə göründüyünə baxaq.
Yerləşdirmə üsulları
Son illərdə Kubernetes-də yerləşdirmə üçün müxtəlif üsullar və alətlər qurulmuşdur:
- Doğma Kubernetes/Kustomize şablonlarına əsaslanır. Bu, tətbiqləri Kubernetes-də yerləşdirməyin ən asan yoludur. Tərtibatçı əsas YAML fayllarını yaradır və onları tətbiq edir. Eyni şablonları daim yenidən yazmaqdan xilas olmaq üçün Kustomize hazırlanmışdır (Kubernetes şablonlarını modullara çevirir). Qeyd. tərcümə.: Kustomize kubectl ilə inteqrasiya olunub .
- Dəbilqə qrafikləri. Dəmir diaqramları sizə şablon əsaslı yanaşma ilə müqayisədə daha çevik fərdiləşdirmə seçimləri ilə tətbiqləri yerləşdirmək üçün istifadə olunan şablon dəstləri, başlanğıc konteynerləri, yan arabalar və s. yaratmağa imkan verir. Bu üsul şablon YAML fayllarına əsaslanır. Helm onları müxtəlif parametrlərlə doldurur və sonra onları klasterdə yerləşdirən və yeniləmələrə və geri çəkilməyə imkan verən klaster komponenti olan Tiller-ə göndərir. Əsas odur ki, Helm sadəcə olaraq şablonlara istədiyiniz dəyərləri daxil edir və sonra onları ənənəvi yanaşmada olduğu kimi tətbiq edir. (bütün bunların necə işlədiyi və ondan necə istifadə edə biləcəyiniz haqqında ətraflı oxuyun - təqribən. tərcümə.). Geniş çeşidli tapşırıqları əhatə edən çox sayda hazır Helm diaqramları var.
- Alternativ Alətlər. Bir çox alternativ vasitə var. Onların hamısının ortaq cəhəti odur ki, bəzi şablon faylları Kubernetes tərəfindən oxuna bilən YAML fayllarına çevirir və sonra onlardan istifadə edirlər.
İşimizdə biz daim vacib alətlər üçün Helm diaqramlarından (çünki onlarda artıq hazır olan çox şey var, bu da həyatı asanlaşdırır) və öz tətbiqlərimizi yerləşdirmək üçün “təmiz” Kubernetes YAML fayllarından istifadə edirik.
Çək və itələyin
Son bloq yazılarımdan birində aləti təqdim etdim , bu sizə şablonları Git repozitoriyasına yerləşdirməyə və konteynerin hər öhdəsindən və ya təkanından sonra yerləşdirməni yeniləməyə imkan verir. Təcrübəm göstərir ki, bu alət çəkmə yanaşmasını təşviq edən əsas vasitələrdən biridir, ona görə də tez-tez ona istinad edəcəyəm. Onu necə istifadə edəcəyiniz haqqında daha çox bilmək istəyirsinizsə, burada .
NB! GitOps-dan istifadənin bütün faydaları hər iki yanaşma üçün eyni qalır.
Çəkməyə əsaslanan yanaşma
Çəkmə yanaşması bütün dəyişikliklərin klaster daxilindən tətbiq edilməsinə əsaslanır. Klaster daxilində əlaqəli Git və Docker Registry repozitoriyalarını müntəzəm olaraq yoxlayan bir operator var. Onlarda hər hansı bir dəyişiklik olarsa, klasterin vəziyyəti daxili olaraq yenilənir. Bu proses ümumiyyətlə çox təhlükəsiz hesab olunur, çünki heç bir xarici müştərinin klaster inzibatçı hüquqlarına çıxışı yoxdur.
Pros:
- Heç bir xarici müştərinin çoxluqda dəyişiklik etmək hüququ yoxdur; bütün yeniləmələr daxildən yayılır.
- Bəzi alətlər həmçinin Helm chart yeniləmələrini sinxronizasiya etməyə və onları çoxluqla əlaqələndirməyə imkan verir.
- Docker Registry yeni versiyalar üçün skan edilə bilər. Əgər yeni şəkil mövcuddursa, Git repozitoriyası və yerləşdirilməsi yeni versiyaya yenilənir.
- Çəkmə alətləri müxtəlif Git depoları və icazələri ilə müxtəlif ad məkanlarında paylana bilər. Bunun sayəsində çox kirayəçi modeldən istifadə etmək olar. Məsələn, A komandası A ad məkanından, B komandası B ad məkanından və infrastruktur komandası qlobal məkandan istifadə edə bilər.
- Bir qayda olaraq, alətlər çox yüngüldür.
- operator kimi alətlərlə birləşdirilir , sirlər Git deposunda şifrələnmiş şəkildə saxlanıla və klaster daxilində əldə edilə bilər.
- Yerləşdirmələr klaster daxilində baş verdiyi üçün CD boru kəmərləri ilə əlaqə yoxdur.
Eksiler:
- Helm diaqramlarından yerləşdirmə sirlərini idarə etmək adi olanlardan daha çətindir, çünki onlar əvvəlcə məsələn, möhürlənmiş sirrlər şəklində yaradılmalı, sonra daxili operator tərəfindən deşifrə edilməli və yalnız bundan sonra onlar çəkmə aləti üçün əlçatan olur. Sonra buraxılışı Helm-də artıq yerləşdirilmiş sirrlərdəki dəyərlərlə işlədə bilərsiniz. Ən asan yol, yerləşdirmə üçün istifadə olunan bütün Helm dəyərləri ilə bir sirr yaratmaq, onun şifrəsini açmaq və Git-ə təhvil verməkdir.
- Bir çəkmə yanaşması tətbiq etdikdə, alətləri çəkməklə bağlı olursunuz. Bu, klasterdə yerləşdirmə prosesini fərdiləşdirmək imkanını məhdudlaşdırır. Məsələn, Kustomize son şablonlar Git-ə daxil edilməzdən əvvəl işləməlidir ki, mürəkkəbdir. Müstəqil alətlərdən istifadə edə bilməyəcəyinizi demirəm, lakin onların yerləşdirmə prosesinizə inteqrasiyası daha çətindir.
Push əsaslı yanaşma
Təkan yanaşmasında xarici sistem (əsasən CD boru kəmərləri) Git repozitoriyasına öhdəlik götürdükdən sonra və ya əvvəlki CI boru kəməri uğurlu olarsa, klasterə yerləşdirmələri işə salır. Bu yanaşmada sistemin klasterə çıxışı var.
Pros:
- Təhlükəsizlik Git deposu və tikinti kəməri ilə müəyyən edilir.
- Helm diaqramlarının yerləşdirilməsi daha asandır və Helm plaginlərini dəstəkləyir.
- Sirləri idarə etmək daha asandır, çünki sirlər boru kəmərlərində istifadə oluna bilər və həmçinin Git-də şifrələnmiş şəkildə saxlanıla bilər (istifadəçinin seçimlərindən asılı olaraq).
- Müəyyən bir alətlə əlaqə yoxdur, çünki istənilən növ istifadə edilə bilər.
- Konteyner versiyası yeniləmələri tikinti boru kəməri ilə başlana bilər.
Eksiler:
- Klasterə giriş məlumatları qurma sisteminin daxilindədir.
- Yerləşdirmə qablarını yeniləmək hələ də çəkmə prosesi ilə daha asandır.
- CD sistemindən güclü asılılıq, çünki bizə lazım olan boru kəmərləri ilkin olaraq Gitlab Runners üçün yazılmış ola bilər və sonra komanda Azure DevOps və ya Jenkins-ə keçməyə qərar verir... və çoxlu sayda tikinti boru kəmərlərini köçürməli olacaq.
Nəticələr: itələyin yoxsa çəkin?
Adətən olduğu kimi, hər bir yanaşmanın müsbət və mənfi tərəfləri var. Bəzi tapşırıqları biri ilə yerinə yetirmək daha asandır, digəri ilə daha çətindir. Əvvəlcə yerləşdirmələri əl ilə edirdim, lakin Weave Flux haqqında bir neçə məqalə ilə rastlaşdıqdan sonra bütün layihələr üçün GitOps proseslərini həyata keçirmək qərarına gəldim. Əsas şablonlar üçün bu asan idi, lakin sonra Helm diaqramlarında çətinlik çəkməyə başladım. O zaman Weave Flux yalnız Helm Chart Operator-un ibtidai versiyasını təklif edirdi, lakin indi də bəzi tapşırıqlar sirləri əl ilə yaratmaq və onları tətbiq etmək ehtiyacına görə daha çətindir. Siz mübahisə edə bilərsiniz ki, çəkmə yanaşması daha təhlükəsizdir, çünki klasterin etimadnamələri klasterdən kənarda əlçatan deyil və onu o qədər təhlükəsiz edir ki, əlavə səylərə dəyər.
Bir qədər düşündükdən sonra gözlənilmədən belə qənaətə gəldim ki, bu belə deyil. Maksimum qorunma tələb edən komponentlərdən danışsaq, bu siyahıya gizli saxlama, CI/CD sistemləri və Git repozitoriyaları daxil olacaq. Onların içindəki məlumatlar çox həssasdır və maksimum qorunma tələb edir. Əlavə olaraq, əgər kimsə Git repozitoriyanıza daxil olarsa və kodu oraya basa bilsə, o, istədiklərini (çəkin və ya təkan olsun) yerləşdirə və klasterin sistemlərinə sıza bilər. Beləliklə, qorunmalı olan ən vacib komponentlər klaster etimadnamələri deyil, Git repozitoriyası və CI/CD sistemləridir. Bu tip sistemlər üçün yaxşı konfiqurasiya edilmiş siyasətləriniz və təhlükəsizlik nəzarətləriniz varsa və klaster etimadnamələri yalnız sirr kimi boru kəmərlərinə çıxarılırsa, çəkmə yanaşmasının əlavə təhlükəsizliyi ilkin düşündüyü kimi dəyərli olmaya bilər.
Beləliklə, çəkmə yanaşması daha çox əmək tələb edirsə və təhlükəsizlik faydası vermirsə, yalnız təkan yanaşmasından istifadə etmək məntiqli deyilmi? Ancaq kimsə iddia edə bilər ki, təkan yanaşmasında CD sisteminə çox bağlısınız və bəlkə də gələcəkdə miqrasiyanı həyata keçirmək daha asan olması üçün bunu etməmək daha yaxşıdır.
Mənim fikrimcə (həmişə olduğu kimi), müəyyən bir iş və ya kombinasiya üçün ən uyğun olanı istifadə etməlisiniz. Şəxsən mən hər iki yanaşmadan istifadə edirəm: əsasən öz xidmətlərimizi ehtiva edən çəkmə əsaslı yerləşdirmələr üçün Weave Flux və Helm və plaginlərlə təkan yanaşması, Helm diaqramlarını klasterə tətbiq etməyi asanlaşdırır və sizə sirləri qüsursuz şəkildə yaratmağa imkan verir. Düşünürəm ki, heç vaxt bütün hallarda uyğun tək bir həll olmayacaq, çünki həmişə çoxlu nüanslar var və onlar konkret tətbiqdən asılıdır. Bununla belə, mən GitOps-u çox tövsiyə edirəm - bu, həyatı çox asanlaşdırır və təhlükəsizliyi artırır.
Ümid edirəm ki, bu mövzu ilə bağlı təcrübəm yerləşdirmə növünüz üçün hansı metodun daha uyğun olduğuna qərar verməyə kömək edəcək və fikirlərinizi eşitməkdən məmnun olaram.
PS Tərcüməçidən qeyd
Çəkmə modelinin mənfi tərəfi odur ki, göstərilən manifestləri Git-ə yerləşdirmək çətindir, lakin heç bir mənfi cəhət yoxdur ki, çəkilmə modelindəki CD boru kəməri buraxılışdan ayrı yaşayır və mahiyyətcə kateqoriya boru kəmərinə çevrilir. Davamlı müraciət. Buna görə də, onların statusunu bütün yerləşdirmələrdən toplamaq və hər hansı bir şəkildə, tercihen CD sisteminə istinad edərək qeydlərə/statuslara çıxışı təmin etmək üçün daha çox səy tələb olunacaq.
Bu mənada, təkan modeli bizə ən azı satışa dair bəzi zəmanətləri təmin etməyə imkan verir, çünki boru kəmərinin istifadə müddəti buraxılış müddətinə bərabər edilə bilər.
Hər iki modeli sınadıq və məqalənin müəllifi ilə eyni nəticəyə gəldik:
- Çəkmə modeli çox sayda klasterdə sistem komponentlərinin yenilənməsini təşkil etmək üçün bizə uyğundur (bax. ).
- GitLab CI-yə əsaslanan təkan modeli, Helm diaqramlarından istifadə edərək tətbiqləri yaymaq üçün yaxşı uyğun gəlir. Eyni zamanda, alətdən istifadə etməklə boru kəmərləri daxilində yerləşdirmələrin yayılmasına nəzarət edilir . Yeri gəlmişkən, bu layihəmizin kontekstində biz KubeCon Europe'19 stendimizdə DevOps mühəndislərinin aktual problemlərini müzakirə edərkən daimi “GitOps” eşitdik.
Tərcüməçidən PPS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. xahiş edirəm.
GitOps istifadə edirsiniz?
-
Bəli, yaxınlaşma
-
Bəli, itələyin
-
Bəli, çəkin + itələyin
-
Bəli, başqa bir şey
-
Heç bir
30 istifadəçi səs verib. 10 istifadəçi bitərəf qalıb.
Mənbə: www.habr.com