Nədənsə bir anda Docker konteynerləri və deb paketləri şəklində çatdırılma haqqında məqalə yazmaq qərarına gəldim, amma işə başlayanda nədənsə ilk fərdi kompüterlərin və hətta kalkulyatorların uzaq dövrlərinə qayıtdım. Ümumiyyətlə, doker və debin quru müqayisəsi əvəzinə, diqqətinizə təqdim etdiyim təkamül mövzusunda bu fikirləri əldə etdik.
İstənilən məhsul, nə olursa olsun, bir şəkildə məhsulun serverlərinə daxil olmalı, konfiqurasiya edilməli və işə salınmalıdır. Bu məqalənin mövzusu budur.
Tarixi kontekstdə düşünəcəyəm: “Gördüyüm şey haqqında oxuduğum şeydir”, ilk dəfə kod yazmağa başlayanda gördüklərim və indi müşahidə etdiklərim, hazırda özümüz nədən istifadə edirik və niyə. Məqalə özünü tam hüquqlu bir araşdırma kimi göstərmir, bəzi məqamlar qaçırılıb, bu, mənim nəyin olub, nəyin indi olduğuna şəxsi baxışımdır.
Beləliklə, köhnə yaxşı günlərdə... tapdığım ən erkən çatdırılma üsulu maqnitofonlardan olan kasetlər idi. Mənim BK-0010.01 kompüterim var idi...
Kalkulyatorlar dövrü
Xeyr, daha erkən bir an var idi, bir kalkulyator da var idi и .
Belə ki, mən olanda , onda proqramı köçürməyin yolu proqramın yazıldığı qutuda adi bir kağız parçası idi, lazım olduqda onu əl ilə idarə etmək üçün kalkulyatora yazılmışdır. Əgər oynamaq istəyirsinizsə (bəli, hətta bu antidiluvian kalkulyatorunda oyunlar var idi) - oturub kalkulyatora proqramı daxil edirsiniz. Təbii ki, kalkulyator söndürüldükdə proqram unudulub yoxa çıxdı. Şəxsən kağız üzərində yazılmış kalkulyator kodlarından əlavə, proqramlar “Radio” və “Gənclər üçün texnologiya” jurnallarında dərc edilmiş, o dövrün kitablarında da dərc edilmişdir.
Növbəti modifikasiya kalkulyator idi , o, artıq dəyişkən olmayan məlumatların saxlanmasına bənzəyir. İndi oyun və ya proqramı əl ilə daxil etmək lazım deyildi, lakin düymələrlə bəzi sehrli keçidləri yerinə yetirdikdən sonra o, özünü yüklədi.
Kalkulyatorda ən böyük proqramın ölçüsü 105 addım, MK-52-də daimi yaddaşın ölçüsü isə 512 addım idi.
Yeri gəlmişkən, bu məqaləni oxuyan bu kalkulyatorların pərəstişkarları varsa, məqaləni yazarkən mən həm Android üçün kalkulyator emulyatoru, həm də onun üçün proqramlar tapdım. Keçmişə doğru!
MK-52 haqqında qısa məlumat (Vikipediyadan)
MK-52 "Soyuz TM-7" kosmik gəmisi ilə kosmosa uçdu. Bort kompüterinin sıradan çıxması halında onun eniş trayektoriyasını hesablamaq üçün istifadə edilməli idi.
52-ci ildən etibarən, Elektronika-Astro yaddaş genişləndirmə qurğusu olan MK-1988 naviqasiya hesablama dəstinin bir hissəsi kimi Hərbi Dəniz Qüvvələri gəmilərinə verilir.
İlk fərdi kompüterlər
Gəlin vaxta qayıdaq . Aydındır ki, orada daha çox yaddaş var idi və bir kağız parçasından kod yazmaq artıq seçim deyildi (baxmayaraq ki, əvvəlcə mən bunu etdim, çünki sadəcə başqa vasitə yox idi). Maqnitofonlar üçün audio kasetlər proqram təminatının saxlanması və çatdırılması üçün əsas vasitəyə çevrilir.
Bir kasetdə saxlama ümumiyyətlə bir və ya iki ikili fayl şəklində idi, qalan hər şey içəridə idi. Etibarlılıq çox aşağı idi, proqramın 2-3 nüsxəsini saxlamalı oldum. Yükləmə vaxtları da məyusedici idi və həvəskarlar bu çatışmazlıqları aradan qaldırmaq üçün müxtəlif tezlik kodlaşdırmaları ilə sınaqdan keçirdilər. O vaxt mən özüm hələ peşəkar proqram təminatının hazırlanması ilə məşğul deyildim (BASIC-də sadə proqramları saymırıq), buna görə də təəssüf ki, hər şeyin içəridə necə qurulduğunu sizə ətraflı danışmayacağam. Kompüterdə yalnız RAM olması faktı, məlumatların saxlanması sxeminin sadəliyini müəyyən etdi.
Etibarlı və böyük saxlama vasitələrinin yaranması
Sonralar disketlər meydana çıxdı, surətin çıxarılması prosesi sadələşdirildi, etibarlılıq artdı.
Ancaq vəziyyət yalnız kifayət qədər böyük yerli saxlama yerləri HDD şəklində göründükdə kəskin şəkildə dəyişir.
Çatdırılma növü əsaslı şəkildə dəyişir: sistemin konfiqurasiya prosesini idarə edən, eləcə də çıxarıldıqdan sonra təmizlənməsini idarə edən quraşdırıcı proqramlar görünür, çünki proqramlar sadəcə yaddaşa oxunmur, həm də artıq yerli yaddaşa kopyalanır, ondan istifadə etməlisiniz. lazım gələrsə, lazımsız şeyləri təmizləyə bilmək.
Eyni zamanda, təchiz edilmiş proqram təminatının mürəkkəbliyi artır.
Çatdırılmadakı faylların sayı bir neçədən yüzlərlə və minlərlə artır, kitabxana versiyaları və digər sevinclər arasında ziddiyyətlər müxtəlif proqramlar eyni məlumatlardan istifadə etdikdə başlayır.
O zamanlar Linux-un varlığı mənim üçün hələ açıq deyildi, mən MS DOS, daha sonra isə Windows dünyasında yaşayırdım, Borland Pascal və Delphi-də yazır, bəzən C++ dilinə baxırdım. Bir çox insanlar o zaman məhsulları çatdırmaq üçün InstallShield istifadə edirdilər. , proqram təminatının yerləşdirilməsi və konfiqurasiyası ilə bağlı bütün təyin edilmiş vəzifələri olduqca uğurla həll etdi.
internet dövrü
Tədricən proqram sistemlərinin mürəkkəbliyi daha da mürəkkəbləşir, monolit və masaüstü proqramlardan paylanmış sistemlərə, nazik müştərilərə və mikroservislərə keçid var. İndi yalnız bir proqramı deyil, onların bir dəstini konfiqurasiya etməlisiniz və hamısı birlikdə işləməlidir.
Konsepsiya tamamilə dəyişdi, internet gəldi, bulud xidmətləri dövrü gəldi. İndiyə qədər yalnız ilkin mərhələdə, veb-saytlar şəklində xidmətlər haqqında heç kim xüsusi xəyal qurmayıb. lakin bu, həm proqramların hazırlanmasında, həm də çatdırılmasında dönüş nöqtəsi idi.
Özüm üçün qeyd etdim ki, o anda inkişaf etdiricilərin nəsillərində dəyişiklik baş verdi (ya da bu, yalnız mənim mühitimdə idi) və bütün köhnə çatdırılma üsullarının bir anda unudulduğu və hər şeyin ən başlanğıcdan başladığı hissi var idi. başlanğıc: bütün çatdırılma diz skriptləri edilməyə başlandı və qürurla onu "Daimi çatdırılma" adlandırdı. Əslində, köhnənin unudulub istifadə olunmadığı, yeninin isə sadəcə mövcud olmadığı bir xaos dövrü başlayıb.
O vaxtlar işlədiyim şirkətimizdə (adını çəkməyəcəyəm) qarışqa vasitəsilə tikinti aparmaq əvəzinə (maven hələ məşhur deyildi və ya ümumiyyətlə mövcud deyildi) insanların sadəcə IDE-də bankalar yığdıqları və rahatlıqla işlədikləri vaxtları xatırlayıram. SVN-də. Müvafiq olaraq, yerləşdirmə faylın SVN-dən alınması və SSH vasitəsilə istədiyiniz maşına kopyalanmasından ibarət idi. Bu qədər sadə və yöndəmsizdir.
Eyni zamanda, PHP-də sadə saytların çatdırılması çox primitiv şəkildə düzəldilmiş faylı FTP vasitəsilə sadəcə hədəf maşına köçürməklə həyata keçirilirdi. Bəzən belə olmurdu - kod məhsul serverində canlı olaraq redaktə olunurdu və haradasa ehtiyat nüsxələri varsa, xüsusilə qəşəng idi.
RPM və DEB paketləri
Digər tərəfdən, İnternetin inkişafı ilə UNIX-ə bənzər sistemlər getdikcə daha çox populyarlıq qazanmağa başladı, xüsusən də RedHat Linux 6-nı, təxminən 2000-ci ildə kəşf etdim. Təbii ki, proqram təminatının çatdırılması üçün müəyyən vasitələr də var idi; Vikipediyaya görə, əsas paket meneceri kimi RPM artıq 1995-ci ildə RedHat Linux 2.0 versiyasında ortaya çıxdı. Və o vaxtdan və bu günə qədər sistem RPM paketləri şəklində çatdırıldı və kifayət qədər uğurla mövcuddur və inkişaf edir.
Debian ailəsinin paylamaları da oxşar yolla getdi və bu günə qədər dəyişməz qalan deb paketləri şəklində çatdırılmanı həyata keçirdi.
Paket menecerləri proqram məhsullarını özləri çatdırmağa, quraşdırma prosesi zamanı onları konfiqurasiya etməyə, müxtəlif paketlər arasında asılılıqları idarə etməyə, məhsulları silməyə və quraşdırma prosesi zamanı lazımsız elementləri təmizləməyə imkan verir. Bunlar. çox hissəsi üçün lazım olan hər şey budur, buna görə də onlar bir neçə onilliklər ərzində demək olar ki, dəyişməz qaldılar.
Bulud hesablama paket menecerlərinə təkcə fiziki mediadan deyil, həm də bulud depolarından quraşdırma əlavə etdi, lakin əsaslı olaraq çox az dəyişiklik etdi.
Qeyd etmək lazımdır ki, hazırda debdən uzaqlaşmaq və snap paketlərinə keçmək istiqamətində bəzi hərəkətlər var, lakin bu barədə daha sonra.
Beləliklə, nə DEB, nə də RPM bilməyən bu yeni nəsil bulud tərtibatçıları da yavaş-yavaş böyüdü, təcrübə qazandı, məhsullar daha mürəkkəbləşdi və FTP, bash skriptləri və buna bənzər tələbə sənətkarlıqlarından daha ağlabatan çatdırılma üsullarına ehtiyac duyuldu.
Və burada Docker virtuallaşdırma, resurs delimitasiyası və çatdırılma metodunun bir növ qarışığına daxil olur. İndi dəbli və gəncdir, amma hər şeyə ehtiyac varmı? Bu panaceadır?
Müşahidələrimə görə, çox vaxt Docker ağlabatan seçim kimi deyil, sadəcə ona görə təklif olunur ki, bir tərəfdən cəmiyyətdə bu haqda danışılır və bunu təklif edənlər ancaq bunu bilirlər. Digər tərəfdən, onlar çox vaxt yaxşı köhnə qablaşdırma sistemləri haqqında susurlar - onlar mövcuddur və öz işlərini sakit və diqqətdən kənarda saxlayırlar. Belə bir vəziyyətdə həqiqətən başqa seçim yoxdur - seçim göz qabağındadır - Docker.
Docker-i necə tətbiq etdiyimiz və bunun nəticəsində baş verənlərlə bağlı təcrübəmi bölüşməyə çalışacağam.
Öz-özünə yazılmış skriptlər
Əvvəlcə jar arxivlərini tələb olunan maşınlara yerləşdirən bash skriptləri var idi. Bu prosesi Cenkins idarə edirdi. Bu uğurla işlədi, çünki jar arxivinin özü artıq sinifləri, resursları və hətta konfiqurasiyanı ehtiva edən bir montajdır. Hər şeyi maksimuma çatdırırsınızsa, onu skriptə genişləndirmək sizə lazım olan ən çətin şey deyil
Lakin skriptlərin bir sıra çatışmazlıqları var:
- skriptlər adətən tələsik yazılır və buna görə də o qədər primitivdir ki, onlar yalnız bir ən yaxşı ssenarini ehtiva edir. Bu, tərtibatçının sürətli çatdırılmada maraqlı olması ilə asanlaşdırılır və normal bir skript layiqli miqdarda resurs sərmayəsini tələb edir.
- əvvəlki bəndin nəticəsi olaraq, skriptlərdə silmə prosedurları yoxdur
- müəyyən edilmiş təkmilləşdirmə proseduru yoxdur
- Yeni məhsul görünəndə yeni skript yazmalısınız
- asılılıq dəstəyi yoxdur
Əlbəttə ki, mürəkkəb bir ssenari yaza bilərsiniz, amma yuxarıda yazdığım kimi, bu inkişaf vaxtıdır və ən azı deyil və bildiyimiz kimi, həmişə kifayət qədər vaxt yoxdur.
Bütün bunlar açıq şəkildə bu yerləşdirmə metodunun tətbiq dairəsini yalnız ən sadə sistemlərlə məhdudlaşdırır. Bunu dəyişdirməyin vaxtı gəldi.
yükvuran
Müəyyən bir nöqtədə, təzə zərb edilmiş ortalar bizə gəlməyə başladı, fikirlərlə qaynayıb doker haqqında çılğınlaşdı. Yaxşı, bayraq əlində - gəlin bunu edək! İki cəhd oldu. Hər ikisi uğursuz oldu - deyək ki, böyük ambisiyalara görə, amma real təcrübənin olmaması. Bunu məcbur etmək və hər hansı bir vasitə ilə bitirmək lazım idimi? Bu mümkün deyil - komanda müvafiq vasitələrdən istifadə etməzdən əvvəl lazımi səviyyəyə qədər inkişaf etməlidir. Bundan əlavə, hazır Docker təsvirlərindən istifadə edərkən biz tez-tez şəbəkənin düzgün işləməməsi (bu, Docker-in özünün nəmliyi ilə bağlı ola bilər) və ya başqalarının konteynerlərini genişləndirməyin çətin olması faktı ilə tez-tez rastlaşırdıq.
Hansı çətinliklərlə qarşılaşdıq?
- Körpü rejimində şəbəkə problemləri
- Bir konteynerdə qeydlərə baxmaq əlverişsizdir (əgər onlar ana maşının fayl sistemində ayrıca saxlanılmırsa)
- ElasticSearch bəzən konteynerin içərisində qəribə şəkildə donur, səbəbi müəyyən edilməyib, konteyner rəsmidir
- Bir qabın içərisində bir qabıq istifadə etmək lazımdır - hər şey çox soyulmuşdur, adi alətlər yoxdur
- Yığılan qabların böyük ölçüsü - saxlamaq üçün bahalıdır
- Konteynerlərin böyük ölçüsünə görə, bir neçə versiyanı dəstəkləmək çətindir
- Digər üsullardan fərqli olaraq daha uzun qurma müddəti (skriptlər və ya deb paketləri)
Digər tərəfdən, eyni deb vasitəsilə bir jar arxivi şəklində Spring xidmətini yerləşdirmək niyə daha pisdir? Resurs izolyasiyası həqiqətən lazımdırmı? Xidməti çox azaldılmış konteynerə doldurmaqla rahat əməliyyat sistemi alətlərini itirməyə dəyərmi?
Təcrübə göstərdiyi kimi, əslində bu lazım deyil, deb paketi 90% hallarda kifayətdir.
Yaxşı köhnə deb nə vaxt uğursuz olur və bizə docker nə vaxt lazımdır?
Bizim üçün bu, python-da xidmətlərin yerləşdirilməsi idi. Maşın öyrənməsi üçün lazım olan və əməliyyat sisteminin standart paylanmasına daxil olmayan bir çox kitabxana (və yanlış versiyalar nə idi), parametrləri olan sındırmalar, eyni host sistemində yaşayan müxtəlif xidmətlər üçün fərqli versiyalara ehtiyac yarandı. bu, bu nüvə qarışığını təmin etməyin yeganə ağlabatan yolu doker idi. Doker konteynerinin yığılmasının əmək intensivliyi, hamısını asılılıqları olan ayrı-ayrı deb paketlərinə qablaşdırmaq fikrindən daha aşağı oldu və əslində ağlı başında olan heç kim bunu etməzdi.
Docker-dən istifadə etməyi planlaşdırdığımız ikinci nöqtə, mavi-yaşıl yerləşdirmə sxemindən istifadə edərək xidmətləri yerləşdirməkdir. Ancaq burada mürəkkəbliyin tədricən artmasına nail olmaq istəyirəm: əvvəlcə deb paketləri qurulur, sonra onlardan docker konteyneri qurulur.
Snap paketləri
Snap paketlərinə qayıdaq. İlk dəfə rəsmi olaraq Ubuntu 16.04-də ortaya çıxdılar. Adi deb paketlərindən və rpm paketlərindən fərqli olaraq, snap bütün asılılıqları daşıyır. Bu, bir tərəfdən, kitabxana konfliktlərinin qarşısını almağa imkan verir, digər tərəfdən, nəticədə paketin ölçüsü daha böyükdür. Bundan əlavə, bu, sistemin təhlükəsizliyinə də təsir edə bilər: sürətli çatdırılma halında, daxil edilmiş kitabxanalara edilən bütün dəyişikliklər paketi yaradan tərtibatçı tərəfindən izlənməlidir. Ümumiyyətlə, hər şey o qədər də sadə deyil və universal xoşbəxtlik onlardan istifadə etməklə gəlmir. Ancaq buna baxmayaraq, eyni Docker virtualizasiya üçün deyil, yalnız qablaşdırma aləti kimi istifadə edilərsə, bu tamamilə ağlabatan bir alternativdir.
Nəticədə, biz indi həm deb paketlərindən, həm də doker konteynerlərindən ağlabatan kombinasiyada istifadə edirik ki, ola bilsin ki, bəzi hallarda biz snap paketləri ilə əvəz edəcəyik.
Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. xahiş edirəm.
Çatdırılma üçün nə istifadə edirsiniz?
-
Öz-özünə yazılmış skriptlər
-
FTP-yə əl ilə kopyalayın
-
deb paketləri
-
rpm paketləri
-
snap paketləri
-
Docker-şəkillər
-
Virtual maşın şəkillər
-
Bütün HDD-ni klonlayın
-
kukla
-
ansible
-
Digər
109 istifadəçi səs verib. 32 istifadəçi bitərəf qalıb.
Mənbə: www.habr.com