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