Op een of ander manier het ek op 'n stadium besluit om 'n artikel oor aflewering in die vorm van Docker-houers en deb-pakkette te skryf, maar toe ek begin het, is ek om een of ander rede teruggevoer na die verre tye van die eerste persoonlike rekenaars en selfs sakrekenaars. Oor die algemeen, in plaas van droë vergelykings van docker en deb, het ons hierdie gedagtes oor die onderwerp van evolusie gekry, wat ek vir u oorweging aanbied.
Enige produk, maak nie saak wat dit is nie, moet op een of ander manier by die produkbedieners uitkom, moet gekonfigureer en bekendgestel word. Dit is waaroor hierdie artikel sal handel.
Ek sal in 'n historiese konteks dink, "wat ek sien is waaroor ek sing," wat ek gesien het toe ek die eerste keer kode begin skryf het en wat ek nou waarneem, wat ons self op die oomblik gebruik en hoekom. Die artikel gee nie voor as 'n volwaardige studie nie, sommige punte word gemis, dit is my persoonlike siening van wat was en wat nou is.
So, in die goeie ou dae ... die vroegste metode van aflewering wat ek gevind het, was kassetbande van bandopnemers. Ek het 'n rekenaar BK-0010.01 gehad...
Die era van sakrekenaars
Nee, daar was 'n nog vroeër oomblik, daar was ook 'n sakrekenaar и .
So toe ek gehad het , dan was die manier om die program oor te dra 'n gewone stuk papier in 'n boks waarop 'n program geskryf is, wat, indien nodig, om dit met die hand te laat loop, in die sakrekenaar geskryf is. As jy wil speel (ja, selfs hierdie antediluviaanse sakrekenaar het speletjies gehad) - gaan sit en voer die program in die sakrekenaar in. Natuurlik, toe die sakrekenaar afgeskakel is, het die program in die vergetelheid verdwyn. Benewens die sakrekenaarkodes wat in sy eie hand op papier uitgeskryf is, is die programme in die tydskrifte “Radio” en “Tegnologie vir Jeug” gepubliseer en is ook in boeke van daardie tyd gepubliseer.
Die volgende wysiging was 'n sakrekenaar , dit het reeds 'n mate van nie-vlugtige databerging. Nou hoef die speletjie of program nie met die hand ingevoer te word nie, maar nadat hy 'n paar magiese passe met die knoppies uitgevoer het, het dit self gelaai.
Die grootte van die grootste program in die sakrekenaar was 105 stappe, en die grootte van die permanente geheue in MK-52 was 512 stappe.
Terloops, as daar aanhangers van hierdie sakrekenaars is wat hierdie artikel lees, het ek tydens die skryf van die artikel beide 'n sakrekenaar-emulator vir Android en programme daarvoor gevind. Vorentoe na die verlede!
'n Kort afwyking oor MK-52 (van Wikipedia)
MK-52 het met die Soyuz TM-7 ruimtetuig die ruimte ingevlieg. Dit was veronderstel om gebruik te word om die landingstrajek te bereken ingeval die aanboordrekenaar sou misluk.
Sedert 52 is die MK-1988 met die Elektronika-Astro-geheue-uitbreidingseenheid aan vlootskepe verskaf as deel van 'n navigasierekenaarstel.
Die eerste persoonlike rekenaars
Kom ons gaan terug na die tye . Dit is duidelik dat daar meer geheue daar was, en om kode vanaf 'n stuk papier in te tik was nie meer 'n opsie nie (alhoewel ek dit eers gedoen het, want daar was eenvoudig geen ander medium nie). Oudiokassette vir bandopnemers word die belangrikste manier om sagteware te stoor en af te lewer.
Berging op 'n kasset was gewoonlik in die vorm van een of twee binêre lêers, al die ander was daarin vervat. Betroubaarheid was baie laag, ek moes 2-3 kopieë van die program hou. Laaitye was ook teleurstellend, en entoesiaste het met verskillende frekwensie-enkoderings geëksperimenteer om hierdie tekortkominge te oorkom. Op daardie tydstip was ek self nog nie betrokke by professionele sagteware-ontwikkeling nie (tensy eenvoudige programme in BASIC getel nie), so ek sal jou ongelukkig nie in detail vertel hoe alles binne gereël is nie. Die feit dat die rekenaar hoofsaaklik net RAM gehad het, het die eenvoud van die databergingskema bepaal.
Die opkoms van betroubare en groot bergingsmedia
Later het diskette verskyn, die kopieerproses is vereenvoudig en betroubaarheid het toegeneem.
Maar die situasie verander slegs dramaties wanneer voldoende groot plaaslike bergings in die vorm van HDD's verskyn.
Die tipe aflewering is fundamenteel aan die verander: installeerderprogramme verskyn wat die proses van konfigurasie van die stelsel bestuur, sowel as skoonmaak na verwydering, aangesien programme nie net in die geheue gelees word nie, maar reeds na plaaslike berging gekopieer is, waaruit u moet onnodige goed kan uitvee indien nodig.
Terselfdertyd neem die kompleksiteit van die verskafde sagteware toe.
Die aantal lêers in die aflewering neem toe van 'n paar na honderde en duisende, konflikte tussen biblioteekweergawes en ander vreugdes begin wanneer verskillende programme dieselfde data gebruik.
Op daardie tydstip was die bestaan van Linux nog nie vir my oop nie; ek het in die wêreld van MS DOS en later Windows gewoon en in Borland Pascal en Delphi geskryf, soms na C++ gekyk. Baie mense het destyds InstallShield gebruik om produkte af te lewer. , wat al die toegewese take van die implementering en konfigurasie van die sagteware redelik suksesvol opgelos het.
Internet era
Geleidelik word die kompleksiteit van sagtewarestelsels selfs meer kompleks; van die monoliet- en rekenaartoepassings is daar 'n oorgang na verspreide stelsels, dun kliënte en mikrodienste. Nou moet jy nie net een program opstel nie, maar 'n stel van hulle, en sodat hulle almal saamwerk.
Die konsep het heeltemal verander, die internet het gekom, die era van wolkdienste het aangebreek. Tot dusver, net in die aanvanklike stadium, in die vorm van webwerwe, het niemand besonders van dienste gedroom nie. maar dit was 'n keerpunt in beide die ontwikkeling en lewering van toepassings.
Vir myself het ek opgemerk dat daar op daardie oomblik 'n verandering in generasies van ontwikkelaars was (of dit was net in my omgewing), en daar was 'n gevoel dat al die goeie ou afleweringsmetodes op een oomblik vergeet is en alles het van die heel eerste af begin. begin: alle aflewering het begin om knieskrifte gedoen te word en het dit met trots "Deurlopende aflewering" genoem. Trouens, 'n tydperk van chaos het begin, wanneer die oue vergeet en nie gebruik word nie, en die nuwe eenvoudig nie bestaan nie.
Ek onthou die tye toe in ons maatskappy waar ek toe gewerk het (ek noem dit nie), in plaas daarvan om via mier te bou (maven was nog nie gewild of het glad nie bestaan nie), het mense eenvoudig potte in die IDE versamel en rustig toegewyd dit in SVN. Gevolglik het ontplooiing bestaan uit die herwinning van die lêer vanaf SVN en die kopiëring daarvan via SSH na die verlangde masjien. Dit is so eenvoudig en lomp.
Terselfdertyd is die aflewering van eenvoudige webwerwe in PHP op 'n baie primitiewe manier gedoen deur bloot die gekorrigeerde lêer via FTP na die teikenmasjien te kopieer. Soms was dit nie die geval nie – die kode is regstreeks op die produkbediener geredigeer, en dit was veral sjiek as daar iewers rugsteun was.
RPM en DEB pakkette
Aan die ander kant, met die ontwikkeling van die internet, het UNIX-agtige stelsels al hoe meer gewild begin word, veral, dit was in daardie tyd dat ek RedHat Linux 6, ongeveer 2000, ontdek het. Natuurlik was daar ook sekere maniere om sagteware af te lewer; volgens Wikipedia het RPM as hoofpakketbestuurder reeds in 1995 verskyn, in die weergawe van RedHat Linux 2.0. En sedertdien en tot vandag toe is die stelsel in die vorm van RPM-pakkette afgelewer en het dit redelik suksesvol bestaan en ontwikkel.
Verspreidings van die Debian-familie het 'n soortgelyke pad gevolg en aflewering geïmplementeer in die vorm van deb-pakkette, wat tot vandag toe onveranderd gebly het.
Pakketbestuurders laat jou toe om die sagtewareprodukte self te lewer, dit tydens die installasieproses op te stel, afhanklikhede tussen verskillende pakkette te bestuur, produkte te verwyder en onnodige items op te ruim tydens die deïnstallasieproses. Dié. vir die grootste deel is dit al wat nodig is, en daarom het hulle etlike dekades feitlik onveranderd gehou.
Wolkrekenaars het installasie by pakketbestuurders gevoeg, nie net vanaf fisiese media nie, maar ook vanaf wolkbewaarplekke, maar fundamenteel het min verander.
Dit is opmerklik dat daar tans 'n paar bewegings is om weg te beweeg van deb en oor te skakel na snap-pakkette, maar later meer daaroor.
So, hierdie nuwe generasie wolkontwikkelaars, wat nie DEB of RPM geken het nie, het ook stadig gegroei, ondervinding opgedoen, produkte het meer kompleks geword, en 'n paar meer redelike afleweringsmetodes was nodig as FTP, bash-skrifte en soortgelyke studentehandwerk.
En dit is waar Docker in die prentjie kom, 'n soort mengsel van virtualisering, hulpbronafbakening en afleweringsmetode. Dis nou modieus en jeugdig, maar is dit vir alles nodig? Is dit 'n wondermiddel?
Uit my waarnemings word Docker baie dikwels nie as 'n redelike keuse voorgestel nie, maar bloot omdat, aan die een kant, daaroor in die gemeenskap gepraat word, en diegene wat dit voorstel, weet dit net. Aan die ander kant swyg hulle meestal oor die goeie ou verpakkingstelsels – hulle bestaan en doen hul werk stil en ongemerk. In so 'n situasie is daar regtig geen ander keuse nie - die keuse is voor die hand liggend - Docker.
Ek sal probeer om my ervaring te deel van hoe ons Docker geïmplementeer het en wat as gevolg daarvan gebeur het.
Selfgeskrewe skrifte
Aanvanklik was daar bash-skrifte wat jar-argiewe na die vereiste masjiene ontplooi het. Hierdie proses is deur Jenkins bestuur. Dit het suksesvol gewerk, aangesien die jar-argief self reeds 'n samestelling is wat klasse, hulpbronne en selfs konfigurasie bevat. As jy alles daarin sit tot die maksimum, dan is dit nie die moeilikste ding wat jy nodig het om dit in 'n skrif uit te brei nie
Maar skrifte het verskeie nadele:
- skrifte word gewoonlik haastig geskryf en is dus so primitief dat dit net een beste scenario bevat. Dit word vergemaklik deur die feit dat die ontwikkelaar belangstel in spoedige aflewering, en 'n normale skrif vereis die belegging van 'n ordentlike hoeveelheid hulpbronne
- as gevolg van die vorige punt, bevat die skrifte nie deïnstallasieprosedures nie
- geen gevestigde opgraderingsprosedure nie
- Wanneer 'n nuwe produk verskyn, moet jy 'n nuwe skrif skryf
- geen afhanklikheidsondersteuning nie
Natuurlik kan jy 'n gesofistikeerde draaiboek skryf, maar, soos ek hierbo geskryf het, is dit ontwikkelingstyd, en nie die minste nie, en, soos ons weet, is daar altyd nie genoeg tyd nie.
Dit alles beperk natuurlik die toepassingsgebied van hierdie ontplooiingsmetode tot slegs die eenvoudigste stelsels. Die tyd het aangebreek om dit te verander.
Docker
Op 'n stadium het vars geslaan middels na ons begin kom, siedende van idees en gaande oor die dokwerker. Wel, vlag in die hand – kom ons doen dit! Daar was twee pogings. Albei was onsuksesvol – kom ons sê, weens groot ambisies, maar gebrek aan werklike ervaring. Was dit nodig om dit te forseer en op enige moontlike manier klaar te maak? Dit is onwaarskynlik - die span moet tot die vereiste vlak ontwikkel voordat dit die toepaslike gereedskap kan gebruik. Daarbenewens, wanneer ons klaargemaakte Docker-beelde gebruik het, het ons dikwels die feit teëgekom dat die netwerk nie reg gewerk het nie (wat moontlik te wyte was aan die vogtigheid van die Docker self) of dit was moeilik om ander mense se houers uit te brei.
Watter ongerief het ons teëgekom?
- Netwerkprobleme in brugmodus
- Dit is ongerieflik om logs in 'n houer te sien (as dit nie afsonderlik in die lêerstelsel van die gasheermasjien gestoor word nie)
- ElasticSearch vries af en toe vreemd binne die houer, die rede is nie vasgestel nie, die houer is amptelik
- Dit is nodig om 'n dop in 'n houer te gebruik - alles is baie gestroop, daar is geen gewone gereedskap nie
- Groot grootte versamelde houers - duur om te stoor
- As gevolg van die groot grootte van houers, is dit moeilik om verskeie weergawes te ondersteun
- Langer boutyd, anders as ander metodes (skrifte of deb-pakkette)
Aan die ander kant, hoekom is dit erger om 'n Spring-diens in die vorm van 'n jar-argief deur dieselfde deb te ontplooi? Is hulpbron-isolasie werklik nodig? Is dit die moeite werd om gerieflike bedryfstelselnutsgoed te verloor deur 'n diens in 'n aansienlik verminderde houer te stop?
Soos die praktyk getoon het, is dit in werklikheid nie nodig nie, die deb-pakket is genoeg in 90% van die gevalle.
Wanneer misluk die goeie ou deb en wanneer het ons regtig dokwerker nodig?
Vir ons was dit die implementering van dienste in python. Baie biblioteke benodig vir masjienleer en nie ingesluit in die standaardverspreiding van die bedryfstelsel nie (en wat daar was was die verkeerde weergawes), hacks met instellings, die behoefte aan verskillende weergawes vir verskillende dienste wat op dieselfde gasheerstelsel woon, het gelei tot dit , dat die enigste redelike manier om hierdie kernmengsel te lewer die dokwerker was. Die arbeidsintensiteit van die samestelling van 'n dokhouer het geblyk laer te wees as die idee om dit alles in afsonderlike deb-pakkette met afhanklikhede te verpak, en in werklikheid sou niemand by sy volle verstand dit onderneem nie.
Die tweede punt waar daar beplan word om Docker te gebruik, is om dienste volgens die blou-groen ontplooiingskema te ontplooi. Maar hier wil ek 'n geleidelike toename in kompleksiteit kry: eerstens word deb-pakkette gebou, en dan word 'n dokhouer daaruit gebou.
Knip pakkies
Kom ons keer terug na snap-pakkette. Hulle het die eerste keer amptelik in Ubuntu 16.04 verskyn. Anders as die gewone deb-pakkette en rpm-pakkette, dra snap al die afhanklikhede. Aan die een kant laat dit jou toe om biblioteekkonflikte te vermy, aan die ander kant is die gevolglike pakket groter in grootte. Daarbenewens kan dit ook die sekuriteit van die stelsel beïnvloed: in die geval van vinnige aflewering, moet alle veranderinge aan die ingeslote biblioteke gemonitor word deur die ontwikkelaar wat die pakket skep. Oor die algemeen is nie alles so eenvoudig nie en universele geluk kom nie uit die gebruik daarvan nie. Maar dit is nietemin 'n heeltemal redelike alternatief as dieselfde Docker slegs as 'n verpakkingsinstrument gebruik word en nie vir virtualisering nie.
As gevolg hiervan gebruik ons nou beide deb-pakkette en docker-houers in 'n redelike kombinasie, wat ons miskien in sommige gevalle met snap-pakkette sal vervang.
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Wat gebruik jy vir aflewering?
-
Selfgeskrewe skrifte
-
Kopieer handmatig na FTP
-
deb pakkette
-
rpm pakkette
-
snap pakkette
-
Docker-beelde
-
Virtuele masjien beelde
-
Kloon die hele HDD
-
marionet
-
ansible
-
Ander
109 gebruikers het gestem. 32 gebruikers het buite stemming gebly.
Bron: will.com