Kubernetes-ə yerləşdirməyin ilk addımı tətbiqinizi konteynerə yerləşdirməkdir. Bu seriyada kiçik, təhlükəsiz konteyner şəklini necə yarada biləcəyinizi nəzərdən keçirəcəyik.
Docker sayəsində konteyner şəkilləri yaratmaq heç vaxt asan olmayıb. Əsas şəkli göstərin, dəyişikliklərinizi əlavə edin və konteyner yaradın.
Bu texnika başlamaq üçün əla olsa da, standart əsas şəkillərdən istifadə zəifliklərlə dolu böyük şəkillərlə təhlükəli işə gətirib çıxara bilər.
Bundan əlavə, Docker-dəki şəkillərin əksəriyyəti əsas təsvir üçün Debian və ya Ubuntu-dan istifadə edir və bu, əla uyğunluq və asan fərdiləşdirmə təmin etsə də (Docker faylı yalnız iki kod sətirini alır), baza şəkilləri konteynerinizə yüzlərlə meqabayt əlavə yük əlavə edə bilər. Məsələn, Go "salam dünya" proqramı üçün sadə node.js faylı təxminən 700 meqabaytdır, halbuki sizin faktiki tətbiqiniz cəmi bir neçə meqabayt ölçüsündədir.
Beləliklə, bütün bu əlavə iş yükü rəqəmsal məkanın itkisidir və təhlükəsizlik zəiflikləri və səhvlər üçün əla gizlənmə yeridir. Beləliklə, konteyner şəklinin ölçüsünü azaltmağın iki yoluna baxaq.
Birincisi, kiçik əsas şəkillərin istifadəsi, ikincisi isə Builder Pattern-in istifadəsidir. Kiçik əsas şəkillərdən istifadə konteynerinizin ölçüsünü azaltmağın ən asan yoludur. Çox güman ki, istifadə etdiyiniz dil və ya yığın standart şəkildən çox kiçik olan orijinal tətbiq şəklini təmin edir. Gəlin node.js konteynerimizə nəzər salaq.
Docker-də standart olaraq node:8 əsas təsvir ölçüsü 670 MB, node: 8-alp image ölçüsü isə cəmi 65 MB, yəni 10 dəfə kiçikdir. Kiçik Alp əsas təsvirindən istifadə etməklə siz konteynerinizin ölçüsünü əhəmiyyətli dərəcədə azaldacaqsınız. Alpine kiçik və yüngül Linux paylanmasıdır və Docker istifadəçiləri arasında çox populyardır, çünki konteynerləri kiçik saxlayaraq bir çox tətbiqlərə uyğun gəlir. Standart Docker "qovşağı" təsvirindən fərqli olaraq, "node:alpine" bir çox xidmət fayllarını və proqramlarını silir, yalnız tətbiqinizi işə salmaq üçün kifayət olanları buraxır.
Daha kiçik əsas təsvirə keçmək üçün yeni əsas təsvirlə işləməyə başlamaq üçün sadəcə Dockerfile-ni yeniləyin:
İndi köhnə onbuild təsvirindən fərqli olaraq, kodunu konteynerə köçürməli və istənilən asılılıqları quraşdırmalısınız. Yeni Dockerfile-də konteyner node:alp image ilə başlayır, sonra kod üçün kataloq yaradır, NPM paket menecerindən istifadə edərək asılılıqları quraşdırır və nəhayət server.js-i işə salır.
Bu təkmilləşdirmə ölçüsü 10 dəfə kiçik olan konteynerlə nəticələnir. Proqramlaşdırma dilinizdə və ya yığınınızda əsas təsviri azaltma funksiyası yoxdursa, Alpine Linux-dan istifadə edin. O, həmçinin konteynerin məzmununu tam idarə etmək imkanı verəcək. Kiçik əsas şəkillərdən istifadə kiçik konteynerləri tez bir zamanda yaratmaq üçün əla bir yoldur. Lakin Builder Pattern istifadə edərək daha böyük azalma əldə edilə bilər.
Tərcümə edilən dillərdə mənbə kodu əvvəlcə tərcüməçiyə ötürülür və sonra birbaşa icra olunur. Tərtib edilmiş dillərdə mənbə kodu əvvəlcə tərtib edilmiş koda çevrilir. Bununla belə, kompilyasiya çox vaxt kodu işlətmək üçün əslində lazım olmayan vasitələrdən istifadə edir. Bu o deməkdir ki, siz bu alətləri son konteynerdən tamamilə çıxara bilərsiniz. Bunun üçün Builder Pattern istifadə edə bilərsiniz.
Kod birinci konteynerdə yaradılır və tərtib edilir. Tərtib edilmiş kod daha sonra həmin kodu tərtib etmək üçün lazım olan kompilyatorlar və alətlər olmadan yekun konteynerə qablaşdırılır. Gəlin bu proses vasitəsilə Go proqramını işə salaq. Birincisi, biz qurulmuş təsvirdən Alp Linux-a keçəcəyik.
Yeni Dockerfile-də konteyner golang:alp təsviri ilə başlayır. Daha sonra kod üçün kataloq yaradır, onu mənbə koduna kopyalayır, həmin mənbə kodunu qurur və tətbiqi işə salır. Bu konteyner quraşdırılmış konteynerdən çox kiçikdir, lakin o, hələ də tərtibçini və həqiqətən ehtiyacımız olmayan digər Go alətlərini ehtiva edir. Beləliklə, sadəcə tərtib edilmiş proqramı çıxaraq və öz konteynerinə yerləşdirək.
Bu Docker faylında qəribə bir şey görə bilərsiniz: o, iki FROM sətrini ehtiva edir. İlk 4 sətir bölməsi əvvəlki Dockerfile ilə tamamilə eyni görünür, ancaq bu mərhələni adlandırmaq üçün AS açar sözündən istifadə edir. Növbəti bölmədə yeni təsvirə başlamaq üçün yeni FROM xətti var, burada qolanq:alp təsviri əvəzinə əsas şəkil kimi Raw alpindən istifadə edəcəyik.
Raw Alpine Linux-da quraşdırılmış SSL sertifikatları yoxdur, bu da HTTPS üzərindən əksər API zənglərinin uğursuzluğuna səbəb olacaq, ona görə də bəzi kök CA sertifikatlarını quraşdıraq.
İndi əyləncəli hissə gəlir: tərtib edilmiş kodu birinci konteynerdən ikinciyə köçürmək üçün sadəcə ikinci bölmənin 5-ci sətirində yerləşən COPY əmrindən istifadə edə bilərsiniz. O, yalnız bir proqram faylını kopyalayacaq və Go kommunal alətlərinə təsir etməyəcək. Yeni çoxmərhələli Docker faylı 12 meqabayt olan orijinal konteyner şəkli ilə müqayisədə yalnız 700 meqabayt ölçüsündə konteyner şəklini ehtiva edəcək, bu böyük fərqdir!
Beləliklə, kiçik əsas şəkillərdən və İnşaatçı Patterndən istifadə çox iş görmədən daha kiçik konteynerlər yaratmaq üçün əla yoldur.
Tətbiq yığınından asılı olaraq şəkil və konteyner ölçüsünü azaltmağın əlavə yolları ola bilər, lakin kiçik qabların həqiqətən ölçülə bilən faydası varmı? Kiçik konteynerlərin son dərəcə təsirli olduğu iki sahəyə baxaq - performans və təhlükəsizlik.
Performans artımını qiymətləndirmək üçün konteynerin yaradılması prosesinin müddətini nəzərdən keçirin, onu reyestrə daxil edin (push) və sonra onu oradan çıxarın (çəkin). Görə bilərsiniz ki, daha kiçik bir qabın daha böyük konteynerdən fərqli üstünlüyü var.
Docker təbəqələri önbelleğe alacaq, ona görə də sonrakı qurmalar çox sürətli olacaq. Bununla belə, konteynerlərin qurulması və sınaqdan keçirilməsi üçün istifadə edilən bir çox CI sistemləri təbəqələri önbelleğe almır, buna görə də vaxta əhəmiyyətli qənaət var. Gördüyünüz kimi, maşınınızın gücündən asılı olaraq böyük bir konteyner qurmaq üçün vaxt 34-dən 54 saniyəyə qədərdir və Builder Pattern istifadə edərək konteynerdən istifadə edərkən 23 saniyədən 28 saniyəyə qədər azaldılır. Bu cür əməliyyatlar üçün məhsuldarlıq artımı 40-50% təşkil edəcəkdir. Ona görə də kodunuzu neçə dəfə qurduğunuzu və sınadığınızı düşünün.
Konteyner qurulduqdan sonra onun şəklini (konteyner şəklini) konteyner reyestrinə itələməlisiniz ki, onu Kubernetes klasterinizdə istifadə edə biləsiniz. Google Konteyner Reyestrindən istifadə etməyi məsləhət görürəm.
Google Konteyner Registri (GCR) ilə siz yalnız xammal saxlama və şəbəkə üçün ödəniş edirsiniz və heç bir əlavə konteyner idarəetmə haqqı yoxdur. Şəxsi, təhlükəsiz və çox sürətlidir. GCR çəkmə əməliyyatını sürətləndirmək üçün bir çox fəndlərdən istifadə edir. Gördüyünüz kimi, go:onbuild istifadə edərək Docker Konteyner Şəkil konteynerinin daxil edilməsi kompüterin performansından asılı olaraq 15-48 saniyə çəkəcək və daha kiçik konteynerlə eyni əməliyyat 14-16 saniyə, daha az məhsuldar maşınlar üçün isə vaxt aparacaq. əməliyyat sürətində üstünlük 3 dəfə artır. Daha böyük maşınlar üçün vaxt təxminən eynidir, çünki GCR paylaşılan şəkillər verilənlər bazası üçün qlobal keşdən istifadə edir, yəni onları ümumiyyətlə yükləməyə ehtiyac yoxdur. Aşağı güclü kompüterdə CPU darboğazdır, ona görə də kiçik konteynerlərdən istifadənin üstünlüyü burada daha böyükdür.
Əgər GCR istifadə edirsinizsə, quraşdırma sisteminizin bir hissəsi kimi Google Konteyner Qurucusundan (GCB) istifadə etməyi tövsiyə edirəm.
Göründüyü kimi, onun istifadəsi hətta məhsuldar maşından da Build+Push əməliyyatının müddətinin azaldılmasında xeyli yaxşı nəticələr əldə etməyə imkan verir - bu halda konteynerlərin qurulması və hosta göndərilməsi prosesi demək olar ki, 2 dəfə sürətli olur. Üstəlik, hər gün 120 pulsuz tikinti dəqiqəsi əldə edirsiniz ki, bu da əksər hallarda konteyner tikinti ehtiyaclarınızı ödəyir.
Daha sonra ən vacib performans göstəricisi gəlir - Konteynerləri götürmə və ya yükləmə sürəti. Bir təkan əməliyyatına sərf olunan vaxta çox əhəmiyyət vermirsinizsə, çəkmə prosesinin uzunluğu sistemin ümumi performansına ciddi təsir göstərir. Tutaq ki, sizdə üç qovşaqdan ibarət çoxluq var və onlardan biri uğursuz oldu. Google Kubernetes Engine kimi bir idarəetmə sistemindən istifadə edirsinizsə, o, avtomatik olaraq ölü nodu yenisi ilə əvəz edəcəkdir. Bununla belə, bu yeni node tamamilə boş olacaq və işə başlaması üçün bütün konteynerlərinizi onun içinə sürükləməli olacaqsınız. Əgər çəkmə əməliyyatı kifayət qədər uzun çəkirsə, klasteriniz bütün vaxt ərzində daha aşağı performansla işləyəcək.
Bunun baş verə biləcəyi bir çox hal var: klasterə yeni bir node əlavə etmək, qovşaqları təkmilləşdirmək və ya hətta yerləşdirmə üçün yeni konteynerə keçid. Beləliklə, çəkmə çıxarma vaxtını minimuma endirmək əsas amilə çevrilir. Kiçik bir konteynerin böyükdən daha sürətli yükləndiyi danılmazdır. Kubernetes klasterində birdən çox konteyner işlədirsinizsə, vaxta qənaət əhəmiyyətli ola bilər.
Bu müqayisəyə nəzər salın: kiçik konteynerlərdə çəkmə əməliyyatı go:onbuild istifadə edərək eyni əməliyyatla müqayisədə maşının gücündən asılı olaraq 4-9 dəfə az vaxt aparır. Paylaşılan, kiçik konteyner bazası şəkillərinin istifadəsi yeni Kubernetes qovşaqlarının yerləşdirilə və onlayn ola biləcəyi vaxtı və sürəti əhəmiyyətli dərəcədə sürətləndirir.
Gəlin təhlükəsizlik məsələsinə baxaq. Kiçik konteynerlər daha böyüklərdən daha təhlükəsiz hesab olunur, çünki onlar daha kiçik hücum səthinə malikdirlər. Doğrudanmı? Google Konteyner Reyestrinin ən faydalı xüsusiyyətlərindən biri, boşluqlar üçün konteynerlərinizi avtomatik skan etmək qabiliyyətidir. Bir neçə ay əvvəl mən həm onbuild, həm də çoxmərhələli konteynerlər yaratdım, ona görə də orada hər hansı zəifliyin olub-olmadığını görək.
Nəticə heyrətamizdir: kiçik konteynerdə yalnız 3 orta səviyyəli zəiflik, böyük konteynerdə isə 16 kritik və 376 digər zəiflik aşkar edilib. Böyük bir konteynerin içinə baxsaq görərik ki, təhlükəsizlik problemlərinin əksəriyyəti bizim tətbiqimizlə heç bir əlaqəsi yoxdur, hətta istifadə etmədiyimiz proqramlarla bağlıdır. Beləliklə, insanlar böyük bir hücum səthi haqqında danışdıqda, bunu nəzərdə tuturlar.
Nəticə aydındır: kiçik konteynerlər qurun, çünki onlar sisteminiz üçün real performans və təhlükəsizlik üstünlükləri təmin edir.
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com