Sådan bliver du DevOps-ingeniør om seks måneder eller mindre, del 4: Pakke

“Pakker” af chuttersnap på Unsplash

Hurtig opsamling

I del 1 talte vi om DevOps-kulturen og de krævede fundamenter:

I del 2 drøftede vi, hvordan man korrekt lægger grundlaget for fremtidige kodedistribution:

I del 3 talte vi om, hvordan du holder din implementerede kode organiseret:

Her skal vi tale om, hvordan du pakker din kode for nem distribution og efterfølgende udførelse.

Som reference er vi her på vores rejse:

Pakke

BEMÆRK: Du kan se, hvordan hver del bygger på den forrige del og lægger grundlaget for den efterfølgende del. Dette er vigtigt og gøres med vilje.

Årsagen er, uanset om du taler med dine nuværende eller fremtidige arbejdsgivere, skal du være i stand til at formulere, hvad DevOps er, og hvorfor det er vigtigt.

Og du gør det ved at fortælle en sammenhængende historie - en historie om, hvordan man bedst hurtigt kan sende kode fra en udviklers bærbare computer til en pengeudviklende produktudvikling.

Derfor er vi ikke efter at have lært en masse afkoblede, trendy DevOps-værktøjer. Vi er efter at have lært et sæt færdigheder, drevet af forretningsbehov, støttet af tekniske værktøjer.

Og husk, at hver fase er en måneds værd at lære, i alt seks måneder.

OK, nok snak, lad os komme til det!

Grundlæggende om virtualisering

Kan du huske fysiske servere? Dem, du skulle vente uger for at blive PO-godkendt, sendt, datacenter accepteret, racket, netværk, OS-installeret og lappet?

Ja, de. De kom først.

Forestil dig i det væsentlige, hvis den eneste måde at få et sted at bo på er at bygge et helt nyt hus. Brug for et sted at bo? Vent uanset hvor lang tid det tager! Slags cool, da alle får et hus, men heller ikke rigtig, fordi det tager lang tid at bygge et hus. I denne analogi er en fysisk server ligesom et hus.

Derefter blev folk irriterede over, hvor lang tid alt tog, og nogle virkelig smarte mennesker kom med idéen om virtualisering: hvordan man kører en flok foregive “maskiner” på en enkelt fysisk maskine og lader hver falske maskine foregive at være en rigtig maskine. Geni!

Så hvis du virkelig ville have et hus, kunne du bygge dit eget og vente i seks uger. Eller du kan gå og bo i en lejlighedsbygning og dele ressourcerne med andre lejere. Måske ikke så fantastisk, men godt nok! Og vigtigst af alt er der ingen ventetid!

Dette gik i et stykke tid, og virksomheder (dvs. VMWare) begik et absolut dræb på dette.

Indtil andre smarte mennesker besluttede, at fylde en masse virtuelle maskiner i en fysisk maskine ikke er god nok: vi har brug for mere kompakt pakning af flere processer i færre ressourcer.

På dette tidspunkt er et hus for dyrt og en lejlighed er stadig for dyrt. Hvad hvis jeg bare har brug for et værelse til leje midlertidigt? Det er forbløffende, jeg kan bevæge mig ind og ud på et øjeblik!

I det væsentlige er det Docker.

BEMÆRK: Fra december 2018,

Fødsel af Docker

Docker er ny, men ideen bag Docker er meget gammel. Et operativsystem kaldet FreeBSD havde et koncept med fængsler, der kan dateres tilbage til 2000! Virkelig alt nyt er gammelt.

Idéen var nu og nu at isolere individuelle processer inden for det samme operativsystem i det, der er kendt som "virtualisering af operativsystemniveau."

BEMÆRK: Dette er ikke det samme som “fuld virtualisering”, der kører virtuelle maskiner side om side på den samme fysiske vært.

Hvad betyder dette i praksis?

I praksis betyder det, at stigningen i Dockers popularitet pænt afspejler fremkomsten af ​​mikroservices - en softwareteknisk tilgang, hvor software er opdelt i mange individuelle komponenter.

Og disse komponenter har brug for et hjem. Det er en enorm smerte at distribuere dem individuelt som fristående Java-applikationer eller binære eksekverbare: hvordan du administrerer en Java-app er forskellig fra, hvordan du administrerer en C ++ -app, og det er anderledes end du administrerer en Golang-app.

I stedet leverer Docker en enkelt administrationsgrænseflade, der giver softwareingeniører mulighed for at pakke (!), Distribuere og køre forskellige applikationer på en ensartet måde.

Det er en enorm gevinst!

OK, lad os tale mere om fordele og ulemper ved Docker.

Fordele ved Docker

Processisolering

Docker tillader, at enhver service har fuld procesisolering. Service A lever i sin egen lille container med alle dens afhængigheder. Service B lever i sin container med alle dens afhængigheder. Og de to er ikke i konflikt!

Derudover påvirkes kun den beholder, hvis en container går ned. Resten vil (skal!) Fortsætte med at køre lykkeligt.

Dette gavner også sikkerhed. Hvis en container er kompromitteret, er det ekstremt vanskeligt (men ikke umuligt!) At komme ud af beholderen og hacke basis-OS.

Endelig, hvis en beholder ikke opfører sig (forbruger for meget CPU eller hukommelse), er det muligt at "indeholde" sprængradiusen til den beholder kun uden at påvirke resten af ​​systemet.

Deployment

Tænk over, hvordan de forskellige applikationer er bygget i praksis.

Hvis det er en Python-app, vil den have en række forskellige Python-pakker. Nogle vil blive installeret som pip-moduler, andre er rpm eller deb-pakker, og andre er enkle git-kloninstallationer. Eller, hvis det er gjort med virtualenv, vil det være en zip-fil med alle afhængigheder i virtualenv-biblioteket.

På den anden side, hvis det er en Java-app, vil den have en gradle build, med alle dens afhængigheder trukket og drysset til passende steder.

Du får poenget. Forskellige apps, bygget med forskellige sprog og forskellige driftstider, udgør en udfordring, når det kommer til at implementere disse apps til prod.

Hvordan kan vi muligvis holde alle afhængigheder tilfredse?

Plus, problemet er værre, hvis der er konflikter. Hvad hvis service A afhænger af Python bibliotek v1, men service B afhænger af Python bibliotek v2? Nu er der en konflikt, da både v1 og v2 ikke kan eksistere på samme maskine.

Gå ind i Docker.

Docker tillader ikke kun fuld procesisolering men også fuld afhængighedsisolering. Det er fuldstændigt muligt og almindeligt at have flere containere, der kører side om side, på det samme operativsystem, hver med sine egne og modstridende biblioteker og pakker.

Runtime Management

Igen, hvordan vi administrerer forskellige applikationer, er forskellige mellem applikationer. Java-kodelogger forskelligt, startes forskelligt og overvåges anderledes end Python. Og Python er forskellig fra Golang osv.

Med Docker får vi en enkelt, samlet styringsgrænseflade, der giver os mulighed for at starte, overvåge, centralisere logfiler, stoppe og genstarte mange forskellige slags applikationer.

Dette er en enorm gevinst og reducerer driftsomkostningerne ved kørende produktionssystemer kraftigt.

BEMÆRK: Fra december 2018 behøver du ikke længere at vælge mellem hurtig opstart af Docker og VMs-sikkerhed. Project Firecracker, høflighed fra Amazon, forsøger at smelte sammen det bedste fra begge verdener. Stadig er dette en meget ny teknik og ikke til at blive implementeret til prod lige nu.

Dog så awesome som Docker er, har det ulemper.

Gå ind i Lambda

Først kører Docker stadig servere. Serverne er sprøde og flassende. De skal styres, lappes og på anden måde plejes.

For det andet er Docker ikke 100% sikker. Ikke som en VM, i det mindste. Der er en grund til, at enorme virksomheder, der driver hostede containere, gør det inde i VM'er, ikke på toppen af ​​bare metal. De vil have hurtige opstartstider med containere og VM's sikkerhed!

For det tredje kører ingen virkelig Docker, som den er. I stedet er det næsten altid brugt som en del af et komplekst containerorkestreringsstof, såsom Kubernetes, ECS, docker-swarm eller Nomad. Dette er temmelig komplekse platforme, der kræver dedikeret personale til at operere (mere om disse løsninger senere).

Hvis jeg imidlertid er en udvikler, vil jeg bare skrive kode og få nogen anden til at køre den for mig. Docker, Kubernetes og al den jazz er ikke enkle ting at lære - skal jeg virkelig ?!

Kort svar er, det afhænger!

For mennesker, der bare vil have nogen til at køre deres kode, er AWS Lambda (og andre lignende løsninger) svaret:

AWS Lambda giver dig mulighed for at køre kode uden at levere eller styre servere. Du betaler kun for den beregnede tid, du forbruger - der koster ikke noget, når din kode ikke kører.

Hvis du har hørt om hele den "serverløse" bevægelse, er det her! Ikke flere servere at køre eller containere til at administrere. Skriv bare din kode, pak den ind i en zip-fil, upload til Amazon og lad dem håndtere hovedpine!

Da Lambdas er kortvarige, er der desuden intet at hacke - Lambdas er temmelig sikre ved design.

Fantastisk, er det ikke?

Det er men (overraskelse!) Der er advarsler.

For det første kan Lambdas kun køre i maks. 15 minutter (fra november 2018). Dette indebærer, at processer med lang drift, som Kafka-forbrugere eller antal knusende apps, ikke kan køre i Lambda.

For det andet er Lambdas Funktioner-som-en-tjeneste, hvilket betyder, at din ansøgning skal nedbrydes fuldstændigt til mikroservices og orkestreres med andre komplekse PaaS-tjenester som AWS Trinfunktioner. Ikke alle virksomheder er på dette niveau af mikroservicearkitektur.

For det tredje er fejlfinding af Lambdas vanskelige. De er sky-native runimes, og al bug fixing finder sted inden for Amazon økosystem. Dette er ofte udfordrende og ikke-intuitivt.

Kort sagt, der er ingen gratis frokost.

BEMÆRK: Der er nu også “serverløse” cloud-containerløsninger. AWS Fargate er en sådan tilgang. Mekanikken er stort set ens. Faktisk, hvis du lige er startet, anbefaler jeg stærkt at give Fargate en prøve - det er en utrolig nem måde at få containere, der kører "på den rigtige måde."

UPDATE 1/13/2019: AWS annoncerede netop en betydelig prisnedsættelse for Fargate, hvilket nu gør det til et meget attraktivt valg at køre “serverløse” containere.

Resumé

Docker og Lambda er to af de mest populære moderne sky-native tilgange til emballering, drift og styring af produktionsapplikationer.

De er ofte gratis, hver egnet til lidt forskellige brugssager og applikationer.

Uanset hvad skal en moderne DevOps-ingeniør være godt bevandret i begge dele. Derfor er det at lære Docker og Lambda gode mål på kort og mellemlang sigt.

BEMÆRK: Hidtil i vores serie har vi behandlet emner, som Junior til Mid-Level DevOps Engineers forventes at kende. I de efterfølgende afsnit vil vi begynde at diskutere teknikker, der er mere velegnede til mellemniveau og Senior DevOps Engineers. Som altid er der dog ingen genveje at opleve!

Næste

For at lære alt om den moderne implementeringspraksis, skal du læse videre!