🥇Еволюцията на инструментите за доставка или мисли за Docker, deb, jar и други

Някак си в един момент реших да напиша статия за доставката под формата на Docker контейнери и deb пакети, но когато започнах, по някаква причина се върнах в далечните времена на първите персонални компютри и дори калкулатори. Като цяло, вместо сухи сравнения на docker и deb, получихме тези мисли по темата за еволюцията, които представям на вашето внимание.

Всеки продукт, независимо какъв е, трябва по някакъв начин да стигне до продуктовите сървъри, трябва да бъде конфигуриран и стартиран. За това ще бъде тази статия.

Ще мисля в исторически контекст „това, което виждам, е това, за което пея“, какво видях, когато за първи път започнах да пиша код и какво наблюдавам сега, какво използваме ние самите в момента и защо. Статията не претендира да бъде пълноценно изследване, някои моменти са пропуснати, това е моето лично виждане за това какво беше и какво е сега.

И така, в добрите стари времена... най-ранният метод за доставка, който открих, бяха касети от магнетофони. Имах компютър BK-0010.01...

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

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

Така че, когато имах MK-61, тогава начинът за прехвърляне на програмата беше обикновен лист хартия в кутия, на който беше написана програма, която, ако е необходимо, за да я стартирате ръчно, се записваше в калкулатора. Ако искате да играете (да, дори този допотопен калкулатор имаше игри) - сядате и въвеждате програмата в калкулатора. Естествено, когато калкулаторът беше изключен, програмата изчезна в забрава. В допълнение към кодовете на калкулатора, написани лично на хартия, програмите са публикувани в списанията „Радио“ и „Техника за младежта“, а също така са публикувани в книги от онова време.

Следващата модификация беше калкулатор MK-52, вече има някакво подобие на енергонезависимо хранилище на данни. Сега играта или програмата не трябваше да се въвеждат ръчно, но след извършване на някои магически пасове с бутоните, тя се зареждаше сама.

Размерът на най-голямата програма в калкулатора беше 105 стъпки, а размерът на постоянната памет в MK-52 беше 512 стъпки.

Между другото, ако има фенове на тези калкулатори, които четат тази статия, в процеса на писане на статията намерих както емулатор на калкулатор за Android, така и програми за него. Напред към миналото!

Кратко отклонение за MK-52 (от Wikipedia)

МК-52 излетя в космоса на космическия кораб Союз ТМ-7. Той трябваше да се използва за изчисляване на траекторията на кацане в случай на повреда на бордовия компютър.

От 52 г. MK-1988 с модула за разширяване на паметта Elektronika-Astro се доставя на кораби на ВМС като част от навигационен изчислителен комплект.

Първите персонални компютри

Да се върнем на времената BK-0010. Ясно е, че там имаше повече памет и писането на код от лист хартия вече не беше опция (въпреки че в началото правех точно това, защото просто нямаше друг носител). Аудио касетите за магнетофони се превръщат в основно средство за съхранение и доставка на софтуер.

Съхранението на касета обикновено беше под формата на един или два двоични файла, всичко останало се съдържаше вътре. Надеждността беше много ниска, трябваше да пазя 2-3 копия на програмата. Времето за зареждане също беше разочароващо и ентусиастите експериментираха с различни честотни кодирания, за да преодолеят тези недостатъци. По това време самият аз все още не се занимавах с професионална разработка на софтуер (без да броим простите програми в BASIC), така че, за съжаление, няма да ви разкажа подробно как всичко беше подредено вътре. Самият факт, че компютърът имаше само RAM в по-голямата си част, определяше простотата на схемата за съхранение на данни.

Появата на надеждни и големи носители за съхранение

По-късно се появиха флопи дискове, процесът на копиране беше опростен и надеждността се увеличи.
Но ситуацията се променя драматично само когато се появят достатъчно големи локални хранилища под формата на твърди дискове.

Типът доставка се променя фундаментално: появяват се програми за инсталиране, които управляват процеса на конфигуриране на системата, както и почистване след премахване, тъй като програмите не се четат само в паметта, но вече се копират в локално хранилище, от което трябва да можете да изчистите ненужните неща, ако е необходимо.

В същото време сложността на доставяния софтуер нараства.
Броят на файловете в доставката се увеличава от няколко до стотици и хиляди, конфликтите между версиите на библиотеката и други радости започват, когато различни програми използват едни и същи данни.

По това време съществуването на Linux все още не беше открито за мен; живеех в света на MS DOS и по-късно на Windows и пишех на Borland Pascal и Delphi, понякога гледайки към C++. Много хора използваха InstallShield, за да доставят продукти тогава. ru.wikipedia.org/wiki/InstallShield, който доста успешно реши всички поставени задачи по внедряване и конфигуриране на софтуера.

Интернет ера

Постепенно сложността на софтуерните системи става още по-сложна; от монолитни и настолни приложения се преминава към разпределени системи, тънки клиенти и микроуслуги. Сега трябва да конфигурирате не само една програма, а набор от тях, така че всички да работят заедно.

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

За себе си отбелязах, че в този момент имаше промяна в поколенията разработчици (или беше само в моята среда) и имаше усещането, че всички добри стари методи за доставка са забравени в един момент и всичко започва от самото начало: всички доставки започнаха да се извършват на коляно скриптове и гордо го нарекоха „Непрекъсната доставка“. Всъщност започна период на хаос, когато старото се забравя и не се използва, а новото просто не съществува.

Спомням си времето, когато в нашата компания, в която работех тогава (няма да я назовавам), вместо да изграждат чрез ant (maven все още не беше популярен или изобщо не съществуваше), хората просто събираха буркани в IDE и спокойно се ангажираха го в SVN. Съответно внедряването се състоеше от извличане на файла от SVN и копирането му чрез SSH на желаната машина. Толкова е просто и тромаво.

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

RPM и DEB пакети

От друга страна, с развитието на Интернет UNIX-подобните системи започнаха да набират все по-голяма популярност, по-специално по това време открих RedHat Linux 6, приблизително 2000 г. Естествено, имаше и определени средства за доставка на софтуер; според Wikipedia RPM като основен мениджър на пакети се появи още през 1995 г. във версията на RedHat Linux 2.0. И оттогава до ден днешен системата се доставя под формата на RPM пакети и доста успешно съществува и се развива.

Дистрибуциите на фамилията Debian следваха подобен път и реализираха доставка под формата на deb пакети, което остава непроменено и до днес.

Мениджърите на пакети ви позволяват да доставяте самите софтуерни продукти, да ги конфигурирате по време на процеса на инсталиране, да управлявате зависимости между различни пакети, да премахвате продукти и да почиствате ненужните елементи по време на процеса на деинсталиране. Тези. в по-голямата си част това е всичко, което е необходимо, поради което те издържаха няколко десетилетия практически непроменени.

Cloud computing добави инсталация към мениджърите на пакети не само от физически носители, но и от облачни хранилища, но фундаментално малко се е променило.

Струва си да се отбележи, че понастоящем има някои стъпки към отдалечаване от deb и преминаване към пакети snap, но повече за това по-късно.

И така, това ново поколение облачни разработчици, които не познаваха нито DEB, нито RPM, също бавно израснаха, натрупаха опит, продуктите станаха по-сложни и бяха необходими някои по-разумни методи за доставка от FTP, bash скриптове и подобни ученически занаяти.
И тук се появява Docker, нещо като смесица от виртуализация, разделяне на ресурси и метод на доставка. Сега е модерно и младежко, но дали е необходимо за всичко? Това ли е панацея?

По мои наблюдения много често Docker се предлага не като разумен избор, а просто защото, от една страна, се говори за него в общността и тези, които го предлагат, само го знаят. От друга страна, в по-голямата си част мълчат за добрите стари опаковъчни системи – те съществуват и си вършат работата тихо и незабелязано. В такава ситуация наистина няма друг избор - изборът е очевиден - Docker.

Ще се опитам да споделя опита си как внедрихме Docker и какво се случи в резултат.

Самостоятелно написани сценарии

Първоначално имаше bash скриптове, които разгръщаха jar архиви на необходимите машини. Този процес беше управляван от Дженкинс. Това работи успешно, тъй като самият jar архив вече е сборка, съдържаща класове, ресурси и дори конфигурация. Ако вложите всичко в него максимално, тогава разширяването му в скрипт не е най-трудното нещо, от което се нуждаете

Но скриптовете имат няколко недостатъка:

скриптовете обикновено се пишат набързо и следователно са толкова примитивни, че съдържат само един най-добър сценарий. Това се улеснява от факта, че разработчикът се интересува от бърза доставка, а нормалният скрипт изисква инвестиране на прилично количество ресурси
като следствие от предходната точка, скриптовете не съдържат процедури за деинсталиране
няма установена процедура за надграждане
Когато се появи нов продукт, трябва да напишете нов скрипт
без поддръжка на зависимости

Разбира се, можете да напишете сложен скрипт, но, както писах по-горе, това е време за разработка, и то не на последно място, а както знаем, винаги няма достатъчно време.

Всичко това очевидно ограничава обхвата на приложение на този метод на внедряване само до най-простите системи. Дойде време да променим това.

докер

В един момент при нас започнаха да идват прясно изсечени среди, кипящи от идеи и бълнуващи за докера. Е, знамето в ръка - да го направим! Имаше два опита. И двете бяха неуспешни - да кажем, поради големи амбиции, но липса на реален опит. Беше ли необходимо да го насилваме и да го довършваме с всички необходими средства? Малко вероятно е - екипът трябва да се развие до необходимото ниво, преди да може да използва подходящите инструменти. Освен това, когато използвахме готови изображения на Docker, често срещахме факта, че мрежата не работи правилно (което може да се дължи на влагата на самия Docker) или беше трудно да се разширят контейнерите на други хора.

Какви неудобства срещнахме?

Мрежови проблеми в мостов режим
Неудобно е да преглеждате регистрационни файлове в контейнер (ако не се съхраняват отделно във файловата система на хост машината)
ElasticSearch понякога замръзва странно вътре в контейнера, причината не е установена, контейнерът е официален
Необходимо е да използвате черупка вътре в контейнер - всичко е много изчистено, няма обичайни инструменти
Голям размер на събраните контейнери - скъпо за съхранение
Поради големия размер на контейнерите е трудно да се поддържат множество версии
По-дълго време за изграждане, за разлика от други методи (скриптове или deb пакети)

От друга страна, защо е по-лошо да разположите Spring услуга под формата на jar архив през същия deb? Наистина ли е необходима изолация на ресурсите? Струва ли си да загубите удобните инструменти на операционната система, като поставите услуга в значително намален контейнер?

Както показа практиката, в действителност това не е необходимо, пакетът deb е достатъчен в 90% от случаите.

Кога добрият стар deb се проваля и кога наистина имаме нужда от докер?

За нас това беше внедряване на услуги в Python. Много библиотеки, необходими за машинно обучение и не включени в стандартната дистрибуция на операционната система (и това, което имаше, бяха грешните версии), хакове с настройки, необходимостта от различни версии за различни услуги, живеещи на една и съща хост система, доведоха до това, че единственият разумен начин да се достави тази ядрена смес е докерът. Трудоемкостта на сглобяването на докер контейнер се оказа по-ниска от идеята да се опакова всичко в отделни deb пакети със зависимости и всъщност никой с здрав ум не би предприел това.

Втората точка, в която планираме да използваме Docker, е да разположим услуги, използвайки синьо-зелената схема за разгръщане. Но тук искам да получа постепенно увеличаване на сложността: първо се изграждат deb пакети, а след това от тях се изгражда докер контейнер.

Снап пакети

Да се върнем към пакетите за прикачване. Те се появиха за първи път официално в Ubuntu 16.04. За разлика от обичайните deb пакети и rpm пакети, snap носи всички зависимости. От една страна, това ви позволява да избегнете библиотечни конфликти, от друга страна, полученият пакет е с по-голям размер. В допълнение, това също може да повлияе на сигурността на системата: в случай на моментна доставка, всички промени на включените библиотеки трябва да бъдат наблюдавани от разработчика, който създава пакета. Като цяло не всичко е толкова просто и всеобщото щастие не идва от използването им. Но въпреки това това е напълно разумна алтернатива, ако същият Docker се използва само като инструмент за пакетиране, а не за виртуализация.

В резултат на това сега използваме както deb пакети, така и docker контейнери в разумна комбинация, която може би в някои случаи ще заменим със snap пакети.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Какво използвате за доставка?

Самостоятелно написани сценарии
Копирайте ръчно на FTP
deb пакети
rpm пакети
модулни пакети
Докер изображения
Изображения на виртуална машина
Клонирайте целия HDD
кукла на конци
ansible
Друг

109 потребители гласуваха. 32 потребители се въздържаха.

Източник: www.habr.com

Еволюцията на инструментите за доставка или мисли за Docker, deb, jar и други