På något sätt bestämde jag mig vid ett tillfälle för att skriva en artikel om leverans i form av Docker-containrar och deb-paket, men när jag började fördes jag av någon anledning tillbaka till de första persondatorerna och till och med miniräknare. I allmänhet, istället för torra jämförelser av docker och deb, fick vi dessa tankar om ämnet evolution, som jag presenterar för din övervägande.
Varje produkt, oavsett vad det är, måste på något sätt komma till produktservrarna, måste konfigureras och lanseras. Det är vad den här artikeln kommer att handla om.
Jag kommer att tänka i ett historiskt sammanhang, "det jag ser är det jag sjunger om", vad jag såg när jag först började skriva kod och vad jag observerar nu, vad vi själva använder för tillfället och varför. Artikeln utger sig inte för att vara en fullfjädrad studie, vissa punkter saknas, detta är min personliga syn på vad som var och vad som är nu.
Så, på den gamla goda tiden... den tidigaste leveransmetoden som jag hittade var kassettband från bandspelare. Jag hade en dator BK-0010.01...
Miniräknarens era
Nej, det fanns ett ännu tidigare ögonblick, det fanns också en miniräknare и .
Så när jag hade , sedan var sättet att överföra programmet ett vanligt papper i en låda som ett program skrevs på, som, om det behövs, för att köra det manuellt, skrevs in i räknaren. Om du vill spela (ja, även denna antediluvianska miniräknare hade spel) - sätter du dig ner och matar in programmet i miniräknaren. Naturligtvis, när räknaren stängdes av, försvann programmet i glömska. Utöver räknarkoderna skrivna på papper i egen hand, publicerades programmen i tidningarna "Radio" och "Teknik för ungdomar", och publicerades även i den tidens böcker.
Nästa modifiering var en miniräknare , den har redan en viss sken av icke-flyktig datalagring. Nu behövde inte spelet eller programmet läggas in manuellt, men efter att ha utfört några magiska pass med knapparna laddade det av sig självt.
Storleken på det största programmet i räknaren var 105 steg, och storleken på det permanenta minnet i MK-52 var 512 steg.
Förresten, om det finns fans av dessa miniräknare som läser den här artikeln, i färd med att skriva artikeln hittade jag både en kalkylatoremulator för Android och program för den. Framåt till det förflutna!
En kort digression om MK-52 (från Wikipedia)
MK-52 flög ut i rymden på rymdfarkosten Soyuz TM-7. Det var tänkt att användas för att beräkna landningsbanan ifall omborddatorn skulle misslyckas.
Sedan 52 har MK-1988 med Elektronika-Astro-minnesexpansionsenheten levererats till marinens fartyg som en del av ett navigeringsdatorkit.
De första persondatorerna
Låt oss gå tillbaka till tiden . Det är tydligt att det fanns mer minne där, och att skriva in kod från ett papper var inte längre ett alternativ (även om jag först gjorde just det, eftersom det helt enkelt inte fanns något annat medium). Ljudkassetter för bandspelare håller på att bli det viktigaste sättet att lagra och leverera programvara.
Lagring på en kassett var vanligtvis i form av en eller två binära filer, allt annat fanns inuti. Tillförlitligheten var mycket låg, jag var tvungen att behålla 2-3 exemplar av programmet. Laddningstiderna var också en besvikelse, och entusiaster experimenterade med olika frekvenskodningar för att övervinna dessa brister. Vid den tiden var jag själv ännu inte involverad i professionell mjukvaruutveckling (inte medräknade enkla program i BASIC), så tyvärr kommer jag inte att berätta i detalj hur allt var ordnat inuti. Själva det faktum att datorn bara hade RAM-minne för det mesta avgjorde enkelheten i datalagringsschemat.
Framväxten av pålitliga och stora lagringsmedia
Senare dök det upp disketter, kopieringsprocessen förenklades och tillförlitligheten ökade.
Men situationen förändras dramatiskt först när tillräckligt stora lokala lagringar dyker upp i form av hårddiskar.
Typen av leverans förändras i grunden: installationsprogram dyker upp som hanterar processen för att konfigurera systemet, samt städa upp efter borttagning, eftersom program inte bara läses in i minnet utan redan kopieras till lokal lagring, varifrån du måste kunna rensa bort onödiga saker vid behov.
Samtidigt ökar komplexiteten i den medföljande programvaran.
Antalet filer i leveransen ökar från några till hundratals och tusentals, konflikter mellan biblioteksversioner och andra glädjeämnen börjar när olika program använder samma data.
Vid den tiden var existensen av Linux ännu inte öppen för mig, jag levde i MS DOS-världen och senare Windows, och skrev i Borland Pascal och Delphi, ibland med tanke på C++. Många använde InstallShield för att leverera produkter då. , som ganska framgångsrikt löste alla tilldelade uppgifter för att distribuera och konfigurera programvaran.
Internet-eran
Gradvis blir komplexiteten hos mjukvarusystem ännu mer komplex, från monolit- och stationära applikationer sker en övergång till distribuerade system, tunna klienter och mikrotjänster. Nu måste du konfigurera inte bara ett program, utan en uppsättning av dem, och så att de alla fungerar tillsammans.
Konceptet förändrades totalt, internet kom, molntjänsternas era anlände. Hittills, bara i inledningsskedet, i form av webbplatser, har ingen särskilt drömt om tjänster. men det var en vändpunkt i både utveckling och leverans av applikationer.
För mig själv noterade jag att det i det ögonblicket skedde en förändring i generationer av utvecklare (eller så var det bara i min miljö), och det fanns en känsla av att alla de gamla goda leveransmetoderna glömdes bort i ett ögonblick och allt började från början början: all leverans började göras knä-skript och kallade det stolt "Kontinuerlig leverans". Faktum är att en period av kaos har börjat, när det gamla glöms bort och inte används, och det nya helt enkelt inte existerar.
Jag minns de gånger när i vårt företag där jag arbetade då (jag ska inte nämna det), istället för att bygga via ant (maven var ännu inte populär eller existerade inte alls), folk helt enkelt samlade burkar i IDE och lugnt engagerade sig det i SVN. Följaktligen bestod distributionen av att hämta filen från SVN och kopiera den via SSH till önskad maskin. Det är så enkelt och klumpigt.
Samtidigt skedde leveransen av enkla sajter i PHP på ett mycket primitivt sätt genom att helt enkelt kopiera den korrigerade filen via FTP till målmaskinen. Ibland var det inte så – koden redigerades live på produktservern, och det var särskilt chic om det fanns backuper någonstans.
RPM- och DEB-paket
Å andra sidan, med utvecklingen av Internet, började UNIX-liknande system få mer och mer popularitet, i synnerhet var det vid den tiden som jag upptäckte RedHat Linux 6, cirka 2000. Naturligtvis fanns det också vissa sätt att leverera mjukvara, enligt Wikipedia dök RPM som huvudpakethanterare upp redan 1995, i versionen av RedHat Linux 2.0. Och sedan dess och till denna dag har systemet levererats i form av RPM-paket och har existerat och utvecklats ganska framgångsrikt.
Distributionerna av Debianfamiljen följde en liknande väg och implementerade leverans i form av deb-paket, som har förblivit oförändrade till denna dag.
Pakethanterare låter dig leverera själva mjukvaruprodukterna, konfigurera dem under installationsprocessen, hantera beroenden mellan olika paket, ta bort produkter och rensa upp onödiga föremål under avinstallationsprocessen. De där. för det mesta är det allt som behövs, varför de varade i flera decennier praktiskt taget oförändrade.
Cloud computing har lagt till installation till pakethanterare inte bara från fysiska medier, utan också från molnlager, men i grunden har lite förändrats.
Det är värt att notera att det för närvarande finns vissa steg mot att gå bort från deb och byta till snappaket, men mer om det senare.
Så denna nya generation av molnutvecklare, som varken kände till DEB eller RPM, växte också sakta, fick erfarenhet, produkterna blev mer komplexa och det behövdes några mer rimliga leveransmetoder än FTP, bash-skript och liknande elevhantverk.
Och det är här Docker kommer in i bilden, en sorts blandning av virtualisering, resursavgränsning och leveransmetod. Det är på modet och ungdomligt nu, men behövs det till allt? Är detta ett universalmedel?
Från mina observationer föreslås Docker ofta inte som ett rimligt val, utan helt enkelt för att det å ena sidan talas om det i samhället, och de som föreslår det vet bara det. Å andra sidan är de för det mesta tysta om de gamla goda förpackningssystemen – de finns och gör sitt jobb tyst och obemärkt. I en sådan situation finns det egentligen inget annat val - valet är självklart - Docker.
Jag ska försöka dela med mig av min erfarenhet av hur vi implementerade Docker och vad som hände som ett resultat.
Självskrivna manus
Till en början fanns det bash-skript som distribuerade jar-arkiv till de nödvändiga maskinerna. Denna process sköttes av Jenkins. Detta fungerade framgångsrikt, eftersom jar-arkivet i sig redan är en sammansättning som innehåller klasser, resurser och till och med konfiguration. Om du lägger allt på det maximalt, är det inte det svåraste du behöver att utöka det till ett skript
Men skript har flera nackdelar:
- skript skrivs vanligtvis i hast och är därför så primitiva att de bara innehåller ett bästa scenario. Detta underlättas av det faktum att utvecklaren är intresserad av snabb leverans, och ett normalt skript kräver investeringar av en anständig mängd resurser
- som en konsekvens av föregående punkt innehåller skripten inga avinstallationsprocedurer
- ingen etablerad uppgraderingsprocedur
- När en ny produkt dyker upp måste du skriva ett nytt manus
- inget beroendestöd
Visst kan man skriva ett sofistikerat manus, men som jag skrev ovan är det här utvecklingstid, och inte minst, och som vi vet finns det alltid inte tillräckligt med tid.
Allt detta begränsar uppenbarligen tillämpningsområdet för denna distributionsmetod till endast de enklaste systemen. Det är dags att ändra på detta.
Hamnarbetare
Vid något tillfälle började nypräglade mellanlägg komma till oss, sjudande av idéer och rabblade om hamnarbetaren. Nåväl, flaggan i handen - låt oss göra det! Det blev två försök. Båda var misslyckade - låt oss säga på grund av stora ambitioner, men brist på verklig erfarenhet. Var det nödvändigt att tvinga fram det och avsluta det på något sätt? Det är osannolikt – teamet måste utvecklas till den nivå som krävs innan det kan använda lämpliga verktyg. Dessutom, när vi använde färdiga Docker-bilder, stötte vi ofta på att nätverket inte fungerade korrekt (vilket kan ha berott på fukten i själva Docker) eller att det var svårt att utöka andras behållare.
Vilka olägenheter har vi stött på?
- Nätverksproblem i bryggläge
- Det är obekvämt att se loggar i en behållare (om de inte lagras separat i värddatorns filsystem)
- ElasticSearch fryser ibland konstigt inne i behållaren, orsaken har inte fastställts, behållaren är officiell
- Det är nödvändigt att använda ett skal inuti en behållare - allt är väldigt avskalat, det finns inga vanliga verktyg
- Stor storlek på insamlade behållare - dyra att lagra
- På grund av den stora storleken på behållare är det svårt att stödja flera versioner
- Längre byggtid, till skillnad från andra metoder (skript eller deb-paket)
Å andra sidan, varför är det värre att distribuera en Spring-tjänst i form av ett burkarkiv genom samma deb? Är resursisolering verkligen nödvändig? Är det värt att förlora praktiska operativsystemverktyg genom att stoppa in en tjänst i en kraftigt reducerad behållare?
Som praxis har visat är detta i verkligheten inte nödvändigt, deb-paketet räcker i 90% av fallen.
När misslyckas den gamla goda skulden och när behöver vi verkligen hamnare?
För oss var detta att distribuera tjänster i python. Många bibliotek som behövs för maskininlärning och som inte ingår i standarddistributionen av operativsystemet (och vad som fanns var fel versioner), hack med inställningar, behovet av olika versioner för olika tjänster som bodde på samma värdsystem ledde till att detta, att det enda rimliga sättet att leverera denna kärnkraftsblandning var hamnarbetaren. Arbetsintensiteten för att montera en hamnarcontainer visade sig vara lägre än tanken på att packa det hela i separata deb-paket med beroenden, och i själva verket skulle ingen med sitt fulla sinne åta sig detta.
Den andra punkten där vi planerar att använda Docker är att distribuera tjänster med det blågröna distributionsschemat. Men här vill jag få en gradvis ökning av komplexiteten: först byggs deb-paket och sedan byggs en dockercontainer av dem.
Snäpp paket
Låt oss återgå till snappaket. De dök först officiellt upp i Ubuntu 16.04. Till skillnad från de vanliga deb-paketen och rpm-paketen, bär snap alla beroenden. Å ena sidan låter detta dig undvika bibliotekskonflikter, å andra sidan är det resulterande paketet större i storlek. Dessutom kan detta också påverka systemets säkerhet: vid snap-leverans måste alla ändringar av de inkluderade biblioteken övervakas av utvecklaren som skapar paketet. I allmänhet är inte allt så enkelt och universell lycka kommer inte från att använda dem. Men ändå är detta ett helt rimligt alternativ om samma Docker endast används som ett paketeringsverktyg och inte för virtualisering.
Som ett resultat använder vi nu både deb-paket och docker-containrar i en rimlig kombination, som vi kanske i vissa fall kommer att ersätta med snap-paket.
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Vad använder du för leverans?
-
Självskrivna manus
-
Kopiera manuellt till FTP
-
deb-paket
-
rpm-paket
-
snappa paket
-
Docker-bilder
-
Virtuella maskinbilder
-
Klona hela hårddisken
-
marionett
-
ansible
-
Andra
109 användare röstade. 32 användare avstod från att rösta.
Källa: will.com