På en eller annen måte bestemte jeg meg for å skrive en artikkel om levering i form av Docker-containere og deb-pakker, men da jeg begynte, ble jeg av en eller annen grunn ført tilbake til den fjerne tiden med de første personlige datamaskinene og til og med kalkulatorene. Generelt, i stedet for tørre sammenligninger av docker og deb, fikk vi disse tankene om emnet evolusjon, som jeg presenterer for din vurdering.
Ethvert produkt, uansett hva det er, må på en eller annen måte komme til produktserverne, må konfigureres og lanseres. Det er det denne artikkelen skal handle om.
Jeg vil tenke i en historisk kontekst, "det jeg ser er det jeg synger om," hva jeg så da jeg først begynte å skrive kode og hva jeg observerer nå, hva vi selv bruker for øyeblikket og hvorfor. Artikkelen gir seg ikke ut for å være en fullverdig studie, noen punkter er savnet, dette er mitt personlige syn på hva som var og hva som er nå.
Så, i de gode gamle dager... den tidligste leveringsmåten jeg fant var kassettbånd fra båndopptakere. Jeg hadde en datamaskin BK-0010.01...
Kalkulatorenes tid
Nei, det var et enda tidligere øyeblikk, det var også en kalkulator и .
Så når jeg hadde , så var måten å overføre programmet på et vanlig stykke papir i en boks som det var skrevet et program på, som, om nødvendig, for å kjøre det manuelt, ble skrevet inn i kalkulatoren. Hvis du vil spille (ja, selv denne antediluvianske kalkulatoren hadde spill) - setter du deg ned og legger inn programmet i kalkulatoren. Naturligvis, når kalkulatoren ble slått av, forsvant programmet inn i glemselen. I tillegg til kalkulatorkodene skrevet ut på papir i egen hånd, ble programmene publisert i magasinene "Radio" og "Technology for Youth", og ble også publisert i datidens bøker.
Den neste modifikasjonen var en kalkulator , har den allerede et utseende av ikke-flyktig datalagring. Nå trengte ikke spillet eller programmet å legges inn manuelt, men etter å ha utført noen magiske pasninger med knappene, lastet det seg selv.
Størrelsen på det største programmet i kalkulatoren var 105 trinn, og størrelsen på det permanente minnet i MK-52 var 512 trinn.
Forresten, hvis det er fans av disse kalkulatorene som leser denne artikkelen, fant jeg i prosessen med å skrive artikkelen både en kalkulatoremulator for Android og programmer for den. Frem til fortiden!
En kort digresjon om MK-52 (fra Wikipedia)
MK-52 fløy ut i verdensrommet på romfartøyet Soyuz TM-7. Den skulle brukes til å beregne landingsbanen i tilfelle datamaskinen om bord skulle svikte.
Siden 52 har MK-1988 med Elektronika-Astro minneutvidelsesenhet blitt levert til marineskip som en del av et navigasjonsdatabehandlingssett.
De første personlige datamaskinene
La oss gå tilbake til tiden . Det er tydelig at det var mer minne der, og å skrive inn kode fra et stykke papir var ikke lenger et alternativ (selv om jeg først gjorde nettopp det, fordi det rett og slett ikke fantes noe annet medium). Lydkassetter for båndopptakere er i ferd med å bli den viktigste måten å lagre og levere programvare på.
Lagring på en kassett var vanligvis i form av en eller to binære filer, alt annet var inneholdt. Reliabiliteten var veldig lav, jeg måtte beholde 2-3 kopier av programmet. Lastetidene var også skuffende, og entusiaster eksperimenterte med forskjellige frekvenskodinger for å overvinne disse manglene. På det tidspunktet var jeg selv ennå ikke involvert i profesjonell programvareutvikling (ikke med på enkle programmer i BASIC), så dessverre vil jeg ikke fortelle deg i detalj hvordan alt ble arrangert inne. Selve det faktum at datamaskinen hadde bare RAM for det meste bestemte enkelheten til datalagringsordningen.
Fremveksten av pålitelige og store lagringsmedier
Senere dukket det opp disketter, kopieringsprosessen ble forenklet og påliteligheten økte.
Men situasjonen endrer seg dramatisk bare når tilstrekkelig store lokale lagringsenheter dukker opp i form av HDD-er.
Leveringstypen endrer seg fundamentalt: installasjonsprogrammer vises som styrer prosessen med å konfigurere systemet, samt rydde opp etter fjerning, siden programmer ikke bare leses inn i minnet, men allerede er kopiert til lokal lagring, hvorfra du må kunne rydde unødvendige ting om nødvendig.
Samtidig øker kompleksiteten til den medfølgende programvaren.
Antall filer i leveransen øker fra noen få til hundrevis og tusenvis, konflikter mellom bibliotekversjoner og andre gleder begynner når ulike programmer bruker samme data.
På den tiden var eksistensen av Linux ennå ikke åpen for meg; jeg levde i en verden av MS DOS og, senere, Windows, og skrev i Borland Pascal og Delphi, noen ganger så mot C++. Mange brukte InstallShield for å levere produkter den gang. , som ganske vellykket løste alle de tildelte oppgavene med å distribuere og konfigurere programvaren.
Internett-æra
Gradvis blir kompleksiteten til programvaresystemer enda mer kompleks; fra monolitt- og skrivebordsapplikasjonene er det en overgang til distribuerte systemer, tynnklienter og mikrotjenester. Nå må du konfigurere ikke bare ett program, men et sett av dem, og slik at de alle fungerer sammen.
Konseptet endret seg fullstendig, Internett kom, epoken med skytjenester kom. Så langt, bare i den innledende fasen, i form av nettsider, har ingen spesielt drømt om tjenester. men det var et vendepunkt i både utvikling og levering av applikasjoner.
For meg selv bemerket jeg at det i det øyeblikket skjedde en endring i generasjoner av utviklere (eller det var bare i mitt miljø), og det var en følelse av at alle de gode gamle leveringsmetodene ble glemt på et øyeblikk og alt startet fra begynnelse: all levering begynte å gjøres kne scripts og stolt kalte det "Kontinuerlig levering". Faktisk har en periode med kaos begynt, da det gamle blir glemt og ikke brukt, og det nye rett og slett ikke eksisterer.
Jeg husker de gangene i selskapet vårt der jeg jobbet da (jeg vil ikke nevne det), i stedet for å bygge via maur (maven var ennå ikke populær eller eksisterte ikke i det hele tatt), samlet folk ganske enkelt krukker i IDE og engasjerte seg i fred det i SVN. Følgelig bestod utrullingen av å hente filen fra SVN og kopiere den via SSH til ønsket maskin. Det er så enkelt og klønete.
Samtidig ble leveringen av enkle nettsteder i PHP gjort på en veldig primitiv måte ved ganske enkelt å kopiere den korrigerte filen via FTP til målmaskinen. Noen ganger var dette ikke tilfelle – koden ble redigert live på produktserveren, og det var spesielt stilig om det var sikkerhetskopier et sted.
RPM- og DEB-pakker
På den annen side, med utviklingen av Internett, begynte UNIX-lignende systemer å få mer og mer popularitet, spesielt var det på den tiden jeg oppdaget RedHat Linux 6, omtrent 2000. Naturligvis fantes det også visse midler for å levere programvare; ifølge Wikipedia dukket RPM som hovedpakkebehandler opp allerede i 1995, i versjonen av RedHat Linux 2.0. Og siden da og frem til i dag har systemet blitt levert i form av RPM-pakker og har vært ganske vellykket eksisterende og utviklet.
Distribusjoner av Debian-familien fulgte en lignende vei og implementerte levering i form av deb-pakker, som har vært uendret frem til i dag.
Pakkeadministratorer lar deg levere programvareproduktene selv, konfigurere dem under installasjonsprosessen, administrere avhengigheter mellom forskjellige pakker, fjerne produkter og rydde opp i unødvendige elementer under avinstalleringsprosessen. De. for det meste er det alt som trengs, og det er grunnen til at de varte i flere tiår praktisk talt uendret.
Cloud computing har lagt til installasjon til pakkebehandlere ikke bare fra fysiske medier, men også fra skylagre, men fundamentalt sett har lite endret seg.
Det er verdt å merke seg at det for tiden er noen bevegelser mot å gå bort fra deb og bytte til snap-pakker, men mer om det senere.
Så denne nye generasjonen skyutviklere, som verken kjente til DEB eller RPM, vokste også sakte, fikk erfaring, produktene ble mer komplekse, og det var nødvendig med noen rimeligere leveringsmetoder enn FTP, bash-skript og lignende elevhåndverk.
Og det er her Docker kommer inn i bildet, en slags blanding av virtualisering, ressursavgrensning og leveringsmetode. Det er moteriktig og ungdommelig nå, men trengs det til alt? Er dette et universalmiddel?
Fra mine observasjoner blir Docker veldig ofte ikke foreslått som et rimelig valg, men ganske enkelt fordi det på den ene siden snakkes om det i samfunnet, og de som foreslår det vet det bare. På den annen side er de for det meste tause om de gode gamle emballasjesystemene – de finnes og gjør jobben sin stille og ubemerket. I en slik situasjon er det egentlig ikke noe annet valg – valget er åpenbart – Docker.
Jeg skal prøve å dele min erfaring med hvordan vi implementerte Docker og hva som skjedde som et resultat.
Selvskrevne manus
Opprinnelig var det bash-skript som distribuerte jar-arkiver til de nødvendige maskinene. Denne prosessen ble administrert av Jenkins. Dette fungerte vellykket, siden jar-arkivet i seg selv allerede er en samling som inneholder klasser, ressurser og til og med konfigurasjon. Hvis du legger alt inn i det maksimalt, er det ikke det vanskeligste du trenger å utvide det til et skript
Men skript har flere ulemper:
- skript er vanligvis skrevet i hast og er derfor så primitive at de bare inneholder ett best-case scenario. Dette tilrettelegges av det faktum at utvikleren er interessert i rask levering, og et normalt skript krever investering av en anstendig mengde ressurser
- som en konsekvens av forrige punkt, inneholder ikke skriptene avinstallasjonsprosedyrer
- ingen etablert oppgraderingsprosedyre
- Når et nytt produkt dukker opp, må du skrive et nytt manus
- ingen avhengighetsstøtte
Selvfølgelig kan du skrive et sofistikert manus, men, som jeg skrev ovenfor, er dette utviklingstid, og ikke minst, og som vi vet, er det alltid ikke nok tid.
Alt dette begrenser åpenbart bruksområdet for denne distribusjonsmetoden til bare de enkleste systemene. Tiden er inne for å endre dette.
Docker
På et tidspunkt begynte det å komme nypregede mellomstykker til oss, syde av ideer og fantaserte om havnearbeideren. Vel, flagg i hånden - la oss gjøre det! Det var to forsøk. Begge var mislykket - la oss si på grunn av store ambisjoner, men mangel på reell erfaring. Var det nødvendig å tvinge den og fullføre den på noen måte? Det er usannsynlig - teamet må utvikle seg til det nødvendige nivået før det kan bruke de riktige verktøyene. I tillegg, når vi brukte ferdiglagde Docker-bilder, møtte vi ofte at nettverket ikke fungerte riktig (noe som kan ha vært på grunn av fuktigheten til Docker selv) eller det var vanskelig å utvide andres containere.
Hvilke ulemper møtte vi?
- Nettverksproblemer i bromodus
- Det er upraktisk å se logger i en beholder (hvis de ikke er lagret separat i filsystemet til vertsmaskinen)
- ElasticSearch fryser av og til merkelig inne i beholderen, årsaken er ikke fastslått, beholderen er offisiell
- Det er nødvendig å bruke et skall inne i en beholder - alt er veldig strippet, det er ingen vanlige verktøy
- Stor størrelse på innsamlede beholdere - dyrt å lagre
- På grunn av den store størrelsen på containere er det vanskelig å støtte flere versjoner
- Lengre byggetid, i motsetning til andre metoder (skript eller deb-pakker)
På den annen side, hvorfor er det verre å distribuere en Spring-tjeneste i form av et jar-arkiv gjennom samme deb? Er ressursisolering virkelig nødvendig? Er det verdt å miste praktiske operativsystemverktøy ved å stappe en tjeneste inn i en sterkt redusert beholder?
Som praksis har vist, er dette i realiteten ikke nødvendig, deb-pakken er nok i 90 % av tilfellene.
Når svikter den gode gamle deb og når trenger vi egentlig havnearbeider?
For oss var dette å distribuere tjenester i python. Mange biblioteker som trengs for maskinlæring og ikke inkludert i standarddistribusjonen av operativsystemet (og det som var det var feil versjoner), hacks med innstillinger, behovet for ulike versjoner for ulike tjenester som bodde på samme vertssystem førte til dette, at den eneste rimelige måten å levere denne atomblandingen på var havnearbeideren. Arbeidsintensiteten ved å sette sammen en docker-container viste seg å være lavere enn ideen om å pakke det hele inn i separate deb-pakker med avhengigheter, og faktisk ville ingen ved sitt rette sinn påta seg dette.
Det andre punktet hvor det er planlagt å bruke Docker er å distribuere tjenester i henhold til den blågrønne distribusjonsordningen. Men her ønsker jeg å få en gradvis økning i kompleksiteten: først bygges deb-pakker, og deretter bygges en docker-container av dem.
Snap pakker
La oss gå tilbake til snap-pakker. De dukket først offisielt opp i Ubuntu 16.04. I motsetning til de vanlige deb-pakkene og rpm-pakkene, har snap alle avhengighetene. På den ene siden lar dette deg unngå bibliotekskonflikter, på den annen side er den resulterende pakken større i størrelse. I tillegg kan dette også påvirke sikkerheten til systemet: Ved snap-levering må alle endringer i de inkluderte bibliotekene overvåkes av utvikleren som lager pakken. Generelt er ikke alt så enkelt og universell lykke kommer ikke fra å bruke dem. Men ikke desto mindre er dette et helt rimelig alternativ hvis den samme Docker bare brukes som et pakkeverktøy og ikke for virtualisering.
Som et resultat bruker vi nå både deb-pakker og docker-containere i en rimelig kombinasjon, som vi kanskje i noen tilfeller vil erstatte med snap-pakker.
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Hva bruker du til levering?
-
Selvskrevne manus
-
Kopier manuelt til FTP
-
deb-pakker
-
rpm-pakker
-
snap pakker
-
Docker-bilder
-
Virtuelle maskinbilder
-
Klon hele harddisken
-
dukketeater
-
ansible
-
andre
109 brukere stemte. 32 brukere avsto.
Kilde: www.habr.com