DevOps : Splunk et le « Déploiement Continu » des applications

Le 05 février 2015 s’est tenu à Paris La Défense l’évènement SplunkLive! organisé par l’éditeur Splunk. Cette société produit des logiciels pour le Big Data, de recherche et d’analyse de données, accessibles via une interface web.
Lors de cette journée j’ai pu assister à l’atelier Splunk pour le DevOps.

Avant de parler de DevOps, je tiens à crever l’abcès concernant le produit Splunk. En effet, dès que j’évoque le mot « Splunk » la première réaction qui m’est donnée est : « Splunk c’est cher ! ».
Disons que Splunk est soumis à licence en fonction du volume de données indexées. Malgré tout, Splunk est livré « Out of the box » avec des fonctionnalités et un support qui séduisent certains clients qui ne sont pas encore prêts à s’équiper d’une équipe de développeurs pour supporter des solutions Open Source ou bien qui ont essuyé des échecs avec ce dernier type de solution.

Ceci étant dit, parlons maintenant de DevOps avec Splunk, sachant que d’autres solutions de collecte/agrégation de données pourraient faire le même travail.

Devops est la concaténation des trois premières lettre du mot anglais « development » et de l’abréviation usuelle (ops) du mot anglais operations (exploitation). DevOps est un mouvement visant à réduire la friction organisationnelle entre les « devs » (chargés de faire évoluer le système d’information) et les « ops » (chargés d’exploiter les applications existantes). Ceci dans le but de travailler ensemble pour produire de la valeur pour l’entreprise.

Concernant les outils et les méthodes utilisés entre les équipes Dev et Ops retenons que :

‐ Un logiciel de Gestion des versions est nécessaire pour garder une trace des changements dans le code source du logiciel et dans la configuration des environnements

‐ On lui adjoindra un outil de suivi du changement pour apporter plus de visibilité au projet

‐ L’automatisation doit garantir que chaque changement est appliqué puis testé sur un environnement avant de passer au suivant (Configuration Unifiée)

‐ Une vraie stratégie de tests doit être mise en place pour couvrir autant de scénarios que possible. Documenter les tests les plus complexes peut s’avérer nécessaire

‐ Il faut pouvoir partager les résultats des tests de manière compréhensible au plus grand nombre

‐ Le déploiement continu peut être un objectif long terme que l’on atteint par étapes

equipe_agile

 Challenge organisationnel :

  • Faire du ≪ DevOps ≫ dans une organisation de taille moyenne ou grande nécessite beaucoup de lobbying et un investissement, comprendre une implication du décisionnel
  • Il faut instaurer de nouveaux processus et s’y tenir pour ne pas revenir en arrière (notamment en termes de communication entre les équipes)
  • Ce changement n’est pas le travail d’une seule personne. L’ingénieur ≪ DevOps ≫ (tel un prophète) n’existe a priori pas
  • C’est un changement qui peut se faire par étapes

 

La boite à outils :

Voici un aperçu d’outils présents sur le marché qui peuvent être utilisés entre les équipes Dev et Ops :

tools_box

 

Splunk vient s’interfacer avec toutes les catégories de solutions du tableau précédent pour collecter les logs, monitorer (ex : nombre de builds) et afficher sur une seule page Web un Dashboard qui synthétise en temps réel les tests d’intégration. Ce dashboard peut être partagé entre les équipes Dev et Ops.

Ci-dessous un exemple avec une application de calcul de risques :

exemple_application

 

Splunk va permettre de créer un dashboard pour suivre des métriques telles que :

– le nombre de BUILD exécutés dans Jetbrains TeamCity

– le nombre de BUILD du logiciel réussis et stockés dans Sonatype Nexus

– le nombre de déploiements réalisés avec Puppet (nombre de machines qui se sont connectées au Puppet Master pour récupérer leur configuration)

– le nombre de requêtes de calcul (front-end) dans le module Apache HTTPD

– le nombre de calculs effectués (back-end) dans le module Apache Tomcat

 

 

Voici un aperçu d’un reporting très synthétique associé :

exemple_reporting_appli

 

Le reporting peut également être plus détaillé :

reporting_01

 

reporting_02

 

Conclusion : Après le Continuous Developpment, le Continuous Integration et le Continuous Delivery, ce qui semble se dessiner comme prochaine étape c’est le Continuous Monitoring…

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *