Paris DevOps #9 : c’est déployé
Publié le 11/06/2012, par Claude Falguiere dans Événements | 1 Commentaire
Le 7 juin, Valtech accueillait la 9ième réunion de Paris-DevOps. Une soirée autour de 2 présentations de 30 mn réalisées pour Devoxx France.
Devops illustré : la jungle de la configuration d’une application
Dans la première partie de soirée, Gilles Di Guglielmo et Dimitri Baeli, nous ont présenté un pattern de gestion des configurations applicatives qu’ils utilisent sur leur projet chez Lesfurets.com (comparateur d’assurances).
L’objectif est de tracer les variables de configuration dans le code et de permettre leur initialisation par différents moyens, le contexte du process mis à jour depuis un Shell, les propriétés de la JVM passés par la ligne de commande, une fichier de configuration voire la surcharge au démarrage de l’application.
Chaque niveau surcharge le précédent. Les variables de configuration sont clairement identifiées dans le code et lorsque l’application est packagée, il est possible de gérer un fichier de configuration exemple et une documentation des paramètres à modifier pour faciliter les mises à jour en production.
Leur pattern s’appuie sur leur expérience de situation que l’on vit dans le déploiement d’application comme par exemple les données à modifier directement dans le web.xml qui est dans le .war, un fichier archive qui est installé tel quel. Cela génère des demande de documentation, de scripts de mise à jour des paramètres et des échanges plus ou moins sereins. Même dans les cas où les gens se montrent raisonnables, les risques de variables ignorées en raison de typo dans une clé de fichier de configuration ou d’information maintenue à plusieurs endroits par erreur existent toujours.
Il faut noter que même s’il est appliqué ici à Java le principe est portable dans d’autres langages. L’idée est de centraliser l’acquisition des paramètres dans la l’application. En Java, l’implémentation mime les méthodes java.lang.System.getProperty qui ne travaillent que sur des fichiers clé-valeur pour les rendre plus générales.
Les variables de configuration sont déclarées dans un fichier XML et peuvent avoir des propriétés comme le scope dans lequel elles sont traitées. Ce scope lui même est un défini dans un fichier de configuration.
Le pattern est mis en oeuvre par un bout de code qui est lancé depuis le ContextListener. Il vérifie la cohérence de la configuration, acquiert les paramètres et garde de la trace de la source de la configuration. Ce mécanisme peut arrêter le démarrage si des paramètres de configuration sont déclarés plusieurs fois sous le même nom ou ne se conforment pas à certaines contraintes supplémentaires comme l’obligation de les changer sur des environnements non dev (devPurposeOnly).
L’état des variables et la source de leur valeur peut être consulté via une page HTML. Cette page affiche aussi les compteurs d’accès que l’on peut activer pour s’assurer qu’une variable est effectivement utilisée.
Plusieurs démo ont été présentées, en test unitaires depuis un IDE ou en déploiement dans un tomcat.
Ce n’est pas une librairie mais un modèle de code. Il est donc possible de le modifier pour avoir plus de scopes ou ajouter des fonctions utiles sur un projet. Un plugin Maven a été développé pour générer la configuration exemple et sa documentation.
Les slides de la présentation et le code.
Continuous deployement : Rackspace, Chef et capistrano en action
Dans la seconde partie de la soirée Stéphane Rios de Fasterize et Bertrand Paquet d’Octo nous ont présenté la solution mise en place chez Fasterize pour le déploiement continu des serveurs de la solution d’optimisation des pages HTML.
Fasterize est un service de proxy qui optimise les pages HTML à la volée pour qu’elles s’affichent plus vite et soient notamment référencées.
Dès le début Fasterize a voulu une solution de déploiement qui couvre l’ensemble de la plate-forme, l’installation des noeuds, des OS, des applications et des services de surveillance. En effet, cette société utilise un IaaS pour ne pas être limité par les fonctions fournies par un PasS, mais la contrepartie est que la construction et la maintenance des environnements est plus complexe. Il y a beaucoup d’outils différents pour gérer toute la stack et les différents services.
Une autre demande est de déployer le plus souvent possible, d’avoir un processus totalement automatisé pour les opérations courantes et supervisé, d’aller vite.
L’outillage de déploiement mis en place installe l’ensemble des composants en utilisant les dépôts de packages et le dépôt Git des projets, teste et met en place les sondes de monitoring. La plate-forme utilise Rackspace, mais elle est agnostique et prévue pour fonctionner en multi-cloud.
La solution s’appuie sur Chef, un outil de gestion de configuration, Capistrano, un outil de déploiement d’applications, Fog, une gem Ruby qui fourni une abstraction des API de Cloud, Jenkins, un serveur d’intégration continue. Les 3 premiers sont en Ruby, le dernier en Java.
- Jenkins gère l’intégration continue et permet aussi de lancer des commandes Capistrano sur l’environnement choisi (intégration, Production …).
- Chef n’est pas utilisé comme on s’y attend. Le déploiement est piloté via Capistrano et non Chef, soit par des commandes cap en ligne de commande, soit via l’intermédiaire d’un job freestyle dans Jenkins.
- Capistrano est utilisé pour sa fonction principale de déploiement applicatif. Il clone l’application depuis le dépôt github et redémare les composants. Mais Capistrano est aussi utilisé pour ses fonctions de parallel ssh, pour lancer les mêmes commandes sur plusieurs machines en même temps, et pour l’exécution de scripts externe via HTTPS, comme par exemple l’accès est interfaces de configuration des Cloud.
- Capistrano fait appel à Chef pour la gestion des configurations (installation et configuration des packages, paramétrage).
Chef est utilisé en mode chef-solo, il n’y a pas de serveur central et de client qui tourne en démon, Chef est simplement lancé en ligne de commande. Fasterize voulait un système qui reconstruise la machine à partir des packages plutôt qu’utiliser des images qu’il faut maintenir. Mais ils voulaient garder le contrôle sur le déclenchement des déploiements et des changements de configuration. En effet, Chef en mode démon peut redémarrer un process s’il voit sa configuration changer. Sur une architecture complexe, les composants ne sont pas toujours redémarrés dans le bon ordre alors que Capistrano utilise un processus impératif qui démarre les composants de l’application dans le bon ordre après la mise à jour de tous les composants.
Ce partage des responsabilités implique de partager les informations de configuration dans un système externe à l’un ou l’autre de ces outils. C’est ZooKeeper, un service de gestion de configuration centralisé, qui est utilisé pour conserver les informations de topologie réseau, les données de configuration des environnements et des applications, les rôles des machines, et les recettes Chef à appliquer pour chaque environnement. Il y a 3 instances, le minimum pour obtenir une redondance. ZooKeeper permet de consulter ces informations, mais aussi de s’abonner aux changement de configuration.
L’ensemble de l’outillage de déploiement est géré en configuration dans git, les recettes Chef, l’application à déployer, la configuration Jenkins (via un plugin). L’ensemble fait 3000 lignes de Ruby et quelques centaines de lignes de Perl et Shell.
Bertrand a fait plusieurs démos via Jenkins
Dans les deux premières démos, nous avons pu consulter la liste des noeuds et les versions d’OS et d’applicatif, puis mettre à jour un noeud, c’est à dire lancer Chef, aller chercher les recettes à jour sur Github, les appliquer, c’est à dire dans ce cas aller chercher les nouveaux packages via apt-get, les installer et finaliser la configuration. L’ensemble de la démo deux a pris 35s pour 15 noeuds en parallèle (mais sans changement à apporter)
A partir de la démo 3, on est rentré dans des processus un peu plus longs, déployer l’application Rails. Ce processus va chercher l’application sur Github, met à jour le code et applique les scrips d’upgrade comme db:migrate. Depuis la version 3.2 de Rails le processus est devenu plus long et l’instance micro peinait un peu aussi. La mise à jour a été arrêtée pour continuer la démo. Mais ça n’est pas grave, l’environnement est dans un état incomplet et sera remis en état lors du prochain lancement de la commande.
Le déploiement est fait en Production le plus rapidement possible après la disponibilité de la fonction et jusqu’à 3 ou 4 fois par jour. En production, les machines sont mises à jour avec un processus plus contrôlé. Les machines sont sorties du cluster une par une pour être mises à jour, le monitoring est désactivé car il tente lui aussi de modifier la configuration en réponse à ses alertes.
La démo 4, a créé un noeud sur Rackspace. Afin de limiter les paramètres à passer, l’outillage utilise le principe de convention over configuration, le nom de la machine indique son usage et donc le set de recette Chef à appliquer. Après obtention de la machine via les API Rackspace, le DNS local est reconfiguré, Chef prend le relais pour installer les packages système, les socles applicatifs, les sondes de monitoring (Monit) et le client de l’aggrégateur de logs (Splunk). Ici c’est un cache donc aucun applicatif n’est déployé. Il ne reste plus qu’à intégrer manuellement le noeud dans le cluster via une ligne de commande.
Ce processus est testé souvent car les machines de test sont reconstruites toutes les nuits afin de passer les tests de non-régression sur l’infrastructure et les tests fonctionnels, ainsi que les tests de performance.
L’ensemble du scripting et du développement des bindings entre outils est évalué à une quarantaine de jours/homme sur la durée du projet en plus de la mise en place des systèmes et de l’intégration par les équipes Fasterize.
Fasterize a construit une solution qui répond bien à ses besoins : une grande facilité d’adaptation de l’infrastructure, car il suffit de modifier quelques scripts et reconstruire, la gestion de l’élasticité est simplifiée, même si elle n’est pas automatique, car les opérations requises sont scriptées.
Les slides de la présentation et un article sur Chef de Bertrand.
[...] http://blog.valtech.fr/2012/06/11/paris-devops-9-cest-deploye/ Share this:ShareTwitterJ'aime ceci:J'aimeBe the first to like this. [...]