Dans ce billet de blog, j’aimerais vous présenter Microsoft Tye. Il s’agit d’un projet open source encore au stade expérimental qui promet de simplifier le développement, les tests en local et les déploiements des microservices, notamment sur des clusters kubernetes.Concrètement, il s’agit en quelque sorte d’un orchestrateur local qui va faciliter le développement des microservices et des applications distribuées, qui pourront être déployés avec le minimum de configuration sur des clusters Kubernetes.
Selon la page du projet, Tye permet :
- Simplifier le développement des microservices en facilitant :
• l’exécution de nombreux services avec une seule commande;
• l’utilisation des dépendances dans des conteneurs;
• la découverte des adresses d’autres services en utilisant des conventions simples.
- Déployer des applications .NET sur Kubernetes en :
• automatisant la conteneurisation des applications .NET;
• générant les manifestes kubernetes;
• utilisant les mêmes concepts qu’en développement pour maintenir une certaine cohérence.
Il s’agit d’un projet expérimental, donc avant la sortie d’une version stable, les fonctionnalités que je vais présenter ici pourraient radicalement changer ou même être supprimées.
Lorsque j’ai découvert le projet Tye, le premier candidat sur lequel je pouvais tester et tirer avantage de l’outil est le code d’exemple que j’ai mis en place pour IdentityServer.
En effet, dans cet exemple, j’ai trois applications .NET :
- AspNetCoreIdentityServer qui est une application ASP.NET Core 3.1 qui joue le rôle de service de gestion sécurisé de jetons (STS) et est utilisée par les autres applications pour s’authentifier et accéder aux ressources sécurisées;
- TestAPI : qui est une Web API ASP.NET Core, dont l’accès est sécurisé par le STS;
- MvcAppClient : qui est une application ASP.NET Core MVC qui utilise le STS et la WebAPI. Lorsque vous accédez à une page sécurisée de cette application, vous êtes redirigé vers le STS pour vous authentifier avant d’accéder à la page. Lorsque l’application consomme l’API, vos jetons d’authentification sont transmis à cette dernière qui utilise le STS pour les valider avant de retourner les informations auxquelles vous voulez accéder.
Vous comprenez que pour tester l’application MvcAppClient, les deux autres applications doivent être en cours d’exécution. En environnement de développement, j’étais obligé d’ouvrir trois fenêtres de l’invite de commande dans le répertoire racine de chaque service et exécuter la commande dotnet run. Ou déboguer une application dans Visual Studio et exécuter les autres avec dotnet run.
Tye vient me simplifier la vie en permettant l’exécution de tous mes services en une seule commande.
Voyons un peu comment.
1. Installation de Tye
Tye est disponible comme un outil .NET Core. Avant de l’installer vous devez disposer de .NET Core 3.1.
Pour installer l’outil, vous devez exécuter la commande suivante :
| Code : | Sélectionner tout |
dotnet tool install -g Microsoft.Tye --version "0.4.0-alpha.20371.1"
Il faut noter que de nouvelles versions sont publiées toutes les quatre semaines.
2. Cloner le projet d’exemple
Vous devez cloner le projet d’exemple en utilisant la commande suivante :
| Code : | Sélectionner tout |
git clone https://github.com/hinault/identityserver.git
| Code : | Sélectionner tout |
cd IdentityServer
3. Exécuter les services
Pour exécuter les services, il suffit juste d’utiliser la commande tye run
| Code : | Sélectionner tout |
Tye run
Le tableau de bord de Tye est accessible via l’adresse 127.0.0.1:8000. Vous pouvez visualiser les projets en cours d’exécution avec leur adresse.
Il est possible de voir les logs de chaque application en cours d’utilisation. Ce qui est utile pour le débogage de ces derniers.
Faites Ctrl+ C en invite de commande pour arrêter Tye.
4. Configuration de Tye
Pour que la communication passe entre les différents services, l’application IdentityServer doit s’exécuter sur le port 5000 en HTTP et 5001 en HTTPS. L’application MVC sur le port 5004 en HTTP et 5005 en HTTPS. La Web API utilise le port 5002 en HTTP et 5003 en HTTPS. Par défaut Tye exécute nos applications sur des ports de façon aléatoire, ce qui rend la communication impossible entre les différents services.
Pour remédier à cela, nous allons utiliser le fichier de configuration tye.yaml pour configurer nos applications.
Pour générer ce fichier, vous devez exécuter la commande
| Code : | Sélectionner tout |
Tye init
| Code yaml : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # tye application configuration file # read all about it at https://github.com/dotnet/tye # # when you've given us a try, we'd love to know what you think: # https://aka.ms/AA7q20u # name: identityservertuto services: - name: aspnetcoreidentityserver project: AspNetCoreIdentityServer/AspNetCoreIdentityServer.csproj - name: testapi project: TestApi/TestApi.csproj - name: mvcappclient project: MvcAppClient/MvcAppClient.csproj |
Nous allons éditer le fichier pour spécifier le port pour chaque application :
| Code yaml : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | # tye application configuration file # read all about it at https://github.com/dotnet/tye # # when you've given us a try, we'd love to know what you think: # https://aka.ms/AA7q20u # name: identityservertuto services: - name: aspnetcoreidentityserver project: AspNetCoreIdentityServer/AspNetCoreIdentityServer.csproj bindings: - name: http port: 5000 protocol: http - name: https port: 5001 protocol: https - name: testapi project: TestApi/TestApi.csproj bindings: - name: http port: 5002 protocol: http - name: https port: 5003 protocol: https - name: mvcappclient project: MvcAppClient/MvcAppClient.csproj bindings: - name: http port: 5004 protocol: http - name: https port: 5005 protocol: https |
Il ne reste plus qu’à exécuter Tye avec la commande tye run :
Maintenant nos applications s’exécutent sur les bons ports.
5. Utilisation du service discovery
J’ai choisi volontairement de ne pas traduire le terme « service discovery ». Ce terme décrit le processus par lequel un service détermine l’adresse d’un autre service. Il existe différentes façons d’implémenter le « service discovery » en environnement microservices. Chacune apporte couramment son lot de complexité.
L’approche de Tye pour supporter le « service discovery » c’est d’offrir un mécanisme qui va :
- fonctionner de la même manière en environnement de développement local, de production ou Cloud;
- être basé sur des primitives simples;
- éviter le besoin d’une infrastructure externe.
Dans mon application d’exemple, j’ai spécifié les URL de mes services en dur dans le code. La conséquence directe est le fait que je dois toujours utiliser les mêmes ports pour faire tourner mes applications. Si les URL changent, je dois modifier le code de chaque application pour changer les URL.
J’aurais également pu utiliser les fichiers de configuration (appsettings.json). Mais à chaque changement d’URL pour un service, je dois aussi modifier le fichier de configuration des autres services.
La meilleure approche à ce stade est d’utiliser le service discovery de Tye et laisser l’attribution des ports aléatoires lors de l’exécution de mes applications. Ainsi, je n’ai pas à me soucier si un port est utilisé ou pas. Par ailleurs, les tests et les déploiements de mes services dans les différents environnements sont simplifiés.
Le service discovery de Tye repose sur des variables d’environnement du runtime .NET Core. Les URI des services et les chaines de connexion sont donc stockées dans des variables d’environnement.
Pour simplifier l’utilisation dans nos applications, nous pouvons utiliser le package Microsoft.Tye.Extensions.Configuration qui apporte des méthodes d’extensions supplémentaires au système de Configuration de ASP.NET Core.
Mon code dans lequel je référençais en dur l’adresse de mon service :
| Code c# : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | services.AddAuthentication(options => { options.DefaultScheme = "Cookies"; options.DefaultChallengeScheme = "oidc"; }) .AddCookie("Cookies") .AddOpenIdConnect("oidc", options => { options.Authority = "https://localhost:5001"; options.RequireHttpsMetadata = false; options.ClientSecret = "secret"; options.ResponseType = "code"; options.ClientId = "mvcappclient"; options.SaveTokens = true; }); |
Devient donc :
| Code c# : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | services.AddAuthentication(options => { options.DefaultScheme = "Cookies"; options.DefaultChallengeScheme = "oidc"; }) .AddCookie("Cookies") .AddOpenIdConnect("oidc", options => { options.Authority = Configuration.GetServiceUri("AspNetCoreIdentityServer").AbsoluteUri options.RequireHttpsMetadata = false; options.ClientSecret = "secret"; options.ResponseType = "code"; options.ClientId = "mvcappclient"; options.SaveTokens = true; }); |
6. Conclusion
Comme vous avez pu le constater Microsoft Tye est un outil assez promoteur qui nous sera d’une grande utilité pour la mise en place de nos microservices. Je vais continuer à suivre l’évolution de l’outil et vous reviendrais avec les fonctionnalités que je trouve intéressantes.
Pour en savoir plus :
Le repository de Tye sur GitHub : https://github.com/dotnet/tye Le repsitory du projet d’exemple : https://github.com/hinault/identityserver Mon article sur IdentityServer : https://rdonfack.developpez.com/tuto...entityserver4/ 