Nekako sem se v nekem trenutku odločil napisati članek o dostavi v obliki Docker kontejnerjev in deb paketov, a ko sem začel, me je iz neznanega razloga odneslo v daljne čase prvih osebnih računalnikov in celo kalkulatorjev. Na splošno smo namesto suhoparnih primerjav dockerja in deba dobili te misli na temo evolucije, ki jih predstavljam v vašo pozornost.
Vsak izdelek, ne glede na to, kakšen je, mora nekako priti do strežnikov izdelkov, mora biti konfiguriran in zagnan. O tem bo govoril ta članek.
Razmišljal bom v zgodovinskem kontekstu, »kar vidim, o tem pojem«, kaj sem videl, ko sem prvič začel pisati kodo in kaj opažam zdaj, kaj sami uporabljamo v tem trenutku in zakaj. Članek se ne pretvarja, da je polnopravna študija, nekatere točke so zgrešene, to je moj osebni pogled na to, kaj je bilo in kaj je zdaj.
Torej, v dobrih starih časih... je bil najzgodnejši način dostave, ki sem ga našel, kasete s snemalnikov. Imel sem računalnik BK-0010.01...
Obdobje kalkulatorjev
Ne, bil je še prejšnji trenutek, bil je tudi kalkulator и .
Torej, ko sem imel , takrat je bil način prenosa programa navaden kos papirja v škatli, na katerem je bil napisan program, ki so ga, če je bilo treba, ročno pognati, zapisali v kalkulator. Če hočeš igrati (ja, tudi ta predpotopni kalkulator je imel igre) - se usedeš in vneseš program v kalkulator. Seveda, ko je bil kalkulator izklopljen, je program izginil v pozabo. Poleg lastnoročno izpisanih kod kalkulatorjev na papirju so bili programi objavljeni v revijah Radio in Mladinska tehnika, objavljeni pa so bili tudi v knjigah tistega časa.
Naslednja sprememba je bil kalkulator , že ima nekaj videza trajnega shranjevanja podatkov. Zdaj igre ali programa ni bilo treba vnašati ročno, ampak se je po izvedbi nekaj magičnih potez z gumbi naložil sam.
Velikost največjega programa v kalkulatorju je bila 105 korakov, velikost trajnega pomnilnika v MK-52 pa 512 korakov.
Mimogrede, če obstajajo ljubitelji teh kalkulatorjev, ki berejo ta članek, sem med pisanjem članka našel emulator kalkulatorja za Android in programe zanj. Naprej v preteklost!
Kratka digresija o MK-52 (iz Wikipedije)
MK-52 je poletel v vesolje na vesoljskem plovilu Soyuz TM-7. Uporabili naj bi ga za izračun pristajalne trajektorije, če bi računalnik na vozilu odpovedal.
Od leta 52 se MK-1988 s pomnilniško razširitveno enoto Elektronika-Astro dobavlja ladjam mornarice kot del navigacijskega računalniškega kompleta.
Prvi osebni računalniki
Vrnimo se v čase . Jasno je, da je bilo tam več pomnilnika in tipkanje kode s papirja ni bilo več možnost (čeprav sem sprva počel samo to, ker drugega medija preprosto ni bilo). Avdio kasete za magnetofone postajajo glavno sredstvo za shranjevanje in dostavo programske opreme.
Shranjevanje na kaseti je bilo običajno v obliki ene ali dveh binarnih datotek, vse ostalo je bilo notri. Zanesljivost je bila zelo nizka, obdržati sem moral 2-3 kopije programa. Tudi časi nalaganja so bili razočarani in navdušenci so eksperimentirali z različnimi frekvenčnimi kodiranji, da bi odpravili te pomanjkljivosti. Takrat se sam še nisem ukvarjal s profesionalnim razvojem programske opreme (če ne štejem preprostih programov v BASIC-u), zato vam žal ne bom podrobneje povedal, kako je bilo vse urejeno znotraj. Prav dejstvo, da je imel računalnik večinoma samo RAM, je določilo enostavnost sheme shranjevanja podatkov.
Pojav zanesljivih in velikih medijev za shranjevanje
Kasneje so se pojavile diskete, postopek kopiranja je bil poenostavljen, zanesljivost pa se je povečala.
Toda situacija se dramatično spremeni šele, ko se pojavijo dovolj veliki lokalni pomnilniki v obliki trdih diskov.
Vrsta dostave se bistveno spremeni: pojavijo se namestitveni programi, ki upravljajo postopek konfiguracije sistema, pa tudi čiščenje po odstranitvi, saj se programi ne preberejo samo v pomnilnik, ampak so že kopirani v lokalni pomnilnik, iz katerega morate po potrebi lahko počistite nepotrebne stvari.
Hkrati se povečuje kompleksnost dobavljene programske opreme.
Število datotek v dostavi se poveča z nekaj na stotine in tisoče, konflikti med različicami knjižnic in druge radosti se začnejo, ko različni programi uporabljajo iste podatke.
Takrat mi obstoj Linuxa še ni bil odprt; živel sem v svetu MS DOS in pozneje Windows ter pisal v Borland Pascalu in Delphiju, včasih pa sem se oziral proti C++. Veliko ljudi je takrat uporabljalo InstallShield za dostavo izdelkov. , ki je dokaj uspešno rešil vse zadane naloge postavitve in konfiguracije programske opreme.
Internetna doba
Postopoma kompleksnost programskih sistemov postaja še bolj kompleksna, od monolitnih in namiznih aplikacij prihaja do prehoda na porazdeljene sisteme, tanke odjemalce in mikrostoritve. Zdaj morate konfigurirati ne samo en program, ampak nabor programov, tako da vsi delujejo skupaj.
Koncept se je povsem spremenil, prišel je internet, nastopila je doba storitev v oblaku. Doslej le v začetni fazi, v obliki spletnih strani, o storitvah še nihče ni posebej sanjal. vendar je bila prelomnica tako v razvoju kot v dostavi aplikacij.
Zase sem opazil, da je v tistem trenutku prišlo do menjave generacij razvijalcev (oz. samo v mojem okolju) in bil je občutek, da so bili vsi dobri stari načini dostave v enem trenutku pozabljeni in se je vse začelo od samega začetka. Začetek: vsa dostava se je začela izvajati s skripti na kolenih in jo ponosno imenovala "Neprekinjena dostava". Pravzaprav se je začelo obdobje kaosa, ko je staro pozabljeno in neizkoriščeno, novega pa preprosto ni.
Spominjam se časov, ko so ljudje v našem podjetju, kjer sem takrat delal (ne bom ga imenoval), namesto da bi gradili prek ant (maven še ni bil popularen ali pa sploh ni obstajal), preprosto zbirali kozarce v IDE in se spokojno zavezali to v SVN. V skladu s tem je uvedba zajemala pridobivanje datoteke iz SVN in njeno kopiranje prek SSH na želeni stroj. Tako preprosto in nerodno je.
Hkrati je bila dostava preprostih spletnih mest v PHP izvedena na zelo primitiven način s preprostim kopiranjem popravljene datoteke prek FTP na ciljni stroj. Včasih temu ni bilo tako – koda se je urejala v živo na produktnem strežniku, še posebej šik pa je bilo, če so bile kje rezervne kopije.
Paketi RPM in DEB
Po drugi strani pa so z razvojem interneta UNIX-u podobni sistemi začeli pridobivati vedno večjo popularnost, zlasti takrat sem odkril RedHat Linux 6, približno 2000. Seveda so obstajala tudi določena sredstva za dostavo programske opreme, po Wikipediji se je RPM kot glavni upravljalnik paketov pojavil že leta 1995, v različici RedHat Linux 2.0. In od takrat do danes je sistem dostavljen v obliki paketov RPM in dokaj uspešno obstaja in se razvija.
Distribucije družine Debian so sledile podobni poti in izvajale dostavo v obliki deb paketov, kar je ostalo nespremenjeno do danes.
Upravitelji paketov vam omogočajo, da same dobavite izdelke programske opreme, jih konfigurirate med postopkom namestitve, upravljate odvisnosti med različnimi paketi, odstranite izdelke in počistite nepotrebne elemente med postopkom odstranitve. Tisti. večinoma je to vse, kar je potrebno, zato so skoraj nespremenjene zdržale več desetletij.
Računalništvo v oblaku je upraviteljem paketov dodalo namestitev ne le s fizičnih medijev, temveč tudi iz skladišč v oblaku, vendar se je bistveno spremenilo malo.
Treba je omeniti, da je trenutno nekaj premikov v smeri odmika od deb in prehoda na snap pakete, a več o tem kasneje.
Tako je tudi ta nova generacija razvijalcev v oblaku, ki ni poznala ne DEB ne RPM, počasi rasla, nabirala izkušnje, produkti so postajali bolj kompleksni in potrebni so bili kakšni bolj razumni načini dostave kot FTP, bash skripte in podobne študentske obrti.
In tukaj nastopi Docker, nekakšna mešanica virtualizacije, razmejitve virov in načina dostave. Zdaj je modno in mladostno, a je potrebno za vse? Je to zdravilo?
Po mojih opažanjih je Docker pogosto predlagan ne kot razumna izbira, ampak preprosto zato, ker se po eni strani o njem govori v skupnosti in tisti, ki ga predlagajo, to samo vedo. Po drugi strani pa o dobrih starih embalažnih sistemih večinoma molčijo – ti obstajajo in svoje delo opravljajo tiho in neopazno. V takšni situaciji res ni druge izbire – izbira je očitna – Docker.
Poskušal bom deliti svoje izkušnje o tem, kako smo implementirali Docker in kaj se je zgodilo kot rezultat.
Samostojno napisani scenariji
Sprva so obstajali bash skripti, ki so razmestili arhive jar na zahtevane stroje. Ta proces je vodil Jenkins. To je delovalo uspešno, saj je sam arhiv jar že sestav, ki vsebuje razrede, vire in celo konfiguracijo. Če vanj vložite vse do maksimuma, potem razširitev v skript ni najtežja stvar, ki jo potrebujete
Toda skripti imajo več pomanjkljivosti:
- skripte so običajno napisane v naglici in so zato tako primitivne, da vsebujejo le en najboljši scenarij. To olajšuje dejstvo, da je razvijalec zainteresiran za hitro dostavo, običajni skript pa zahteva naložbo dostojne količine sredstev
- kot posledica prejšnje točke skripti ne vsebujejo postopkov za odstranitev
- ni vzpostavljenega postopka nadgradnje
- Ko se pojavi nov izdelek, morate napisati nov scenarij
- brez podpore odvisnosti
Seveda lahko napišete prefinjen scenarij, vendar, kot sem napisal zgoraj, je to čas razvoja, in ne nazadnje, in kot vemo, je vedno premalo časa.
Vse to očitno omejuje obseg uporabe te metode uvajanja le na najpreprostejše sisteme. Prišel je čas, da se to spremeni.
Lučki delavec
Na neki točki so k nam začeli prihajati sveže skovani sredinci, ki so kipeli od idej in navdušeni nad dockerjem. No, zastavo v roke – naredimo! Bila sta dva poskusa. Oba sta bila neuspešna – recimo zaradi velikih ambicij, a pomanjkanja pravih izkušenj. Ga je bilo treba izsiliti in dokončati na kakršen koli način? To je malo verjetno – ekipa se mora razviti na zahtevano raven, preden lahko uporabi ustrezna orodja. Poleg tega smo pri uporabi že pripravljenih slik Dockerja pogosto naleteli na dejstvo, da omrežje ni delovalo pravilno (kar je morda posledica vlažnosti samega Dockerja) ali pa je bilo težko razširiti vsebnike drugih ljudi.
Na katere nevšečnosti smo naleteli?
- Težave z omrežjem v načinu mostu
- Ogled dnevnikov v vsebniku je neprijetno (če niso shranjeni ločeno v datotečnem sistemu gostiteljskega računalnika)
- ElasticSearch občasno nenavadno zmrzne znotraj vsebnika, razlog ni ugotovljen, vsebnik je uraden
- V posodi je treba uporabiti lupino - vse je zelo očiščeno, običajnih orodij ni
- Velika velikost zbranih posod - drago shranjevanje
- Zaradi velike velikosti vsebnikov je težko podpirati več različic
- Daljši čas gradnje, za razliko od drugih metod (skripte ali deb paketi)
Po drugi strani pa, zakaj je slabše razmestiti storitev Spring v obliki arhiva jar prek istega deba? Ali je izolacija virov res potrebna? Ali se splača izgubiti priročna orodja operacijskega sistema, če storitev stlačimo v močno zmanjšan vsebnik?
Kot je pokazala praksa, v resnici to ni potrebno, paket deb zadostuje v 90% primerov.
Kdaj dobri stari deb odpove in kdaj res potrebujemo dockerja?
Za nas je bilo to uvajanje storitev v pythonu. Veliko knjižnic, potrebnih za strojno učenje in niso vključene v standardno distribucijo operacijskega sistema (in kar je bilo, so bile napačne različice), vdori z nastavitvami, potreba po različnih različicah za različne storitve, ki živijo v istem gostiteljskem sistemu, so privedli do to, da je bil edini razumen način za dostavo te jedrske mešanice docker. Izkazalo se je, da je delovna intenzivnost sestavljanja docker kontejnerja nižja od ideje, da bi vse skupaj zapakirali v ločene pakete deb z odvisnostmi, in pravzaprav se tega ne bi lotil nihče pri zdravi pameti.
Druga točka, kjer je načrtovana uporaba Dockerja, je uvajanje storitev po modro-zeleni shemi uvajanja. Tukaj pa želim doseči postopno povečanje kompleksnosti: najprej se zgradijo paketi deb, nato pa se iz njih zgradi vsebnik docker.
Snap paketi
Vrnimo se k snap paketom. Prvič so se uradno pojavili v Ubuntu 16.04. Za razliko od običajnih paketov deb in paketov rpm snap nosi vse odvisnosti. Po eni strani vam to omogoča, da se izognete konfliktom knjižnic, po drugi strani pa je nastali paket večji. Poleg tega lahko to vpliva tudi na varnost sistema: v primeru hitre dostave mora vse spremembe vključenih knjižnic spremljati razvijalec, ki ustvari paket. Na splošno ni vse tako preprosto in univerzalna sreča ne izvira iz njihove uporabe. Toda kljub temu je to povsem razumna alternativa, če se isti Docker uporablja le kot orodje za pakiranje in ne za virtualizacijo.
Posledično zdaj uporabljamo pakete deb in vsebnike docker v razumni kombinaciji, ki jo bomo morda v nekaterih primerih nadomestili s paketi snap.
V anketi lahko sodelujejo samo registrirani uporabniki. , prosim.
Kaj uporabljate za dostavo?
-
Samostojno napisani scenariji
-
Kopirajte ročno na FTP
-
deb paketi
-
paketi rpm
-
snap paketi
-
Docker-slike
-
Slike virtualnih strojev
-
Klonirajte celoten trdi disk
-
lutkovna
-
odgovoren
-
Drugo
Glasovalo je 109 uporabnikov. 32 uporabnika sta se vzdržala.
Vir: www.habr.com