Qandaydir tarzda men Docker konteynerlari va deb paketlari ko'rinishida etkazib berish haqida maqola yozishga qaror qildim, lekin men boshlaganimda, negadir men birinchi shaxsiy kompyuterlar va hatto kalkulyatorlarning uzoq vaqtlariga qaytdim. Umuman olganda, biz doker va debni quruq taqqoslash o'rniga, men sizning e'tiboringizga taqdim etayotgan evolyutsiya mavzusidagi bu fikrlarni oldik.
Har qanday mahsulot, nima bo'lishidan qat'i nazar, qandaydir tarzda mahsulot serverlariga kirishi kerak, sozlanishi va ishga tushirilishi kerak. Ushbu maqola nima haqida bo'ladi.
Men tarixiy kontekstda o'ylab ko'raman: "Men ko'rgan narsa men qo'shiq aytayotganim", kod yozishni boshlaganimda ko'rganlarim va hozir nimani kuzatayotganim, hozir o'zimiz nimadan foydalanayotganimiz va nima uchun. Maqola o'zini to'laqonli tadqiqot deb ko'rsatmaydi, ba'zi fikrlar o'tkazib yuborilgan, bu mening bo'lgan va hozir nima bo'lganiga shaxsiy nuqtai nazarim.
Shunday qilib, yaxshi kunlarda ... eng qadimgi etkazib berish usuli magnitofonlardan olingan kassetalar edi. Menda BK-0010.01 kompyuterim bor edi...
Kalkulyatorlar davri
Yo'q, bundan ham oldingi vaqt bor edi, kalkulyator ham bor edi ΠΈ .
Shunday qilib, men bo'lganimda , keyin dasturni o'tkazish usuli dastur yozilgan qutidagi oddiy qog'oz bo'lib, agar kerak bo'lsa, uni qo'lda ishlatish uchun kalkulyatorga yozilgan. Agar siz o'ynashni xohlasangiz (ha, hatto bu antediluvian kalkulyatorida ham o'yinlar bor edi) - siz o'tirib, dasturni kalkulyatorga kiritasiz. Tabiiyki, kalkulyator o'chirilganida, dastur unutilib ketdi. Shaxsan qog'ozga yozilgan kalkulyator kodlaridan tashqari, dasturlar "Radio" va "Yoshlar uchun texnologiya" jurnallarida nashr etilgan va o'sha davrning kitoblarida ham nashr etilgan.
Keyingi modifikatsiya kalkulyator edi , u allaqachon o'zgaruvchan bo'lmagan ma'lumotlarni saqlashga o'xshaydi. Endi o'yin yoki dasturni qo'lda kiritish shart emas edi, lekin tugmalar yordamida sehrli o'tishlarni amalga oshirgandan so'ng, u o'zini yukladi.
Kalkulyatordagi eng katta dastur hajmi 105 qadamni, MK-52 da doimiy xotira hajmi esa 512 qadamni tashkil etdi.
Aytgancha, agar ushbu maqolani o'qiyotgan ushbu kalkulyatorlarning muxlislari bo'lsa, maqolani yozish jarayonida men Android uchun kalkulyator emulyatorini ham, u uchun dasturlarni ham topdim. O'tmishga intiling!
MK-52 haqida qisqacha ma'lumot (Vikipediyadan)
MK-52 "Soyuz TM-7" kosmik kemasida koinotga uchdi. Agar bort kompyuteri ishlamay qolgan bo'lsa, u qo'nish traektoriyasini hisoblash uchun ishlatilishi kerak edi.
52 yildan beri Elektronika-Astro xotira kengaytirish blokiga ega MK-1988 dengiz floti kemalariga navigatsiya hisoblash to'plamining bir qismi sifatida etkazib berildi.
Birinchi shaxsiy kompyuterlar
Keling, zamonlarga qaytaylik . Ko'rinib turibdiki, u erda ko'proq xotira bor edi va qog'oz varag'idan kod yozish endi imkoniyat emas edi (garchi dastlab men buni qildim, chunki boshqa vosita yo'q edi). Magnitofonlar uchun audio kassetalar dasturiy ta'minotni saqlash va yetkazib berishning asosiy vositasiga aylanmoqda.
Kassetada saqlash odatda bitta yoki ikkita ikkilik fayl shaklida bo'lgan, qolgan hamma narsa uning ichida joylashgan edi. Ishonchlilik juda past edi, men dasturning 2-3 nusxasini saqlashim kerak edi. Yuklash vaqtlari ham umidsizlikka uchradi va ishqibozlar bu kamchiliklarni bartaraf etish uchun turli chastotali kodlashlar bilan tajriba o'tkazdilar. O'sha paytda men o'zim hali professional dasturiy ta'minotni ishlab chiqish bilan shug'ullanmagan edim (BASIC-dagi oddiy dasturlarni hisobga olmaganda), shuning uchun, afsuski, ichkarida hamma narsa qanday tuzilganligini batafsil aytib bermayman. Kompyuterda faqat operativ xotira mavjudligining o'zi ma'lumotlarni saqlash sxemasining soddaligini aniqladi.
Ishonchli va katta hajmli saqlash vositalarining paydo bo'lishi
Keyinchalik floppi disklar paydo bo'ldi, nusxa ko'chirish jarayoni soddalashtirildi va ishonchlilik oshdi.
Ammo vaziyat faqat qattiq disklar ko'rinishida etarlicha katta mahalliy xotiralar paydo bo'lganda keskin o'zgaradi.
Yetkazib berish turi tubdan o'zgarib bormoqda: tizimni sozlash, shuningdek olib tashlangandan keyin tozalash jarayonini boshqaradigan o'rnatuvchi dasturlari paydo bo'ladi, chunki dasturlar shunchaki xotiraga o'qilmaydi, balki allaqachon mahalliy xotiraga ko'chiriladi, undan agar kerak bo'lsa keraksiz narsalarni tozalashga qodir.
Shu bilan birga, taqdim etilgan dasturiy ta'minotning murakkabligi ortib bormoqda.
Yetkazib berishdagi fayllar soni bir necha yuzlab va minglabgacha ko'payadi, kutubxona versiyalari va boshqa quvonchlar o'rtasidagi ziddiyatlar turli dasturlar bir xil ma'lumotlardan foydalanganda boshlanadi.
O'sha paytda Linuxning mavjudligi men uchun hali ochiq emas edi, men MS DOS, keyinroq Windows dunyosida yashadim va Borland Paskal va Delphida yozdim, ba'zan C++ ga qaradim. O'sha paytda ko'pchilik mahsulotlarni etkazib berish uchun InstallShield-dan foydalangan. , bu dasturiy ta'minotni joylashtirish va sozlash bo'yicha barcha tayinlangan vazifalarni muvaffaqiyatli hal qildi.
Internet davri
Asta-sekin dasturiy ta'minot tizimlarining murakkabligi yanada murakkablashmoqda, monolit va ish stoli ilovalaridan taqsimlangan tizimlarga, nozik mijozlarga va mikroservislarga o'tish. Endi siz faqat bitta dasturni emas, balki ularning to'plamini va ularning barchasi birgalikda ishlashi uchun sozlashingiz kerak.
Kontseptsiya butunlay o'zgardi, Internet paydo bo'ldi, bulutli xizmatlar davri keldi. Hozircha, faqat dastlabki bosqichda, veb-saytlar ko'rinishida, hech kim xizmatlarni ayniqsa orzu qilmagan. lekin bu ilovalarni ishlab chiqishda ham, yetkazib berishda ham burilish nuqtasi bo'ldi.
Men o'zim uchun shuni ta'kidladimki, o'sha paytda ishlab chiquvchilarning avlodlari o'zgargan (yoki bu faqat mening muhitimda edi) va barcha yaxshi eski etkazib berish usullari bir zumda unutilgan va hamma narsa eng boshidan boshlangan degan tuyg'u bor edi. boshlanishi: barcha yetkazib berish tizza skriptlari amalga oshirila boshlandi va uni g'urur bilan "Uzluksiz etkazib berish" deb nomladi. Darhaqiqat, eskisi unutilib, ishlatilmaydigan, yangisi esa oddiygina mavjud bo'lmagan tartibsizlik davri boshlandi.
O'shanda men ishlagan kompaniyamizda (ismini aytmayman) chumolilar orqali qurish o'rniga (maven hali mashhur bo'lmagan yoki umuman yo'q edi) odamlar IDEda bankalarni yig'ib, xotirjamlik bilan qilgan vaqtlarini eslayman. u SVNda. Shunga ko'ra, tarqatish faylni SVN'dan olish va uni SSH orqali kerakli mashinaga nusxalashdan iborat edi. Bu juda oddiy va noqulay.
Shu bilan birga, PHPda oddiy saytlarni yetkazib berish juda ibtidoiy usulda tuzatilgan faylni FTP orqali maqsadli mashinaga oddiygina nusxalash orqali amalga oshirildi. Ba'zida bunday bo'lmagan - kod mahsulot serverida jonli ravishda tahrirlangan va agar biron bir joyda zaxira nusxalari mavjud bo'lsa, ayniqsa ajoyib edi.
RPM va DEB paketlari
Boshqa tomondan, Internetning rivojlanishi bilan UNIX-ga o'xshash tizimlar tobora ommalasha boshladi, xususan, men RedHat Linux 6 ni, taxminan 2000-yilda kashf etganman. Tabiiyki, dasturiy ta'minotni etkazib berish uchun ma'lum vositalar ham mavjud edi; Vikipediyaga ko'ra, RPM asosiy paket menejeri sifatida 1995 yilda RedHat Linux 2.0 versiyasida paydo bo'lgan. Va o'shandan beri va shu kungacha tizim RPM paketlari ko'rinishida etkazib berildi va juda muvaffaqiyatli mavjud va rivojlanmoqda.
Debian oilasining taqsimotlari xuddi shunday yo'ldan bordi va bugungi kungacha o'zgarmagan deb to'plamlari ko'rinishida etkazib berishni amalga oshirdi.
Paket menejerlari dasturiy ta'minot mahsulotlarini o'zlari yetkazib berish, o'rnatish jarayonida ularni sozlash, turli paketlar orasidagi bog'liqlikni boshqarish, mahsulotlarni olib tashlash va o'chirish jarayonida keraksiz narsalarni tozalash imkonini beradi. Bular. ko'pincha, bu zarur bo'lgan narsa, shuning uchun ular bir necha o'n yillar davomida deyarli o'zgarmagan.
Bulutli hisoblash paketlar menejerlariga nafaqat jismoniy mediadan, balki bulutli omborlardan ham o'rnatishni qo'shdi, lekin tubdan oz narsa o'zgargan.
Shuni ta'kidlash kerakki, hozirda debdan voz kechish va snap paketlarga o'tish bo'yicha ba'zi harakatlar bor, lekin bu haqda keyinroq.
Shunday qilib, na DEB, na RPMni bilmaydigan bulutli ishlab chiquvchilarning yangi avlodi ham asta-sekin o'sib bordi, tajriba orttirdi, mahsulotlar murakkablashdi va FTP, bash skriptlari va shunga o'xshash talaba hunarmandchiligiga qaraganda ancha oqilona etkazib berish usullari kerak edi.
Va bu erda Docker rasmga tushadi, bu virtualizatsiya, resurslarni chegaralash va etkazib berish usuli aralashmasi. Hozir moda va yosh, lekin hamma narsa uchun kerakmi? Bu panatseyami?
Mening kuzatishlarimga ko'ra, Docker ko'pincha oqilona tanlov sifatida emas, balki shunchaki, bir tomondan, bu haqda jamiyatda gapirilgani uchun taklif qilinadi va buni taklif qilganlar buni bilishadi. Boshqa tomondan, ular ko'pincha yaxshi eski qadoqlash tizimlari haqida sukut saqlaydilar - ular mavjud va o'z ishlarini jim va sezilmasdan bajaradilar. Bunday vaziyatda haqiqatan ham boshqa tanlov yo'q - tanlov aniq - Docker.
Men Docker-ni qanday amalga oshirganimiz va buning natijasida nima sodir bo'lganligi haqidagi tajribam bilan bo'lishishga harakat qilaman.
O'z-o'zidan yozilgan skriptlar
Dastlab, kerakli mashinalarga jar arxivlarini joylashtiradigan bash skriptlari mavjud edi. Bu jarayonni Jenkins boshqargan. Bu muvaffaqiyatli ishladi, chunki jar arxivining o'zi allaqachon sinflar, resurslar va hatto konfiguratsiyani o'z ichiga olgan yig'ilishdir. Agar siz hamma narsani maksimal darajada qo'ysangiz, uni skriptga kengaytirish sizga kerak bo'lgan eng qiyin narsa emas
Ammo skriptlarning bir nechta kamchiliklari bor:
- skriptlar odatda shoshqaloqlik bilan yoziladi va shuning uchun ular juda ibtidoiy bo'lib, ular faqat bitta eng yaxshi stsenariyni o'z ichiga oladi. Bunga ishlab chiquvchining tezkor yetkazib berishdan manfaatdorligi va oddiy skript munosib miqdorda resurslarni sarflashni talab qilishi bilan yordam beradi.
- oldingi bandning natijasi sifatida, skriptlarda o'chirish protseduralari mavjud emas
- o'rnatilgan yangilash tartibi yo'q
- Yangi mahsulot paydo bo'lganda, siz yangi skript yozishingiz kerak
- qaramlikni qo'llab-quvvatlamaydi
Albatta, siz murakkab skript yozishingiz mumkin, lekin men yuqorida yozganimdek, bu rivojlanish vaqti va eng muhimi emas va biz bilganimizdek, har doim ham vaqt etarli emas.
Bularning barchasi, shubhasiz, ushbu joylashtirish usulini qo'llash doirasini faqat eng oddiy tizimlar bilan cheklaydi. Buni o'zgartirish vaqti keldi.
Docker
Bir paytlar bizga yangi zarb qilingan o'rtamiyalar kela boshladilar, ular doker haqida g'oyalar bilan to'lib-toshgan. Xo'sh, qo'lda bayroq - qilaylik! Ikkita urinish bo'ldi. Ikkalasi ham muvaffaqiyatsiz bo'ldi - aytaylik, katta ambitsiyalar tufayli, lekin haqiqiy tajriba yo'qligi. Uni majburlash va har qanday usul bilan tugatish kerakmi? Bu dargumon - jamoa tegishli vositalardan foydalanishdan oldin kerakli darajaga ko'tarilishi kerak. Bundan tashqari, tayyor Docker tasvirlaridan foydalanganda, biz ko'pincha tarmoqning to'g'ri ishlamayotganligi (bu Dockerning o'zi namligi bilan bog'liq bo'lishi mumkin) yoki boshqalarning konteynerlarini kengaytirish qiyin bo'lgan holatlarga duch keldik.
Qanday noqulayliklarga duch keldik?
- Ko'prik rejimida tarmoq muammolari
- Jurnallarni konteynerda ko'rish noqulay (agar ular asosiy kompyuterning fayl tizimida alohida saqlanmasa)
- ElasticSearch vaqti-vaqti bilan konteyner ichida g'alati tarzda muzlaydi, sababi aniqlanmagan, konteyner rasmiy
- Idishning ichida qobiqdan foydalanish kerak - hamma narsa juda tozalangan, oddiy asboblar yo'q
- Yig'ilgan idishlarning katta hajmi - saqlash qimmat
- Konteynerlarning katta hajmi tufayli bir nechta versiyalarni qo'llab-quvvatlash qiyin
- Boshqa usullardan farqli o'laroq (skriptlar yoki deb paketlar) uzoqroq qurish vaqti
Boshqa tomondan, xuddi shu deb orqali jar arxivi ko'rinishida Spring xizmatini joylashtirish nima uchun yomonroq? Resurs izolyatsiyasi haqiqatan ham zarurmi? Xizmatni juda kamaytirilgan konteynerga to'ldirish orqali operatsion tizimning qulay vositalarini yo'qotishga arziydimi?
Amaliyot shuni ko'rsatadiki, aslida bu kerak emas, deb to'plami 90% hollarda etarli.
Yaxshi eski deb qachon muvaffaqiyatsiz bo'ladi va bizga qachon docker kerak?
Biz uchun bu python-da xizmatlarni tarqatish edi. Mashinani o'rganish uchun zarur bo'lgan va operatsion tizimning standart taqsimotiga kiritilmagan juda ko'p kutubxonalar (va noto'g'ri versiyalar bor edi), sozlamalarni buzish, bir xil xost tizimida yashovchi turli xizmatlar uchun turli versiyalarga bo'lgan ehtiyoj. Bu yadroviy aralashmani yetkazib berishning yagona oqilona yo'li doker edi. Docker konteynerini yig'ishdagi mehnat zichligi, uning barchasini bog'liqliklari bo'lgan alohida deb paketlarga qadoqlash g'oyasidan pastroq bo'lib chiqdi va aslida aqli bor hech kim buni zimmasiga olmaydi.
Docker-dan foydalanishni rejalashtirgan ikkinchi nuqta - bu ko'k-yashil joylashtirish sxemasidan foydalangan holda xizmatlarni joylashtirish. Ammo bu erda men murakkablikni bosqichma-bosqich oshirishni xohlayman: birinchi navbatda, deb paketlari quriladi, so'ngra ulardan docker konteyneri quriladi.
Snap paketlari
Keling, snap paketlarga qaytaylik. Ular birinchi marta Ubuntu 16.04 da rasmiy ravishda paydo bo'ldi. Odatiy deb paketlari va rpm paketlaridan farqli o'laroq, snap barcha bog'liqliklarni o'z ichiga oladi. Bu, bir tomondan, kutubxona mojarolaridan qochish imkonini beradi, boshqa tomondan, natijada olingan paket hajmi kattaroqdir. Bunga qo'shimcha ravishda, bu tizimning xavfsizligiga ham ta'sir qilishi mumkin: tezkor etkazib berishda, kiritilgan kutubxonalarga kiritilgan barcha o'zgarishlar paketni yaratgan ishlab chiquvchi tomonidan kuzatilishi kerak. Umuman olganda, hamma narsa juda oddiy emas va universal baxt ulardan foydalanishdan kelib chiqmaydi. Ammo, shunga qaramay, agar xuddi shu Docker virtualizatsiya uchun emas, balki faqat qadoqlash vositasi sifatida ishlatilsa, bu mutlaqo oqilona alternativa.
Natijada, biz endi deb paketlarini ham, docker konteynerlarini ham oqilona kombinatsiyada ishlatamiz, ehtimol, ba'zi hollarda biz snap paketlar bilan almashtiramiz.
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Yetkazib berish uchun nimadan foydalanasiz?
-
O'z-o'zidan yozilgan skriptlar
-
FTP-ga qo'lda nusxa ko'chiring
-
deb paketlari
-
rpm paketlari
-
snap paketlari
-
Docker-tasvirlar
-
Virtual mashina tasvirlar
-
Butun HDDni klonlash
-
qo'g'irchoq
-
sezilmaydigan
-
boshqa
109 nafar foydalanuvchi ovoz berdi. 32 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com