Raz jednu som sa rozhodol napísať článok o dodávke vo forme kontajnerov Docker a deb balíkov, ale keď som začal, nejako ma to zanieslo do dávnych čias prvých osobných počítačov a dokonca kalkulačiek. Celkovo, namiesto suchých porovnaní Dockera a debu sa vyformovali akési úvahy na tému evolúcie, ktoré teraz predkladám na váš súd.
Akýkoľvek produkt, nech je akýkoľvek, musí sa nejakým spôsobom dostať na produktové servery, musí byť nastavený a spustený. O tom bude tento článok.
Budem uvažovať v historickom kontexte, "čo vidím — o tom spievam", čo som videl, keď som začínal písať kód a čo pozorujem teraz, čo sami v súčasnosti používame a prečo. Článok si nenárokuje na úplne zamerané výskum, niektoré momenty sú opomenuté, je to môj osobný pohľad na to, čo bolo a čo je teraz.
Takže, v starých dobrých časoch… najskorší spôsob dodávky, ktorý som zažil — boli kazety z magnetofónov. Mám počítač BK-0010.01…
Éra kalkulačiek
Nie, bola tu ešte skôr, bola tu aj kalkulačka a .
Keď som mal , spôsobom prenosu programu bol obyčajný list papiera s mriežkou, na ktorom bola zapísaná program, ktorý, ak som ho chcel spustiť, som musel ručne zapísať do kalkulačky. Chceš si zahrať (áno, dokonca na tejto pravekej kalkulačke boli hry) — sadneš si a vpíšeš program do kalkulačky. Samozrejme, pri vypnutí kalkulačky program zmizol. Okrem vlastnoručne prepísaných kódov na papieri, programy sa publikovali v časopisoch "Rádio" a "Technika mládeže" a tiež sa tlačili v knihách tej doby.
Ďalšou modifikáciou bol kalkulačka , už mal akúsi podobu energonezávislého úložiska dát. Teraz už nebolo potrebné zadávať hru alebo program ručne, ale po vykonaní niektorých magických pohybov tlačidlami sa načítala sama.
Objem najväčšieho programu v kalkulačke bol 105 krokov a veľkosť trvalej pamäte v MK-52 — 512 krokov.
Mimochodom, ak sú medzi čitateľmi tohto článku fanúšikovia týchto kalkulačiek — pri písaní článku som našiel aj emulátor kalkulačky pre Android a programy preň. Poďme späť do minulosti!
Malé odbočenie k MK-52 (z wikipedie)
MK-52 letel do vesmíru na lodi „Sojuz TM-7“. Mal sa použiť na výpočet trajektórie pristátia, ak by sa pokazil palubný počítač.
MK-52 s blokom rozšírenia pamäte „Elektronika-Astro“ sa od roku 1988 dodával na lode námorníctva ako súčasť výpočtového komplexu pre navigáciu.
Prvé osobné počítače
Vráťme sa do čias . Samozrejme, že pamäte tam bolo viac a zadávať kód z papierika už nebola možnosť (hoci v prvých časoch som to robil práve tak, pretože iné médium jednoducho nebolo). Základným prostriedkom uchovávania a dodávania softvéru sa stávajú audiokazety pre magnetofóny.
Uchovávanie na kazete zvyčajne pozostávalo z jedného alebo dvoch binárnych súborov, všetko ostatné bolo uložené vo vnútri. Spoľahlivosť bola veľmi nízka, musel som mať 2-3 kópie programu. Čas načítania tiež nebol potešujúci, nadšenci experimentovali s rôznymi frekvenčnými kódovaniami, aby prekonali tieto nevýhody. V tom čase som sa ešte nezačal profesionálne zaoberať vývojom softvéru (okrem jednoduchých programov v Basicu), takže bohužiaľ nemôžem podrobne opísať, ako to všetko fungovalo. Skutočnosť, že počítač mal iba RAM, do značnej miery určovala jednoduchosť schémy uchovávania dát.
Objavenie spoľahlivých a veľkých úložných médií
Neskôr sa objavujú disketové jednotky, proces kopírovania sa zjednodušuje, zvyšuje sa spoľahlivosť.
Ale situácia sa zásadne mení až vtedy, keď sa objavia dostatočne veľké lokálne úložiská v podobe HDD.
Zásadne sa mení typ dodávky: objavujú sa inštalačné programy, ktoré riadia proces konfigurácie systému a tiež čistenie po odstránení, pretože programy sa už nielen načítavajú do pamäte, ale kopírujú do lokálneho úložiska, z ktorého je potrebné vedieť aj odstraňovať nepotrebné.
Súčasne sa zvyšuje zložitost dodávaného softvéru.
Počet súborov v dodávke sa zvyšuje z jedného na stovky a tisíce, začínajú konflikty verzií knižníc a iné radosti, keď rôzne programy používajú tie isté dáta.
V tých časoch som ešte nevedel o existencii Linuxu, žil som vo svete MS DOS a neskôr Windows, pričom som písal v Borland Pascal a Delphi, občas som sa pozrel na C++. Mnohí na dodávku produktov vtedy používali InstallShield. , ktorý úspešne riešil všetky zadané úlohy nasadenia a konfigurácie softvéru.
Éra internetu.
Postupne sa zložitosti programových systémov ešte zvyšovali, od monolitických a desktopových aplikácií prechádzalo ku distribuovaným systémom, tenkým klientom a mikroservisom. Teraz už bolo potrebné konfigurovať nielen jednu aplikáciu, ale ich celú sadu, a to tak, aby spolu spolupracovali.
Úplne sa zmenila koncepcia, prišiel internet a nastala éra cloudových služieb. Ešte stále sme boli len na začiatku, v podobe webových stránok, zatiaľ nikto ani nesníval o nejakých službách, ale bol to prelomový moment v odvetví, ako v oblasti vývoja, tak aj dodávky aplikácií.
Pre seba som si uvedomil, že v tomto momente došlo k zmene generácií vývojárov (alebo to bolo len v mojej blízkosti) a vytvorilo sa také pocity, že všetky staré dobré spôsoby dodávky boli zabudnuté v jednom momente a všetko začalo odznova: celú dodávku začali robiť na kolene písanými skriptami a nazvali to hrdinsky „Continuous delivery“. V skutočnosti začalo akési obdobie chaosu, keď bola stará prax zabudnutá a nová prakticky neexistovala.
Pamätám si časy, keď u nás v spoločnosti, kde som vtedy pracoval (nebudem ju menovať), namiesto toho, aby sme robili zostavenie cez ant (maven ešte nebol populárny alebo vôbec neexistoval), ľudia jednoducho zostavovali jar v IDE a bezstarostne ho zaväzovali do SVN. Podľa toho sa nasadenie skladalo z vyťahovania súboru zo SVN a jeho kopírovania cez SSH na potrebný stroj. Tak jednoducho a surovo.
V tom istom čase sa dodávka jednoduchých webových stránok na PHP robila úplne primitívne, jednoducho kopírovaním upraveného súboru cez FTP na cieľový server. Niekedy nebolo ani takéto niečo — kód sa opravoval priamo na produktovom serveri, a bolo výnimočné, ak existovali nejaké zálohy.
RPM- a DEB-pakety
Na druhej strane, s rozvojom internetu začali čoraz viac získavať na popularite systémy podobné UNIX-u, konkrétne v tom čase som objavil RedHat Linux 6, približne v roku 2000. Samozrejme, že aj tam boli isté prostriedky na dodávku softvéru, podľa Wikipédie, RPM ako hlavný správca balíčkov sa objavil už v roku 1995, vo verzii RedHat Linux 2.0. A od tej doby po súčasnosť sa systém dodáva vo forme RPM balíčkov a úspešne existuje a vyvíja sa.
Distribúcie rodiny Debian išli podobnou cestou a implementovali dodávku vo forme deb balíčkov, čo je nezmenené až do dnes.
Správcovia balíčkov umožňujú dodávať samotné softvérové produkty, konfigurovať ich počas inštalácie, spravovať závislosti medzi rôznymi balíčkami, vykonávať odinštaláciu produktov a čistiť nadbytočné počas odinštalácie. T.j. väčšinou je to všetko, čo je potrebné, práve preto prežili niekoľko desaťročí prakticky bez zmien.
Cloud priniesol do správcov balíčkov inštaláciu nielen z fyzických nosičov, ale aj z cloudových repozitárov, ale principiálne sa málo zmenilo.
Treba poznamenať, že v súčasnosti existujú určité snahy o opustenie deb a prechod na snap balíčky, ale o tom neskôr.
Takže toto nové поколение облачных разработчиков, которое не знало ни DEB, ни RPM, тоже потихоньку росло, набиралось опыта, продукты усложнялись, и нужны были какие-то более разумные способы поставки, нежели FTP, bash-скриптики и подобные студенческие поделки.
A tu prichádza Docker, akási zmes virtualizácie, rozdeľovania zdrojov a spôsobu dodávky. To je teraz módne, moderné, ale je potrebný pre všetko? Je to strieborná guľka?
Podľa mojich pozorovaní, veľmi často je Docker ponúkaný nie ako rozumná voľba, ale jednoducho preto, že o tom, na jednej strane, hovoria v komunite a tí, ktorí ho ponúkajú, poznajú len to. Na druhej strane, o starých dobrých systémoch balenia sa väčšinou mlčí — sú tu a robia svoju prácu potichu a nenápadne. V takejto situácii nie je veľa na výber — voľba je jasná — Docker.
Pokúsim sa podeliť o skúsenosti, ako u nás prebiehalo zavádzanie Dockeru a čo nakoniec vzišlo.
Vlastné skripty
Pôvodne boli bash skripty, ktoré nasadzovali jar archívy na požadované stroje. Týmto procesom riadil Jenkins. To úspešne fungovalo, keďže samotný jar archív už je zostava, ktorá obsahuje triedy, zdroje a dokonca aj konfiguráciu. Ak do neho vložíte všetko na maximum — rozložiť ho pomocou skriptu nie je to najťažšie, čo je potrebné.
Avšak skripty majú niekoľko nevýhod:
- skripty sa zvyčajne píšu na rýchlo a sú preto také primitívne, že obsahujú iba jeden najoptimálnejší scenár. K tomu prispieva skutočnosť, že vývojár sa zaujíma o čo najrýchlejšie dodanie, a normálny skript si vyžaduje investíciu slušného množstva zdrojov.
- ako dôsledok predchádzajúceho bodu skripty neobsahujú procedúru odinštalovania.
- nie je stanovená procedúra upgrade.
- pri vzniku nového produktu je potrebné napísať nový skript.
- neexistuje podpora závislostí.
Samozrejme, môžete napísať zložitý skript, ale, ako som už písal vyššie — to je čas na vývoj, a nie je to malé množstvo, a času, ako je známe, vždy chýba.
To všetko zjavne obmedzuje okruh aplikácií tohto spôsobu nasadenia iba na najjednoduchšie systémy. Prišiel čas to zmeniť.
Docker
V určitom momente k nám začali prichádzať čerstvo upečení midly, boilujúcimi nápadmi a snívajúce o dockeri. No, vlajka do rúk - robíme! Boli dve pokusy. Obe neúspešné - povedzme, z veľkých ambícií, ale nedostatočnej reálnej skúsenosti. Malo sa to urýchliť a dokončiť za každú cenu? Ťažko — kolektív by mal evolučne dorásť na potrebnú úroveň, kým bude môcť používať zodpovedajúce nástroje. Navyše, pri používaní hotových docker obrazov sme sa často stretávali s tým, že tam nesprávne fungovala sieť (čo možno súviselo aj so surovosťou samotného dockera) alebo bolo zložité rozširovať cudzie kontajnery.
S akými nevhodnosťami sme sa stretli?
- Problémy so sieťou v režime bridge.
- Nepohodlné sledovať logy v kontejnery (ak nie sú nikam presunuté do súborového systému hostiteľského stroja).
- Občas zvláštne zamrznutie ElasticSearch vnútri kontajnera, príčinu sme tak aj nezistili, kontajner je oficiálny.
- Nepohodlné používať shell vnútri kontajnera — všetko je značne obmedzené, chýbajú obvyklé nástroje.
- Veľká veľkosť zhromažďovaných kontajnerov — drahé na uloženie
- Kvôli veľkej veľkosti kontajnerov je ťažké udržiavať viacero verzií
- Dlhšia zostava, na rozdiel od iných metód (skripty alebo deb balíky)
Na druhej strane, prečo je nasadenie Spring služby vo forme jar archívu horšie ako cez deb? Je naozaj potrebná izolácia zdrojov? Stojí za to vzdať sa pohodlných nástrojov operačného systému a natlačiť službu do silno obmedzeného kontajnera?
Ako ukázala prax — v realite to nie je nutné, deb balíka stačí v 90% prípadov.
Kedy nakoniec starý dobrý deb nefunguje a kedy naozaj potrebujeme docker?
Pre nás to bolo nasadenie služieb na Pythone. Množstvo knižníc potrebných pre strojové učenie a chýbajúcich v štandardnej dodávke operačného systému (a to, čo tam bolo — nie tie verzie), hacky s nastaveniami, potreba rôznych verzií pre rôzne služby, ktoré bežia na tej istej hostiteľskej sústave, viedli k tomu, že jediným rozumným spôsobom dodania tejto jadrovej zmesi sa ukázal byť docker. Práca na zostave docker kontajnera bola menej náročná ako myšlienka zabaliť to všetko do samostatných deb balíkov so závislosťami, a vlastne nikto by sa do toho v zdravej mysli ani nepustil.
Druhý bod, kde sa plánuje použiť docker — na nasadenie služieb podľa schémy blue-green deploy. Ale tu chceme dosiahnuť postupné zvyšovanie zložitosti: najprv sa zostavujú deb balíky a potom už z nich vzniká docker kontajner.
Snap balíky
Vráťme sa k snap balíkom. Po 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 nesú všetky závislosti. Na jednej strane to umožňuje vyhnúť sa konfliktom s knižnicami, na druhej strane — to vedie k významnejším veľkostiam výsledného balíka. Okrem toho, to môže ovplyvniť aj bezpečnosť systému: v prípade dodania snap by si mal vývojár, ktorý vytvára balík, sledovať všetky zmeny zapojených knižníc. Vo všeobecnosti to nie je úplne jednoznačné a univerzálne šťastie z ich používania nenastáva. Ale, napriek tomu, je to celkom rozumná alternatíva, ak sa ten istý Docker používa len ako prostriedok balenia, nie virtualizácie.
Na záver používame rozumnú kombináciu deb balíkov a Docker kontajnerov, ktoré možno v niektorých prípadoch nahradíme snap balíkmi.
Len registrovaní používatelia sa môžu zúčastniť prieskumu. , prosím.
A čo používate na dodávku vy?
Vlastné skripty
Kopírujeme ručne na FTP
deb balíky
rpm balíky
snap balíky
Docker obrazy
Obrazy virtuálnych strojov
Klonujeme HDD celý
puppet
ansible
Other
Hlasovalo 109 používateľov. 32 používateľov sa zdržalo.
Zdroj: habr.com
