Vi starter vores blog med publikationer baseret på de seneste taler fra vores tekniske direktør (Dmitry Stolyarov). Alle fandt sted i 2016 ved forskellige professionelle arrangementer og var dedikeret til emnet DevOps og Docker. En video fra Docker Moskva-mødet på Badoo-kontoret har vi allerede Online. Nye vil blive ledsaget af artikler, der formidler essensen af rapporterne. Så…
31. maj på konferencen , afholdt som en del af festivalen "Russian Internet Technologies" (RIT++ 2016), åbnede afsnittet "Continuous Deployment and Deployment" med rapporten "Best Practices of Continuous Delivery with Docker". Den opsummerede og systematiserede de bedste praksisser for opbygning af en kontinuerlig leveringsproces (CD) ved hjælp af Docker og andre Open Source-produkter. Vi arbejder med disse løsninger i produktionen, hvilket giver os mulighed for at stole på praktisk erfaring.
Hvis du har mulighed for at bruge en time , anbefaler vi, at du ser det fuldt ud. Ellers er nedenstående hovedresumé i tekstform.
Kontinuerlig levering med Docker
under Kontinuerlig tilførsel vi forstår kæden af begivenheder som et resultat af, at applikationskoden fra Git repository først kommer til produktion og derefter ender i arkivet. Det ser sådan ud: Git → Byg → Test → Frigiv → Betjen.
Det meste af rapporten er afsat til byggefasen (applikationssamling), og emnerne frigivelse og drift berøres kort. Vi vil tale om problemer og mønstre, der giver dig mulighed for at løse dem, og de specifikke implementeringer af disse mønstre kan være anderledes.
Hvorfor er der overhovedet brug for Docker her? Det er ikke for ingenting, at vi besluttede at tale om kontinuerlig leveringspraksis i forbindelse med dette Open Source-værktøj. Selvom hele rapporten er viet til dens brug, afsløres mange årsager, når man overvejer hovedmønsteret for udrulning af applikationskode.
Hovedudrulningsmønster
Så når vi udruller nye versioner af applikationen, står vi bestemt over for nedetidsproblem, genereret under skift af produktionsserveren. Trafik fra den gamle version af applikationen til den nye kan ikke skifte øjeblikkeligt: Først skal vi sikre os, at den nye version ikke kun er succesfuldt downloadet, men også "varmet op" (dvs. helt klar til at betjene anmodninger).
I nogen tid vil begge versioner af applikationen (gamle og nye) således fungere samtidigt. Hvilket automatisk fører til konflikt med fælles ressourcer: netværk, filsystem, IPC osv. Med Docker løses dette problem nemt ved at køre forskellige versioner af applikationen i separate containere, for hvilke ressourceisolering er garanteret inden for samme vært (server/virtuel maskine). Selvfølgelig kan du klare dig med nogle tricks uden isolering overhovedet, men hvis der er et færdiglavet og praktisk værktøj, så er der den modsatte grund - ikke at forsømme det.
Containerisering giver mange andre fordele, når den implementeres. Enhver ansøgning afhænger af specifik version (eller versionsområde) tolk, tilgængelighed af moduler/udvidelser osv., samt deres versioner. Og det gælder ikke kun det umiddelbare eksekverbare miljø, men også hele miljøet, herunder systemsoftware og dens version (op til den anvendte Linux-distribution). På grund af det faktum, at containere ikke kun indeholder applikationskode, men også forudinstalleret system- og applikationssoftware af de nødvendige versioner, kan du glemme problemer med afhængigheder.
Lad os generalisere hovedudrulningsmønster nye versioner under hensyntagen til følgende faktorer:
- Først kører den gamle version af applikationen i den første container.
- Den nye version rulles derefter ud og "varmes op" i en anden beholder. Det er bemærkelsesværdigt, at denne nye version i sig selv kan bære ikke kun opdateret applikationskode, men også enhver af dens afhængigheder såvel som systemkomponenter (for eksempel en ny version af OpenSSL eller hele distributionen).
- Når den nye version er helt klar til at betjene anmodninger, skifter trafikken fra den første container til den anden.
- Den gamle version kan nu stoppes.
Denne tilgang med at implementere forskellige versioner af applikationen i separate containere giver en anden bekvemmelighed - hurtig tilbagerulning til den gamle version (det er trods alt nok at skifte trafik til den ønskede container).
Den sidste første anbefaling lyder som noget, som selv kaptajnen ikke kunne finde fejl i: "[når du organiserer kontinuerlig levering med Docker] Brug Docker [og forstå, hvad det giver]" Husk, at dette ikke er en sølvkugle, der løser ethvert problem, men et værktøj, der giver et vidunderligt fundament.
Reproducerbarhed
Med "reproducerbarhed" mener vi et generaliseret sæt af problemer, der opstår under drift af applikationer. Vi taler om sådanne tilfælde:
- Scripts, der kontrolleres af kvalitetsafdelingen til iscenesættelse, skal gengives nøjagtigt i produktionen.
- Applikationer udgives på servere, der kan modtage pakker fra forskellige repository-spejle (over tid opdateres de, og med dem versionerne af installerede applikationer).
- “Alt fungerer for mig lokalt!” (...og udviklere må ikke komme i produktion.)
- Du skal tjekke noget i den gamle (arkiverede) version.
- ...
Deres generelle essens koger ned til det faktum, at fuld overholdelse af de anvendte miljøer (såvel som fraværet af den menneskelige faktor) er nødvendig. Hvordan kan vi garantere reproducerbarhed? Lav Docker-billeder baseret på kode fra Git, og brug dem derefter til enhver opgave: på teststeder, i produktionen, på programmørers lokale maskiner... Samtidig er det vigtigt at minimere de handlinger, der udføres efter samle billedet: Jo enklere det er, jo mindre sandsynligt er der fejl.
Infrastruktur er kode
Hvis infrastrukturkravene (tilgængelighed af serversoftware, dens version osv.) ikke er formaliserede og "programmerede", kan udrulningen af enhver applikationsopdatering resultere i katastrofale konsekvenser. For eksempel, i iscenesættelse har du allerede skiftet til PHP 7.0 og omskrevet koden i overensstemmelse hermed - så vil dens udseende i produktion med noget gammelt PHP (5.5) helt sikkert overraske nogen. Du må ikke glemme en større ændring i tolkeversionen, men "djævelen er i detaljerne": overraskelsen kan være i en mindre opdatering af enhver afhængighed.
En tilgang til at løse dette problem er kendt som IaC (Infrastruktur som kode, "infrastruktur som kode") og involverer lagring af infrastrukturkrav sammen med applikationskoden. Ved at bruge det kan udviklere og DevOps-specialister arbejde med det samme Git-applikationsdepot, men på forskellige dele af det. Ud fra denne kode oprettes et Docker-image i Git, hvor applikationen implementeres under hensyntagen til alle detaljerne i infrastrukturen. Enkelt sagt skal scripts (reglerne) til at samle billeder være i det samme lager med kildekoden og flettes sammen.
I tilfælde af en flerlags applikationsarkitektur - for eksempel er der nginx, som står foran en applikation, der allerede kører inde i en Docker-container - skal Docker-billeder oprettes fra kode i Git for hvert lag. Så vil det første billede indeholde en applikation med en fortolker og andre "nære" afhængigheder, og det andet billede vil indeholde opstrøms nginx.
Docker-billeder, kommunikation med Git
Vi opdeler alle Docker-billeder indsamlet fra Git i to kategorier: midlertidige og frigivet. Midlertidige billeder tagget med navnet på filialen i Git, kan overskrives af den næste commit og udrulles kun til forhåndsvisning (ikke til produktion). Dette er deres vigtigste forskel fra udgivelser: du ved aldrig, hvilken specifik commit der er i dem.
Det giver mening at samle i midlertidige billeder: mastergrenen (du kan automatisk rulle den ud til et separat websted for konstant at se den aktuelle version af master), grene med udgivelser, grene af specifikke innovationer.
Efter forhåndsvisningen af midlertidige billeder kommer til behovet for oversættelse til produktion, satte udviklerne et bestemt tag. Automatisk indsamlet af tag frigive billede (dets tag svarer til tagget fra Git) og rulles ud til iscenesættelse. Hvis det er succesfuldt verificeret af kvalitetsafdelingen, går det til produktion.
DAI
Alt beskrevet (udrulning, billedsamling, efterfølgende vedligeholdelse) kan implementeres uafhængigt ved hjælp af Bash-scripts og andre "improviserede" værktøjer. Men hvis du gør dette, så vil implementeringen på et tidspunkt føre til stor kompleksitet og dårlig kontrollerbarhed. For at forstå dette kom vi til at skabe vores eget specialiserede Workflow-værktøj til at bygge CI/CD - DAI.
Dens kildekode er skrevet i Ruby, open source og offentliggjort på . Desværre er dokumentation i øjeblikket det svageste punkt ved værktøjet, men vi arbejder på det. Og vi vil skrive og tale om dappen mere end én gang, fordi... Vi kan oprigtigt ikke vente med at dele dets muligheder med hele det interesserede fællesskab, men i mellemtiden, send dine problemer og træk anmodninger og/eller følg udviklingen af projektet på GitHub.
Opdateret 13. august 2019: i øjeblikket et projekt DAI omdøbt til , dens kode er blevet fuldstændig omskrevet i Go, og dens dokumentation er blevet væsentligt forbedret.
Kubernetes
Et andet færdiglavet Open Source-værktøj, der allerede har fået betydelig anerkendelse i det professionelle miljø er Kubernetes,en Docker management klynge. Emnet for dets brug i driften af projekter bygget på Docker ligger uden for rapportens omfang, så præsentationen er begrænset til en oversigt over nogle interessante funktioner.
Til udrulning tilbyder Kubernetes:
- parathedssonde — kontrol af klarheden af en ny version af applikationen (for at skifte trafik til den);
- rullende opdatering - sekventiel billedopdatering i en klynge af containere (nedlukning, opdatering, forberedelse til lancering, trafikskift);
- synkron opdatering - opdatering af et billede i en klynge med en anden tilgang: først på halvdelen af beholderne, derefter på resten;
- canary releases - lancering af et nyt billede på et begrænset (lille) antal beholdere for at overvåge uregelmæssigheder.
Da Continuous Delivery ikke kun er udgivelsen af en ny version, har Kubernetes en række muligheder for efterfølgende infrastrukturvedligeholdelse: indbygget overvågning og logning for alle containere, automatisk skalering osv. Alt dette virker allerede og venter bare på ordentlig implementering i dine processer.
Endelige anbefalinger
- Brug Docker.
- Opret Docker-billeder af applikationer til alle dine behov.
- Følg princippet "Infrastruktur er kode."
- Link Git til Docker.
- Reguler rækkefølgen af udrulning.
- Brug en færdiglavet platform (Kubernetes eller en anden).
Videoer og dias
Video fra forestillingen (ca. en time) (selve rapporten starter fra 5. minut - følg linket for at spille fra dette øjeblik).
Præsentation af rapporten:
PS
Andre rapporter om emnet på vores blog:
- «» (Dmitry Stolyarov; 27. maj 2019 på DevOpsConf);
- «» (Dmitry Stolyarov; 8. november 2018 på HighLoad++);
- «» (Dmitry Stolyarov; 7. november 2017 på HighLoad++);
- «» (Dmitry Stolyarov; 6. juni 2017 på RootConf).
Kilde: www.habr.com