Blå-grønn distribusjon

Blå-grønn distribusjon er en programvareutviklingsteknikk som bruker to produksjonsmiljøer (blå og grønn) for å gjøre programvaredistribusjon enklere og tryggere.

Hva er blå-grønn distribusjon?

Blå-grønn distribusjon er en programvareutviklingsteknikk som benytter to produksjonsmiljøer (et «blått miljø» og et «grønt miljø») for å gjøre programvaredistribusjonsprosessen tryggere. Det er en relativt kompleks distribusjonsstrategi, men minimerer effektivt nedetid ved oppdatering av applikasjonen din i produksjon. Den er også svært nyttig for produkteksperimentering

De to produksjonsmiljøene holdes så identiske som mulig. Den nylig distribuerte koden overføres til det for øyeblikket inaktive miljøet. Når de nye endringene er testet i produksjon, bytter en ruter for å peke til miljøet der de nye endringene er live, noe som gir en jevn overgang.

En blå-grønn distribusjonsstrategi lar deg oppdatere applikasjonen din i produksjon med minimal nedetid. Den fungerer ved å distribuere to identiske kopier av applikasjonen din, en kalt «blå» og en kalt «grønn». Den blå kopien er den nåværende produksjonsversjonen av applikasjonen din, og den grønne er den nye versjonen du ønsker å distribuere. Du tildeler noen av serverne dine til å være vert for en ny versjon av applikasjonen og de gjenværende serverne til å være vert for den forrige versjonen.

Når den grønne kopien er distribuert og testet, kan du gradvis flytte trafikk fra blå til grønn. Start gradvis, for eksempel ved å rute 20 % av trafikken til den grønne kopien og deretter øke prosentandelen over tid. Det lar deg overvåke eventuelle problemer før du bytter over.

Hvis du støter på et problem, kan du raskt rulle tilbake til den blå kopien ved å rute all trafikk tilbake til den. Derfor omtales blå-grønn distribusjon som en «null nedetid»-distribusjonsstrategi. 

Med blå-grønn distribusjon får du: 

  • Ingen nedetid: Overgangen fra blå til grønn er øyeblikkelig. Kunder opplever ingen nedetid under distribusjonsfasen siden begge miljøene er aktive og identiske.  
  • Tilbakestillingsmulighet: Ved problemer kan du enkelt bytte tilbake til det blå miljøet. 
  • Risikoreduksjon: Ved å ha et fullstendig testet miljø (grønt) før du dirigerer live-trafikk til det, reduseres risikoen for å distribuere feilaktige eller buggy oppdateringer direkte til det live systemet (blått) betydelig.  

I bunn og grunn reduserer blå-grønn distribusjon nedetid og risiko forbundet med å distribuere nye endringer til et live system betydelig. 

fordeler med blå-grønn distribusjon

Bilde: Optimizely

Hvordan bruke blå-grønn distribusjon?

Blå-grønn distribusjon er en kompleks distribusjonsstrategi. Ha en veldefinert plan siden dette kan være dyrere enn andre distribusjonsstrategier, som A/B-testing. 

  • Bruk skalerbar infrastruktur. Det hjelper deg med å redusere de totale kostnadene. 
  • Praktiser kaosteknikk i et grønt miljø. Det lar deg teste påliteligheten til applikasjonen din uten å påvirke sluttbrukerne dine. 
  • Administrer databasetilstand nøye. Det er en av de største utfordringene ved blå-grønn distribusjon. 
  • Endre lastbalansere, ikke DNS. Det gir deg mer kontroll over trafikkstyringsprosessen. 

Faser i en blå-grønn distribusjonsmodell 

Her er de 9 fasene i en blå-grønn distribusjonsmodell:

Faser i en blå-grønn distribusjon

Bilde: Optimizely

  1. Konfigurer miljøer
    Opprett identiske blå og grønne miljøer.
  2. Distribuer oppdateringer til grønn
    Implementer endringer i det grønne miljøet.
  3. Testing og validering
    Utfør omfattende testing av det grønne miljøet.
  4. Bekreftelse og kvalitetskontroller
    Bekreft oppdateringer for ytelse og kompatibilitet.
  5. Overgang
    Omdiriger live-trafikk fra blå til grønn raskt.
  6. Overvåkning (etter distribusjon)
    Overvåk kontinuerlig grønt for problemer eller avvik.
  7. Tilbakestilling (ved behov)
    Gå raskt tilbake til det stabile blå miljøet dersom problemer oppstår.
  8. Oppgrader grønn til blå
    Når stabilt, gjør det grønne miljøet til ny live-produksjon (blå).
  9. Rydd opp og forbered neste syklus
    Tilbakestill og forbered et nytt grønt miljø for fremtidige oppdateringer. 

Denne strømlinjeformede prosessen sikrer en smidig overgang mellom miljøer og minimerer nedetid og risiko under oppdateringer eller endringer i live-systemet. 

Bruksområder for blå-grønn distribusjon

Tilbakestillinger

En av de viktigste fordelene med blå-grønn distribusjon er gjenoppretting etter katastrofer. Siden det finnes to identiske produksjonsmiljøer, kan en ruter, hvis nye endringer rulles ut til ett (si den blå versjonen) og problemer oppdages, enkelt bytte tilbake til det andre miljøet (grønn versjon) som har den gamle versjonen av koden uten nedetid. 

Kontinuerlig integrasjon/kontinuerlig levering (CI/CD-rørledning)

Et av målene med kontinuerlig integrasjon (en DevOps-teknikk) er å få programvare live så snart som mulig og fremskynde utviklingsprosessen gjennom automatisert testing og hyppig kodeintegrasjon. Blå-grønn distribusjon er en distribusjonsstrategi som kan bidra til dette målet ved å tillate flere kode-pushes til produksjon mens risikoen for nye utgivelser senkes. 

Testing i produksjon

Det er ofte små kompatibilitetsforskjeller mellom testmiljøet og produksjon, uansett hvor mye innsats som legges i å gjøre dem identiske. For DevOps-team kan dette føre til edge cases og feil som ikke kan oppdages før koden er overført til produksjon. Blå-grønn distribusjon tillater testing i produksjon ved å overføre ny kode til det faktiske produksjonsmiljøet og se hvordan den fungerer, før den jevnt overføres til produksjonstrafikk og faktiske brukere. 

Canary-distribusjon

En canary-utgivelse er når nye endringer slippes til et lite segment av brukergrunnlaget ditt, i stedet for å rulle ut til alle. Mye som en kanarifugl i en kullgruve, kan denne lille kontrollerte testen brukes til å avgjøre om det er fatale feil i den nye versjonen av koden. Blå-grønn distribusjon kan brukes for slik canary testing ved ganske enkelt å la ruteren dirigere en prosentandel av trafikken til en ny versjon av koden for å se hvordan den fungerer med live-trafikk, før endringen rulles ut til 100 % av brukerne. 

A/B-testing

Et annet mulig brukstilfelle for blå-grønn distribusjon er A/B-testing. I dette tilfellet laster du den nye versjonen av koden inn i det blå miljøet og dirigerer 50 % av bruktrafikken til den blå versjonen mot den opprinnelige grønne versjonen. Deretter kan du overvåke hvordan de to miljøene presterer i henhold til nøkkelberegningene dine, og bruke statistisk analyse til å bestemme den nøyaktige effekten av den nye applikasjonen. 

Lastbalansering

Et annet mulig brukstilfelle for blå-grønn distribusjon er lastbalansering. Hvis den blå/grønne distribusjonen er konfigurert slik at de to produksjonsmiljøene befinner seg på separate servere (i stedet for en virtuell maskin), kan en ruter enkelt balansere trafikk mellom de blå og grønne versjonene av produksjonsmiljøet siden de er funksjonelt identiske.

Hva er fordelene med blå-grønn distribusjon? 

Her er noen av de viktigste fordelene med denne distribusjonsmetoden: 

  • Ingen nedetid: Du kan oppdatere applikasjonen din i produksjon uten nedetid med to identiske kopier som kjører. Du kan bytte trafikk fra en til den andre.
  • Tilbakestilling: Hvis du møter utfordringer med den nye versjonen av applikasjonen, kan du enkelt rulle tilbake til den forrige versjonen.
  • Redusert risiko: Du kan teste den nye versjonen av applikasjonen i det grønne miljøet før du distribuerer den til produksjon.
  • Kontrollert distribusjon: Få kontroll over distribusjonsprosessen. Bestem hvor mye trafikk som skal rutes til det grønne miljøet, og overvåk eventuelle problemer før du foretar byttet.
  • Skalerbarhet: Blå-grønn distribusjon kan enkelt skaleres for å imøtekomme mer trafikk ved å legge til flere servere i det grønne miljøet. 

Eksempel på blå-grønn distribusjon

Si at utviklingsteamet ditt jobber med en nettapp og ønsker å lansere en ny funksjon, men ønsker å eliminere nedetid og ha en jevn overgang til den nye koden. I tillegg til testmiljøet ditt ville du sette opp to identiske produksjonsmiljøer (en «blå versjon» og en «grønn versjon») med en ruter som dirigerer trafikk til den grønne versjonen.

Deretter kan du overføre de nye endringene til den blå versjonen av produksjonsmiljøet og se hvordan den fungerer i en faktisk produksjonsomgivelse. Det kan vise seg at det er feil som bare oppstår i produksjonsmiljøet ditt, i hvilket tilfelle du enkelt kan gå tilbake til utvikling uten påvirkning på brukerne dine.

Når du er fornøyd med ytelsen til den nye versjonen av applikasjonen, kan du begynne å dirigere en prosentandel av bruktrafikken til det blå miljøet for å kjøre en canary-test på faktiske brukere. Hvis ingen problemer oppdages, kan du rute 100 % av trafikken til det nye miljøet, noe som gir en jevn funksjonsutgivelse.

Hvis problemer oppdages etter at overgangen er gjort, kan du igjen enkelt rute trafikk tilbake til det grønne miljøet som har den forrige versjonen av koden for å utføre en enkel tilbakestilling.

Når du er overbevist om at det ikke er noen problemer med den nye koden, kan du klone det blå miljøet til det grønne, slik at du igjen har to identiske produksjonsmiljøer. Du kan deretter fortsette i utviklingssyklusen, eller bruke den andre serveren som lastbalanserer ved behov hvis du ser en økning i bruken.

Hva er ulempene med blå-grønn distribusjon?

Her er noen av de viktigste ulempene:

  • Flere ressurser: Det krever at du opprettholder to identiske miljøer, noe som kan være dyrere enn andre distribusjonsstrategier.
  • Mer koordinering: Du må koordinere distribusjonen av den nye versjonen av applikasjonen til det grønne miljøet, samt overgangen fra blå til grønn.
  • Tregere overgang: Det kan være tregere å bytte til ulike undergrupper enn andre distribusjonsstrategier, som A/B-testing. Du må tømme all trafikk fra det blå miljøet før du bytter til grønt.
  • Ikke for alle applikasjoner: Blå-grønn distribusjon passer ikke for alle applikasjoner. For eksempel applikasjoner som bruker mye tilstand, som databaser.
  • Granularitet på funksjonsnivå: En grønn distribusjonsprosess muliggjør ikke granularitet på funksjonsnivå. Så hvis du støter på et problem med en bestemt funksjon, må du rulle tilbake hele utgivelsen, ikke bare den berørte funksjonen. Hvis du distribuerer en stor eller kompleks applikasjon, kan det være vanskelig å anvende denne metoden. 

Feature flags vs. blå-grønn distribusjon

En alternativ utviklingstilnærming til blå-grønn distribusjon er bruken av feature flags eller feature toggles som rullende distribusjoner. Med feature flags pakkes nye funksjoner og kode inn i betinget kode som kan slås på eller av eksternt. Dette lar utviklere rulle ut nye funksjoner til produksjon og ha en enkel måte å rulle tilbake uten å måtte opprettholde to produksjonsmiljøer. 

I tillegg til enkel av/på-funksjonalitet kan feature flags også brukes til målrettede utrullinger, der en funksjon kun er aktivert for et bestemt segment av brukertrafikken. Dette muliggjør brukstilfeller som canary-distribusjoner og A/B-testing, igjen uten å måtte opprettholde to separate produksjonsmiljøer.

Hvis du leter etter en enkel arbeidsflyt for å komme i gang med feature flags, er Optimizely gratis feature flagging en gratis feature flagging-løsning fra Optimizely som lar deg raskt og sikkert implementere feature toggles og A/B-testing i appen din. Optimizely Rollouts er tilgjengelig for de mest populære språkene & bibliotekene inkludert JavaScript, Ruby, Node, React og Python. 

Kom i gang i dag med gratis feature flagging