Tradisjonelle tilnærminger til programvareutvikling, ofte beskrevet som «big bang», passer dårlig med behovet for fleksibilitet, smidighet og hyppige oppdateringer som dagens skybaserte og DevOps-plattformer krever.
Det holder ikke lenger å bare lage en liste over manuelle steg som skal utføres ved lansering av en ny produksjonsversjon. En slik metode er verken smidig eller i tråd med prinsippene for ekte DevOps.
Blue-Green Deployment: En Introduksjon
Blue-Green deployment er en strategi for programvaredistribusjon som minimerer nedetid og risiko ved lansering av nye versjoner. Dette oppnås ved å ha to identiske miljøer: et aktivt (blått) og et inaktivt (grønt).
Det aktive miljøet kjører den nåværende programvareversjonen, og her genereres all produksjonstrafikk fra brukerne. Det inaktive miljøet brukes til å distribuere og teste den nye programvareversjonen.
Når den nye versjonen er testet og godkjent, flyttes all trafikk fra det aktive til det inaktive miljøet, som dermed blir det nye aktive miljøet. Denne prosessen kan gjentas ved behov.
Kilde: docs.aws.amazon.com
DevOps Kontekst
Blue-Green deployment er en god match for DevOps-filosofien og prosesser, da den muliggjør kontinuerlig levering og utrulling av programvare. Samtidig minimeres nedetid for sluttbrukere, og risikoen for feil i produksjonsmiljøet reduseres.
Ved å ha to like miljøer, kan man teste og distribuere nye versjoner uten å påvirke det eksisterende produksjonsmiljøet. Dette fører til raskere og hyppigere lanseringer, som er et sentralt element i DevOps.
Muligheten for raskt å bytte trafikk mellom miljøer er også viktig for rask tilbakestilling ved eventuelle problemer, noe som er essensielt i et DevOps-miljø.
Grunnleggende Prinsipper for Blue-Green Deployment
#1. To Identiske Miljøer
Blue-Green deployment forutsetter to identiske miljøer. Dette gjelder både data og prosesser. Det ene miljøet er aktivt (blått), mens det andre er inaktivt (grønt).
Det blå miljøet brukes av sluttbrukere i deres daglige arbeid. Det grønne miljøet synkroniseres kontinuerlig med det blå, men det er her testerne utfører sine testscenarier. Selv om dette miljøet ikke er i produksjon, kjøres testene under realistiske forhold siden det er et produksjonslignende miljø.
#2. Trafikkomkobling
Når en ny versjon av programvaren er testet og godkjent, flyttes trafikken fra det aktive miljøet til det inaktive miljøet, som da blir det nye aktive miljøet.
Overgangen skjer øyeblikkelig. Distribusjonen er fullført, og det er ingen nedetid. Brukere merker ikke endringen og trenger ikke gjøre noe for å koble seg til det nye miljøet. De omdirigeres automatisk og samtidig.
Kilde: aws.amazon.com
#3. Rask Tilbakestilling
Muligheten for raskt å bytte trafikk mellom miljøer betyr også rask tilbakestilling i tilfelle problemer. Dette sikrer minimal nedetid og at applikasjonen forblir tilgjengelig.
Hvis noe går galt i det grønne miljøet, vil alle brukere umiddelbart bli flyttet tilbake til det stabile blå miljøet uten forstyrrelser.
#4. Automatisert Testing
Automatisert testing er et kritisk aspekt ved Blue-Green deployment. Dette sikrer at den nye programvareversjonen er grundig testet før den tas i bruk i det aktive miljøet.
Hvis en betydelig del av testingen ikke er automatisert (inkludert enhetstester, funksjonstester og regresjonstester), er det lite hensiktsmessig å vurdere Blue-Green deployment.
Mangelen på automatiserte tester vil forsinke prosessen betydelig. Testtiden for det nye (grønne) miljøet vil være så lang at når det er klart for overgang, vil det allerede være «for gammelt» sett fra et utviklingsperspektiv.
#5. Kontinuerlig Levering
Blue-Green deployment er en del av en kontinuerlig leveringspipeline som muliggjør raskere og hyppigere programvarelanseringer i produksjonsmiljøet.
Du kan bytte så snart du er klar til å teste den nye programvareversjonen i det grønne miljøet. Siden distribusjonen allerede er gjennomført og det eneste som gjenstår er å bytte trafikk, går dette så raskt at du kan gjøre det daglig. Forutsatt at testene også gjennomføres effektivt, selvfølgelig.
Typisk Livssyklus
Plattformen som driver Blue-Green deployment har sin egen livssyklus med bestemte trinn og prosesser. Disse inkluderer vanligvis:
Implementering av CI/CD Pipelines
Implementering av Blue-Green deployment i en DevOps CI/CD-pipeline bør være en naturlig prosess.
En viktig forutsetning er at du allerede har to identiske miljøer klare. Siden dette skal være en automatisert prosess, kan du benytte infrastruktur som kodeverktøy som for eksempel AWS CloudFormation eller Terraform for å opprette, gjenskape og oppdatere miljøene automatisk.
Med dette på plass, er det relativt enkelt å skape en helautomatisert distribusjonsprosess. Du gjenbruker eksisterende pipelines for å lage det blå og grønne miljøet. Denne gangen må du imidlertid inkludere testprosesser i pipelinen.
Trafikkomkoblingen kan automatiseres med verktøy som AWS Elastic Load Balancer eller NGINX. Dette innebærer å oppdatere lastbalanseren eller DNS-innstillingene for å dirigere trafikken til det grønne miljøet når den nye programvareversjonen er testet og klar.
Neste steg er overvåking. For dette kan du bruke verktøy som AWS CloudWatch, New Relic eller Datadog.
Til slutt bør du også gjenbruke eksisterende pipelines for å avvikle det gamle blå miljøet. Du kan enten ødelegge og gjenskape alle tjenester, eller oppdatere skriptene for hver tjeneste. Det tryggeste alternativet er som regel å ødelegge og gjenskape, da oppdatering av eksisterende systemer gir flere utfordringer.
Anbefalte Metoder for Blue-Green Deployment
Her er noen tips for å utnytte Blue-Green deployment på best mulig måte:
Ha en God Strategi for Databasemigrering
Når du lanserer en ny versjon, er det viktig å sørge for at databaseskjemaet er korrekt oppdatert. Bruk en migreringsstrategi som Flyway eller Liquibase for å administrere endringer i databaseskjemaet.
Bruk et Verktøy for Kanarianalyse
Selv om Canary deployment er en alternativ tilnærming, kan du bruke noen av teknikkene for å forbedre din Blue-Green-distribusjon.
Bruk et kanari-analyseverktøy som Kayenta eller Spinnaker for å analysere ytelsen til den nye programvareversjonen i et reelt miljø. Dette innebærer å sammenligne ytelsen med den gamle versjonen.
Bruk et rammeverk for funksjonsveksling som Togglz for å aktivere eller deaktivere funksjoner i den nye versjonen. Dette gir mulighet for en gradvis utrulling av nye funksjoner og rask tilbakestilling om nødvendig.
Bruk en Lastbalanser med Helsesjekker
Bruk en lastbalanser som AWS Elastic Load Balancer eller NGINX med helsesjekker for å sikre at trafikken kun sendes til fungerende instanser. Dette sikrer at applikasjonen er tilgjengelig og at nedetiden minimeres.
Ha en Tilbakestillingsplan med Automatisert Tilbakestilling
Ha en tilbakestillingsplan i tilfelle problemer, og automatiser tilbakestillingsprosessen med et verktøy som AWS CodeDeploy eller Octopus Deploy. Dette sørger for at nedetiden holdes minimal og at applikasjonen forblir tilgjengelig.
Dette gjelder for det meste det grønne miljøet når du oppdager et problem med den nye versjonen.
En tilbakestillingsplan er ikke nødvendig for det blå miljøet, da dette ikke påvirkes av overgangen og kan tas i bruk umiddelbart.
Utfordringer med Blue-Green Deployment
Implementering av Blue-Green deployment kan gi utviklingsteamene noen utfordringer. Her er noen typiske:
Forskjellen mellom Blue-Green og Canary Deployment
Mens forskjellen til tradisjonelle distribusjonsprosesser er ganske tydelig (det er ikke to parallelle miljøer med forskjellige versjoner), kan forskjellen til Canary deployment være mer interessant.
Blue-Green deployment involverer to miljøer (blått og grønt). Disse to miljøene er synkroniserte når det gjelder data. Når den nye versjonen er klar, byttes trafikken fra det aktive til det inaktive miljøet. Det innebærer ikke distribusjon av ny kode og det er ingen nedetid. Alle brukere jobber i det aktive miljøet og merker ikke overgangen.
Canary deployment innebærer å distribuere den nye versjonen til et lite utvalg av brukere mens majoriteten fortsetter å bruke den gamle versjonen. Dette er en gradvis distribusjon i stedet for en full bytte. Testere er i dette tilfellet de faktiske brukerne, selv om det bare er et lite utvalg av dem. Denne gruppen tester aktivt den nye versjonen i produksjon, og når den er stabil, distribueres den til resten av brukerne.
Så, hvilken er best?
Som konsulenter ofte sier, så «kommer det an på».
Hvis systemets høyeste prioritet er tilgjengelighet, vil Blue-Green deployment være det beste valget.
Hvis du ønsker raskere tilbakemeldinger og en mer kontrollert (men tregere) utrulling, har Canary deployment noen fordeler.
Begge er smidige nok til å betraktes som gode metoder for seriøs DevOps-systemutvikling.
Eksempler fra Praksis
Netflix benytter Blue-Green deployment for å lansere nye versjoner av sin strømmetjeneste. Ved å bruke denne metoden kan Netflix distribuere oppdateringer uten å påvirke brukeropplevelsen. Netflix bruker også Canary deployment i andre tilfeller, og det er ikke uvanlig å kombinere ulike tilnærminger.
Amazon og Etsy bruker også Blue-Green deployment for å lansere nye versjoner av sine e-handelsplattformer.
LinkedIn bruker denne metoden for å distribuere oppdateringer til sin sosiale nettverksplattform.
IBM bruker Blue-Green deployment for å lansere nye versjoner av sin skyplattform.
Disse selskapene har implementert Blue-Green deployment med suksess og er gode eksempler for andre.
Avsluttende Ord
I likhet med Canary, handler Blue-Green deployment om å optimalisere eksisterende smidige prosesser for å levere ny programvare uten at brukerne legger merke til det. Dette er det endelige målet. Man leverer kontinuerlig og hyppig, men ingen merker det.
Det kan være frustrerende for utviklingsteamet at det ikke er noe oppstyr rundt deres nyeste lanseringer. Men dette er den beste tjenesten man kan levere. Ingen snakker om det, men alle bruker det daglig.
Sjekk gjerne ut vanlige DevOps intervjuspørsmål og svar.