Sekina.Belguendouz at 02:11, 15 January 2019

2019-01-15T02:11:38Z

← Older revision	Revision as of 02:11, 15 January 2019
Line 1:	Line 1:
		=Auteur=
		*Nom : BELGUENDOUZ Sekina
		*Mail : sekina.belguendouz@etu.univ-grenoble-alpes.fr
		*Sujet : Service Mesh

		=Résumé=
		Le service mesh est une infrastructure qui assure la communication entre les microservices d'une application. Il rend non seulement les communications sont plus fiable et rapide, mais il permet aussi d’avoir un contrôle sur ces dernières.
		Avec l’utilisation de sidecar (proxy), il devient facile de configurer les connexions selon nos besoins. Il est possible de :
		* Répartir les charge équitablement,
		* Contrôler de trafic entrant et sortant au microservice,
		* Sécuriser les connexions en encryptant les données, en obligeant une authentification ou en bloquant totalement l’accès à certains microservice,
		* etc.
		Istio est une plateforme qui permet de configurer le service mesh d’une application microservice. Elle utilise le proxy Envoy et mets à disposition un bon nombre d’outil pour le monitoring.

		==Mots clés==
		* Microservices
		* Conteneur
		* Proxy / Sidecar
		* Istio
		* Kebernetes

		=Abstract=
		Service mesh is an infrastructure layer which ensures the communication between the services in a microservices application. It allows not only the communication to be faster and more reliable, but it also provides some control.
		With the use of sidecar (proxy), it becomes easier to configure connexions according to our needs. It provides:
		* load balancing,
		* Control on the incoming and outgoing traffic of the microservices,
		* Security and safety by encrypting data, forcing an authentication or blocking access to some microservices.
		* etc.
		Istio is a platform that allows the configuration of the service mesh. It uses Envoy proxy and provides some monitoring tools.

		==Keywords==
		* Microservices
		* Container
		* Proxy / Sidecar
		* Istio
		* Kebernetes

		=Synthèse=
		==Définitions ==

		« Le service mesh désigne une plateforme chargée d’assurer la sécurité, le routage et la traçabilité des communications entre applications microservices déployées de façon dynamique dans des conteneurs. », nous donne comme définition Octo Tech. Mais cela ne rend pas plus claire le terme Service Mesh, pour cela il nous faut définir certain terme de cette définition.

		'''Conteneur'''
		Un conteneur est un système de virtualisation, permettant d’isoler des environnements Linux, afin d’y faire tourner différentes applications de manière totalement indépendantes.

		[[ File:VT2018SM_CONT.png ]]

		'''Application Microservices'''
		L’approche architecturale Microservices se différentie de l’approche Monolithique de par sa décomposition en plusieurs composants. Ces derniers sont nommés des microservices et sont totalement isolées les uns des autres. On va ensuite pouvoir déployer ces services de manière indépendante sur des conteneurs différents.

		[[ File:VT2018SM_MONOvsMICRO.png ]]

		Au lieu d’avoir la partie calcul de l’application avec l’interface utilisateur, comme pour une application monolithique, on va avoir une séparation dans les fonctions de l’application. Par exemple, soit une application de e-commerce.

		[[ File:VT2018SM_ECOM.png ]]

		On va un service pour toutes les actions liées à l’inventaire : récupérations des valeurs dans la base de données, affichage des éléments, … . On peut ensuite avoir autre service pour la gestion du panier : ajout d’élément, affichage du panier, … .

		L’avantage d’une telle technologie est que si un microservice ne répond plus pour une raison ou pour une autre l’application ne risquera rien. Ces deniers étant déployés dans des conteneurs différents.

		'''Service Mesh'''
		Maintenant, que l’on a défini les termes importants, on va revenir sur la définition de service mesh. Un service mesh est tout simplement l’infrastructure de configuration qui permet de définir comment les microservices vont communiquer les uns avec les autres.
		En reprenant l’exemple précédent, le service Shopping Cart va avoir besoin d’informations de l’inventaire pour fonctionner correctement. Il nous faut donc un moyen de communiquer entre les microservices, mais surtout il nous faut contrôler la provenance des requêtes, peut-être même sécuriser les données en les cryptant.
		Toutes les configurations nécessaires peuvent bien sûr être implémentées dans le service lui-même. Cependant si le nombre de microservices devient trop grand, les développeurs seront vite débordés. C’est là qu’intervient le service mesh et ses sidecar.

		==Fonctionnement==
		===Les Sidecars===

		[[ File:VT2018SM_SideCar.png ]]

		L’utilisation de sidecar va permettre au microservice de lui déléguer toutes les tâches liées à la communication inter-microservice. Ces sidecars fonctionnent comme des proxys, le microservice va émettre une requête au sidecar qui va transmettre le message au dentinaire et récupérer la réponse pour la remettre à son microservice associé.

		[[ File:VT2018SM_Proxy.png ]]

		Les configurations des proxys dépendent de la plateforme utilisée. A ce jour, on peut en trouver plusieurs comme linkerd, kubeflix ou zuul, mais on va, pour monter le fonctionnement du service mesh, se concentrer sur le plus célèbre Istio.

		===Istio===

		Istio est une technologie OpenSource développé par les ingénieurs de Google, IBM et Lyft. Cette plateforme permet non seulement connecter et sécuriser les microservices mais aussi de les manager et monitorer. Elle est utilisable sur plusieurs environnement et plateformes, mais elle est Kubernetes first. Les proxys utilisés ici sont des Envoy proxys qui permettent :
		* Découverte dynamique de service
		* Repartition des charges
		* TLS termination
		* HTTP/2 et gRPC proxys
		* Staged rollouts with %-based traffic split
		* Injection de fautes
		* Metrique riche
		Pour faire fonctionner le tout, Istio est composé de 4 modules : Mixer, Control Plane, Pilot et Citadel.

		[[ File:VT2018SM_Istio.png ]]

		==== Control Plane =====

		Le control Plane gère et configure les proxys au trafic. On va aussi configurer Mixer pour appliquer les règles et collecter des donnée nécessaires.

		====Mixer =====

		Mixer est de composant qui a assuré le respect des politiques dans le service mesh, tout en collectant des données. A partir de ces dernières, il est possible d’avoir une visualisation graphique de l’évolution de requêtes.

		==== Pilot =====

		Pilot est le composant qui est le réel cerveau d’Istio. C’est ce composant qui va configurer les proxys et qui va pousser les configurations dans chaque sidecar présent dans le projet.

		==== Citadel =====

		Et enfin on a le composant Citadel, chargé de tout ce qui touche la sécurité, allant de l’authentification au cryptage des données.

		==Références==

		* https://www.nginx.com/blog/what-is-a-service-mesh/ - Fourni par le corps enseignant
		* https://www.nginx.com/learn/service-mesh/
		* https://blog.octo.com/vision-docto-sur-le-service-mesh-les-enjeux/ - Le blog de l’entreprise OCTO Tech. qui traite de nombreuse nouvelle technologie
		* https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh# - Website de la société RedHat
		* https://istio.io/docs/concepts/what-is-istio/ - Fourni par le corps enseignant
		* https://saturnism.me/talk/making-microservices-micro-istio/ - Fourni par le corps enseignant

Sekina.Belguendouz: Created blank page

2019-01-14T12:02:11Z

Created blank page

New page

VT2018 Service Mesh - Revision history

Sekina.Belguendouz at 02:11, 15 January 2019

Sekina.Belguendouz: Created blank page