Stratégies avancées de déploiement avec Istio: Blue-Green, A/B testing et Canary

L’un des défis de l’automatisation du déploiement est le passage de la phase finale des tests d’une application à la production. Nous devons généralement le faire rapidement afin de minimiser les temps d’arrêt. C’est à cette question que doit répondre le déploiement continu et l’ensemble d’un processus DevOps. Nous avons souvent besoin de mettre en place des stratégies de déploiement pour réussir un déploiement automatisé jusqu’en production.

Une stratégie de déploiement est un moyen de modifier ou de mettre à niveau une application. Le but est de faire le changement sans temps d’arrêt de manière à ce que l’utilisateur remarque à peine les améliorations.

Qu’est-ce que le déploiement continu (CD)?

Aujourd’hui nous vivons à l’ère DevOps et certaines entreprises effectuent plusieurs déploiements par jour. Il existe certaines stratégies pour augmenter la fréquence des déploiements qui aident à réduire les risques de temps d’arrêt sans que les utilisateurs ne remarquent que quelque chose a changé. 

L’utilisation de workflows d’intégration continue et de déploiement continu (CI/CD) est l’une des meilleures pratiques à mettre en œuvre par les équipes Devops. Il s’agit également d’une pratique de méthodologie agile, car elles permettent aux équipes de développement de se concentrer sur la satisfaction des exigences commerciales,

Le déploiement continu (CD) est la suite de l’intégration continue. Une fois que les tests sont validés sur l’environnement de développement, il faut immédiatement sans attendre mettre en production. Le déploiement continu consiste donc à automatiser les actions de déploiements qui étaient auparavant réalisées manuellement. C’est pour cette raison que l’on parle souvent de CI/CD ensemble, l’un va difficilement sans l’autre. 

Il faut aussi noter que sans les stratégies avancées de déploiement, il est difficile de mettre en place le déploiement continu. C’est la raison pour laquelle 99 % des DevOps ne font pas de CD (Continuous deployment). En réalité il font du CD (Continuous Delivery).

Pour réussir le déploiement continu, il est nécessaire de faire appel aux stratégies avancée de déploiement pour garantir la continuité des services. Nous allons voir dans la suites certaines stratégies avancées de déploiement (Blue-Green, A/B testing et Canary) et leurs mises en oeuvre avec Istio.

Blue-Green

Qu’est-ce que le Blue-Green?

Un déploiement Blue-Green utilise deux environnements de production configurés de manière identique sur lesquels vous pouvez déployer votre application et un routeur pour envoyer du trafic utilisateur vers l’un ou l’autre. L’un des environnement (le Blue) sert activement les utilisateurs et l’autre environnement (Green) est inactif. Lorsqu’une nouvelle version de l’application est prête, on la déploie sur l’environnement Green pour effectuer les dernières étapes de test. Une fois que l’application fonctionne dans l’environnement Green, on change de routeur pour que tout le trafic utilisateur soit dirigé vers l’environnement Green et le Blue devient maintenant inactif.

Comment fonctionne le Blue-Green?

Dans ce déploiement Blue-Green, la version Green est déployée en même temps que la version Blue. Il permet de mettre à niveau une application existante, en basculant complètement d’une version à une autre, dès qu’on vérifie que la nouvelle version répond aux exigences. Cela permet de réduire le temps d’interruption de service. En d’autres termes, l’utilisateur de l’application en question ressentira juste une légère interruption en passant de la version Blue à la version Green.

Avantages
  • L’implémentation est facile et rapide
  • Roll-Back possible car l’ancien déploiement est encore opérationnel
Inconvénients
  • Besoin de deux fois plus de ressources
  • Une brève coupure qui peut gêner la production
Comment faire du Blue-Green avec Istio?

Avec Istio, on peut effectuer un déploiement Blue-Green entre deux déploiements en utilisant les règles de destination pour décrire les versions et des services virtuels pour le basculement du trafic d’une version à une autre. 

Supposons que nous avons déployé deux versions du microservice productpage dans le cluster. Nous pouvons ainsi créer la règle de destination ci-dessous pour spécifier à Istio l’ensemble des versions déployées de ce microservice.

Copy to Clipboard

Après cela, nous créons un service virtuel qui route le trafic vers une des versions par exemple la version v1 comme décrit ci-dessus.

Copy to Clipboard

Istio va transférer toutes requêtes vers le microservice productpage vers la version v1. Pour passer à la version v2, il suffit juste de changer la valeur du champ subset du service virtuel par v2 et tout le trafic bascule vers v2.

A/B Testing

Qu’est-ce que le test A/B?

Le test A/B est une méthode de comparaison de deux versions d’une application pour déterminer celle qui fonctionne mieux. Les tests A/B sont essentiellement des expériences dans lesquelles deux variantes ou plus d’une application sont présentées aux utilisateurs de manière aléatoire, et une analyse statistique est utilisée pour déterminer quelle variation fonctionne mieux pour un objectif donné.

Les cas d’utilisation pour les tests A/B de microservices sont souvent l’essai de nouvelles fonctionnalités pour une partie d’utilisateurs ou de régions géographiques, ou le test d’une mise à jour à une échelle réduite avant le déploiement complet. 

Dans cette stratégie de déploiement, si un nombre significatif d’erreurs est détecté sur la nouvelle version le déploiement peut alors être annulé et tout le trafic est envoyé au service ancien. 

Comment fonctionne un A/B testing?

Dans un test A/B, nous modifions une page Web d’une application pour créer une deuxième version de la même page. Ce changement peut être un simple titre ou la position d’un bouton, ou une refonte complète de la page. Ensuite, une partie du trafic affiche la version originale de la page et l’autre partie, identifiée par un paramètre spécifique, la version modifiée de la page.

  

Comment faire un A/B testing avec Istio?

Le routage du trafic d’Istio peut être utilisé pour les tests A/B, le test de nouvelles fonctionnalités en envoyant une partie du trafic client vers les services avec la nouvelle fonctionnalité et en observant la télémétrie et les commentaires des utilisateurs.

Istio offre plusieurs moyens pour mettre en oeuvre les tests A/B. Parmi eux, il y a le routage du trafic en fonction d’un host spécifique,  d’une valeur de cookie, d’un paramètre de requête et d’entêtes HTTP, etc…

Ci-dessous un exemple de service virtuel permettant de router la requête vers la version v2 du service reviews si elle contient l’entête end-user avec la valeur “test” et vers la version v1 sinon.

Copy to Clipboard

Ci-dessous un service virtuel qui route le trafic vers reviews:v2 si les cookies sont présentes et vers reviews:v1 sinon.

Copy to Clipboard

Test Canary

Qu’est-ce que le test Canary?

Le test canary est un moyen de réduire les risques et de valider de nouvelles versions de logiciels en proposant des versions à un petit pourcentage d’utilisateurs. Avec le test canary, nous pouvons livrer une nouvelle version à certains groupes d’utilisateurs. Le test canary est une meilleure pratique en matière de déploiement continu. Son objectif est de détecter et de résoudre rapidement un problème avec une nouvelle version de logiciel avant qu’il ne dégrade l’expérience de chacun.

Comment fonctionne un test canary?

Le canary pourrait être considéré comme un cas spécial de test A / B, dans lequel le déploiement se produit de manière progressive. Le trafic est transféré lentement d’une version d’une application à une version plus récente d’une application à l’aide d’un routeur de trafic au niveau du serveur. 

On commence par déployer une nouvelle version de service, qui ne reçoit aucun trafic. Si l’on observe que le service démarre en bonne santé, on dirige un petit pourcentage de trafic (par exemple 10%) vers ce service. Les erreurs sont surveillées en permanence. La bonne santé du service est récompensée par une augmentation du trafic jusqu’à ce que le nouveau service reçoive 100% du trafic. Ce qui permet en inverse d’arrêter progressivement les anciens services. La mise en place de cette stratégie de déploiement repose sur des contrôles de santé fiables et précis des applications.

Comment faire un test canary avec Istio?

Avec Istio, cette stratégie est mise en oeuvre avec le routage basé sur le poids.  Ce dernier est effectué à l’aide des services virtuels en ajustant la pondération relative du trafic entre les versions d’un service donné. Par exemple le service virtuel ci-dessous route 90% du trafic vers la version reviews:v1 et 10% vers reviews:v2.

Copy to Clipboard

Pour résumer

Dans cet article, nous avons vu qu’il existe plusieurs façons de déployer une nouvelle version d’une application. L’utilisation d’une des stratégies de déploiement dépend des besoins et du budget.

  • En production, un déploiement Blue-Green est généralement un bon choix, mais des tests appropriés de la nouvelle version de l’application sont nécessaires au préalable. Cependant il a plus d’impact sur le budget car il nécessite une double capacité de ressources.
  • Si l’application manque de tests au préalable ou s’il y a peu de confiance quant à l’impact et la stabilité de l’application, alors la technique du test canary peut être utilisée car la migration vers la nouvelle version se fait progressivement.
  • Si l’on cible d’abord un ensemble d’utilisateurs, caractérisé par des paramètres spécifiques, pour tester une nouvelle fonctionnalité, le A/B testing peut être le choix adéquat.

A travers cet article, nous avons vu que toutes ces stratégies peuvent facilement être mises en œuvre avec Istio. Il fournit des outils nécessaires sans avoir à se soucier des détails sous-jacents.