Le Breizhcamp 2017

“BreihzCamp”, mais qu’est-ce donc ?

Un camp d’entrainement Breton ? Presque ! Le BreizhCamp, c’est 3 jours de conférences et de “hacker-space” au sein des locaux de l’Université de Rennes. Il a été créé en 2011 à l’initiative du BreizhJUG. Et depuis, cette conférence ne cesse de prendre de l’ampleur, de se forger une identité propre et de s’imposer petit à petit comme un événement phare pour les développeurs en Bretagne France.

La 7ème édition a eu lieu du 19 au 21 avril 2017 (en même temps que MiXiT, et ça c’est pas cool !). A l’image d’autres conférences, le programme est scindé en deux parties : Une première journée “d’université” et deux autres jours de conférences. L’université est un format de conférence plus long (2h par session) qui prend le temps d’entrer plus avant dans les détails.

Les journées de conférences sont quant à elles plus classiques avec un format de 45 minutes par conférence (plus 10 minutes pour les questions). Pour ma part je me suis inscrit à ces 2 jours de conférences pour la somme extravagante de 75€. Autant prévenir, on en a bien plus que pour son argent.

Les conférences se déroulent sur 4 tracks en parallèle sur une thématique variée qualifiée de “Mix de technologies” : Objets connectés, IoT, Robotique, Architecture, Cloud, DevOps, Java, Agilité, BigData, Web, …

TL;DR

Pour moi le BreihzCamp a été l’occasion :

• D’assister à une conférence en breton français
• De manger des galettes saucisses (c’est très bon)
• De boire de la bière sans alcool (c’est pas bon)
• De discuter avec des sponsors “locaux”
• De retrouver des amis et de faire des rencontres
• D’apprendre deux trois trucs… (beaucoup en fait)

Et tout ceci dans la joie et la bonne humeur !

Une Conférence pure à 99,1%

Car c’est bien une spécificité du BreizhCamp : la bonne humeur. La faute sans doute au caractère des Bretons ou au côté “loof-oque” du maître de cérémonie (Nicolas De Loof). Cette conférence met l’accent sur la convivialité et la bonne humeur. Le décor est posé avec le choix du thème de cette édition : Breaking Bad.

Ce thème n’est pas qu’un prétexte, il s’invite partout dans la conférence. Du t-shirt, aux keynotes et jusque dans les stands qui ont rivalisé d’ingéniosité pour y coller. C’est un des petits plus qui fait que l’on se sent bien au BreihzCamp.

C’est également une conférence à taille humaine. Environ 600 participants. Ce n’est pas intimiste mais cela reste agréable et permet de profiter des stands, de ne pas faire une queue folle au moment des repas (qui sont très biens soit dit en passant), de ne pas se retrouver dans des salles saturées ou de ne pas avoir le sentiment de participer à la transhumance du développeur entre chaque conf (mais sinon le Devoxx c’est bien aussi ;).

Voilà pour la présentation du décor. Place maintenant à la technique. Dans la suite de ce billet je vais essayer de vous synthétiser mon programme de conférence. Ceci ne donne bien sûr qu’une vue personnelle du contenu de la conférence mais avec “seulement” 4 tracks en parallèle on n’a pas le sentiment de passer à coté de trop de choses. On a même l’occasion de se rattraper car une grande partie des conférences ont été filmées et postées sur Youtube :

TL;DR : Chaque paragraphe est indépendant et peut se lire (ou pas) dans le désordre. Il s’agit d’une synthèse unitaire des conférences qui m’ont le plus intéressé.

Premier jour

Les problèmes que l’on rencontre en microservices : configuration, authentification et autre joyeusetés

Par Quentin ADAM de Clever Cloud

Premier problème adressé : le réseau. Il n’y a pas de réseau de confiance. Ni d’un point de vue sécurité ni d’un point de vue résilience. SSL et authentification sont des prérequis même entre des services non exposés. Ceci semble abusif quand on s’estime en sécurité au sein d’une DMZ, mais l’argument se défend bien mieux dans les architectures microservices. Le réseau est généralement à plat ; une faille sur un service peut mettre en péril les autres ; un microservice peut être exposé ou déplacé sur une autre infrastructure ; auditer en détail les accès permet d’identifier des éventuelles fuites ; etc.

The network will fail

La résilience à la panne est un des piliers des architectures microservices. Il faut pouvoir gérer les pannes de communications entre les services et pour ça il faut tester ces pannes.

Quentin met également en garde contre le découpage abusif des services et des “armées bruyantes de microservices”. Outre la complexité induite il y a un coût non négligeable au niveau des communications réseau (et donc des performances). Il rappelle que les infrastructures microservices ne sont en rien une une réponse aux problèmes de répartition de charge.

Pour la communication inter microservices, il conseille l’usage des brokers de messages et l’évènementiel au détriment des accès directs de type HTTP ou RPC. Le découplage étant un autre de ces piliers.

Autre problème évoqué : la configuration. Pour lui la configuration est portée par l’environnement et un changement de configuration revient à supprimer et recréer une instance (selon les principes de l’Immutable Infrastructure).

L’authentification. Elle doit être distribuée et robuste. Les solutions techniques évoquées sont JWT et un projet qui a suscité mon intérêt : Macaroons. Un système de gestion des autorisations dans un système distribué. Voici un bon article d’introduction : Macaroons are Better ThanCookies!

Enfin différentes bonnes pratiques évoquées pêle-mêle :

• Le nettoyage du code legacy de façon régulière.
• Le code est quelque chose qui vit.
• Il ne faut pas tomber dans le dogmatisme sous n’importe quelle forme.
• Enfin il faut cultiver le bonheur au travail. Un développeur heureux fera du meilleur code.

Les infrastructures auto-adaptives

Par Sylvain REVEREAULT de Zenika

L’idée est d’outiller l’infrastructure pour être capable de s’adapter aux pannes, à la charge et aux malveillances.

En préambule Sylvain présente la notion de SD* : “Software Defined n’importe quoi”. Le fait d’apporter une abstraction logicielle à des problématiques matérielles. Un focus est fait sur le Software-Defined Networking (ou SDN) avec le protocole OpenFlow.

L’auto-adaptation aux pannes

Elle peut se faire via l’utilisation des orchestrateurs d’infrastructure (Mesos, K8S, Swarmkit, Nomad, …). Chacun de ces orchestrateurs vient avec des outils qui permettent de jouer sur l’élasticité de l’infrastructure en fonction de la charge mais également en fonction des pannes.

Sylvain présente également le protocole RAFT qui permet à une application de gérer une clusterisation de ses services. A noter qu’il y a une très bonne explication du protocole et notamment un simulateur interactif à cette adresse : https://raft.github.io/

Il insiste évidemment sur le fait que cette auto-adaptation doit être lourdement testée, notamment en production. Il fait référence au Chaos Engineering de Netflix.

L’auto-adaptation à la charge

On reparle des orchestrateurs mais plus précisément des architectures d’Amazon avec ELB et CloudWatch.

Pour un usage plus “on premise” Sylvain fait l’article d’une solution développée par Zenika: ZenScaler. Un démon utilisant les métriques de Docker pour effectuer de l’auto-scaling avec les containers. Une démo est effectuée avec Apache Benchmark pour simuler la charge.

L’auto-adaptation à la malveillance

L’idée est de se protéger des script-kiddies, des scans de port, etc. C’est ici que revient sur scène le SDN via l’utilisation des contrôleurs SDN pour identifier des patterns d’attaque sur le réseau. Il fait une démonstration avec la distribution Mininet.

La démonstration consiste à détecter les requêtes ARP à l’aide de Redis et Pox.

D’un point de vu plus production, il fait référence à Defense4All.

Containers et configuration : de la promesse au concret avec git et confd

Par Christophe Furmaniak de Zenika

L’occasion de retrouver un ancien collègue :)

Christophe s’attarde dans un premier temps à faire le point sur les types de configuration. La configuration c’est bien sûr des fichiers textes (properties, yaml, etc.) mais également des fichiers binaires (certificats, images, etc.) et des secrets (mot de passe BDD, API keys, etc.).

Un point important que Christophe soulève est que la configuration doit être versionnée, à l’instar du code. Ceci afin de visualiser les évolutions, identifier les changements, pouvoir effectuer des rollbacks et tout simplement être capable de dire précisément quelle configuration est actuellement appliquée.

Ensuite Christophe passe en revue les différents scénarios de configuration des containers :

• L’image All In One. Autrement dit l’image qui embarque le runtime et la configuration. C’est clairement une mauvaise pratique car on se retrouve avec des livrables différents en fonction de l’environnement. Le livrable devrait être iso quel que soit la cible et son comportement devrait uniquement changer via des stimuli extérieurs.

• Les variables d’environnements. Sans doute l’approche la plus classique pour Docker, mais quid des secrets et des fichiers de configuration binaires ?

• La configuration sur le host. C’est également une pratique courante. Souvent mixée avec la précédente pour les configurations clés/valeurs. C’est pourtant un choix que remet en question Christophe. Premièrement car utiliser un outil de gestion de configuration pour altérer le host peut être contraint (en terme d’accès et de sécurité) et que pour lui ce n’est pas compatible avec une approche Container as a Service (CaaS). Dans un CaaS on ne peut pas interagir avec le host.

• La configuration gérée par l’orchestrateur. Il prend l’exemple des ConfigMap de Kubernetes. C’est sans aucun doute très puissant mais Christophe avance le fait que nous devenons dépendants de la solution de hosting. On devient vendor locked (bon c’est déjà le cas avec Docker ;).

• Le service de configuration (Consul, Etcd, Archaius, …). C’est évidemment une très bonne approche mais qui se révèle intrusive pour le code. C’est l’application qui prend conscience qu’elle interagit avec un service externe de configuration. Bien sûr des frameworks tel que Spring Boot apportent un haut niveau d’abstraction et sont capables de configurer l’application de façon locale ou distante très simplement. Mais toutes les applications ne sont pas faites avec Spring Boot ou un équivalent. Christophe conseille cette façon de faire si on a la chance de ne pas traiter du code legacy dépourvu de ce type de facilitateur.

• Enfin la solution que Christophe qualifie de moins mauvaise : le data container. Le fait de déployer au côté du container de runtime un container embarquant la configuration. De son point de vue, c’est reproductible quelle que soit la solution de hosting et cela reste relativement simple.

Le reste de la présentation est une mise en pratique de ce dernier scénario en utilisant Rancher, GIT et Confd.

L’exemple est disponible sur son GitHub : https://github.com/looztra/guestbook-api-server

Vue.js, même un dev Java peut en faire !

Par Bruno Bonnin

Voilà un titre qui a piqué ma curiosité tellement je n’y adhère pas. J’ai de plus en plus tendance à penser que le métier de développeur se spécialise et que le développeur full stack devient, avec le temps et la complexité galopante, une licorne.

Mais ce n’est pas l’objet de la conférence et encore moins de ce billet. C’est donc une introduction à Vue.js et la preuve par l’exemple de la simplicité du Framework (comparé notamment au mastodonte qu’est Angular).

Vue.js c’est donc un framework Web, orienté composant, flexible, performant, focus sur la couche view et très facile à apprendre.

Ce qui est sans doute moins vrai (de mon point de vue) pour un développeur Java c’est le reste : le langage JavaScript, l’écosystème, l’asynchrone, la gestion des états, le css, l’offline, etc. Arf, je recommence à digresser ;)

C’est donc une très bonne introduction de Vue.js faite par un développeur convaincu. On peut retrouver les slides ce cette présentation ici : https://github.com/bbonnin/breizhcamp2017-vuejs

Les stars du X : VertX, RX, HystriX : La seule conférence PEGI 18

Par Gabriel Magniez des PagesJaunes

C’est au tour des PageJaunes de faire un REX sur l’utilisation des solutions interdites aux mineurs débutants que sont VertX, RX et Hystrix. Gabriel commence d’abord par présenter la stack technique des PagesJaunes :

• Varnish  : Un serveur de cache très populaire notamment dans le monde PHP.

• Nginx : Le serveur http qu’on ne présente plus.

• Node : Ici Node semble être utilisé pour certaines API et l’usage des WebSocket.

• PHP : Tout le métier des pages Jaunes est fait en PHP. Certainement pour des raisons historiques. Mais PagesJaunes ne semble pas une seconde souffrir de ce legacy.

• MongoDB : La plus connue des base de donnée documentaires. Ce qui pour le coup fait moins legacy.

• Redis : L’usage premier qui est fait de Redis semble être le cache au niveau backend (PHP).

• Et enfin Pertimm : Le plus étonant, c’est l’usage d’un moteur de recherche e-Commerce en mode SaaS.

Le site des PagesJaunes est avant tout un service de consultation de données. C’est pourquoi le cache prend une importance considérable au sein de l’architecture. Varnish remplit à merveille cette fonction. Mais la problématique pour les PagesJaunes c’est qu’ils expérimentent certaines de leurs fonctionnalités via le Feature Flipping (FF), méthode qui consiste à activer ou non des fonctionnalités en fonction d’une segmentation des utilisateurs. Et c’est ici que ça se corse car le FF et le cache ne se marient pas forcément bien.

La présentation consiste à expliquer la solution retenue. Après quelques itérations, ils ont implémenté un proxy entre le NGINX et Varnish pour calculer la clé de cache en prenant en compte la segmentation des utilisateurs nécessaire au FF.

La suite est une présentation rapide de chacune des briques en X :

• VertX : un framework pour construire des applications réactive sur la JVM. La contrainte de ce proxy est de pouvoir monter en charge et gérer un nombre considérable de requêtes. De par l’usage d’un event loop, VertX est, à l’instar de Node, capable d’avoir un traitement asynchrone des requêtes entrantes et de ne pas monopoliser de threads dormants. Là ou un serveur Java traditionnel avec un pool de threads échouerait.

• RXJava : Les extensions réactives pour la JVM. L’idée est de pousser le paradigme asynchrone à des traitements métier en utilisant le pattern reactive.

• Hystrix : Latency and Fault Tolerance for Distributed Systems. Ici il s’agit de protéger l’utilisateur via l’emploi du Circuit Breaker de Netflix. Si le “microservice” de calcul de clé de cache est indisponible alors l’utilisateur obtiendra une clé de cache pré-calculée pour obtenir un cache plus générique mais fonctionnel.

Deuxième jour

Retour sur les panama papers et les bases de donnés graphe

Par Benoit Simard

L’occasion de refaire un point sur la plus grande “fuite” de l’histoire avec plus de 3To de données non structurée !

Ici la présentation consiste à présenter les technologies qui ont permis à l’ICIJ (International Consortium Of Investigate Journalists) de remonter le labyrinthe de relations douteuses : sources

La stack technologique utilisée :

• Apache Tika : Un outil très connu capable d’extraire des données textuelles et les métas données d’un nombre important de formats différents (PDF, PPT, Images, Etc.). L’OCR-isation d’un document étant une opération longue et coûteuse celle-ci a été distribuée sur AWS pour l’accélérer.

• Apache Solr : Une plateforme d’indexation construite sur Apache Lucene (Comparable à Elasticsearch). La masse de documents est indexée par Solr. Il s’agit ensuite d’explorer ces documents. Et pour cela il est fait usage de Blacklight : Une interface graphique open source (développée en RoR) pour explorer les index de Solr. Cette interface permet également de travailler de façon collaborative sur une base Solr.

• Neo4j : La base de données graphe hautement scalable. C’est la star des Panama Papers. La base qui consiste à modéliser des graphes composés de nœuds et de relations (ces 2 éléments pouvant porter des attributs). La force de Neo4j est sa capacité à stocker physiquement ces relations et donc de pouvoir les parcourir extrêmement rapidement (là ou un moteur SGBDR traditionnel construit ces relations à chaque requêtes de jointure). Neo4J dispose d’un langage de requêtage particulièrement puissant : Cypher Query Language. A noter que Neo4J est également capable d’effectuer des requêtes géographiques. Si l’envie vous prend de tester ce moteur il existe une sandbox qui permet de jouer avec entre autres un dataset des Panama Papers : https://neo4j.com/sandbox-v2/

• Enfin la visualisation et l’analyse des relations est confiées à un service non open source : Linkurious

Ingest node : (ré)indexer et enrichir des documents dans Elasticsearch

Par David Pilato d’Elastic

David commence par une revue très courte de la suite Elastic qui propose une offre logicielle riche autour de son moteur phare : ElasticSearch.

Il bascule ensuite sur la présentation d’une fonctionnalité majeure introduite dans ES 5 : L’Ingest Node. C’est un nouveau type de nœud capable de réaliser des opérations d’ingestion, de transformation et d’indexation de données. On pense tout de suite à Logstash et Ingest Node peut s’avérer, dans certains cas un parfait remplaçant.

Ingest node introduit certains concepts :

• Les pipelines : Le pipeline est la définition d’une succession de processeurs. Cette définition est faite via l’API.

• Les processeurs : Il existe tout un panel de processeurs capable d’être chaînés dans le pipeline d’ingestion : Grok, mutate, date, GeoIP, etc. Il est également possible de créer en Java son propre processeur et de l’intégrer au pipeline. C’est l’objet de la démonstration.

La gestion des erreurs est bien faite et permet une granularité niveau pipeline ou niveau processeur.

David effectue une démonstration d’un pipeline d’enrichissement des donnés d’un index existant. La démonstration consiste à réindexer un dataset contenant des adresses IP. Ces adresses IP sont d’abord géolocalisées via le processeur standard GeoIP. Puis un second processeur custom utilise ces coordonnées GPS pour géocoder les adresses IP. Pour ce faire, le processeur utilise BANO (Base Adresse Nationale d’OSM).

La démonstration est faite en livecoding via l’utilisation des dev tools de Kibana et l’usage de l’API simulate (simuler l’application de pipeline à des données de test).

David promet une mise à disposition de sa démonstration sur son Github : https://github.com/dadoonet

Introduction à Unikernel

Par Tomas Rodriguez et Jean-Baptiste Claramonte

La conférence commence par expliquer que le Kernel Linux c’est 22 million de lignes de code. C’est énorme ! On conçoit sans mal l’impact sur les performances, la surface d’attaque et la probabilité de bug.

L’idée des Unikernel est de disposer d’un OS sur mesure :

• Un noyau minimaliste et simplifié.
• Uniquement des librairies utiles à l’exécution du processus.
• et … le processus.

On supprime également l’user space et on garde uniquement le kernel space pour des gains de performance (relative au accès IO). Enfin on supprime le multi process ! Rien que ça.

Les implémentations sont nombreuses. On distingue 2 approches. Les unikernels dédiés à un langage (runtime.js, HaLVM, …) et les “généralistes”: Unik, Rumprun, Osv, …

Thomas et Jean-Baptiste parlent de leur REX sur Unik et OSv. Unik est un échec. Trop compliqué, mauvaise documentation, instable… OSv semble plus abouti.

Une démonstration est faite avec VirtualBox, OSv et Capstan (une CLI pour OSv).

Alors un remplacent à Docker ? Sans doute, mais pas pour tout de suite car selon eux la “peinture n’est pas fraiche”.

Ici le commandant de bord, on passe en mode avion !

Par Olivier Leplus et Wassim Chegham

On commence par une brève introduction aux Progressive Web Apps (PWA). Ce concept introduit par Google fait le constat que les App mobiles sont délaissés au profit des sites webs et que ces dernier doivent s’adapter pour prendre à bras le corps les problématiques du mobile : l’UX, l’Offline et les notifications.

L’essentiel de la conférence est un live coding en binôme sur une application de prise de photo. Cette application est “progressivement” améliorée pour gérer l’offline.

Le live conding présente l’usage d’IndexDb (via la librairie IDB) pour stocker des données en local. Et l’usage des Service Workers pour gérer le offline et la synchronisation avec le backend une fois le réseau présent.

Il est fait mention de PouchDB : Une implémentation JS de CouchDB capable de se synchroniser avec une BDD distante implémentant le protocole de synchronisation de CouchDB (comme Couchbase par exemple). A noter qu’il est également fréquent d’utiliser PouchDB pour faciliter l’usage d’une BDD locale sans avoir besoin de synchronisation distante.

Remember my name

Et voilà ce qui clôture mon premier BreihzCamp. Il y a encore beaucoup à dire. Je fais l’impasse sur :

• les quickies et sur les keynotes de très bonne qualité. Mention spéciale à celle d’@antoninlemee sur les logiciels qui pourrissent la vie des gens qui ne “rentrent pas dans les cases”. Egalement une keynote animée par CommitStrip extrêmement drôle sur une parodie de qui veut gagner des millions transposé à la progression de carrière des développeurs.

• Des discussions passionnantes sur les stands notamment avec l’équipe d’OVH qui m’a bien boosté sur l’étude de Wrap10. Une Geo Time Series Database capable de traiter les flux de donnés avec un langage de scripting dynamique est très puissant : WarpScript.

• Les rencontres en tout genre : Les Code Troopers, les Code Lutin, l’auteur d’Hubpress (un très bon générateur de site static utilisant GitHub comme backend ), etc.

Et tout ceci encore une fois dans la bonne humeur autour d’une crêpe au sucre.

Que dire de plus si ce n’est vivement l’année prochaine !