Nolabait momentu batean Docker ontzi eta deb paketeen formako bidalketari buruzko artikulu bat idaztea erabaki nuen, baina hasi nintzenean, arrazoiren batengatik, lehen ordenagailu pertsonalen eta baita kalkulagailuen garai urrunetara eraman ninduten. Orokorrean, docker eta deb konparaketa lehorren ordez, eboluzioaren gaiari buruzko gogoeta hauek jaso ditugu, hausnartzeko aurkezten ditudanak.
Edozein produktu, edozein dela ere, produktuen zerbitzarietara iritsi behar da nolabait, konfiguratu eta abiarazi behar da. Horri buruz arituko da artikulu hau.
Testuinguru historiko batean pentsatuko dut, βikusten dudana zertaz abesten dudana daβ, kodea idazten hasi nintzenean ikusi nuena eta orain behatzen dudana, une honetan zer erabiltzen ari garen eta zergatik. Artikuluak ez du erabateko azterketa bat denik, puntu batzuk galdu egiten dira, hau da nire ikuspegi pertsonala zenaren eta orain dagoenaren inguruan.
Beraz, garai onetan... aurkitu nuen lehen entrega-metodoa magnetofonoetako kasete-zintak izan ziren. BK-0010.01 ordenagailu bat nuen...
Kalkulagailuen garaia
Ez, oraindik lehenagoko momentu bat zegoen, bazegoen kalkulagailu bat ere ΠΈ .
Hala izan nuenean , orduan programa transferitzeko modua programa bat idatzita zegoen kutxa batean paper arrunt bat zen, behar izanez gero, eskuz exekutatzeko, kalkulagailuan idazten zen. Jolastu nahi baduzu (bai, kalkulagailu antediluviano honek ere jokoak zituen) - eseri eta programa kalkulagailuan sartzen zara. Berez, kalkulagailua itzalita zegoenean, programa ahanzturan desagertu zen. Paperean pertsonalki idatzitako kalkulagailu-kodeez gain, programak "Irratia" eta "Gazteentzako Teknologia" aldizkarietan argitaratu ziren, eta garai hartako liburuetan ere argitaratu ziren.
Hurrengo aldaketa kalkulagailua izan zen , Dagoeneko datu ez-hegazkorren biltegiratze itxuraren bat dauka. Orain jokoa edo programa ez zen eskuz sartu behar, baina botoiekin pase magiko batzuk egin ondoren, bera kargatu zen.
Kalkulagailuko programarik handienaren tamaina 105 urratsekoa zen eta MK-52ko memoria iraunkorraren tamaina 512 urratsekoa zen.
Bide batez, artikulu hau irakurtzen ari diren kalkulagailu hauen zaleak badaude, artikulua idaztean Androiderako kalkulagailu emuladore bat eta horretarako programak aurkitu ditut. Aurrera iraganera!
MK-52ri buruzko digresio labur bat (Wikipediatik)
MK-52 espaziora hegan egin zuen Soyuz TM-7 espazio-ontzian. Lurreratze ibilbidea kalkulatzeko erabili behar zen, ontziko ordenagailuak huts egingo balu.
52az geroztik, Elektronika-Astro memoria hedatzeko unitatearekin MK-1988 Armadako itsasontziei hornitu zaie nabigazio informatikoko kit baten barruan.
Lehenengo ordenagailu pertsonalak
Goazen garaietara . Argi dago hor memoria gehiago zegoela, eta paper batetik kodea idaztea jada ez zen aukera bat (hasieran hori egiten nuen arren, beste euskarririk ez zegoelako). Grabagailuetarako audio kaseteak softwarea gordetzeko eta entregatzeko baliabide nagusi bihurtzen ari dira.
Kasete batean biltegiratzea normalean fitxategi bitar baten edo biren moduan zegoen, gainerako guztia barruan zegoen. Fidagarritasuna oso baxua zen, programaren 2-3 kopia gorde behar izan nituen. Kargatze-denborak ere etsigarriak izan ziren, eta zaleek maiztasun-kodeketa ezberdinekin esperimentatu zuten gabezia horiek gainditzeko. Garai hartan, ni neu oraindik ez nengoen software profesionalaren garapenean (BASIC-en programa sinpleak kontatu gabe), beraz, tamalez, ez dizut zehatz-mehatz kontatuko nola zegoen dena barruan antolatuta. Ordenagailuak gehienetan RAM bakarrik izateak zehaztu zuen datuak biltegiratzeko eskemaren sinpletasuna.
Biltegiratze euskarri fidagarri eta handien agerpena
Geroago, disketeak agertu ziren, kopiatzeko prozesua erraztu eta fidagarritasuna handitu zen.
Baina egoera izugarri aldatzen da tokiko biltegiratze nahiko handiak HDD moduan agertzen direnean.
Bidalketa mota funtsean aldatzen ari da: sistema konfiguratzeko prozesua kudeatzen duten instalatzaile-programak agertzen dira, baita kendu ondoren garbitu ere, programak ez baitira memorian bakarrik irakurtzen, baizik eta tokiko biltegiratzera kopiatzen baitira, eta bertatik egin behar duzu. beharrezkoak ez diren gauzak garbitzeko gai izan.
Aldi berean, hornitutako softwarearen konplexutasuna gero eta handiagoa da.
Entregako fitxategien kopurua handitzen da gutxi batzuetatik ehunka eta milaka izatera, liburutegien bertsioen arteko gatazkak eta beste poz batzuk programa ezberdinek datu berdinak erabiltzen dituztenean hasten dira.
Garai hartan, Linux-en existentzia oraindik ez zitzaidan zabalik; MS DOS eta, geroago, Windows-en munduan bizi nintzen eta Borland Pascal eta Delphi-n idazten nuen, batzuetan C++-ra begira. Jende askok InstallShield erabiltzen zuen produktuak entregatzeko orduan. , eta horrek nahiko arrakastaz konpondu zituen softwarea zabaltzeko eta konfiguratzeko esleitutako zeregin guztiak.
Interneten garaia
Pixkanaka, software sistemen konplexutasuna are konplexuagoa da; monolito eta mahaigaineko aplikazioetatik sistema banatuetara, bezero meheetara eta mikrozerbitzuetara igarotzen da. Orain programa bat ez ezik, horietako multzo bat konfiguratu behar duzu eta denak batera funtzionatzeko.
Kontzeptua guztiz aldatu zen, Internet etorri zen, hodeiko zerbitzuen aroa iritsi zen. Orain arte, hasierako fasean bakarrik, webguneen moduan, inork ez du zerbitzuekin bereziki amestu. baina inflexio-puntua izan zen aplikazioen garapenean zein entregan.
Niretzat, ohartu nintzen momentu horretan garatzaileen belaunaldietan aldaketa bat egon zela (edo nire ingurunean bakarrik zegoen), eta sentsazioa zegoela entregatzeko metodo zahar on guztiak momentu batean ahaztu zirela eta dena hasieratik hasi zen. hasiera: erditze guztiak belauneko gidoiak egiten hasi ziren eta harro "Etengabeko entrega" deitu zion. Izan ere, kaos garai bat hasi da, zaharra ahaztu eta erabiltzen ez denean, eta berria besterik gabe existitzen ez dena.
Gogoan dut orduan lan egin nuen gure enpresan (ez dut izenik emango), ant bidez eraiki beharrean (maven oraindik ez zen ezaguna edo ez zen existitzen), jendeak IDEan poteak biltzen zituen eta lasaitasunez konpromisoa hartzen zuen. SVNn. Horren arabera, inplementazioa fitxategia SVNtik berreskuratzean eta SSH bidez nahi den makinan kopiatzea izan zen. Hain sinplea eta traketsa da.
Aldi berean, PHPn gune soilen bidalketa oso modu primitiboan egin zen, zuzendutako fitxategia FTP bidez helburuko makinan kopiatuz. Batzuetan ez zen horrela gertatzen - kodea zuzenean editatzen zen produktuaren zerbitzarian, eta bereziki dotorea zen nonbait babeskopiak bazeuden.
RPM eta DEB paketeak
Bestalde, Interneten garapenarekin, UNIX antzeko sistemak gero eta ospe handiagoa hartzen hasi ziren, bereziki, garai hartan aurkitu nuen RedHat Linux 6, 2000. urtea gutxi gorabehera. Jakina, softwarea emateko modu batzuk ere bazeuden; Wikipediaren arabera, RPM pakete kudeatzaile nagusi gisa 1995ean agertu zen jada, RedHat Linux 2.0 bertsioan. Eta orduz geroztik eta gaur arte, sistema RPM paketeen moduan entregatu da eta nahiko arrakastatsua izan da existitzen eta garatzen.
Debian familiaren banaketak antzeko bidetik jarraitu zuten eta deb paketeen formako entrega inplementatu zuten, gaur egunera arte aldatu gabe egon dena.
Pakete-kudeatzaileek software produktuak beraiek entregatzeko aukera ematen dute, instalazio-prozesuan konfiguratu, pakete ezberdinen arteko mendekotasunak kudeatu, produktuak kendu eta beharrezkoak ez diren elementuak garbitu desinstalazio-prozesuan. Horiek. gehienetan, hori da behar dena, eta horregatik iraun zuten hainbat hamarkada ia aldatu gabe.
Hodeiko informatikak paketeen kudeatzaileei instalazioa gehitu die euskarri fisikoetatik ez ezik, hodeiko biltegietatik ere, baina funtsean ezer gutxi aldatu da.
Aipatzekoa da gaur egun deb-etik aldendu eta snap paketeetara aldatzeko mugimendu batzuk daudela, baina gehiago gehiago geroago.
Beraz, hodeiko garatzaileen belaunaldi berri hau, DEB ez RPM ezagutzen ez zutenak, poliki-poliki hazi zen, esperientzia lortu zuen, produktuak konplexuagoak bihurtu ziren eta FTP, bash script-ak eta antzeko ikasleen eskulanak baino bidalketa-metodo zentzuzkoagoak behar ziren.
Eta hor agertzen da Docker, birtualizazioa, baliabideen mugaketa eta entrega metodoaren nahasketa moduko bat. Orain modan eta gaztea da, baina denetarako beharrezkoa al da? Hau panazea al da?
Nire behaketetatik, sarritan Docker ez da arrazoizko aukera gisa proposatzen, baizik eta, alde batetik, komunitatean hitz egiten delako, eta proposatzen dutenek bakarrik ezagutzen dutelako. Bestalde, gehienetan ontziratze sistema zahar onen inguruan isilik daude: existitzen dira eta isil-isilik eta oharkabean egiten dute lana. Egoera horretan, benetan ez dago beste aukerarik - hautua begi-bistakoa da - Docker.
Docker nola inplementatu genuen eta horren ondorioz gertatu zenari buruzko nire esperientzia partekatzen saiatuko naiz.
Norberak idatzitako gidoiak
Hasieran, jar artxiboak behar ziren makinetan zabaltzen zituzten bash script-ak zeuden. Jenkinsek kudeatu zuen prozesu hau. Honek ondo funtzionatu zuen, jar artxiboa bera dagoeneko klaseak, baliabideak eta baita konfigurazioa dituen asanblada bat baita. Dena ahalik eta gehien jartzen baduzu, gidoi batean zabaltzea ez da behar duzun gauzarik zailena
Baina gidoiek hainbat desabantaila dituzte:
- gidoiak presaka idazten dira normalean eta, beraz, hain dira primitiboak, non kasurik oneneko agertoki bakarra dutela. Hori errazten du garatzaileak bidalketa azkarra izateak interesa duela eta gidoi arrunt batek baliabide dezente inbertitzea eskatzen du.
- aurreko puntuaren ondorioz, scriptek ez dute desinstalazio prozedurarik
- ez da ezarri berritze-prozedurarik
- Produktu berri bat agertzen denean, gidoi berri bat idatzi behar duzu
- menpekotasun-laguntzarik ez
Noski, gidoi sofistikatu bat idatz dezakezu, baina, goian idatzi dudan bezala, hau garatzeko garaia da, eta ez gutxienekoa, eta, dakigunez, beti ez dago denbora nahikorik.
Horrek guztiak, jakina, hedapen-metodo honen aplikazio-eremua sistema sinpleenetara mugatzen du. Hau aldatzeko garaia heldu da.
Docker
Noizbait, erdiak asmatu berriak etortzen hasi ziren gurera, ideiez ikaraz eta atrakatzaileari buruz. Beno, bandera eskuan - egin dezagun! Bi saiakera izan ziren. Biek ez zuten arrakastarik izan, demagun, anbizio handiengatik, baina benetako esperientzia faltagatik. Beharrezkoa al zen behartu eta akabatu behar den edozein bitarteko? Nekez da - taldeak beharrezko mailara eboluzionatu behar du tresna egokiak erabili aurretik. Gainera, prest egindako Docker irudiak erabiltzean, sarea ez dabilela behar bezala topatzen genuen (Dockerren beraren hezetasunagatik izan zitekeela) edo besteen edukiontziak zabaltzea zaila zela.
Zein eragozpen topatu ditugu?
- Sare-arazoak zubi moduan
- Desegokia da erregistroak edukiontzi batean ikustea (ostalari makinaren fitxategi-sisteman bereizita gordetzen ez badira)
- ElasticSearch noizean behin arraro izozten da edukiontzi barruan, arrazoia ez da zehaztu, edukiontzia ofiziala da
- Edukiontzi baten barruan maskor bat erabili behar da - dena oso txikituta dago, ez dago ohiko tresnarik
- Bildutako ontzien tamaina handia - biltegiratzea garestia
- Edukiontzien tamaina handia dela eta, zaila da hainbat bertsio onartzea
- Eraikitze denbora luzeagoa, beste metodo batzuek ez bezala (scriptak edo deb paketeak)
Bestalde, zergatik da okerragoa deb beraren bidez Spring zerbitzu bat jar artxibo moduan zabaltzea? Baliabideen isolamendua benetan beharrezkoa al da? Merezi al du sistema eragilearen tresna erosoak galtzeak zerbitzu bat asko murriztutako edukiontzi batean sartuz?
Praktikak erakutsi duen bezala, errealitatean hori ez da beharrezkoa, zor paketea nahikoa da kasuen %90ean.
Noiz huts egiten du zor zahar onak eta noiz behar dugu benetan docker?
Guretzat, hau zerbitzuak python-en zabaltzea zen. Ikaskuntza automatikorako beharrezkoak diren liburutegi asko eta sistema eragilearen banaketa estandarrean sartu gabeak (eta zer zegoen bertsio okerrak ziren), ezarpenekin hackeak, ostalari-sistema berean bizi diren zerbitzu ezberdinetarako bertsio desberdinak behar izateak ekarri zuen. hau, nahaste nuklear hori emateko arrazoizko modu bakarra atrakatzailea zela. Docker edukiontzi bat muntatzeko lan intentsitatea dena menpekotasunekin batera deb pakete bereizietan biltzeko ideia baino txikiagoa izan zen, eta, egia esan, ez zuen bere buruko inork hartuko.
Docker erabiltzeko asmoa dugun bigarren puntua zerbitzuak zabaltzea da inplementazio eskema urdin-berdea erabiliz. Baina hemen konplexutasuna pixkanaka handitzea lortu nahi dut: lehenik eta behin, deb paketeak eraikitzen dira, eta gero docker edukiontzi bat eraikitzen da.
Snap paketeak
Itzul gaitezen snap paketeetara. Ubuntu 16.04-n agertu ziren ofizialki lehen aldiz. Ohiko deb paketeek eta rpm paketeek ez bezala, snap-ek menpekotasun guztiak daramatza. Alde batetik, horri esker, liburutegien gatazkak saihesteko aukera ematen du, bestetik, lortzen den paketea tamainaz handiagoa da. Horrez gain, horrek sistemaren segurtasunean ere eragina izan dezake: snap entregaren kasuan, sartutako liburutegietan egindako aldaketa guztiak kontrolatu behar ditu paketea sortzen duen garatzaileak. Oro har, dena ez da hain sinplea eta zoriontasun unibertsala ez dator horiek erabiltzeatik. Baina, hala ere, guztiz arrazoizkoa den alternatiba da Docker bera ontziratzeko tresna gisa soilik erabiltzen bada eta ez birtualizaziorako.
Ondorioz, orain deb paketeak eta docker edukiontziak zentzuzko konbinazio batean erabiltzen ditugu, eta, agian, kasu batzuetan snap paketeekin ordezkatuko dugu.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Zer erabiltzen duzu bidaltzeko?
-
Norberak idatzitako gidoiak
-
Kopiatu eskuz FTPra
-
deb paketeak
-
rpm paketeak
-
snap paketeak
-
Docker-irudiak
-
Makina birtualeko irudiak
-
Klonatu HDD osoa
-
txotxongilo
-
ansible
-
Beste
109 erabiltzailek eman dute botoa. 32 erabiltzaile abstenitu ziren.
Iturria: www.habr.com