Vi vil starte bloggen vår med publikasjoner basert på de siste talene til vår tekniske direktør (Dmitry Stolyarov). Alle fant sted i 2016 på ulike profesjonelle arrangementer og var dedikert til temaet DevOps og Docker. En video fra Docker Moskva-møtet på Badoo-kontoret har vi allerede På nett. Nye vil bli ledsaget av artikler som formidler essensen av rapportene. Så…
31. mai på konferansen , holdt som en del av festivalen "Russian Internet Technologies" (RIT++ 2016), åpnet delen "Kontinuerlig utrulling og utrulling" med rapporten "Beste praksiser for kontinuerlig levering med Docker". Den oppsummerte og systematiserte beste praksis for å bygge en kontinuerlig leveringsprosess (CD) ved å bruke Docker og andre åpen kildekode-produkter. Vi jobber med disse løsningene i produksjonen, noe som gjør at vi kan stole på praktisk erfaring.
Hvis du har mulighet til å bruke en time , vi anbefaler å se den i sin helhet. Ellers nedenfor er hovedoppsummeringen i tekstform.
Kontinuerlig levering med Docker
under Kontinuerlig Levering vi forstår hendelseskjeden som et resultat av at applikasjonskoden fra Git-depotet først kommer til produksjon, og deretter havner i arkivet. Hun ser slik ut: Git → Bygg → Test → Frigjør → Betjen.
Mesteparten av rapporten er viet byggestadiet (applikasjonsmontering), og emnene utgivelse og drift berøres kort. Vi vil snakke om problemer og mønstre som lar deg løse dem, og de spesifikke implementeringene av disse mønstrene kan være forskjellige.
Hvorfor trengs Docker her i det hele tatt? Det er ikke for ingenting at vi bestemte oss for å snakke om kontinuerlig leveringspraksis i sammenheng med dette Open Source-verktøyet. Selv om hele rapporten er viet til bruken, avsløres mange årsaker når man vurderer hovedmønsteret for utrulling av applikasjonskode.
Hovedutrullingsmønster
Så når vi ruller ut nye versjoner av applikasjonen, står vi absolutt overfor nedetidsproblem, generert under bytte av produksjonsserveren. Trafikk fra den gamle versjonen av applikasjonen til den nye kan ikke bytte umiddelbart: først må vi sørge for at den nye versjonen ikke bare er vellykket nedlastet, men også "varmet opp" (dvs. helt klar til å betjene forespørsler).
Dermed vil begge versjonene av applikasjonen (gamle og nye) fungere samtidig. Som automatisk fører til konflikt med delte ressurser: nettverk, filsystem, IPC, etc. Med Docker løses dette problemet enkelt ved å kjøre forskjellige versjoner av applikasjonen i separate containere, for hvilke ressursisolasjon er garantert innenfor samme vert (server/virtuell maskin). Selvfølgelig kan du klare deg med noen triks uten isolasjon i det hele tatt, men hvis det er et ferdiglaget og praktisk verktøy, så er det motsatt grunn - ikke å forsømme det.
Containerisering gir mange andre fordeler når den distribueres. Enhver søknad avhenger av spesifikk versjon (eller versjonsområde) tolk, tilgjengelighet av moduler/utvidelser osv., samt deres versjoner. Og dette gjelder ikke bare det umiddelbare kjørbare miljøet, men også hele miljøet, inkludert systemprogramvare og versjonen (opptil Linux-distribusjonen som brukes). På grunn av det faktum at containere ikke bare inneholder applikasjonskode, men også forhåndsinstallert system- og applikasjonsprogramvare for de nødvendige versjonene, kan du glemme problemer med avhengigheter.
La oss generalisere hovedutrullingsmønster nye versjoner som tar hensyn til følgende faktorer:
- Til å begynne med kjører den gamle versjonen av applikasjonen i den første beholderen.
- Den nye versjonen rulles deretter ut og "varmes opp" i en annen beholder. Det er bemerkelsesverdig at denne nye versjonen i seg selv kan inneholde ikke bare oppdatert applikasjonskode, men også hvilken som helst av dens avhengigheter, så vel som systemkomponenter (for eksempel en ny versjon av OpenSSL eller hele distribusjonen).
- Når den nye versjonen er helt klar til å betjene forespørsler, bytter trafikken fra den første beholderen til den andre.
- Den gamle versjonen kan nå stoppes.
Denne tilnærmingen med å distribuere forskjellige versjoner av applikasjonen i separate beholdere gir en annen bekvemmelighet - rask tilbakerulling til den gamle versjonen (tross alt er det nok å bytte trafikk til ønsket container).
Den endelige første anbefalingen høres ut som noe som selv kapteinen ikke kunne finne feil med: "[når du organiserer kontinuerlig levering med Docker] Bruk Docker [og forstå hva det gir]" Husk at dette ikke er en sølvkule som vil løse alle problemer, men et verktøy som gir et fantastisk grunnlag.
Reproduserbarhet
Med "reproduserbarhet" mener vi et generalisert sett med problemer som oppstår under drift av applikasjoner. Vi snakker om slike tilfeller:
- Skript kontrollert av kvalitetsavdelingen for iscenesettelse skal være nøyaktig gjengitt i produksjonen.
- Applikasjoner publiseres på servere som kan motta pakker fra forskjellige depotspeil (over tid oppdateres de, og med dem versjonene av installerte applikasjoner).
- "Alt fungerer for meg lokalt!" (...og utviklere er ikke tillatt i produksjon.)
- Du må sjekke noe i den gamle (arkiverte) versjonen.
- ...
Deres generelle essens koker ned til det faktum at full overholdelse av miljøene som brukes (så vel som fraværet av den menneskelige faktoren) er nødvendig. Hvordan kan vi garantere reproduserbarhet? Lag Docker-bilder basert på kode fra Git, og deretter bruke dem til enhver oppgave: på teststeder, i produksjon, på lokale maskiner til programmerere... Samtidig er det viktig å minimere handlingene som utføres etter sette sammen bildet: jo enklere det er, jo mindre sannsynlig er det feil.
Infrastruktur er kode
Hvis infrastrukturkravene (tilgjengelighet av serverprogramvare, dens versjon, osv.) ikke er formalisert og "programmert", kan utrullingen av enhver applikasjonsoppdatering føre til katastrofale konsekvenser. For eksempel, i iscenesettelse har du allerede byttet til PHP 7.0 og skrevet om koden tilsvarende - da vil dens utseende i produksjon med noe gammelt PHP (5.5) sikkert overraske noen. Du glemmer kanskje ikke en stor endring i tolkeversjonen, men "djevelen er i detaljene": overraskelsen kan være i en mindre oppdatering av enhver avhengighet.
En tilnærming for å løse dette problemet er kjent som IaC (Infrastruktur som kode, "infrastruktur som kode") og innebærer lagring av infrastrukturkrav sammen med applikasjonskoden. Ved å bruke det kan utviklere og DevOps-spesialister jobbe med det samme Git-applikasjonsarkivet, men på forskjellige deler av det. Fra denne koden opprettes et Docker-bilde i Git, der applikasjonen distribueres under hensyntagen til alle spesifikasjonene til infrastrukturen. Enkelt sagt bør skriptene (reglene) for å sette sammen bilder være i samme depot med kildekoden og flettes sammen.
Når det gjelder en flerlags applikasjonsarkitektur - for eksempel er det nginx, som står foran en applikasjon som allerede kjører inne i en Docker-beholder - Docker-bilder må lages fra kode i Git for hvert lag. Da vil det første bildet inneholde en applikasjon med tolk og andre "nære" avhengigheter, og det andre bildet vil inneholde oppstrøms nginx.
Docker-bilder, kommunikasjon med Git
Vi deler alle Docker-bilder samlet inn fra Git i to kategorier: midlertidig og utgivelse. Midlertidige bilder merket med navnet på grenen i Git, kan overskrives av neste commit og rulles ut kun for forhåndsvisning (ikke for produksjon). Dette er deres viktigste forskjell fra utgivelser: du vet aldri hvilken spesifikk forpliktelse som er i dem.
Det er fornuftig å samle inn i midlertidige bilder: mastergrenen (du kan automatisk rulle den ut til et eget nettsted for hele tiden å se den gjeldende versjonen av master), grener med utgivelser, grener av spesifikke innovasjoner.
Etter at forhåndsvisningen av midlertidige bilder kommer til behovet for oversettelse til produksjon, satte utviklerne en bestemt kode. Automatisk samlet av tag utgivelsesbilde (taggen tilsvarer taggen fra Git) og rulles ut til iscenesettelse. Hvis det er vellykket verifisert av kvalitetsavdelingen, går det til produksjon.
Dapp
Alt beskrevet (utrulling, bildemontering, påfølgende vedlikehold) kan implementeres uavhengig ved hjelp av Bash-skript og andre "improviserte" verktøy. Men hvis du gjør dette, vil implementeringen på et tidspunkt føre til stor kompleksitet og dårlig kontrollerbarhet. For å forstå dette kom vi til å lage vårt eget spesialiserte Workflow-verktøy for å bygge CI/CD - Dapp.
Kildekoden er skrevet i Ruby, åpen kildekode og publisert på . Dessverre er dokumentasjon foreløpig det svakeste punktet ved verktøyet, men vi jobber med det. Og vi vil skrive og snakke om dappen mer enn en gang, fordi... Vi kan oppriktig ikke vente med å dele dens evner med hele det interesserte fellesskapet, men i mellomtiden kan du sende problemene dine og trekke forespørsler og/eller følge utviklingen av prosjektet på GitHub.
Oppdatert 13. august 2019: for tiden et prosjekt Dapp omdøpt til , koden har blitt fullstendig omskrevet i Go, og dokumentasjonen er betydelig forbedret.
Kubernetes
Et annet ferdiglaget Open Source-verktøy som allerede har fått betydelig anerkjennelse i fagmiljøet er Kubernetes,en Docker-administrasjonsklynge. Temaet for bruk i driften av prosjekter bygget på Docker er utenfor rammen av rapporten, så presentasjonen er begrenset til en oversikt over noen interessante funksjoner.
For utrulling tilbyr Kubernetes:
- beredskapsprobe — sjekke beredskapen til en ny versjon av applikasjonen (for å bytte trafikk til den);
- rullende oppdatering - sekvensiell bildeoppdatering i en klynge av containere (avslutning, oppdatering, forberedelse til lansering, trafikkbytte);
- synkron oppdatering - oppdatering av et bilde i en klynge med en annen tilnærming: først på halvparten av beholderne, deretter på resten;
- canary-utgivelser - lanserer et nytt bilde på et begrenset (lite) antall beholdere for å overvåke uregelmessigheter.
Siden Continuous Delivery ikke bare er utgivelsen av en ny versjon, har Kubernetes en rekke muligheter for påfølgende vedlikehold av infrastrukturen: innebygd overvåking og logging for alle containere, automatisk skalering osv. Alt dette fungerer allerede og venter bare på ordentlig implementering i dine prosesser.
Endelige anbefalinger
- Bruk Docker.
- Lag Docker-bilder av applikasjoner for alle dine behov.
- Følg prinsippet "Infrastruktur er kode."
- Koble Git til Docker.
- Reguler rekkefølgen på utrullingen.
- Bruk en ferdig plattform (Kubernetes eller en annen).
Videoer og lysbilder
Video fra forestillingen (ca. en time) (selve rapporten starter fra 5. minutt - følg lenken for å spille fra dette øyeblikket).
Presentasjon av rapporten:
PS
Andre rapporter om emnet på bloggen vår:
- «» (Dmitry Stolyarov; 27. mai 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