🥇Udviklingen af leveringsværktøjer, eller tanker om Docker, deb, jar og andre ting

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere

På et tidspunkt 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 revet med af de fjerne tider med de første personlige computere og endda lommeregnere. Generelt, i stedet for tørre sammenligninger af docker og deb, fik jeg disse tanker om emnet evolution, som jeg præsenterer til din vurdering.

Ethvert produkt, uanset hvad det er, skal på en eller anden måde nå frem til produktets servere, konfigureres og lanceres. Det er det, denne artikel vil handle om.

Jeg vil reflektere i en historisk kontekst, "det jeg ser, er det jeg synger om", hvad jeg så, da jeg begyndte at skrive kode, og hvad jeg observerer nu, hvad vi selv bruger i øjeblikket, og hvorfor. Artiklen gør ikke krav på at være et fuldgyldigt studie, nogle pointer mangler, dette er mit personlige syn på, hvad der var, og hvad der er nu.

Så, tilbage i de gode gamle dage ... var den tidligste leveringsmetode, jeg husker, bånd fra båndoptagere. Jeg havde en computer BK-0010.01…

Lommeregnernes tidsalder

Nej, der var et endnu tidligere tidspunkt, der var også en lommeregner MK-61 и MK-52.

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere Så, da jeg havde MK-61, så var metoden til at overføre programmet et almindeligt stykke papir i en æske, hvorpå programmet blev skrevet, som om nødvendigt manuelt blev skrevet ind i lommeregneren. Hvis du vil spille (ja, selv denne fordums lommeregner havde spil), sætter du dig ned og indtaster et program i lommeregneren. Naturligvis, da lommeregneren blev slukket, forsvandt programmet i glemsel. Udover de håndskrevne lommeregnerkoder blev programmerne udgivet i magasinerne "Radio" og "Teknologi for Ungdommen" og blev også trykt i datidens bøger.

Den næste ændring var en lommeregner MK-52, den har allerede en form for ikke-flygtig datalagring. Nu var det ikke længere nødvendigt at indtaste et spil eller program manuelt, men efter at have udført nogle magiske gennemløb med knapperne, ville det indlæse sig selv.

Størrelsen på det største program i lommeregneren var 105 trin, og størrelsen på den permanente hukommelse i MK-52 var 512 trin.

Forresten, hvis der er fans af disse lommeregnere, der læser denne artikel - i processen med at skrive artiklen fandt jeg både en lommeregneremulator til Android og programmer til den. Frem til fortiden!

En lille afstikker om MK-52 (fra Wikipedia)
MK-52 fløj ud i rummet på Soyuz TM-7 rumfartøjet. Den var beregnet til at blive brugt til at beregne landingsbanen i tilfælde af at den indbyggede computer svigtede.
Siden 52 er MK-1988 med Elektronika-Astro hukommelsesudvidelsesenhed blevet leveret til flådeskibe som en del af navigationscomputersættet.

De første personlige computere

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere Lad os gå tilbage til tiderne BC-0010. Det er tydeligt, at der var mere hukommelse der, og det var ikke længere en mulighed at indtaste koden fra et stykke papir (selvom jeg i starten gjorde præcis det, fordi der simpelthen ikke var noget andet medie). Lydkassetter til båndoptagere er blevet det primære middel til lagring og levering af software.

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere Lagringen på kassetten var normalt en eller to binære filer, med alt andet indeholdt indeni. Pålideligheden var meget lav, det var nødvendigt at beholde 2-3 kopier af programmet. Indlæsningstiderne var heller ikke opmuntrende, og entusiaster eksperimenterede med forskellige frekvenskodninger for at overvinde disse mangler. På det tidspunkt var jeg endnu ikke selv involveret i professionel softwareudvikling (udover simple programmer i BASIC), så jeg kan desværre ikke fortælle dig i detaljer, hvordan alt var arrangeret indeni. Selve det faktum, at en computer kun havde RAM, bestemte i høj grad enkelheden af datalagringssystemet.

Fremkomsten af pålidelige og store lagringsmedier

Senere dukkede disketter op, kopieringsprocessen blev enklere, og pålideligheden steg.
Men situationen ændrer sig først radikalt, når tilstrækkeligt store lokale lagringe i form af harddiske dukker op.

Leveringstypen ændrer sig fundamentalt: der vises installationsprogrammer, der styrer processen med at konfigurere systemet samt rengøring efter fjernelse, da programmer ikke blot læses ind i hukommelsen, men allerede kopieres til lokal lagring, hvorfra du skal kunne rydde op i unødvendige programmer, hvis det er nødvendigt.

Samtidig øges kompleksiteten af den leverede software.
Antallet af filer i leverancen stiger fra enheder til hundreder og tusinder, konflikter mellem biblioteksversioner og andre glæder begynder, når forskellige programmer bruger de samme data.

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere På det tidspunkt var eksistensen endnu ikke åbenbaret for mig LinuxJeg levede i MS DOS' verden, og senere, Windows, og skrev i Borland Pascal og Delphi, og prøvede lejlighedsvis C++. På det tidspunkt brugte mange InstallShield til at levere produkter. ru.wikipedia.org/wiki/InstallShield, som med stor succes løste alle opgaverne med implementering og konfiguration af software.

Internetalderen

Gradvist bliver kompleksiteten af softwaresystemer endnu mere kompleks, fra monolitter og desktopapplikationer til distribuerede systemer, tynde klienter og mikrotjenester. Nu skal du konfigurere ikke bare ét program, men et sæt af dem, og på en sådan måde, at de alle fungerer sammen.

Konceptet ændrede sig fuldstændigt, internettet kom, æraen med cloud-tjenester begyndte. Indtil videre er det kun i sin indledende fase, i form af hjemmesider; ingen drømmer rigtigt om tjenester. men det var et vendepunkt i branchen, både hvad angår udvikling og selve leveringen af applikationer.

For mit eget vedkommende bemærkede jeg, at der i det øjeblik var et generationsskifte af udviklere (eller var det bare i min kreds), og det føltes som om alle de gode gamle leveringsmetoder var glemt på et tidspunkt, og alt startede helt forfra: al levering begyndte at foregå med refleksscripts, og de kaldte det stolt "Kontinuerlig levering". Faktisk er en periode med kaos begyndt, hvor det gamle er glemt og ikke brugt, og der simpelthen ikke er noget nyt.

Jeg husker de gange, hvor folk i den virksomhed, hvor jeg arbejdede på det tidspunkt (jeg vil ikke nævne navnet), i stedet for at bygge via ant (maven var ikke populært dengang eller eksisterede slet ikke), simpelthen byggede en jar i IDE'en og roligt committede den til SVN. Derfor bestod implementeringen af at hente filen fra SVN og kopiere den via SSH til den ønskede maskine. Så simpelt og groft er det.

Samtidig blev leveringen af simple PHP-sider udført på en meget primitiv måde, ved blot at kopiere den korrigerede fil via FTP til målmaskinen. Nogle gange var der ikke sådan noget - koden blev redigeret live på produktionsserveren, og det var især smart, hvis der var sikkerhedskopier et sted.

RPM- og DEB-pakker

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere På den anden side, med udviklingen af internettet, begyndte UNIX-lignende systemer at vinde stigende popularitet; især var det på det tidspunkt, at jeg opdagede RedHat. Linux 6, omkring år 2000. Naturligvis var der også visse måder at levere software på der. Ifølge Wikipedia dukkede RPM op som den primære pakkehåndtering tilbage i 1995 i RedHat-versionen. Linux 2.0. Siden da er systemet blevet leveret som RPM-pakker og fortsætter med at trives.

Familiens fordeling Debian De fulgte en lignende vej og implementerede leveringen i form af deb-pakker, som forbliver uændret den dag i dag.

Pakkeadministratorer giver dig mulighed for at levere softwareprodukter selv, konfigurere dem under installationen, administrere afhængigheder mellem forskellige pakker, fjerne produkter og rydde op i unødvendige elementer under afinstallation. Dem. For det meste er det alt, hvad der er behov for, hvilket er grunden til, at de har holdt i årtier stort set uændrede.

Cloud computing har tilføjet installation ikke kun fra fysiske medier, men også fra cloud-arkiver til pakkeadministratorer, men fundamentalt set har der ikke ændret sig meget.

Det er værd at bemærke, at der i øjeblikket er nogle forsøg på at bevæge sig væk fra deb og hen imod snap-pakker, men mere om det senere.

Så denne nye generation af cloud-udviklere, der hverken kendte til DEB eller RPM, voksede også langsomt, fik erfaring, produkterne blev mere komplekse, og der var behov for mere fornuftige leveringsmetoder end FTP, bash-scripts og lignende studenterhåndværk.
Det er her, Docker kommer ind i billedet, en slags blanding af virtualisering, ressourceisolering og leveringsmetode. Det er moderigtigt og ungdommeligt nu, men er det nødvendigt til alt? Er dette et universalmiddel?

Efter min observation foreslås Docker meget ofte ikke som et rimeligt valg, men simpelthen fordi det på den ene side tales om i fællesskabet, og de, der foreslår det, er de eneste, der kender til det. På den anden side holdes de gode gamle emballagesystemer for det meste stille – de eksisterer, og de udfører deres arbejde stille og ubemærket. I en sådan situation er der intet andet valg - valget er indlysende - Docker.

Jeg vil forsøge at dele mine erfaringer med, hvordan vi implementerede Docker, og hvad resultatet blev.

Selvskrevne manuskripter

I starten var der bash-scripts, der implementerede jar-arkiver på de nødvendige maskiner. Denne proces blev håndteret af Jenkins. Dette fungerede med succes, da selve jar-arkivet allerede er en assembly, der indeholder klasser, ressourcer og endda konfiguration. Hvis du lægger alt i det maksimalt, er det ikke det sværeste at lægge det ud i et manuskript.

Men manuskripter har flere ulemper:

Manuskripter skrives normalt i en fart og er derfor så primitive, at de kun indeholder ét mest gunstigt scenarie. Dette fremmes af, at udvikleren er interesseret i den hurtigste levering, og et normalt script kræver en anstændig mængde ressourcer.
Som følge af det foregående punkt indeholder scriptene ikke afinstallationsprocedurer
der er ingen etableret opgraderingsprocedure
Når et nyt produkt dukker op, skal du skrive et nyt manuskript
ingen afhængighedsstøtte

Selvfølgelig kan man skrive et sofistikeret manuskript, men som jeg skrev ovenfor, tager det tid at udvikle det, og ikke mindst, og som vi ved, er der aldrig nok tid.

Alt dette begrænser naturligvis anvendelsesområdet for denne implementeringsmetode til kun de enkleste systemer. Tiden er kommet til at ændre dette.

Docker

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere På et tidspunkt begyndte friskbagte middles at komme til os, boblende af ideer og begejstrede for docker. Nå, lad os gå! 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 fremtvinge det og afslutte det på alle nødvendige måder? Usandsynligt - teamet skal udvikle sig til det nødvendige niveau, før det kan bruge de passende værktøjer. Derudover stødte vi ofte på, at netværket ikke fungerede korrekt, når vi brugte færdige Docker-billeder (hvilket sandsynligvis også skyldtes selve Dockerens råhed), eller at det var vanskeligt at udvide andres containere.

Hvilke ulemper oplevede vi?

Netværksproblemer i brotilstand
Det er ubelejligt at se logfiler i en container (hvis de ikke flyttes separat til værtsmaskinens filsystem)
Periodisk mærkelig frysning af ElasticSearch inde i containeren, årsagen blev ikke fastslået, containeren er officiel.
Det er ubelejligt at bruge skallen inde i beholderen - alt er meget begrænset, der er ingen sædvanlige værktøjer
Store mængder indsamlede beholdere - dyre at opbevare
På grund af containernes store størrelse er det vanskeligt at understøtte flere versioner.
Længere byggetid end 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 via den samme deb? Er ressourceisolering virkelig nødvendig? Er det værd at miste operativsystemets praktiske værktøjer ved at proppe tjenesten ind i en stærkt reduceret container?

Som praksis har vist, er dette i virkeligheden ikke nødvendigt; deb-pakken er tilstrækkelig i 90% af tilfældene.

Hvornår fejler det gode gamle Deb, og hvornår har vi virkelig brug for Docker?

For os handlede det om at implementere tjenester i Python. Mange biblioteker, der var nødvendige til maskinlæring, og som ikke var inkluderet i standardleveringen af operativsystemet (og det, der var der, var ikke den rigtige version), hacks med indstillinger og behovet for forskellige versioner til forskellige tjenester, der leverer på det samme værtssystem, førte til, at den eneste rimelige måde at levere denne nukleare blanding på var Docker. Arbejdsintensiteten ved at samle en docker-container viste sig at være lavere end ideen om at pakke alt dette i separate deb-pakker med afhængigheder, og faktisk ville ingen ved deres fulde fem have taget sig af dette.

Det andet punkt, hvor docker er planlagt til at blive brugt, er til implementering af tjenester ved hjælp af den blågrønne implementeringsordning. Men her ønsker vi en gradvis stigning i kompleksitet: først bygges deb-pakker, og derefter bygges en docker-container ud fra dem.

Snap-pakker

Udviklingen af leveringsværktøjer eller tanker om Docker, deb, jar og mere Lad os vende tilbage til Snap-pakkerne. De dukkede officielt op første gang i Ubuntu 16.04. april. I modsætning til traditionelle DEB- og RPM-pakker inkluderer Snaps alle afhængigheder. Selvom dette undgår bibliotekskonflikter, betyder det også, at den resulterende pakke er større. Desuden kan dette påvirke systemsikkerheden: Når Snaps implementeres, skal udvikleren, der opretter pakken, administrere alle ændringer i de inkluderede biblioteker. Samlet set er det ikke så ligetil, og det er ikke altid en win-win-situation at bruge dem. Det er dog et helt rimeligt alternativ, hvis Docker for eksempel udelukkende bruges som et pakkeværktøj, ikke til virtualisering.