Blågröna distributionsstrategier i Azure Spring Apps
Kommentar
Azure Spring Apps är det nya namnet på Azure Spring Cloud-tjänsten. Även om tjänsten har ett nytt namn ser du det gamla namnet på vissa platser ett tag medan vi arbetar med att uppdatera tillgångar som skärmbilder, videor och diagram.
Den här artikeln gäller för: ✔️ Basic/Standard ✔️ Enterprise
I den här artikeln beskrivs stöd för blågrön distribution i Azure Spring Apps.
Azure Spring Apps (standardplan och högre) tillåter två distributioner för varje app, varav endast en tar emot produktionstrafik. Det här mönstret kallas ofta för blågrön distribution. Azure Spring Apps stöd för blågrön distribution, tillsammans med en pipeline för kontinuerlig leverans (CD) och rigorös automatiserad testning, möjliggör smidiga programdistributioner med hög konfidens.
Alternerande distributioner
Det enklaste sättet att implementera blågrön distribution med Azure Spring Apps är att skapa två fasta distributioner och alltid distribuera till den distribution som inte tar emot produktionstrafik. Med Azure Spring Apps-uppgiften för Azure Pipelines kan du distribuera på det här sättet bara genom att ange UseStagingDeployment flaggan till true.
Så här fungerar metoden för alternerande distributioner i praktiken:
Anta att programmet har två distributioner: deployment1 och deployment2. deployment1 För närvarande anges som produktionsdistribution och kör versionen v3 av programmet.
Detta gör deployment2 mellanlagringsdistributionen. När pipelinen för kontinuerlig leverans (CD) är redo att köras distribuerar den därför nästa version av appen, version v4, till mellanlagringsdistributionen deployment2.
När v4 du har startat deployment2den kan du köra automatiserade och manuella tester mot den via en privat testslutpunkt för att säkerställa v4 att alla förväntningar infrias.
När du har förtroende för v4kan du ange deployment2 som produktionsdistribution så att den tar emot all produktionstrafik. v3 fortsätter att köras deployment1 om du upptäcker ett kritiskt problem som kräver återställning.
deployment1 Nu är mellanlagringsdistributionen. Nästa körning av distributionspipelinen distribueras därför till deployment1.
Nu kan du testa V5 den deployment1privata testslutpunkten.
Slutligen, när v5 du uppfyller alla dina förväntningar, anger deployment1 du som produktionsdistribution igen, så att v5 tar emot all produktionstrafik.
Kompromisser med metoden för alternerande distributioner
Metoden för alternerande distributioner är enkel och snabb eftersom den inte kräver att nya distributioner skapas. Det medför dock flera nackdelar, enligt beskrivningen i följande avsnitt.
Beständig distribution av mellanlagring
Mellanlagringsdistributionen körs alltid och förbrukar därför resurser i Azure Spring Apps-instansen. Detta fördubblar effektivt resurskraven för varje program i Azure Spring Apps.
Villkoret för godkännandetävling
Anta att versionspipelinen i programmet ovan kräver manuellt godkännande innan varje ny version av programmet kan ta emot produktionstrafik. Detta skapar en risk för att distributionspipelinen körs igen medan en version (v6) väntar på manuellt godkännande av mellanlagringsdistributionen och skriver över den med en nyare version (v7). När godkännandet för v6 beviljas kommer pipelinen som distribuerades v6 sedan att ange mellanlagringsdistributionen som produktion. Men nu är det den icke godkända v7, inte godkända v6, som distribueras på distributionen och tar emot trafik.
Du kanske kan förhindra konkurrensvillkoret genom att se till att distributionsflödet för en version inte kan börja förrän distributionsflödet för alla tidigare versioner har slutförts eller avbrutits. Ett annat sätt att förhindra godkännandets konkurrensvillkor är att använda metoden Namngivna distributioner som beskrivs nedan.
Namngivna distributioner
I den namngivna distributionsmetoden skapas en ny distribution för varje ny version av programmet som distribueras. När programmet har testats på den skräddarsydda distributionen anges distributionen som produktionsdistribution. Distributionen som innehåller den tidigare versionen kan tillåtas sparas tillräckligt länge för att vara säker på att en återställning inte behövs.
I bilden nedan körs versionen v5 på distributionen deployment-v5. Distributionsnamnet innehåller nu versionen eftersom distributionen skapades specifikt för den här versionen. Det finns ingen annan distribution från början. För att distribuera version v6skapar distributionspipelinen nu en ny distribution deployment-v6 och distribuerar appversionen v6 där.
Det finns ingen risk för att en annan version distribueras parallellt. För det första tillåter inte Azure Spring Apps att en tredje distribution skapas medan det redan finns två distributioner. För det andra, även om det var möjligt att ha fler än två distributioner, identifieras varje distribution av den version av programmet som den innehåller. Pipelinen som samordnar distributionen av v6 skulle därför bara försöka ange deployment-v6 som produktionsdistribution.
När distributionen som skapats för den nya versionen tar emot produktionstrafik måste du ta bort distributionen som innehåller den tidigare versionen för att göra plats för framtida distributioner. Du kanske vill skjuta upp med ett antal minuter eller timmar så att du kan återställa till den tidigare versionen om du upptäcker ett kritiskt problem i den nya versionen.
Kompromisser med den namngivna distributionsmetoden
Den namngivna distributionsmetoden har följande fördelar:
- Det förhindrar godkännandets konkurrensvillkor.
- Det minskar resursförbrukningen genom att ta bort mellanlagringsdistributionen när den inte används.
Det finns dock nackdelar också, enligt beskrivningen i följande avsnitt.
Distributionspipelinefel
Mellan den tidpunkt då en distribution startar och den tid då mellanlagringsdistributionen tas bort misslyckas eventuella ytterligare försök att köra distributionspipelinen. Pipelinen försöker skapa en ny distribution, vilket resulterar i ett fel eftersom endast två distributioner tillåts per program i Azure Spring Apps.
Distributionsorkestreringen måste därför antingen ha möjlighet att försöka utföra en misslyckad distributionsprocess igen vid ett senare tillfälle, eller ett sätt att säkerställa att distributionsflödena för varje version förblir i kö tills flödet har slutförts för alla tidigare versioner.