Bir DevOps Mühəndisi olmaq necədir, Bölüm 4: Maksimum altı ay ərzində paket

Unsplash-da Chuttersnap-dan

Qisa xülasə

Hissə 1-də DevOps mədəniyyəti və tələb olunan əsaslardan bəhs etdik:

Hissə 2-də gələcək kod yerləşdirmələrinin təməllərini necə düzgün bir şəkildə qoymağı müzakirə etdik:

Hissə 3-də yerləşdirilmiş kodunuzu necə təşkil edəcəyimiz barədə danışdıq:

Aşağıdakı, asan yerləşdirmə və sonra icra üçün kodunuzu necə paketləndirəcəyinizi izah edir.

İstinad olaraq, səyahətimizdəyik:

paket

Qeyd: Hər bir hissənin əvvəlki hissəyə necə qurulduğunu və növbəti hissənin təməlini qoyduğunu görə bilərsiniz. Bu vacibdir və qəsdən edilir.

Bunun səbəbi, istər hazırkı işəgötürənlərinizlə, istərsə də gələcək işəgötürənlərinizlə danışsanız da, DevOps-un nə olduğunu və bunun nə üçün vacib olduğunu açıqlaya bilməyiniz lazımdır.

Bunu bir araya gətirən bir hekayə söyləyərək edirsiniz - bir geliştirici noutbukundan bir pul istehsalçı məhsuluna sürətli və səmərəli şəkildə kod almağın ən yaxşı yolu haqqında bir hekayə.

Beləliklə, bir dəstə ayrı, meylli DevOps alətini öyrəndikdən sonra deyilik. İş ehtiyaclarından asılı olan və texniki vasitələrlə dəstəklənən bir sıra bacarıqları öyrənmək istəyirik.

Unutmayın ki, hər mərhələ ümumilikdə altı ay ərzində təxminən bir aylıq iş vaxtı alır.

Tamam, kifayət qədər söhbət et, başlayaq!

Virtuallaşdırmaya giriş

Fiziki serverləri xatırlayırsınız? Göndərilmək, məlumat mərkəzini qəbul etmək, racked etmək, şəbəkəyə qoymaq, əməliyyat sisteminə quraşdırmaq və yamaqlamaq üçün PO təsdiqini almaq üçün həftələr gözləməyiniz lazım olanlar?

Bəli. Birincisi onlar gəldi.

Yaşayış evinə sahib olmağın yeganə yolu tamamilə yeni bir ev tikmək olduğunu düşünün. Yaşayacaq bir yerə ehtiyacınız var? Gözləyin nə qədər vaxt aparır! Hər kəs bir ev aldığından bəri sərin, həm də həqiqətən də bir ev tikmək çox vaxt aldığına görə deyil. Bu bənzətmədə fiziki bir server bir ev kimidir.

O zaman insanlar hər şeyin nə qədər çəkdiyini əsəbiləşdirəcəkdilər və bəzi həqiqətən ağıllı insanlar sanallaşdırma fikri ilə gəldilər: bir qrup "maşın" adlanan bir fiziki maşında necə çalışacağı və hər saxta maşının özünü necə göstərəcəyi o həqiqi bir maşın olardı. Dahi!

Beləliklə, həqiqətən bir ev istəyirsinizsə, öz evinizi tikib altı həftə gözləyə bilərsiniz. Yoxsa bir mənzildə yaşayırsınız və mənbələri digər kiracılarla paylaşırsınız. Bəlkə də böyük deyil, amma kifayət qədər yaxşıdır! Və hər şeydən əvvəl gözləmə yoxdur!

Bu bir müddət çəkdi və şirkətlər (yəni VMWare) bunun üzərində mütləq bir qətl etdilər.

Digər parlaq ağıllar bir çox virtual maşının bir fiziki maşına yığılmasının kifayət qədər yaxşı olmadığına qərar verməyincə: Daha az mənbədə daha çox prosesi daha kompakt qablaşdırmağa ehtiyacımız var.

Bu nöqtədə bir ev çox bahalı və bir mənzil hələ də çox bahalıdır. Yalnız müvəqqəti bir otaq icarəyə götürməyim lazım olsa? Gözəldir, istədiyim zaman içəri girib çıxa bilərəm!

Əsasən bu Docker.

Qeyd: 2018-ci ilin dekabr ayından etibarən

Docker-in anadan olması

Docker yenidir, lakin Docker-in arxasındakı fikir çox köhnədir. FreeBSD adlı bir əməliyyat sistemində 2000-ci ildən bəri həbsxana konsepsiyası var idi! Yeni hər şey həqiqətən köhnədir.

O vaxt və indi də "əməliyyat sistemi səviyyəsində virtualizasiya" kimi tanınan eyni əməliyyat sistemi daxilindəki fərdi prosesləri təcrid etmək idi.

DİQQƏT: Bu, virtual maşınların eyni fiziki hostda yan-yana çalışdığı "tam virtualizasiya" ilə eyni deyil.

Bu praktikada nə deməkdir?

Təcrübədə bu, Docker-in populyarlıq artımının mikroservislərin artımını əks etdirməsi deməkdir - proqramı bir çox fərdi komponentlərə ayıran bir proqram mühəndisliyi yanaşması.

Və bu komponentlərin bir evə ehtiyacı var. Bunları ayrıca Java tətbiqetmələri və ya yürütülebilir ikili fayllar olaraq ayrı-ayrılıqda yerləşdirmək böyük bir problemdir: Java tətbiqetməsini idarə etmək C ++ tətbiqetməsini idarə etmək və Golang tətbiqini idarə etməkdən fərqlidir.

Bunun əvəzinə, Docker, proqram inkişaf etdiricilərinin paketini (!), Yerləşdirə və fərqli tətbiqetmələri ardıcıl şəkildə idarə edə biləcəyi tək bir idarəetmə interfeysi təmin edir.

Bu böyük bir qələbədir!

Tamam, Docker-in müsbət və mənfi cəhətləri haqqında daha çox danışaq.

Docker-in üstünlükləri

Proses təcrid

Docker hər hansı bir xidmət üçün tam proses təcridini təmin edir. Xidmət A, bütün asılılıqları ilə öz kiçik konteynerində yaşayır. Xidmət B, bütün asılılıqları ilə konteynerində yaşayır. Və ikisi zidd deyil!

Əlavə olaraq, bir qabın çökməsi halında yalnız bu konteyner təsirlənir. Qalanları xoşbəxtliklə davam edəcəkdir!

Bu da təhlükəsizliyə fayda gətirir. Bir konteyner təhlükəyə məruz qaldıqda, həmin konteynerdən çıxmaq və əsas əməliyyat sistemini sındırmaq son dərəcə çətindir (amma mümkün deyil!).

Bir konteyner pis davranırsa (çox CPU və ya yaddaş istifadə olunur), partlayış radiusu sistemin qalan hissəsinə təsir etmədən həmin konteyner üçün yalnız "daraldıla bilər".

öhdəlik

Müxtəlif tətbiqetmələrin praktikada necə qurulduğunu düşünün.

Bir Python tətbiqidirsə, bir neçə Python paketi mövcuddur. Bəziləri pip modulları kimi qurulur, bəziləri RPM və ya Deb paketləri, bəziləri isə sadə git-klon quraşdırmalarıdır. Bu virtualenv ilə edildikdə, virtualenv qovluğundakı bütün asılılıqları olan bir ZIP sənədidir.

Digər tərəfdən, bir Java tətbiqidirsə, bütün asılılıqlar çəkilərək uyğun yerlərə paylanaraq tədricən qurulur.

Sözü sən başa düşürsən. Fərqli dillərə və işləmə müddətlərinə sahib fərqli tətbiqlər, bu tətbiqetmələrin məhsullar üçün təmin edilməsinə gəldikdə bir çətinlik yaradır.

Bütün asılılıqları necə qarşılaya bilərik?

Həm də, münaqişə olduqda problem daha da pisləşir. Xidmət A, Python kitabxanası v1-dən, B xidməti isə Python kitabxanası v2-dən asılıdırsa nə olar? İndi v1 və v2 eyni kompüterdə mövcud ola bilmədiyi üçün bir münaqişə var.

Docker daxil edin.

Docker yalnız tam proses təcridinə deyil, həm də tam asılılıq təcridinə imkan verir. Hər birinin öz ziddiyyətli kitabxanalarını və paketlərini ehtiva edən eyni əməliyyat sistemində birdən çox konteynerin yan-yana işləməsi tamamilə mümkündür və yaygındır.

İş vaxtının idarəedilməsi

Yenə də fərqli tətbiqetmələri idarə etmə üsulumuz tətbiqetmədən fərqlidir. Java kodu Python-dan fərqli olaraq qeyd olunur, başlayır və izlənir. Və Python Golang'dan fərqlidir və s.

Docker ilə bir çox müxtəlif növ tətbiqləri başlamağımıza, izləməyimizə, mərkəzləşdirməyimizə, dayandırmağa və yenidən başlamağımıza imkan verən tək, vahid idarəetmə interfeysi əldə edirik.

Bu, böyük bir qazancdır və işləyən istehsal sistemlərinin əməliyyat xərclərini əhəmiyyətli dərəcədə azaldır.

Qeyd: 2018-ci ilin dekabr ayından etibarən artıq Docker-in sürətli işə salınması ilə VM-lərin təhlükəsizliyi arasında seçim etmək lazım deyil. Project Firecracker, Amazon’un nəzakəti ilə hər iki dünyanın ən yaxşısını birləşdirməyə çalışır. Ancaq bu hələ istehsalda istifadə edilməməsi lazım olan çox yeni bir texnologiyadır.

Docker nə qədər böyük olsa da, mənfi cəhətləri də var.

Lambda'ya daxil olun

Birincisi, serverlər hələ Docker üzərində işləyir. Garsonlar kövrək və qırıqdır. Bunların idarə edilməli, yamalı və başqa bir şəkildə saxlanılması lazımdır.

İkincisi, Docker 100% təhlükəsiz deyil. Heç olmasa VM kimi deyil. Barındırılan konteynerləri işləyən böyük təşkilatların çılpaq metal əsaslarla deyil, VM-lərdə etməsinin bir səbəbi var. Sürətli konteynerin başlama vaxtları və VM təhlükəsizliyi istəyirsən!

Üçüncüsü, heç kim Docker-i olduğu kimi işlədir. Bunun əvəzinə, demək olar ki, həmişə Kubernetes, ECS, Docker-Swarm və ya Nomad kimi kompleks bir konteyner orkestr quruluşunun bir hissəsi olaraq verilir. Bunlar mütəxəssis kadrların işləməsini tələb edən kifayət qədər mürəkkəb platformalardır (daha sonra bu həllər haqqında daha çox məlumat).

Ancaq bir geliştirici olduğum zaman yalnız kod yazmaq və başqasının bunu etməsini istəyirəm. Docker, Kubernetes və cazın hamısını öyrənmək asan deyil - həqiqətən məcburam?!

Qısa cavab, bu asılıdır!

Yalnız başqasının kodunu çalıştırmasını istəyən insanlar üçün AWS Lambda (və bənzər həllər) cavabdır:

AWS Lambda ilə kod hazırlamadan və ya serverləri idarə etmədən işləyə bilərsiniz. Yalnız istifadə etdiyiniz hesablama vaxtını ödəyəcəksiniz - kodunuz yerinə yetirilmədiyi təqdirdə heç bir ödəniş yoxdur.

Bütün "serversiz" hərəkəti eşitmisinizsə, budur! Artıq serverləri işə salmağa və konteynerləri idarə etməyə ehtiyac qalmır. Yalnız kodunuzu yazın, zipləyin, Amazon-a yükləyin və baş ağrısı ilə qarşılaşmalarına icazə verin!

Lambdalar qısa müddətli olduğundan, hack ediləcək bir şey yoxdur - lambdalar təbii olaraq olduqca təhlükəsizdir.

Əla deyilmi?

Ancaq (sürpriz!) Rezervasyonlar var.

Birincisi, Lambdas yalnız maksimum 15 dəqiqə işləyə bilər (2018-ci ilin noyabr ayından etibarən). Bu, Kafka istehlakçıları və ya nömrə sıxan tətbiqetmələr kimi uzun müddət davam edən proseslərin Lambda'da işləyə bilməyəcəyini nəzərdə tutur.

İkincisi, Lambdalar bir xidmət kimi fəaliyyət göstərir. Bu o deməkdir ki, tətbiqiniz tamamilə mikroservislərə bölünməli və AWS Step Functions kimi digər mürəkkəb PaaS xidmətləri ilə təşkil olunmalıdır. Hər bir şirkət bu mikroservis arxitekturasına sahib deyil.

Üçüncüsü, lambdaların problemlərini həll etmək çətindir. Bunlar buluddan doğma iş vaxtlarıdır və bütün səhv düzəlişləri Amazon ekosistemində baş verir. Bu, çox vaxt çətin və intuitiv deyil.

Bir sözlə, pulsuz nahar yoxdur.

Qeyd: İndi bir server olmadan bulud konteyner həlləri var. AWS Fargate belə yanaşmalardan biridir. Mexanika əsasən oxşardır. Yeni başlayırsınızsa, Fargate'i sınamağınızı tövsiyə edirəm - bu konteynerləri işə salmağın "doğru yolu" üçün inanılmaz dərəcədə asan bir yoldur.

YENİLƏNİB 1/13/2019: AWS, Fargate üçün əhəmiyyətli bir endirim elan etdi və bu, "serversiz" konteynerlərin işlənməsi üçün çox cəlbedici bir seçim oldu.

Xülasə

Docker və Lambda, istehsal tətbiqetmələrinin qablaşdırılması, işlədilməsi və idarə edilməsinə dair ən məşhur müasir, bulud əsaslı yanaşmalardan biridir.

Bunlar tez-tez tamamlayıcıdır və bir az fərqli istifadə halları və tətbiqləri üçün uygundur.

Asılı olmayaraq, müasir bir DevOps mühəndisinin hər ikisini də çox bilməsi lazımdır. Buna görə Docker və Lambda öyrənmək yaxşı qısa və orta müddətli hədəflərdir.

Qeyd: Seriyamızda indiyə qədər kiçik və orta səviyyəli DevOps mühəndislərindən gözlənilən mövzuları müzakirə etdik. Növbəti hissələrdə orta və yuxarı DevOps mühəndisləri üçün daha uyğun olan texnikaları müzakirə edəcəyik. Həmişə olduğu kimi, təcrübə üçün heç bir qısa yol yoxdur!

Növbəti

Müasir yerləşdirmənin ən yaxşı təcrübələri haqqında daha çox məlumat üçün oxuyun.