Jednoho dne jsem se rozhodl napsat článek o dodávce v podobě Docker kontejnerů a deb balíčků, ale když jsem začal, nějak jsem se dostal do dávných časů prvních osobních počítačů a dokonce kalkulaček. Namísto suchých srovnání Dockeru a deb jsem nakonec sepsal úvahy o evoluci, které vám nyní předkládám.
Jakýkoli produkt, ať už je jakýkoli, se musí nějak dostat na produkční servery, musí být nastaven a spuštěn. O tom bude tento článek.
Budu přemýšlet v historickém kontextu, "co vidím — o tom zpívám", co jsem viděl, když jsem teprve začínal psát kód, a co pozoruji nyní, co používáme v současnosti a proč. Článek si neklade za cíl být komplexním výzkumem, některé aspekty jsou opomenuty, je to můj osobní pohled na to, co bylo a co je teď.
Takže, v dávných dobrých časech… nejranější způsob dodání, který jsem zažil — byly magnetofonové kazety. Měl jsem počítač BK-0010.01…
Éra kalkulaček
Ne, byl tu ještě dřívější moment, byl tu ještě kalkulačkový model a .
Takže když jsem měl , byl způsob přenosu programu obyčejný čtverečkovaný list papíru, na kterém byl napsán program, který se při nutnosti spouštěl ručně do kalkulačky. Chceš si zahrát (ano, i na této předpotopní kalkulačce byly hry) — sedneš si a napíšeš program do kalkulačky. Pochopitelně, po vypnutí kalkulačky program zmizel do zapomnění. Kromě vlastnoručně napsaných kódů na papíře byly programy publikovány v časopisech "Rádio" a "Technika mládeže", a také tisknuty v knihách té doby.
Další modifikací byl kalkulačkový model , u něj už měla nějakou podobu bezenergetického ukládání dat. Teď už nebylo nutné hru nebo program zadávat ručně, ale po provedení několika kouzelných tahů tlačítky se nahrál sám.
Objem největšího programu v kalkulačce byl 105 kroků, zatímco velikost trvalé paměti v MK-52 byla 512 kroků.
Mimochodem, pokud jsou mezi čtenáři této články fanoušci těchto kalkulaček — při psaní článku jsem našel emulátor kalkulačky pro Android a programy pro něj. Vpřed, do minulosti!
Krátké odbočení k MK-52 (z wikipedie)
MK-52 létal do vesmíru na lodi „Soyuz TM-7“. Měl být použit pro výpočet trajektorie přistání v případě, že by selhal palubní počítač.
Od roku 1988 byl MK-52 s rozšiřujícím paměťovým blokem „Elektronika-Astro“ dodáván na lodi VMF v rámci navigačního výpočetního komplexu.
První osobní počítače
Vraťme se do doby . Je jasné, že paměti tam bylo více a zadávání kódu z papíru už bylo zcela nepřijatelné (i když první dobu jsem to přesně tak dělal, protože jiný nosič prostě nebyl). Hlavním médiem pro ukládání a distribuci softwaru se staly audiokazety pro magnetofony.
Ukládání na kazetě obvykle probíhalo jako jeden nebo dva binární soubory, vše ostatní bylo uvnitř. Spolehlivost byla velmi nízká, bylo nutné mít 2-3 kopie programu. Čas načítání také nebyl povzbudivý, nadšenci experimentovali s různými frekvenčními kódováními, aby překonali tyto nedostatky. Sám jsem se tehdy ještě profesionální vývoji softwaru nevěnoval (pokud nepočítám jednoduché programy v Basicu), takže podrobnosti o tom, jak to všechno uvnitř fungovalo, bohužel neřeknu. Samotný fakt, že na počítači byla pouze RAM, většinou určoval jednoduchost schématu ukládání dat.
Objevení spolehlivých a velkých nosičů informací
Později se objevují disketové jednotky, proces kopírování se usnadňuje, zvyšuje se spolehlivost.
Ale situace se zásadně mění až s příchodem dostatečně velkých lokálních úložišť ve formě HDD.
Zásadně se mění typ dodávky: objevují se instalační programy, které řídí proces konfigurace systému a také jeho čištění po odstranění, protože programy se nečtou pouze do paměti, ale již se kopírují do lokálního úložiště, ze kterého je třeba umět v případě potřeby odstraňovat nepotřebné.
Současně se zvyšuje složitost dodávaného softwaru.
Počet souborů v dodávce vzrůstá z jednotek na stovky a tisíce, začínají konflikty verzí knihoven a další radosti, kdy různé programy používají stejná data.
V té době jsem ještě nevěděl o existenci Linuxu, žil jsem ve světě MS DOS a později Windows, a programoval jsem v Borland Pascal a Delphi, občas jsem pokukoval po C++. Pro dodávání produktů mnozí tehdy používali InstallShield. , který úspěšně řešil všechny úkoly spojené s nasazením a konfigurací softwaru.
Období internetu
Postupně se složitost softwarových systémů ještě zvýšila, z monolitických a desktopových aplikací došlo k přechodu na distribuované systémy, tenké klienty a mikroslužby. Nyní je třeba konfigurovat již ne jednu aplikaci, ale jejich soubor, a to tak, aby spolu dobře fungovaly.
Kompletně se změnila koncepce, přišel internet, nastala éra cloudových služeb. Ačkoliv to bylo stále na počátku, ve formě webových stránek, nikdo o službách příliš nepřemýšlel. Ale to byl zlomový okamžik v průmyslu jak vývoje, tak dodávání aplikací.
Všiml jsem si, že v tu chvíli došlo ke změně generací vývojářů (nebo to bylo jen v mém okolí), a vytvořil se pocit, že všechny staré dobré způsoby dodávání byly z jednoho okamžiku zapomenuty a všechno začalo znovu: celá dodávka se začala provádět pomocí nasazovacích skriptů a nazvali to hrdě „Continuous delivery“. V podstatě začalo jakési období chaosu, kdy staré bylo zapomenuto a nové jednoduše neexistovalo.
Pamatuji si na časy, kdy v naší společnosti, kde jsem tehdy pracoval (nebudu ji jmenovat), místo toho, aby se sestavení provádělo přes ant (maven tehdy ještě nebyl populární nebo vůbec nebyl), lidé jednoduše vytvářeli jar v IDE a klidně ho committovali do SVN. Odpovídajícím způsobem se nasazení skládalo z vytahování souboru ze SVN a jeho kopírování přes SSH na potřebný stroj. Tak jednoduché a primitivní.
Ve stejnou dobu dodávka jednoduchých webů na PHP probíhala naprosto primitivně: prostým kopírováním opraveného souboru přes FTP na cílový stroj. Někdy nebylo ani to — kód se upravoval přímo na produkčním serveru a bylo velkým luxusem mít někde zálohy.
RPM a DEB balíčky
Na druhou stranu, s rozvojem internetu získaly stále větší popularitu systémy podobné UNIXu, konkrétně jsem v té době objevil RedHat Linux 6, zhruba kolem roku 2000. Samozřejmě, že i tam byly určité prostředky pro dodávání softwaru; podle Wikipedie se hlavní správce balíčků RPM objevil v roce 1995 při vydání 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 vyvíjí se.
Distribuce rodiny Debian šly podobnou cestou a realizovaly dodávání ve formě deb balíčků, což je také neměnné až do dnešních dnů.
Správci balíčků umožňují dodávat samotné programové produkty, konfigurovat je během instalace, spravovat závislosti mezi různými balíčky, provádět odstraňování produktů a úklid nepotřebného při deinstalaci. Tedy v podstatě to je všechno, co potřebujete; proto přetrvaly několik desetiletí prakticky beze změn.
Cloud přidal k správcům balíčků instalaci nejen z fyzických nosičů, ale i z cloudových repozitářů, ale principálně se toho moc nezměnilo.
Je třeba poznamenat, že v současné době existují určité snahy o odklon od deb balíčků a přechod na snap balíčky, ale o tom později.
Takže to nové pokolení cloudových vývojářů, které neznalo ani DEB, ani RPM, také pomalu rostlo, získávalo zkušenosti, produkty se komplikovaly a byly potřeba rozumnější způsoby dodávání než FTP, bash skripty a podobné studentské výtvory.
A zde vstupuje na scénu Docker, jakási směs virtualizace, rozdělování zdrojů a způsobu dodávání. Dnes je to trendy, mladistvé, ale je skutečně potřeba pro všechno? Je to lék na všechno?
Podle mých pozorování je velmi často Docker nabízen ne jako rozumná volba, ale jednoduše proto, že o něm, z jedné strany, hovoří v komunitě a ti, kdo jej nabízejí, ho znají jako jediného. Na druhou stranu se o starých dobrých systémech balení většinou mlčí — existují a dělají svou práci tiše a nenápadně. V takové situaci vlastně není na výběr — volba je jasná — Docker.
Pokusím se podělit o zkušenosti, jak u nás probíhalo zavádění Dockeru a co z toho nakonec vzešlo.
Vlastní skripty
Na začátku byly bash skripty, které nasazovaly jar archivy na potřebné stroje. Tento proces řídil Jenkins. To úspěšně fungovalo, protože jar archiv je sám o sobě balíčkem, který obsahuje třídy, zdroje a dokonce i konfiguraci. Pokud do něj naskládáte vše maximálně, rozbalení skriptem není to nejtěžší, co je třeba udělat.
Ale skripty mají několik nevýhod:
- Skripty se obvykle píší na poslední chvíli a jsou tak primitivní, že obsahují pouze jeden nejvýhodnější scénář. K tomu přispívá to, že vývojář touží po rychlé dodávce, zatímco normální skript vyžaduje značné množství zdrojů.
- Jako důsledek předchozího bodu skripty neobsahují proceduru odinstalace.
- Neexistuje stanovená procedura pro upgrade.
- Při příchodu nového produktu je třeba napsat nový skript.
- Není zde podpora závislostí.
Samozřejmě, lze napsat sofistikovaný skript, ale, jak jsem již zmínil, to vyžaduje čas na vývoj, a jak je známo, času je vždy nedostatek.
To samozřejmě významně omezuje použití tohoto způsobu nasazení pouze na nejjednodušší systémy. Nastal čas to změnit.
Docker
V určitém okamžiku k nám začali přicházet noví středně pokročilí vývojáři plní nápadů a nadšení pro Docker. No, bandera v ruce – jdeme na to! Byly dvě pokusy. Oba neúspěšné – řekněme kvůli velkým ambicím, ale nedostatku skutečných zkušeností. Mělo se to urychlovat a dodělávat za každou cenu? O pochybnost – tým by měl evolučně dospět na potřebnou úroveň, než bude schopen používat odpovídající nástroje. Kromě toho, při používání hotových Docker image jsme často narazili na to, že tam špatně fungovala síť (což možná souviselo i s nevyzrálostí samotného Dockera) nebo bylo obtížné rozšířit cizí kontejnery.
Jaké potíže jsme zažili?
- Problémy se sítí v režimu bridge.
- Není pohodlné sledovat logy v kontejneru (pokud nejsou nikam jinam vyvedeny do souborového systému hostitelského stroje).
- Příležitostně docházelo k podivnému zamrznutí ElasticSearch uvnitř kontejneru, příčinu jsme tak nikdy neustavili, kontejner byl oficiální.
- Není pohodlné používat shell uvnitř kontejneru – vše je silně omezené, chybí obvyklé nástroje.
- Velikost shromažďovaných kontejnerů je vysoká — je nákladné je skladovat.
- Kvůli velkým rozměrům kontejnerů je obtížné udržovat vícero verzí.
- Dlouhodobější sestavení, na rozdíl od jiných metod (skripty nebo deb balíčky).
Na druhou stranu, proč by měl být Spring servis ve formě jar archivu horší na nasazení než stejný deb? Opravu potřebujeme izolaci zdrojů? Má smysl se zbavovat praktických nástrojů operačního systému, když prosazujeme službu do výrazně omezeného kontejneru?
Jak ukazuje praxe — ve skutečnosti to není potřeba, deb balíčku stačí v 90 % případů.
Kdy však starý dobrý deb nefunguje a kdy jsme opravdu potřebovali Docker?
Pro nás to bylo nasazení služeb v Pythonu. Mnoho knihoven potřebných pro strojové učení, které chyběly ve standardním dodávce operačního systému (a to, co tam bylo — v nesprávných verzích), hacky s nastavením, potřeba různých verzí pro různé služby, které běží na stejné hostitelské systému vedly k tomu, že jediným rozumným způsobem dodání této směsi se stal Docker. Pracnost sestavení Docker kontejneru se ukázala jako nižší než myšlenka zabalit to všechno do samostatných deb balíčků se závislostmi, vlastně by se nikdo při zdravém rozumu o to ani nepokusil.
Druhý aspekt, kde se plánuje použití Dockeru — pro nasazení služeb podle schématu blue-green deploy. Ale zde si přeji postupné zvyšování složitosti: nejprve se sestaví deb balíčky a teprve poté z nich vznikne Docker kontejner.
Snap balíčky
Vraťme se k snap balíčkům. Poprvé se oficiálně objevily v Ubuntu 16.04. Na rozdíl od běžných deb balíčků a rpm balíčků nesou snap všechny závislosti. Na jedné straně to umožňuje vyhnout se konfliktu knihoven, na straně druhé — to znamená větší velikosti výsledného balíčku. Kromě toho to může mít vliv na bezpečnost systému: při dodávání snap musí vývojář, který balíček vytváří, sledovat všechny změny zahrnutých knihoven. Celkově to není tak jednoznačné a obecné štěstí z jejich používání nenastává. Nicméně, je to rozumná alternativa, pokud je Docker používán pouze jako prostředek balení, nikoli virtualizace.
Výsledkem je, že nyní rozumně používáme jak deb balíčky, tak docker kontejnery, které v některých případech možná nahradíme snap balíčky.
Pouze registrovaní uživatelé se mohou účastnit ankety. , prosím.
Co používáte pro dodávku?
Vlastní skripty
Kopírujeme ručně pomocí FTP.
deb balíčky
rpm balíčky
snap balíčky
Docker obrazy
Obrázky virtuálních strojů
Klonujeme HDD kompletně.
puppet
ansible
Jiné
Hlasovalo 109 uživatelů. 32 uživatelů se zdrželo.
Zdroj: habr.com
