Blauwgroene implementatiestrategieën in Azure Spring Apps
Notitie
De Basic-, Standard- en Enterprise-abonnementen worden afgeschaft vanaf medio maart 2025, met een pensioenperiode van 3 jaar. We raden u aan om over te stappen naar Azure Container Apps. Zie de aankondiging over buitengebruikstelling van Azure Spring Apps voor meer informatie.
Het standaardverbruik en het speciale abonnement worden vanaf 30 september 2024 afgeschaft, met een volledige afsluiting na zes maanden. We raden u aan om over te stappen naar Azure Container Apps. Zie Azure Spring Apps Standard-verbruik en toegewezen abonnement migreren naar Azure Container Apps voor meer informatie.
Dit artikel is van toepassing op: ✔️ Basic/Standard ✔️ Enterprise
In dit artikel wordt de blauwgroene implementatieondersteuning in Azure Spring Apps beschreven.
Azure Spring Apps (Standard-abonnement en hoger) staat twee implementaties toe voor elke app, waarvan slechts één productieverkeer ontvangt. Dit patroon wordt meestal blauwgroene implementatie genoemd. De ondersteuning van Azure Spring Apps voor blauwgroene implementatie, samen met een CD-pijplijn (Continuous Delivery) en strenge geautomatiseerde tests, maakt flexibele toepassingsimplementaties met een hoge betrouwbaarheid mogelijk.
Afwisselende implementaties
De eenvoudigste manier om blauwgroene implementatie te implementeren met Azure Spring Apps is door twee vaste implementaties te maken en altijd te implementeren in de implementatie die geen productieverkeer ontvangt. Met de Azure Spring Apps-taak voor Azure Pipelines kunt u deze op deze manier implementeren door de UseStagingDeployment vlag in te stellen op true.
Zo werkt de benadering van afwisselende implementaties in de praktijk:
Stel dat uw toepassing twee implementaties heeft: deployment1 en deployment2. deployment1 Momenteel is ingesteld als productie-implementatie en wordt de versie v3 van de toepassing uitgevoerd.
Dit maakt deployment2 de faseringsimplementatie. Wanneer de cd-pijplijn (Continuous Delivery) dus klaar is om te worden uitgevoerd, wordt de volgende versie van de app, versie v4, geïmplementeerd in de faseringsimplementatie deployment2.
Nadat v4 de test is gestart deployment2, kunt u geautomatiseerde en handmatige tests uitvoeren via een privétesteindpunt om ervoor te zorgen dat v4 aan alle verwachtingen wordt voldaan.
Wanneer u er vertrouwen in v4hebt, kunt u instellen deployment2 als productie-implementatie, zodat alle productieverkeer wordt ontvangen. v3 blijft actief deployment1 voor het geval u een kritiek probleem ontdekt waarvoor terugdraaien is vereist.
Nu is deployment1 de faseringsimplementatie. De volgende uitvoering van de implementatiepijplijn wordt dus geïmplementeerd op deployment1.
U kunt nu testen V5 op deployment1het privétesteindpunt.
Ten slotte hebt u, nadat v5 u aan al uw verwachtingen hebt voldaan, opnieuw ingesteld deployment1 als de productie-implementatie, zodat al het v5 productieverkeer wordt ontvangen.
Compromissen van de benadering van afwisselende implementaties
De benadering voor afwisselende implementaties is eenvoudig en snel, omdat er geen nieuwe implementaties hoeven te worden gemaakt. Het biedt echter verschillende nadelen, zoals beschreven in de volgende secties.
Permanente faseringsimplementatie
De faseringsimplementatie blijft altijd actief en verbruikt dus resources van het Azure Spring Apps-exemplaar. Dit verdubbelt de resourcevereisten van elke toepassing in Azure Spring Apps.
De voorwaarde voor goedkeuringsrace
Stel dat voor de release-pijplijn in de bovenstaande toepassing handmatige goedkeuring is vereist voordat elke nieuwe versie van de toepassing productieverkeer kan ontvangen. Dit creëert het risico dat terwijl één versie (v6) wacht op handmatige goedkeuring voor de faseringsimplementatie, de implementatiepijplijn opnieuw wordt uitgevoerd en overschrijft met een nieuwere versie (v7). Wanneer de goedkeuring wordt v6 verleend, wordt de faseringsimplementatie door de geïmplementeerde pijplijn v6 ingesteld als productie. Maar nu is het de niet-goedgekeurde v7, niet de goedgekeurde v6, die op die implementatie is geïmplementeerd en verkeer ontvangt.
Mogelijk kunt u de racevoorwaarde voorkomen door ervoor te zorgen dat de implementatiestroom voor één versie pas kan beginnen als de implementatiestroom voor alle vorige versies is voltooid of afgebroken. Een andere manier om te voorkomen dat de voorwaarde voor goedkeuringsraces wordt gebruikt, is het gebruik van de methode Benoemde implementaties die hieronder worden beschreven.
Benoemde implementaties
In de benadering met benoemde implementaties wordt er een nieuwe implementatie gemaakt voor elke nieuwe versie van de toepassing die wordt geïmplementeerd. Nadat de toepassing is getest op de op maat gemaakte implementatie, wordt die implementatie ingesteld als productie-implementatie. De implementatie met de vorige versie kan zo lang genoeg blijven bestaan om er zeker van te zijn dat een terugdraaiactie niet nodig is.
In de onderstaande afbeelding wordt de versie v5 uitgevoerd op de implementatie deployment-v5. De implementatienaam bevat nu de versie omdat de implementatie specifiek is gemaakt voor deze versie. Er is geen andere implementatie aan het begin. Als u nu versie v6wilt implementeren, maakt de implementatiepijplijn een nieuwe implementatie deployment-v6 en implementeert de app-versie v6 daar.
Er is geen risico dat een andere versie parallel wordt geïmplementeerd. Ten eerste staat Azure Spring Apps het maken van een derde implementatie niet toe, terwijl er al twee implementaties bestaan. Ten tweede, zelfs als het mogelijk was om meer dan twee implementaties te hebben, wordt elke implementatie geïdentificeerd door de versie van de toepassing die deze bevat. De pijplijn die de implementatie v6 organiseert, probeert dus alleen in te stellen deployment-v6 als productie-implementatie.
Nadat de implementatie die voor de nieuwe versie is gemaakt, productieverkeer ontvangt, moet u de implementatie met de vorige versie verwijderen om ruimte te maken voor toekomstige implementaties. U kunt het aantal minuten of uren uitstellen, zodat u kunt terugkeren naar de vorige versie als u een kritiek probleem in de nieuwe versie ontdekt.
Compromissen van de methode voor benoemde implementaties
De benadering voor benoemde implementaties heeft de volgende voordelen:
- Hiermee voorkomt u de voorwaarde van de goedkeuringsrace.
- Het vermindert het resourceverbruik door de faseringsimplementatie te verwijderen wanneer deze niet in gebruik is.
Er zijn echter ook nadelen, zoals beschreven in de volgende sectie.
Implementatiepijplijnfouten
Tussen het moment dat een implementatie wordt gestart en de tijd waarop de faseringsimplementatie wordt verwijderd, mislukken eventuele extra pogingen om de implementatiepijplijn uit te voeren. De pijplijn probeert een nieuwe implementatie te maken, wat resulteert in een fout omdat er slechts twee implementaties zijn toegestaan per toepassing in Azure Spring Apps.
Daarom moet de implementatieindeling de middelen hebben om een mislukt implementatieproces op een later tijdstip opnieuw uit te voeren, of de middelen om ervoor te zorgen dat de implementatiestromen voor elke versie in de wachtrij blijven staan totdat de stroom voor alle vorige versies is voltooid.