Stratégies de déploiement bleu-vert dans Azure Spring Apps
Remarque
Les plans Essentiel, Standard et Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de 3 ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce de mise hors service d’Azure Spring Apps.
Le plan de consommation standard et dédiée sera déconseillé à compter du 30 septembre 2024, avec un arrêt complet après six mois. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer le plan de consommation standard et dédiée Azure Spring Apps vers Azure Container Apps.
Cet article s’applique à :✅ Essentiel/Standard ✅ Entreprise
Cet article décrit la prise en charge de déploiement bleu-vert dans Azure Spring Apps.
Azure Spring Apps (plan Standard et supérieur) autorise deux déploiements pour chaque application, un seul reçoit le trafic de production. Ce modèle est connu sous le nom de déploiement bleu-vert. La prise en charge par Azure Spring Apps du déploiement bleu-vert, avec un pipeline de livraison continue (CD) et des tests automatisés rigoureux, permet des déploiements d’applications agiles avec un niveau de confiance élevé.
Déploiements alternés
Le moyen le plus simple d’implémenter un déploiement bleu-vert avec Azure Spring Apps consiste à créer deux déploiements fixes et à toujours déployer sur le déploiement qui ne reçoit pas de trafic de production. Avec la tâche Azure Spring Apps pour Azure Pipelines, vous pouvez déployer de cette façon, juste en affectant à l’indicateur UseStagingDeployment la valeur true.
Voici comment fonctionne l’approche des déploiements alternés dans la pratique :
Supposons que votre application a deux déploiements : deployment1 et deployment2. Actuellement, deployment1 est défini en tant que déploiement de production et exécute la version v3 de l’application.
Ce qui fait de deployment2 le déploiement de préproduction. Ainsi, lorsque le pipeline de livraison continue (CD) est prêt à être exécuté, il déploie la version suivante de l’application, la version v4, sur le déploiement de préproduction deployment2.
Une fois que v4 a démarré sur deployment2, vous pouvez exécuter des tests automatisés et manuels sur ce dernier via un point de terminaison de test privé pour garantir que v4 répond à toutes les attentes.
Lorsque vous avez confiance en v4, vous pouvez définir deployment2 en tant que déploiement de production afin qu’il reçoive tout le trafic de production. v3 continuera à s’exécuter sur deployment1 au cas où vous découvririez un problème critique nécessitant une restauration.
Maintenant, deployment1 est le déploiement de préproduction. Par conséquent, la prochaine exécution du pipeline de déploiement se déploie sur deployment1.
Vous pouvez maintenant tester V5 sur le point de terminaison de test privé de deployment1.
Enfin, une fois que v5 répond à toutes vos attentes, vous définissez deployment1 à nouveau comme déploiement de production afin que v5 reçoive tout le trafic de production.
Compromis de l’approche des déploiements alternés
L’approche des déploiements alternés est simple et rapide, car elle ne nécessite pas la création de nouveaux déploiements. Toutefois, elle présente plusieurs inconvénients, comme décrit dans les sections suivantes.
Déploiement de préproduction persistant
Le déploiement de préproduction s’exécute en continu et consomme donc des ressources de l’instance Azure Spring Apps. Cela double les besoins en ressources de chaque application sur Azure Spring Apps.
Condition de concurrence d’approbation
Supposons que dans l’application ci-dessus, le pipeline de mise en production nécessite une approbation manuelle avant que chaque nouvelle version de l’application ne puisse recevoir le trafic de production. Cela crée le risque que, pendant qu’une version (v6) attend une approbation manuelle sur le déploiement de préproduction, le pipeline de déploiement s’exécute à nouveau et la remplace par une version plus récente (v7). Ensuite, lorsque l’approbation pour v6 est accordée, le pipeline qui a déployé v6 définit le déploiement de préproduction comme déploiement de production. Mais maintenant, c’est la version v7 non approuvée, et non la version v6 approuvée, qui est déployée sur ce déploiement et qui reçoit le trafic.
Vous pouvez éviter la condition de concurrence en vous assurant que le flux de déploiement d’une version ne peut pas commencer tant que le flux de déploiement de toutes les versions précédentes n’est pas terminé ou abandonné. Une autre façon d’éviter la condition de concurrence d’approbation consiste à utiliser l’approche des déploiements nommés décrite ci-dessous.
Déploiements nommés
Dans l’approche des déploiements nommés, un nouveau déploiement est créé pour chaque nouvelle version de l’application en cours de déploiement. Une fois l’application testée sur son déploiement sur mesure, ce déploiement est défini comme déploiement de production. Le déploiement contenant la version précédente peut être autorisé à rester suffisamment longtemps pour être certain qu’une restauration ne sera pas nécessaire.
Dans l’illustration ci-dessous, la version v5 est exécutée sur le déploiement deployment-v5. Le nom du déploiement contient maintenant la version parce que le déploiement a été spécialement créé pour cette version. Il n’y a pas d’autres déploiements au départ. Maintenant, pour déployer la version v6, le pipeline de déploiement crée un nouveau déploiement deployment-v6 et y déploie la version de l’application v6.
Il n’y a aucun risque qu’une autre version soit déployée en parallèle. Premièrement, Azure Spring Apps n’autorise pas la création d’un troisième déploiement alors que deux déploiements existent déjà. Deuxièmement, même s’il était possible d’avoir plus de deux déploiements, chaque déploiement est identifié par la version de l’application qu’il contient. Par conséquent, le pipeline qui orchestre le déploiement de v6 tenterait uniquement de définir deployment-v6 comme déploiement de production.
Une fois que le déploiement créé pour la nouvelle version reçoit le trafic de production, vous devez supprimer le déploiement qui contient la version précédente afin de libérer de l’espace pour les déploiements ultérieurs. Vous voudrez peut-être décaler d’un certain nombre de minutes ou d’heures pour pouvoir revenir à la version précédente si vous rencontrez un problème critique dans la nouvelle version.
Compromis de l’approche des déploiements nommés
L’approche des déploiements nommés présente les avantages suivants :
- Elle empêche la condition de concurrence d’approbation.
- Elle réduit la consommation des ressources en supprimant le déploiement de préproduction lorsqu’il n’est pas utilisé.
Toutefois, il existe également des inconvénients, comme décrit dans la section suivante.
Échecs du pipeline de déploiement
Entre le moment où un déploiement démarre et le moment où le déploiement de préproduction est supprimé, toutes les tentatives supplémentaires d’exécution du pipeline de déploiement échouent. Le pipeline tente de créer un nouveau déploiement, ce qui génère une erreur, car seuls deux déploiements sont autorisés par application dans Azure Spring Apps.
C’est pourquoi l’orchestration de déploiement doit avoir le moyen de réessayer ultérieurement un processus de déploiement qui a échoué, ou le moyen de s’assurer que les flux de déploiement pour chaque version restent en file d’attente jusqu’à ce que le flux soit terminé pour toutes les versions précédentes.