Disi në një moment vendosa të shkruaj një artikull në lidhje me dorëzimin në formën e kontejnerëve Docker dhe paketave deb, por kur fillova, për disa arsye u çova përsëri në kohët e largëta të kompjuterëve të parë personalë dhe madje edhe kalkulatorëve. Në përgjithësi, në vend të krahasimeve të thata të docker dhe deb, ne morëm këto mendime për temën e evolucionit, të cilat unë i paraqes për shqyrtim.
Çdo produkt, pavarësisht se çfarë është, duhet të arrijë disi te serverët e produktit, duhet të konfigurohet dhe të lansohet. Kjo është ajo që ky artikull do të jetë rreth.
Unë do të mendoj në një kontekst historik, "ajo që unë shoh është ajo për të cilën këndoj", çfarë pashë kur fillova të shkruaj kodin dhe çfarë vëzhgoj tani, çfarë përdorim ne vetë në këtë moment dhe pse. Artikulli nuk pretendon të jetë një studim i plotë, disa pika mungojnë, ky është këndvështrimi im personal për atë që ishte dhe çfarë është tani.
Pra, në ditët e mira të vjetra... metoda më e hershme e dorëzimit që gjeta ishin kasetat nga magnetofonët. Kam pasur një kompjuter BK-0010.01...
Epoka e kalkulatorëve
Jo, ka pasur një moment edhe më të hershëm, ka pasur edhe një makinë llogaritëse и .
Pra, kur kisha , atëherë mënyra për të transferuar programin ishte një copë letre e zakonshme në një kuti në të cilën ishte shkruar një program, i cili, nëse ishte e nevojshme, për ta ekzekutuar atë me dorë, shkruhej në kalkulator. Nëse doni të luani (po, edhe ky kalkulator paradiluvian kishte lojëra) - uleni dhe futni programin në kalkulator. Natyrisht, kur kalkulatori u fikur, programi u zhduk në harresë. Përveç kodeve të kalkulatorit të shkruar personalisht në letër, programet u botuan në revistat "Radio" dhe "Teknologjia për të rinjtë" dhe u botuan edhe në librat e asaj kohe.
Modifikimi tjetër ishte një kalkulator , tashmë ka një farë ngjashmërie të ruajtjes së të dhënave jo të paqëndrueshme. Tani loja apo programi nuk duhej të futej manualisht, por pasi kishte kryer disa kalime magjike me butonat, ngarkohej vetë.
Madhësia e programit më të madh në kalkulator ishte 105 hapa, dhe madhësia e memories së përhershme në MK-52 ishte 512 hapa.
Nga rruga, nëse ka tifozë të këtyre kalkulatorëve që po lexojnë këtë artikull, në procesin e shkrimit të artikullit gjeta një emulator kalkulator për Android dhe programe për të. Përpara në të kaluarën!
Një digresion i shkurtër rreth MK-52 (nga Wikipedia)
MK-52 fluturoi në hapësirë me anijen kozmike Soyuz TM-7. Ai supozohej të përdorej për të llogaritur trajektoren e uljes në rast se kompjuteri në bord dështonte.
Që nga viti 52, MK-1988 me njësinë e zgjerimit të memories Elektronika-Astro është furnizuar me anijet e Marinës si pjesë e një komplete kompjuterike lundrimi.
Kompjuterët e parë personalë
Le të kthehemi në kohë . Është e qartë se kishte më shumë memorie atje, dhe shtypja e kodit nga një copë letër nuk ishte më një opsion (edhe pse në fillim bëra pikërisht këtë, sepse thjesht nuk kishte asnjë mjet tjetër). Kasetat audio për magnetofon po bëhen mjetet kryesore të ruajtjes dhe shpërndarjes së softuerit.
Ruajtja në një kasetë ishte zakonisht në formën e një ose dy skedarëve binare, gjithçka tjetër ishte brenda. Besueshmëria ishte shumë e ulët, më duhej të mbaja 2-3 kopje të programit. Kohët e ngarkimit ishin gjithashtu zhgënjyese, dhe entuziastët eksperimentuan me kodime të ndryshme të frekuencave për të kapërcyer këto mangësi. Në atë kohë, unë vetë nuk isha ende i përfshirë në zhvillimin profesional të softuerit (duke mos llogaritur programet e thjeshta në BASIC), kështu që, për fat të keq, nuk do t'ju tregoj në detaje se si ishte rregulluar gjithçka brenda. Vetë fakti që kompjuteri kishte vetëm RAM në pjesën më të madhe përcaktoi thjeshtësinë e skemës së ruajtjes së të dhënave.
Shfaqja e mediave të besueshme dhe të mëdha të ruajtjes
Më vonë, u shfaqën disqe, procesi i kopjimit u thjeshtua dhe besueshmëria u rrit.
Por situata ndryshon në mënyrë dramatike vetëm kur magazinat lokale mjaft të mëdha shfaqen në formën e HDD-ve.
Lloji i dorëzimit po ndryshon rrënjësisht: shfaqen programet e instaluesit që menaxhojnë procesin e konfigurimit të sistemit, si dhe pastrimin pas heqjes, pasi programet jo vetëm që lexohen në memorie, por tashmë janë kopjuar në ruajtjen lokale, nga e cila duhet të të jetë në gjendje të pastrojë gjërat e panevojshme nëse është e nevojshme.
Në të njëjtën kohë, kompleksiteti i softuerit të furnizuar po rritet.
Numri i skedarëve në dorëzim rritet nga disa në qindra e mijëra, konfliktet midis versioneve të bibliotekës dhe gëzimeve të tjera fillojnë kur programe të ndryshme përdorin të njëjtat të dhëna.
Në atë kohë, ekzistenca e Linux nuk ishte ende e hapur për mua; unë jetoja në botën e MS DOS dhe, më vonë, Windows, dhe shkruaja në Borland Pascal dhe Delphi, ndonjëherë duke parë drejt C++. Shumë njerëz përdorën InstallShield për të ofruar produkte në atë kohë. , i cili zgjidhi me mjaft sukses të gjitha detyrat e caktuara për vendosjen dhe konfigurimin e softuerit.
Epoka e internetit
Gradualisht, kompleksiteti i sistemeve softuerike po bëhet edhe më i ndërlikuar; nga aplikacionet monolit dhe desktop ka një kalim në sistemet e shpërndara, klientët e hollë dhe mikroshërbimet. Tani ju duhet të konfiguroni jo vetëm një program, por një grup prej tyre, dhe në mënyrë që të gjithë të punojnë së bashku.
Koncepti ndryshoi plotësisht, erdhi interneti, erdhi epoka e shërbimeve cloud. Deri më tani, vetëm në fazën fillestare, në formën e faqeve të internetit, askush nuk ka ëndërruar veçanërisht për shërbimet. por ishte një pikë kthese si në zhvillimin ashtu edhe në shpërndarjen e aplikacioneve.
Për veten time, vura re se në atë moment kishte një ndryshim në brezat e zhvilluesve (ose ishte vetëm në mjedisin tim), dhe kishte një ndjenjë që të gjitha metodat e mira të vjetra të dorëzimit u harruan në një moment dhe gjithçka filloi nga vetë fillimi: të gjitha dorëzimet filluan të kryheshin skriptet e gjurit dhe me krenari e quajtën atë "Dorëzimi i vazhdueshëm". Në fakt, ka filluar një periudhë kaosi, kur e vjetra harrohet dhe nuk përdoret, dhe e reja thjesht nuk ekziston.
Më kujtohen kohët kur në kompaninë tonë ku punoja atëherë (nuk do ta përmend), në vend që të ndërtonin me anë të milingonës (maven nuk ishte ende popullor ose nuk ekzistonte fare), njerëzit thjesht mblidhnin kavanoza në IDE dhe angazhoheshin qetësisht atë në SVN. Prandaj, vendosja konsistonte në marrjen e skedarit nga SVN dhe kopjimin e tij nëpërmjet SSH në makinën e dëshiruar. Është kaq e thjeshtë dhe e ngathët.
Në të njëjtën kohë, shpërndarja e faqeve të thjeshta në PHP u bë në një mënyrë shumë primitive duke kopjuar thjesht skedarin e korrigjuar përmes FTP në makinën e synuar. Ndonjëherë nuk ishte kështu - kodi redaktohej drejtpërdrejt në serverin e produktit dhe ishte veçanërisht elegant nëse kishte kopje rezervë diku.
Paketat RPM dhe DEB
Nga ana tjetër, me zhvillimin e internetit, sistemet e ngjashme me UNIX filluan të fitojnë gjithnjë e më shumë popullaritet, në veçanti, ishte në atë kohë që zbulova RedHat Linux 6, afërsisht 2000. Natyrisht, kishte edhe mjete të caktuara për dërgimin e softuerit; sipas Wikipedia, RPM si menaxheri kryesor i paketave u shfaq tashmë në 1995, në versionin e RedHat Linux 2.0. Dhe që atëherë dhe deri më sot, sistemi është dorëzuar në formën e paketave RPM dhe ka ekzistuar dhe zhvilluar me mjaft sukses.
Shpërndarjet e familjes Debian ndoqën një rrugë të ngjashme dhe zbatuan shpërndarjen në formën e paketave deb, e cila ka mbetur e pandryshuar edhe sot e kësaj dite.
Menaxherët e paketave ju lejojnë të dorëzoni vetë produktet e softuerit, t'i konfiguroni ato gjatë procesit të instalimit, të menaxhoni varësitë midis paketave të ndryshme, të hiqni produktet dhe të pastroni artikujt e panevojshëm gjatë procesit të çinstalimit. Ato. në pjesën më të madhe, kjo është gjithçka që nevojitet, kjo është arsyeja pse ato zgjatën disa dekada pothuajse të pandryshuara.
Cloud computing ka shtuar instalimin për menaxherët e paketave jo vetëm nga mediat fizike, por edhe nga depot e resë kompjuterike, por thelbësisht pak ka ndryshuar.
Vlen të përmendet se aktualisht ka disa lëvizje drejt largimit nga deb dhe kalimit në paketat snap, por më shumë për këtë më vonë.
Pra, kjo gjeneratë e re e zhvilluesve të cloud, të cilët nuk dinin as DEB as RPM, gjithashtu u rrit ngadalë, fitoi përvojë, produktet u bënë më komplekse dhe nevojiteshin disa metoda më të arsyeshme shpërndarjeje sesa FTP, skriptet bash dhe zanatet e ngjashme studentore.
Dhe këtu shfaqet Docker, një lloj përzierje e virtualizimit, përcaktimit të burimeve dhe metodës së shpërndarjes. Tani është në modë dhe rinore, por a nevojitet për gjithçka? A është kjo një ilaç?
Nga vëzhgimet e mia, shumë shpesh Docker propozohet jo si një zgjedhje e arsyeshme, por thjesht sepse, nga njëra anë, për të flitet në komunitet dhe ata që e propozojnë e dinë vetëm atë. Nga ana tjetër, në pjesën më të madhe ata heshtin për sistemet e mira të paketimit të vjetër - ato ekzistojnë dhe e bëjnë punën e tyre në heshtje dhe pa u vënë re. Në një situatë të tillë, me të vërtetë nuk ka zgjidhje tjetër - zgjedhja është e qartë - Docker.
Do të përpiqem të ndaj përvojën time se si e zbatuam Docker dhe çfarë ndodhi si rezultat.
Skriptet e shkruara vetë
Fillimisht, kishte skripta bash që vendosën arkivat e kavanozëve në makinat e kërkuara. Ky proces u menaxhua nga Jenkins. Kjo funksionoi me sukses, pasi vetë arkivi i kavanozit është tashmë një asamble që përmban klasa, burime dhe madje edhe konfigurim. Nëse vendosni gjithçka në të në maksimum, atëherë zgjerimi i tij në një skenar nuk është gjëja më e vështirë që ju nevojitet
Por skriptet kanë disa disavantazhe:
- Skriptet zakonisht shkruhen me nxitim dhe për këtë arsye janë aq primitive saqë përmbajnë vetëm një skenar të rastit më të mirë. Kjo lehtësohet nga fakti se zhvilluesi është i interesuar për dorëzim të shpejtë, dhe një skenar normal kërkon investimin e një sasie të mirë burimesh
- si pasojë e pikës së mëparshme, skriptet nuk përmbajnë procedura të çinstalimit
- asnjë procedurë e përcaktuar për përmirësim
- Kur shfaqet një produkt i ri, duhet të shkruani një skenar të ri
- nuk ka mbështetje për varësinë
Sigurisht, ju mund të shkruani një skenar të sofistikuar, por, siç shkrova më lart, kjo është koha e zhvillimit, dhe jo më pak e rëndësishmja, dhe, siç e dimë, gjithmonë nuk ka kohë të mjaftueshme.
E gjithë kjo padyshim kufizon gamën e aplikimit të kësaj metode të vendosjes vetëm në sistemet më të thjeshta. Ka ardhur koha për ta ndryshuar këtë.
prerës
Në një moment, filluan të na vinin mesi të sapokripura, të mbushura me ide dhe të tërbuara për dokerin. Epo, flamuri në dorë - le ta bëjmë! Pati dy përpjekje. Të dyja ishin të pasuksesshme - le të themi, për shkak të ambicieve të mëdha, por mungesës së përvojës reale. A ishte e nevojshme të detyrohej dhe të përfundonte me çdo mjet të nevojshëm? Nuk ka gjasa - ekipi duhet të evoluojë në nivelin e kërkuar përpara se të përdorë mjetet e duhura. Për më tepër, kur përdornim imazhe të gatshme të Docker, shpesh hasëm në faktin që rrjeti nuk funksiononte siç duhet (gjë që mund të ishte për shkak të lagështisë së vetë Docker) ose ishte e vështirë të zgjeroheshin kontejnerët e njerëzve të tjerë.
Çfarë shqetësimesh hasëm?
- Problemet e rrjetit në modalitetin e urës
- Është e papërshtatshme të shikoni regjistrat në një enë (nëse ato nuk ruhen veçmas në sistemin e skedarëve të makinës pritëse)
- ElasticSearch herë pas here ngrin çuditërisht brenda kontejnerit, arsyeja nuk është përcaktuar, kontejneri është zyrtar
- Është e nevojshme të përdorni një guaskë brenda një enë - gjithçka është shumë e zhveshur, nuk ka mjete të zakonshme
- 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ë mbështeten versione të shumta
- Kohë më e gjatë e ndërtimit, ndryshe nga metodat e tjera (skriptet ose paketat deb)
Nga ana tjetër, pse është më keq të vendosësh një shërbim Spring në formën e një arkivi kavanoz përmes të njëjtit deb? A është vërtet i nevojshëm izolimi i burimeve? A ia vlen të humbasësh mjetet e përshtatshme të sistemit operativ duke futur një shërbim në një enë shumë të reduktuar?
Siç ka treguar praktika, në realitet kjo nuk është e nevojshme, paketa deb është e mjaftueshme në 90% të rasteve.
Kur dështon deb-i i vjetër i mirë dhe kur na duhet vërtet doker?
Për ne, kjo ishte vendosja e shërbimeve në python. Shumë biblioteka të nevojshme për mësimin e makinerive dhe të pa përfshira në shpërndarjen standarde të sistemit operativ (dhe ato që kishte ishin versionet e gabuara), hakimet me cilësimet, nevoja për versione të ndryshme për shërbime të ndryshme që jetojnë në të njëjtin sistem pritës çuan në kjo, se e vetmja mënyrë e arsyeshme për të dhënë këtë përzierje bërthamore ishte dokeri. Intensiteti i punës për montimin e një kontejneri docker doli të ishte më i ulët se ideja për ta paketuar të gjithën në paketa të veçanta deb me varësi, dhe në fakt askush në mendjen e tij nuk do ta ndërmerrte këtë.
Pika e dytë ku ne planifikojmë të përdorim Docker është vendosja e shërbimeve duke përdorur skemën e vendosjes blu-jeshile. Por këtu unë dua të marr një rritje graduale të kompleksitetit: së pari, ndërtohen paketat deb, dhe më pas ndërtohet një kontejner docker prej tyre.
Snap paketat
Le të kthehemi te paketat e parakohshme. Ata fillimisht u shfaqën zyrtarisht në Ubuntu 16.04. Ndryshe nga paketat e zakonshme deb dhe paketat rpm, snap mbart të gjitha varësitë. Nga njëra anë, kjo ju lejon të shmangni konfliktet e bibliotekës, nga ana tjetër, paketa që rezulton është më e madhe në madhësi. Përveç kësaj, kjo mund të ndikojë gjithashtu në sigurinë e sistemit: në rastin e dërgimit të parakohshëm, të gjitha ndryshimet në bibliotekat e përfshira duhet të monitorohen nga zhvilluesi që krijon paketën. Në përgjithësi, jo gjithçka është kaq e thjeshtë dhe lumturia universale nuk vjen nga përdorimi i tyre. Por, megjithatë, kjo është një alternativë plotësisht e arsyeshme nëse i njëjti Docker përdoret vetëm si një mjet paketimi dhe jo për virtualizim.
Si rezultat, ne tani përdorim si paketat deb ashtu edhe kontejnerët docker në një kombinim të arsyeshëm, të cilat, ndoshta, në disa raste do t'i zëvendësojmë me paketa snap.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , te lutem
Çfarë përdorni për dërgesë?
-
Skriptet e shkruara vetë
-
Kopjojeni manualisht në FTP
-
paketat deb
-
paketa rpm
-
paketat e parakohshme
-
Docker-imazhe
-
Imazhet e makinës virtuale
-
Klononi të gjithë HDD-në
-
kukull
-
ansible
-
Tjetër
109 përdorues votuan. 32 përdorues abstenuan.
Burimi: www.habr.com