Kubernetes prend en charge une stratégie de cycle de vie du développement logiciel appelée déploiements bleu-vert, qui implique d’exécuter simultanément les nouvelles et les anciennes versions d’une application en production. Poursuivez votre lecture pour découvrir ce qu’est un déploiement blue-green et pourquoi vous souhaiteriez peut-être mettre en œuvre cette tactique pour vos applications Kubernetes.
Qu’est-ce qu’un déploiement Blue-green ?
Un déploiement blue-green est une stratégie de cycle de vie du développement logiciel qui implique d’exécuter simultanément les versions nouvelle et précédente d’une application en production. Après le déploiement, les utilisateurs migrent progressivement de l’ancienne version (bleue) vers la version plus récente (verte).
Pour fournir rapidement des mises à jour logicielles, les développeurs avaient besoin d’un moyen de déployer en continu des fonctionnalités. Traditionnellement, les déploiements de code nécessitaient des temps d’arrêt, ils étaient donc effectués certains jours, chaque semaine ou chaque mois. Cette stratégie ralentit les mises à jour logicielles et ne prend pas en charge la livraison continue.
Les déploiements « bleu-vert » résolvent ce problème en exécutant les anciennes et les nouvelles versions d’une application en production. La version bleue est l’ancienne application, et la version verte est la nouvelle. Les utilisateurs sont lentement transférés vers la nouvelle version verte après son déploiement. Une fois que les utilisateurs sont transférés vers la nouvelle version verte, la version bleue peut servir de basculement si le code doit être restauré à la version précédente en raison de bogues ou d’erreurs critiques.
Déploiement Blue-green et Rolling avec Kubernetes
Dans de nombreux environnements d’entreprise, la production s’exécute sur plusieurs serveurs. Au lieu d’exécuter plusieurs versions simultanément, un déploiement continu fonctionne avec une version d’une application et met à jour chaque serveur individuellement.
Supposons que vous ayez deux serveurs derrière un équilibreur de charge et que vous exécutiez une seule application de production. Dans un déploiement continu, un développeur met un serveur hors rotation, met à jour l’application, puis remet le serveur en rotation. Le second serveur est mis hors rotation, puis mis à jour. La plupart des environnements roulants disposent de trois serveurs afin qu’un seul serveur puisse agir comme un basculement en cas d’erreurs dans le nouvel environnement de version.
Blue-green et Canary avec Kubernetes
Les déploiements canaries sont similaires aux déploiements bleu-vert, mais ils envoient des utilisateurs spécifiques vers la version la plus récente d’une application plutôt que de déplacer lentement tous les utilisateurs vers la nouvelle version. C’est une excellente stratégie pour tester une nouvelle application avec des utilisateurs intéressés par les tests bêta ou tester en silence de nouvelles fonctionnalités avec de nouveaux utilisateurs pour obtenir des commentaires.
En général, les déploiements canaries sont utilisés sur un petit sous-ensemble d’utilisateurs et la version originale est toujours exécutée pour la majorité des utilisateurs. Étant donné que seul un petit sous-ensemble d’utilisateurs est dirigé vers la nouvelle version, l’infrastructure est moins coûteuse et n’a pas besoin d’être trop avancée pour prendre en charge un petit nombre d’utilisateurs.
Avantages d’un déploiement Blue-green
Dans n’importe quel environnement de livraison continue, les déploiements blue-green offrent plusieurs avantages. Les déploiements « bleu-vert » accélèrent la mise à jour des fonctionnalités applicatives. Les développeurs n’ont plus besoin d’attendre une fenêtre pour déployer un nouveau code, ce qui peut retarder les déploiements de plusieurs mois.
Parmi les trois types de déploiement, les déploiements blue-green sont plus sûrs que les autres. Les deux versions de l’application s’exécutent simultanément, ce qui permet aux développeurs de restaurer les modifications sans effort. Les utilisateurs ne subiront pas de temps d’arrêt ni de perte de productivité pendant les déploiements ou les restaurations si nécessaire.
Inconvénients du déploiement Blue-green
Le principal inconvénient des déploiements bleu-vert est la dépense. Les entreprises doivent disposer du budget informatique nécessaire pour payer les environnements doubles capables d’héberger les versions bleue et verte d’une application. Les organisations paient également les frais de personnel pour la maintenance et la surveillance des deux environnements.
La synchronisation des bases de données constitue un autre obstacle pour les organisations. Les modifications apportées aux bases de données ne sont pas aussi faciles à restaurer. Il faut donc mettre à jour soigneusement les tables et le schéma de base de données, en particulier si les environnements verts et bleus utilisent la même base de données. Les deux environnements doivent être soigneusement testés avant d’être déployés dans des bases de données de production.
Quand utiliser un déploiement Blue-green avec Kubernetes
La livraison continue et Kubernetes vont de pair. Les développeurs peuvent déployer automatiquement des applications à l’aide d’outils d’orchestration tels que Kubernetes . Kubernetes peut être utilisé pour orchestrer les environnements bleu et vert, et les développeurs peuvent simplement déployer du code et permettre à Kubernetes de gérer la promotion du code d’un environnement de préproduction à la production.
Les environnements conteneurisés sont parfaits pour les déploiements bleu-vert, car ils permettent de détruire et de reconstruire rapidement les pods d’application afin qu’ils puissent exécuter des versions bleues ou vertes. Si une application de conteneur génère des erreurs, les développeurs peuvent plus facilement restaurer les modifications apportées à la version bleue.
