Cet article décrit une solution de déploiement bleu/vert haute disponibilité pour les applications sur Azure Spring Apps.
Le modèle de déploiement bleu/vert implique de maintenir une version existante d'une application active (appelée version bleue) pendant qu'une nouvelle version de l'application est déployée (appelée version verte). Ce déploiement vous permet de redémarrer, de préchauffer et de tester la nouvelle version de l'application indépendamment. Une fois la nouvelle version de l'application en cours d'exécution, vous pouvez basculer vers celle-ci et rediriger tout nouveau trafic entrant vers celle-ci. Pour l’utilisateur de l’application, le déploiement de la nouvelle version se produit sans temps d’arrêt visible. Le déploiement bleu/vert permet d'abandonner facilement une nouvelle version sans affecter la version en cours si un nouveau déploiement ne fonctionne pas comme prévu.
Architecture
Le schéma ci-dessous illustre l'architecture de cette approche :
Téléchargez un fichier Visio de cette architecture.
Components
Cette solution utilise les composants suivants :
Azure Spring Apps est une plateforme de microservices moderne pour l'exécution d'applications Java Spring Boot et Steeltoe .NET Core. Le service élimine le code réutilisable pour l'exécution de microservices et vous permet de développer rapidement des applications robustes dans le cloud. Vous pouvez également utiliser Azure Spring Apps pour déployer du code pour chaque application.
GitHub est une plateforme d'hébergement de code fournissant des fonctionnalités de contrôle de version et de collaboration. GitHub offre une gestion de version, une gestion du code source et d’autres fonctionnalités distribuées par Git.
GitHub Actions vous aide à automatiser les flux de travail de développement et de déploiement de logiciels à partir d'un référentiel. Vous pouvez utiliser la plateforme pour créer une configuration d'intégration continue et de livraison continue (CI/CD) entièrement automatisée. Vous pouvez également utiliser GitHub Actions pour créer des environnements pour lesquels vous pouvez configurer des règles comme l'exigence de réviseurs.
Workflow
L'architecture de la solution met en œuvre le flux de travail suivant :
Un développeur apporte une modification à une application. Le référentiel GitHub contient le code de l'application qui doit être déployé dans Azure Spring Apps. Chaque modification apportée au code d'application s'effectue sous le contrôle de code source. GitHub effectue les tâches suivantes :
Veiller à ce que les modifications soient révisées
Empêcher toute modification involontaire ou non autorisée
Veiller à ce que les contrôles de qualité soient terminés
Le référentiel GitHub contient également un flux de travail GitHub Actions pour générer les modifications du code et effectuer les contrôles de qualité nécessaires. Une fois le code compilé, le flux de travail GitHub Actions déploie la version la plus récente du code de l'application dans Azure Spring Apps. Le workflow de GitHub Actions comprend les étapes suivantes :
Déterminer l'environnement de production actif actuel
Déployer le code dans un environnement de non-production Si un environnement de non-production n'existe pas, créez-le.
À ce stade du déploiement, l'ancienne version (bleue) de l'application dans le déploiement de production continue à recevoir tout le trafic de production.
Attendez l'examen du déploiement et l'approbation de la nouvelle application.
Cette étape définit l'heure de démarrage et de préchauffage de l'application (la version verte) nouvellement déployée.
Avant l'approbation, vous pouvez utiliser l'URL de non-production de l'application pour vérifier la nouvelle version et vous assurer qu'elle est prête.
Après approbation, basculez le déploiement en production et le déploiement hors production.
Tout le trafic de production est désormais dirigé vers la nouvelle version de l'application.
Notes
Si vous rejetez le nouveau déploiement, GitHub ne change pas les environnements. La version précédente continue à recevoir le trafic de production.
Après approbation et basculement du trafic, supprimez l'ancien déploiement de production.
Cette étape de nettoyage permet d'obtenir une installation plus économique.
Autres solutions
Cette solution utilise GitHub Actions pour automatiser le déploiement. Vous pouvez également utiliser Azure Pipelines ou tout autre système d'automatisation CI/CD comme alternative. L'exemple fourni dans la section déploiement du scénario utilise les instructions Azure CLI autant que possible, ce qui vous permet de traduire facilement cette configuration en un autre outil d'automatisation. Utilisez un outil CI/CD pour configurer un environnement et y créer un flux d’approbation.
Cette architecture utilise Azure Spring Apps avec des déploiements en tant que service cible. Vous pouvez utiliser les emplacements de préproduction Azure App Service comme alternative. Un emplacement contient la nouvelle version de l'application, qui peut être rechargée, mise à l'épreuve et testée avant de procéder à un échange d'emplacement. L’échange d’emplacement place la nouvelle version en production. Ce processus étant intégré au service, l’installation est facile.
Vous pouvez également placer n’importe quel service Azure hébergeant des points de terminaison Web derrière une solution d’équilibrage de charge. Si vous utilisez cette approche, vous pouvez créer une deuxième instance du service Azure, dans laquelle vous pouvez déployer une nouvelle version de votre application. L'étape suivante consiste à créer un déploiement sans temps d'arrêt en basculant le trafic de la solution d'équilibrage de charge vers le service Azure qui contient la nouvelle version de l'application. Il faut garder à l'esprit que cette approche du déploiement bleu/vert nécessite des frais de gestion importants.
Détails du scénario
Pour certaines applications cloud, il est essentiel de maintenir le temps d’activité le plus élevé possible. Une solution consiste à utiliser une configuration à haute disponibilité, qui peut doubler les coûts. Une autre solution est un plan de récupération d’urgence qui rétablit l’application dans une autre région après une panne. Le coût de ce dernier peut être inférieur, mais le fait de remettre l’application en ligne dans son intégralité prend du temps.
Cet article décrit un processus permettant de garantir une haute disponibilité pendant le déploiement d’une nouvelle version d’une application. Dans une configuration traditionnelle, les nouveaux bits de l’application sont déployés sur le service qui héberge l’application. Cette configuration provoque souvent un rechargement et un redémarrage de l’application. Pendant ce processus, l’application n’est pas disponible.
Cette solution utilise Azure Spring Apps pour implémenter un déploiement bleu/vert et des adresses qui automatisent le déploiement des applications.
Cas d’usage potentiels
Cette solution peut bénéficier de toute organisation nécessitant une haute disponibilité. La solution est particulièrement adaptée aux secteurs tels que le commerce électronique et les jeux, où les temps d’arrêt peuvent entraîner une perte d’activité et de chiffre d’affaires.
Vous pouvez améliorer votre disponibilité en implémentant des déploiements sans temps d’arrêt. Pour plus d’informations, consultez la section Alternatives de cet article.
Considérations
Les considérations suivantes sur les solutions mettent en œuvre les piliers d'Azure Well-Architected Framework. Cette infrastructure est un ensemble de principes directeurs pouvant être utilisés pour améliorer la qualité d'une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Disponibilité
Cette solution vous aide à maintenir la disponibilité de votre application pendant le déploiement d’une nouvelle version. Il n’augmente pas le contrat de niveau de service global fourni par Azure Spring Apps. Les pannes de maintenance qui surviennent sur la plateforme peuvent toujours affecter votre application.
Si vous souhaitez améliorer l'accord de niveau de service global de votre configuration, envisagez de mettre en place un service Azure Spring Apps à haute disponibilité sur plusieurs régions. Dans cette approche, la configuration est précédée d'une solution globale d'équilibrage de la charge.
Extensibilité
Cette solution fonctionne pour chaque application, ce qui est idéal pour les applications de microservices. Elle permet également aux équipes chargées des applications de travailler indépendamment des autres équipes chargées des applications sans influencer la disponibilité de la solution globale.
Cette solution fonctionne également mieux pour chaque application, où chaque application possède son propre flux de travail de déploiement bleu/vert. Si vous combinez des applications dans le même flux de travail, cette configuration devient rapidement complexe, c’est pourquoi nous ne recommandons pas cette approche.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Outre la configuration des autorisations de référentiel, pensez à mettre en œuvre les mesures de sécurité suivantes dans les référentiels Git qui contiennent du code que vous souhaitez déployer dans Azure Spring Apps :
Protection de branche. Protégez les branches qui représentent l’état de production de votre application contre les modifications transmises directement. Exiger que chaque proposition de changement soit soumise sous la forme d'une demande de tirage (PR). Utilisez les PR pour effectuer des vérifications automatiques. Les vérifications peuvent inclure la construction de tout le code et l'exécution des tests unitaires sur le code qu'une PR crée ou modifie.
Revue des demandes de tirage. Pour appliquer le principe des quatre yeux, vous devez disposer d’au moins un réviseur. Vous pouvez également utiliser la fonctionnalité des propriétaires du code GitHub pour définir des personnes ou des équipes chargées de la révision de fichiers spécifiques dans un référentiel.
Historique immuable. N'autorisez que les nouvelles validations en plus des modifications existantes. L’historique immuable est particulièrement important pour les audits.
Autres mesures de sécurité. Demandez à vos utilisateurs GitHub d'activer l'authentification multifacteur. Autorisez aussi uniquement les validations signées qui ne peuvent pas être modifiées ultérieurement.
Nous vous recommandons également d’effectuer le déploiement sur un seul service Azure Spring Apps. Dans une installation de production, vous devez d’abord tester votre code sur d’autres environnements avant de le déployer en production. Votre environnement de production doit de préférence se trouver dans un environnement différent de votre environnement de développement et de test.
Pour plus d'informations sur la sécurité supplémentaire de votre service Spring Azure Apps, reportez-vous à Déployer Azure Spring Apps dans un réseau virtuel. Si vous implémentez le déploiement recommandé, vous ne pouvez pas utiliser d'exécuteurs hébergés sur GitHub. Vous devez utiliser votre propre exécuteur pour le flux de travail de déploiement.
DevOps
L'automatisation de cette configuration via les workflows GitHub Actions augmente la productivité DevOps. L'une des fonctionnalités les plus utiles est la possibilité de restaurer rapidement les modifications en cas de comportement inattendu de l'environnement dû à celles-ci. Refusez simplement le nouveau déploiement.
Les équipes gèrent souvent plusieurs environnements pour la même application. Il est courant que plusieurs versions d’une application soient déployées sur différents services Azure Spring Apps. Le référentiel Git, qui est la seule source de vérité, indique les versions des applications actuellement déployées sur un cluster.
Optimisation des coûts
L'optimisation des coûts consiste à rechercher des moyens de réduire les dépenses inutiles et d'améliorer l'efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Utiliser la calculatrice de prix Azure pour estimer les coûts.
Azure Spring Apps possède un niveau de base et un niveau standard. Pour plus d’informations, consultez Tarification Azure Spring Apps. Lorsque vous utilisez la stratégie de déploiement bleu/vert, vous payez pour des SPU virtuelles supplémentaires pendant une brève période durant l’exécution de votre déploiement.
GitHub offre un service gratuit. Cependant, pour utiliser des fonctionnalités avancées en matière de sécurité comme les propriétaires du code ou les réviseurs requis, vous avez besoin d'un plan Team. Pour plus d’informations, consultez la Page de tarification GitHub.
Déploiement de scénarios
Pour obtenir un exemple de cette configuration, consultez le référentiel GitHub Déploiement automatisé bleu/vert pour les applications Azure Spring Apps. Le référentiel comprend également les étapes de configuration de votre service Azure Spring Apps à l’aide d’un modèle Bicep.
Contributeurs
Microsoft gère ce contenu. Le contributeur suivant a développé le contenu original.
Auteur principal :
- Gitte Vermeiren | Ingénieur FastTrack pour Azure
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Mettre en œuvre cette architecture à l'aide d'un guide pas à pas
- Stratégies de déploiement bleu/vert dans Azure Spring Apps
- Démarrage rapide : Créer et déployer des applications sur Azure Spring Apps
- Configurer un environnement de préproduction dans Azure Spring Apps
- GitHub : comprendre GitHub Actions
- GitHub : utiliser les environnements pour le déploiement
- GitHub : réutiliser des flux de travail