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