Du script shell à Ansible

Retour d'expérience sur une migration douloureuse mais heureuse depuis un outil de déploiement maison en script shell vers Ansible.

Transcript

1. Du script shell à Ansible Retour d’expérience sur une migration douloureuse mais heureuse
2. A propos de moi... Claire Villard @leneurone_eu / https://github.com/leneurone Développeuse Java depuis 5 ans 2 ans au sein d’une équipe “Java + DevOps”
3. Le projet • Application de centralisation de logs applicatives chez un client grand compte • ElasticSearch, LogStash, Oracle, WebLogic, Apache, RabbitMQ, Kafka… • 2 environnements de production : 6 serveurs et 24 serveurs • Au total : 10 environnements, ~ 100 serveurs
4. Le projet - Contraintes • Pas de serveurs à la demande • Pas d’accès à Internet • Sécurité réseau variable selon les zones (et les serveurs…) • Machines partagées avec d’autres projets • MeP tous les 2 à 3 mois • Délai de recette ~1 mois
5. L’outil de déploiement “maison” Phase 1 : build • Maven : 1 package de properties par environnement lors des releases
6. L’outil de déploiement “maison” Phase 2 : déploiement • Essentiellement du KSH (30 000+ lignes)... • … Qui lit des fichiers XML décrivant les machines et les environnements… • … Qui déploie via SSH les packages de properties... • … Avec un peu de Python aussi (pour WebLogic) • … Pour notre application, mais aussi 6 autres, soit ~ 1200 serveurs !
7. L’outil de déploiement maison Avantages : • Existait avant Ansible, Puppet, Chef, ... • Adaptabilité aux contraintes infra (OS, firewall, …) • Consultation de la valorisation des variables pour un env. facile Inconvénients : • Packaging applicatif long • Livrables lourds • 1 correction d’une valeur de variable = 1 nouvelle release • Très complexe à comprendre et maintenir • 0 support...
8. Migrons à Ansible !!
9. Pourquoi migrer ? • Packaging applicatif plus rapide et livrables plus légers • Modification d’une valeur d’une variable sans devoir refaire une release • Outil plus facile à comprendre et à utiliser • Support communautaire
10. C’est parti… Stratégie de migration : le “Big Bang” → Erreur #1 ! • Bascule beaucoup plus longue que prévu • Pas de mise en production pendant la migration (6 mois) • Nombreuses indisponibilités des environnements • Difficultés pour voir l’avancement et ne rien oublier Idées pour faire mieux : • S’efforcer de faire cohabiter l’ancien et le nouveau système • Migrer par petits morceaux bien maîtrisés, jusqu’à la production • Rejouer, rejouer, rejouer
11. Les contraintes d’infrastructure “Ce rôle devra gérer les 4 zones réseau, les 2 OS, les 4 versions d’OS, et le café” → Erreur #2 ! • Rôles et modules “couteau suisse” avec trop de cas • Playbooks complexes Idées pour faire mieux : • Harmoniser au maximum les stratégies de déploiement • Privilégier les rôles / modules / playbooks simples exécutés au besoin • Gérer les cas 1 par 1 jusqu’à la production et complexifier petit à petit ensuite
12. La gestion des variables Avant : toutes les variables dans l’application, gérées par des filtres Maven Après : toutes les variables dans Ansible • Logique de priorité des variables “inversée” entre Maven et Ansible • Beaucoup d’erreurs de refactoring et de recopie Idées pour faire mieux : • Utiliser un outil de comparaison sur les fichiers après remplacement des variables pour contrôler qu’ils sont identiques, sur tous les environnements
13. La stabilisation • Deploy, deploy, deploy, and deploy again • Harmoniser au maximum le fonctionnement entre environnements • Ne pas sous estimer le temps nécessaire !
14. Le rejeu et l’idempotence “Je dois pouvoir rejouer N fois mon playbook sans impact” → Bonne idée #1 ! • Garde une procédure de déploiement simple et identique d’une version à l’ autre, qu’elle soit majeure ou mineure Idée pour faire encore mieux : • Rendre les scripts de démarrage des produits (services, etc.) idempotents aussi pour limiter les tests dans les playbooks
15. L’idempotence et le temps de déploiement • 30 minutes pour un playbook qui ne modifie rien… → c’est trop long ! Idées pour faire mieux • Optimiser les connexions SSH • Optimiser les transferts réseau • Compromis entre vitesse de déploiement et idempotence • Détecter l’inutilité au plus tôt sans prendre de risques au rejeu
16. Faire des modules maison → Bonne idée #2 ! … A condition de savoir faire du Python et d’en avoir le besoin • Évite les redondances dans les playbooks • Permet de mutualiser du code • Est lisible • Plus puissant que les modules Core seuls Idées pour faire encore mieux • Éviter de multiplier les paramètres en entrée pour qu’ils restent simples à documenter et à utiliser • De la doc, de la doc, et encore de la doc !
17. Le résultat...
18. Ca marche ! • Plus robuste • Plus facile à comprendre pour un développeur Java • Beaucoup plus facile à faire évoluer • Des traces de déploiement complètes sans effort
19. En conclusion... • Satisfaits du choix d’Ansible • Migration douloureuse (1 an) mais réussie • Robustesse, efficacité et facilité de prise en main au rendez-vous
20. Merci !