Piegādes rīku attīstība vai domas par Docker, deb, jar un citiem

Piegādes rīku attīstība vai domas par Docker, deb, jar un citiem

Kaut kā vienā brÄ«dÄ« es nolēmu uzrakstÄ«t rakstu par piegādi Docker konteineru un deb paku veidā, bet, kad sāku, nez kāpēc tiku aizvests uz pirmo personālo datoru un pat kalkulatoru tālajiem laikiem. Kopumā docker un deb sauso salÄ«dzinājumu vietā mēs ieguvām Ŕīs domas par evolÅ«cijas tēmu, ko es piedāvāju jÅ«su apsvērÅ”anai.

JebkurÅ” produkts, neatkarÄ«gi no tā, kāds tas ir, kaut kādā veidā jānokļūst produkta serveros, ir jākonfigurē un jāpalaiž. TieÅ”i par to bÅ«s Å”is raksts.

Es padomāŔu vēsturiskā kontekstā, "tas, ko es redzu, ir tas, par ko es dziedu", ko es redzēju, kad sāku rakstÄ«t kodu, un ko novēroju tagad, ko mēs paÅ”i lietojam Å”obrÄ«d un kāpēc. Raksts nepretendē uz pilnvērtÄ«gu pētÄ«jumu, daži punkti ir garām, tas ir mans personÄ«gais skatÄ«jums uz to, kas bija un kas ir tagad.

Tātad, vecajos labajos laikos... agrākais piegādes veids, ko es atradu, bija magnetofona kasetes. Man bija dators BK-0010.01...

Kalkulatoru laikmets

Nē, bija vēl agrāks brÄ«dis, bija arÄ« kalkulators MK-61 Šø MK-52.

Piegādes rÄ«ku attÄ«stÄ«ba vai domas par Docker, deb, jar un citiem Tātad, kad man bija MK-61, tad programmas pārsÅ«tÄ«Å”anas veids bija parasts papÄ«rs kastÄ«tē, uz kura bija uzrakstÄ«ta programma, kuru nepiecieÅ”amÄ«bas gadÄ«jumā, lai palaistu manuāli, ierakstÄ«ja kalkulatorā. Ja gribi spēlēt (jā, pat Å”im pirmsÅ«dens kalkulatoram bija spēles) - apsēdies un ievadi programmu kalkulatorā. Protams, kad kalkulators tika izslēgts, programma pazuda aizmirstÄ«bā. Papildus paÅ”a rokām uz papÄ«ra izrakstÄ«tajiem kalkulatora kodiem raidÄ«jumi tika publicēti žurnālos ā€œRadioā€ un ā€œTehnoloÄ£ija jaunatneiā€, kā arÄ« publicēti tā laika grāmatās.

Nākamā modifikācija bija kalkulators MK-52, tai jau ir zināma nepastāvÄ«gas datu glabāŔanas lÄ«dzÄ«ba. Tagad spēle vai programma nebija jāievada manuāli, bet pēc dažu maÄ£isku piespēļu veikÅ”anas ar pogām tā ielādējās pati.

Lielākās programmas lielums kalkulatorā bija 105 soļi, un pastāvīgās atmiņas lielums MK-52 bija 512 soļi.

Starp citu, ja ir Å”o kalkulatoru cienÄ«tāji, kas lasa Å”o rakstu, raksta tapÅ”anas procesā es atradu gan kalkulatora emulatoru priekÅ” Android, gan arÄ« tam paredzētas programmas. Uz priekÅ”u pagātnē!

ÄŖsa atkāpe par MK-52 (no Vikipēdijas)

MK-52 lidoja kosmosā ar kosmosa kuÄ£i Sojuz TM-7. To bija paredzēts izmantot, lai aprēķinātu nosÄ“Å”anās trajektoriju gadÄ«jumā, ja borta dators sabojājas.

KopÅ” 52. gada MK-1988 ar Elektronika-Astro atmiņas paplaÅ”ināŔanas bloku tiek piegādāts JÅ«ras spēku kuÄ£iem kā daļa no navigācijas skaitļoÅ”anas komplekta.

Pirmie personālie datori

Piegādes rÄ«ku attÄ«stÄ«ba vai domas par Docker, deb, jar un citiem AtgriezÄ«simies laikos BC-0010. Skaidrs, ka tur bija vairāk atmiņas, un koda ievadÄ«Å”ana no papÄ«ra vairs nebija iespējama (lai gan sākumā darÄ«ju tieÅ”i tā, jo cita datu nesēja vienkārÅ”i nebija). Magnetofonu audiokasetes kļūst par galveno programmatÅ«ras uzglabāŔanas un piegādes lÄ«dzekli.





Piegādes rÄ«ku attÄ«stÄ«ba vai domas par Docker, deb, jar un citiemUzglabāŔana kasetē parasti bija viena vai divu bināro failu veidā, viss pārējais bija iekŔā. UzticamÄ«ba bija ļoti zema, man bija jāsaglabā 2-3 programmas kopijas. Ielādes laiki arÄ« bija neapmierinoÅ”i, un entuziasti eksperimentēja ar dažādu frekvenču kodējumu, lai novērstu Å”os trÅ«kumus. Pats tajā laikā vēl nenodarbojos ar profesionālu programmatÅ«ras izstrādi (neskaitot vienkārÅ”as programmas BASIC), tāpēc, diemžēl, sÄ«kāk nestāstÄ«Å”u, kā iekŔā viss bija sakārtots. Pats fakts, ka datoram lielākoties bija tikai operatÄ«vā atmiņa, noteica datu uzglabāŔanas shēmas vienkārŔību.

Uzticamu un lielu datu nesēju parādÄ«Å”anās

Vēlāk parādÄ«jās disketes, tika vienkārÅ”ots kopÄ“Å”anas process un palielinājās uzticamÄ«ba.
Taču situācija krasi mainās tikai tad, kad HDD formātā parādās pietiekami lielas lokālās krātuves.

Piegādes veids bÅ«tiski mainās: parādās instalÄ“Å”anas programmas, kas pārvalda sistēmas konfigurÄ“Å”anas procesu, kā arÄ« tÄ«rÄ«Å”anu pēc noņemÅ”anas, jo programmas ne tikai nolasa atmiņā, bet jau tiek kopētas uz vietējo krātuvi, no kuras jums ir nepiecieÅ”ams nepiecieÅ”amÄ«bas gadÄ«jumā spēt notÄ«rÄ«t nevajadzÄ«gās lietas.

Tajā paŔā laikā pieaug piegādātās programmatūras sarežģītība.
Failu skaits piegādē palielinās no dažiem lÄ«dz simtiem un tÅ«kstoÅ”iem, konflikti starp bibliotēkas versijām un citi prieki sākas, kad dažādas programmas izmanto vienus un tos paÅ”us datus.

Piegādes rÄ«ku attÄ«stÄ«ba vai domas par Docker, deb, jar un citiem Tolaik Linux pastāvÄ“Å”ana man vēl nebija atklāta; es dzÄ«voju MS DOS un vēlāk Windows pasaulē un rakstÄ«ju Borland Pascal un Delphi, dažreiz skatoties uz C++. Daudzi cilvēki toreiz izmantoja InstallShield, lai piegādātu produktus. ru.wikipedia.org/wiki/InstallShield, kas diezgan veiksmÄ«gi atrisināja visus uzdotos programmatÅ«ras izvietoÅ”anas un konfigurÄ“Å”anas uzdevumus.




Interneta laikmets

Pakāpeniski programmatūras sistēmu sarežģītība kļūst vēl sarežģītāka; no monolītajām un darbvirsmas lietojumprogrammām notiek pāreja uz sadalītām sistēmām, plāniem klientiem un mikropakalpojumiem. Tagad jums ir jākonfigurē ne tikai viena programma, bet arī to kopa, lai tās visas darbotos kopā.

Koncepcija pilnÄ«bā mainÄ«jās, nāca internets, pienāca mākoņpakalpojumu laikmets. Pagaidām tikai sākumposmā mājaslapu veidā par servisiem neviens Ä«paÅ”i nav sapņojis. taču tas bija pagrieziena punkts gan lietojumprogrammu izstrādē, gan piegādē.

Pie sevis piefiksēju, ka tajā brÄ«dÄ« notika izstrādātāju paaudžu maiņa (vai tā bija tikai manā vidē), un bija sajÅ«ta, ka visas vecās labās piegādes metodes vienā mirklÄ« aizmirstas un viss sākās no paÅ”a sākuma. sākums: visas piegādes sāka veikt ar ceļa skriptiem un lepni to sauca par "nepārtrauktu piegādi". PatiesÄ«bā ir sācies haosa periods, kad vecais tiek aizmirsts un netiek izmantots, un jaunais vienkārÅ”i neeksistē.

Atceros laikus, kad mÅ«su uzņēmumā, kurā toreiz strādāju (nenosaukÅ”u), tā vietā, lai bÅ«vētu caur skudru (maven vēl nebija populārs vai vispār neeksistēja), cilvēki vienkārÅ”i savāca burkas IDE un mierÄ«gi apņēmās to SVN. AttiecÄ«gi izvietoÅ”ana ietvēra faila izgÅ«Å”anu no SVN un tā kopÄ“Å”anu, izmantojot SSH, vajadzÄ«gajā maŔīnā. Tas ir tik vienkārÅ”i un neveikli.

Tajā paŔā laikā vienkārÅ”u vietņu piegāde PHP tika veikta ļoti primitÄ«vā veidā, vienkārÅ”i kopējot laboto failu, izmantojot FTP, uz mērÄ·a maŔīnu. Dažreiz tas tā nebija - kods tika rediģēts produkta serverÄ«, un tas bija Ä«paÅ”i Å”iki, ja kaut kur bija rezerves kopijas.


RPM un DEB pakotnes

Piegādes rÄ«ku attÄ«stÄ«ba vai domas par Docker, deb, jar un citiemNo otras puses, attÄ«stoties internetam, UNIX lÄ«dzÄ«gas sistēmas sāka iegÅ«t arvien lielāku popularitāti, jo Ä«paÅ”i tajā laikā es atklāju RedHat Linux 6, aptuveni 2000. Protams, bija arÄ« noteikti lÄ«dzekļi programmatÅ«ras piegādei, saskaņā ar Vikipēdiju RPM kā galvenais pakotņu pārvaldnieks parādÄ«jās jau 1995. gadā RedHat Linux 2.0 versijā. Un kopÅ” tā laika un lÄ«dz Å”ai dienai sistēma tiek piegādāta RPM pakotņu veidā un diezgan veiksmÄ«gi pastāv un attÄ«stās.

Debian saimes izplatÄ«Å”ana gāja lÄ«dzÄ«gu ceļu un ieviesa piegādi deb pakotņu veidā, kas ir palikusi nemainÄ«ga lÄ«dz mÅ«sdienām.

PakeÅ”u pārvaldnieki ļauj piegādāt paÅ”us programmatÅ«ras produktus, konfigurēt tos instalÄ“Å”anas procesa laikā, pārvaldÄ«t atkarÄ«bas starp dažādām pakotnēm, noņemt produktus un iztÄ«rÄ«t nevajadzÄ«gos vienumus atinstalÄ“Å”anas procesa laikā. Tie. lielākoties tas ir viss, kas vajadzÄ«gs, tāpēc tie praktiski nemainÄ«jās vairākus gadu desmitus.

MākoņdatoÅ”ana pakotņu pārvaldniekiem ir pievienojusi instalÄ“Å”anu ne tikai no fiziskajiem datu nesējiem, bet arÄ« no mākoņu krātuvēm, taču bÅ«tiski maz ir mainÄ«jies.

Ir vērts atzÄ«mēt, ka paÅ”laik notiek dažas virzÄ«bas uz atteikÅ”anos no deb un pāreju uz snap pakotnēm, bet par to vēlāk.

Tātad Ŕī jaunā mākoņu izstrādātāju paaudze, kas nezināja ne DEB, ne RPM, arÄ« lēnām auga, ieguva pieredzi, produkti kļuva sarežģītāki un bija vajadzÄ«gas dažas saprātÄ«gākas piegādes metodes nekā FTP, bash skripti un lÄ«dzÄ«gas studentu amatniecÄ«bas.
Un Å”eit parādās Docker, sava veida virtualizācijas, resursu norobežoÅ”anas un piegādes metodes sajaukums. Tagad tas ir modē un jauneklÄ«gi, bet vai tas ir vajadzÄ«gs visam? Vai Ŕī ir panaceja?

Pēc maniem novērojumiem, ļoti bieži Docker tiek piedāvāts nevis kā saprātÄ«ga izvēle, bet vienkārÅ”i tāpēc, ka, no vienas puses, sabiedrÄ«bā par to runā, un tie, kas to ierosina, to tikai zina. Savukārt par vecajām labajām iepakoÅ”anas sistēmām lielākoties klusē - tās eksistē un savu darbu dara klusi un nemanot. Šādā situācijā citas izvēles Ä«sti nav ā€“ izvēle ir acÄ«mredzama ā€“ Docker.

Es mēģināŔu dalÄ«ties savā pieredzē par to, kā mēs ieviesām Docker un kas notika tā rezultātā.


PaŔu rakstīti skripti

Sākotnēji bija bash skripti, kas izvietoja jar arhÄ«vus vajadzÄ«gajās iekārtās. Å o procesu vadÄ«ja Dženkinss. Tas darbojās veiksmÄ«gi, jo pats jar arhÄ«vs jau ir komplekts, kas satur klases, resursus un pat konfigurāciju. Ja tajā visu ievietojat maksimāli, tad izvērst to skriptā nav grÅ«tākais, kas jums nepiecieÅ”ams

Taču skriptiem ir vairāki trūkumi:

  • skripti parasti tiek rakstÄ«ti steigā un tāpēc ir tik primitÄ«vi, ka satur tikai vienu labāko scenāriju. To veicina fakts, ka izstrādātāju interesē ātra piegāde, un parastam skriptam ir jāiegulda pienācÄ«gs resursu apjoms.
  • IepriekŔējā punkta rezultātā skripti nesatur atinstalÄ“Å”anas procedÅ«ras
  • nav noteiktas jaunināŔanas procedÅ«ras
  • Kad parādās jauns produkts, jums ir jāraksta jauns skripts
  • nav atkarÄ«bas atbalsta

Protams, jÅ«s varat uzrakstÄ«t sarežģītu skriptu, taču, kā jau rakstÄ«ju iepriekÅ”, Å”is ir izstrādes laiks, un tas nav mazākais, un, kā mēs zinām, laika vienmēr nepietiek.

Tas viss acÄ«mredzami ierobežo Ŕīs izvietoÅ”anas metodes pielietojumu tikai visvienkārŔākajās sistēmās. Ir pienācis laiks to mainÄ«t.


dokers

Piegādes rÄ«ku attÄ«stÄ«ba vai domas par Docker, deb, jar un citiemKādā brÄ«dÄ« pie mums sāka nākt svaigi kaltas vidus, kas kÅ«sā ar idejām un trakoja par dokeru. Nu karogs rokā ā€“ darÄ«sim! Bija divi mēģinājumi. Abi bija neveiksmÄ«gi ā€“ teiksim, lielu ambÄ«ciju, bet reālas pieredzes trÅ«kuma dēļ. Vai tas bija jāpiespiež un jāpabeidz ar jebkādiem lÄ«dzekļiem? Tas ir maz ticams ā€” komandai ir jāattÄ«stās lÄ«dz vajadzÄ«gajam lÄ«menim, lai tā varētu izmantot atbilstoÅ”os rÄ«kus. Turklāt, izmantojot gatavus Docker attēlus, mēs bieži saskārāmies ar faktu, ka tÄ«kls nedarbojās pareizi (kas, iespējams, ir saistÄ«ts ar paÅ”a Docker mitrumu) vai arÄ« bija grÅ«ti paplaÅ”ināt citu cilvēku konteinerus.

Ar kādām neērtībām mēs saskārāmies?

  • TÄ«kla problēmas tilta režīmā
  • Ir neērti skatÄ«t žurnālus konteinerā (ja tie nav glabāti atseviŔķi saimniekdatora failu sistēmā)
  • ElasticSearch ik pa laikam dÄ«vaini sasalst konteinera iekÅ”pusē, iemesls nav noskaidrots, konteiners ir oficiāls
  • Tvertnē ir jāizmanto apvalks - viss ir ļoti notÄ«rÄ«ts, nav pazÄ«stamu rÄ«ku
  • Liela izmēra savāktie konteineri - dārgi uzglabāt
  • Tā kā konteineri ir lieli, ir grÅ«ti atbalstÄ«t vairākas versijas
  • Ilgāks izveides laiks atŔķirÄ«bā no citām metodēm (skripti vai deb pakotnes)

No otras puses, kāpēc ir sliktāk izvietot Pavasara pakalpojumu burku arhÄ«va veidā, izmantojot to paÅ”u deb? Vai resursu izolācija tieŔām ir nepiecieÅ”ama? Vai ir vērts pazaudēt ērtus operētājsistēmas rÄ«kus, ievietojot pakalpojumu ievērojami samazinātā konteinerā?

Kā liecina prakse, patiesībā tas nav nepiecieŔams, deb pakete ir pietiekama 90% gadījumu.

Kad vecais labais deb neizdodas un kad mums patieŔām ir nepiecieŔams docker?

Mums tā bija pakalpojumu izvietoÅ”ana python. Daudzas bibliotēkas, kas bija nepiecieÅ”amas maŔīnmācÄ«bai un nebija iekļautas operētājsistēmas standarta izplatÄ«Å”anā (un kas tur bija nepareizās versijas), uzlauÅ”ana ar iestatÄ«jumiem, nepiecieÅ”amÄ«ba pēc dažādām versijām dažādiem pakalpojumiem, kas dzÄ«vo vienā un tajā paŔā resursdatora sistēmā, noveda pie tas, ka vienÄ«gais saprātÄ«gais veids, kā piegādāt Å”o kodolmaisÄ«jumu, bija dokeris. Dokera konteinera montāžas darbietilpÄ«ba izrādÄ«jās mazāka nekā ideja to visu iesaiņot atseviŔķās deb pakās ar atkarÄ«bām, un patiesÄ«bā neviens pie pilna prāta to neuzņemtos.

Otrs punkts, kur plānots izmantot Docker, ir pakalpojumu izvietoÅ”ana pēc zili zaļās izvietoÅ”anas shēmas. Bet Å”eit es vēlos pakāpeniski palielināt sarežģītÄ«bu: vispirms tiek veidotas deb pakotnes, un pēc tam no tām tiek izveidots dokera konteiners.


Snap pakas

Piegādes rÄ«ku attÄ«stÄ«ba vai domas par Docker, deb, jar un citiem AtgriezÄ«simies pie snap pakām. Tie pirmo reizi oficiāli parādÄ«jās Ubuntu versijā 16.04. AtŔķirÄ«bā no parastajām deb pakotnēm un rpm pakotnēm, snap ir visas atkarÄ«bas. No vienas puses, tas ļauj izvairÄ«ties no bibliotēku konfliktiem, no otras puses, iegÅ«tā pakotne ir lielāka izmēra. Turklāt tas var ietekmēt arÄ« sistēmas droŔību: snap piegādes gadÄ«jumā visas izmaiņas iekļautajās bibliotēkās ir jāuzrauga izstrādātājam, kurÅ” izveido pakotni. Kopumā ne viss ir tik vienkārÅ”i un universāla laime nerodas no to izmantoÅ”anas. Bet tomēr Ŕī ir pilnÄ«gi saprātÄ«ga alternatÄ«va, ja to paÅ”u Docker izmanto tikai kā iepakoÅ”anas rÄ«ku, nevis virtualizācijai.



Rezultātā tagad mēs izmantojam gan deb pakotnes, gan docker konteinerus saprātīgā kombinācijā, ko, iespējams, dažos gadījumos aizstāsim ar snap pakotnēm.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Ko jūs izmantojat piegādei?

  • PaÅ”u rakstÄ«ti skripti

  • Kopējiet manuāli uz FTP

  • deb paketes

  • rpm paketes

  • snap pakas

  • Docker-attēli

  • Virtuālās maŔīnas attēli

  • Klonējiet visu HDD

  • marionete

  • ansible

  • Cits

Nobalsoja 109 lietotāji. 32 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru