gRPC

• Rappel réseau, internet
• Problématique du format de donnée dans les systeme distribué => modification difficile
• Historique des protocoles RCP : CORBA, RMI, EJB, SOAP, REST -> 2008 Protocol Buffers : sérialization (prémice du RCP chez Google : open sourcing partiel) -> 2009 Thrift (Fb) -> 2015 gRPC (basé sur Protocol Buffers)
• gRPC : système de RPC avec Protocol Buffers comme sérialization et basé sur des Interface Description Language et incubé depuis peu dans la Cloud Native Fondation
• IDL : définit les méthodes et les messages -> retour aux principes des systèmes SOAP
• Gestion native des “stream” de réponse avec pagination
• Les attributs des messages sont numéroté et typé pour pouvoir évoluer facilement => évite le big bang ou le versionning dans l’URL
• Serialization Protocole Buffer 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é, …
• Plugin : log, auth, resilience, …
• 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 plugin gRPC <> REST pour appel externe

Métrologie et alerting avec Prometheus et Grafana

• Blackbox monitoring : monitoring comme vu par un end user (ping URL ?)
• Prometheus : système de collecte de métrique de soundcloud intégré dans la CNCF => binaire (GO) => local storage (pas de cluster) => HA : on en démarre deux => multi-dim time serie => requêtage via PromQL => système sans agent : prometheus va chercher les métriques sur les serveurs (pull) via des exporter (jmx par ex) … => existe une push gateway pour pouvoir pousser des métriques vers prometheus (ex via un batch ou un script) => service discover (NDS, consul, docker, …)
• Push vs Pull : => en push les apps doivent être configuré pour envoyer les métriques : configuration hell, risque de platnage de l’apps pour cause de monitoring, connaissance de la stock de monitoring, … => en pull : le conf se fait côté système de monitoring, mais limité par les capacités des collecteurs de métriques (OS, JMX, …)
• Stock des métriques de type compteur, gauge, histogramme, summary (histo avec percentille)
• Promql : requêtage basic via nom_metrique, nom_mertrique{tags}, operation possible (sum, rate, …), request, opérateur logique, offset (dans le passé), [periode], …
  • webUI permet de tester ses requêtes
• Pour du 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, …

Cookie:

Lou Montulli créateur du cookie et dev sur Lynx. (1994, puis RFC en 1997 et 2000) -> au départ : web complètement stateless et le cookie a été créé pour pouvoir implémenter un état côté client -> Brevêt Netscape racheté par Fb … -> les bases du cookie : => client request serveur -> Server Set-Cookie : “42” -> Nav dans jarre -> client request 2 Cookie : “42” => cookie expiré à la fermeture de session par défaut ou à date précise (Expires) ou en duré (Max-Age en seconde) => supression d’un cokie : expires avec date dans le passé ou max-age 0 => définit sur un domain (ou sans) : domaine augmente la portée du cookie par tous les hotes qui se terminent par la valeur (sans : egualité stricte) => pas possible de mettre un cookie sur un top level domain … pb des tld en deux partie (ex co.uk) résolu depuis une RFC de 2011 qui définit une liste de “suffixe publique” utilisé par la pluspart des navigateurs (sauf eddge) => pas possible de mettre Domain=localhost => path : permet de limiter l’envoit des cookie sur certaines URL (commencent par le path) => 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 pour ne suporter le secure qu’en https => un serveur ne reçoit que le cookie et ne sais donc pas s’il est secure : draft pour utilisation d’un prefix Secure ni s’il est sur un domain ou un path précise : prefix Host (RFC draft 2017) => attention : le port n’est pas pris en compte pour différencier les cookie (n’obéit pas à la same origin policy) -> Si on est sur une page example.com et qu’on appèlle une URL en cookies.rocks … les cookies de cookies.rocks vont être envoyé => CSRF ! => 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 cookie sont accessible en Javascript via document.cookie => faille XSS possible => attribut HttpOnly permet d’éviter que le cookie soit lu via JS et donc le XSS -> les cookies permettent de tracer les utilisateurs via une simple image sur une page différente car dans la requêtes il y a le referer … => technique de traking qui détourne l’usage primaire …

Istio:

-> Service Mesh : ajoute plein de services à Kubernetes : zipkin, grafana, service graph, prometheus -> ajout automatique depuis Kubernetes via des composant “Envoy” intégré automatiquement dans les pod -> service graph : graphe des services utilisé par une requête avec le nb 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 monitoré ce canary => configuration à faire 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 -> Pas encore en version finale … des bugs existent … surtout que c’est un ensemble de composants OSS externe … -> Blue/Green deployement : ppossibilité de router une fraction des utilisateurs vers le nouveau service -> Dev par Google -> Solution totalement modulable