Introduction
Votre éditeur de logiciels s'engage à fournir aux clients les dernières fonctionnalités et améliorations sans perturber leur expérience. Un temps d'arrêt inattendu n'est pas une option. Dans cette leçon, vous allez découvrir comment exploiter les pratiques de déploiement zéro temps d'arrêt (ZDD) pour garantir que vos applications restent hautement disponibles et bénéficient de mises à jour fluides.
Motivation
Dans l'environnement numérique en constante évolution d'aujourd'hui, vos clients exigent un accès permanent à vos applications, quels que soient les mises à jour, les mises à niveau ou les problèmes imprévus. Les temps d'arrêt, qu'ils soient planifiés ou non, peuvent entraîner des pertes financières importantes, nuire à la réputation de votre marque et entraîner la perte de clients précieux. Pour rester compétitif et proposer des solutions innovantes sans interruption, il est essentiel de réduire les temps d'arrêt. Les stratégies de déploiement zéro temps d'arrêt (ZDD) sont essentielles pour atténuer ces risques et garantir une expérience utilisateur fluide.
Stratégies de déploiement Zero Downtime
cf push / cf déploiement
Voici les commandes principales utilisées pour déployer la plupart des applications dans l'environnement Cloud Foundry :
- cf push : charge votre code et vos dépendances dans Cloud Foundry, qui identifie ensuite le buildpack nécessaire, compile votre code et crée une goutte (un package contenant votre application).
cf push my-app
- cf deploy : il est utilisé pour des déploiements plus complexes et n'est utilisé qu'avec la commande de build MBT MTA Build Tool (MBT) pour gérer les applications multicibles (MTA). Il ne fonctionne pas avec les manifestes utilisés dans les commandes push cf.Code Snippet12mbt build cf deploy mta_archive.mtar
Avantages : Facile et efficace pour les déploiements rapides de petites applications.
Inconvénients : bien que cf push et cf deploy conviennent tous les deux à des déploiements simples, cf push manque spécifiquement de capacités intégrées zéro temps d'arrêt, ce qui le rend inadapté aux environnements de production nécessitant une disponibilité continue.
Déploiement glissant de l'application
Dans les déploiements continus, les instances de l'ancienne version sont progressivement remplacées par des instances de la nouvelle version. Cela garantit que certaines versions de l'application sont toujours actives.
cf push APP-NAME --strategy rolling
- Avantages : temps d'arrêt minimal. Capacité à revenir en arrière si des problèmes surviennent.
- Inconvénients : Potentiel de latence en cas de changement de version. Les rollbacks peuvent prendre du temps en raison des modifications apportées aux applications avec état et au schéma de base de données.
Déploiement bleu vert
Le déploiement bleu-vert est une technique puissante pour minimiser les temps d'arrêt et réduire les risques lors des mises à jour de l'application. Dans cette section, vous allez explorer les éléments essentiels de l'implémentation d'une stratégie de déploiement bleu-vert d'applications multicibles à l'aide de Cloud Foundry. Le processus est simple. Voici une synthèse simplifiée :
- Environnement bleu : il s'agit de votre environnement de production actuel. Il est opérationnel, servant tout votre trafic utilisateur.
cf deploy <your-mta-archive-v1> --strategy blue-green
Cette commande lance un déploiement bleu-vert pour une nouvelle application, en commençant par aucun MTA précédemment déployé. Il déclenche les applications appname-idle, les rendant accessibles à des URL spécifiques. Après avoir confirmé que ces instances appname-idle s'exécutent correctement, la commande les renomme de appname-idle en appname, finalisant le processus de déploiement et rendant la nouvelle version active.
- Environnement vert : il s'agit de l'environnement inactif dans lequel vous déployez la nouvelle version de votre application. C'est identique à l'environnement Bleu, mais il ne sert pas encore à aucun trafic.
cf deploy <your-mta-archive-v2> --strategy blue-green
Cette commande lance un déploiement bleu-vert en renommant les applications actuelles en versions "actives" et en lançant de nouvelles versions "inactives". Les versions inactives des applications démarrent et deviennent accessibles à des URL spécifiés. Le déploiement passe ensuite à une phase de test dans laquelle vous pouvez tester la nouvelle version avant de la rendre définitive. Vous avez la possibilité de poursuivre ou d'annuler le déploiement à l'aide de commandes spécifiques. Si vous souhaitez contourner la phase de test, utilisez simplement l'option --skip-testing-phase.
- Test : une fois la nouvelle version déployée dans l'environnement vert, vous pouvez la tester minutieusement sans affecter l'environnement bleu vivant.
- Commutateur : Lorsque vous êtes sûr que la nouvelle version fonctionne parfaitement, vous pouvez changer de routeur pour que toutes les demandes entrantes passent maintenant dans l'environnement vert. Et voilà ! L'environnement vert devient le nouvel environnement vivant. La commande suivante avec l'ID d'opération correct est également imprimée à partir de l'exécution de la dernière commande cf deploy.
cf deploy -i <operation ID> -a resume
Cette commande effectue les opérations suivantes :
- Mappe les itinéraires productifs sur "web-idle" et "backend-idle".
- Supprime les routes temporaires pour 'web-idle' et 'backend-idle'.
- Relance "Web-idle" et "backend-idle" avec les configurations d'itinéraires productifs.
- Renommez "web-idle" et "backend-idle" en "web" et "backend".
- Supprime les applications "Web Live" et "Backend Live" précédemment productives.
- Avantages : la commande "--stratégie bleu-vert" simplifie les déploiements bleu-vert en automatisant l'ensemble du processus, y compris les tests et le nettoyage, réduisant ainsi les étapes manuelles et les erreurs. Il améliore l'efficacité des ressources et offre un mécanisme de rollback facile, garantissant une expérience de déploiement rationalisée et fiable avec un temps d'arrêt minimal.
- Inconvénients : la gestion des sessions utilisateur et la cohérence des données pendant le basculement peuvent s'avérer difficiles, en particulier dans les applications avec état, l'augmentation de la consommation des ressources en raison des environnements en double.
Déploiement canarien
Le déploiement Canary est une stratégie de déploiement qui implique le déploiement progressif d'une nouvelle version d'une application vers un petit sous-ensemble d'utilisateurs ou de serveurs dans un environnement de production en dirigeant initialement un petit pourcentage de trafic vers la version mise à jour tout en conservant la majorité du trafic sur la version stable.
- Avantages : test et validation réels avant le déploiement complet, identification plus facile des problèmes en production et possibilité de revenir rapidement à la version stable si nécessaire.
- Inconvénients : le rollback peut être complexe pour les applications avec état et les modifications de schéma de base de données, et nécessite une planification minutieuse pour garantir une compatibilité vers l'avant et une observabilité efficace.
- Vous déployez une nouvelle version de votre application à l'aide de la commande. cf push <app_name> --strategy canary
- Désormais, une instance d'application est mise à jour avec la nouvelle version. Le trafic est également acheminé vers cette instance d'application, mais le trafic est également acheminé vers les instances de l'application avec l'ancienne version. Vous pouvez être redirigé vers l'instance d'application déployée avec le champ En-tête HTTP :"X-Cf-Process-Instance":"<PROCESS_GUID>:<INDEX>"
- Après le test, vous pouvez mettre à jour les instances d'application avec l'ancienne version vers la nouvelle version à l'aide de la commande.cf continue-deployment <app_name>
Utilisation de Redis pour la gestion des sessions utilisateur dans Approuter
Lorsqu'une application active est remplacée par une application inactive, les données en mémoire sont perdues, ce qui entraîne l'effacement des données de session utilisateur. Pour éviter cela, Approuter active la gestion des sessions externes à l'aide de Redis. Cela permet la récupération de session en cas de plantage de l'instance Approuter d'origine, garantissant ainsi la gestion continue des sessions utilisateur.
Pour des étapes de configuration plus détaillées, reportez-vous à la documentation officielle de SAP Approuter.
Choisir la bonne stratégie ZDD
La stratégie ZDD idéale dépend de plusieurs facteurs :
Criticité des applications : les applications stratégiques exigent une interruption minimale, ce qui favorise souvent les déploiements bleus/verts. Les applications non critiques peuvent tolérer plus de flexibilité, ce qui permet des mises à jour plus rapides avec des déploiements glissants ou canariens.
Contraintes liées aux ressources : des ressources limitées peuvent rendre les déploiements bleu-vert nécessitant beaucoup de ressources moins réalisables. Les déploiements roulants ou canariens sont souvent plus rentables dans de tels cas.
Tolérance aux risques : les entreprises averties aux risques privilégient la sécurité grâce à des déploiements bleu-vert. Les organisations exposées à certains risques peuvent exploiter les déploiements canariens pour des tests réels et la détection précoce des problèmes.
Complexité du déploiement : les déploiements simples à l'aide d'un déploiement cf push ou cf peuvent être rapides, mais entraîneront un temps d'arrêt temporaire. Considérez ces commandes dans le contexte de votre stratégie ZDD plus large.
Synthèse
Le déploiement zéro temps d'arrêt (ZDD) est une pratique cruciale pour le développement de logiciels modernes, en minimisant les interruptions pour les utilisateurs et en garantissant un accès continu aux applications. Dans cette leçon, vous avez découvert différentes stratégies ZDD, y compris les mises à jour continues, les déploiements bleu-vert, les déploiements canaries et la gestion des sessions utilisateur avec la base de données Redis. En comprenant ces stratégies et en tenant compte de facteurs tels que la complexité de l'application, la tolérance au risque et les ressources, vous pouvez sélectionner et implémenter la stratégie ZDD la plus efficace pour vos besoins spécifiques.