Avant chaque déploiement d’application en production sur kubernetes vous voulez vous assurer que le déploiement se déroule bien, et que vos utilisateurs finaux auront un produit à la hauteur de leurs attentes. Sécurité, Scaling, Disaster recovery sont alors des sujets auxquels vous devrez apporter une attention particulière avant de déployer votre application en production.
Dans cet article nous allons couvrir les meilleures pratiques que nous recommandons de suivre avant le déploiement en production de votre application.
Disaster Recovery : établir un plan et l’exécuter
Définir un plan de reprise garantit que l’équipe de l’application et de la plate-forme s’accorde sur qui est responsable de quoi.
Un plan de reprise après sinistre claire et bien défini, vous permet de minimiser les risques liés à la coupure de vos services et de votre application.
Nous préconisons de faire un plan de reprise :
1 – Simple :
Un plan simple permet à vos équipes de faire une reprise rapide afin de remettre votre application en état de marche.
2 – Reproductible :
N’attendez pas qu’un problème se produise pour exécuter votre plan, simuler le problème en amont, tester votre plan et adaptez le au fur et à mesure.
3 – Adaptable :
Votre plan doit être facilement adaptable et facile à mettre à jour.
Par exemple, afin de tester votre plan de reprise, vous pouvez détruire l’environnement et le restaurer à partir de la dernière sauvegarde. Vérifiez si votre application est sauvegardée et si ses données sont à jour.
Assurez-vous de stocker les données d’application dans des volumes persistants ou dans une base de données managée dans le cloud.
Automatisation des déploiements.
L’automatisation des déploiements, permet de réduire les interventions manuelles, il vous permet de vous baser sur du code pour déployer vos applications. Beaucoup d’entreprises font des déploiement manuellement, ou le savoir du déploiement est dans les mains de un ou deux SRE ou développeurs, en vous basant sur l’automatisation vous éliminer le risque d’être bloqué et de perdre du temps en cas de départ de vos ressources.
Il faut donc tester et s’assurer que les déploiements fonctionnent de manière automatisée, cela permet de vérifier que tout est stocké sur votre github, et que toutes les étapes de déploiement sont automatisées, et qu’ aucune action manuelle n’est requise.
Aussi, il faut vérifier que vous avez la documentation pour votre déploiement, et que toutes les étapes et autres informations sont répertoriées dans un document.
Pour tester vos déploiements automatisés, il suffit de “réinitialiser” l’environnement, c’est-à-dire de supprimer toutes les images de conteneurs, de supprimer toutes les images de conteneurs mises en cache, de supprimer toutes les ressources Kubernetes, etc. Puis déplacez votre application.
Mener des tests de charges
Avant de lancer une nouvelle version de votre application, ou la version initiale, vous devez pouvoir la tester en charge.
L’objectif des tests de charges sont :
- S’assurer qu’une capacité suffisante a été allouée à l’environnement et à l’application.
- S’assurer que l’application peut être mise à jour sans temps d’arrêt, en donnant les garanties de disponibilité adéquates que l’on attend.
- S’assurer que le disaster recovery fonctionne.
Pour cela, nous vous recommandons de mener des tests de charges dans ces trois situations :
- Test de charge simple, pour s’assurer qu’un capacité suffisante a été alloué à l’environnement et à l’application : Dans ce cas vous allez faire un test sur votre application en l’état.
- Test lors de la mise à jour de l’application, Pour s’assurer que l’application peut être mise à jour sans temps d’arrêt, en donnant les garanties de disponibilité adéquates que l’on attend. Dans ce cas, effectuer un changement trivial sur votre application et faites le test.
- Test lors de la suppression d’une des régions ou votre application est déployée. L’objectif est de tester la résilience afin de s’assurer qu’une défaillance régionale ne va pas entraîner une interruption de l’application.
- Test lors de la mise à jour d’un cluster, Une défaillance de nœud peut entraîner un temps d’arrêt de l’application. Comme un test de charge classique, mais demandez maintenant à l’administrateur d’effectuer un redémarrage progressif de tous les nœuds du cluster Kubernetes.
Conclusion
En suivant ces bonnes pratiques, vous pouvez déployer sereinement vos applications dans kubernetes.
Dans un environnement microservices, ou vous devez innover rapidement et de façon récurrente, il est préférable de souvent tester les points listés ci-dessous, cela vous fera gagner du temps et l’impact sur vos applications sera minime car vous vous êtes déjà entraînés sur les défaillances que pourrait avoir vos application et votre cluster kubernetes.
