Hamıya salam! Mənim adım Pavel Agaletsky. Mən Lamoda çatdırılma sistemini inkişaf etdirən komandada komanda lideri kimi işləyirəm. 2018-ci ildə mən HighLoad ++ konfransında çıxış etdim və bu gün hesabatımın stenoqramını təqdim etmək istəyirəm.

Mənim mövzum müxtəlif mühitlərdə sistem və xidmətlərin yerləşdirilməsi üzrə şirkətimizin təcrübəsinə həsr olunub. Bütün sistemləri adi virtual serverlərə yerləşdirdiyimiz tarixdən əvvəlki dövrlərdən başlayaraq, Nomad-dan Kubernetes yerləşdirməsinə tədricən keçidlə başa çatır. Bunu nə üçün etdiyimizi və prosesdə hansı problemlərlə üzləşdiyimizi söyləyəcəyəm.

Tətbiqləri VM-də yerləşdirin

Gəlin ondan başlayaq ki, 3 il əvvəl şirkətin bütün sistemləri və xidmətləri adi virtual serverlərdə yerləşdirilib. Texniki olaraq, sistemlərimizin bütün kodlarının yerləşdirildiyi və jenkins istifadə edərək avtomatik montaj alətləri ilə yığıldığı şəkildə təşkil edilmişdir. Ansible-ın köməyi ilə o, artıq versiyaya nəzarət sistemimizdən virtual serverlərə yayıldı. Eyni zamanda, şirkətimizdə olan hər bir sistem ən azı 2 serverə yerləşdirildi: onlardan biri başda, ikincisi quyruqda. Bu iki sistem bütün parametrləri, gücü, konfiqurasiyası və s. baxımından bir-biri ilə tamamilə eyni idi. Aralarındakı yeganə fərq o idi ki, baş istifadəçi trafiki alırdı, quyruq isə heç vaxt özü üçün istifadəçi trafiki almamışdı.

Nə üçün idi?

Tətbiqimizin yeni buraxılışlarını yerləşdirərkən, istifadəçilər üçün nəzərəçarpacaq nəticələr olmadan, problemsiz şəkildə yayıla bilmək istəyirdik. Bu, Ansible-dan istifadə edərək növbəti tərtib edilmiş buraxılışın quyruğa yuvarlanması səbəbindən əldə edildi. Orada yerləşdirmə ilə məşğul olan insanlar hər şeyin qaydasında olduğunu yoxlaya və əmin ola bilərdilər: bütün ölçülər, bölmələr və proqramlar işləyir; lazımi skriptlər işə salınır. Yalnız hər şeyin qaydasında olduğuna əmin olduqdan sonra nəqliyyatın hərəkəti dəyişdirildi. Daha əvvəl quyruq olan serverə getməyə başladı. Tətbiqimizin əvvəlki versiyasında mövcud olduğu halda, əvvəllər baş olan istifadəçi trafiki olmadan qaldı.

Beləliklə, istifadəçilər üçün problemsiz idi. Çünki keçid ani olur, çünki bu, sadəcə balanslaşdırıcı keçiddir. Sadəcə balanslaşdırıcını geriyə dəyişdirməklə əvvəlki versiyaya qayıtmaq çox asandır. Biz həmçinin istifadəçi trafiki ona getməzdən əvvəl proqramın istehsala hazır olmasına əmin ola bilərdik ki, bu da olduqca rahat idi.

Bütün bunlarda hansı fəzilətləri görürük?

1. Əvvəla, kifayətdir sadəcə işləyir. Hər kəs belə bir yerləşdirmə sxeminin necə işlədiyini başa düşür, çünki insanların çoxu nə vaxtsa adi virtual serverlərə yerləşdirilib.
2. Bu kifayətdir etibarlı, yerləşdirmə texnologiyası sadə olduğundan, minlərlə şirkət tərəfindən sınaqdan keçirilmişdir. Milyonlarla server bu şəkildə yerləşdirilir. Nəyisə qırmaq çətindir.
3. Və nəhayət əldə edə bildik atom yerləşdirmələri. Köhnə versiya ilə yeni versiya arasında keçidin nəzərə çarpan mərhələsi olmadan istifadəçilər üçün eyni vaxtda baş verən yerləşdirmələr.

Ancaq bütün bunlarda bir sıra çatışmazlıqlar da gördük:

1. İstehsal mühiti, inkişaf mühiti ilə yanaşı, başqa mühitlər də var. Məsələn, qa və preproduction. O vaxt bizim çoxlu serverlərimiz və 60-a yaxın xidmətimiz var idi. Bu səbəbdən məcbur idi hər bir xidmət üçün onun ən son versiyasını qoruyun virtual maşın. Bundan əlavə, kitabxanaları yeniləmək və ya yeni asılılıqlar quraşdırmaq istəyirsinizsə, bunu bütün mühitlərdə etməlisiniz. Həmçinin proqramınızın növbəti yeni versiyasını yerləşdirməyə hazırlaşacağınız vaxtı devops-un lazımi mühit parametrlərini yerinə yetirdiyi vaxtla sinxronlaşdırmaq lazım idi. Bu vəziyyətdə, ətrafımızın ardıcıl olaraq bütün mühitlərdə bir anda bir qədər fərqli olacağı bir vəziyyətə düşmək asandır. Məsələn, QA mühitində kitabxanaların bəzi versiyaları, istehsalda isə digərləri olacaq ki, bu da problemlərə gətirib çıxaracaq.
2. Asılılıqları yeniləməkdə çətinlik ərizəniz. Bu, sizdən deyil, digər komandadan asılıdır. Yəni, serverləri qoruyan devops komandasından. Onlara müvafiq tapşırıq verməli və nə etmək istədiyinizi təsvir etməlisiniz.
3. O zaman biz də əlimizdə olan iri iri monolitləri ayrı-ayrı kiçik xidmətlərə bölmək istəyirdik, çünki onların sayının getdikcə daha çox olacağını başa düşdük. O zaman bizdə onların 100-dən çoxu var idi.Hər yeni xidmət üçün ayrıca yeni virtual maşın yaratmaq lazım idi ki, ona da xidmət göstərilməli və yerləşdirilməlidir. Bundan əlavə, bir avtomobil deyil, ən azı iki lazımdır. Bütün bunlara QA mühiti əlavə olunur. Bu, problemlərə səbəb olur və sizin üçün yeni sistemlər qurmağı və işə salmağı çətinləşdirir. mürəkkəb, bahalı və uzun prosesdir.

Buna görə də qərara gəldik ki, adi virtual maşınların yerləşdirilməsindən tətbiqlərimizi docker konteynerində yerləşdirməyə keçmək daha rahat olacaq. Dockeriniz varsa, tətbiqi klasterdə işlədə bilən bir sistemə ehtiyacınız var, çünki sadəcə belə bir konteyner qaldıra bilməzsiniz. Adətən nə qədər konteynerin qaldırıldığını izləmək istərdiniz ki, onlar avtomatik qaldırılsın. Bu səbəbdən nəzarət sistemini seçməli olduq.

Hansını götürəcəyimizi uzun müddət düşündük. Fakt budur ki, o zaman adi virtual serverlərə bu yerləşdirmə yığını bir qədər köhnəlmişdi, çünki əməliyyat sistemlərinin ən son versiyaları yox idi. Müəyyən bir nöqtədə, hətta FreeBSD də orada idi, onu saxlamaq çox da rahat deyildi. Biz anladıq ki, ən qısa zamanda docker-ə köçməliyik. Bizim devops müxtəlif həllər ilə təcrübələrinə baxdı və Nomad kimi bir sistem seçdi.

Nomad-a keçid

Nomad HashiCorp-un məhsuludur. Onlar digər həlləri ilə də tanınırlar:

Konsul xidmət kəşfi üçün bir vasitədir.

"Terraforma" - serverləri idarə etmək üçün bir sistemdir ki, bu da onları kod kimi infrastruktur adlanan konfiqurasiya vasitəsilə konfiqurasiya etməyə imkan verir.

avara xüsusi konfiqurasiya faylları vasitəsilə virtual maşınları yerli və ya buludda yerləşdirməyə imkan verir.

O dövrdə Nomad, bütün infrastrukturu dəyişdirmədən tez keçə biləcəyiniz kifayət qədər sadə bir həll kimi görünürdü. Üstəlik, öyrənmək olduqca asandır. Buna görə də konteynerimiz üçün filtrləmə sistemi olaraq onu seçdik.

Sisteminizi Nomad-da yerləşdirmək üçün əslində nə lazımdır?

1. İlk növbədə, sizə lazımdır docker şəkli ərizəniz. Siz onu qurmaq və docker image mağazasına qoymaq lazımdır. Bizim vəziyyətimizdə bu artefaktdır - ona müxtəlif növ müxtəlif artefaktları itələməyə imkan verən bir sistem. O, arxivləri, docker şəkillərini, PHP bəstəkar paketlərini, NPM paketlərini və s.
2. Həmçinin lazımdır konfiqurasiya faylı, bu, Nomad-a nəyi, harada və nə qədər yerləşdirmək istədiyinizi söyləyəcək.

Nomad haqqında danışarkən, o, məlumat faylı formatı kimi HCL dilindən istifadə edir HashiCorp Konfiqurasiya Dili. Bu, xidmətinizi Nomad baxımından təsvir etməyə imkan verən Yaml-ın super dəstidir.

Bu, yerləşdirmək istədiyiniz neçə konteyneri, yerləşdirmə zamanı hansı şəkillərdən müxtəlif parametrləri onlara ötürəcəyinizi söyləməyə imkan verir. Beləliklə, siz bu faylı Nomad-a qidalandırırsınız və o, konteynerləri ona uyğun olaraq istehsala göndərir.

Bizim vəziyyətimizdə başa düşdük ki, hər bir xidmət üçün eyni, eyni HCL fayllarını yazmaq çox rahat olmayacaq, çünki çoxlu xidmətlər var və bəzən siz onları yeniləmək istəyirsiniz. Belə olur ki, bir xidmət bir instansiyada deyil, müxtəlif müxtəlif növlərdə yerləşdirilir. Məsələn, istehsalda olan sistemlərdən birinin istehsalda 100-dən çox nümunəsi var. Onlar eyni şəkillərdən işləyir, lakin konfiqurasiya parametrlərində və konfiqurasiya fayllarında fərqlənirlər.

Buna görə də, yerləşdirmə üçün bütün konfiqurasiya fayllarımızı bir ümumi depoda saxlamağın bizim üçün əlverişli olacağına qərar verdik. Beləliklə, onlar görünməyə başladılar: onlara qulluq etmək asan idi və siz bizim necə sistemlərimiz olduğunu görə bilərsiniz. Lazım gələrsə, nəyisə yeniləmək və ya dəyişdirmək də asandır. Yeni sistem əlavə etmək də çətin deyil - sadəcə olaraq yeni qovluğa konfiqurasiya faylı əlavə edin. Onun içərisində fayllar var: xidmətimizin təsvirini ehtiva edən service.hcl və istehsalda tətbiq olunan bu xidmətin konfiqurasiyasına imkan verən bəzi env faylları.

Bununla belə, bəzi sistemlərimiz istehsalda bir nüsxədə deyil, eyni anda bir neçə nüsxədə yerləşdirilir. Buna görə də qərara gəldik ki, konfiqurasiyaları təmiz formada deyil, şablon şəklində saxlamağımız bizim üçün əlverişli olacaqdır. Və şablon dili olaraq biz seçmişik jinja 2. Bu formatda biz həm xidmətin özünün konfiqurasiyalarını, həm də onun üçün lazım olan env fayllarını saxlayırıq.

Bundan əlavə, biz depoda bütün layihələr üçün ümumi olan, xidmətinizi istehsalda, düzgün mühitdə, düzgün hədəfdə işə salmağa və yerləşdirməyə imkan verən yerləşdirmə skriptini yerləşdirdik. HCL konfiqurasiyamızı şablona çevirdiyimiz halda, ondan əvvəl adi Nomad konfiqurasiyası olan HCL faylı bu halda bir az fərqli görünməyə başladı.

Yəni, bəzi konfiqurasiya yeri dəyişənlərini env fayllarından və ya digər mənbələrdən götürülmüş dəyişən əlavələrlə əvəz etdik. Bundan əlavə, HCL fayllarını dinamik şəkildə qurmaq imkanı əldə etdik, yəni biz təkcə adi dəyişən əlavələrdən istifadə edə bilmirik. Jinja dövrləri və şərtləri dəstəklədiyinə görə, tətbiqlərinizi tam olaraq harada yerləşdirdiyinizdən asılı olaraq dəyişən konfiqurasiya fayllarını da ora qoya bilərsiniz.

Məsələn, xidmətinizi istehsaldan əvvəl və istehsala yerləşdirmək istəyirsiniz. Deyək ki, pre-istehsalda siz cron skriptlərini işlətmək istəmirsiniz, sadəcə olaraq xidmətin işlədiyinə əmin olmaq üçün onu ayrıca domendə görmək istəyirsiniz. Xidməti istifadə edən hər kəs üçün proses çox sadə və şəffafdır. Bunun üçün deploy.sh faylını icra etmək, hansı xidməti yerləşdirmək istədiyinizi və hansı hədəfi göstərmək kifayətdir. Məsələn, siz Rusiya, Belarus və ya Qazaxıstanda hansısa sistemi yerləşdirmək istəyirsiniz. Bunu etmək üçün sadəcə parametrlərdən birini dəyişdirin və düzgün konfiqurasiya faylına sahib olacaqsınız.

Nomad xidməti artıq klasterinizdə yerləşdirildikdə, belə görünür.

Başlamaq üçün kənardan yük balanslaşdırıcısına ehtiyacınız var ki, bu da bütün istifadəçi trafikini özünə cəlb edəcək. O, Konsulla birlikdə işləyəcək və ondan konkret domen adına uyğun gələn konkret xidmətin harada, hansı qovşaqda, hansı IP ünvanında yerləşdiyini öyrənəcək. Konsulda xidmətlər Nomadın özündən gəlir. Bunlar eyni şirkətin məhsulları olduğu üçün yaxşı bağlıdırlar. Deyə bilərik ki, “Nomad” konsul daxilində təqdim edilən bütün xidmətlərin qeydiyyatını qutudan çıxara bilir.

Xarici balanslaşdırıcınız hansı xidmətə trafik göndərəcəyini bildikdən sonra onu müvafiq konteynerə və ya tətbiqinizə uyğun gələn çoxsaylı konteynerlərə yönləndirir. Təbii ki, təhlükəsizlik haqqında da düşünmək lazımdır. Bütün xidmətlər konteynerlərdə eyni virtual maşınlarda işləsə də, bu, adətən hər hansı bir xidmətin digərinə pulsuz girişinin rədd edilməsini tələb edir. Biz buna seqmentləşdirmə yolu ilə nail olduq. Hər bir xidmət marşrutlaşdırma qaydaları və digər sistemlərə və xidmətlərə girişə icazə / rədd etmək qaydaları yazılmış öz virtual şəbəkəsində işə salındı. Onlar həm bu klasterin daxilində, həm də onun xaricində ola bilər. Məsələn, bir xidmətin müəyyən verilənlər bazasına qoşulmasının qarşısını almaq istəyirsinizsə, bu, şəbəkə səviyyəsində seqmentləşdirmə yolu ilə edilə bilər. Yəni səhvən belə, təsadüfən sınaq mühitindən istehsal bazanıza qoşula bilməzsiniz.

İnsan resursları baxımından keçid bizə nə qədər baha başa gəldi?

Təxminən 5-6 ay ərzində bütün şirkətin Nomad-a keçidi lazım idi. Xidmətdən-xidmətə keçdik, lakin kifayət qədər sürətli templə. Hər komanda öz xidmət qablarını yaratmalı idi.

Biz elə bir yanaşma qəbul etmişik ki, hər bir komanda öz sistemlərinin docker təsvirlərinə görə müstəqil olaraq cavabdehdir. Devops isə yerləşdirmə üçün lazım olan ümumi infrastrukturu, yəni klasterin özünə dəstəyi, CI sisteminə dəstəyi və s. Və o vaxt Nomad-a 60-dan çox sistem köçürdük ki, bu da təxminən 2 min konteynerə çevrildi.

DevOps serverlərlə birlikdə yerləşdirmə ilə bağlı hər şeyin ümumi infrastrukturuna cavabdehdir. Və hər bir inkişaf qrupu, öz növbəsində, xüsusi sistemləri üçün konteynerlərin tətbiqinə cavabdehdir, çünki bu, müəyyən bir konteynerdə ümumiyyətlə nəyə ehtiyacı olduğunu bilən komandadır.

Nomad'dan ayrılma səbəbləri

Nomad və docker-dən istifadə edərək yerləşdirməyə keçməklə hansı üstünlükləri əldə etdik?

1. Biz eyni şərtləri təmin etdi bütün mühitlər üçün. İnkişafda, QA-mühit, pre-istehsal, istehsal, eyni konteyner şəkilləri, eyni asılılıqlarla istifadə olunur. Müvafiq olaraq, əvvəllər yerli və ya sınaq mühitində sınaqdan keçirdiyinizdən fərqli bir şeyin istehsalda ortaya çıxması üçün praktiki olaraq heç bir şansınız yoxdur.
2. Biz də gördük ki, kifayətdir yeni xidmət əlavə etmək asandır. Yerləşdirmə baxımından istənilən yeni sistemlər çox sadə şəkildə işə salınır. Konfiqurasiyaları saxlayan depoya getmək, sisteminiz üçün növbəti konfiqurasiyanı ora əlavə etmək kifayətdir və hamınız hazırsınız. Devoplardan əlavə səy göstərmədən sisteminizi istehsala yerləşdirə bilərsiniz.
3. Bütün konfiqurasiya faylları bir paylaşılan depoda diqqətdən kənarda qaldığı ortaya çıxdı. Sistemlərimizi virtual serverlərdən istifadə edərək yerləşdirdiyimiz anda konfiqurasiyaların eyni depoda olduğu Ansible-dan istifadə etdik. Bununla belə, əksər tərtibatçılar üçün bununla işləmək bir az daha çətin idi. Burada xidməti yerləşdirmək üçün əlavə etməli olduğunuz konfiqurasiya və kodun həcmi xeyli azalıb. Üstəlik devops üçün onu düzəltmək və ya dəyişdirmək çox asandır. Keçid vəziyyətində, məsələn, Nomad-ın yeni versiyasına, eyni yerdə olan bütün əməliyyat fayllarını götürə və kütləvi şəkildə yeniləyə bilərlər.

Ancaq bir sıra çatışmazlıqlarla da qarşılaşdıq:

Məlum oldu ki, biz qüsursuz yerləşdirmələrə nail ola bilmədi Nomad vəziyyətində. Fərqli şərtlərdən konteynerləri yayarkən, onun işlədiyi ortaya çıxa bilər və Nomad onu trafik qəbul etməyə hazır konteyner kimi qəbul etdi. Bu, daxilindəki tətbiqin başlamasına vaxt çatmazdan əvvəl baş verdi. Bu səbəbdən sistem hələ qəbul etməyə hazır olmayan konteynerə hərəkət etməyə başladığı üçün qısa müddət ərzində sistem 500 xəta verməyə başladı.

Bəziləri ilə qarşılaşdıq bataqlıqlar tərəfindən. Ən əhəmiyyətli səhv odur ki, çoxlu sistem və konteyneriniz varsa Nomad böyük klasteri yaxşı idarə etmir. Nomad klasterinə daxil olan serverlərdən birini xidmətə götürmək istədiyiniz zaman klasterin özünü çox yaxşı hiss etməməsi və dağılma ehtimalı kifayət qədər yüksəkdir. Bəzi konteynerlər, məsələn, düşə bilər və qalxmaya bilər - istehsalda olan bütün sistemləriniz Nomad tərəfindən idarə olunan klasterdə yerləşərsə, bu, sonradan sizə çox baha başa gələcək.

Odur ki, bundan sonra hara getməli olduğumuz barədə düşünməyə qərar verdik. O zaman biz nəyə nail olmaq istədiyimizi daha çox dərk etdik. Məhz: biz etibarlılıq, Nomad-ın verdiyindən bir az daha çox xüsusiyyət və daha yetkin, daha stabil sistem istəyirik.

Bu baxımdan, seçimimiz klasterləri idarə etmək üçün ən populyar platforma kimi Kubernetes-ə düşdü. Xüsusilə nəzərə alsaq ki, qablarımızın ölçüsü və sayı kifayət qədər böyük idi. Bu məqsədlər üçün Kubernetes baxa biləcəyimiz sistemlər arasında ən uyğun sistem kimi görünürdü.

Kubernetesə köçür

Kubernetes-in əsas anlayışlarının nə olduğu və onların Nomad-dan nə ilə fərqləndiyi haqqında bir az danışacağam.

Əvvəla, Kubernetesdə ən əsas anlayış pod anlayışıdır. Ləpələmək həmişə birlikdə başlayan bir və ya bir neçə konteynerdən ibarət qrupdur. Və onlar sanki həmişə eyni virtual maşında işləyirlər. Onlar müxtəlif portlarda 127.0.0.1 IP ünvanı ilə bir-biri üçün mövcuddur.

Tutaq ki, sizin nginx və php-fpm-dən ibarət PHP proqramınız var - klassik nümunə. Çox güman ki, həm nginx, həm də php-fpm konteynerlərinin həmişə bir yerdə olmasını istəyəcəksiniz. Kubernetes, onları bir ümumi pod kimi təsvir etməklə buna nail olmağa imkan verir. Nomad ilə əldə edə bilmədiyimiz məhz budur.

İkinci anlayışdır yerləşdirilməsi. Məsələ burasındadır ki, pod özü də efemer bir şeydir, başlayır və yox olur. Əvvəlcə bütün əvvəlki konteynerlərinizi öldürmək, sonra dərhal yeni versiyaları işə salmaq və ya onları tədricən yaymaq istəməyinizdən asılı olmayaraq, bu prosesə cavabdeh olan yerləşdirmə konsepsiyasıdır. Bu, podları necə yerləşdirdiyinizi, nə qədərini və onları necə yeniləməyinizi təsvir edir.

Üçüncü anlayışdır xidmət. Xidmətiniz əslində bəzi trafiki götürən və sonra onu xidmətinizə uyğun gələn bir və ya daha çox podlara yönəldən sisteminizdir. Yəni deməyə imkan verir ki, filan xidmətə gələn bütün trafik bu və belə adla bu xüsusi podlara göndərilməlidir. Və eyni zamanda, sizə trafik balansını təmin edir. Yəni siz tətbiqinizin iki podunu işə sala bilərsiniz və bütün daxil olan trafik bu xidmətlə əlaqəli podlar arasında bərabər balanslaşdırılacaq.

Və dördüncü əsas konsepsiya - Girme. Bu, Kubernetes klasterində işləyən xidmətdir. Bütün sorğuları qəbul edən xarici yük balanslaşdırıcısı kimi çıxış edir. Kubernetes API vasitəsilə Ingress bu sorğuların hara göndərilməli olduğunu müəyyən edə bilər. Və bunu çox çevik edir. Deyə bilərsiniz ki, bu host və filan URL üçün bütün sorğular bu xidmətə göndərilir. Bu hosta və başqa URL-ə gələn bu sorğular başqa xidmətə göndərilir.

Tətbiq hazırlayan birinin nöqteyi-nəzərindən ən maraqlısı odur ki, siz bütün bunları özünüz idarə edə bilirsiniz. Ingress konfiqurasiyasını təyin etməklə, siz bu və ya digər API-yə gələn bütün trafiki, məsələn, Go-da qeydiyyatdan keçmiş ayrı-ayrı konteynerlərə göndərə bilərsiniz. Amma eyni domenə, lakin fərqli URL-ə gələn bu trafik PHP-də yazılmış konteynerlərə göndərilir, burada çox məntiq var, lakin onlar çox sürətli deyil.

Bütün bu anlayışları Nomad ilə müqayisə etsək, ilk üç anlayışın hamısının birlikdə Xidmət olduğunu deyə bilərik. Və sonuncu anlayış Nomadın özündə yoxdur. Biz xarici balanslaşdırıcıdan istifadə etdik: o, haproxy, nginx, nginx + və s. ola bilər. Kub vəziyyətində bu əlavə konsepsiyanı ayrıca təqdim etməyə ehtiyac yoxdur. Ancaq içəridəki Ingressə baxsanız, o, ya nginx, ya da haproxy, ya da traefikdir, lakin sanki Kubernetes-də qurulmuşdur.

Təsvir etdiyim bütün anlayışlar əslində Kubernetes klasterində mövcud olan resurslardır. Onları kubda təsvir etmək üçün yaml formatından istifadə olunur, bu, Nomad vəziyyətində HCL fayllarından daha oxunaqlı və tanışdır. Ancaq struktur olaraq, məsələn, pod vəziyyətində eyni şeyi təsvir edirlər. Deyirlər ki, mən orda filan podları, filan şəkillərlə, filan miqdarda yerləşdirmək istəyirəm.

Bundan əlavə, biz hər bir fərdi resursu əl ilə yaratmaq istəmədiyimizi başa düşdük: yerləşdirmə, xidmətlər, giriş və s. Bunun əvəzinə, yerləşdirmə zamanı hər sistemimizi Kubernetes baxımından təsvir etmək istədik ki, bütün lazımi resurs asılılıqlarını düzgün qaydada əl ilə yenidən yaratmağa ehtiyac qalmasın. Helm bizə bunu etməyə imkan verən belə bir sistem seçildi.

Helmdə əsas anlayışlar

Sükandır paket meneceri Kubernetes üçün. Bu, paket menecerlərinin proqramlaşdırma dillərində necə işlədiyinə çox bənzəyir. Onlar sizə, məsələn, yerləşdirmə nginx, yerləşdirmə php-fpm, Ingress üçün konfiqurasiya, konfiqurasiya xəritələrindən (bu, sisteminiz üçün env və digər parametrləri təyin etməyə imkan verən bir qurumdur) ibarət xidməti saxlamağa imkan verir. qrafiklər adlanır. Eyni zamanda, Helm Kubernetesin üstündən keçir. Yəni bu, kənarda duran bir növ sistem deyil, kubun içərisində işləyən başqa bir xidmətdir. Konsol əmri ilə API vasitəsilə onunla qarşılıqlı əlaqə qurursunuz. Onun rahatlığı və cazibədarlığı ondan ibarətdir ki, sükan sınsanız və ya onu çoxluqdan çıxarsanız belə, xidmətləriniz yox olmayacaq, çünki sükan mahiyyətcə yalnız sistemin işə salınmasına xidmət edir. Kubernetes özü xidmətlərin sağlamlığına və vəziyyətinə görə daha çox məsuliyyət daşıyır.

Biz də bunu anladıq şablonlaşdırma, o vaxta qədər konfiqurasiyalarımıza jinja tətbiq etməklə özümüz etməli idik, helmin əsas xüsusiyyətlərindən biridir. Sistemləriniz üçün yaratdığınız bütün konfiqurasiyalar, bir az jinja kimi, şablonlar şəklində saxlanılır, lakin əslində Kubernetes kimi helmin yazıldığı Go dilinin şablonundan istifadə edir.

Helm bizə bir neçə əlavə konsepsiya əlavə edir.

Diaqram xidmətinizin təsviridir. Digər paket menecerlərində bu paket, paket və ya buna bənzər bir şey adlanırdı. Burada ona diaqram deyilir.

Dəyərlər, konfiqurasiyalarınızı şablonlardan qurmaq üçün istifadə etmək istədiyiniz dəyişənlərdir.

Buraxın. Hər dəfə sükanla yerləşdirilən xidmət buraxılışın artımlı versiyasını əldə edir. Helm əvvəlki buraxılış, keçən il və s. üçün xidmət konfiqurasiyasının nə olduğunu xatırlayır. Buna görə də, geri qayıtmaq lazımdırsa, sadəcə buraxılışın əvvəlki versiyasına işarə edərək, geri çağırış əmrini yerinə yetirin. Repozitoriyanızda müvafiq konfiqurasiya geri qaytarma zamanı mövcud olmasa belə, helm onun nə olduğunu xatırlayacaq və sisteminizi əvvəlki buraxılışda olduğu vəziyyətə qaytaracaq.

Sükandan istifadə etdiyimiz halda, Kubernetes üçün adi konfiqurasiyalar da dəyişənlərdən, funksiyalardan istifadə etmək və şərti ifadələr tətbiq etmək mümkün olan şablonlara çevrilir. Beləliklə, ətraf mühitdən asılı olaraq xidmətinizin konfiqurasiyasını toplaya bilərsiniz.

Praktikada biz Nomad ilə etdiyimizdən bir az fərqli bir şey etmək qərarına gəldik. Nomad həm yerləşdirmə konfiqurasiyalarını, həm də xidmətimizi bir depoda yerləşdirmək üçün lazım olan n-dəyişənləri saxlayıbsa, onda biz onları iki ayrı depoya bölmək qərarına gəldik. "Yerləşdirmə" deposu yalnız yerləşdirmə üçün lazım olan n-dəyişənləri saxlayır, "sükan" repozitoriyası isə konfiqurasiyaları və ya diaqramları saxlayır.

Bizə nə verdi?

Baxmayaraq ki, biz konfiqurasiya fayllarının özlərində həqiqətən həssas məlumatları saxlamırıq. Məsələn, verilənlər bazası parolları. Onlar Kubernetes-də sirr kimi saxlanılır, lakin buna baxmayaraq, hər kəsə ardıcıl olaraq giriş vermək istəmədiyimiz ayrı şeylər var. Buna görə də, "yerləşdirmə" repozitoriyasına giriş daha məhduddur və "sükan" anbarında yalnız xidmətin təsviri var. Bu səbəbdən, daha geniş bir insan dairəsinə təhlükəsiz şəkildə daxil ola bilər.

Bizdə təkcə istehsal deyil, həm də digər mühitlər olduğundan, bu ayırma sayəsində biz yalnız istehsala deyil, həm də, məsələn, QA mühitinə xidmətləri yerləşdirmək üçün sükan cədvəllərimizdən yenidən istifadə edə bilərik. Hətta yerli istifadə edərək onları yerləşdirmək Minikube - bu Kubernetes-i yerli olaraq idarə etmək üçün belə bir şeydir.

Hər bir deponun içərisində bölməni hər bir xidmət üçün ayrı-ayrı kataloqlara buraxdıq. Yəni, hər bir kataloqun içərisində müvafiq diaqramla əlaqəli və sistemimizi işə salmaq üçün istifadə edilməli olan resursları təsvir edən şablonlar var. "Yerləşdirmə" anbarında yalnız paxıllıq buraxdıq. Bu halda, biz jinja şablonlaşdırmasından istifadə etmədik, çünki helm qutudan kənar şablonlaşdırma təmin edir - bu, onun əsas xüsusiyyətlərindən biridir.

Biz yerləşdirmə skriptini tərk etdik - deploy.sh, bu, sükandan istifadə edərək yerləşdirmə üçün işə salınmanı sadələşdirir və standartlaşdırır. Beləliklə, yerləşdirmək istəyən hər kəs üçün yerləşdirmə interfeysi Nomad vasitəsilə yerləşdirmə vəziyyətində olduğu kimi eyni görünür. Eyni deploy.sh, xidmətinizin adı və onu yerləşdirmək istədiyiniz yer. Bu, sükanı daxildən idarə etməyə səbəb olur. O, öz növbəsində, şablonlardan konfiqurasiyaları toplayır, lazımi dəyərlər fayllarını onlara əvəz edir, sonra onları Kubernetes-də işə salaraq yerləşdirir.

Tapıntılar

Kubernetes xidməti Nomad-dan daha mürəkkəb görünür.

Bu, gedən trafikin Ingressə gəldiyi yerdir. Bu, yalnız bütün sorğuları qəbul edən və sonra onları sorğu məlumatlarına uyğun xidmətlərə göndərən ön nəzarətçidir. O, onları idarəetmə sistemindəki tətbiqinizin təsvirinin bir hissəsi olan və tərtibatçıların özləri təyin etdiyi konfiqurasiyalar əsasında müəyyən edir. Xidmət isə bu xidmətə aid olan bütün konteynerlər arasında daxil olan trafiki balanslaşdıraraq öz podlarına, yəni konkret konteynerlərə sorğular göndərir. Və əlbəttə ki, unutmamalıyıq ki, şəbəkə səviyyəsində təhlükəsizlikdən heç bir yerə getməməliyik. Buna görə də, seqmentləşdirmə etiketləşdirməyə əsaslanan Kubernetes klasterində işləyir. Bütün xidmətlərdə xidmətlərin klaster daxilində və ya xaricində müəyyən xarici/daxili resurslara giriş hüquqları əlavə olunduğu müəyyən etiketlər var.

Keçid zamanı gördük ki, Kubernetes indiyə qədər istifadə etdiyimiz Nomad-ın bütün xüsusiyyətlərinə malikdir və bir çox yeni şeylər əlavə edir. O, plaginlər vasitəsilə və əslində xüsusi resurs növləri vasitəsilə genişləndirilə bilər. Yəni, təkcə Kubernetes ilə birlikdə gələn bir şeydən istifadə etmək deyil, həm də resursunuzu oxuyacaq öz resursunuzu və xidmətinizi yaratmaq imkanınız var. Bu, Kubernetes-i yenidən quraşdırmadan və dəyişiklik etmədən sisteminizi genişləndirmək üçün daha çox seçim imkanı verir.

Bu cür istifadə nümunəsi Kubernetes klasterində işlədiyimiz Prometeydir. Müəyyən bir xidmətdən ölçüləri toplamağa başlamaq üçün xidmətin təsvirinə monitor xidməti adlanan əlavə resurs növü əlavə etməliyik. Prometheus, oxuya bildiyinə görə, xüsusi bir resurs növü olan Kubernetes-də işə salınaraq, avtomatik olaraq yeni sistemdən ölçüləri toplamağa başlayır. Kifayət qədər rahatdır.

Kubernetes-də etdiyimiz ilk yerləşdirmə 2018-ci ilin mart ayında oldu. Və bu müddət ərzində onunla heç bir problem yaşamadıq. Əhəmiyyətli səhvlər olmadan olduqca sabit işləyir. Bundan əlavə, biz onu daha da genişləndirə bilərik. Bu günə qədər onun kifayət qədər imkanları var və biz Kubernetes-in inkişaf tempini çox bəyənirik. Hazırda Kubernetesdə 3000-dən çox konteyner var. Klaster bir neçə Node tutur. Eyni zamanda, xidmətə yararlı, sabit və çox idarə olunandır.

Mənbə: www.habr.com