Blue-Green Deployment og dens rolle i DevOps forklart

Tradisjonelle «big bang»-tilnærminger til programvareutvikling er inkompatible med den høye fleksibiliteten, smidigheten og kontinuerlige utrullingskravene til dagens sky- og DevOps-programvareplattformer.

Det er bare ikke nok å utarbeide en sjekkliste over manuelle trinn som skal utføres under distribusjon av produksjonsutgivelsen. Hvis du gjør det, er du ikke veldig smidig, og du er heller ikke en skikkelig DevOps.

Blue-Green Deployment: En oversikt

Blue-Green-distribusjon er en tilnærming til programvaredistribusjon som reduserer nedetid og risiko for nye programvareversjoner ved å lage to identiske miljøer: aktiv (blå) og inaktiv (grønn).

Det aktive miljøet er der den gjeldende versjonen av programvaren kjører, og brukerne genererer produksjonstrafikk. Det inaktive miljøet er der den nye versjonen av programvaren distribueres og testes.

Når den nye versjonen er testet og klar, byttes trafikken fra det aktive miljøet til det inaktive miljøet, noe som gjør det til det nye aktive miljøet. Du kan gjenta denne prosessen etter behov.

Kilde: docs.aws.amazon.com

DevOps-kontekst

Blue-Green-distribusjon passer godt med DevOps-tankegangen og -prosessene fordi den støtter kontinuerlig levering og distribusjon av programvare samtidig som den minimerer nedetid for produksjonsbrukere og eliminerer risikoen for feil i produksjonsutgivelsen.

Å ha to identiske miljøer gjør det mulig å teste og distribuere nye versjoner av programvare uten å påvirke gjeldende produksjonsmiljø. Dette betyr raskere og hyppigere utgivelser, som er et sentralt aspekt ved DevOps.

I tillegg er muligheten til å bytte trafikk mellom miljøer raskt en primær forutsetning for rask tilbakerulling ved problemer, noe som også er viktig i et DevOps-miljø.

Nøkkelprinsipper for blågrønn distribusjon

#1. To identiske miljøer

Blue-Green-distribusjon krever at du oppretter to identiske miljøer. Det betyr identisk fra data- og prosesssynspunkt. Den ene er aktiv (blå), og den andre er inaktiv (grønn).

Det blå miljøet er der produksjonsbrukere kjører sine daglige prosesser. Det grønne miljøet er alltid synkronisert med det blå, men testerne kjører testsakene sine der. Selv om dette miljøet ikke er produksjonen, kjører du testene under virkelige forhold ettersom det er et produksjonslignende miljø.

#2. Trafikkbryter

Når den nye versjonen av programvaren er testet og klar, byttes trafikken fra det aktive miljøet til det inaktive miljøet, noe som gjør det til det nye aktive miljøet.

Bryteren er øyeblikkelig. All utplasseringen er nå en saga blott. Det er ikke noe nedetidsvindu. Brukere trenger ikke å gjøre noe for å nå det nye miljøet. De omdirigeres automatisk, og alle samtidig.

Kilde: aws.amazon.com

#3. Rask tilbakerulling

Muligheten til å bytte trafikk mellom miljøer raskt betyr også rask tilbakerulling ved problemer. Dette sikrer minimal nedetid, og applikasjonen forblir svært tilgjengelig.

Hvis noe går galt med det grønne miljøet, vil alle brukere umiddelbart bytte tilbake til det stabile originale blå miljøet uten uklarhet.

#4. Automatisert testing

Automatisert testing er et nøkkelaspekt ved Blue-Green-distribusjon. Den sikrer at den nye versjonen av programvaren blir grundig testet før den distribueres til det aktive miljøet.

Hvis du ikke har en betydelig mengde av testene automatisert i systemene dine (inkludert i det minste enhetstester, funksjonstester og regresjonstester), så har det sannsynligvis ikke engang mye mening å tenke på å implementere Blue-Green-implementering.

Mangelen på automatiserte tester vil bremse deg dramatisk. Tiden som kreves for å teste det nye (grønne) miljøet vil være så lang at når du vil være i stand til å bytte til det grønne miljøet, vil det allerede være «for gammelt» sett fra programvareutviklingens livssyklus.

#5. Kontinuerlig levering

Blue-Green distribusjon er en del av en kontinuerlig leveringspipeline, som til syvende og sist betyr raskere og hyppigere utgivelser av programvare i produksjon.

Du kan bytte så snart du er klar til å teste ny programvareversjon på det grønne miljøet. Siden distribusjonen allerede var ferdig og du bare trenger å gjøre selve trafikkbyttet, er det så raskt at du kan gjøre dette hver dag. Forutsatt at du er rask også i testaktiviteter, selvsagt.

Typisk livssyklus

Plattformen som kjører Blue-Green-distribusjon har sin egen spesifikke livssyklus av trinn og prosesser som skal kjøres. Dette er hva det vanligvis består av:

Bygg en ny versjon av programvaren. Dette innebærer å kompilere koden, kjøre automatiserte tester og lage en distribuerbar artefakt.

Det neste trinnet er hvor du distribuerer den nye versjonen av programvaren til det inaktive (grønne) miljøet. Dette innebærer å sette opp miljøet, distribuere artefakten og konfigurere eventuelle nødvendige innstillinger.

Når den nye versjonen av programvaren er distribuert til det grønne miljøet, kjør automatiserte tester for å sikre at den nye versjonen fungerer som den skal. Dette inkluderer funksjonstester, regresjonstester, integrasjonstester og, hvis du er enestående, til og med ytelsestester.

Bytt trafikken fra det aktive (blå) miljøet til det inaktive (grønne) miljøet. Dette innebærer å oppdatere lastbalanseren eller DNS-innstillingene for å dirigere trafikk til det grønne miljøet. Selvfølgelig ønsker du å få dette gjort via automatiserte prosesser.

Når byttet er gjort, overvåk applikasjonen for å sikre at den fungerer som den skal. Dette inkluderer overvåking for feil, ytelsesproblemer og andre problemer.

Dette trinnet er valgfritt, og du vil egentlig ikke nå det for ofte. Men hvis noen oppdager noen vesentlige problemer, bytt trafikken tilbake til det blå miljøet for å utføre en umiddelbar tilbakestilling. Igjen, uten nedetid eller frakobling knyttet til produksjonsbrukere. Bare oppdater belastningsbalanseren eller DNS-innstillingene for å dirigere trafikk til det blå miljøet.

Når du har løst disse problemene og du er klar til å gå tilbake til den nye versjonen igjen, bytter du trafikken tilbake til det grønne miljøet. Så igjen – oppdater belastningsbalanseren eller DNS-innstillingene for å lede trafikk tilbake til det grønne miljøet.

Til slutt, når den nye versjonen av programvaren er stabil og fungerer som den skal, kan du ta den gamle versjonen av programvaren som kjører i det blå miljøet. Du trenger den for å bygge opp en ny versjon av systemet ditt.

Implementering av CI/CD pipelines

Implementering av Blue-Green-distribusjon i en DevOps CI/CD-pipeline skal være en naturlig prosess.

En sterk forutsetning er at du allerede har de to identiske miljøene på plass. Siden dette skal være en automatisert prosess, kan du bruke infrastruktur som et kodeverktøy som f.eks AWS CloudFormation eller til og med skyagnostiker Terraform skript for å lage/gjenskape/oppdatere miljøene for deg innenfor automatiserte pipelines.

Når du har dette, er det et relativt enkelt skritt mot å lage en helautomatisert distribusjonsprosess. Du gjenbruker bare de allerede eksisterende rørledningene for å skape det blå og grønne miljøet. Denne gangen må du imidlertid inkludere testprosesser i pipelinen.

Trafikkbytteprosessen kan du automatisere med verktøy som AWS Elastic Load Balancer eller NGINX. Dette innebærer å oppdatere lastbalanseren eller DNS-innstillingene for å dirigere trafikk til det grønne miljøet når den nye versjonen av programvaren er testet og klar.

Den neste brikken i puslespillet er overvåking. For det, bruk verktøy som AWS CloudWatch, New Relikvieeller Datadog.

Til slutt, gjenbruk eksisterende rørledninger selv for dekommisjonering av det gamle blå miljøet. Det er opp til deg om du først kjører destroy for alle tjenestene og komponentene før du gjenskaper dem fra bunnen av, eller alternativt kan du bare oppdatere skript for hver tjeneste i kjeden. Vanligvis er ødelegge og gjenskape et tryggere alternativ, ettersom med oppdateringen har du mye flere hjørnesaker å vurdere.

Beste praksis for blågrønn distribusjon

Nysgjerrig på hvordan du kan utnytte Blue-Green distribusjon best mulig? Her er noen av tipsene som kommer fra praksisen.

Ha en solid databasemigreringsstrategi

Når du distribuerer en ny versjon av programvaren, er det viktig å sørge for at databaseskjemaet er riktig oppdatert. Bruk en databasemigreringsstrategi som Flyvei eller Liquibase for å administrere databaseskjemaendringer.

Bruk et kanariøyeanalyseverktøy

Selv om Canary-distribusjon er en alternativ tilnærming, kan du fortsatt bruke noen av teknikkene for å perfeksjonere din Blue-Green-distribusjon.

Bruk et kanari-analyseverktøy som f.eks Kayenta eller Spinnaker å analysere ytelsen til den nye versjonen av programvaren i et virkelig miljø. Dette innebærer å sammenligne ytelsen til den nye versjonen av programvaren med ytelsen til den gamle versjonen av programvaren.

Bruk en funksjonsvekslerramme som f.eks Togglz for å aktivere eller deaktivere funksjoner i den nye versjonen av programvaren. Dette gir mulighet for en gradvis utrulling av nye funksjoner og muliggjør rask tilbakerulling om nødvendig.

Bruk en belastningsbalanser med helsesjekker

Bruk en belastningsbalanser som AWS Elastic Load Balancer eller NGINX med helsesjekker for å sikre at trafikken kun ledes til sunne tilfeller. Dette sikrer at applikasjonen forblir svært tilgjengelig og at nedetiden minimeres.

Bruk en tilbakeføringsplan med automatisk tilbakeføring

Ha en tilbakeføringsplan på plass i tilfelle problemer, og automatiser tilbakerullingsprosessen ved å bruke et verktøy som AWS CodeDeploy eller Octopus Deploy. Dette sikrer at nedetid minimeres og at applikasjonen forblir svært tilgjengelig.

Dette gjelder for det meste det grønne miljøet når du oppdager et betydelig problem med den nye versjonen.

Du trenger ikke en tilbakestillingsplan for det blå miljøet, siden denne forblir uberørt av bryteren, og du kan gå tilbake til dette stabile miljøet når det trengs og umiddelbart.

Utfordringer med Blue-Green Deployment

Implementering av Blue-Green-distribusjon kan by på noen utfordringer for utviklingsteam. Her er noen typiske utfordringer:

Å sette opp og administrere to identiske miljøer kan være komplisert og tidkrevende. Dette krever kompetanse innen infrastruktur som kodeverktøy som Terraform eller CloudFormation. Du må ha et seniorutviklingsteam på plass som er i stand til å takle slike tekniske utfordringer.

Når du distribuerer en ny versjon av programvaren, er det viktig å sørge for at databaseskjemaet er riktig oppdatert. Dette kan være utfordrende, spesielt hvis databaseskjemaet er komplekst. Du trenger solide databasedistribusjonsprosesser som kan håndtere skjemaoppdateringsaktivitetene automatisk og pålitelig.

Å analysere ytelsen til den nye versjonen av programvaren i et virkelig miljø kan være utfordrende. Dette krever ekspertise på kanari-analyseverktøy som Kayenta eller Spinnaker.

Implementering av funksjonsvekslinger kan være utfordrende, spesielt hvis applikasjonen har et stort antall funksjoner. Dette krever nøye planlegging og koordinering mellom utviklingsteam.

Å teste den nye versjonen av programvaren i et virkelig miljø kan være utfordrende, spesielt hvis applikasjonen har et stort antall brukere eller servere. Du må ha testsaker automatisert så mye som mulig. Dessuten vil rutineprosessene dine ende opp med å inkludere mye koordinering mellom utviklings- og testteam.

Å ha en god overvåkingsløsning er en svært sjelden realitet, men for riktig DevOps-drift er dette et must. Så snart som mulig, gå og invester tiden i å bygge den løsningen med velprøvde tjenester (AWS CloudWatch, New Relic, Datadog).

Forskjellen mellom Blue-Green og Canary Deployment

Mens forskjellen til tradisjonelle distribusjonsprosesser er ganske åpenbar (det er ikke to parallelle miljøer som kjører med forskjellige programvareversjoner i tradisjonelle distribusjonsprosesser), kan forskjellen til Canary-distribusjon være litt mer interessant.

Blå-grønn utplassering betyr to miljøer (blått og grønt). Men samtidig er de to miljøene hele tiden synkroniserte når det gjelder data. Når den nye versjonen er testet og ansett som klar, byttes trafikken fra det aktive miljøet til det inaktive miljøet, noe som gjør det til det nye aktive miljøet. Du bruker ikke tid på å distribuere ny kode, og det er ingen produksjonsstans involvert. Alle produksjonsbrukere jobber hele tiden på det aktive miljøet, og de legger ikke engang merke til bryteren.

Canary-distribusjon innebærer distribusjon av en ny versjon av programvaren til et lite undersett av brukere mens flertallet av brukere eller servere fortsetter å bruke den gjeldende versjonen. Dette er en gradvis distribusjon i stedet for en full bytte. Testere er, i dette tilfellet, direkte produksjonsbrukere, selv om bare en definert undergruppe av dem. Denne gruppen tester aktivt den nye versjonen med produksjonsprosesser, og når den endelig er stabil, vil den nye versjonen spre seg til resten av brukerne.

Så hvilken er bedre?

En konsulents svar «det kommer an på» passer best her, så slemt som det kan høres ut.

Hvis systemets prioritet er høy tilgjengelighet fremfor alt, vil blå-grønn distribusjon være ditt valg.

Hvis din sterke preferanse er ganske raskere tilbakemeldinger og en mer kontrollert (men tregere) utrulling av den nye systemversjonen, så har Canary-distribusjon fordeler fremfor blågrønn.

Det viktige er at begge er smidige nok til å anse seg selv som gode nok for seriøs DevOps-systemoppretting.

Kasusstudier

Netflix bruker Blue-Green-distribusjon for å distribuere nye versjoner av strømmetjenesten. Ved å bruke Blue-Green-distribusjon, kan Netflix distribuere nye versjoner av tjenesten uten å påvirke brukeropplevelsen. Faktisk bruker Netflix også Canary-distribusjon parallelt for andre tilfeller, så det er ikke urealistisk å kombinere ulike tilnærminger til DevOps-distribusjon under samme tak.

Amazon og Etsy bruker også Blue-Green-distribusjon for å distribuere nye versjoner av deres e-handelsplattform.

En annen sak er LinkedIn som bruker Blue-Green-distribusjon til å distribuere nye versjoner av sin sosiale nettverksplattform.

Sist, men ikke minst, bruker IBM Blue-Green-distribusjon til å distribuere nye versjoner av sin skyplattform.

Disse selskapene har vellykket implementert Blue-Green-distribusjon til plattforminfrastrukturen deres og fungerer som et godt eksempel for andre.

Siste ord

I likhet med Canary, streber Blue-Green-distribusjonen etter den beste optimaliseringen av dine allerede eksisterende smidige prosesser og metoder for å levere ny programvare jevnt på en slik måte at ingen noensinne vil legge merke til det i det hele tatt. Dette er det endelige målet for slike tilnærminger. Du leverer konstant og veldig ofte, men ingen vet om det, ingen legger merke til det, og til slutt er det ingen som bryr seg.

Det kan være litt frustrerende for utviklingsteamet at det ikke er noe sladder rundt selskapet om deres siste utgivelser. Men spør du meg, er dette akkurat den beste tjenesten du kan levere. Ingen snakker om det, men alle bruker det dag til dag.

Deretter kan du sjekke ut ofte stilte DevOps-intervjuspørsmål og svar.