På en eller anden måde besluttede jeg mig for at skrive en artikel om levering i form af Docker-containere og deb-pakker, men da jeg startede, blev jeg af en eller anden grund båret tilbage til de fjerne tider med de første personlige computere og endda regnemaskiner. Generelt, i stedet for tørre sammenligninger af docker og deb, fik vi disse tanker om emnet evolution, som jeg præsenterer for din overvejelse.
Ethvert produkt, uanset hvad det er, skal på en eller anden måde komme til produktserverne, skal konfigureres og lanceres. Det er, hvad denne artikel vil handle om.
Jeg vil tænke i en historisk kontekst, "det jeg ser, er det, jeg synger om", hvad jeg så, da jeg først begyndte at skrive kode, og hvad jeg observerer nu, hvad vi selv bruger i øjeblikket og hvorfor. Artiklen foregiver ikke at være en fuldgyldig undersøgelse, nogle punkter er savnet, dette er mit personlige syn på, hvad der var og hvad der er nu.
Så i de gode gamle dage... var den tidligste leveringsmetode, jeg fandt, kassettebånd fra båndoptagere. Jeg havde en computer BK-0010.01...
Regnemaskinernes æra
Nej, der var et endnu tidligere øjeblik, der var også en lommeregner и .
Så da jeg havde , så var måden at overføre programmet på et almindeligt stykke papir i en æske, hvorpå der var skrevet et program, som om nødvendigt for at køre det manuelt, blev skrevet ind i lommeregneren. Hvis du vil spille (ja, selv denne antidiluvianske lommeregner havde spil) - sætter du dig ned og indtaster programmet i lommeregneren. Når lommeregneren blev slukket, forsvandt programmet naturligvis i glemmebogen. Ud over de personligt udskrevne lommeregnerkoder på papir, blev programmerne udgivet i magasinerne "Radio" og "Teknologi for ungdom", og blev også udgivet i datidens bøger.
Den næste ændring var en lommeregner , den har allerede et udtryk for ikke-flygtig datalagring. Nu skulle spillet eller programmet ikke indtastes manuelt, men efter at have udført nogle magiske afleveringer med knapperne, indlæste det sig selv.
Størrelsen af det største program i lommeregneren var 105 trin, og størrelsen af den permanente hukommelse i MK-52 var 512 trin.
Forresten, hvis der er fans af disse regnemaskiner, der læser denne artikel, fandt jeg i færd med at skrive artiklen både en lommeregneremulator til Android og programmer til den. Frem til fortiden!
En kort digression om MK-52 (fra Wikipedia)
MK-52 fløj ud i rummet på Soyuz TM-7 rumfartøjet. Den skulle bruges til at beregne landingsbanen i tilfælde af, at computeren om bord fejlede.
Siden 52 er MK-1988 med Elektronika-Astro hukommelsesudvidelsesenheden blevet leveret til flådens skibe som en del af et navigationscomputersæt.
De første personlige computere
Lad os gå tilbage til tiden . Det er tydeligt, at der var mere hukommelse der, og at skrive kode fra et stykke papir var ikke længere en mulighed (selvom jeg først gjorde netop det, fordi der simpelthen ikke var noget andet medie). Lydkassetter til båndoptagere er ved at blive det vigtigste middel til lagring og levering af software.
Opbevaring på en kassette var normalt i form af en eller to binære filer, alt andet var indeholdt indeni. Pålideligheden var meget lav, jeg skulle beholde 2-3 kopier af programmet. Indlæsningstiderne var også skuffende, og entusiaster eksperimenterede med forskellige frekvenskodninger for at overvinde disse mangler. På det tidspunkt var jeg selv endnu ikke involveret i professionel softwareudvikling (ikke medregnet simple programmer i BASIC), så desværre vil jeg ikke fortælle dig i detaljer, hvordan alt var arrangeret indeni. Selve det faktum, at computeren kun havde RAM for det meste, bestemte enkelheden af datalagringsordningen.
Fremkomsten af pålidelige og store lagermedier
Senere dukkede disketter op, kopieringsprocessen blev forenklet, og pålideligheden steg.
Men situationen ændrer sig kun dramatisk, når der dukker tilstrækkeligt store lokale lager op i form af HDD'er.
Leveringstypen ændrer sig fundamentalt: Der vises installationsprogrammer, der styrer processen med at konfigurere systemet, samt rydde op efter fjernelse, da programmer ikke bare læses ind i hukommelsen, men allerede er kopieret til lokalt lager, hvorfra du skal kunne rydde unødvendige ting, hvis det er nødvendigt.
Samtidig er kompleksiteten af den medfølgende software stigende.
Antallet af filer i leveringen stiger fra nogle få til hundreder og tusinder, konflikter mellem biblioteksversioner og andre glæder begynder, når forskellige programmer bruger de samme data.
På det tidspunkt var eksistensen af Linux endnu ikke åben for mig; jeg levede i en verden af MS DOS og senere Windows, og skrev i Borland Pascal og Delphi, nogle gange kiggede jeg mod C++. Mange mennesker brugte InstallShield til at levere produkter dengang. , som ganske vellykket løste alle de tildelte opgaver med at implementere og konfigurere softwaren.
Internet æra
Gradvist bliver kompleksiteten af softwaresystemer endnu mere kompleks; fra monolit- og desktopapplikationer er der en overgang til distribuerede systemer, tynde klienter og mikrotjenester. Nu skal du konfigurere ikke kun et program, men et sæt af dem, og så de alle arbejder sammen.
Konceptet ændrede sig fuldstændig, internettet kom, skytjenesternes æra ankom. Hidtil er der kun i den indledende fase, i form af hjemmesider, ingen der har drømt særligt om tjenester. men det var et vendepunkt i både udvikling og levering af applikationer.
For mig selv bemærkede jeg, at der i det øjeblik skete en ændring i generationer af udviklere (eller det var kun i mit miljø), og der var en følelse af, at alle de gode gamle leveringsmetoder blev glemt på et øjeblik, og alt startede fra begyndelse: al levering begyndte at blive udført knæ-scripts og kaldte det stolt "Kontinuerlig levering". Faktisk er en periode med kaos begyndt, hvor det gamle er glemt og ikke brugt, og det nye simpelthen ikke eksisterer.
Jeg husker de gange, hvor i vores virksomhed, hvor jeg arbejdede dengang (jeg vil ikke nævne det), i stedet for at bygge via ant (maven var endnu ikke populær eller eksisterede slet ikke), samlede folk simpelthen krukker i IDE og forpligtede sig roligt. det i SVN. Følgelig bestod implementeringen af at hente filen fra SVN og kopiere den via SSH til den ønskede maskine. Det er så enkelt og klodset.
Samtidig foregik leveringen af simple sites i PHP på en meget primitiv måde ved blot at kopiere den rettede fil via FTP til målmaskinen. Nogle gange var det ikke tilfældet – koden blev redigeret live på produktserveren, og det var især smart, hvis der var backups et sted.
RPM og DEB pakker
På den anden side, med udviklingen af internettet, begyndte UNIX-lignende systemer at vinde mere og mere popularitet, især var det på det tidspunkt, at jeg opdagede RedHat Linux 6, cirka 2000. Naturligvis var der også visse måder at levere software på; ifølge Wikipedia dukkede RPM som hovedpakkemanager op allerede i 1995, i versionen af RedHat Linux 2.0. Og siden da og den dag i dag er systemet blevet leveret i form af RPM-pakker og har været ganske succesfuldt eksisterende og udviklet.
Distribution af Debian-familien fulgte en lignende vej og implementerede levering i form af deb-pakker, som har været uændret indtil i dag.
Pakkeadministratorer giver dig mulighed for selv at levere softwareprodukterne, konfigurere dem under installationsprocessen, administrere afhængigheder mellem forskellige pakker, fjerne produkter og rydde op i unødvendige elementer under afinstallationsprocessen. De der. for det meste er det alt, der skal til, og derfor varede de flere årtier stort set uændret.
Cloud computing har tilføjet installation til pakkeadministratorer, ikke kun fra fysiske medier, men også fra cloud repositories, men grundlæggende er lidt ændret.
Det er værd at bemærke, at der i øjeblikket er nogle bevægelser i retning af at gå væk fra deb og skifte til snap-pakker, men mere om det senere.
Så denne nye generation af cloud-udviklere, som hverken kendte DEB eller RPM, voksede også langsomt, fik erfaring, produkterne blev mere komplekse, og der var brug for nogle mere fornuftige leveringsmetoder end FTP, bash-scripts og lignende elevhåndværk.
Og det er her Docker kommer ind i billedet, en slags blanding af virtualisering, ressourceafgrænsning og leveringsmetode. Det er moderigtigt og ungdommeligt nu, men er det nødvendigt til alt? Er dette et vidundermiddel?
Ud fra mine observationer foreslås Docker meget ofte ikke som et rimeligt valg, men simpelthen fordi der på den ene side tales om det i samfundet, og de, der foreslår det, ved det kun. Til gengæld er de for det meste tavse om de gode gamle pakkesystemer – de findes og udfører deres arbejde stille og ubemærket. I sådan en situation er der virkelig ikke noget andet valg - valget er indlysende - Docker.
Jeg vil prøve at dele min oplevelse af, hvordan vi implementerede Docker, og hvad der skete som et resultat.
Selvskrevne manuskripter
Oprindeligt var der bash-scripts, der implementerede jar-arkiver til de nødvendige maskiner. Denne proces blev styret af Jenkins. Dette fungerede med succes, da selve jar-arkivet allerede er en samling, der indeholder klasser, ressourcer og endda konfiguration. Hvis du sætter alt ind i det maksimalt, så er det ikke det sværeste, du har brug for at udvide det til et script
Men scripts har flere ulemper:
- scripts er normalt skrevet i hast og er derfor så primitive, at de kun indeholder ét best-case scenario. Dette lettes af det faktum, at udvikleren er interesseret i hurtig levering, og et normalt script kræver investering af en anstændig mængde ressourcer
- som en konsekvens af det foregående punkt, indeholder scripts ikke afinstallationsprocedurer
- ingen etableret opgraderingsprocedure
- Når et nyt produkt dukker op, skal du skrive et nyt script
- ingen afhængighedsstøtte
Selvfølgelig kan du skrive et sofistikeret manuskript, men, som jeg skrev ovenfor, er dette udviklingstid, og ikke mindst, og som vi ved, er der altid ikke tid nok.
Alt dette begrænser naturligvis anvendelsesområdet for denne implementeringsmetode til kun de mest simple systemer. Tiden er inde til at ændre dette.
Docker
På et tidspunkt begyndte nyslåede mellemstykker at komme til os, sydende af ideer og fablede om havnearbejderen. Nå, flag i hånden - lad os gøre det! Der var to forsøg. Begge var mislykkede - lad os sige på grund af store ambitioner, men mangel på reel erfaring. Var det nødvendigt at tvinge det og afslutte det på nogen måde? Det er usandsynligt - holdet skal udvikle sig til det krævede niveau, før det kan bruge de passende værktøjer. Derudover stødte vi ofte på, når vi brugte færdiglavede Docker-billeder, at netværket ikke fungerede korrekt (hvilket kan have været på grund af selve Dockers fugt), eller det var svært at udvide andres containere.
Hvilke gener stødte vi på?
- Netværksproblemer i brotilstand
- Det er ubelejligt at se logfiler i en container (hvis de ikke er gemt separat i værtsmaskinens filsystem)
- ElasticSearch fryser af og til mærkeligt inde i beholderen, årsagen er ikke fastlagt, beholderen er officiel
- Det er nødvendigt at bruge en skal inde i en beholder - alt er meget strippet, der er ingen sædvanlige værktøjer
- Stor størrelse af indsamlede beholdere - dyre at opbevare
- På grund af den store størrelse af containere er det svært at understøtte flere versioner
- Længere byggetid i modsætning til andre metoder (scripts eller deb-pakker)
På den anden side, hvorfor er det værre at implementere en Spring-tjeneste i form af et jar-arkiv gennem den samme deb? Er ressourceisolering virkelig nødvendig? Er det værd at miste praktiske operativsystemværktøjer ved at fylde en tjeneste i en stærkt reduceret beholder?
Som praksis har vist, er dette i virkeligheden ikke nødvendigt, deb-pakken er nok i 90% af tilfældene.
Hvornår fejler den gode gamle deb, og hvornår har vi egentlig brug for havnemand?
For os var dette at implementere tjenester i python. En masse biblioteker, der er nødvendige for maskinlæring og ikke inkluderet i standarddistributionen af operativsystemet (og hvad der var, var de forkerte versioner), hacks med indstillinger, behovet for forskellige versioner til forskellige tjenester, der bor på det samme værtssystem, førte til dette, at den eneste rimelige måde at levere denne nukleare blanding var havnearbejderen. Arbejdsintensiteten ved at samle en docker-container viste sig at være lavere end ideen om at pakke det hele i separate deb-pakker med afhængigheder, og faktisk ville ingen ved deres rette sind påtage sig dette.
Det andet punkt, hvor vi planlægger at bruge Docker, er at implementere tjenester ved hjælp af den blå-grønne implementeringsordning. Men her ønsker jeg at få en gradvis stigning i kompleksiteten: Først bygges deb-pakker, og derefter bygges en docker-container af dem.
Snap pakker
Lad os vende tilbage til snap-pakker. De dukkede først officielt op i Ubuntu 16.04. I modsætning til de sædvanlige deb-pakker og rpm-pakker, bærer snap alle afhængigheder. På den ene side giver dette dig mulighed for at undgå bibliotekskonflikter, på den anden side er den resulterende pakke større i størrelse. Derudover kan dette også påvirke systemets sikkerhed: i tilfælde af snap-levering skal alle ændringer i de inkluderede biblioteker overvåges af udvikleren, der opretter pakken. Generelt er ikke alt så simpelt, og universel lykke kommer ikke af at bruge dem. Men ikke desto mindre er dette et fuldstændig rimeligt alternativ, hvis den samme Docker kun bruges som et pakkeværktøj og ikke til virtualisering.
Som følge heraf bruger vi nu både deb-pakker og docker-containere i en fornuftig kombination, som vi måske i nogle tilfælde vil erstatte med snap-pakker.
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Hvad bruger du til levering?
-
Selvskrevne manuskripter
-
Kopier manuelt til FTP
-
deb pakker
-
rpm pakker
-
snap pakker
-
Docker-billeder
-
Billeder af virtuelle maskiner
-
Klon hele harddisken
-
marionet
-
ansible
-
Andet
109 brugere stemte. 32 brugere undlod at stemme.
Kilde: www.habr.com