Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Notitie
De Basic, Standarden Enterprise--plannen zijn op 17 maart 2025 buiten gebruik gesteld. Zie de aankondiging over buitengebruikstelling van Azure Spring Apps voor meer informatie.
Het Standaardverbruik en het toegewezen-plan zijn op 30 september 2024 met een uitfasering begonnen, met een volledige beëindiging eind maart 2025. 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. Momenteel is deployment1 ingesteld als productie-implementatie en wordt versie v3 van de toepassing uitgevoerd.
Dit maakt van deployment2 de staging implementatie. Dus, wanneer de CD-pijplijn (Continuous Delivery) klaar is om te worden uitgevoerd, wordt de volgende versie van de app, versie v4, geïmplementeerd in de staging-omgeving deployment2.
Nadat v4 is opgestart op deployment2, kunt u geautomatiseerde en handmatige tests uitvoeren via een privétesteindpunt om ervoor te zorgen dat v4 aan alle verwachtingen voldoet.
Wanneer u er vertrouwen in v4hebt, kunt u instellen deployment2 als productie-implementatie, zodat alle productieverkeer wordt ontvangen.
v3 blijft draaien op deployment1 voor het geval dat u een kritiek probleem ontdekt dat een terugdraaiactie vereist.
Nu is deployment1 de faseringsimplementatie. De volgende uitvoering van de implementatiepijplijn wordt dus geïmplementeerd op deployment1.
U kunt nu V5 testen op het privétesteindpunt van deployment1.
Ten slotte, nadat v5 aan al uw verwachtingen heeft voldaan, stelt u deployment1 opnieuw in als de productie-implementatie, zodat v5 al het productieverkeer ontvangt.
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 raceconditie voor goedkeuring
Stel dat voor de release-pijplijn in de bovenstaande toepassing handmatige goedkeuring is vereist voordat elke nieuwe versie van de toepassing productieverkeer kan ontvangen. Er is een risico dat terwijl één versie (v6) wacht op handmatige goedkeuring in de testomgeving, de implementatiepijplijn opnieuw wordt uitgevoerd en de oude versie overschrijft met een nieuwere versie (v7). Wanneer de goedkeuring voor v6 wordt verleend, zal de pijplijn die v6 implementeerde de stagingimplementatie tot productie instellen. 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 een raceconditie bij goedkeuring te voorkomen, is door gebruik te maken van de zogenaamde Benoemde implementaties, zoals hieronder 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 uitrol vanaf 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 van v6 organiseert, zou dus alleen deployment-v6 als productie-implementatie proberen in te stellen.
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.