Comme chaque année, le Fosdem a réuni à Bruxelles des milliers de développeurs et autres geeks du monde entier partageant un intérêt commun pour la bière, les gaufres et bien sûr l’Open Source.

Fosdem2017

La première étape incontournable du Fosdem est le Friday Beer Event. Impossible de venir à Bruxelles sans déguster quelques boissons houblonnées locales !!
Le Delirium café est rapidement saturé mais il est facile de retrouver du monde dans les bars / restaurants attenants pour bien commencer le week-end.

 

Après un réveil parfois difficile, tout le monde se retrouve pour deux jours de conférences.

Le FOSDEM de Julien

Ce FOSDEM est l’occasion d’introduire une nouvelle track « Monitoring and Cloud ». Beaucoup de titres sont alléchants sur le papier avec comme sujets principaux Kubernetes et Prometheus.
Malheureusement, ces sujets sont très superficiellement abordés (quand ils le sont). Dommage, cette track a clairement du potentiel, espérons du contenu plus consistant pour l’année prochaine.

Alerting with Time Series

Après un rappel sur les time series, la présentation s’attarde sur les fonctionnalités d’alerting de Prometheus : Alertmanager.Prometheus
Les mécanismes de définition de règles sont assez complets:

  • seuils dynamiques (en fonction des dimensions utilisées) pour les erreurs et problèmes de latences
  • prédiction (linear regression) pour anticiper les problèmes matériels et faire du capacity planning
  • détection d’anomalies (holt winter & standard deviation)

Cependant les définitions sont manuelles et peuvent vite devenir complexes. Aussi, il vaut mieux savoir ce que l’on cherche.
Le système d’alerte dispose aussi de fonctionnalités intéressantes comme le groupement d’alertes en meta-alerte, la mise en sourdine des alertes suivantes en fonction d’une alerte initiale (évite d’avoir une cascade d’incidents) ou le self healing (possibilité de lancer des actions correctrices suite à la réception d’alerte).

Monitoring Kubernetes with OMD Labs Edition and Prometheus

Que faire quand on doit superviser un cluster Kubernetes et que les outils classiques ne sont pas une option ? On utilise Prometheus qui s’appuie notamment sur le service discovery Etcd. L’implementation est la suivante :

  • Intégration de l’API kubernetes pour récupérer les informations des conteneurs
  • Utilisation du node exporter pour les métriques des hôtes du cluster (Matériel et OS)
  • Kubernetes stat metrics pour l’état du cluster Kubernetes (noeuds, API, Pods, déploiements…)

La solution utilisé est OMD Labs, distribution qui embarque les outils classiques de supervision mais aussi Prometheus et Grafana.
L’architecture présentée est cependant un peu hasardeuse avec l’utilisation de federation Prometheus plutôt que d’utiliser les APIs externes Kubernetes.

 

Un autre sujet chaud lors de ce Fosdem : la cohabitation des VMs et des containers:

Pet-VMs and Containers united?

Ce talk est une réflexion sur les solutions à disposition pour faire cohabiter une infrastructure IAAS existante avec des containers.
Bien souvent, cette intégration est assez périlleuse et se résume à maintenir deux infrastructures séparées nécessitant un double travail opérationnel.
Des solutions existantes permettent de provisionner des clusters de containers (Kubernetes par exemple) dans des instances gérées par une solution IAAS.
Ce talk présente la solution Kubevirt (en développement) inversant le paradigme et permettant de lancer des VMs de la meme façon que des containers à l’intérieur d’un cluster Kubernetes.
L’approche peut être intéressante mais n’est clairement pas mature. A suivre.

Openstack Magnum at Cern

Magnum est le projet permettant de provisionner des instances, du réseau, du stockage et tout le nécessaire à la mise en place de clusters de conteneurs dans Openstack.
Comme souvent avec le CERN, la présentation est l’occasion de montrer chiffre à l’appui la scalabilité de la solution en production (depuis octobre 2016) et la mise à disposition des utilisateurs de leur cloud la possibilité de lancer des cluster Kubernetes, Swarm ou Mesos.
Si vous vous demandez si Magnum est utilisable en production, allez voir la vidéo ici.

 

Pour finir les conférences, un petit tour par la track sécurité.

How to audit, fix (and be merry) with OpenSCAP & Foreman

Cette présentation montre l’intégration de openscap, suite d’outils d’audit et de conformité sécurité : utilisation de puppet pour l’automatisation des corrections et de foreman pour l’orchestration et la génération des rapports de conformité.
L’approche est intéressante et peut valoir le coup pour assurer le maintien en condition de sécurité de vos instances dans le cloud.

Conclusion

Entre les nombreux échanges intéressants partagés sur le stand Openstack
et les personnes rencontrées durant ces deux jours,
c’est un vrai plaisir de participer à cet événement.

Le FOSDEM de Maxime

Entre les bières et la présence au stand OpenStack, j’ai réussi (avec parfois quelques difficultés) à assister à des présentations, principalement sur les tracks « HPC, BigData and Data Science », « Virtualization and IaaS », « Linux Container and microservices » et « Montoring and Cloud ».
Comme dans toute conférence, les présentations furent relativement inégales, tant en terme de durées (au FOSDEM cela dépend des tracks, ce qui ne facilite pas la mise en place du planning) que de qualité. Je ne m’attarderai donc qu’aux présentations qui m’ont paru les plus intéressantes (et non couvertes par mes compagnons de boisson et accessoirement collègues).

Track « HPC, Bigdata and Data Science »

C’était la deuxième édition de cette track au FOSDEM et beaucoup de gens se pressaient à l’entrée de la petite salle pour y assister. Il fallait s’armer de patience.
Les sessions étaient relativement courtes (20 min) ce qui ne permettait pas vraiment de rentrer dans les détails. Cependant, quelques informations furent bonnes à prendre:

Singularity

Un des challenges en HPC est de fournir à différents projets l’ensemble des outils qui leur sont nécessaires sur un cluster supposé extrèmement optimisé et homogène. Le conteneur, comme solution de distribution « all-incluse » d’application apparait comme une excellente solution
et une alternative crédible aux modules. Cependant, le maitre en la matière, Docker, n’est pas adapté à un environnement HPC. Une équipe du LBNL a donc décidé de créer son propre gestionnaire de conteneurs répondant aux exigences du monde HPC. Singularity permet donc d’exécuter
simplement un conteneur au nom de l’utilisateur, avec montage automatique d’un ensemble de volumes ($HOME, $SCRATCH, etc) et permettant l’utilisation native de composants HPC avancées (MPI, Infiniband, Cuda, OpenCL, Xeon Phi, etc). Pour simplifier la transition entre dev
et cluster HPC, il est possible d’utiliser des images docker (via un utilitaire d’import au format singularity).

BigPetStore

En programmation, il y a le « hello world », en bigdata/mapreduce/spark, il y a le « wordcount ». Celui-ci est d’ailleurs souvent utilisé pour vérifier le bon fonctionnement d’une plateforme mais n’est bien sûr pas du tout représentatif d’un vrai code distribuée. BigBench a donc été créé
pour permettre de valider et benchmarker une installation bigdata (hadoop, spark principalement) en se rapprochant d’une utilisation nominale.

Nifi

Une des problématiques dans les bigdata et IoT est de gérer correctement le flux de données. Nifi se pose comme un logstash sous stéroides (car scalable horizontalement), proposant de gérer des flux de transformation de données et de garder une trace des différentes transformations en
ajoutant un header à la sauce http aux données transitantes. Proposant une interfance visuelle, il se veut simple à utiliser, notamment pour une partie du monde scientifique allergique à la ligne de commande. A évaluer, minify, le petit frère, sorte d’agent de collecte embarquant des capacité
de transformation de la données et suffisament légér pour être embarqué sur des objets connectés.

Track « Linux container et microservices »

L’amphi était relativement grand mais il était quand même difficile de trouver une place assise, ce qui fait que j’ai pris peu de notes. Je n’ai vu que 3 ou 4 sessions mais 1 seule a vraiment retenu mon attention (car novice en la matière) :

Cgroupsv2 par Chris Down Ingenieur de production @ Facebook

Clairement l’un des meilleurs orateurs que j’ai vu sur cette édition du FOSDEM. Vu que je n’ai pas pu prendre de note, le lien vers sa présentation ici

 

Petite mention tout de même pour l’outil Sysdig, présenté lors de la session « troublesooting Kubernetes » : même si la présentation ne m’a pas particulièrement emballé, je trouve l’outil intéressant et je pense qu’il peut avoir une réelle utilité pour analyser et comprendre le comportement
de divers composants d’un hôte de conteneurs ou de VM.

Conclusion

Ce fut une bonne « première fois au FOSDEM » et son ambiance de barbus/geek. Je suivrai probablement les conseils d’un collègue pour le prochain (si jamais) en visant plutôt des tracks hors de mes domaines de compétences et ainsi vraiment découvrir de nouvelles choses.
De volgende (oui, c’est du néerlandais … mais google connait pas le flamand :-))

Le FOSDEM d’Alexis

Pour mon premier Fosdem, je me trouve un peu perdu tant le nombre de conférences est important. Mais après un bon café, je me mets à chercher la salle de ma première conf (It is F* huge).
Les conférences sont souvent intéressantes mais trop courtes donc les orateurs doivent faire de leur mieux pour faire concis et intéressant.

Hyper-converged, persistent storage for containers with GlusterFS

Bien que les « conteneurs » soient « stateless », certaines applications ont encore des exigences au niveau du stockage qui lui doit être persistant.
Dans cette conférence nous parlions de heketi; une API rest au dessus de Gluster qui permet de rendre l’administration plus simple et centralisée.
Grâce a heketi nous pouvons administrer le cycle de vie des volumes Gluster au niveau de Openstack Manila, Kubernetes et Openshift.
Nous allons gérer dynamiquement le provisionning des volumes Gluster sur nos applications.

Grafana – Past, present and future

  • Tous les tableaux de bord et sources de données sont liés à une Organisation (et non à un utilisateur). Les utilisateurs sont liés aux Organisations via un rôle (spectateur / editeur / Admin).
  • Template de dashboard
  • Echelle algorithmique (très utile lors du rendu de nombreuses séries de grandeur différente sur ​​le même graphique, tel que la latence, le trafic réseau, stockage, …)
  • Grafana contient son propre backend serveur (obligatoire). Ce dernier est écrit en Go et comprend une API HTTP complète.
  • Et enfin de l’alerting dans la dernière beta.

En soit pas grand chose de nouveaux mais le produit fournit de plus en plus de fonctionnalités.

Conclusion

Pour finir, j’ai passé un peu de temps sur le stand OpenStack, où j’ai pu rencontrer Rich Bowen (Apache Software fondation), animateur de la conférence « Write a Better FM
Read The F* Manual? Maybe you need to write a better f* manual » et contributeur actif de la documentation OpenStack.
Tout cela fut vraiment intéressant, et la bière y est bonne et pour le même prix que le café :O

On se retrouve l’année prochaine !