Njëherë, vendosa të shkruaj një artikull rreth shpërndarjes në formën e kontejnerëve Docker dhe paketave deb, por kur fillova, më ndoqi një mendim për kohët e para të kompjuterëve personalë dhe madje kalkulatorëve. Në përgjithësi, në vend të krahasimeve të thata ndërmjet Docker-it dhe deb, rezultuan këto reflektime mbi evolucionin, të cilat i paraqes për gjykimin tuaj.
Ădo produkt, çfarĂ«do qoftĂ«, duhet nĂ« njĂ«farĂ« mĂ«nyre tĂ« arrijĂ« nĂ« serverĂ«t produktivĂ«, duhet tĂ« konfigurohet dhe tĂ« nisĂ«. Ky do tĂ« jetĂ« subjekti i kĂ«tij artikulli.
Do të reflektoj në kontekstin historik, "çfarë shoh - atë këndoj", çfarë kam parë kur fillova të shkruaj kod dhe çfarë vërej sot, se çfarë përdorim aktualisht dhe pse. Artikulli nuk pretendon për një hulumtim të plotë, disa momente janë lënë jasht, ky është qëndrimi im personal mbi atë që ka qenë dhe atë që është tani.
Pra, në kohët e vjetra të mira... mënyra më e hershme e shpërndarjes, që kam përjetuar - ishin kasetat e magnetofonëve. Kisha një kompjuter BK-0010.01...
Epoka e kalkulatorëve
Jo, kishte një moment edhe më të hershëm, ishte kalkulatori dhe .
Pra, kur kisha , mënyra e transfertës së programit ishte një copë letër me katrorë, mbi të cilën ishte shkruar programi, i cili në rast nevoje është regjistruar manualisht në kalkulator. Dëshiron të luash (po, po, në këtë kalkulator të vjetër kishte lojëra) - ulesh dhe shkruan programin në kalkulator. Natyrisht, kur kalkulatori fiket, programi humbiste. Përveç kodeve të shkruara me dorë në letër, programet publikoheshin në revista si "Radio" dhe "Teknika e rinisë", si dhe printoheshin në librat e asaj kohe.
Modifikimi tjetër ishte kalkulatori , tashmë kishte një farë forme të ruajtjes së të dhënave që nuk varen nga energjia. Tani nuk ishte më e nevojshme të shkruaje manualisht lojën ose programin, por, duke bërë disa lëvizje magjike me butona, ai niste vetvetiu.
Vëllimi i programit më të madh në kalkulator ishte 105 hapat, ndërsa madhësia e memories së përhershme në MK-52 ishte 512 hapat.
Tani, nëse ka adhurues të këtyre kalkulatorëve që po e lexojnë këtë artikull - gjatë shkrimit të këtij artikulli kam gjetur një emulator kalkulatori për android dhe programe për të. Përpara, në të kaluarën!
Një prapashtesë e vogël mbi MK-52 (nga Wikipedia)
MK-52 fluturoi në hapësirë me anijen 'Soyuz TM-7'. Kishte për qëllim të përdorej për llogaritjen e rrugës së uljes në rast se kompjuteri bord i avioni dështon.
MK-52 me bllokun e zgjerimit të memories 'Elektronika-Astro' nga viti 1988 u dorëzua në anijet e Marinës si pjesë e komplekseve të llogaritjes së navigatorit.
Kompjuterët e parë personalë
Le të kthehemi në kohët . E qartë, se edhe memoria u rrit, dhe të shkruaje kod me dorë nga një letër nuk ishte më një mundësi (pavarësisht se për një kohë të shkurtër e bëra pikërisht kështu, pasi nuk kishte ndonjë mbajtës tjetër). Mjeti kryesor për ruajtjen dhe furnizimin e softuerit u bënë kasetat audio për magnetofonë.
Ruajtja në kasetë zakonisht ishte në formën e një ose dy skedarëve binarë, të gjitha gjërat e tjera ishin të përfshira brenda. Besueshmëria ishte shumë e ulët, duhej të mbaje 2-3 kopje të programit. Koha e ngarkimit gjithashtu nuk ishte e këndshme, entuziastët eksperimentonin me kodimin e ndryshëm të frekuencës për të luftuar këto të meta. Unë vetë atë kohë nuk merresha me zhvillimin profesional të softuerit (përveç disa programeve të thjeshta në BASIC), prandaj, fatkeqësisht, nuk mund të tregoj në detaje se si ishin të rregulluara brenda. Fakti që kompjuteri kishte kryesisht vetëm RAM përcaktonte thjeshtësinë e skemës së ruajtjes së të dhënave.
Shfaqja e mbajtësve të informacionit të besueshëm dhe të mëdhenj
Më vonë u shfaqën disketa, procesi i kopjimit u thjeshtua, besueshmëria u rrit.
Por situata ndryshon radikalisht, vetëm kur shfaqen hapësira të mjaftueshme lokale si HDD.
Lloji i dorëzimit ndryshon thelbësisht: shfaqen programet-instaluese, të cilat menaxhojnë procesin e konfigurimit të sistemit, si dhe pastrimin pas fshirjes, pasi programet nuk thjesht lexohen në memorie, por gjithashtu kopjohen në mbajtjen lokale, nga e cila duhet të dimë dhe të pastrojmë të panevojshmet kur është e nevojshme.
Paralelisht, kompleksiteti i softuerit të dorëzuar rritet.
Numri i skedarëve në dorëzim rritet nga disa në qindra dhe mijëra, fillojnë konfliktet e versioneve të bibliotekave dhe këto gëzime të tjera, kur programe të ndryshme përdorin të njëjtat të dhëna.
Në ato kohë, për mua nuk ishte ende e njohur ekzistenca e Linux-it, unë jetova në botën e MS DOS-it dhe, më vonë, Windows-it, dhe shkruaja në Borland Pascal dhe Delphi, duke hedhur ndonjëherë një sy në C++. Për shpërndarjen e produkteve në ato kohë, shumë përdornin InstallShield , e cila zgjidhte me sukses të gjitha detyrat e vendosura për shpërndarjen dhe konfigurimin e softuerit.
Epoka e internetit
Gradualisht, kompleksiteti i sistemeve të softuerit po bëhet edhe më i ndërlikuar, duke kaluar nga monolitët dhe aplikacionet desktop në sisteme të shpërndara, klienët e hollë dhe mikroshërbimet. Tani duhet të konfigurohet jo vetëm një program, por një grup i tyre, në mënyrë që të bashkëpunojnë të gjithë së bashku.
Koncepti u ndryshua plotësisht, erdhi Interneti, filloi epoka e shërbimeve në re. Ende në fazën fillestare, në formën e faqeve, askush nuk ëndërronte shumë për shërbime, por kjo ishte një moment kyç në industrinë e zhvillimit si dhe të shpërndarjes së aplikacioneve.
PĂ«r veten time kam vĂ«rejtur se gjatĂ« kĂ«saj periudhe ndodhi njĂ« ndĂ«rrim i brezave tĂ« zhvilluesve (ose ndoshta vetĂ«m nĂ« mjedisin tim), dhe kishte njĂ« ndjesi se tĂ« gjitha metodat e vjetra tĂ« shpĂ«rndarjes ishin harruar nĂ« njĂ« moment dhe gjithçka filloi nga fillimi: tĂ« gjithĂ« shpĂ«rndarja filloi tĂ« bĂ«hej me skripte tĂ« improvizuara dhe u quajt me krenari âContinuous deliveryâ. NĂ« fakt, filloi njĂ« periudhĂ« kaosi, kur e vjetra ishte harruar dhe nuk pĂ«rdorej, ndĂ«rsa e reja thjesht nuk kishte.
E mbaj mend atëherë kur në kompaninë tonë, ku punoja (nuk do ta përmend emrin), në vend që të bëjnë ndërtimin përmes ant (maven atëherë nuk ishte populare ose nuk kishte fare), njerëzit thjesht ndërtuan jar në IDE dhe pa ndonjë shqetësim e komituan atë në SVN. Për rrjedhojë, shpërndarja përfshinte nxjerrjen e skedarit nga SVN dhe kopjimin e tij përmes SSH në makinën e duhur. Kështu e thjeshtë dhe e parë.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, shpĂ«rndarja e faqeve tĂ« thjeshta nĂ« PHP bĂ«hej nĂ« njĂ« mĂ«nyrĂ« krejtĂ«sisht primitive duke kopjuar dosjen e korrigjuar pĂ«rmes FTP nĂ« makinĂ«n e synuar. NdonjĂ«herĂ« nuk kishte as kaq â kodin e rregullonin drejtpĂ«rdrejt nĂ« serverin produktiv, dhe ishte njĂ« stil veçanĂ«risht i njohur nĂ«se kishte ndonjĂ« backup diku.
RPM- dhe DEB-pakete
Nga ana tjetër, me zhvillimin e internetit, sistemet që i ngjajnë UNIX-it filluan të fitojnë popullaritet gjithnjë e më të madh, sidomos në atë kohë zbulova RedHat Linux 6, rreth vitit 2000. Natyrisht, aty kishin një numër mjetesh për shpërndarjen e softuerit; sipas Wikipedia-s, RPM si menaxheri kryesor i pakove u shfaq në vitin 1995, në versionin RedHat Linux 2.0. Që atëherë deri në ditët tona, sistemi shpërndahet në formën e pakove RPM dhe eksistenca e tij vazhdon të jetë e suksesshme dhe e zhvilluar.
Distribucionet e familjes Debian ndoqën një rrugë të ngjashme dhe realizuan shpërndarjen në formën e pakove deb, e cila gjithashtu mbetet e pandryshuar deri në ditët tona.
Menaxherët e pakove lejojnë shpërndarjen e produkteve softuerike, konfigurimin e tyre gjatë instalimit, menaxhimin e varësive midis paketave të ndryshme, si dhe heqjen e produkteve dhe pastrimin e mbeturinave gjatë deinstalimit. Pra, për pjesën më të madhe, kjo është gjithçka që nevojitet, dhe për këtë arsye, ata janë mbajtur për disa dekada praktikisht pa ndryshime.
Ajo qĂ« quhet âcloudâ ka shtuar nĂ« menaxherĂ«t e pakove instalimin jo vetĂ«m nga mediumet fizike, por edhe nga depozitĂ« cloud, por ndryshe shumĂ« pak ka ndryshuar.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se aktualisht ka disa tendenca pĂ«r tĂ« shmangur deb dhe pĂ«r t'u kaluar nĂ« pako snap, por pĂ«r kĂ«tĂ« mĂ« vonĂ«.
Pra, kjo gjeneratë e re e zhvilluesve cloud, e cila nuk kishte njohuri për DEB dhe RPM, gjithashtu po rritej ngadalë, fitonte përvojë, produktet po bëheshin më komplekse, dhe nevojiteshin disa mënyra më të arsyeshme të shpërndarjes më shumë se FTP, skriptet bash dhe blloqet e ngjashme studentore.
Dhe këtu hyn në skenë Docker, një përzierje e virtualizimit, ndarjes së burimeve dhe mënyrës së shpërndarjes. Tani është në modë, i rinj, por a është e nevojshme për çdo gjë? A është kjo një panacee?
Sipas vĂ«zhgimeve tĂ« mia, shumĂ« shpesh Docker ofrohet jo si njĂ« zgjedhje e arsyeshme, por thjesht sepse pĂ«r tĂ« flitet nĂ« komunitet, dhe ata qĂ« e ofrojnĂ« e njohin vetĂ«m atĂ«. Nga ana tjetĂ«r, pĂ«r sistemet e vjetra tĂ« paketimit, pĂ«r shumicĂ«n e rasteve nuk flitet â ato ekzistojnĂ« dhe bĂ«jnĂ« punĂ«n e tyre qetĂ« dhe pa u vĂ«nĂ« re. NĂ« njĂ« situatĂ« tĂ« tillĂ«, nuk ka shumĂ« zgjedhje â zgjedhja Ă«shtĂ« e dukshme â Docker.
Do përpiqem të ndaj përvojën time se si kaluam në përdorimin e Docker dhe çfarë arritëm si rezultat.
Skripte të shkruara vetë
Fillimisht ishin skriptet bash, qĂ« shpĂ«rndanin arkivat jar nĂ« makinat e nevojshme. Jenkins menaxhonte kĂ«tĂ« proces. Kjo funksiononte me sukses, pasi vetĂ« arkiva jar Ă«shtĂ« njĂ« ndĂ«rtim qĂ« pĂ«rmban klasat, burimet dhe madje edhe konfigurimin. NĂ«se e cakton çdo gjĂ« nĂ« maksimum â ta shpĂ«rndash me skript nuk Ă«shtĂ« gjĂ«ja mĂ« e vĂ«shtirĂ« qĂ« duhet bĂ«rĂ«.
Por skriptet kanë disa disavantazhe:
- skriptet zakonisht shkruhen nxitimthi dhe për këtë arsye janë aq primitive, sa që përmbajnë vetëm skenarin më të favorshëm. Kjo ndihmon nga fakti se zhvilluesi është i interesuar për dorëzimin sa më shpejt, ndryshe nga një skript normal që kërkon investim të konsiderueshëm burimesh.
- si pasojë e pikës së mëparshme, skriptet nuk përmbajnë procedurën e deinstalimit.
- nuk ka procedurë të vendosur për përmirësim.
- kur shfaqet një produkt i ri, duhet të shkruhet një skript i ri.
- nuk ka mbështetje për varësitë.
Sigurisht, mund tĂ« shkruhet njĂ« skript i pĂ«rparuar, por, siç kam shkruar mĂ« lart â kjo kĂ«rkon kohĂ« pĂ«r zhvillim, dhe koha, siç dihet, gjithmonĂ« i mungon.
Të gjitha këto kufizojnë qartë aplikimin e këtij mënyre shpërndarjeje vetëm ndaj sistemeve më të thjeshta. Ka ardhur koha për ta ndryshuar këtë.
Docker
NĂ« njĂ« moment, filluam tĂ« marrim mesatarĂ« tĂ« rinj, tĂ« mbushur me ide dhe tĂ« pasionuar pas Docker-it. ĂfarĂ« tĂ« bĂ«jmĂ«, flamuri nĂ« duar â veprojmĂ«! PatĂ«m dy pĂ«rpjekje. TĂ« dyja dĂ«shtuan â le tĂ« themi pĂ«r shkak tĂ« ambicieve tĂ« mĂ«dha, por mungesĂ«s sĂ« pĂ«rvojĂ«s reale. Duhej tĂ« ishim tĂ« nxitur dhe tĂ« pĂ«rfundojmĂ« me çdo mĂ«nyrĂ«? Padyshim qĂ« jo â ekipi duhet tĂ« evoluojĂ« nĂ« nivelin e duhur para se tĂ« jetĂ« nĂ« gjendje tĂ« pĂ«rdorĂ« instrumentet pĂ«rkatĂ«se. PĂ«r mĂ« tepĂ«r, duke pĂ«rdorur imazhe tĂ« gatshme Docker, shpesh hasnim nĂ« probleme me rrjetin (e cila, ndoshta, lidhej gjithashtu me papjekurinĂ« e vetĂ« Docker-it) ose ishte e vĂ«shtirĂ« tĂ« zgjerojmĂ« kontejnerĂ«t e tĂ« tjerĂ«ve.
Me çfarë problemi u përballëm?
- Probleme me rrjetin në modalitetin bridge.
- E pamundur të shikosh log-et në kontejner (nëse ato nuk janë nxjerrë veçmas në sistemin e skedarëve të makinës pritëse).
- Periodikisht ndodhte një ngrirje e çuditshme e ElasticSearch brenda kontejnerit, por nuk arritëm asnjëherë ta vendosim shkakun, kontejneri ishte zyrtar.
- E vĂ«shtirĂ« tĂ« pĂ«rdorĂ«sh shell-in brenda kontejnerit â çdo gjĂ« Ă«shtĂ« shumĂ« e kufizuar, nuk ka mjete tĂ« njohura.
- MadhĂ«sia e madhe e kontejnerĂ«ve tĂ« mbledhur â e shtrenjtĂ« pĂ«r t'u ruajtur
- Për shkak të madhësisë së madhe të kontejnerëve, është e vështirë të mbahen versione të shumta
- Një ndërtim më i gjatë, ndryshe nga metodat e tjera (skriptet ose paketat deb)
Nga ana tjetër, çfarë është më keq për të vendosur një shërbim Spring në formën e një arkivi jar sesa përmes të njëjtit deb? A është vërtet e nevojshme izolimi i burimeve? A ia vlen të humbasim mjete të dobishme të sistemit operativ duke futur një shërbim në një kontejner shumë të reduktuar?
Siç e ka treguar praktika â nĂ« realitet kjo nuk Ă«shtĂ« e nevojshme, paketa deb mjafton nĂ« 90% tĂ« rasteve.
Kur nuk funksionon mirë e vjetra deb dhe kur realisht na nevojitet Docker?
PĂ«r ne kjo ishte vendosja e shĂ«rbimeve nĂ« python. ShumĂ« biblioteka tĂ« nevojshme pĂ«r mĂ«simin e makinĂ«s dhe tĂ« munguar nĂ« paketimin standard tĂ« sistemit operativ (ndĂ«rsa ato qĂ« ishin â nuk ishin ato versionet) dhe hack-et me konfigurimet, kĂ«rkesa pĂ«r versione tĂ« ndryshme pĂ«r shĂ«rbime tĂ« ndryshme qĂ« jetonin nĂ« tĂ« njĂ«jtĂ«n sistem pritĂ«s, çuan nĂ« pĂ«rfundimin se mĂ«nyra mĂ« e arsyeshme pĂ«r shpĂ«rndarjen e kĂ«saj pĂ«rzierjeje bĂ«rthamore ishte Docker. Puna e ndĂ«rtimit tĂ« kontejnerit Docker doli tĂ« ishte mĂ« e lehtĂ« se idea e paketimit tĂ« gjithçkaje nĂ« paketa tĂ« veçanta deb me varĂ«si, dhe askush nĂ« mendjen e tij tĂ« shĂ«ndoshĂ« nuk do ta merrte pĂ«rsipĂ«r kĂ«tĂ«.
Momenti i dytĂ«, ku planifikohet pĂ«rdorimi i Docker-it â pĂ«r vendosjen e shĂ«rbimeve sipas skemĂ«s blue-green deploy. Por kĂ«tu dĂ«shirojmĂ« tĂ« kemi njĂ« rritje graduale tĂ« kompleksitetit: fillimisht grumbullohen paketat deb dhe pastaj nga to ndĂ«rtohet kontejneri Docker.
Paketat Snap
TĂ« kthehemi tek paketat snap. Ato u shfaqĂ«n pĂ«r herĂ« tĂ« parĂ« zyrtarisht nĂ« Ubuntu 16.04. Ndryshe nga paketat standarde deb dhe rpm, snap pĂ«rmbajnĂ« tĂ« gjitha varĂ«sitĂ«. Nga njĂ«ra anĂ«, kjo shmang konfliktin e bibliotekave, ndĂ«rsa nga ana tjetĂ«r â kjo sjell madhĂ«si mĂ« tĂ« mĂ«dha tĂ« paketĂ«s pĂ«rfundimtare. PĂ«rveç kĂ«saj, kjo mund tĂ« ndikojĂ« nĂ« sigurinĂ« e sistemit: nĂ« rastin e shpĂ«rndarjes sĂ« snap, tĂ« gjitha ndryshimet nĂ« bibliotekat pĂ«rfshira duhet tĂ« mbahen nĂ«n mbikĂ«qyrjen e vet zhvilluesit qĂ« krijon paketĂ«n. NĂ« pĂ«rgjithĂ«si, nuk Ă«shtĂ« gjithçka kaq e drejtpĂ«rdrejtĂ« dhe lumturia e pĂ«rbashkĂ«t nga pĂ«rdorimi i tyre nuk arrin. Por, megjithatĂ«, kjo Ă«shtĂ« njĂ« alternativĂ« e arsyeshme, nĂ«se Docker po pĂ«rdoret vetĂ«m si njĂ« mjet paketimi dhe jo virtualizimi.
Si përfundim, tani kemi një kombinim të arsyeshëm të paketave deb dhe kontejnerëve Docker, të cilat, ndoshta, në disa raste do t'i zëvendësojmë me paketat snap.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
ĂfarĂ« pĂ«rdorni ju pĂ«r shpĂ«rndarjen?
Skripte të shkruara vetë
Kopjojmë manualisht në FTP
paketat deb
paketat rpm
paketat snap
imazhet Docker
Imazhet e makinave virtuale
Klonojmë tërë HDD-në
puppet
ansible
Tjetër
Votuan 109 përdorues. U abstenuan 32 përdorues.
Burimi: habr.com
