Nějak jsem se v jednu chvíli rozhodl napsat článek o doručování ve formě docker kontejnerů a deb balíčků, ale když jsem začal, z nějakého důvodu jsem byl přenesen do dalekých časů prvních osobních počítačů a dokonce i kalkulaček. Obecně místo suchých srovnání dockeru a deb jde o úvahy na téma evoluce, které předkládám k vašemu soudu.
Jakýkoli produkt, ať už je jakýkoli, se musí nějakým způsobem dostat na produktové servery, musí být nakonfigurován a spuštěn. O tom bude tento článek.
Budu přemýšlet v historickém kontextu „to, co vidím, o tom zpívám“, co jsem viděl, když jsem právě začal psát kód, a co pozoruji nyní, co my sami v tuto chvíli používáme a proč. Článek si nečiní nárok na plnohodnotnou studii, některé body chybí, toto je můj osobní pohled na to, co bylo a co je nyní.
Takže za starých dobrých časů... první způsob doručení, který jsem našel, byly kazety z magnetofonu. Měl jsem počítač BK-0010.01 ...
Éra kalkulaček
Ne, byl ještě dřívější okamžik, byla tam i kalkulačka и .
Takže tehdy jsem měl , pak byl způsob přenosu programu obyčejný papír v krabici, na kterém byl napsán program, který se v případě potřeby pro ruční spuštění zaznamenal v kalkulačce. Pokud si chcete zahrát (ano, i na této předpotopní kalkulačce byly hry), posadíte se a zadáte program do kalkulačky. Přirozeně, když byla kalkulačka vypnuta, program upadl v zapomnění. Kromě papírových kódů kalkulačky vycházely pořady v časopisech Rádio a Technika mládeže a byly tištěny i v tehdejších knihách.
Další úpravou byla kalkulačka , už má nějaké energeticky nezávislé úložiště dat. Nyní se hra nebo program nemusely zadávat ručně, ale po několika magických průchodech tlačítky se načetly samy.
Objem největšího programu v kalkulačce byl 105 kroků a velikost trvalé paměti v MK-52 byla 512 kroků.
Mimochodem, pokud existují fanoušci těchto kalkulaček, kteří čtou tento článek, v procesu psaní článku jsem našel jak emulátor kalkulačky pro Android, tak programy pro něj. Vpřed do minulosti!
Malá odbočka k MK-52 (z wikipedie)
MK-52 letěl do vesmíru na kosmické lodi Sojuz TM-7. Měl sloužit k výpočtu přistávací dráhy v případě, že selže palubní počítač.
Od roku 52 se MK-1988 s paměťovou rozšiřující jednotkou Elektronika-Astro dodával na lodě námořnictva jako součást navigačního počítače.
První osobní počítače
Vraťme se do časů . Je jasné, že tam bylo více paměti a už nebylo možné zadat kód z kusu papíru (i když jsem to zpočátku dělal, protože jiné médium prostě nebylo). Audiokazety pro magnetofony se stávají hlavním prostředkem pro ukládání a dodávání softwaru.
Úložiště na kazetě bylo obvykle ve formě jednoho nebo dvou binárních souborů, vše ostatní bylo obsaženo uvnitř. Spolehlivost byla velmi nízká, musel jsem si nechat 2-3 kopie programu. Doba načítání také nebyla povzbudivá, nadšenci experimentovali s různým frekvenčním kódováním, aby tyto nedostatky překonali. Sám jsem se v té době ještě nezabýval profesionálním vývojem softwaru (nepočítám jednoduché programy BASIC), takže vám bohužel podrobně neřeknu, jak bylo uvnitř vše uspořádáno. Samotný fakt, že počítač měl z větší části pouze RAM, určoval jednoduchost schématu ukládání dat.
Vznik spolehlivých a velkých paměťových médií
Později se objevují diskety, zjednodušuje se proces kopírování a roste spolehlivost.
Situace se ale dramaticky změní, až když se objeví dostatečně velká lokální úložiště v podobě HDD.
Zásadně se mění typ doručení: objevují se instalační programy, které řídí proces konfigurace systému a také čištění po odstranění, protože programy nejsou pouze načteny do paměti, ale jsou již zkopírovány do místního úložiště, ze kterého je třeba být schopen v případě potřeby vyčistit zbytečné.
Souběžně s tím se zvyšuje složitost dodávaného softwaru.
Počet souborů v distribuci se zvyšuje z několika na stovky a tisíce, konflikty verzí knihoven a další radosti začínají, když různé programy používají stejná data.
V té době pro mě ještě nebyla objevena existence Linuxu, žil jsem ve světě MS DOS a později Windows, psal jsem v Borland Pascalu a Delphi, občas jsem pokukoval po C++. V té době mnozí používali InstallShield k doručování produktů. , který celkem úspěšně vyřešil všechny úkoly nasazení a konfigurace softwaru.
Internetová éra
Postupně se komplexnost softwarových systémů ještě více komplikuje, od monolitu a desktopových aplikací se přechází k distribuovaným systémům, tenkým klientům a mikroslužbám. Nyní musíte nakonfigurovat ne jeden program, ale jejich sadu, aby byli všichni přátelé.
Zcela se změnil koncept, přišel internet, přišla éra cloudových služeb. Zatím, pouze v počáteční fázi, ve formě stránek, nikdo nesnil o speciálních službách. ale byl to zlomový bod jak ve vývoji, tak ve vývoji aplikací.
Za sebe jsem poznamenal, že v tu chvíli došlo ke změně generací vývojářů (nebo to bylo jen v mém prostředí) a byl pocit, že všechny staré dobré způsoby doručování byly v jednu chvíli zapomenuty a vše začalo od úplný začátek: začali dělat všechny scénáře pro doručovací kolena a hrdě to nazvali „Nepřetržité doručování“. Začalo vlastně nějaké období chaosu, kdy se na staré zapomnělo a nepoužívalo se, ale nové prostě nebylo.
Pamatuji si časy, kdy se u nás ve firmě, kde jsem tehdy pracoval (nebudu jmenovat), místo stavby přes mravence (maven tehdy nebyl populární nebo vůbec neexistoval), lidé jen stavěli jar v IDE a tiše to spáchal v SVN. Nasazení tedy spočívalo v získání souboru ze SVN a jeho zkopírování přes SSH na požadovaný počítač. Je to tak jednoduché a neohrabané.
Doručování jednoduchých stránek v PHP přitom probíhalo dost primitivně pouhým zkopírováním opraveného souboru přes FTP na cílový stroj. Někdy nic takového neexistovalo - kód byl opraven živě na produktovém serveru a bylo zvláštní, pokud byly někde zálohy.
RPM a DEB balíčky
Na druhou stranu s rozvojem internetu si UNIXové systémy začaly získávat stále větší oblibu, konkrétně v té době jsem pro sebe objevil RedHat Linux 6, kolem roku 2000. Samozřejmě existovaly i určité prostředky pro dodávání softwaru, podle Wikipedie se RPM jako hlavní správce balíčků objevil již v roce 1995 ve verzi RedHat Linux 2.0. A od té doby až do současnosti je systém dodáván ve formě RPM balíčků a úspěšně existuje a rozvíjí se.
Distribuce rodiny Debian se vydaly podobnou cestou a implementovaly distribuci ve formě deb balíčků, což je také dodnes nezměněné.
Správci balíčků vám umožňují dodávat samotné softwarové produkty, konfigurovat je během procesu instalace, spravovat závislosti mezi různými balíčky, odstraňovat produkty a čistit přebytky během procesu odinstalace. Tito. z velké části je to vše, co je potřeba, a proto vydržely několik desetiletí s malými nebo žádnými změnami.
Cloudiness sice přidal instalaci správcům balíčků nejen z fyzických médií, ale i z cloudových úložišť, ale zásadně málo se změnilo.
Stojí za zmínku, že v současné době dochází k určitému posunu od deb směrem k snap balíčkům, ale o tom později.
Takže tato nová generace cloudových vývojářů, kteří neznali DEB ani RPM, také pomalu rostla, získávala zkušenosti, produkty se komplikovaly a bylo potřeba nějakých rozumnějších způsobů doručení než FTP, bash skripty a podobná studentská řemesla.
A zde vstupuje do hry Docker, směs virtualizace, alokace zdrojů a způsobu doručení. Nyní je módní, mladistvý, ale je potřeba ke všemu? Je to všelék?
Podle mých pozorování je Docker velmi často nabízen ne jako rozumná volba, ale prostě proto, že se o něm jednak v komunitě mluví a ti, co nabízejí, to jen vědí. Na druhou stranu o starých dobrých balicích systémech většinou mlčí – jsou a jsou, svou práci dělají tiše a neznatelně. V takové situaci opravdu není jiná volba - volba je nasnadě - Docker.
Pokusím se podělit o své zkušenosti, jak jsme implementovali Docker a co se ve výsledku stalo.
Samostatně psané skripty
Zpočátku existovaly bash skripty, které nasazovaly jar archivy na požadované stroje. Řídil tento Jenkinsův proces. To fungovalo úspěšně, protože samotný jar archiv je již sestavení obsahující třídy, prostředky a dokonce i konfiguraci. Pokud do toho dáte všechno na maximum, tak rozložit to pomocí skriptu není to nejtěžší, co potřebujete
Ale skripty mají několik nevýhod:
- skripty jsou obvykle psány ve spěchu a jsou proto tak primitivní, že obsahují pouze jeden nejúspěšnější skript. To je usnadněno skutečností, že vývojář má zájem o co nejrychlejší doručení a běžný skript vyžaduje investování slušného množství prostředků.
- v důsledku předchozího odstavce skripty neobsahují proceduru odinstalace
- neexistuje žádný zavedený postup upgradu
- když se objeví nový produkt, musíte napsat nový skript
- žádná podpora závislosti
Samozřejmě můžete napsat efektní scénář, ale jak jsem psal výše, toto je vývojový čas, a ne nejmenší, a jak víte, času není vždy dost.
To vše samozřejmě omezuje rozsah této metody nasazení pouze na nejjednodušší systémy. Nastal čas to změnit.
přístavní dělník
V určitém okamžiku k nám začaly přicházet čerstvě upečené středy, kypějící nápady a blouznění o dockeru. No, vlajka v ruce - pojďme na to! Byly dva pokusy. Oba neuspěli – řekněme kvůli velkým ambicím, ale nedostatku reálných zkušeností. Bylo nutné se nějak donutit a zakončit? Nepravděpodobné – tým se musí vyvinout na správnou úroveň, než bude moci používat vhodné nástroje. Navíc jsme se při použití hotových obrázků dockeru často setkávali s tím, že tam nefungovala správně síť (což bylo možná i kvůli vlhkosti samotného dockeru) nebo bylo obtížné rozšiřovat cizí kontejnery.
Jaké nepříjemnosti jsme čelili?
- Problémy se sítí v režimu mostu
- Je nepohodlné dívat se na protokoly v kontejneru (pokud nejsou umístěny nikde samostatně v systému souborů hostitelského počítače)
- Pravidelně podivné zavěšení ElasticSearch uvnitř kontejneru, důvod nebyl stanoven, kontejner je oficiální
- Je zdlouhavé používat skořápku uvnitř kontejneru - vše je značně omezeno, neexistují žádné známé nástroje
- Velké sběrné nádoby - drahé na skladování
- Vzhledem k velké velikosti kontejnerů je obtížné podporovat více verzí
- Delší sestavení než u jiných metod (skripty nebo deb balíčky)
Na druhou stranu, proč je horší nasadit službu Spring ve formě jar archivu přes stejný deb? Je izolace zdrojů skutečně nutná? Vyplatí se ztratit pohodlné nástroje operačního systému tím, že nacpete službu do silně zkráceného kontejneru?
Jak ukázala praxe, ve skutečnosti to není nutné, v 90% případů stačí deb balíček.
Kdy selhal starý dobrý deb a kdy jsme opravdu potřebovali docker?
Pro nás to bylo nasazení pythonových služeb. Spousta knihoven potřebných pro strojové učení a nezahrnutých ve standardní distribuci operačního systému (a co tam bylo, nebyly ty verze), hacky s nastavením, potřeba různých verzí pro různé služby žijící na stejném hostitelském systému vedly k že jediný rozumný způsob, jak tuto jadernou směs dodat, se ukázal být doker. Složitost sestavení docker kontejneru se ukázala být nižší než myšlenka zabalit to vše do samostatných deb balíčků se závislostmi, a ve skutečnosti by to nikdo se zdravým rozumem nepodstoupil.
Druhým bodem, kde se plánuje použití dockeru, je nasazení služeb podle schématu modro-zeleného nasazení. Ale tady chci dosáhnout postupného nárůstu složitosti: nejprve se sestaví deb balíčky a pak se z nich sestaví docker kontejner.
Snap balíčky
Vraťme se ke snapovým balíčkům. Poprvé se oficiálně objevily v Ubuntu 16.04. Na rozdíl od obvyklých deb balíčků a rpm balíčků, snapy nesou všechny závislosti. Na jednu stranu se tím zabrání konfliktům knihoven, na druhou stranu to znamená větší velikosti výsledného balíčku. Navíc to může ovlivnit i bezpečnost systému: v případě bleskového doručení musí všechny změny v zahrnutých knihovnách sledovat vývojář, který balíček vytváří. Obecně není vše tak jednoduché a obecné štěstí nepochází z jejich používání. Nicméně je to docela rozumná alternativa, pokud se stejný Docker používá pouze jako prostředek balení, a ne virtualizace.
V důsledku toho nyní používáme jak deb balíčky, tak docker kontejnery v rozumné kombinaci, kterou možná v některých případech nahradíme snap balíčky.
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
Co používáte pro doručení?
-
Samostatně psané skripty
-
Kopírování pomocí úchytů na FTP
-
deb balíčky
-
rpm balíčky
-
snap balíčky
-
docker-images
-
obrázky VM
-
Klonování celého HDD
-
loutka
-
ansible
-
Další
Hlasovalo 109 uživatelů. 32 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com