Il y a quelques semaines, j’ai eu la chance d’assister au DevFest Lille, organisé par le GDG Lille.

Mon impression globale : une très bonne organisation, des locaux sympa (merci l’IMT Lille-Douai), des talks intéréssant et beaucoup de bonne humeur!

Voici un petit retour sur les talks auxquels j’ai assistés :

gRPC, communiquons autrement (Sébastien FRIESS)

Après un rappel sur ce qu’est le réseau et internet, Sébastien nous a dressé la problématique du format de donnée dans les systèmes distribués et de la dificulté de la modification de ce format quand on a plusieurs producers/consommateurs d’une donnée.

Il nous as fait un historique des protocoles d’échange de données de type Remote Procedure Call – RCP : CORBA, RMI, EJB, SOAP, REST, … Pour arriver sur Protocol Buffers de Google (2008, open source partiel, prémice de gRPC) et puis gRPC en 2015, qui est basé sur Protocol Buffers mais 100% open source.

gRPC est un système de RPC avec Protocol Buffers comme sérialization et basé sur des Interface Description Language (IDL : définiton des méthodes et des messages) et incubé depuis peu dans la Cloud Native Computing Foundation

Voici ses principales fonctionalités présentées :

• Les attributs des messages sont numérotés et typés dans les IDL pour pouvoir évoluer facilement
• Serialization Protocole Buffers par défaut mais d’autre supporté (protocole buffer : taille divisé par deux par rapport à JSON)
• Transport binaire donc compact et performant
• HTTP/2, 10 languages supportés, …
• Plugin : log, authentification, resilience (retry, timeout, …), …
• Streaming bi-directionel : stream de request (client -> server) ou de response (server -> client) de manière performant. Existance d’un EOL pour définir la fin de la stream.
• Sécurisé par défaut (TLS)
• Existe un plugin gRPC <> REST pour appel externe

La fin de la session a donnée lieu à une petite démo avec entre autre la modification d’un service sans modification du client pour montrer le méchanisme de monté de version possible via les IDL.

Métrologie et Alerting avec Prometheus et Grafana (Christophe Furmaniak & Yoan Rousseau)

Après être revenu sur ce qu’est le monitoring et les différents types de monitoring existant, les speakers nous ont présenté Prometheus, un système de collecte de métrique, inventé par Soundcloud et intégré dans la Cloud Native Computing Foundation

Les caractéristiques de Prometheus sont les suivantes :

• Un unique binaire (GO)
• Stockage local (pas de cluster). Si on veut de la haute dispo on en démarre deux …
• Multi-dimensional Time Series avec tag possible sur les métriques
• Requêtage via PromQL : requêtage basic via nom_metrique, nom_mertrique{tags}, operation possible (sum, rate, …), request, opérateur logique, offset (dans le passé), [periode], …
• Système sans agent : Prometheus va chercher les métriques sur les serveurs (mode pull) via des exporter (jmx par ex). C’est le point fort de Prometheus pas d’adhérence à celui-ci dans vos applications (ni sur les serveurs les hébergeant).
• Existe une Push Gateway pour pouvoir pousser des métriques vers Prometheus (ex via un batch ou un script)
• Capacité de Service Discovery (NDS, consul, docker, …) pour configuration automatique
• Stock des métriques de type compteur, gauge, histogramme, summary (histogramme avec percentille), …
• WebUI qui permet de tester ses requêtes
• Pour le dashboarding : Grafana! (existe des dashbord fournit par la communauté)
• Alerting : génère des alerte depuis des règles sur des requêtes. Vecteur d’alerte : mail, slack, …

Un focus a été fait sur le Push vs Pull :

• en push les applications doivent être configurées pour envoyer les métriques : configuration hell, risque de plantage de l’apps pour cause de monitoring, connaissance de la stack de monitoring par l’application, …
• en pull : le configuration se fait côté système de monitoring, mais limité par les capacités des collecteurs de métriques (OS, JMX, …)

Pour finir : une petit démo avec dashboard Graphana à l’appui.

HTTP2 en pratique (Alexis Hassler)

Je n’ai pas pris de notes pour ce talk mais je vais essayer de vous le présenter quand même dans les grandes lignes.

Tout d’abord, Alexis nous a présenté les principales fonctionalités d’HTTP/2 :

• Multiplexing des requêtes
• Compression des headers
• Server Push (permet d’envoyer des requêtes au navigateur pour mise en cache par celui-ci)
• HTTPS (mode h2) ou pas (mode h2c – clear text – mais pas supporté par les navigateurs)

Une petite démo à base d’une image fractionnée en 64 parties nous a montré l’effet du multiplexing des requêtes et effectivement, c’est beaucoup plus rapide!

Ensuite, la liste des clients/serveurs HTTP supportant ce protocole a été évoqué avec les limitations actuelles : certains supportent h2 uniquement, h2c uniquement, certains nécessitent des versions de Java ou d’OpenSSL spécifique, …

En gros : c’est compliqué d’avoir de l’HTTP/2 de bout en bout, et encore plus complexe quand un proxy s’intercalle dans nos architecture.

#RetourAuxSources : Les cookies HTTP (Hubert Sablonnière)

Après une introduction très drôle en forme de dialogue entre Sherlock et Watson (avec l’accent anglais!) sur le pourquoi de cette présentation, Hubert nous a parlé de l’historique du cookie.

Le cookie a été créé par Lou Montulli en 1994 qui était alors developpeur sur Lynx (navigateur texte). Il y a ensuite eu une RFC en 1997 puis en 2000, et un brevet Netscape qui a été racheté par … Facebook!

Mais pourquoi avoir créé le cookie? Au départ le web était complètement stateless. Le cookie a été créé pour pouvoir implémenter un état côté client et était nécessaire pour Lynx car celui-ci n’avait pas d’interface graphique … (je ne me rapelle plus de la subtilité en question …)

Voici les bases du cookie telles que reprises dans la présentation :

• Cinématique : Le client emmet une requête vers le serveur => Le serveur répond avec un header Server Set-Cookie : "42" => Le navigateur met le cookie dans sa jarre => a la prochaine requête vers le serveur le client ajoutera un header Cookie : "42"
• Un cookie expire à la fermeture de session par défaut ou à date précise (Expires) ou en durée (Max-Age en seconde)
• Pour supprimer un cokie le serveur doit le renvoyer avec un Expires avec une date dans le passé ou un Max-Age à 0
• On peut définir un domain (optionnel) : le domaine augmente la portée du cookie sur tous les hotes qui se terminent par la valeur (sans : egalité stricte)
• Il n’est pas possible de mettre un cookie sur un top level domain (tld). Le soucis est que certain tld sont en deux partie (ex co.uk)! Ceci a été résolu depuis une RFC de 2011 qui définit une liste de « suffixe publique » utilisé par la pluspart des navigateurs (sauf eddge). Le domaine ne peut pas être localhost.
• Il est possible de préciser un path qui permet de limiter l’envoit des cookie sur certaines URL (commencent par le path)
• Attention : le port n’est pas pris en compte pour différencier les cookies (n’obéit pas à la same origin policy)

La présentation  a beaucoup insisté sur les problèmes de sécurités posés par les cookies et quelques techniques pour les mitiger :

• Un cookie déposé en HTTPS sera accessible en HTTP sauf si déposé avec l’attribut secure (envoit uniquement en HTTPS)
• Un cookie déposé en HTTP pourra être secure et envoyé en HTTPS dans une requêtes successive (draft RFC en cours pour ne supporter le secure qu’en https) : c’est une faille de sécurité.
• Un serveur ne reçoit que le cookie et ne sais donc pas s’il est secure (draft RFC en cours pour utilisation d’un prefix __Secure) ni s’il est sur un domain ou un path spécifique (draft RFC en 2017 pour l’utilisation d’un prefix __Host)
• Si on est sur une page example.com et qu’on appelle une URL en cookies.rocks (par exemple via une image ou un JS), les cookies de cookies.rocks vont être envoyés : c’est ce qu’on appelle un faille CSRF (Cross Site Request Forgery). Un nouvel attribut SameSite permet d’éviter le risque de CSRF en disant au nav de ne pas envoyer de cookie quand on est dans une page différente.
• Les cookies sont accessible en Javascript via document.cookie : faille XSS (Cross Site Scripting) possible. L’attribut HttpOnly permet d’éviter que le cookie soit lu via JS et donc empecher toute attaque de type XSS.

Pour finir, Hubert est revenu sur le fait que les cookies permettent de tracer les utilisateurs via une simple image hébergée sur un domaine différente. Ceci est dut au fait que une requete vers une image contient une entête HTTP referer  qui contient la page source. Le site hébergeant l’image va donc pouvoir via un cookie définir un identifiant unique et via le referer savoir de quelle page la requête a été effectuée. C’est une technique de traking qui détourne l’usage primaire du cookie. Le soucis n’est donc pas les cookies mais bien les techniques de tracking des prestataires marketing …

Istio, we have a problem! Understanding and fixing bugs with a service-mesh. (David Gageot)

Istio est un Service Mesh (terme très à la mode en ce moment) : il ajoute plein de services à Kubernetes. Il est basé sur un ensemble de solutiond existanted qu’il intègre et interface automatiquement avec Kubernetes  : Zipkin, Grafana, Service Graph et Prometheus.

L’interêt d’Istio est que tout est intégré et automatiquement configuré : aucune modification de vos applications nécessaire … par contre il faut utiliser Kubernetes.

En voici les principales fonctionalités :

• Ajout automatique depuis Kubernetes via des composants Envoy intégrés automatiquement dans les pods
• Service graph : graphe des services utilisés par une requête avec le nombre de req/s
• Intégration Prometheus / Grafana
• Intégration Zipkin : tracing des requêtes dans tous les services … sans modification de l’apps existante!
• Déployement controllé : canary deployement : déployer uniquement pour une partie des utilisateur et monitorer ce canary
• Une configuration est nécessaire dans Istio pour un canary deployement via un RouteRule qui définit des règles de routage (destination, request header, …)
• Traffic mirroring : possibilité de copier le traffic d’un service à l’autre : ex envoyer tous en double sur le service 1 et 2 pour valider ‘en live‘ une nouvelle version
• Blue/Green deployement : possibilité de router une fraction des utilisateurs vers le nouveau service

Isto est une solution totalement modulable, dévelopée par Google mais pas encore en version finale (des bugs existent … surtout que c’est un ensemble de composants OSS externe …)

La présentation s’est terminée par une petite démo avec le déploiement d’une application buggée, sa correction, le déploiement d’une version 2 testé via traffic mirroring, puis mis en production en canary sur 50% des apples, puis passage complet sur la nouvelle version le tout visualisé via Graphana avec des graphes de taux d’erreur.

Keynote de fermeture

Le keybote de fermeture a vu trois speakers du devfest s’affronter en présentation speechless : le principe : un sujet choisit au hasard, 6 slides inconnus, pas de préparation : de l’impro. Ce fut très drôle et les trois speakers se sont montrés très inventif.