FOSDEM-2018

Le FOSDEM est un rendez-vous annuel incontournable pour tous les amoureux des logiciels libres et l’équipe d’Objectif Libre était encore une fois présente à Bruxelles début février, avec 10 consultants qui avaient fait le déplacement !

L’occasion pour eux de revenir sur les bancs de l’Université Libre de Bruxelles, et de vous faire le récit des faits marquants de cet événement.

Au programme : Cypher for Apache Spark, KVM on Hyper-V, Python 3, Cython, Prometheus, Diskimage-builder et un retour sur les tracks Conteneurs et Config Management.

Bonne lecture !

En savoir plus sur le FOSDEM

Beaucoup de monde

Premier élément marquant : la foule !

On croise de plus en plus de monde au FOSDEM. Conséquence : même avec la parfaite organisation des bénévoles (que nous remercions au passage), certaines sessions, comme les conférences Go dont les intervenants étaient de très haut niveau, étaient inaccessibles, avec des salles remplies plus de 30 minutes avant le début des conférences. Heureusement, le streaming en direct des conférences a bien fonctionné et a permis à ceux qui sont restés à la porte de suivre ces présentations.

Ci-dessous un résumé des conférences et tracks qui ont retenu notre attention.

 

Cypher for Apache Spark

Cypher est le langage de requête créé par Neo4J pour accéder à sa base de données de graphes.

En se basant sur OpenCypher, Neo4J a développé une version de Cypher au-dessus du format de dataset de Spark. Cela devrait faciliter les requêtes de données issues de graphes et/ou de données structurées classiques.

Un exemple d’application possible : permettre la corrélation d’un graphe social et une base d’achat de produits pour créer un moteur de recommandations.

 

KVM on Hyper-V

Lorsqu’on parle de nested virtualization, on imagine plutôt KVM on KVM. L’idée d’utiliser KVM on Hyper-V peut sembler bizarre, mais c’est un cas qui peut être imposé dans des cas de contraintes fortes, en particulier l’exécution de workloads dans un cloud Azure (privé ou pulic).

Les usages sont multiples : Secure Containers (Intel Clear Containers), tests, virtualisation de processus (avec du OpenStack au-dessus par exemple). Cette fonctionnalité est rendue possible depuis 2016 avec pour cible Hyper-V on Hyper-V, mais elle peut être détournée.

La majeure partie de la conférence a consisté en une (longue) présentation de la théorie de la virtualisation et nested virtualisation. Quelques exemples de micro-benchmarking (très bas niveau d’utilisation du noyau) ou macro-benchmark (plus haut niveau comme utilisation réseau) ont ensuite été présentés, avec chaque fois la présentation de solutions d’optimisation de KVM on Hyper-V et avec quelques résultats bluffants : gain de x20 en performances par exemple sur l’utilisation de l’horloge matérielle.

 

Python 3: 10 years later

Voici une bonne conférence tour d’horizon, qui est revenue sur l’évolution de Python depuis sa première version, en mettant en lumière quelques fonctionnalités clefs ou qui ont posé problème. Les problèmes et débats autour de la communauté ont également été abordés.

Quelques points notables :

  • Python2 est encore trop utilisé mais doit être abandonné : la fin du support officiel de Python2 est prévue en 2020
  • Python3 est aujourd’hui très utilisé. Pour autant, la plupart des apports de Python3 par rapport à sa version précédente ne sont pas exploités, à cause des algorithmes écrits avec la rétrocompatibilité comme objectif.
  • Un core dev de Python avait créé le « Wall of Shame » (site affichant les paquets non portés sur python3). Ce site est par la suite devenu le « Wall of Superpowers » lorsque Python3 s’est bien répandu.
  • Malgré la maintenance, certains bugs ne seront jamais corrigés sur Python2 en raison de design du langage : une bonne raison pour passer à Python3 !
  • Il n’y aura pas de version Python2.8 : une telle évolution est jugée anti-Python3 et il est préférable de pousser à l’évolution vers Python3

Enfin, quelques retours d’expériences sur la puissance de Python3 : chez Instagram, le portage en Python3 a permis une réduction de 12% de charge CPU (uwsgi/django) et 30% de RAM (celery).

Lift you speed limits with Cython

Une conférence passionnante sur la manière de porter du code Python vers Cython, étape par étape, avec une démonstration progressive de l’augmentation des performances selon les modifications.

Pour résumer, il ne suffit pas de changer d’interpréteur pour avoir du code Cython optimisé : il faut également appeler des fonctions C dans du code Python, typer ses variables, définir des fonctions comportant des instructions C, etc.

Passer à Cython ne rend pas le code rapide par magie. L’utilisation de librairies spécifiques, comme pandas, augmente les performances de manière drastique pour le cas de structures de données lourdes à manipuler.

 

Evolving Prometheus for the Cloud Native World

Cette présentation passait en revue l’évolution de Promotheus (P8s).

P8s répond au besoin de monitorer différemment, ce qui est nécessaire puisqu’aujourd’hui nous développons différemment, en particulier avec l’apparition et la généralisation du cloud et des applications pensées nativement pour le cloud. On observe une augmentation des besoins en monitoring des machines virtuelles et une adaptation à un cycle de vie des VMs, plus court dans le cloud.

Les questions soulevées étaient vraiment intéressantes, en particulier :

  • Quelles sont les futures fonctionnalités pour Prometheus, hors améliorations de performances ?
    • P8s est aujourd’hui un produit mûr. Aucune nouvelle fonctionnalité n’est attendue !
  • Étant donné que le design de Prometheus ne permet pas le passage à l’échelle de l’application, comment gérer le cas où le node sur lequel P8s tourne tombe ?
    • Il n’y a pas de solution magique, à par lancer (« spawn ») une autre instance P8s ailleurs. Le sockage externe et persistant est également très utile. Enfin, il est important de diviser les traitements (par exemple par type) en utilisant plusieurs serveurs P8s autonomes.

 

Diskimage-builder: Building Linux Images for Cloud

Le projet (écrit en Python) est maintenu par la communauté OpenStack et permet de construire des images cloud. Si vous souhaitez faire une image très simple (comme celles que l’on peut créer avec debootstrap ou similaires), le projet peut être intéressant.

Ils semblerait cependant que ce soit sa principale utilité. Nous restons donc sur nos positions et préférons utiliser Packer, qui est bien plus réactif/dynamique, mais aussi plus puissant.

Track Conteneurs

Cet ensemble de conférences ne parlait pas uniquement de Docker (pour une fois) mais traitait bien du large écosystème des conteneurs : Docker, containerd, rkt, LXC/LXD…

Sécurité des conteneurs

Le point le plus marquant de la track est la place primordiale accordée aux questions de sécurité dans les conteneurs. Plus de la moitié des conférences traitait de la sécurité, directement ou indirectement, avec notamment une conférence sur le projet Atomic Host et son utilisation pour avoir un poste de travail à base de conteneurs.

NB : si vous êtes des lecteurs assidus de notre blog, ou un participant régulier à nos webinaires, vous savez déjà que cette thématique est au cœur de des activités d’Objectif Libre. Sinon, nous vous invitons par exemple à voir/revoir le webinaire dédié à ce sujet et à découvrir les articles en rapport avec ce sujet.

Migration des conteneurs

Quelques conférences ont abordé la question de l’amélioration de la migration de conteneurs, en se basant sur CRIU (Checkpoint/Restore in Userspace), avec des ajouts d’étapes pré et/ou post copy pour permettre de faire des migrations en minimisant les perturbations des applicatifs. Notons que c’est la solution qui existe depuis plusieurs années sur LXC et OpenVZ.

Exploring container image distribution with casync

Nous avons particulièrement apprécié cette conférence à propos de casync : un logiciel permettant de calculer le différentiel entre 2 fichiers (répertoire, image docker, block device, tarball, whatever) – les 2 fichiers pouvant être un fichier local et un fichier sur une plateforme distante (Docker Hub par example) – et de télécharger uniquement les différences.

Une démonstration a été faite, avec des tarballs puis des images docker du docker hub. Le but est de télécharger uniquement les couches qui comportent des différences pour le rebuild. Un certain nombre de graphes prouvent que les ressources réseaux sont soulagées, surtout lorsque les fichiers comportent beaucoup de différences. En revanche, étant donnés les appels préalables qu’ils doivent effectuer pour calculer les différences, on perd un peu de temps et de bande passante lorsque tout le fichier est à re-télécharger. Ce logiciel évolue rapidement et son développement est actif.

Track Config Management

Encore une track dédiée pour un sujet vaste et dont plusieurs conférences ont retenu notre attention.

La première portait sur l’utilisation ou non du provisionning, du config management et de l’orchestration. La réponse est d’utiliser les 3, chacun apportant des fonctionnalités qui répondent à des besoins de chaque partie lors de la mise en place d’une plateforme :

  • Provisionning pour l’installation de la plateforme
  • Config Management pour le run de la plateforme
  • Orchestration pour les VMs et les instances

Une conférence était une présentation de Augeas : outil utilisé très souvent dans Puppet et qui permet de faire des modifications dans les fichiers de configuration facilement, en unifiant leur représentation sous une forme d’arborescence. Cette conférence présentait aussi une nouvelle commande « augmatch » qui permet de mieux visualiser l’arborescence des fichiers de configuration.

Le sujet autour de la mise en place de Foreman et Puppet en Haute Disponibilité a bien mis en avant la contrainte de gestion des certificats et de l’autorité de certifications de Puppet. C’est un sujet que nous connaissons bien puisque nous avons déjà réalisé ces actions à plusieurs reprises pour certains de nos clients.

Enfin, la dernière conférence sur laquelle nous reviendrons traitait de la maturité de Terraform. Cette conférence était intéressante car l’honnêteté était de mise, avec le passage en revue des points un peu décevants de terraform, et pour chacun la visibilité donnée aux modifications apportées dans la nouvelle version.

 

Pour conclure

Beaucoup de monde, mais des sujets toujours aussi passionnants. A l’année prochaine !