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 :
dotnet tool install -g Microsoft.Tye --version "0.4.0-alpha.20371.1"
576550
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 :
git clone https://github.com/hinault/identityserver.git
Puis vous positionner sur le dossier IdentityServer :
cd IdentityServer
576551
3. Exécuter les services
Pour exécuter les services, il suffit juste d’utiliser la commande tye run
Tye run
Tye va analyser le fichier de solution (.sln), ensuite générer et exécuter les projets dans la solution, comme vous pouvez le consulter dans la capture ci-dessous :
576552
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.
576553
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.
576555
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
Tye init
Cette commande va générer un fichier tye.yaml à la racine de votre solution, avec le contenu suivant :
# 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 :
# 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 :
576556
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 :
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 :
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 :
:fleche: Le repository de Tye sur GitHub : https://github.com/dotnet/tye
:fleche: Le repsitory du projet d’exemple : https://github.com/hinault/identityserver
:fleche: Mon article sur IdentityServer : https://rdonfack.developpez.com/tutoriels/mise-en-place-service-authentification-avec-identityserver4/
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.