Redigera

Dela via


Blå/gröna distributioner för program i Azure Spring Apps

Azure Spring Apps
GitHub
Azure DevOps

Den här artikeln beskriver en blå/grön distributionslösning med hög tillgänglighet för program i Azure Spring Apps.

Det blå/gröna distributionsmönstret innebär att behålla en befintlig version av ett program live (kallas den blå versionen) medan en ny version av programmet distribueras (kallas den gröna versionen). Med den här distributionen kan du starta om, värma upp och testa den nya programversionen separat. När den nya versionen av programmet har körts kan du växla till den och omdirigera eventuell ny inkommande trafik till den. För programmets användare sker distributionen av den nya versionen utan synlig stilleståndstid. Blå/grön distribution gör det enkelt att överge en ny version utan att påverka liveversionen om en ny distribution inte fungerar som förväntat.

Arkitektur

Följande diagram visar arkitekturen för den här metoden:

Diagram som visar en arkitektur för blå/grön distribution som använder GitHub, GitHub Actions och Azure Spring Apps.

Ladda ned en Visio-fil med den här arkitekturen.

Komponenter

Den här lösningen använder följande komponenter:

  • Azure Spring Apps är en modern mikrotjänstplattform för att köra Java Spring Boot- och Steeltoe .NET Core-program . Tjänsten eliminerar standardkod för att köra mikrotjänster och hjälper dig att snabbt utveckla robusta appar i molnet. Du kan också använda Azure Spring Apps för att distribuera kod per program.

  • GitHub är en kodvärdplattform som tillhandahåller versionskontroll och samarbete. GitHub tillhandahåller git-distribuerad versionskontroll, källkodshantering och andra funktioner.

  • GitHub Actions hjälper dig att automatisera arbetsflöden för programutveckling och distribution från en lagringsplats. Du kan använda plattformen för att skapa en helt automatiserad installation av kontinuerlig integrering och kontinuerlig leverans (CI/CD). Du kan också använda GitHub Actions för att skapa miljöer där du kan konfigurera regler som kräver granskare.

Arbetsflöde

Lösningsarkitekturen implementerar följande arbetsflöde:

  1. En utvecklare gör en ändring i ett program. GitHub-lagringsplatsen innehåller den appkod som måste distribueras till Azure Spring Apps. Varje ändring av appkoden sker under källkontroll. GitHub utför följande uppgifter:

    • Kontrollera att ändringarna granskas.

    • Förhindra oavsiktliga eller obehöriga ändringar.

    • Kontrollera att kvalitetskontroller har slutförts.

  2. GitHub-lagringsplatsen innehåller också ett GitHub Actions-arbetsflöde för att skapa kodändringarna och slutföra nödvändiga kvalitetskontroller. När koden har kompilerats distribuerar GitHub Actions-arbetsflödet den senaste versionen av appkoden till Azure Spring Apps. GitHub Actions-arbetsflödet innehåller följande steg:

    1. Fastställa den aktuella aktiva produktionsmiljön.

    2. Distribuera koden till en icke-produktionsmiljö. Om det inte finns någon icke-produktionsmiljö skapar du miljön.

      Nu i distributionen fortsätter den gamla (blå) versionen av appen i produktionsdistributionen att ta emot all produktionstrafik.

    3. Vänta tills distributionsgranskningen och godkännandet av den nya appen har godkänts.

      Det här steget ger den nyligen distribuerade appen (den gröna versionen) tid att starta och värma upp.

      Innan du godkänner det kan du använda appens icke-produktions-URL för att verifiera den nya versionen och se till att den är klar.

    4. Efter godkännandet växlar du produktionsdistributionen och icke-produktionsdistributionen.

      All produktionstrafik dirigerar nu till den nya versionen av appen.

      Kommentar

      Om du avvisar den nya distributionen växlar Inte GitHub miljöerna. Den tidigare versionen fortsätter att ta emot produktionstrafik.

    5. När godkännande och trafik har växlats över tar du bort den gamla produktionsdistributionen.

      Det här rensningssteget ger en mer kostnadseffektiv konfiguration.

Alternativ

Den här lösningen använder GitHub Actions för att automatisera distributionen. Du kan också använda Azure Pipelines eller något annat CI/CD-automatiseringssystem som ett alternativ. Exemplet i avsnittet Scenariodistribution använder Azure CLI-instruktioner så mycket som möjligt, så att du enkelt kan översätta den här installationen till ett annat automatiseringsverktyg. Använd ett CI/CD-verktyg för att konfigurera en miljö och skapa ett godkännandeflöde på den.

Den här arkitekturen använder Azure Spring Apps med distributioner som måltjänst. Du kan använda Azure App Service-mellanlagringsplatser som ett alternativ. Ett fack innehåller den nya versionen av programmet, som kan läsas in igen, värmas upp och testas innan ett fackbyte är klart. Fackbytet placerar den nya versionen i produktion. Den här processen är inbyggd i tjänsten, så konfigurationen är enkel.

Som ett annat alternativ kan du placera alla Azure-tjänster som är värdar för webbslutpunkter bakom en belastningsutjämningslösning. Om du använder den här metoden kan du starta en andra instans av Azure-tjänsten, där du kan distribuera en ny version av ditt program. Som ett nästa steg kan du skapa en distribution utan avbrott genom att växla trafik vid belastningsutjämningslösningen till Azure-tjänsten som innehåller den nya versionen av appen. Tänk på att den här metoden för blå/grön distribution kräver betydande hanteringskostnader.

Information om scenario

För vissa molnprogram är det viktigt att hålla drifttiden så hög som möjligt. En lösning är att använda en konfiguration med hög tillgänglighet, vilket kan fördubbla kostnaderna. En annan lösning är en haveriberedskapsplan som tar upp programmet igen i en annan region efter ett avbrott. Kostnaden för det senare kan vara lägre, men det tar tid att aktivera hela programmet igen.

Den här artikeln beskriver en process för att säkerställa hög tillgänglighet under distributionen av en ny version av ett program. I en traditionell konfiguration distribueras de nya bitarna i programmet till den tjänst som är värd för programmet. Den här konfigurationen leder ofta till en ny inläsning och omstart av programmet. Under den processen är programmet inte tillgängligt.

Den här lösningen använder Azure Spring Apps för att implementera blå/grön distribution och adresser som automatiserar distributionen av program.

Potentiella användningsfall

Den här lösningen kan vara till nytta för alla organisationer som kräver hög tillgänglighet. Lösningen är särskilt lämplig för branscher som e-handel och spel, där stilleståndstid kan leda till förlust av företag och intäkter.

Du kan förbättra tillgängligheten ytterligare genom att implementera distributioner med noll stilleståndstid. Mer information finns i avsnittet Alternativ i den här artikeln.

Att tänka på

Följande lösningsöverväganden implementerar grundpelarna i Azure Well-Architected Framework. Det här ramverket är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillgänglighet

Den här lösningen hjälper dig att upprätthålla tillgängligheten för ditt program under distributionen av en ny version. Det ökar inte det övergripande serviceavtalet som Azure Spring Apps tillhandahåller. Tjänstfel på plattformen kan fortfarande påverka din app.

Om du vill ha en lösning för att öka det övergripande serviceavtalet för din konfiguration kan du titta på hur du konfigurerar en Azure Spring Apps-tjänst med hög tillgänglighet i flera regioner. I den här metoden frontar du konfigurationen med en global belastningsutjämningslösning.

Skalbarhet

Den här lösningen fungerar per program, så den passar bra för mikrotjänstprogram. Det gör också att programteam kan arbeta oberoende av andra programteam utan att påverka drifttiden för den övergripande lösningen.

Den här lösningen fungerar också bäst per program, där varje program har ett eget arbetsflöde för blå/grön distribution. Om du kombinerar program i samma arbetsflöde blir den här konfigurationen komplex snabbt, så vi rekommenderar inte den metoden.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Förutom att konfigurera lagringsplatsens behörigheter bör du överväga att implementera följande säkerhetsåtgärder i Git-lagringsplatser som innehåller kod som du vill distribuera till Azure Spring Apps:

  • Grenskydd. Skydda de grenar som representerar programmets produktionstillstånd från att skicka ändringarna direkt till dem. Kräv att varje ändringsförslag skickas som en pull-begäran (PR). Använd PR:er för att utföra automatiska kontroller. Kontroller kan omfatta att skapa all kod och köra enhetstester på den kod som en PR skapar eller ändrar.

  • PR-granskning. För att framtvinga principen med fyra ögon kräver du att PR:er har minst en granskare. Du kan också använda funktionen GitHub-kodägare för att definiera individer eller team som ansvarar för att granska specifika filer på en lagringsplats.

  • Oföränderlig historik. Tillåt endast nya incheckningar utöver befintliga ändringar. Oföränderlig historik är särskilt viktig för granskningsändamål.

  • Ytterligare säkerhetsåtgärder. Kräv att dina GitHub-användare aktiverar multifaktorautentisering. Tillåt också endast signerade incheckningar, som inte kan ändras vid ett senare tillfälle.

Vi rekommenderar också att du distribuerar till endast en Azure Spring Apps-tjänst. I en produktionskonfiguration bör du först testa koden i andra miljöer innan du distribuerar den till produktion. Produktionsmiljön bör helst finnas i en annan miljö än utvecklings- och testmiljön.

Information om extra säkerhet för din Azure Spring Apps-tjänst finns i Distribuera Azure Spring Apps i ett virtuellt nätverk. Om du implementerar den rekommenderade distributionen kan du inte använda GitHub-värdbaserade löpare. Du måste använda din egen löpare för distributionsarbetsflödet.

DevOps

Automatisering av den här konfigurationen via GitHub Actions-arbetsflöden ökar DevOps-produktiviteten. En av de mest användbara funktionerna är möjligheten att snabbt återställa ändringar som beter sig oväntat. Avvisa bara den nya distributionen.

Teams hanterar ofta flera miljöer för samma program. Det är vanligt att flera versioner av ett program distribueras till olika Azure Spring Apps-tjänster. Git-lagringsplatsen, som är den enda sanningskällan, visar vilka versioner av program som för närvarande distribueras till ett kluster.

Kostnadsoptimering

Kostnadsoptimering innebär att söka efter sätt att minska onödiga utgifter och förbättra driftseffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure.

Azure Spring Apps har en Basic-nivå och en Standard-nivå. Mer information finns i Prissättning för Azure Spring Apps. När du använder den blå/gröna distributionsstrategin betalar du för extra virtuell SPU under en kort tid medan distributionen körs.

GitHub erbjuder en kostnadsfri tjänst. Men om du vill använda avancerade säkerhetsrelaterade funktioner som kodägare eller nödvändiga granskare behöver du teamplanen. Mer information finns på sidan med GitHub-priser.

Scenariodistribution

Ett exempel på den här konfigurationen finns i GitHub-lagringsplatsen Automatiserad blå/grön distribution för Azure Spring Apps-program . Lagringsplatsen innehåller också stegen för att konfigurera din Azure Spring Apps-tjänst med hjälp av en Bicep-mall.

Deltagare

Microsoft underhåller det här innehållet. Följande deltagare utvecklade det ursprungliga innehållet.

Huvudförfattare:

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg