Blue-Green Deployment: En Modern Metod för Mjukvaruutrullning
Traditionella metoder för mjukvaruutveckling, ofta kallade ”big bang”-lanseringar, är svåra att kombinera med det behov av flexibilitet, smidighet och kontinuerlig expansion som dagens moln- och DevOps-plattformar kräver.
Att enbart förlita sig på en manuell checklista för distribution av produktionsversioner är inte längre tillräckligt. Om man gör så, kan man inte påstå att man arbetar enligt agila principer, eller att man verkligen är en DevOps-organisation.
En Översikt av Blue-Green Deployment
Blue-Green-distribution är en teknik för att rulla ut programvara som minimerar avbrott och risker vid lansering av nya versioner. Det görs genom att skapa två identiska driftsmiljöer: en aktiv (blå) och en inaktiv (grön).
Den aktiva miljön används för den aktuella versionen av programvaran där användarna arbetar och genererar trafik. Den inaktiva miljön används för att distribuera och testa den nya versionen.
När den nya versionen är färdigtestad flyttas all trafik från den aktiva miljön till den inaktiva, vilket gör den nya miljön aktiv. Denna process kan sedan upprepas vid behov.
Källa: docs.aws.amazon.com
DevOps Sammanhang
Blue-Green-distribution är väl lämpad för DevOps-filosofin och dess processer. Den främjar kontinuerlig leverans och distribution av mjukvara, samtidigt som den minimerar driftstopp för användarna och eliminerar risken för misslyckade produktionslanseringar.
Två identiska miljöer möjliggör testning och utrullning av nya mjukvaruversioner utan att störa den nuvarande produktionsmiljön. Detta resulterar i snabbare och mer frekventa utgåvor, vilket är en grundläggande del av DevOps.
Dessutom är möjligheten att snabbt byta trafik mellan miljöerna avgörande för att snabbt kunna återställa systemet vid problem, vilket också är en viktig del av en DevOps-miljö.
Viktiga Principer för Blue-Green-distribution
#1. Två Identiska Miljöer
Blue-Green distribution bygger på existensen av två identiska miljöer. Detta innefattar identiska data och processer. Den ena är aktiv (blå) och den andra är inaktiv (grön).
Den blå miljön är den plats där produktionsanvändare utför sina dagliga arbetsuppgifter. Den gröna miljön är en spegelbild av den blå, men den används av testare för att köra testfall. Även om den gröna miljön inte är produktionsmiljön, körs testerna under verkliga förhållanden eftersom den är identisk med produktionsmiljön.
#2. Trafikväxling
När den nya programvaruversionen har testats och godkänts, flyttas trafiken från den aktiva miljön till den inaktiva, vilket gör den inaktiva miljön till den nya aktiva.
Trafikväxlingen sker omedelbart. Utplaceringsprocessen är nu avslutad. Det finns inget behov av underhållsfönster. Användarna behöver inte göra något för att komma åt den nya miljön. De omdirigeras automatiskt, och alla på samma gång.
Källa: aws.amazon.com
#3. Snabb Återställning
Möjligheten att snabbt växla trafik mellan miljöerna ger även möjlighet till en snabb återställning vid eventuella problem. Detta säkerställer minimal driftstopp och garanterar applikationens tillgänglighet.
Om problem uppstår i den gröna miljön, byts alla användare omedelbart tillbaka till den stabila, ursprungliga blå miljön utan avbrott.
#4. Automatiserade Tester
Automatiserad testning är en väsentlig del av Blue-Green-distribution. Det säkerställer att den nya versionen testas grundligt innan den lanseras i den aktiva miljön.
Om du inte har en betydande del av dina tester automatiserade (inklusive enhetstester, funktionstester och regressionstester), kan det vara tveksamt om Blue-Green-distribution är ett lämpligt alternativ.
Brist på automatiserade tester kommer att bromsa processen. Tiden det tar att testa den nya (gröna) miljön kan bli så lång att när du väl kan flytta över till den, så är den redan ”för gammal” i mjukvaruutvecklingscykeln.
#5. Kontinuerlig Leverans
Blue-Green-distribution är en del av en kontinuerlig leveranspipeline, vilket i sin tur leder till snabbare och mer frekventa mjukvaruutgåvor i produktion.
Du kan göra bytet så fort du är redo att testa den nya mjukvaruversionen i den gröna miljön. Eftersom utrullningen redan är gjord, och du bara behöver utföra själva trafikväxlingen, går det så pass snabbt att du kan göra detta varje dag, förutsatt att du är snabb även i testprocessen.
Typisk Livscykel
Plattformen som kör Blue-Green-distribution har sin egen specifika livscykel av steg och processer. Här följer en sammanfattning av de vanligaste stegen:
- Bygg en ny version av programvaran. Detta inkluderar kompilering av koden, körning av automatiserade tester och skapandet av en distribuerbar artefakt.
- Distribuera den nya versionen till den inaktiva (gröna) miljön. Detta innefattar att ställa in miljön, distribuera artefakten och konfigurera nödvändiga inställningar.
- Efter distribution till den gröna miljön, körs automatiserade tester för att säkerställa att den nya versionen fungerar korrekt. Dessa tester inkluderar funktionstester, regressionstester, integrationstester och ibland även prestandatester.
- Växla trafiken från den aktiva (blå) miljön till den inaktiva (gröna) miljön. Detta görs genom att uppdatera lastbalanseraren eller DNS-inställningarna för att dirigera trafik till den gröna miljön. Det är viktigt att automatisera denna process.
- När växlingen är klar, övervaka applikationen noggrant för att säkerställa att den fungerar som den ska. Övervaka fel, prestandaproblem och andra potentiella fel.
- Detta steg är valfritt och ska inte behövas alltför ofta. Om problem uppstår, växla tillbaka trafiken till den blå miljön för att omedelbart återställa systemet. Detta ska ske utan driftstopp eller avbrott för användarna. Uppdatera lastbalanseraren eller DNS-inställningarna för att dirigera trafiken till den blå miljön.
- Efter att problemen är åtgärdade, och du är redo att gå tillbaka till den nya versionen, växla tillbaka trafiken till den gröna miljön genom att uppdatera lastbalanseraren eller DNS-inställningarna.
- Slutligen, när den nya versionen är stabil, kan den gamla versionen som körs i den blå miljön avvecklas för att göra plats för nästa iteration av systemet.
Implementering av CI/CD-pipelines
Att integrera Blue-Green-distribution i en DevOps CI/CD-pipeline bör ske naturligt.
En förutsättning är att du redan har två identiska miljöer på plats. Eftersom detta ska vara en automatiserad process, använd infrastruktur som kodverktyg som AWS CloudFormation eller Terraform för att skapa, återskapa och uppdatera miljöerna via automatiserade pipelines.
När detta är på plats, är det enkelt att skapa en helt automatiserad distributionsprocess. Du kan återanvända befintliga pipelines för att skapa de blå och gröna miljöerna, men denna gång måste du också inkludera testprocesser.
Trafikväxlingsprocessen kan automatiseras med verktyg som AWS Elastic Load Balancer eller NGINX. Detta görs genom att uppdatera lastbalanseraren eller DNS-inställningarna för att dirigera trafiken till den gröna miljön när den nya mjukvaruversionen är klar.
Nästa steg är övervakning. Använd verktyg som AWS CloudWatch, New Relic eller Datadog.
Slutligen, återanvänd befintliga pipelines även för avveckling av den gamla blå miljön. Välj om du vill förstöra och återskapa alla tjänster och komponenter från grunden eller bara uppdatera skript för varje tjänst i kedjan. Förstöra och återskapa är ofta ett säkrare alternativ, eftersom uppdateringen kan leda till fler komplikationer.
Bästa Metoder för Blue-Green-distribution
Nyfiken på att veta hur man bäst använder Blue-Green-distribution? Här följer några tips baserade på erfarenhet:
Ha en Robust Databasmigreringsstrategi
Vid utrullning av en ny mjukvaruversion, är det viktigt att databasschemat uppdateras korrekt. Använd en databasmigreringsstrategi med verktyg som Flyway eller Liquibase för att hantera databasschemaändringar.
Använd ett Analysverktyg för Canary-utrullning
Även om Canary-utrullning är ett alternativt tillvägagångssätt, kan du använda vissa metoder för att förbättra din Blue-Green-distribution.
Använd ett analysverktyg för Canary-utrullning som Kayenta eller Spinnaker för att analysera prestandan hos den nya mjukvaruversionen i en riktig miljö. Jämför prestandan med den gamla versionen.
Använd en funktionsväxlingsram som Togglz för att aktivera eller inaktivera funktioner i den nya mjukvaruversionen. Detta möjliggör en gradvis lansering av nya funktioner och snabb återställning om problem uppstår.
Använd en Lastbalanserare med Hälsokontroller
Använd en lastbalanserare som AWS Elastic Load Balancer eller NGINX med hälsokontroller för att säkerställa att trafik endast dirigeras till fungerande instanser. Detta garanterar att applikationen är tillgänglig och minimerar driftstopp.
Använd en Återställningsplan med Automatisk Återställning
Ha en återställningsplan i händelse av problem och automatisera återställningsprocessen med verktyg som AWS CodeDeploy eller Octopus Deploy. Detta minimerar driftstopp och säkerställer att applikationen förblir tillgänglig.
Detta gäller främst den gröna miljön om problem uppstår med den nya versionen.
Ingen återställningsplan behövs för den blå miljön eftersom den förblir opåverkad. Du kan snabbt återvända till denna stabila miljö vid behov.
Utmaningar med Blue-Green-distribution
Implementeringen av Blue-Green-distribution kan medföra vissa utmaningar för utvecklingsteam. Här är några vanliga utmaningar:
- Att skapa och hantera två identiska miljöer kan vara komplext och tidskrävande. Det kräver kompetens i infrastruktur som kodverktyg som Terraform eller CloudFormation. Ett erfaret utvecklingsteam kan behövas för att hantera sådana tekniska utmaningar.
- När du rullar ut en ny version, är det viktigt att databasschemat uppdateras korrekt. Detta kan vara utmanande, särskilt om databasschemat är komplext. Du behöver robusta processer för databasutrullning som automatiskt och tillförlitligt kan hantera uppdateringar av schemat.
- Att analysera prestandan hos den nya programvaran i en verklig miljö kan vara svårt. Det kräver kompetens i analysverktyg som Kayenta eller Spinnaker.
- Att implementera funktionsväxlar kan vara utmanande, speciellt om applikationen har ett stort antal funktioner. Det kräver noggrann planering och samordning mellan utvecklingsteam.
- Att testa den nya versionen i en riktig miljö kan vara svårt, speciellt om applikationen har många användare eller servrar. Testfallen måste automatiseras i så stor utsträckning som möjligt. Rutinerna bör inkludera samarbete mellan utvecklings- och testteam.
- En bra övervakningslösning är sällsynt, men en nödvändighet för korrekt DevOps-drift. Investera tid i att bygga en sådan lösning med beprövade tjänster (AWS CloudWatch, New Relic, Datadog).
Skillnaden mellan Blue-Green och Canary-distribution
Skillnaden gentemot traditionella distributionsprocesser är tydlig (inga parallella miljöer med olika programvaruversioner i traditionella metoder). Skillnaden mot Canary-distribution kan vara mer intressant.
Blue-Green-distribution innebär två miljöer (blå och grön) som är synkroniserade med data. När den nya versionen är testad, flyttas trafiken från den aktiva miljön till den inaktiva, som blir den nya aktiva miljön. Ingen tid läggs på att rulla ut ny kod, och inga driftstopp förekommer. Användarna arbetar kontinuerligt i den aktiva miljön utan att märka bytet.
Canary-distribution innebär att en ny version rullas ut till en liten del av användarna medan majoriteten fortsätter använda den gamla versionen. Det är en gradvis implementering snarare än en fullständig omställning. Testarna är direkta produktionsanvändare, men en begränsad delmängd. Denna grupp testar aktivt den nya versionen med produktionsprocesser, och när den är stabil, distribueras den till resten av användarna.
Så, Vilken är Bäst?
Ett konsultsvar ”det beror på” passar bäst här, hur otrevligt det än låter.
Om ditt systems prioritet är hög tillgänglighet, så är Blue-Green-distribution ett bra val.
Om du föredrar snabbare feedback och en mer kontrollerad (men långsammare) utrullning, kan Canary-distribution vara bättre än Blue-Green.
Viktigast är att båda metoderna är tillräckligt agila för att vara bra alternativ för DevOps-system.
Fallstudier
Netflix använder Blue-Green-distribution för att rulla ut nya versioner av sin streamingtjänst. Det gör att de kan distribuera nya versioner utan att påverka användarupplevelsen. Netflix använder också Canary-distribution parallellt för andra fall, vilket visar att det går att kombinera olika distributionsstrategier.
Amazon och Etsy använder också Blue-Green-distribution för att rulla ut nya versioner av sina e-handelsplattformar.
LinkedIn använder Blue-Green-distribution för nya versioner av sin sociala nätverksplattform.
Slutligen använder IBM Blue-Green-distribution för att rulla ut nya versioner av sin molnplattform.
Dessa företag har framgångsrikt implementerat Blue-Green-distribution i sina plattformsinfrastrukturer och är goda exempel för andra.
Slutord
Precis som Canary-distribution, strävar Blue-Green-distribution efter optimal optimering av agila processer för att leverera ny programvara smidigt utan att någon märker det. Detta är det slutliga målet. Du levererar kontinuerligt, men ingen vet om det, märker det, eller bryr sig om det.
Det kan vara frustrerande för utvecklingsteamet att det inte är något snack om deras senaste lanseringar. Men detta är just det bästa du kan åstadkomma. Ingen pratar om det, men alla använder det varje dag.
Kolla även in vanliga frågor och svar i DevOps-intervjuer.