Некако сам у једном тренутку одлучио да напишем чланак о испоруци у облику Доцкер контејнера и деб пакета, али када сам почео, из неког разлога сам се вратио у далека времена првих персоналних рачунара, па чак и калкулатора. Генерално, уместо сувих поређења доцкер-а и деб-а, добили смо ова размишљања на тему еволуције, које вам износим на разматрање.
Сваки производ, без обзира какав је, мора некако доћи до сервера производа, мора бити конфигурисан и покренут. О томе ће бити речи у овом чланку.
Размишљаћу у историјском контексту, „оно што видим је оно о чему певам“, шта сам видео када сам први пут почео да пишем код и шта сада посматрам, шта ми сами користимо у овом тренутку и зашто. Чланак не претендује да буде пуноправна студија, неке тачке су пропуштене, ово је мој лични поглед на оно што је било и шта је сада.
Дакле, у добра стара времена... најранији начин испоруке који сам пронашао су биле касете са касетофона. Имао сам компјутер БК-0010.01...
Ера калкулатора
Не, постојао је још ранији тренутак, био је и калкулатор и .
Па кад сам имао , тада је начин преноса програма био обичан папир у кутији на којој је исписан програм, који је, по потреби, за ручно покретање, уписан у калкулатор. Ако желите да играте (да, чак и овај претпотопни калкулатор је имао игрице) - седите и унесите програм у калкулатор. Наравно, када је калкулатор искључен, програм је нестао у забораву. Поред кодова калкулатора лично исписаних на папиру, програми су објављивани у часописима „Радио” и „Технологија за младе”, а објављивани су и у књигама тог времена.
Следећа модификација је био калкулатор , већ има неки привид непроменљивог складиштења података. Сада у игру или програм нису морали да се уносе ручно, али након извођења неких магичних пасова помоћу дугмади, сами се учитавају.
Величина највећег програма у калкулатору била је 105 корака, а величина трајне меморије у МК-52 била је 512 корака.
Иначе, ако има љубитеља ових калкулатора који читају овај чланак, у процесу писања чланка нашао сам и емулатор калкулатора за Андроид и програме за њега. Напред у прошлост!
Кратка дигресија о МК-52 (са Википедије)
МК-52 је летео у свемир на летелици Сојуз ТМ-7. Требало је да се користи за израчунавање путање слетања у случају квара на компјутеру.
Од 52. године, МК-1988 са јединицом за проширење меморије Електроника-Астро се испоручује морнаричким бродовима као део навигационог рачунарског комплета.
Први персонални рачунари
Вратимо се у времена . Јасно је да је ту било више меморије, а куцање кода са парчета папира више није било опција (иако сам у почетку радио управо то, јер једноставно није било другог медија). Аудио касете за касетофоне постају главно средство за складиштење и испоруку софтвера.
Складиштење на касети је обично било у облику једне или две бинарне датотеке, све остало је било унутра. Поузданост је била веома ниска, морао сам да задржим 2-3 копије програма. Време учитавања је такође било разочаравајуће, а ентузијасти су експериментисали са различитим фреквентним кодирањем како би превазишли ове недостатке. У то време, ја се још нисам бавио професионалним развојем софтвера (не рачунајући једноставне програме у БАСИЦ-у), па вам, нажалост, нећу детаљно говорити како је све било распоређено унутра. Сама чињеница да је рачунар углавном имао само РАМ меморију одредила је једноставност шеме складиштења података.
Појава поузданих и великих медија за складиштење
Касније су се појавиле дискете, процес копирања је поједностављен, а поузданост повећана.
Али ситуација се драматично мења тек када се појави довољно велика локална складишта у облику ХДД-а.
Тип испоруке се суштински мења: појављују се инсталатерски програми који управљају процесом конфигурисања система, као и чишћењем након уклањања, јер се програми не само читају у меморију, већ се већ копирају у локалну меморију, из које морате да бити у стању да очисти непотребне ствари ако је потребно.
Истовремено се повећава сложеност испорученог софтвера.
Број датотека у испоруци расте са неколико на стотине и хиљаде, сукоби између верзија библиотеке и других радости почињу када различити програми користе исте податке.
У то време, постојање Линукса ми још није било отворено; живео сам у свету МС ДОС-а, а касније и Виндовс-а, и писао у Борланд Пасцал-у и Делпхију, понекад гледајући у Ц++. Многи људи су тада користили ИнсталлСхиелд за испоруку производа. , који је прилично успешно решио све постављене задатке постављања и конфигурисања софтвера.
Интернет ера
Постепено, сложеност софтверских система постаје још сложенија, од монолитних и десктоп апликација долази до преласка на дистрибуиране системе, танке клијенте и микросервисе. Сада морате да конфигуришете не само један програм, већ скуп њих, и тако да сви раде заједно.
Концепт се потпуно променио, дошао је интернет, стигла је ера услуга у облаку. До сада, само у почетној фази, у виду веб страница, нико није посебно сањао о услугама. али је то била прекретница и у развоју и у испоруци апликација.
За себе сам приметио да је у том тренутку дошло до смене генерација програмера (или је то било само у мом окружењу), а постојао је осећај да су сви добри стари начини испоруке у једном тренутку заборављени и да је све почело од самог почетка. почетак: сва испорука је почела да се ради по скриптама и поносно је назвала „Континуирана испорука“. У ствари, почео је период хаоса, када се старо заборавља и не користи, а ново једноставно не постоји.
Сећам се времена када су у нашој компанији у којој сам тада радио (нећу да је именујем), уместо да граде преко мрава (мавен још није био популаран или уопште није постојао), људи једноставно скупљали тегле у ИДЕ-у и спокојно предавали то у СВН. Сходно томе, имплементација се састојала од преузимања датотеке из СВН-а и копирања преко ССХ-а на жељену машину. Тако је једноставно и неспретно.
Истовремено, испорука једноставних сајтова у ПХП-у обављена је на веома примитиван начин једноставним копирањем исправљене датотеке преко ФТП-а на циљну машину. Понекад то није био случај – код се уређивао уживо на серверу производа, а посебно је било шик ако негде постоје резервне копије.
РПМ и ДЕБ пакети
С друге стране, развојем Интернета, системи слични УНИКС-у почели су да добијају све већу популарност, посебно у то време сам открио РедХат Линук 6, отприлике 2000. године. Наравно, тамо су постојала одређена средства за испоруку софтвера, према Википедији, РПМ као главни менаџер пакета појавио се већ 1995. године, у верзији РедХат Линук 2.0. И од тада до данас систем се испоручује у облику РПМ пакета и прилично успешно постоји и развија се.
Дистрибуције Дебиан породице су пратиле сличан пут и имплементирале испоруку у облику деб пакета, која је остала непромењена до данас.
Менаџери пакета вам омогућавају да сами испоручите софтверске производе, конфигуришете их током процеса инсталације, управљате зависностима између различитих пакета, уклоните производе и очистите непотребне ставке током процеса деинсталације. Оне. углавном је то све што је потребно, због чега су трајале неколико деценија практично непромењене.
Рачунарство у облаку је додало инсталацију менаџерима пакета не само са физичких медија, већ и из складишта у облаку, али се суштински мало тога променило.
Вреди напоменути да тренутно постоје неки помаци ка удаљавању од деб-а и преласку на снап пакете, али о томе касније.
Дакле, ова нова генерација цлоуд програмера, која није познавала ни ДЕБ ни РПМ, такође је полако расла, стицала искуство, производи су постајали сложенији, а били су потребни неки разумнији начини испоруке од ФТП-а, басх скрипти и сличних студентских рукотворина.
И ту се појављује Доцкер, нека врста мешавине виртуелизације, разграничења ресурса и метода испоруке. Сада је модерно и младалачки, али да ли је потребно за све? Да ли је ово панацеа?
Из мојих запажања, врло често се Доцкер не предлаже као разуман избор, већ једноставно зато што се, с једне стране, о њему прича у заједници, а они који га предлажу само то знају. С друге стране, о старим добрим системима паковања углавном ћуте – они постоје и раде свој посао тихо и неприметно. У таквој ситуацији заиста нема другог избора – избор је очигледан – Доцкер.
Покушаћу да поделим своје искуство о томе како смо имплементирали Доцкер и шта се десило као резултат.
Самонаписане скрипте
У почетку су постојале басх скрипте које су постављале јар архиве на потребне машине. Овим процесом је руководио Џенкинс. Ово је успешно функционисало, пошто је сама јар архива већ склоп који садржи класе, ресурсе, па чак и конфигурацију. Ако све уложите максимално, онда проширивање у скрипту није најтежа ствар која вам треба
Али скрипте имају неколико недостатака:
- скрипте се обично пишу на брзину и стога су толико примитивне да садрже само један најбољи сценарио. Ово је олакшано чињеницом да је програмер заинтересован за брзу испоруку, а нормална скрипта захтева улагање пристојне количине ресурса
- као последица претходне тачке, скрипте не садрже процедуре за деинсталацију
- нема успостављене процедуре надоградње
- Када се појави нови производ, потребно је да напишете нову скрипту
- нема подршке зависности
Наравно, можете написати софистициран сценарио, али, као што сам горе написао, ово је време за развој, и то не најмање важно, и, као што знамо, увек нема довољно времена.
Све ово очигледно ограничава опсег примене овог начина постављања само на најједноставније системе. Дошло је време да се ово промени.
лучки радник
У неком тренутку, свеже исковане средине су почеле да нам пристижу, вреле идејама и бунцале о докеру. Па, застава у руке - хајде! Била су два покушаја. И једни и други су били неуспешни - рецимо, због великих амбиција, али недостатка правог искуства. Да ли је то било потребно форсирати и завршити на било који начин? Мало је вероватно - тим мора да еволуира до потребног нивоа да би могао да користи одговарајуће алате. Поред тога, када смо користили готове Доцкер слике, често смо наилазили на чињеницу да мрежа није радила исправно (што је можда било због влаге самог Доцкер-а) или је било тешко проширити туђе контејнере.
На какве смо непријатности наишли?
- Проблеми са мрежом у режиму моста
- Незгодно је прегледати евиденције у контејнеру (ако се не чувају засебно у систему датотека хост машине)
- ЕластицСеарцх се повремено чудно замрзне унутар контејнера, разлог није утврђен, контејнер је званичан
- Неопходно је користити шкољку унутар контејнера - све је врло огољено, нема познатих алата
- Велика величина сакупљених контејнера - скупо за складиштење
- Због велике величине контејнера, тешко је подржати више верзија
- Дуже време израде, за разлику од других метода (скрипте или деб пакети)
С друге стране, зашто је горе применити Спринг сервис у облику јар архиве кроз исти деб? Да ли је изолација ресурса заиста неопходна? Да ли је вредно изгубити погодне алате оперативног система тако што ћете услугу ставити у знатно смањени контејнер?
Као што је пракса показала, у стварности то није неопходно, деб пакет је довољан у 90% случајева.
Када стари добри деб пропадне и када нам заиста треба доцкер?
За нас је ово било постављање услуга у Питхон-у. Много библиотека потребних за машинско учење и које нису укључене у стандардну дистрибуцију оперативног система (а шта је било погрешних верзија), хакови са подешавањима, потреба за различитим верзијама за различите услуге које живе на истом хост систему довеле су до тога да ово, да је једини разуман начин за испоруку ове нуклеарне мешавине био докер. Интензитет рада састављања доцкер контејнера показао се мањим од идеје да се све то спакује у засебне деб пакете са зависностима, а заправо нико при здравој памети не би то предузео.
Друга тачка у којој планирамо да користимо Доцкер је да применимо услуге користећи плаво-зелену шему постављања. Али овде желим да добијем постепено повећање сложености: прво се граде деб пакети, а затим се од њих прави доцкер контејнер.
Снап пакети
Вратимо се на снап пакете. Први пут су се званично појавили у Убунту 16.04. За разлику од уобичајених деб пакета и рпм пакета, снап носи све зависности. С једне стране, ово вам омогућава да избегнете конфликте у библиотекама, са друге стране, резултујући пакет је веће величине. Поред тога, ово такође може утицати на безбедност система: у случају брзе испоруке, све промене у укљученим библиотекама мора да надгледа програмер који креира пакет. Генерално, није све тако једноставно и универзална срећа не долази од њиховог коришћења. Али, ипак, ово је сасвим разумна алтернатива ако се исти Доцкер користи само као алат за паковање, а не за виртуелизацију.
Као резултат тога, сада користимо и деб пакете и доцкер контејнере у разумној комбинацији, које ћемо, можда, у неким случајевима заменити снап пакетима.
Само регистровани корисници могу учествовати у анкети. , Добродошао си.
Шта користите за испоруку?
-
Самонаписане скрипте
-
Ручно копирајте на ФТП
-
деб пакети
-
рпм пакети
-
снап пакети
-
Доцкер-слике
-
Слике виртуелне машине
-
Клонирајте цео ХДД
-
марионета
-
ансибле
-
други
Гласало је 109 корисника. 32 корисника су била уздржана.
Извор: ввв.хабр.цом