Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleira

Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleira

Einhvern veginn ákvað ég á einum tímapunkti að skrifa grein um afhendingu í formi Docker gáma og deb pakka, en þegar ég byrjaði var ég einhverra hluta vegna fluttur aftur til fjarlægra tíma fyrstu einkatölvanna og jafnvel reiknivélanna. Almennt séð, í stað þurrs samanburðar á docker og deb, fengum við þessar hugsanir um þróunarefnið, sem ég legg fram til umhugsunar.

Sérhver vara, sama hver hún er, verður einhvern veginn að komast á vöruþjónana, verður að vera stillt og ræst. Um það mun þessi grein fjalla.

Ég mun hugsa í sögulegu samhengi, "það sem ég sé er það sem ég syng um," það sem ég sá þegar ég byrjaði að skrifa kóða og hvað ég sé núna, hvað við sjálf erum að nota í augnablikinu og hvers vegna. Greinin gefur sig ekki út fyrir að vera fullgild rannsókn, sumum atriðum vantar, þetta er mín persónulega skoðun á því sem var og hvað er núna.

Svo, í gamla góða daga... elsta afhendingaraðferðin sem ég fann var kassettubönd af segulbandstækjum. Ég átti tölvu BK-0010.01...

Tímabil reiknivéla

Nei, það var enn fyrr augnablik, það var líka reiknivél MK-61 и MK-52.

Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleira Svo þegar ég átti MK-61, þá var leiðin til að flytja forritið venjulegt blað í kassa sem forrit var skrifað á, sem, ef nauðsyn krefur, til að keyra það handvirkt, var skrifað inn í reiknivélina. Ef þú vilt spila (já, meira að segja þessi fortíðarreiknivél átti leiki) - sest þú niður og setur forritið inn í reiknivélina. Auðvitað, þegar slökkt var á reiknivélinni, hvarf forritið í gleymsku. Auk reiknikóðana sem voru persónulega skrifaðir á pappír voru þættirnir birtir í tímaritunum „Radio“ og „Technology for Youth“ og voru einnig birt í bókum þess tíma.

Næsta breyting var reiknivél MK-52, það hefur nú þegar einhverja sýn á óstöðug gagnageymslu. Nú þurfti ekki að slá inn leikinn eða forritið handvirkt, en eftir að hafa framkvæmt nokkrar töfrandi sendingar með hnöppunum hleðst það sjálft.

Stærð stærsta forritsins í reiknivélinni var 105 skref og stærð varanlegs minnis í MK-52 var 512 skref.

Við the vegur, ef það eru aðdáendur þessara reiknivéla sem eru að lesa þessa grein, í því ferli að skrifa greinina fann ég bæði reiknihermi fyrir Android og forrit fyrir það. Áfram til fortíðar!

Stutt útdráttur um MK-52 (frá Wikipedia)

MK-52 flaug út í geim á Soyuz TM-7 geimfarinu. Það átti að nota til að reikna út lendingarferilinn ef ske kynni að aksturstölvan bilaði.

Síðan 52 hefur MK-1988 með Elektronika-Astro minnisstækkunareiningunni verið afhent sjóhernum sem hluti af siglingatölvubúnaði.

Fyrstu einkatölvurnar

Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleira Við skulum hverfa aftur til tímans BC-0010. Það er greinilegt að það var meira minni þarna og að slá inn kóða af blaði var ekki lengur valmöguleiki (þótt ég gerði það í fyrstu, því það var einfaldlega enginn annar miðill). Hljóðsnældur fyrir segulbandstæki eru að verða aðalleiðin til að geyma og afhenda hugbúnað.





Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleiraGeymsla á snældu var venjulega í formi einnar eða tveggja tvöfaldra skráa, allt annað var inni í. Áreiðanleiki var mjög lítill, ég þurfti að geyma 2-3 eintök af forritinu. Hleðslutími olli líka vonbrigðum og áhugamenn gerðu tilraunir með mismunandi tíðnikóðun til að vinna bug á þessum göllum. Á þeim tíma var ég sjálfur ekki enn þátt í faglegri hugbúnaðarþróun (að ótal einföldum forritum í BASIC), svo því miður mun ég ekki segja þér í smáatriðum hvernig öllu var raðað inni. Sú staðreynd að tölvan hafði aðeins vinnsluminni að mestu réði einfaldleika gagnageymslukerfisins.

Tilkoma áreiðanlegra og stórra geymslumiðla

Seinna komu fram disklingar, afritunarferlið var einfaldað og áreiðanleiki jókst.
En ástandið breytist aðeins þegar nægilega stórar staðbundnar geymslur birtast í formi HDDs.

Tegund afhendingar er að breytast í grundvallaratriðum: uppsetningarforrit birtast sem stjórna ferlinu við að stilla kerfið, auk þess að þrífa upp eftir að það hefur verið fjarlægt, þar sem forrit eru ekki bara lesin inn í minni, heldur eru þau þegar afrituð í staðbundna geymslu, þaðan sem þú þarft að geta hreinsað óþarfa hluti ef þörf krefur.

Á sama tíma eykst flókið hugbúnaðar sem fylgir.
Fjöldi skráa í afhendingunni eykst úr nokkrum í hundruð og þúsundir, árekstrar milli útgáfur bókasafns og önnur gleði hefjast þegar mismunandi forrit nota sömu gögnin.

Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleira Á þeim tíma var tilvist Linux ekki enn opin fyrir mér; ég lifði í heimi MS DOS og síðar Windows og skrifaði í Borland Pascal og Delphi og horfði stundum í átt að C++. Margir notuðu InstallShield til að afhenda vörur þá. ru.wikipedia.org/wiki/InstallShield, sem leysti með góðum árangri öll úthlutað verkefni við að dreifa og stilla hugbúnaðinn.




Internet tímabil

Smám saman er flókið hugbúnaðarkerfi að verða enn flóknara; frá einliða- og skrifborðsforritum er skipt yfir í dreifð kerfi, þunnt kerfi og örþjónustur. Nú þarftu að stilla ekki bara eitt forrit, heldur sett af þeim, og þannig að þau vinni öll saman.

Hugmyndin gjörbreyttist, internetið kom, tímabil skýjaþjónustunnar kom. Hingað til, aðeins á upphafsstigi, í formi vefsíðna, hefur enginn dreymt sérstaklega um þjónustu. en það urðu tímamót bæði í þróun og afhendingu umsókna.

Fyrir sjálfan mig tók ég eftir því að á því augnabliki varð breyting á kynslóðum þróunaraðila (eða það var bara í umhverfi mínu), og það var tilfinning að allar gömlu góðu afhendingaraðferðirnar gleymdust á einu augnabliki og allt byrjaði strax upphaf: öll afhending byrjaði að gera hnéhandrit og kallaði það stolt "Stöðug afhending". Reyndar er tímabil glundroða hafið, þegar hið gamla gleymist og er ekki notað og hið nýja er einfaldlega ekki til.

Ég man þá tíma þegar í fyrirtækinu okkar þar sem ég vann þá (ég nefni það ekki), í stað þess að byggja í gegnum maur (maven var ekki enn vinsæll eða var alls ekki til), safnaði fólk einfaldlega krukkum í IDE og skuldbundið sig af æðruleysi það í SVN. Í samræmi við það fólst dreifing í því að sækja skrána úr SVN og afrita hana í gegnum SSH á viðkomandi vél. Þetta er svo einfalt og klaufalegt.

Á sama tíma var afhending á einföldum síðum í PHP gert á mjög frumstæðan hátt með því einfaldlega að afrita leiðrétta skrána í gegnum FTP á markvélina. Stundum var þetta ekki raunin - kóðanum var breytt í beinni útsendingu á vöruþjóninum og það var sérstaklega flott ef það voru afrit einhvers staðar.


RPM og DEB pakka

Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleiraÁ hinn bóginn, með þróun internetsins, fóru UNIX-lík kerfi að ná meiri og meiri vinsældum, sérstaklega var það á þeim tíma sem ég uppgötvaði RedHat Linux 6, um það bil 2000. Auðvitað voru líka ákveðnar leiðir til að afhenda hugbúnað; samkvæmt Wikipedia birtist RPM sem aðalpakkastjóri þegar árið 1995, í útgáfunni af RedHat Linux 2.0. Og síðan þá og fram á þennan dag hefur kerfið verið afhent í formi RPM pakka og hefur verið til og þróast með nokkuð góðum árangri.

Dreifingar á Debian fjölskyldunni fóru á svipaðan hátt og innleiddu afhendingu í formi deb-pakka, sem hefur haldist óbreytt til þessa dags.

Pakkastjórar leyfa þér að afhenda hugbúnaðarvörurnar sjálfir, stilla þær meðan á uppsetningarferlinu stendur, stjórna ósjálfstæði milli mismunandi pakka, fjarlægja vörur og hreinsa upp óþarfa hluti á meðan á uppsetningarferlinu stendur. Þeir. að mestu leyti, það er allt sem þarf, þess vegna stóðu þau nokkra áratugi nánast óbreytt.

Tölvuský hefur bætt uppsetningu við pakkastjóra, ekki aðeins frá efnismiðlum, heldur einnig frá skýjageymslum, en í grundvallaratriðum hefur lítið breyst.

Það er rétt að taka fram að eins og er eru nokkrar hreyfingar í átt að því að hverfa frá skuldabréfum og skipta yfir í snappakka, en meira um það síðar.

Þannig að þessi nýja kynslóð skýjaframleiðenda, sem þekkti hvorki DEB né RPM, stækkaði líka hægt og rólega, öðlaðist reynslu, vörur urðu flóknari og það þurfti nokkrar sanngjarnari afhendingaraðferðir en FTP, bash forskriftir og svipað handverk nemenda.
Og þetta er þar sem Docker kemur inn í myndina, eins konar blanda af sýndarvæðingu, afmörkun auðlinda og afhendingaraðferð. Það er smart og unglegt núna, en er það nauðsynlegt fyrir allt? Er þetta töfralyf?

Af athugunum mínum er mjög oft Docker ekki lagt fram sem sanngjarnt val, heldur einfaldlega vegna þess að annars vegar er talað um það í samfélaginu og þeir sem leggja fram það vita það bara. Hins vegar þegja þeir að mestu um gömlu góðu umbúðakerfin - þau eru til og vinna sína vinnu hljóðlega og óséður. Í slíkum aðstæðum er í raun ekkert annað val - valið er augljóst - Docker.

Ég mun reyna að deila reynslu minni af því hvernig við innleiddum Docker og hvað gerðist í kjölfarið.


Sjálfskrifuð handrit

Upphaflega voru bash forskriftir sem sendu jar skjalasafn á nauðsynlegar vélar. Þetta ferli var stjórnað af Jenkins. Þetta virkaði með góðum árangri, þar sem jar skjalasafnið sjálft er nú þegar samsetning sem inniheldur flokka, auðlindir og jafnvel stillingar. Ef þú setur allt í það að hámarki, þá er það ekki það erfiðasta sem þú þarft að stækka það í handrit

En forskriftir hafa nokkra ókosti:

  • handrit eru venjulega skrifuð í flýti og eru því svo frumstæð að þau innihalda aðeins eina besta tilfelli. Þetta er auðveldað af þeirri staðreynd að verktaki hefur áhuga á skjótum afhendingu og venjulegt handrit krefst fjárfestingar á viðeigandi magni af fjármagni
  • sem afleiðing af fyrri lið, innihalda forskriftirnar ekki uppsetningaraðferðir
  • engin staðfest uppfærsluaðferð
  • Þegar ný vara birtist þarftu að skrifa nýtt handrit
  • engin framfærslustuðningur

Auðvitað er hægt að skrifa vandað handrit, en eins og ég skrifaði hér að ofan er þetta þróunartími og ekki síst, og eins og við vitum er alltaf ekki nægur tími.

Allt þetta takmarkar augljóslega notkunarsvið þessarar dreifingaraðferðar við aðeins einföldustu kerfin. Það er kominn tími til að breyta þessu.


Docker

Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleiraÁ einhverjum tímapunkti fóru að koma til okkar nýsmögnuð miðja, súrandi af hugmyndum og ærslast um hafnarmanninn. Jæja, fána í hendi - við skulum gera það! Það voru tvær tilraunir. Hvort tveggja tókst ekki - við skulum segja, vegna mikils metnaðar, en skorts á raunverulegri reynslu. Var nauðsynlegt að þvinga það og klára það með einhverjum hætti? Það er ólíklegt - liðið verður að þróast í tilskilið stig áður en það getur notað viðeigandi verkfæri. Þar að auki, þegar við notuðum tilbúnar Docker myndir, lentum við oft í því að netið virkaði ekki rétt (sem gæti hafa verið vegna raka Docker sjálfs) eða það var erfitt að stækka ílát annarra.

Hvaða óþægindi lentum við í?

  • Netvandamál í brúarstillingu
  • Það er óþægilegt að skoða annála í gámi (ef þeir eru ekki geymdir sérstaklega í skráarkerfi vélarinnar)
  • ElasticSearch frýs stundum undarlega inni í ílátinu, ástæðan hefur ekki verið ákveðin, ílátið er opinbert
  • Það er nauðsynlegt að nota skel inni í íláti - allt er mjög afskræmt, það eru engin venjuleg verkfæri
  • Stór stærð af söfnuðum ílátum - dýrt í geymslu
  • Vegna stórrar stærðar gáma er erfitt að styðja við margar útgáfur
  • Lengri byggingartími, ólíkt öðrum aðferðum (forskriftir eða deb pakkar)

Á hinn bóginn, hvers vegna er það verra að dreifa Vorþjónustu í formi krukkuskjalasafns í gegnum sömu deb? Er einangrun auðlinda virkilega nauðsynleg? Er það þess virði að týna þægilegum stýrikerfisverkfærum með því að troða þjónustu í mjög minnkaðan ílát?

Eins og æfingin hefur sýnt er þetta í raun ekki nauðsynlegt, deb pakkinn er nóg í 90% tilvika.

Hvenær mistakast gamla góða debbið og hvenær þurfum við virkilega bryggjumann?

Fyrir okkur var þetta að dreifa þjónustu í Python. Mörg bókasöfn sem þarf til vélanáms og eru ekki innifalin í hefðbundinni dreifingu stýrikerfisins (og það sem var þar voru rangar útgáfur), hakk með stillingum, þörfin fyrir mismunandi útgáfur fyrir mismunandi þjónustu sem búa á sama hýsingarkerfinu leiddi til þess að þetta, að eina sanngjarna leiðin til að afhenda þessa kjarnorkublöndu var hafnarmaðurinn. Vinnuálag við að setja saman hafnargám reyndist lægri en hugmyndin um að pakka þessu öllu saman í aðskilda deb-pakka með ósjálfstæði, og í raun myndi enginn með réttu huga taka að sér þetta.

Annað atriðið þar sem við ætlum að nota Docker er að dreifa þjónustu með því að nota blágræna dreifingarkerfið. En hér vil ég fá smám saman aukningu á flækjustiginu: fyrst eru deb pakkar smíðaðir og síðan er bryggjugámur byggður úr þeim.


Smelltu pakka

Þróun afhendingartækja, eða hugsanir um Docker, deb, jar og fleira Snúum okkur aftur að snappökkunum. Þeir birtust fyrst opinberlega í Ubuntu 16.04. Ólíkt venjulegum deb pakka og rpm pakka, þá ber snap allar ósjálfstæðin. Annars vegar gerir þetta þér kleift að forðast árekstra í bókasafni, hins vegar er pakkinn sem myndast stærri í stærð. Að auki getur þetta einnig haft áhrif á öryggi kerfisins: ef um skyndisendingu er að ræða, verður að fylgjast með öllum breytingum á meðfylgjandi bókasöfnum af verktaki sem býr til pakkann. Almennt séð er ekki allt svo einfalt og alhliða hamingja stafar ekki af notkun þeirra. En engu að síður er þetta fullkomlega sanngjarn valkostur ef sami Docker er aðeins notaður sem pökkunartæki en ekki til sýndarvæðingar.



Fyrir vikið notum við nú bæði deb pakka og docker gáma í hæfilegri samsetningu, sem, ef til vill, í sumum tilfellum munum við skipta út fyrir snappakka.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Hvað notar þú við afhendingu?

  • Sjálfskrifuð handrit

  • Afritaðu handvirkt á FTP

  • deb pakka

  • rpm pakka

  • snap pakka

  • Docker-myndir

  • Sýndarvélar myndir

  • Klóna allan HDD

  • Puppet

  • ansible

  • Annað

109 notendur greiddu atkvæði. 32 notendur sátu hjá.

Heimild: www.habr.com

Bæta við athugasemd