Mənim adım Dmitri Sugrobov, mən Leroy Merlin-də tərtibatçıyam. Bu yazıda sizə Helm-in nə üçün lazım olduğunu, Kubernetes ilə işləməyi necə asanlaşdırdığını, üçüncü versiyada nələrin dəyişdiyini və fasiləsiz istehsalda tətbiqləri yeniləmək üçün ondan necə istifadə edəcəyinizi izah edəcəyəm.
Bu, konfransdakı çıxışa əsaslanan xülasədir by — oxumaq istəmirsinizsə, videoya baxın.
Niyə istehsalda Kubernetes istifadə edirik
Leroy Merlin Rusiya və Avropada DIY pərakəndə satış bazarında liderdir. Şirkətimizdə yüzdən çox tərtibatçı, 33 daxili işçi və hipermarketlərə və vebsayta baş çəkən çoxlu sayda insan var. Onların hamısını xoşbəxt etmək üçün biz sənaye standartı yanaşmalarına riayət etmək qərarına gəldik. Mikroservis arxitekturasından istifadə edərək yeni proqramların hazırlanması; mühitləri təcrid etmək və düzgün çatdırılmanı təmin etmək üçün konteynerlərdən istifadə edin; və orkestr üçün Kubernetes istifadə edin. Orkestrlərdən istifadənin qiyməti sürətlə ucuzlaşır: bazarda texnologiyanı bilən mühəndislərin sayı artır və provayderlər Kubernetes-i bir xidmət kimi təklif edirlər.
Kubernetes-in etdiyi hər şey, əlbəttə ki, başqa yollarla da edilə bilər, məsələn, bəzi Jenkins və docker-compose-ni skriptlərlə əhatə etməklə, amma hazır və etibarlı həll yolu varsa, həyatı niyə çətinləşdirir? Buna görə də biz Kubernetes-ə gəldik və artıq bir ildir ki, ondan istehsalda istifadə edirik. Hal-hazırda iyirmi dörd Kubernetes klasterimiz var, onlardan ən qədiminin yaşı bir ildən çoxdur və təxminən iki yüz poddur.
Kubernetes-də böyük YAML fayllarının lənəti
Kubernetes-də mikroservisi işə salmaq üçün ən azı beş YAML faylı yaradacağıq: Yerləşdirmə, Xidmət, Giriş, Konfiqurasiya Xəritəsi, Sirlər üçün - və onları klasterə göndərəcəyik. Növbəti tətbiq üçün eyni tıxac paketini yazacağıq, üçüncüsü ilə başqa birini yazacağıq və s. Sənədlərin sayını mühitlərin sayına vursaq, artıq yüzlərlə fayl alacağıq və bu hələ dinamik mühitləri nəzərə almır.
Helm-in əsas idarəçisi Adam Riz "konseptini təqdim etdi.", bu kimi görünür:
- Copy YAML - YAML faylını kopyalayın.
- YAML yapışdırın - yapışdırın.
- Girintiləri düzəldin - girintiləri düzəldin.
- Təkrar et - yenidən təkrar et.
Seçim işləyir, lakin YAML fayllarını dəfələrlə kopyalamalısınız. Bu dövrü dəyişdirmək üçün Helm icad edilmişdir.
Helm nədir
Birincisi, Helm - paket meneceri, bu sizə lazım olan proqramları tapıb quraşdırmanıza kömək edir. Məsələn, MongoDB-ni quraşdırmaq üçün rəsmi vebsayta girib ikili faylları yükləməyinizə ehtiyac yoxdur, sadəcə əmri yerinə yetirin. helm install stable/mongodb.
İkincisi, Helm - şablon mühərriki, faylları parametrləşdirməyə kömək edir. Kubernetes-də YAML faylları ilə bağlı vəziyyətə qayıdaq. Eyni YAML faylını yazmaq, ona Helm-in dəyərləri əvəz edəcəyi bəzi yer tutucular əlavə etmək daha asandır. Yəni, böyük bir iskele dəsti əvəzinə, lazımi dəyərlərin lazımi anda əvəz ediləcəyi bir sıra şablonlar olacaq.
Üçüncüsü, Helm - yerləşdirmə ustası. Bununla siz proqramları quraşdıra, geri qaytara və yeniləyə bilərsiniz. Bunu necə edəcəyimizi anlayaq.
Öz tətbiqlərinizi yerləşdirmək üçün Helm-dən necə istifadə etmək olar
Gəlin rəsmini izləyərək Helm müştərisini kompüterinizə quraşdıraq . Sonra YAML faylları dəsti yaradacağıq. Xüsusi dəyərləri qeyd etmək əvəzinə, Helm-in gələcəkdə məlumatla dolduracağı yer tutucuları tərk edəcəyik. Belə fayllar toplusuna Helm diaqramı deyilir. Helm konsol müştərisinə üç yolla göndərilə bilər:
- şablonları olan bir qovluğu göstərin;
- arxivi .tar-a yığın və ona işarə edin;
- şablonu uzaq depoya yerləşdirin və Helm müştərisində depoya keçid əlavə edin.
Sizə dəyərləri olan bir fayl da lazımdır - values.yaml. Oradan məlumatlar şablona daxil ediləcək. Gəlin onu da yaradaq.
Helmin ikinci versiyasında əlavə server proqramı var - Tiller. O, Kubernetes-dən kənarda dayanır və Helm müştərisindən sorğu gözləyir və çağırıldıqda tələb olunan dəyərləri şablonda əvəz edir və Kubernetes-ə göndərir.
Helm 3 daha sadədir: şablonları serverdə emal etmək əvəzinə, məlumat indi tamamilə Helm müştəri tərəfində işlənir və birbaşa Kubernetes API-yə göndərilir. Bu sadələşdirmə klaster təhlükəsizliyini yaxşılaşdırır və yayılma sxemini asanlaşdırır.
Hamısı necə işləyir
Komandanı işə salın helm install. Proqram buraxılışının adını göstərək və values.yaml yolunu verək. Sonda biz diaqramın yerləşdiyi anbarı və diaqramın adını göstərəcəyik. Nümunədə bunlar müvafiq olaraq “lmru” və “bestchart”dır.
helm install --name bestapp --values values.yaml lmru/bestchart
Əmr yalnız bir dəfə yerinə yetirilə bilər, yerinə yenidən yerinə yetirildikdə install istifadə etmək lazımdır upgrade. Sadəlik üçün iki əmr əvəzinə əmri icra edə bilərsiniz upgrade əlavə açar ilə --install. İlk dəfə icra edildikdə, Helm buraxılışı quraşdırmaq üçün əmr göndərəcək və gələcəkdə onu yeniləyəcək.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Helm ilə tətbiqin yeni versiyalarını yerləşdirməyin tələləri
Hekayənin bu nöqtəsində tamaşaçılarla Kim Milyoner Olmaq İstəyir filmini oynayıram və biz Helm-i proqramın versiyasını yeniləmək üçün necə əldə edəcəyimizi düşünürük. .
Helm-in necə işlədiyini öyrənərkən, işləyən proqramların versiyalarını yeniləməyə çalışarkən qəribə davranış məni təəccübləndirdi. Tətbiq kodunu yenilədim, Docker reyestrinə yeni şəkil yüklədim, yerləşdirmə əmrini göndərdim - və heç nə olmadı. Aşağıda tətbiqləri yeniləmək üçün tamamilə uğurlu olmayan bəzi yollar verilmişdir. Onların hər birini daha ətraflı öyrənərək, alətin daxili quruluşunu və bu açıq-aşkar olmayan davranışın səbəblərini anlamağa başlayırsınız.
Metod 1. Son buraxılışdan sonra məlumatları dəyişdirməyin
Kak glasit Helm, "Kubernetes diaqramları böyük və mürəkkəb ola bilər, ona görə də Helm heç bir şeyə çox toxunmamağa çalışır." Buna görə də, docker registrində tətbiq şəklinin ən son versiyasını yeniləsəniz və əmri işlətsəniz helm upgrade, onda heç nə olmayacaq. Helm heç nəyin dəyişmədiyini düşünəcək və tətbiqi yeniləmək üçün Kubernetes-ə əmr göndərməyə ehtiyac yoxdur.
Burada və aşağıda, ən son etiket yalnız nümunə olaraq göstərilir. Bu teqi təyin etdiyiniz zaman, Kubernetes imagePullPolicy parametrindən asılı olmayaraq hər dəfə şəkli docker reyestrindən endirəcək. Ən son istehsalatdan istifadə arzuolunmazdır və yan təsirlərə səbəb olur.
Metod 2. Şəkildəki LABEL-i yeniləyin
Eyni şəkildə yazıldığı kimi , “Helm tətbiqi yalnız sonuncu buraxılışdan sonra dəyişdikdə yeniləyəcək.” Bunun üçün məntiqi seçim, docker görüntüsünün özündə LABEL-i yeniləmək kimi görünür. Bununla belə, Helm proqram şəkillərinə baxmır və onlara edilən hər hansı dəyişiklik barədə heç bir fikri yoxdur. Müvafiq olaraq, şəkildəki etiketləri yeniləyərkən Helm onlar haqqında bilməyəcək və tətbiq yeniləmə əmri Kubernetes-ə göndərilməyəcək.
Metod 3: Açardan istifadə edin --force
Gəlin təlimatlara müraciət edək və lazımi açarı axtaraq. Açar ən mənalıdır --force. Aydın adına baxmayaraq, davranış gözləniləndən fərqlidir. Proqram yeniləməsini məcbur etmək əvəzinə, onun əsl məqsədi UĞURSUZ statusunda olan buraxılışı bərpa etməkdir. Bu düymədən istifadə etməsəniz, əmrləri ardıcıl olaraq yerinə yetirməlisiniz helm delete && helm install --replace. Bunun əvəzinə açardan istifadə etmək tövsiyə olunur --force, bu əmrlərin ardıcıl icrasını avtomatlaşdırır. Bu barədə ətraflı məlumat . Helm-ə proqram versiyasını yeniləməyi söyləmək üçün təəssüf ki, bu açar işləməyəcək.
Metod 4. Etiketləri birbaşa Kubernetes-də dəyişdirin
Komandadan istifadə edərək etiketin birbaşa klasterdə yenilənməsi kubectl edit - Pis fikir. Bu hərəkət çalışan proqram ilə ilkin olaraq yerləşdirmə üçün göndərilmiş proqram arasında məlumatın uyğunsuzluğuna səbəb olacaq. Bu halda Helm-in yerləşdirmə zamanı davranışı onun versiyasından fərqlənir: Helm 2 heç nə etməyəcək, Helm 3 isə tətbiqin yeni versiyasını yerləşdirəcək. Bunun səbəbini başa düşmək üçün Helmin necə işlədiyini başa düşməlisiniz.
Helm necə işləyir?
Tətbiqin son buraxılışından sonra dəyişib-dəyişmədiyini müəyyən etmək üçün Helm istifadə edə bilər:
- Kubernetes-də işləyən proqram;
- yeni dəyərlər.yaml və cari diaqram;
- Helmin daxili buraxılış məlumatları.
Daha maraqlısı üçün: Helm buraxılışlar haqqında daxili məlumatları harada saxlayır?Əmri yerinə yetirməklə helm history, biz Helm istifadə edərək quraşdırılmış versiyalar haqqında bütün məlumatları əldə edəcəyik.
Göndərilən şablonlar və dəyərlər haqqında ətraflı məlumat da var. Biz bunu tələb edə bilərik:
Helm-in ikinci versiyasında bu məlumat “OWNER=TILLER” etiketi ilə qeyd olunan Konfiqurasiya Xəritəsində Tillerin işlədiyi eyni ad məkanında (defolt olaraq kub sistemi) yerləşir:
Helm-in üçüncü versiyası görünəndə məlumat sirrlərə və tətbiqin işlədiyi eyni ad sahəsinə keçdi. Bunun sayəsində eyni buraxılış adı ilə müxtəlif ad məkanlarında eyni vaxtda bir neçə proqramı işə salmaq mümkün oldu. İkinci versiyada ad boşluqları təcrid olunduqda, lakin bir-birinə təsir edə bildikdə ciddi başağrısı idi.
İkinci Helm, yeniləməyə ehtiyac olub-olmadığını anlamağa çalışarkən yalnız iki məlumat mənbəyindən istifadə edir: indi ona təqdim olunanlar və ConfigMap-də olan buraxılışlar haqqında daxili məlumat.
Üçüncü Helm üçtərəfli birləşmə strategiyasından istifadə edir: bu məlumatlara əlavə olaraq, hazırda Kubernetes-də işləyən tətbiqi də nəzərə alır.
Bu səbəbdən Helm-in köhnə versiyası heç bir iş görməyəcək, çünki o, klasterdəki tətbiq məlumatlarını nəzərə almır, lakin Helm 3 dəyişiklikləri qəbul edəcək və yerləşdirmə üçün yeni tətbiqi göndərəcək.
Metod 5. --recreate-pods keçidindən istifadə edin
Açarla --recreate-pods açarla əvvəlcə əldə etməyi planlaşdırdığınız şeyə nail ola bilərsiniz --force. Konteynerlər yenidən işə düşəcək və imagePullPolicy: Həmişə ən son teq üçün siyasətə uyğun olaraq (bu barədə daha çox yuxarıdakı qeyddə) Kubernetes şəklin yeni versiyasını endirib işə salacaq. Bu, ən yaxşı şəkildə edilməyəcək: yerləşdirmənin Strategiya Növünü nəzərə almadan, bütün köhnə tətbiq nümunələrini qəfil söndürəcək və yenilərini işə salmağa başlayacaq. Yenidən başlatma zamanı sistem işləməyəcək, istifadəçilər əziyyət çəkəcəklər.
Kubernetesin özündə də oxşar problem uzun müddət mövcud idi. İndi, açılışdan 4 il sonra , problem həll edildi və Kubernetes-in 1.15 versiyasından başlayaraq, podları yuvarla-yenidən başlatma imkanı görünür.
Helm sadəcə olaraq bütün proqramları söndürür və yaxınlıqda yeni konteynerləri işə salır. Tətbiqin dayanmasına səbəb olmamaq üçün istehsalda bunu edə bilməzsiniz. Bu, yalnız inkişaf ehtiyacları üçün lazımdır və yalnız səhnə mühitlərində həyata keçirilə bilər.
Helm istifadə edərək proqram versiyasını necə yeniləmək olar?
Helm-ə göndərilən dəyərləri dəyişdirəcəyik. Tipik olaraq, bunlar şəkil etiketinin yerinə əvəz olunan dəyərlərdir. Tez-tez qeyri-məhsuldar mühitlər üçün istifadə olunan ən son vəziyyətində, dəyişkən məlumat Kubernetesin özü üçün faydasız olan annotasiyadır və Helm üçün tətbiqi yeniləmək ehtiyacı üçün bir siqnal rolunu oynayacaqdır. Annotasiya dəyərini doldurmaq üçün seçimlər:
- Təsadüfi dəyər standart funksiyadan istifadə edərək -
{{ randAlphaNum 6 }}.
Bir xəbərdarlıq var: belə bir dəyişəni olan bir diaqramdan istifadə edərək hər yerləşdirmədən sonra annotasiya dəyəri unikal olacaq və Helm dəyişikliklərin olduğunu güman edəcək. Belə çıxır ki, biz onun versiyasını dəyişməmiş olsaq belə, həmişə proqramı yenidən başladacağıq. Bu kritik deyil, çünki fasilə olmayacaq, amma yenə də xoşagəlməzdir. - Cari yapışdırın Tarix və saat -
{{ .Release.Date }}.
Variant daimi unikal dəyişənə malik təsadüfi dəyərə bənzəyir. - Daha düzgün yol istifadə etməkdir yoxlama məbləğləri. Bu, şəklin SHA-sı və ya git-də son öhdəliyin SHA-sıdır -
{{ .Values.sha }}.
Onları hesablamaq və çağıran tərəfdəki Helm müştərisinə göndərmək lazımdır, məsələn, Jenkinsdə. Tətbiq dəyişibsə, yoxlama məbləği dəyişəcək. Buna görə də, Helm tətbiqi yalnız lazım olduqda yeniləyəcək.
Gəlin cəhdlərimizi ümumiləşdirək
- Helm ən az invaziv şəkildə dəyişikliklər edir, ona görə də Docker Registry-də tətbiq təsviri səviyyəsində hər hansı dəyişiklik yeniləmə ilə nəticələnməyəcək: əmr yerinə yetirildikdən sonra heç bir şey olmayacaq.
- Açar
--forceproblemli buraxılışları bərpa etmək üçün istifadə olunur və məcburi yeniləmələrlə əlaqəli deyil. - Açar
--recreate-podstətbiqləri zorla yeniləyəcək, lakin bunu vandal şəkildə edəcək: bütün konteynerləri qəfil söndürəcək. İstifadəçilər bundan əziyyət çəkəcək; bunu istehsalda etməməlisiniz. - Komandadan istifadə edərək birbaşa Kubernetes klasterində dəyişikliklər edin
kubectl editetməyin: biz ardıcıllığı pozacağıq və davranış Helm versiyasından asılı olaraq fərqli olacaq. - Helmin yeni versiyasının buraxılması ilə bir çox nüanslar ortaya çıxdı. Helm deposundakı məsələlər aydın dildə təsvir edilmişdir, onlar sizə təfərrüatları başa düşməyə kömək edəcəkdir.
- Qrafikə redaktə edilə bilən annotasiya əlavə etmək onu daha çevik edəcək. Bu, proqramın fasiləsiz olaraq düzgün şəkildə yayılmasına imkan verəcək.
Həyatın bütün sahələrində işləyən "dünya sülhü" düşüncəsi: istifadə etməzdən əvvəl təlimatları oxuyun, sonra deyil. Yalnız tam məlumatla etibarlı sistemlər qurmaq və istifadəçiləri sevindirmək mümkün olacaq.
Digər əlaqəli bağlantılar:
Bu hesabat ilk dəfə olaraq təqdim olunub Mail.ru Cloud Solutions tərəfindən. Bax digər tamaşalar və Telegram-da hadisələrin elanlarına abunə olun .
Mənbə: www.habr.com