Une nouvelle fois nous passons le week-end à Toulouse à l'occasion de Capitole du Libre., événement toulousain du libre à rayonnement national voire plus ! À l'image du FOSDEM, Capitole du Libre est un événement annuel organisé par une équipe de bénévoles efficaces. Comme le FOSDEM, cela se déroule sur un week-end, et comme le FOSDEM, on parle beaucoup plus de communauté et de logiciel libre, que de sujets corporate. En revanche, Capitole du Libre vise un public bien plus large que simplement des développeurs, on y trouve ainsi des conférences portant sur des sujets tels que la culture libre ou d'autres visant à initier des publics débutants sur certains sujets. Au-delà des conférences, Capitole du Libre c'est des ateliers, des tables rondes, des stands, et bien plus encore.

Cette année comme à l'habitude, beaucoup de contenu a été filmé et sera rapidement disponible, faites un tour sur le programme.

Nous revenons ici sur deux sujets abordés pendant ce week-end.

1001 façons d'installer Prometheus

par Mathieu CINQUIN, David SABATIÉ

https://2019.capitoledulibre.org/programme/#1001-facons-dinstaller-prometheus

La conférence ne dure que 30 min, on va donc à l'essentiel ! Néanmoins l'orateur démarre avec une présentation rapide de Prometheus, solution de monitoring centrée autour du concept de métriques, inspiré d'une solution de chez Google et aujourd'hui projet graduated de la Cloud Native Computing Foundation (CNCF).

Le cœur de la présentation porte sur les méthodes d'installation de Prometheus, et même s'il n'y en a pas réellement 1001, il y en a quelques unes. Elles sont présentées par catégories.

Dans un premier temps, on évoque les méthodes très classiques : compilation ou utilisation de binaires déjà compilés, et déploiement via un système de paquets et/ou éventuellement ou outil de gestion de configuration. Autrement dit on vise ici les infrastructures dites "pas hype", classiques ! On ajoute la possibilité d'encapsuler ça simplement un container Docker, éventuellement au travers de l'utilisation de docker-compose.

Ensuite est abordée la méthode de déploiement dite "de nos jours", c'est-à-dire dans un cluster Kubernetes :) Ici on trouve le déploiement via un fichier YAML classique pour Kubernetes, mais également l'utilisation du package manager Helm. Helm va générer lui même le YAML ensuite fourni à Kubernetes.

Enfin, la dernière méthode évoquée est celle qui permet d'intégrer Prometheus "nativement" au sein de Kubernetes, et ce au travers de l'utilisation d'un Operator et de Custom Resource Definitions (CRD). On trouve pour cela kube-prometheus ou le chart Helm prometheus-operator.

Bref, pas mal de possibilités, à choisir en fonction du contexte et du besoin.

Plateforme d'intégration continue élastique avec Gitlab CI

par Sébastien DINOT

https://2019.capitoledulibre.org/programme/#plateforme-dintegration-continue-elastique-avec-gi

Une conférence d'une trentaine de minutes plutôt sous la forme d'un retour d'expérience, dans laquelle l'intervenant a présenté une solution d'intégration continue, les bénéfices tirées et les coûts de mise en place.

Un petite présentation du contexte : la société développe et maintient Orfeo Toolbox, qui est un ensemble de bibliothèques et d’outils libres de traitement d’images pour la télédétection. Comme pour tout produit, ils ont besoin de le builder, le tester et tout ce qui va avec. Plutôt que de partir sur une approche traditionnelle, ils ont préféré opté pour un workflow d'intégration continue (ou CI), tout ce qu'il y a de plus moderne.

La solution présentée est une solution plutôt standard d'integration continue, basée donc sur Gitlab CI (L'intervenant a dit préférer Gitlab CI a Jenkins), Docker machine, la Registry Gitlab et avec comme provider le cloud Openstack d'OVHCloud.

L'idée est donc, à chaque commit, de lancer un pipeline de build, test, deploy (Ici le deploy correspond à la publication du package généré, et non a un deploiement) etc. Ce pipeline s'exécute sur des instances générées par Docker Machine sur le cloud Openstack d'OVHCloud. Une fois le pipeline exécuté, les instances sont détruites. Ainsi, les instances vivent uniquement lors de l'exécution du pipeline. Le but est donc d'économiser des ressources, qui sont, on le rappelle, coûteuses financierement puisqu'elles s'exécutent dans le cloud Openstack d'OVHCloud. L'intervenant a insisté sur la nécessité de cette économie étant donné que les besoins sont assez conséquents. On notera également une adaption du pipeline selon la branche dans laquelle le commit a lieu. On est donc dans un CI multibranche. On retrouve donc une solution de CI standard. Étant donnée la durée de la conférence, nous n'avons pas eu droit à une demo, même si on visualise assez aisément la solution.

L'intervenant a mis l'accent sur les gains apportés par la solution, notamment, l'amélioration de la qualité du code, ainsi que des méthodes de travail. On voit clairement que l'intervenant est satisfait du résultat et des bénéfices apportés par la solution (Son équipe est probablement satisfaite également). Il souligne aussi une certaine satisfaction vis-à-vis du cloud Openstack d'OVHCloud.

Néanmoins, il note certaines difficultés rencontrées, ainsi que des coûts de mise en place. Il a notamment insisté sur une mise en place plus complexe que prévu. Un exemple qu'il donne : La gestion des instances orphelines, qui sont des instances générées mais non connues par Docker Machine (suite a une erreur ou une autre). Ces machines ne sont donc pas détruites par Docker Machine a la fin du pipeline puisqu'elles lui sont inconnues. Pour palier à cela, ils ont écrit un script de purge des instances orphelines. Autre difficulté notable : Le contrôle de l'utilisation de la PIC (Plateforme d'Intégration Continue). En effet, les machines générées pour l'exécution du pipeline ont un coût financier. Et vu que le produit est Open Source, on imagine aisément que si la PIC était ouverte à n'importe quel contributeur, la facture pourrait être lourde ! Ils ont donc dû mettre en place un contrôle des droits sur la PIC, même si, il insiste sur le fait que l'équipe des mainteneurs n'est pas du tout fermée pour donner les droits à un contributeur qui le souhaite et qui en fait la demande.

En conclusion, nous avons donc une approche de CI standard et classique mais très répandue dans l'industrie actuelle. Cette demarche a pour but premier une amélioration notable de la qualité, impliquant tout de même un certain coût et une certaine complexité supplémentaire (loin d'être insurmontable cela dit). La création/destruction des instances sur lesquelles s'exécute le pipeline du CI rend la PIC très dynamique et permet de faire des économies non négligeables !