Partager via


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 au : Niveau ✔️ De base/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.

Le diagramme montre le deployment 1 avec la v3 recevant le trafic de production et le deployment 2 mettant en scène la v4.

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.

Diagramme montrant la V4 déployée sur deployment2 et en cours de test.

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.

Diagramme montrant V4 sur deployment2 recevant le trafic de production.

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.

Diagramme montrant la V5 en phase de deployment1.

Vous pouvez maintenant tester V5 sur le point de terminaison de test privé de deployment1.

Diagramme montrant la V5 testée sur le deploymment1.

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.

Diagramme montrant que V5 reçoit le trafic de production sur le deployment1.

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.

Diagramme illustrant la condition de course à l’approbation décrite dans cette section.

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.

Diagramme montrant le deployment d’une nouvelle version sur un deployment nommé comme décrit dans cette section.

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.

Diagramme montrant que v6 est déployé dans deployment-v6 et qu’il reçoit le trafic 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.

Diagramme montrant qu’après une période de repli, le deployment précédent est supprimé.

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.

Étapes suivantes