Неяк у адзін момант я вырашыў напісаць артыкул пра пастаўку ў выглядзе кантэйнераў докер і 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-архіў ужо з'яўляецца зборкай, утрымоўвальнай у сабе класы, рэсурсы і нават канфігурацыю. Калі скласці ў яго ўсё па максімуме - тое раскласці яго скрыптам - гэта не самае складанае, што трэба
Але ў скрыптоў ёсць некалькі недахопаў:
- скрыпты звычайна пішуцца на хуткую руку і таму настолькі прымітыўныя, што змяшчаюць толькі адзін самы шчасны сцэнар. Гэтаму спрыяе тое, што распрацоўшчык зацікаўлены ў больш хуткай пастаўцы, а нармальны скрыпт патрабуе ўкладанне прыстойнай колькасці рэсурсаў.
- як следства папярэдняга пункта, скрыпты не ўтрымоўваюць працэдуры дэўсталёўкі
- няма ўсталяванай працэдуры апгрэйду
- пры з'яўленні новага прадукта трэба пісаць новы скрыпт
- няма падтрымкі залежнасцяў
Вядома, можна напісаць наварочаны скрыпт, але, як я пісаў вышэй - гэта час на распрацоўку, прычым не самае малое, а часу, як вядома, заўсёды не хапае.
Гэта ўсё відавочна абмяжоўвае круг ужывання такога спосабу разгортвання толькі найпростымі сістэмамі. Надышоў момант гэта мяняць.
Докер
У нейкі момант да нас пачалі прыходзіць свежыя мідлы, якія бурлілі ідэямі і трызняць докерам. Што ж, сцяг у рукі - які робіцца! Было дзве спробы. Абедзве няўдалых - скажам так, з-за вялікіх амбіцый, але недастатковасці рэальнага вопыту. Ці трэба было фарсіраваць і дарабляць любымі сіламі? Ці наўрад калектыў павінен эвалюцыйна дарасці да патрэбнага ўзроўня, перш чым зможа выкарыстаць якія адпавядаюць прылады. Да ўсяго іншага, выкарыстоўваючы гатовыя вобразы докера, мы часта сутыкаліся з тым, што там некарэктна працавала сетка (што, магчыма, было яшчэ звязана з волкасцю самага докера) ці было складана пашыраць чужыя кантэйнеры.
З якімі нязручнасцямі мы сутыкнуліся?
- Праблемы з сеткай у рэжыме bridge
- Няёмка глядзець логі ў кантэйнеры (калі яны нікуды не вынесены асобна ў файлавую сістэмы хост-машыны)
- Перыядычна дзіўнае завісанне ElasticSearch ўнутры кантэйнера, прычыну так і не ўсталявалі, кантэйнер афіцыйны
- Трэба карыстацца шеллом усярэдзіне кантэйнера — усё моцна зрэзана, няма звыклых прылад
- Вялікі памер збіраемых кантэйнераў - дорага захоўваць
- З-за вялікага памеру кантэйнераў складана падтрымліваць шматлікія версіі.
- Больш працяглая зборка, у адрозненне ад іншых спосабаў (скрыпты ці deb-пакеты)
З іншага боку, чым Spring-сэрвіс у выглядзе jar-архіва горш дэплоіць праз той жа deb? Ці рэальна патрэбна ізаляцыя рэсурсаў? Ці варта пазбаўляцца зручных прылад аперацыйнай сістэмы, запіхваючы сэрвіс у моцна зрэзаны кантэйнер?
Як паказала практыка – у рэальнасці гэта не трэба, deb-пакета хапае ў 90% выпадкаў.
Калі ж стары добры deb не спрацоўвае і калі сапраўды нам быў неабходны докер?
Для нас гэта было разгортваннем сэрвісаў на python. Мноства бібліятэк, патрэбных для машыннага навучання і якія адсутнічаюць у стандартнай пастаўцы аперацыйнай сістэмы (а тое, што там было – не тых версій), хакі з наладамі, неабходнасць розных версій для розных сэрвісаў, якія жывуць на адной і той жа хост-сістэме прывялі да таго , Што адзіным разумным спосабам пастаўкі гэтай ядзернай сумесі аказаўся докер. Працаёмкасць зборкі докер-кантэйнера апынулася ніжэй, чым ідэя спакаваць усё гэта ў асобныя deb-пакеты з залежнасцямі, ды ўласна ніхто ў разумным розуме за гэта б і не ўзяўся.
Другі момант, дзе плануецца выкарыстоўваць докер - для разгортвання сэрвісаў па схеме blue-green deploy. Але тут жадаецца атрымаць паступовае павелічэнне складанасці: спачатку збіраюцца deb-пакеты, а затым ужо з іх збіраецца докер-кантэйнер.
Snap-пакеты
Вернемся да snap-пакетаў. Упершыню яны афіцыйна з'явіліся ў Ubuntu 16.04/XNUMX. У адрозненне ад звыклых deb-пакетаў і rpm-пакетаў, snap нясуць у сабе ўсе залежнасці. З аднаго боку, гэта дазваляе пазбегнуць канфлікту бібліятэк, з іншага боку - гэта значнейшыя памеры выніковага пакета. Акрамя таго, гэта ж можа ўплываць на бяспеку сістэмы: у выпадку пастаўкі snap за ўсімі зменамі ўключаных бібліятэк павінен сачыць сам распрацоўшчык, які стварае пакет. Увогуле не ўсё так адназначна і ўсеагульнае шчасце ад іх выкарыстання не надыходзіць. Але, тым не менш, гэта цалкам сабе разумная альтэрнатыва, калі той жа Docker выкарыстоўваецца толькі як сродак пакавання, а не віртуалізацыі.
Як вынік, у нас зараз у разумным спалучэнні выкарыстоўваюцца як deb-пакеты, так і докер-кантэйнеры, якія, магчыма, у асобных выпадках мы заменім на snap-пакеты.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
А што для пастаўкі карыстаецеся Вы?
-
Самапісныя скрыпты
-
Капіяваны ручкамі на FTP
-
deb-пакеты
-
rpm-пакеты
-
snap-пакеты
-
Docker-images
-
Выявы віртуальных машын
-
Кланаваны HDD цалкам
-
лялечны
-
адказны
-
Іншая
Прагаласавалі 109 карыстальнікаў. Устрымаліся 32 карыстальніка.
Крыніца: habr.com