Një herë vendosa të shkruaj një artikull në lidhje me shpërndarjen përmes kontejnerëve Docker dhe paketave deb, por kur fillova, ndjeva se më shpuri në kohë të largëta të kompjuterëve të parë personalë dhe madje kalkulatorëve. Në vend të krahasimeve të thata midis Docker dhe deb, më dolën këto reflektime mbi temën e evolucionit, të cilat po ju paraqes.
Ădo produkt, çfarĂ«do qĂ« tĂ« jetĂ«, duhet nĂ« njĂ« mĂ«nyrĂ« tĂ« arrijĂ« nĂ« serverat produktivĂ«, duhet tĂ« konfigurohet dhe tĂ« niset. Ky Ă«shtĂ« subjekti i kĂ«tij artikulli.
UnĂ« do tĂ« reflektoj nĂ« njĂ« kontekst historik, "çfarĂ« shoh â pĂ«r atĂ« kĂ«ndoj", çfarĂ« kam parĂ« kur fillova tĂ« shkruaj kod dhe çfarĂ« vĂ«zhgoj tani, çfarĂ« ne vetĂ« po pĂ«rdorim aktualisht dhe pse. Artikulli nuk pretendon tĂ« jetĂ« njĂ« hulumtim i plotĂ«, disa pika janĂ« lĂ«nĂ« jashtĂ«, ky Ă«shtĂ« kĂ«ndvĂ«shtrimi im personal mbi atĂ« qĂ« ishte dhe çfarĂ« Ă«shtĂ« tani.
Pra, nĂ« vitet e vjetra tĂ« mira... mĂ«nyra mĂ« e hershme e shpĂ«rndarjes, qĂ« unĂ« pĂ«rjetova â ishin kasetat e tapeve. Kishin njĂ« kompjuter BK-0010.01...
Epoka e kalkulatorëve
Jo, kishte edhe një moment më të hershëm, kishte kalkulatorin dhe .
I remember when I had , the way to transfer the program was a regular grid paper, on which the program was written. To launch it manually when needed, one would write it down into the calculator. Want to play (yes, yes, even on this ancient calculator there were games) â you sit down and enter the program into the calculator. Naturally, when the calculator was turned off, the program would vanish into oblivion. Besides the codes written by hand on paper, programs were published in magazines like 'Radio' and 'Youth Technique', as well as printed in books of that era.
The next modification was the calculator , which already featured some sort of non-volatile memory. Now, the game or program didnât have to be entered manually; after performing some magical button sequences, it would load itself.
The largest program size in the calculator was 105 steps, and the constant memory size in the MK-52 was 512 steps.
NĂ« fakt, nĂ«se ka pasionarĂ« tĂ« kĂ«tyre kalkulatorĂ«ve qĂ« lexojnĂ« kĂ«tĂ« artikull â gjatĂ« shkrimit tĂ« artikullit, gjeta dhe njĂ« emulator kalkulatori pĂ«r Android, si dhe programe pĂ«r tĂ«. ShkĂ«mbehu nĂ« tĂ« kaluarĂ«n!
Një shpjegim i vogël për MK-52 (nga Wikipedia)
MK-52 fluturonte në hapësirë me anijen 'Soyuz TM-7'. Ai ishte parashikuar të përdorej për llogaritjen e trajektoreve të uljes nëse kompjuteri i bordit dështonte.
MK-52 me bllokun e zgjerimit të memories 'Elektronika-Astro' u dërgua në anijet e Marinës nga viti 1988, si pjesë e kompleksit të llogaritjeve të ndihmës për navigacionin.
Kompjuterët personalë të parë
Le të kthehemi në kohët . Natyrisht, që po pati më shumë memorie dhe ishte krejtësisht e pamundur të shkruaje kod nga një letër (ndonëse për fillimin e kohës unë e bëja këtë, sepse nuk kishte asgjë tjetër për ruajtje). Skuadrat kryesore për ruajtjen dhe shpërndarjen e softuerit bënë kasetat audio për magnetofonët.
Ruajtja në kasetë zakonisht ishte në formën e një ose dy skedarëve binarë, gjithë e tjera ishte brenda. Besueshmëria ishte shumë e ulët, duhej të mbaje 2-3 kopje të programit. Koha e ngarkimit gjithashtu nuk ishte e kënaqshme, entuziastët e eksperimentonin me kodimin e ndryshëm të frekuencave për të luftuar këto mangësi. Unë vetë në atë kohë nuk merresha ende me zhvillimin profesional të softuerit (përveç disa programeve të thjeshta në BASIC), prandaj për fat të keq nuk mund të tregoj në detaje se si ishte e gjithë kjo brenda. Fakti që në kompjuter kishte vetëm RAM në masë të madhe përcaktonte thjeshtësinë e skemës së ruajtjes së të dhënave.
Shfaqja e mediave të informacionit të besueshme dhe të mëdha
Më vonë shfaqen disketat, procesi i kopjimit bëhet më i thjeshtë, besueshmëria rritet.
Por situata ndryshon rrënjësisht vetëm kur shfaqen ruajtjet lokale mjaft të mëdha në formën e HDD.
Ndryshon themelisht tipi i shpërndarjes: shfaqen programet-instaluese që menaxhojnë procesin e konfigurimit të sistemit dhe gjithashtu pastrimin pas fshirjes, pasi programet nuk thjesht lexohen në kujtesë, por kopjohen në ruajtjen lokale, nga e cila duhet të jemi në gjendje të pastroni atë që nuk nevojitet kur është e nevojshme.
Paralelisht, rritet kompleksiteti i softuerit të dorëzuar.
Numri i skedave në dorëzim rritet nga një në qindra dhe mijëra, fillojnë konfliktet e versioneve të bibliotekave dhe gëzimet e tjera, kur programet e ndryshme përdorin të njëjtat të dhëna.
Në ato kohë, për mua nuk kishte ende hapur ekzistencën e Linux-it, jetoja në botën e MS DOS dhe, më vonë, Windows, duke shkruar në Borland Pascal dhe Delphi, ndonjëherë duke shikuar në drejtim të C++. Për shpërndarjen e produkteve në ato kohë, shumë përdornin InstallShield , i cili zgjidhte me sukses të gjitha detyrat e vendosura të shpërndarjes dhe konfigurimit të softuerit.
Epoka e internetit
Gradualisht, kompleksiteti i sistemeve softuerike po rritet, nga monolitët dhe aplikacionet desktop, po kalojmë në sisteme të shpërndara, klientë të hollë dhe mikroshërbime. Tani duhet të konfigurojmë jo një program të vetëm, por një grup të tyre, duke siguruar që ato të funksionojnë së bashku.
Koncepti është ndërruar plotësisht, ka ardhur Interneti, dhe ka filluar epoka e shërbimeve në re. Në atë kohë, ende ishim në fazën fillestare, në formën e faqeve, askush nuk ëndërronte për shërbime të tilla. Por ky ishte një moment kyç në industri, si për zhvillimin, ashtu edhe për shpërndarjen e aplikacioneve.
Kam vënë re se në atë moment ndodhi një ndërrim gjeneratash zhvilluesish (ose ishte vetëm në mjedisin tim), dhe krijohej ndjenja se të gjithë metodat e vjetra të shpërndarjes ishin harruar në një moment, dhe gjithçka filloi nga e para: e gjithë shpërndarja bëhej përmes skripteve të improvizuara dhe e quajtën me krenari "Continuous delivery". Në fakt filloi një periudhë ngatërrese, kur e kaluara ishte e harruar dhe e reja thjesht nuk ekzistonte.
E mbaj mend kohët kur në kompaninë ku punoja (nuk do ta përmend emrin), në vend që të bënim ndërtimin përmes ant (maven ende nuk ishte popullor ose nuk ekzistonte fare), njerëzit thjesht ndanin jar në IDE dhe e komitonin pa u shqetësuar në SVN. Si rezultat, implementimi përfshinte marrjen e skedarit nga SVN dhe kopjimin e tij përmes SSH në makinerinë e duhur. Kaq thjeshtë dhe meskinisht.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, ofrimi i faqeve tĂ« thjeshta nĂ« PHP bĂ«hej njĂ« mĂ«nyrĂ« krejtĂ«sisht primitive duke kopjuar thjesht skedarin e rregulluar pĂ«rmes FTP nĂ« makinerinĂ« e synuar. NdonjĂ«herĂ« nuk kishte asgjĂ« tĂ« tillĂ« â kodi dukej nĂ« jetĂ«n reale nĂ« serverin produktiv, dhe ishte shumĂ« e veçantĂ« nĂ«se kishte ndonjĂ« rezervĂ« diku.
RPM- dhe DEB-pakete
Nga ana tjetër, me zhvillimin e internetit, sistemet UNIX-like filluan të fitonin popullaritet gjithnjë e më shumë, sidomos në atë kohë për vete zbulova RedHat Linux 6, rreth vitit 2000. Sigurisht, ato kishin disa mjete për shpërndarjen e softuerit; sipas Wikipedias, RPM si menaxheri kryesor i pakove u shfaq në 1995, në versionin RedHat Linux 2.0. Dhe nga ajo kohë e deri në ditët e sotme, sistemi ofrohet në formën e pakove RPM dhe ekziston e zhvillohet me sukses.
Distribucioni i familjes Debian ndoqi një rrugë të ngjashme dhe realizoi shpërndarjen në formën e paketave deb, që është gjithashtu e pandryshuar deri në ditët tona.
Menaxherët e paketave lejojnë shpërndarjen e produkteve programore, konfigurimin e tyre gjatë instalimit, menaxhimin e varësive midis paketave të ndryshme, si dhe heqjen e produkteve dhe pastrimin e tepricave gjatë deinstalimit. Pra, në thelb, këto janë të gjitha që duhen, për këtë arsye ato kanë qëndruar pothuajse pa ndryshime për disa dekada.
Baza e cloud-it ka sjellë në menaxherët e paketave instalimin jo vetëm nga mbajtësit fizikë, por edhe nga depozitat cloud, megjithatë, ndryshe pak ka ndryshuar.
Duket se aktualisht ka disa përpjekje për të shmangur deb dhe për të kaluar në paketat snap, por për këtë më vonë.
Kështu, kjo brezi i ri i zhvilluesve cloud, të cilët nuk e dinin as DEB as RPM, gjithashtu po rritej ngadalë, duke fituar përvojë, produktet bëheshin më të ndërlikuara, dhe ishin të nevojshme disa mënyra më të arsyeshme të shpërndarjes, përveç FTP, skenarëve bash dhe prodhimeve të tjera të ngjashme studentore.
Dhe këtu në skenë del Docker, një përzierje e virtualizimit, ndarjes së burimeve dhe metodës së shpërndarjes. Tani është e njohur, rinore, por a është nevoja për të në çdo rast? A është kjo një panacee?
Nga vĂ«zhgimet e mia, shumĂ« shpesh Docker ofrohet jo si njĂ« zgjedhje tĂ« 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 kryesisht nuk flitet â ato ekzistojnĂ« dhe bĂ«nĂ« punĂ«n e tyre nĂ« heshtje dhe pa u vĂ«nĂ« re. NĂ« njĂ« situatĂ« tĂ« tillĂ«, nuk ka shumĂ« zgjedhje â zgjedhja Ă«shtĂ« e qartĂ« â Docker.
Do të provoj të ndaj përvojën time, se si u implementua Docker te ne, dhe çfarë rezultati arritëm.
Skemat e shkruara vetë
Fillimisht kishim skripte bash, tĂ« cilat e shpĂ«rndanin arkivĂ«n jar nĂ« makinat e nevojshme. Jenkins menaxhonte kĂ«tĂ« proces. Kjo funksiononte me sukses, mirĂ«qenia e vet arkivĂ«s jar Ă«shtĂ« njĂ« ndĂ«rtim qĂ« pĂ«rmban klasat, burimet dhe madje edhe konfigurimin. NĂ«se e mbledhim gjithçka nĂ« maksimum â qĂ« ta shpĂ«rndajmĂ« atĂ« me skript â kjo nuk Ă«shtĂ« gjĂ« e vĂ«shtirĂ«.
Por skriptet kanë disa disavantazhe:
- Scriptet zakonisht shkruhen në një mënyrë të shpejtë dhe për këtë arsye janë kaq primitivë, sa që përmbajnë vetëm një skenar të suksesshëm. Kjo ndihmohet nga fakti që zhvilluesi është i interesuar për dërgimin sa më të shpejtë, ndërsa një skript normal kërkon investim të një sasi të konsiderueshme burimesh.
- Si pasojë e pikës së mëparshme, skriptet nuk përmbajnë procedurë çinstalimi.
- Nuk ka një procedurë të vendosur për përditësim.
- Meqenëse 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 më të avancuar, por, siç kam përmendur më parë, kjo është një kohë zhvillimi, madje jo e vogël, dhe siç dihet, koha gjithmonë mungon.
Kjo padyshim kufizon përdorimin e këtij mënyre të shpërndarjes vetëm për sistemi më të thjeshta. Ka ardhur koha për ta ndryshuar këtë.
Docker
NĂ« njĂ« moment, filluan tĂ« na vijnĂ« midlat e sapobĂ«rĂ«, tĂ« mbushur me ide dhe tĂ« pasionuar pas Docker-it. ĂfarĂ« tĂ« themi, flamuri nĂ« dorĂ« â le tĂ« bĂ«jmĂ«! BĂ«mĂ« dy pĂ«rpjekje. TĂ« dyja dĂ«shtuan â thĂ«nĂ« ndryshe, pĂ«r shkak tĂ« ambicieve tĂ« mĂ«dha, por njĂ« mungese pĂ«rvoje reale. A duhej tĂ« nxitojmĂ« dhe tĂ« pĂ«rfundojmĂ« me çdo mĂ«nyrĂ«? VĂ«shtirĂ« â kolektivi duhet tĂ« evoluojĂ« nĂ« nivelin e nevojshĂ«m, pĂ«rpara se tĂ« mund tĂ« pĂ«rdorĂ« mjetet pĂ«rkatĂ«se. Prandaj, duke pĂ«rdorur imazhe tĂ« gatshme Docker, shpesh u ndeshĂ«m me probleme nĂ« rrjet (diçka qĂ« ndoshta kishte tĂ« bĂ«nte edhe me papjekurinĂ« e Docker-it vetĂ«) ose ishte e vĂ«shtirĂ« tĂ« zgjeroje konteinerĂ«t e tjerĂ«.
Me cilat shqetësime u ndeshëm?
- Probleme në rrjetin në modalitetin bridge
- Nuk është e lehtë të shikosh log-et në konteiner (nëse ato nuk janë nxjerrë diku veçmas në sistemin e skedarëve të makinës host)
- Herë pas here, ngadalësim i çuditshëm ElasticSearch brenda konteinerit, arsyet nuk u zbuluan, konteineri është zyrtar
- E vĂ«shtirĂ« tĂ« pĂ«rdorĂ«sh shell-in brenda konteinerit â gjithçka Ă«shtĂ« shumĂ« e kufizuar, nuk ka mjetet e njohura
- Masa tĂ« mĂ«dha tĂ« konteinerĂ«ve tĂ« ndĂ«rtuar â kushton shtrenjtĂ« pĂ«r t'i ruajtur
- Për shkak të madhësisë së madhe të kontejnerëve, është e vështirë të mbahet më shumë se një version.
- Ndërtime më të gjata, ndryshe nga metodat e tjera (skriptet ose paketat deb).
Nga ana tjetër, a është vërtet më keq të deploy-osh një shërbim Spring si një arkiv jar përmes të njëjtës deb? A është e nevojshme izolimi i burimeve? A vlen të humbasim mjetet komode të sistemit operativ duke vendosur shërbimin në një kontejner të shumë kufizuar?
Siç e tregoi praktika â nĂ« realitet, kjo nuk Ă«shtĂ« e nevojshme, paketa deb mjafton nĂ« 90% tĂ« rasteve.
Kur në fakt paketa e vjetër deb nuk funksionon dhe kur vërtet na nevojitet Docker?
Për ne, kjo ishte implementimi i shërbimeve në python. Një sërë bibliotekash të nevojshme për mësimin e makinerisë, që mungonin në paketimin standard të sistemit operativ (dhe ato që ishin, nuk ishin versione të duhura), hile me konfigurimet, nevoja për versione të ndryshme për shërbime të ndryshme që përjetonin në të njëjtën sistem pritës, çuan në përfundimin se mënyra e vetme logjike për të shpërndarë këtë përzierje thelbësore ishte docker. Punën për ndërtimin e kontejnerit docker doli të ishte më e lehtë se ideja për të paketuar të gjithë këtë në paketa deb të ndara me varësi, për më tepër, askush në mendje të shëndoshë nuk do ta merrte përsipër këtë.
Momenti i dytĂ«, ku planifikohet tĂ« pĂ«rdoret docker â pĂ«r shpĂ«rndarjen e shĂ«rbimeve sipas skemĂ«s blue-green deploy. Por kĂ«tu do tĂ« dĂ«shironim tĂ« merrnim njĂ« rritje graduale tĂ« kompleksitetit: fillimisht mblidhen paketat deb, dhe pastaj, nga ato, ndĂ«rtohet kontejneri docker.
Paketat Snap
Le të kthehemi te paketat snap. Ato u shfaqën zyrtarisht për herë të parë në Ubuntu 16.04. Ndryshe nga paketat deb dhe rpm, snap përmbajnë të gjitha varësitë e nevojshme. Nga njëra anë, kjo ndihmon për të shmangur konflikte bibliotekash, ndërsa nga ana tjetër, përkthimi rezultues ka dimensione më të mëdha. Për më tepër, kjo mund të ndikojë në sigurinë e sistemit: në rastin e shpërndarjes së snap, zhvilluesi që krijon paketën duhet të mbajë nën vëzhgim të gjitha ndryshimet e bibliotekave të përfshira. Në përgjithësi, situata nuk është kaq e thjeshtë dhe gëzimi i përgjithshëm nga përdorimi i tyre nuk ndodh. Megjithatë, kjo është një alternativë mjaft e arsyeshme nëse Docker përdoret vetëm si një mjet paketimi dhe jo virtualizimi.
Si përfundim, tani kemi një kombinim të arsyeshëm që përdor si paketat deb ashtu edhe enët Docker, të cilat, ndoshta, në raste të caktuara do t'i zëvendësojmë me paketat snap.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
ĂfarĂ« pĂ«rdorni pĂ«r shpĂ«rndarje?
Skemat e shkruara vetë
Kopjojmë manualisht në FTP
paketat deb
paketat rpm
paketat snap
imazhe Docker
imazhe të makinave virtuale
Klonojmë të gjithë HDD-në
puppet
ansible
TĂ« tjera
109 përdorues votuan. 32 përdorues abstenuan.
Burimi: habr.com
