Nejako som sa v istom momente rozhodol napísať článok o doručovaní vo forme kontajnerov Docker a deb balíčkov, ale keď som začal, z nejakého dôvodu som bol prenesený späť do vzdialených čias prvých osobných počítačov a dokonca aj kalkulačiek. Vo všeobecnosti sme namiesto suchých porovnaní dockera a deb dostali tieto myšlienky na tému evolúcie, ktoré vám predkladám na zváženie.
Akýkoľvek produkt, bez ohľadu na to, aký je, sa musí nejakým spôsobom dostať na produktové servery, musí byť nakonfigurovaný a spustený. O tom bude tento článok.
Budem premýšľať v historickom kontexte, „to, čo vidím, je to, o čom spievam“, čo som videl, keď som prvýkrát začal písať kód a čo pozorujem teraz, čo my sami momentálne používame a prečo. Článok sa netvári ako plnohodnotná štúdia, niektoré body chýbajú, toto je môj osobný pohľad na to, čo bolo a čo je teraz.
Takže za starých dobrých čias... najskorší spôsob doručenia, ktorý som našiel, boli kazety z magnetofónov. Mal som počítač BK-0010.01...
Éra kalkulačiek
Nie, bol ešte skorší moment, bola tam aj kalkulačka и .
Takže keď som mal , potom bol spôsob prenosu programu obyčajný papier v krabici, na ktorej bol napísaný program, ktorý sa v prípade potreby na manuálne spustenie zapísal do kalkulačky. Ak si chcete zahrať (áno, aj táto predpotopná kalkulačka mala hry) - sadnete si a zadáte program do kalkulačky. Prirodzene, keď bola kalkulačka vypnutá, program zmizol do zabudnutia. Okrem kódov kalkulačiek napísaných osobne na papieri boli programy publikované v časopisoch „Rádio“ a „Technológia pre mládež“ a boli publikované aj v knihách tej doby.
Ďalšou úpravou bola kalkulačka , už má nejaké zdanie energeticky nezávislého úložiska dát. Teraz hru alebo program nebolo potrebné zadávať ručne, ale po vykonaní niektorých magických pohybov tlačidlami sa načítal sám.
Veľkosť najväčšieho programu v kalkulačke bola 105 krokov a veľkosť trvalej pamäte v MK-52 bola 512 krokov.
Mimochodom, ak existujú fanúšikovia týchto kalkulačiek, ktorí čítajú tento článok, v procese písania článku som našiel emulátor kalkulačky pre Android a programy preň. Vpred do minulosti!
Krátka odbočka o MK-52 (z Wikipédie)
MK-52 letel do vesmíru na kozmickej lodi Sojuz TM-7. Ten mal slúžiť na výpočet pristávacej dráhy v prípade zlyhania palubného počítača.
Od roku 52 sa MK-1988 s pamäťovou rozširujúcou jednotkou Elektronika-Astro dodáva námorným lodiam ako súčasť navigačnej výpočtovej súpravy.
Prvé osobné počítače
Vráťme sa do čias . Je jasné, že tam bolo viac pamäte a písanie kódu z kúska papiera už neprichádzalo do úvahy (hoci som to najprv robil, pretože iné médium jednoducho nebolo). Audiokazety pre magnetofóny sa stávajú hlavným prostriedkom na ukladanie a dodávanie softvéru.
Úložisko na kazete bolo zvyčajne vo forme jedného alebo dvoch binárnych súborov, všetko ostatné bolo obsiahnuté vo vnútri. Spoľahlivosť bola veľmi nízka, musel som si nechať 2-3 kópie programu. Časy načítania boli tiež sklamaním a nadšenci experimentovali s rôznymi frekvenčnými kódovaniami, aby prekonali tieto nedostatky. Sám som sa v tom čase ešte nevenoval profesionálnemu vývoju softvéru (nepočítajúc jednoduché programy v BASICu), takže vám, žiaľ, nepoviem do detailov, ako to bolo vo vnútri všetko usporiadané. Samotný fakt, že počítač mal z väčšej časti len RAM, určoval jednoduchosť schémy ukladania dát.
Vznik spoľahlivých a veľkých pamäťových médií
Neskôr sa objavili diskety, zjednodušil sa proces kopírovania a zvýšila sa spoľahlivosť.
Situácia sa však dramaticky zmení až vtedy, keď sa objavia dostatočne veľké lokálne úložiská v podobe HDD.
Typ dodávky sa zásadne mení: objavujú sa inštalačné programy, ktoré riadia proces konfigurácie systému, ako aj čistenie po odstránení, pretože programy sa nielen načítajú do pamäte, ale už sa skopírujú do lokálneho úložiska, z ktorého je potrebné vedieť v prípade potreby vyčistiť nepotrebné veci.
Zároveň sa zvyšuje komplexnosť dodávaného softvéru.
Počet súborov v dodávke sa zvyšuje z niekoľkých na stovky a tisíce, konflikty medzi verziami knižníc a iné radosti začínajú, keď rôzne programy používajú rovnaké dáta.
V tom čase mi ešte existencia Linuxu nebola otvorená, žil som vo svete MS DOS a neskôr Windows, písal som v Borland Pascal a Delphi, občas som sa obzeral po C++. Mnoho ľudí vtedy používalo InstallShield na dodávanie produktov. , ktorý celkom úspešne vyriešil všetky zadané úlohy nasadenia a konfigurácie softvéru.
Internetová éra
Postupne sa zložitosť softvérových systémov stáva ešte zložitejšou, od monolitných a desktopových aplikácií sa prechádza k distribuovaným systémom, tenkým klientom a mikroslužbám. Teraz musíte nakonfigurovať nielen jeden program, ale ich sadu, aby všetky fungovali spolu.
Úplne sa zmenil koncept, prišiel internet, prišla éra cloudových služieb. Zatiaľ len v počiatočnom štádiu, v podobe webových stránok, nikto o službách špeciálne nesníval. ale bol to zlomový bod vo vývoji aj dodávaní aplikácií.
Za seba som si všimol, že v tom momente došlo k zmene generácií vývojárov (alebo to bolo len v mojom prostredí) a bol tu pocit, že všetky staré dobré spôsoby doručovania boli v jednom momente zabudnuté a všetko začalo od samého začiatku. začiatok: všetky dodávky sa začali vykonávať kolennými skriptami a hrdo to nazvali „Nepretržité doručovanie“. V skutočnosti sa začalo obdobie chaosu, kedy sa na staré zabúda a nepoužíva sa a nové jednoducho neexistuje.
Pamätám si časy, keď v našej spoločnosti, kde som vtedy pracoval (nebudem menovať), ľudia namiesto stavania cez mravca (maven ešte nebol populárny alebo vôbec neexistoval) ľudia jednoducho zbierali poháre v IDE a pokojne sa zaviazali to v SVN. Nasadenie teda pozostávalo z načítania súboru zo SVN a jeho skopírovania cez SSH na požadovaný počítač. Je to také jednoduché a nemotorné.
Zároveň doručovanie jednoduchých stránok v PHP prebiehalo veľmi primitívnym spôsobom jednoduchým skopírovaním opraveného súboru cez FTP na cieľový stroj. Niekedy to tak nebolo - kód bol upravovaný naživo na produktovom serveri a bolo obzvlášť elegantné, ak niekde existovali zálohy.
RPM a DEB balíky
Na druhej strane, s rozvojom internetu si systémy podobné UNIXu začali získavať čoraz väčšiu obľubu, konkrétne v tom čase som objavil RedHat Linux 6, približne v roku 2000. Samozrejme, existovali aj určité prostriedky na dodávanie softvéru, podľa Wikipédie sa RPM ako hlavný správca balíkov objavil už v roku 1995, vo verzii RedHat Linux 2.0. A odvtedy a dodnes je systém dodávaný vo forme RPM balíčkov a celkom úspešne existuje a rozvíja sa.
Distribúcie rodiny Debian sa vydali podobnou cestou a implementovali doručovanie vo forme deb balíčkov, ktoré zostalo nezmenené dodnes.
Správcovia balíkov vám umožňujú dodávať samotné softvérové produkty, konfigurovať ich počas procesu inštalácie, spravovať závislosti medzi rôznymi balíkmi, odstraňovať produkty a čistiť nepotrebné položky počas procesu odinštalovania. Tie. poväčšine je to všetko, čo je potrebné, a preto vydržali niekoľko desaťročí prakticky nezmenené.
Cloud computing pridal správcom balíkov inštaláciu nielen z fyzických médií, ale aj z cloudových úložísk, no zásadne sa toho zmenilo len málo.
Stojí za zmienku, že v súčasnosti existujú určité kroky smerom k odklonu od deb a prechodu na snap balíčky, ale o tom neskôr.
Takže táto nová generácia cloudových vývojárov, ktorí nepoznali ani DEB, ani RPM, tiež pomaly rástla, získavala skúsenosti, produkty sa stávali zložitejšími a boli potrebné nejaké rozumnejšie spôsoby doručenia ako FTP, bash skripty a podobné študentské remeslá.
A tu prichádza na scénu Docker, akási zmes virtualizácie, delimitácie zdrojov a spôsobu doručenia. Teraz je to módne a mladistvé, ale je to potrebné na všetko? Je to všeliek?
Z mojich pozorovaní sa Docker veľmi často navrhuje nie ako rozumná voľba, ale jednoducho preto, že na jednej strane sa o ňom v komunite hovorí a tí, ktorí ho navrhujú, to len vedia. Na druhej strane o starých dobrých obalových systémoch väčšinou mlčia – existujú a svoju prácu vykonávajú potichu a nepozorovane. V takejto situácii naozaj nie je iná možnosť - voľba je zrejmá - Docker.
Pokúsim sa podeliť o svoje skúsenosti s tým, ako sme implementovali Docker a čo sa stalo ako výsledok.
Vlastnoručne písané skriptá
Spočiatku existovali bash skripty, ktoré nasadili archívy jar do požadovaných počítačov. Tento proces riadil Jenkins. Toto fungovalo úspešne, pretože samotný jar archív je už zostava obsahujúca triedy, zdroje a dokonca aj konfiguráciu. Ak do toho dáte všetko na maximum, tak rozšírenie do skriptu nie je to najťažšie, čo potrebujete
Ale skripty majú niekoľko nevýhod:
- skripty sa zvyčajne píšu narýchlo, a preto sú také primitívne, že obsahujú iba jeden najlepší scenár. To je uľahčené skutočnosťou, že vývojár má záujem o rýchle dodanie a normálny skript vyžaduje investíciu slušného množstva zdrojov
- v dôsledku predchádzajúceho bodu skripty neobsahujú procedúry odinštalovania
- žiadny stanovený postup aktualizácie
- Keď sa objaví nový produkt, musíte napísať nový skript
- žiadna podpora závislosti
Samozrejme, môžete napísať sofistikovaný scenár, ale ako som už napísal vyššie, toto je čas na vývoj a v neposlednom rade, a ako vieme, času je vždy málo.
To všetko samozrejme obmedzuje rozsah použitia tejto metódy nasadenia len na najjednoduchšie systémy. Nastal čas to zmeniť.
prístavný robotník
V určitom okamihu k nám začali prichádzať čerstvo vyrazené stredy, ktoré kypeli nápadmi a šaleli o dokerovi. Nuž, vlajka v ruke – poďme na to! Boli dva pokusy. Obaja boli neúspešní – povedzme pre veľké ambície, ale nedostatok reálnych skúseností. Bolo to potrebné nejako vynútiť a dokončiť? Je to nepravdepodobné – tím sa musí vyvinúť na požadovanú úroveň, aby mohol použiť vhodné nástroje. Pri používaní hotových obrázkov Docker sme sa navyše často stretávali s tým, že sieť nefungovala správne (čo mohlo byť spôsobené vlhkosťou samotného Dockera) alebo bolo ťažké rozširovať kontajnery iných ľudí.
S akými nepríjemnosťami sme sa stretli?
- Problémy so sieťou v režime mosta
- Je nepohodlné prezerať protokoly v kontajneri (ak nie sú uložené oddelene v súborovom systéme hostiteľského počítača)
- ElasticSearch občas zvláštne zamrzne vo vnútri kontajnera, príčina nebola stanovená, kontajner je oficiálny
- Vo vnútri kontajnera je potrebné použiť škrupinu - všetko je veľmi zbavené, neexistujú žiadne obvyklé nástroje
- Veľká veľkosť zberaných nádob - nákladné skladovanie
- Kvôli veľkej veľkosti kontajnerov je ťažké podporovať viacero verzií
- Dlhší čas zostavovania, na rozdiel od iných metód (skripty alebo deb balíčky)
Na druhej strane, prečo je horšie nasadiť službu Spring vo forme jar archívu cez rovnaký deb? Je izolácia zdrojov skutočne potrebná? Oplatí sa stratiť pohodlné nástroje operačného systému tým, že službu nacpete do výrazne zmenšeného kontajnera?
Ako ukázala prax, v skutočnosti to nie je potrebné, v 90% prípadov stačí deb balík.
Kedy starý dobrý deb zlyhá a kedy skutočne potrebujeme docker?
Pre nás to bolo nasadenie služieb v pythone. Veľa knižníc potrebných na strojové učenie a ktoré nie sú zahrnuté v štandardnej distribúcii operačného systému (a čo tam bolo, boli nesprávne verzie), hacky s nastaveniami, potreba rôznych verzií pre rôzne služby žijúce na rovnakom hostiteľskom systéme viedli k to, že jediný rozumný spôsob, ako dodať túto jadrovú zmes, bol docker. Náročnosť montáže dokovacieho kontajnera sa ukázala byť nižšia ako myšlienka zabaliť to všetko do samostatných deb balíkov so závislosťami a v skutočnosti by to nikto so zdravým rozumom nepodnikol.
Druhým bodom, kde plánujeme použiť Docker, je nasadenie služieb pomocou schémy nasadenia modro-zelenej farby. Ale tu chcem dosiahnuť postupné zvyšovanie zložitosti: najprv sa zostavia deb balíčky a potom sa z nich zostaví kontajner docker.
Snap balíky
Vráťme sa k snap balíčkom. Prvýkrát sa oficiálne objavili v Ubuntu 16.04. Na rozdiel od bežných deb balíkov a rpm balíkov, snap nesie všetky závislosti. Na jednej strane to umožňuje vyhnúť sa konfliktom knižníc, na druhej strane je výsledný balík väčších rozmerov. Okrem toho to môže ovplyvniť aj bezpečnosť systému: v prípade rýchleho doručenia musí všetky zmeny v zahrnutých knižniciach sledovať vývojár, ktorý balík vytvára. Vo všeobecnosti nie je všetko také jednoduché a univerzálne šťastie nepochádza z ich používania. Je to však úplne rozumná alternatíva, ak sa rovnaký Docker používa iba ako nástroj na balenie a nie na virtualizáciu.
Výsledkom je, že teraz používame deb balíčky aj docker kontajnery v rozumnej kombinácii, ktoré možno v niektorých prípadoch nahradíme snap balíčkami.
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Čo používate na doručenie?
-
Vlastnoručne písané skriptá
-
Skopírujte manuálne na FTP
-
deb balíčky
-
rpm balíčky
-
snap balíčky
-
Docker-obrázky
-
Obrazy virtuálnych strojov
-
Naklonujte celý HDD
-
bábka
-
ansible
-
Ďalšie
Hlasovalo 109 užívateľov. 32 používatelia sa zdržali hlasovania.
Zdroj: hab.com