Avant de commencer ce discours, euh article, je tiens à remercier de toute mon âme la petite ESN Rennaise Slickteam, sans qui, bien évidement, je ne serais pas là… je veux dire à vous parler, enfin, à vous écrire, bref… Je me comprends.
Dans tous les cas, j’ai pu participer au Breizhcamp 2019 et voir cette conférence qui m’a grandement intéressé et dont je vais tenter de vous en dire quelques mots.
Cette conférence, il s’agit de celle de Mathieu Herbert : “Du Blue-Green au Canary-Release avec Kubernetes” que je vous invite également à regarder sur Youtube:
Mettre à jour la Production
Je vais commencer simplement : « Que celui qui n’a jamais souffert lors d’une Mise En Production me jette la première pierre ? ». Bien souvent encore, les mises en production sont des moments à haut risque et sources de grand stress pour tous les participants.
L’un des objectifs du ‘devOps’ ou plutôt du CI/CD (Continuous Integration/Continuous Deployment) est:
« la mise en production est un non-évènement ».
Avec cette méthodologie, il n’est plus question de faire une mise en production tous les deux ans, mais plus régulièrement.
« Bon ok, c’est bien, mais régulièrement à quel point ? »
Ça pourrait être par exemple:
«- Toutes les deux semaines.»
«- À la fin de chaque sprint par exemple.»
Déjà, j’imagine certaines personnes crier à l’impossibilité, voir… au scandale. Mais, pourtant, on peut aller beaucoup plus loin. Comme par exemple :
« À chaque commit sur la branche ‘master’ !!!».
Bien sûr, on ne passe pas d’une mise en production tous les deux ans à une mise en production à chaque commit en claquant des doigts. Ce n’est jamais si simple. Ça se saurait. Il y a beaucoup de travail à faire avant, tels que :
avoir une solide politique de tests
une gestion de projet solide
Un outillage CI/CD
etc…
Cette liste est loin d’être exhaustive, mais la compléter ne fait pas partie des objectifs de cet article.
L’objectif de cet article est plutôt de se concentrer sur une de ces stratégies, à savoir: La gestion de la mise à jour d’une application en production. Pour cela, on va se concentrer sur trois méthodologies présentées lors de cette conférence :
le Rolling update
le Blue-green deployment
et le Canary release
Une simplification par rapport à la présentation
La conférence prenait exemple d’un déploiement dans un cluster Kubernetes ainsi que l’utilisation d’un outil appelé Traefik. Afin de simplifier l’article, je vais m’abstraire de ces outils au maximum, en limitant autant que possible les connaissances à Kubernetes, afin de me concentrer sur ces trois grands principes de mise à jour.
Voici le schéma de l’application utilisée lors de la présentation :
Afin que ce schéma que je vais utiliser soit plus clair, je vais expliquer quelques principes de Kubernetes. Mais rassurez-vous, on n’ira pas trop loin dans les détails :
Deploy : C’est un outil Kubernetes qui permet de décrire comment déployer notre application. On ne va pas s’intéresser à lui dans cet article.
Pod : C’est l’outil Kubernetes principal. Un pod va contenir notre application. Ou plus exactement l’image docker de notre application qu’on cherche à mettre à jour. Actuellement on utilise la version V1 de l’application représentée en bleu sur ce schéma.
RS : Le replicaSet est un outil Kubernetes qui gère le nombre d’instance disponible d’un même pod. Ici le nombre d’instance est de 3. Il y a donc trois instances identiques de notre application présentes sur le (ou les serveurs).
Ing : l’Ingress controller. C’est le point d’entrée des requêtes utilisateurs. Chaque requête va être redirigée vers un service (ici il n’y en a qu’un). Cet Ingress Controller peut être un Istio ou un Nginx par exemple. Dans la présentation il s’agit de Traefik.
svc : Le service. Il est associé a différentes instances d’un même Pod. Il va redirigé la requête vers un des Pods qui est disponible pour la recevoir.
Pour résumer, notre application est répliquée trois fois dans des pods. Une requête utilisateur arrive par l’Ingress controller, elle est redirigée vers l’unique service qui la redirige finalement vers l’un des trois pods disponibles.
L’objectif sera donc de migrer nos trois pods de la V1 (en bleu) vers une V2 (en vert).
Le Rolling update
Une première stratégie : le Rolling update, qui est le comportement par défaut dans Kubernetes. Il est assez intuitif. Le principe est simple: on va migrer petit à petit chacune des instances de nos trois pods.
Voici les différentes étapes:
On ajoute un nouveau Pod V2
2. On supprime un Pod V1
3. On ajoute un second Pod V2
4. On supprime à nouveau un Pod V1.
etc… jusqu’à la mise à jour complète de tous les Pods.
Cette méthodologie de mise-à-jour est plutôt simple, car directement implémentée dans Kubernetes. Toutefois, elle n’est pas sans conséquence puisqu’il faut connaître avant de savoir si celle-ci est adaptée à notre problématique ou non.
Avant la finalisation de la mise-à-jour, on a pendant un moment des pods à la fois en version V1 et en V2. Si on imagine que notre application est un site web. L’utilisateur va aléatoirement récupérer une page en V1 ou en V2. Imaginez qu’un même utilisateur voit sur son ordinateur la page web affichée en V2, mais s’il rafraîchit la page il risque de visualiser une page en V1. C’est probablement un comportement non souhaité, et dans ce cas-là, il est probable que cette méthodologie ne soit pas la bonne.
The Blue-green deployment
Cette méthodologie est assez simple également et se découpe en trois étapes.
0. L’application V1 est déployée et utilisée
On déploie la V2 à côté de la V1, mais uniquement la V2 reste utilisée.
2. On bascule le trafic de la V1 vers la V2.
3. On vérifie que tout se passe bien. Si oui, on supprime la V1, sinon on repasse le trafic sur la V1.
Avec cette solution, si tout se passe bien, on a plus le même soucis qu’on avait avec le Rolling update. En effet, dans ce cas, le trafic est soit entièrement dirigé vers la V1 ou la V2. On a donc une méthodologie plus intéressante, mais qui présente tout de même des limites.
En effet, que se passe-t-il si on se rend compte de problèmes sur la V2. Entre le temps de mise en place de la V2 et de la détection des soucis, il peut se passer un temps conséquent. Pendant ce laps de temps, le trafic utilise exclusivement la V2. Bien sûr tout dépend du problème. Mais imaginons l’un des pires scénario : un problème difficilement détectable, qui corrompt des données sensibles, difficilement réversible. Ceci peut être catastrophique.
The canary deployment
Le canary deployment est très semblable au blue/green deployment à ceci près qu’il va diminuer grandement le risque.
Le mot canary provient de l’époque des grandes mines de charbons ou les mineurs pour détecter les fuites de gaz avaient avec eux un petit canari en cage. Si celui-ci meurt, c’est que du gaz est présent et qu’il fallait fuir en vitesse… Pauvre petit canari.
On va donc reprendre les étapes du blue/green deployment mais en modifiant l’étape 3. Lors de l’étape 3, on basculait le trafic de la V1 vers la V2. Une autre façon de voir ceci est de dire que:
lors de l’étape 2, 100% du trafic allait de la V1 et 0% à la V2.
lors de l’étape 3, 0% du trafic allait de la V1 et 100% à la V2.
Avec le canary deployment, on va être beaucoup plus prudent. On va par exemple dans un premier temps, laisser 95% du trafic vers la V1, et 5% vers la V2. On vérifie que tout se passe bien. Si oui, on augmente, doucement le pourcentage jusqu’à ce que 100% du trafic soit dirigé vers la V2 et qu’on puisse supprimer la V1.
80% du trafic vers la V1 et 20% vers la V2.
20% du trafic vers la V1 et 80% vers la V2.
0% du trafic vers la V1 et 100% vers la V2.
Cette méthodologie diminue grandement le défaut de la méthode précédent. Si une anomalie se produit, un nombre restreint d’utilisateurs sera impacté. Pour réaliser de telles répartitions de trafic, les outils de type Apache ou Nginx risque de ne pas suffire. Les outils tels que Traefik présentés lors de cette conférence ou encore Istio permettent de réaliser cet aiguillage.
Toutefois, avec cette méthode on risque de se retrouver face au même problème qu’avec la méthodologie du Rolling update. À savoir qu’un même utilisateur risque d’être redirigé tantôt vers la V1, tantôt vers la V2. Il est toutefois possible avec ces outils de dire que pour dans une même session, toutes les requêtes seront dirigées vers la même version, Ce qui limite grandement ce défaut.
Conclusion
Dans cette présentation, trois différentes manières de mise-à-jour d’application ont été abordées :
le Rolling update
le Blue-green deployment
le Canary deployment
Cette liste n’est pas une liste exhaustive les méthodologies des mises-à-jour, mais traduit une évolution. On va de la plus simple à la plus complexe. Mais également vers la plus subtile.
La suite naturelle est la mise en place d’outil de monitoring de votre application. En effet, même si avec le Canary deployment, le risque devient limité. Si on n’a pas d’outil qui nous aide à connaître l’état du système, qui s’assure que l’application fonctionne comme escompté, on risque de ne pas s’en rendre compte. Il est donc indispensable avant d’avoir mis en place des outils de monitoring pour l’application (état des serveurs, logs, métriques, alertes, etc.). Mais je suis sûr que c’est le cas chez vous. N’est-ce pas ? ;)
Slickteam