Някога реших да напиша статия за доставката на контейнери Docker и deb пакети, но когато започнах, някак ме накара да се върна назад в далечните времена на първите персонални компютри и дори калкулатори. В крайна сметка, вместо сухи сравнения между Docker и deb, получиха се размисли за еволюцията, които представям на вашето внимание.
Всеки продукт, без значение какъв е, трябва по някакъв начин да стигне до продуктови сървъри, да бъде настроен и стартиран. Именно за това ще става дума в тази статия.
Ще размишлявам в исторически контекст, "каквото виждам — това и пея", относно това, което видях, когато започвах само да пиша код, и какво наблюдавам сега, какво ние самите използваме в момента и защо. Статията не претендира за пълно изследване, някои моменти са пропуснати, това е моят личен поглед върху това, което е било и какво е сега.
И така, в стари добри времена… най-ранният начин за доставка, който помня — това бяха касети за магнитофони. Имах компютър БК-0010.01…
Епохата на калкулаторите
Не, имаше и по-ранен момент, имаше и калкулатор и .
Така че, когато имах , начинът за пренос на програмата беше обикновен лист хартия в квадратчета, на който беше записана програмата, която при нужда се въвеждаше ръчно в калкулатора. Искаш да играеш (да-да, даже на този примитивен калкулатор имаше игри) — сядаш и вписваш програмата в калкулатора. Разбира се, при изключване на калкулатора, програмата изчезваше. Освен собственоръчно записаните на хартия кодове за калкулатора, програми бяха публикувани в списания "Радио" и "Техника на младежта", а също така печатани в книги от това време.
Следващата модификация беше калкулаторът , при който вече имаше нещо подобно на ненадеждно съхранение на данни. Сега не беше нужно играта или програмата да се въвеждат ръчно, а след като направиш някои магически движения с бутоните, тя се зареждаше сама.
Обемът на най-голямата програма в калкулатора беше 105 стъпки, а размерът на постоянната памет в МК-52 — 512 стъпки.
Но между другото, ако има фенове на тези калкулатори, които четат тази статия — в процеса на писането открих и емулатор на калкулатора за Android, както и програми за него. Напред, в миналото!
Няколко думи за МК-52 (от Уикипедия)
МК-52 летеше в космос с кораба "Союз ТМ-7". Предполагаше се да бъде използван за изчисляване на траекторията на кацане в случай, че бордовият компютър се повреди.
МК-52 с блок за разширяване на паметта "Електроника-Астро" от 1988 година се доставя на корабите на ВМС в състава на навигационния изчислителен комплекс.
Първите персонални компютри
Нека се върнем назад във времето . Разбира се, че и паметта там стана повече, а въвеждането на код от хартия вече не беше вариант (макар че в началото правех точно това, тъй като нямаше друг носител). Основното средство за съхранение и разпространение на софтуер станаха аудиокасетите за магнитофони.
Съхранението на касета обикновено беше под формата на един или два бинарни файла, всичко останало се съдържаше вътре. Надеждността беше много ниска, наложеше се да се държат 2-3 копия на програмата. Времето за зареждане също не радваше, ентусиастите експериментираха с различни честотни кодировки, за да преодолеят тези недостатъци. Аз самият тогава не се занимавах професионално с разработка на софтуер (освен прости програми на бейсик), затова в детайли как всичко беше устроено вътре, за съжаление, не мога да разкажа. Самият факт, че на компютъра имаше само ОЗУ, до голяма степен определяше простотата на схемата за съхранение на данни.
Появата на надеждни и големи носители на информация
По-късно се появяват флопи дискове, опростява се процесът на копиране, увеличава се надеждността.
Но ситуацията коренно се променя, едва когато се появят достатъчно големи локални хранилища във вид на HDD.
Принципно се променя типът на доставката: появяват се инсталатори, които управляват процеса на конфигуриране на системата, както и почистването след деинсталиране, тъй като програмите не просто се прочитат в паметта, а вече се копират в локалното хранилище, от което трябва да се научите как да изтривате ненужните при необходимост.
Паралелно с това нараства сложността на доставяния софтуер.
Броят на файловете в доставката нараства от единици до стотици и хиляди, започват конфликти с версиите на библиотеките и други радости, когато различни програми използват едни и същи данни.
В онези времена за мен все още не съществуваше Linux, живеех в света на MS DOS и по-късно Windows, а писах на Borland Pascal и Delphi, понякога поглеждайки към C++. За доставка на продукти тогава много хора използваха InstallShield , който успешно разрешаваше всички поставени задачи за разгръщане и конфигуриране на софтуер.
Епохата на интернет
Постепенно сложността на софтуерните системи се увеличава, от монолитни и десктоп приложения се преминава към разпределени системи, тънки клиенти и микросервизи. Сега трябва да конфигурирате не само едно приложение, а набор от тях, така че всички да работят заедно.
Концепцията изцяло се промени, дойде интернет, настъпи епохата на облачните услуги. Докато все още беше само в начален стадий, под формата на сайтове, особено никой не мечтаеше за услуги. Но това беше повратен момент в индустрията, както за разработката, така и за самото доставяне на приложения.
За себе си отбелязах, че в този момент настъпи смяна на поколенията разработчици (или това беше само в моето обкръжение), и се създаде такова усещане, че всичките стари добри начини за доставка бяха забравени изведнъж и всичко започна отначало: цялата доставка започна да се прави с наколеночни скриптове и бе наречена гордо „Непрекъсната доставка“. Всъщност започна някакъв период на хаос, когато старото беше забравено и не се използва, а новото просто го нямаше.
Помня времена, когато в нашата компания, където работех тогава (няма да споменавам името), вместо да правим сборка през ant (maven тогава още не беше популярен или изобщо не съществуваше), хората просто събираха jar в IDE и безсмислено го комитваха в SVN. Съответно, разгръщането се състоеше в изваждане на файла от SVN и копиране по SSH на нужната машина. Толкова просто и грубо.
По същото време доставката на прости сайтове на PHP се правеше съвсем примитивно с простото копиране на коригирания файл през FTP на целевата машина. Понякога нямаше и такова нещо — кодът се коригираше на живо на продукционния сървър и беше особено шиком, ако имаше някъде резервни копия.
RPM- и DEB-пакети
От друга страна, с развитието на интернет, все по-голяма популярност започнаха да получават UNIX-подобните системи, като именно по това време открих RedHat Linux 6, около 2000 г. Разбира се, и там имаше определени средства за доставка на софтуер, според Wikipedia, RPM като основен пакетен мениджър се появява чак през 1995 г. в версия RedHat Linux 2.0. И оттогава и до днешния ден системата се доставя под формата на RPM пакети и успешно съществува и се развива.
Дистрибутивите от семейството Debian тръгнаха по подобен път и реализираха доставката под формата на deb пакети, което също е неизменно до днешния ден.
Пакетните мениджъри позволяват доставката на самите софтуерни продукти, конфигурирането им по време на инсталацията, управление на зависимостите между различните пакети, извършване на премахване на продукти и почистване на излишното по време на деинсталация. Тоест, в по-голямата си част, това е всичко, което е необходимо, именно затова те издържаха няколко десетилетия практически без промени.
Облачността добави в пакетните мениджъри инсталация не само от физически носители, но и от облачни репозитории, но принципно малко се е променило.
Струва си да се отбележи, че в момента има някои опити да се откажат от deb и да се премине на snap пакети, но за това по-късно.
Така че, това ново поколение облачни разработчици, което не знаеше нито DEB, нито RPM, също постепенно растеше, натрупваше опит, продуктите се усложняваха, и бяха необходими някакви по-разумни начини за доставка, освен FTP, bash скриптчета и подобни студентски изпълнения.
И тук на сцената излиза Docker, нещо като смес от виртуализация, разделяне на ресурси и начин за доставка. В момента е на мода, младежко е, но нужен ли е за всичко? Панацея ли е това?
Според моите наблюдения, много често Docker се предлага не като разумен избор, а просто защото за него, от една страна, се говори в общността, и тези, които го предлагат, само него познават. От друга страна, за старите добри системи за опаковане по-голямата част мълчи — те са там и си вършат работата тихо и незабелязано. В такава ситуация друг избор не остава — изборът е очевиден — Docker.
Ще се опитам да споделя опита си, как при нас премина внедряването на Docker и какво в резултат се получи.
Самописни скриптове
Първоначално имаше bash скриптове, които внедряваха jar архиви на нужните машини. Процесът се управляваше от Jenkins. Това работеше успешно, тъй като самият jar архив вече представлява сборка, съдържаща класове, ресурси и дори конфигурация. Ако в него се съберат всичко максимално — разполагането му със скрипт не е най-сложната задача.
Но скриптовете имат няколко недостатъка:
- скриптовете обикновено се пишат на бързо и затова са толкова примитивни, че съдържат само един най-успешен сценарий. Това се дължи на факта, че разработчикът е заинтересован от бърза доставка, а един нормален скрипт изисква значителни ресурси.
- в резултат на предишната точка, скриптовете не съдържат процедура за деинсталиране.
- няма установена процедура за ъпгрейд.
- при появата на нов продукт трябва да се напише нов скрипт.
- няма поддръжка на зависимости.
Разбира се, може да се напише сложен скрипт, но, както вече споменах — това отнема време за разработка, и то не малко, а времето, както знаем, винаги е недостатъчно.
Всичко това очевидно ограничава използването на този метод на внедряване само до най-простите системи. Време е за промяна.
Docker
В един момент започнаха да идват нови мидлове, избухващи от идеи и хипнотизирани от Docker. Какво да правим, даваме зелена светлина — действаме! Имаше две опити. И двете неуспешни — да го кажем така, заради големи амбиции, но недостатъчен реален опит. Трябваше ли да натискаме и да довършим с каквито и да било средства? Вероятно не — екипът трябва еволюционно да достигне нужния ниво, преди да може да използва съответните инструменти. Освен това, използвайки готови Docker изображения, често се сблъсквахме с факта, че мрежата там не работеше коректно (може би, свързано с неустойчивостта на самия Docker) или беше трудно да се разширяват чуждите контейнери.
С какви неудобства се сблъскахме?
- Проблеми с мрежата в режим bridge.
- Непрактично е да се гледат логовете в контейнера (ако не са извлечени отделно в файловата система на хост машината).
- Периодично странно замразяване на ElasticSearch в контейнера, причината така и не беше установена, контейнерът е официален.
- Непрактично е да се използва шеллът вътре в контейнера — всичко е силно ограничено, няма познати инструменти.
- Голямото количество събирани контейнери е скъпо за съхранение
- Поради голямото количество контейнери е трудно да се поддържат множество версии
- По-дълъг процес на събиране в сравнение с други методи (скриптове или deb-пакети)
От друга страна, какво прави Spring-сервис в jar-формат по-лош за разгръщане в сравнение с deb? Нужна ли е наистина изолация на ресурсите? Струва ли си да се лишаваме от удобните инструменти на операционната система, поставяйки услугата в силно ограничен контейнер?
Както е показала практиката – в действителност това не е необходимо, deb-пакетът е достатъчен в 90% от случаите.
Кога старият добър deb наистина не проработва и кога наистина се нуждаем от Docker?
За нас това беше разгръщането на услуги на python. Множество библиотеки, нужни за машинно обучение, които липсват в стандартната версия на операционната система (а онова, което има – не е същата версия), хакове с настройки, необходимост от различни версии за различни услуги, които работят на същата хост-система, доведоха до извода, че единственият разумен начин за доставка на тази ядрена смес е Docker. Трудоемкостта на изграждането на Docker-контейнера се оказа по-ниска, отколкото идеята за опаковане на всичко това в отделни deb-пакети със зависимости, всъщност никой в здравия си ум не би се заел с това.
Вторият момент, където е планирано да се използва Docker – за разгръщане на услуги по схемата blue-green deploy. Но тук искам да получа постепенно увеличение на сложността: първо се събират deb-пакети, а след това от тях се изгражда Docker-контейнер.
Snap-пакети
Нека се върнем към snap-пакетите. За първи път те официално се появиха в Ubuntu 16.04. В отличие от обикновените deb-пакети и rpm-пакети, snap включват всички зависимости. От една страна, това позволява да се избегнат конфликти на библиотеки, от друга страна – това води до значителни размери на крайния пакет. Освен това, това може да повлияе на сигурността на системата: в случай на доставка на snap, за всички промени в включените библиотеки трябва да следи самият разработчик, който създава пакета. Общото е, че не всичко е толкова ясно и всеобщото щастие от тяхното използване не настъпва. Но, все пак, това е напълно разумна алтернатива, ако Docker се използва само като средство за опаковане, а не за виртуализация.
В резултат, в момента използваме разумна комбинация от deb пакети и Docker контейнери, които, възможно е, в отделни случаи да заменим със snap пакети.
Само регистрирани потребители могат да участват в анкетата. , моля.
А вие какво използвате за доставка?
Самописни скриптове
Копираме ръчно на FTP
deb пакети
rpm пакети
snap пакети
Docker изображения
Образи на виртуални машини
Клонираме целия HDD
puppet
ansible
Друго
Гласували са 109 потребители. 32 потребители са се въздържали.
Източник: habr.com
