Azure : Slot Deployment & Blue Green
par Julien HATZIG
Aujourd’hui, c’est un grand jour, c’est jour de livraison, il est 21h00, après une dure journée de travail à préparer la mise en production vous avez décidé de livrer une nouvelle version de l’application, attendue depuis plusieurs semaines par votre métier. En analysant le trafic, vous savez qu’à cette heure-ci, il est limité, seulement quelques requêtes par seconde.
Au même moment, un utilisateur parcourt votre site, et alors qu’il effectue une saisie, une page d’erreur technique s’affiche sur son écran. Après plusieurs tentatives de “F5” ou “Ctrl + F5” — comme on lui a appris — le site ne répond toujours pas, et pire, le site affiche une page blanche pendant de longues minutes.
Mécontent, il décide d’envoyer un énième email à l’équipe technique, son expérience utilisateur est gâchée, votre livraison bien que techniquement réussie est un échec.
Comment empêcher cette situation ?
Avec l’arrivée du cloud et des solutions “PaaS” (Platform as a Service), Microsoft Azure propose une fonctionnalité très intéressante pour garantir une haute disponibilité de vos applications.
Cette fonctionnalité s’appelle le “Slot Deployment” mais qu’est ce que cela veut dire ?
Les slots de déploiements sont une fonctionnalité présente dans Azure App Service. Ce sont des “copies” de vos applications (par exemple -stage ou -test). Le slot de “production” correspond au slot dans lequel vos utilisateurs se situent. Les slots vous permettent de valider tout changement avant de les “swapper” vers le slot de production.
Et techniquement, comment ça se passe ?
Le “Slot Deployment” est situé au niveau de votre webApp. Il n’est pas nécessaire de créer une seconde webApp. Vous disposez de deux “slots” sur la même webapp. Vous pouvez “swapper” sur le slot A ou le slot B : soit de manière automatique en redirigeant l’ensemble du trafic vers le slot B, soit de manière manuelle avec l’A/B Testing quand vous décidez de rediriger le X pourcent du trafic vers le slot B.
Les slots offrent également la possibilité d’avoir des paramètres d’applications différents. Par exemple, sur votre slot de test, vous ne souhaitez pas accéder à une API de production. Vous avez la possibilité de changer son paramètre pour accéder à une API de mocks.
Comment automatiser via les templates ARM, le slot deployment ?
Dans les templates ARM, vous allez spécifier le slot de déploiement sur lequel la livraison va être déployée :
A/B Testing, Késako ?
Un peu plus haut, je vous ai parlé de l’A/B Testing proposé par la fonctionnalité du slot deployment. Il faut savoir que cela reste un A/B Testing très simple. Vous avez la possibilité de rediriger — de manière totalement aléatoire — le trafic utilisateur vers le slot B. Vous pouvez donc décider de basculer 50% du trafic vers le nouveau slot.
Si vous laissez 0%, il faudra que les utilisateurs connaissent l’url de staging.
Car le slot possède sa propre configuration et son propre hostName.
Le « Slot Deployment » est-il indispensable ?
1. Une livraison à chaud, sans interruption de service
Finies les livraisons en soirée, après une longue journée de travail, vous livrez en journée, en assurant une haute disponibilité de votre site. Puisque la webApp gère en automatique le trafic et le déploiement, les utilisateurs ne sont pas impactés par une livraison. Il n’y a pas d’interruption de service. Ce processus vous permet également de simplifier vos livraisons, et donc de livrer plus souvent, des releases de plus petite taille. On ne livre plus un monolithe tous les 3–4 mois.
2. Un BUG est détecté ? Faut-il faire un retour arrière ?
Vos logs AppInsights et vos alertes de monitoring vous remontent une anomalie, vous avez livré du code qui introduit un bug : Pas de panique.
→ Si vous constatez le bug sur le slot B, et que celui ci n’est accessible que par une url connue de vous, il suffira de livrer le correctif sur le slot sans impacter la production.
→ Si vous constatez le bug sur le slot B, et que vous avez redirigé le trafic sur celui ci, il faut rebasculer le trafic vers le slot de production. Les utilisateurs seront automatiquement redirigés vers le slot de production.
3. Le staging est en production, la production devient le staging ?
Après quelques heures/jours sur le nouveau couloir de production (slot B), il est temps pour vous de déployer sur l’ancien couloir de production (slot A) la livraison afin d’avoir vos deux slots identiques.
Vous pourrez ensuite rebasculer l’ensemble du trafic vers le slot A si vous le souhaitez.
Oui, mais y a t’il des risques/limites ?
1. Votre application est interfacée avec une base de données ?
Votre code doit donc être résilient et s’adapter à toutes modifications de la structure de la base de données. Si on ajoute ou supprime une colonne dans une table, il faut que le code présent dans le slot de production continue de fonctionner sans risquer de générer un bug. Une des règles d’or est de mettre de valeur par défaut sur une nouvelle colonne, il ne faut pas rendre un champ obligatoire. Il faut prévoir des scripts SQL de rollback et s’inscrire dans une démarche de déploiement Blue/Green.
2. L’A/B Testing proposé par le Slot Deployment est très sommaire
Par exemple, vous ne pouvez pas configurer une liste d’utilisateurs, la redirection du trafic se fait de manière aléatoire. Difficile donc de cibler une personne en particulier pour faire partie du pilote. Cependant l’A/B testing est adapté à un déploiement progressif du trafic : 4% , 20%, 40%, 60%, 80% 100%. Attention, tout se fera de manière manuelle. Pour le moment, le déploiement progressif automatisé n’est pas au programme du slot deployment. Vous pouvez également communiquer l’adresse du slot à des utilisateurs identifiés au préalable.
3. Tous les paramètres ne sont pas swappés
Les paramètres suivants sont propres à chaque slot et sont donc à configurer unitairement :
- Endpoint
- DNS personnalisé
- Certificats et paramètres TLS/SSL
- Paramètres de Scaling
- Paramètres de planification des WebJobs
- Restrictions d’IP
- Always On
- Paramètres de Diagnostic/Log
- Cross-origin resource sharing (CORS)
Demain, c’est un jour comme un autre, c’est jour de livraison, il est 15h36, vous avez décidé de livrer une nouvelle version de votre application — pas vraiment attendue car vous livrez régulièrement de petites fonctionnalités chaque semaine — vous savez que le trafic à ce moment là sur votre site, est au plus fort, on parle de plusieurs centaines de requêtes à la seconde, mais vous n’avez pas peur. Vous déployez votre site à l’aide du “Slot Deployment”.
En parallèle, des centaines d’utilisateurs parcourent votre site, et ne se sont pas rendus compte qu’ils viennent de migrer — en mode big bang ou via A/B testing — vers une nouvelle version de l’application. Le site affiche toujours une haute disponibilité de 100%.
L’expérience utilisateur a été préservée. Votre livraison est un succès.
Thanks to Aurélien Vanhoucke, Jérôme Boukorras, Guillaume Menegatti, triathlete_23, and Christophe Mignot.
👉 Auteur : Julien Hatzig
