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
