Еволуцијата на алатките за испорака или размислувањата за Docker, deb, jar и многу повеќе

Некако во еден момент решив да напишам статија за испорака во форма на Docker контејнери и деб пакети, но кога почнав, поради некоја причина бев однесен назад во далечните времиња на првите персонални компјутери, па дури и калкулатори. Во принцип, наместо суви споредби на докер и деб, ги добивме овие размислувања на темата еволуција, кои ви ги презентирам за разгледување.

Секој производ, без разлика што е, мора некако да стигне до серверите на производите, мора да биде конфигуриран и лансиран. Тоа е она што оваа статија ќе биде за.

Ќе размислувам во историски контекст, „она што го гледам е она за што пеам“, што видов кога првпат почнав да пишувам код и што набљудувам сега, што ние самите користиме во моментот и зошто. Статијата не се преправа дека е полноправна студија, некои точки се пропуштени, ова е мој личен став за тоа што беше и што е сега.

Така, во старите добри времиња... најраниот начин на испорака што го најдов беа касети од магнетофони. Имав компјутер BK-0010.01...

Ерата на калкулаторите

Не, имаше уште пораен момент, имаше и калкулатор МК-61 и МК-52.

Па кога имав МК-61, тогаш начинот на пренесување на програмата беше обичен лист хартија во кутија на која беше напишана програма, која по потреба, за рачно да се изврши, се пишуваше во калкулаторот. Ако сакате да играте (да, дури и овој калкулатор против дилувијата имаше игри) - седнувате и ја внесувате програмата во калкулаторот. Секако, кога калкулаторот беше исклучен, програмата исчезна во заборав. Покрај шифрите на калкулаторот лично испишани на хартија, програмите беа објавени во списанијата „Радио“ и „Технологија за млади“, а беа објавени и во книги од тоа време.

Следната модификација беше калкулатор МК-52, веќе има некој привид на неиспарливо складирање на податоци. Сега играта или програмата не мораше да се внесува рачно, туку откако изврши неколку магични додавања со копчињата, се вчита сама.

Големината на најголемата програма во калкулаторот беше 105 чекори, а големината на постојаната меморија во МК-52 беше 512 чекори.

Патем, ако има обожаватели на овие калкулатори кои ја читаат оваа статија, во процесот на пишување на статијата најдов и емулатор за калкулатор за Android и програми за него. Напред кон минатото!

• Емулатор МК-61 за Андроид
• Програмски каталог за МК-61

Кратка дигресија за МК-52 (од Википедија)

МК-52 полета во вселената со леталото Сојуз ТМ-7. Требаше да се користи за пресметување на траекторијата на слетување во случај да не успее вградениот компјутер.

Од 52 година, MK-1988 со единицата за проширување на меморијата Elektronika-Astro се доставува до бродовите на морнарицата како дел од комплет за навигациски компјутери.

Првите персонални компјутери

Да се ​​вратиме на времињата п.н.е.-0010. Јасно е дека таму имаше повеќе меморија, а пишувањето код од парче хартија веќе не беше опција (иако на почетокот го правев токму тоа, бидејќи едноставно немаше друг медиум). Аудио касетите за магнетофони стануваат главно средство за складирање и испорака на софтвер.

Складирањето на касета обично беше во форма на една или две бинарни датотеки, сè друго беше содржано внатре. Доверливоста беше многу мала, морав да задржам 2-3 примероци од програмата. Времето на вчитување беше исто така разочарувачки, а ентузијастите експериментираа со различни шифри за фреквенција за да ги надминат овие недостатоци. Во тоа време, јас самиот сè уште не бев вклучен во професионален развој на софтвер (не сметајќи ги едноставните програми во BASIC), така што, за жал, нема да ви кажам детално како сè беше уредено внатре. Самиот факт дека компјутерот во најголем дел имал само RAM меморија ја одредувал едноставноста на шемата за складирање податоци.

Појавата на сигурни и големи медиуми за складирање

Подоцна, се појавија флопи дискови, процесот на копирање беше поедноставен, а доверливоста се зголеми.
Но, ситуацијата драматично се менува само кога се појавуваат доволно големи локални складишта во форма на HDD.

Типот на испорака фундаментално се менува: се појавуваат програми за инсталирање кои управуваат со процесот на конфигурирање на системот, како и чистење по отстранувањето, бидејќи програмите не само што се читаат во меморијата, туку веќе се копираат во локално складирање, од кое треба да да може да ги расчисти непотребните работи доколку е потребно.

Во исто време, комплексноста на испорачаниот софтвер се зголемува.
Бројот на датотеки во испораката се зголемува од неколку на стотици и илјадници, конфликтите помеѓу верзиите на библиотеката и другите радости започнуваат кога различни програми користат исти податоци.

Во тоа време, постоењето на Linux сè уште не ми беше отворено; живеев во светот на MS DOS, а подоцна и на Windows, и пишував во Borland Pascal и Delphi, понекогаш гледајќи кон C++. Многу луѓе користеа InstallShield за да доставуваат производи во тоа време. ru.wikipedia.org/wiki/InstallShield, кој доста успешно ги реши сите зададени задачи за распоредување и конфигурирање на софтверот.

Интернет ера

Постепено, сложеноста на софтверските системи станува уште посложена, од монолитните и десктоп апликациите се преминува кон дистрибуирани системи, тенки клиенти и микроуслуги. Сега треба да конфигурирате не само една програма, туку збир од нив, и така што сите тие работат заедно.

Концептот целосно се промени, дојде интернетот, дојде ерата на облак услуги. Досега, само во почетната фаза, во форма на веб-страници, никој особено не сонувал за услуги. но тоа беше пресвртница и во развојот и во испораката на апликациите.

За себе, забележав дека во тој момент имаше промена на генерации на програмери (или тоа беше само во мојата околина), и имаше чувство дека сите стари добри методи на испорака беа заборавени во еден момент и сè започна од самиот почеток: целата испорака почна да се врши според скриптите на коленото и гордо ја нарече „Континуирана испорака“. Всушност, започна период на хаос, кога старото се заборава и не се користи, а новото едноставно не постои.

Се сеќавам на времињата кога во нашата компанија каде што работев тогаш (нема да именувам), наместо да градат преку мравка (мавен сè уште не беше популарен или воопшто не постоеше), луѓето едноставно собираа тегли во IDE и мирно се обврзаа тоа во SVN. Според тоа, распоредувањето се состоеше од преземање на датотеката од SVN и нејзино копирање преку SSH на саканата машина. Толку е едноставно и несмасно.

Во исто време, испораката на едноставни сајтови во PHP беше направена на многу примитивен начин со едноставно копирање на коригираната датотека преку FTP на целната машина. Понекогаш тоа не беше случај - кодот се уредуваше во живо на серверот на производот и беше особено шик ако некаде имаше резервни копии.

RPM и DEB пакети

Од друга страна, со развојот на Интернет, системите слични на UNIX почнаа да добиваат сè поголема популарност, особено, токму во тоа време го открив RedHat Linux 6, приближно 2000 година. Секако, имаше и одредени средства за доставување софтвер; според Википедија, RPM како главен менаџер на пакети се појави веќе во 1995 година, во верзијата на RedHat Linux 2.0. И оттогаш и до денес, системот се испорачува во форма на RPM пакети и доста успешно постои и се развива.

Дистрибуциите на семејството Debian следеа сличен пат и имплементираа испорака во форма на deb пакети, која остана непроменета до ден-денес.

Управувачите на пакети ви дозволуваат сами да ги доставувате софтверските производи, да ги конфигурирате за време на процесот на инсталација, да управувате со зависностите помеѓу различните пакети, да ги отстранувате производите и да ги исчистите непотребните предмети за време на процесот на деинсталирање. Оние. во најголем дел, тоа е сè што е потребно, поради што тие траеја неколку децении практично непроменети.

Cloud computing додаде инсталација на менаџерите на пакети не само од физички медиуми, туку и од складишта на облак, но суштински малку се промени.

Вреди да се напомене дека во моментов има некои потези кон оддалечување од deb и префрлување на Snap пакети, но повеќе за тоа подоцна.

Така, оваа нова генерација на развивачи на облак, кои не знаеја ниту DEB ниту RPM, исто така полека растеше, стекна искуство, производите станаа посложени и беа потребни некои поразумни методи за испорака од FTP, баш скриптите и слични студентски занаети.
И ова е местото каде што Docker доаѓа на сликата, еден вид мешавина на виртуелизација, разграничување на ресурсите и метод на испорака. Сега е модерно и младешко, но дали е потребно за се? Дали е ова лек?

Според моите согледувања, многу често Докер се предлага не како разумен избор, туку едноставно затоа што, од една страна, за него се зборува во заедницата, а тие што го предлагаат само тоа го знаат. Од друга страна, во најголем дел молчат за старите добри системи за пакување - тие постојат и си ја вршат работата тивко и незабележано. Во таква ситуација, навистина нема друг избор - изборот е очигледен - Докер.

Ќе се обидам да го споделам моето искуство за тоа како го имплементиравме Docker и што се случи како резултат.

Само-напишани скрипти

Првично, имаше баш скрипти кои распоредуваа архиви на тегли на потребните машини. Овој процес беше управуван од Џенкинс. Ова функционираше успешно, бидејќи самата архива на тегла е веќе склоп што содржи класи, ресурси, па дури и конфигурација. Ако ставите сè во него до максимум, тогаш проширувањето во скрипта не е најтешкото нешто што ви треба

Но, скриптите имаат неколку недостатоци:

• скриптите обично се пишуваат набрзина и затоа се толку примитивни што содржат само едно најдобро сценарио. Ова е олеснето со фактот дека инвеститорот е заинтересиран за брза испорака, а нормалната скрипта бара инвестирање на пристојна количина ресурси
• како последица на претходната точка, скриптите не содржат процедури за деинсталирање
• нема воспоставена процедура за надградба
• Кога ќе се појави нов производ, треба да напишете нова скрипта
• нема поддршка за зависност

Се разбира, можете да напишете софистицирано сценарио, но, како што напишав погоре, ова е време за развој, и не најмалку важно, и, како што знаеме, секогаш нема доволно време.

Сето ова очигледно го ограничува опсегот на примена на овој метод на распоредување само на наједноставните системи. Дојде време ова да се промени.

пристанишен работник

Во одреден момент, почнаа да доаѓаат кај нас свежо исковани средини, вриејќи од идеи и беснеејќи по докерот. Па, знаме во рака - ајде да го направиме тоа! Имаше два обиди. И двајцата беа неуспешни - да речеме, поради големи амбиции, но недостаток на вистинско искуство. Дали беше неопходно да се присили и да се заврши на кој било можен начин? Малку е веројатно - тимот мора да еволуира до потребното ниво пред да може да ги користи соодветните алатки. Дополнително, кога користевме готови слики на Docker, честопати наидувавме на фактот дека мрежата не работи правилно (што можеби се должи на влагата на самиот Docker) или беше тешко да се прошират туѓите контејнери.

На какви непријатности наидовме?

• Мрежни проблеми во режим на мост
• Незгодно е да се гледаат дневници во контејнер (ако тие не се зачувани одделно во датотечниот систем на машината домаќин)
• ElasticSearch повремено чудно замрзнува внатре во контејнерот, причината не е утврдена, контејнерот е официјален
• Неопходно е да се користи школка во контејнер - сè е многу соголено, нема познати алатки
• Големи димензии на собрани контејнери - скапи за складирање
• Поради големата големина на контејнерите, тешко е да се поддржат повеќе верзии
• Подолго време за градење, за разлика од другите методи (скрипти или деб пакети)

Од друга страна, зошто е полошо да се распореди пролетна услуга во форма на архива на тегли преку истиот деб? Дали изолацијата на ресурсите е навистина потребна? Дали вреди да се загубат пригодните алатки на оперативниот систем со полнење на услугата во многу намален контејнер?

Како што покажа практиката, во реалноста тоа не е потребно, деб пакетот е доволен во 90% од случаите.

Кога стариот добар деб пропаѓа и кога навистина ни е потребен докер?

За нас, ова беше распоредување услуги во python. Многу библиотеки потребни за машинско учење и кои не се вклучени во стандардната дистрибуција на оперативниот систем (а што беше таму беа погрешните верзии), хакерите со поставките, потребата за различни верзии за различни услуги кои живеат на ист систем домаќин доведе до ова, дека единствениот разумен начин да се испорача оваа нуклеарна мешавина е докерот. Интензитетот на трудот на склопување на докер-контејнер се покажа како помал од идејата сето тоа да се спакува во посебни деб-пакети со зависности, а всушност никој со здрав ум не би го направил тоа.

Втората точка каде што планираме да го користиме Docker е да распоредиме услуги користејќи ја шемата за распоредување сино-зелена. Но, овде сакам да добијам постепено зголемување на сложеноста: прво се градат деб-пакети, а потоа од нив се гради докер-контејнер.

Snap пакети

Да се ​​вратиме на привремените пакети. Тие првпат официјално се појавија во Ubuntu 16.04. За разлика од вообичаените deb пакети и пакети за вртежи во минута, Snap ги носи сите зависности. Од една страна, ова ви овозможува да избегнете конфликти во библиотеката, од друга страна, добиениот пакет е поголем по големина. Покрај тоа, ова може да влијае и на безбедноста на системот: во случај на навремена испорака, сите промени во вклучените библиотеки мора да бидат надгледувани од развивачот кој го создава пакетот. Во принцип, не е сè толку едноставно и универзалната среќа не доаѓа од нивното користење. Но, сепак, ова е сосема разумна алтернатива доколку истиот Docker се користи само како алатка за пакување, а не за виртуелизација.

Како резултат на тоа, сега ги користиме и деб пакетите и докерските контејнери во разумна комбинација, кои, можеби, во некои случаи ќе ги замениме со snap пакети.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Што користите за испорака?

• Само-напишани скрипти

• Копирај рачно на FTP

• deb пакети

• вртежи во минута пакети

• предвремени пакети

• Докер-слики

• Слики од виртуелна машина

• Клонирајте го целиот HDD

• куклен

• одговорен

• Останати

Гласаа 109 корисници. 32 корисници се воздржаа.

Извор: www.habr.com