Guide de conversion des rôles web et de travail en services sans état Service Fabric
Cet article explique comment migrer vos rôles web et de travail des services cloud vers les services sans état Service Fabric. Il s’agit de la manière la plus simple de migrer des applications dont l’architecture globale va rester quasi identique des services cloud vers Service Fabric.
Passer d’un projet de service cloud à un projet d’application Service Fabric
Les projets de service cloud et les projets d’application Service Fabric présentent une structure similaire. Les deux représentent l’unité de déploiement de votre application : autrement dit, ils définissent tous deux l’ensemble du package déployé pour exécuter votre application. Un projet de service cloud contient un ou plusieurs rôles web ou de travail. De la même façon, un projet d’application Service Fabric regroupe un ou plusieurs services.
La différence est que le projet de service cloud associe le déploiement d’application à un déploiement de machine virtuelle et inclut donc les paramètres de configuration de la machine virtuelle, tandis que le projet d’application Service Fabric définit uniquement une application qui sera déployée sur un ensemble de machines virtuelles existantes dans un cluster Service Fabric. Le cluster Service Fabric est déployé une seule fois, par le biais d’un modèle Resource Manager ou du portail Azure, et plusieurs applications Service Fabric peuvent y être déployées.
Rôle de travail en service sans état
D’un point de vue conceptuel, un rôle de travail représente une charge de travail sans état, ce qui signifie que toutes les instances de la charge de travail sont identiques et que les requêtes peuvent être acheminées vers n’importe quelle instance à tout moment. Chaque instance n’est pas censée se souvenir de la requête précédente. L’état auquel la charge de travail s’exécute est géré par un magasin d’état externe, tel qu’Azure Stockage Table ou Azure Cosmos DB. Dans Service Fabric, ce type de charge de travail est représenté par un service sans état. Le plus simple pour migrer un rôle de travail dans Service Fabric est de convertir un code de rôle de travail en service sans état.
Rôle web en service sans état
Comme pour le rôle de travail, un rôle web représente également une charge de travail sans état, et, d’un point de vue conceptuel, il peut donc lui aussi être mappé vers un service sans état Service Fabric. Toutefois, contrairement aux rôles web, Service Fabric ne prend pas en charge les IIS. Pour migrer une application web d’un rôle web vers un service sans état, vous devez d’abord passer à une infrastructure web auto-hébergée et qui ne dépend pas d’IIS ou de System.Web, comme ASP.NET Core 1.
| Application | Pris en charge | Chemin de migration |
|---|---|---|
| Formulaires web ASP.NET | Non | Convertir en ASP.NET Core 1 MVC |
| ASP.NET MVC | Avec migration | Mettre à niveau vers ASP.NET Core 1 MVC |
| API Web ASP.NET | Avec migration | Utiliser un serveur auto-hébergé ou ASP.NET Core 1 |
| ASP.NET Core 1 | Oui | N/A |
API de point d’entrée et cycle de vie
Les points d’entrée des API de rôle de travail et de Service Fabric sont semblables :
| Point d’entrée | Instances de | Service Service Fabric |
|---|---|---|
| Traitement en cours | Run() |
RunAsync() |
| Démarrer la machine virtuelle | OnStart() |
N/A |
| Arrêter la machine virtuelle | OnStop() |
N/A |
| Ouvrir l’écouteur pour les requêtes du client | N/A |
|
Instances de
using Microsoft.WindowsAzure.ServiceRuntime;
namespace WorkerRole1
{
public class WorkerRole : RoleEntryPoint
{
public override void Run()
{
}
public override bool OnStart()
{
}
public override void OnStop()
{
}
}
}
Services sans état Service Fabric
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.ServiceFabric.Services.Communication.Runtime;
using Microsoft.ServiceFabric.Services.Runtime;
namespace Stateless1
{
public class Stateless1 : StatelessService
{
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
}
protected override Task RunAsync(CancellationToken cancelServiceInstance)
{
}
}
}
Les deux disposent d’un remplacement « Exécuter » principal où commencer le traitement. Les services Service Fabric associent Run, Start et Stop en un point d’entrée unique, RunAsync. Votre service doit démarrer en même temps que RunAsync et doit cesser de fonctionner quand le CancellationToken de la méthode RunAsync est signalé.
Il existe plusieurs différences majeures entre le cycle de vie et la durée de vie des rôles de travail et des services Service Fabric :
- Cycle de vie : la plus grande différence est qu’un rôle de travail est une machine virtuelle. Son cycle de vie est donc lié à la machine virtuelle, ce qui inclut les événements de démarrage et d’arrêt de la machine virtuelle. Le cycle de vie des services Service Fabric est distinct du cycle de vie de la machine virtuelle. Il n’inclut donc pas d’événements lorsque l’ordinateur ou la machine virtuelle hôte démarre et s’arrête, dans la mesure où ils ne sont pas liés.
- Durée de vie : les instances de rôle de travail sont recyclées quand la méthode
Runse ferme. La méthodeRunAsyncdans un service Service Fabric peut cependant s’exécuter jusqu’à la fin et l’instance de service continuera de s’exécuter.
Service Fabric fournit un point d’entrée de configuration de la communication en option pour les services qui écoutent les requêtes des clients. RunAsync et le point d’entrée de communication constituent tous deux des remplacements en option dans les services Service Fabric. Votre service peut choisir d’écouter les requêtes des clients, d’exécuter uniquement une boucle de traitement, ou les deux. C’est pourquoi la méthode RunAsync peut se fermer sans redémarrer l’instance de service : elle peut continuer à écouter les requêtes des clients.
API d’application et environnement
L’API d’environnement des services cloud fournit des informations et des fonctionnalités pour l’instance de machine virtuelle active ainsi que des informations sur les autres instances de rôle de machine virtuelle. Service Fabric fournit des informations concernant son exécution et le nœud sur lequel un service s’exécute actuellement.
| Tâche d’environnement | Cloud Services | Service Fabric |
|---|---|---|
| Paramètres de configuration et notification de modification | RoleEnvironment |
CodePackageActivationContext |
| Stockage local | RoleEnvironment |
CodePackageActivationContext |
| Informations sur le point de terminaison | RoleInstance
|
|
| Émulation de l’environnement | RoleEnvironment.IsEmulated |
N/A |
| Événement de modification simultanée | RoleEnvironment |
N/A |
Paramètres de configuration
Les paramètres de configuration des services cloud sont définis pour un rôle de machine virtuelle et s’appliquent à toutes les instances de ce rôle de machine virtuelle. Ces paramètres correspondent à des paires clé-valeur définies dans les fichiers ServiceConfiguration.*.cscfg. Ils sont accessibles directement via RoleEnvironment. Dans Service Fabric, les paramètres s’appliquent individuellement à chaque service et chaque application, plutôt qu’à une machine virtuelle. En effet, une machine virtuelle peut héberger plusieurs applications et services. Un service se compose de trois packages :
- Code : contient les exécutables du service, ses fichiers binaires, ses DLL et tous les autres fichiers dont un service a besoin pour s’exécuter.
- Config : tous les fichiers de configuration et les paramètres d’un service.
- Data : fichiers de données statiques associés au service.
Chacun de ces packages peut être individuellement mis à niveau et faire l’objet d’un contrôle de version indépendant. Comme pour les services cloud, les packages de configuration sont accessibles par programme via une API et des événements permettent d’informer le service de toute modification apportée au package de configuration. Un fichier Settings.xml peut être utilisé pour la configuration clé-valeur et l’accès par programmation de manière similaire à la section appSetttings d’un fichier App.config. Toutefois, contrairement aux services cloud, les packages de configuration Service Fabric peuvent contenir des fichiers de configuration à n’importe quel format : XML, JSON, YAML ou tout format binaire personnalisé.
Accès à la configuration
Cloud Services
Les paramètres de configuration de ServiceConfiguration.*.cscfg sont accessibles par le biais de RoleEnvironment. Toutes les instances de rôle d’un même déploiement de service cloud peuvent accéder à ces paramètres.
string value = RoleEnvironment.GetConfigurationSettingValue("Key");
Service Fabric
Chaque service dispose de son propre package de configuration individuel. Il n’existe aucun mécanisme intégré permettant à toutes les applications d’un cluster d’accéder à l’ensemble des paramètres de configuration. Lorsque vous utilisez le fichier de configuration spécial Settings.xml de Service Fabric dans un package de configuration, les valeurs du fichier Settings.xml peuvent être remplacées au niveau de l’application, permettant ainsi l’utilisation de paramètres de configuration au niveau de l’application.
Les paramètres de configuration constituent des accès au sein de chaque instance de service par le biais du CodePackageActivationContextdu service.
ConfigurationPackage configPackage = this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config");
// Access Settings.xml
KeyedCollection<string, ConfigurationProperty> parameters = configPackage.Settings.Sections["MyConfigSection"].Parameters;
string value = parameters["Key"]?.Value;
// Access custom configuration file:
using (StreamReader reader = new StreamReader(Path.Combine(configPackage.Path, "CustomConfig.json")))
{
MySettings settings = JsonConvert.DeserializeObject<MySettings>(reader.ReadToEnd());
}
Événements de mise à jour de la configuration
Cloud Services
L’événement RoleEnvironment.Changed sert à informer toutes les instances de rôle quand une modification est apportée à l’environnement, telle qu’une modification de configuration. Cela permet d’effectuer les mises à jour de la configuration sans recycler les instances de rôle, ni redémarrer un processus de travail.
RoleEnvironment.Changed += RoleEnvironmentChanged;
private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e)
{
// Get the list of configuration changes
var settingChanges = e.Changes.OfType<RoleEnvironmentConfigurationSettingChange>();
foreach (var settingChange in settingChanges)
{
Trace.WriteLine("Setting: " + settingChange.ConfigurationSettingName, "Information");
}
}
Service Fabric
Chacun des trois types de package d’un service (Code, Config et Data) inclut des événements qui informent une instance de service lorsqu’un package est mis à jour, ajouté ou supprimé. Un service peut contenir plusieurs packages de chaque type. Par exemple, un service peut avoir plusieurs packages de configuration, chacun pouvant être géré et mis à niveau individuellement.
Ces événements permettent d’apporter des modifications aux packages de service sans avoir à redémarrer l’instance de service.
this.Context.CodePackageActivationContext.ConfigurationPackageModifiedEvent +=
this.CodePackageActivationContext_ConfigurationPackageModifiedEvent;
private void CodePackageActivationContext_ConfigurationPackageModifiedEvent(object sender, PackageModifiedEventArgs<ConfigurationPackage> e)
{
this.UpdateCustomConfig(e.NewPackage.Path);
this.UpdateSettings(e.NewPackage.Settings);
}
Tâches de démarrage
Les tâches de démarrage sont des actions effectuées avant le démarrage d’une application. Elles sont généralement utilisées pour exécuter des scripts de configuration avec des privilèges élevés. Les services cloud et Service Fabric prennent tous deux en charge les tâches de démarrage. La principale différence est que dans les services cloud, les tâches de démarrage sont liées à une machine virtuelle, car elles font partie d’une instance de rôle, tandis que dans Service Fabric, les tâches de démarrage sont liées à un service, qui n’est lui-même pas lié à une machine virtuelle en particulier.
| Service Fabric | Cloud Services |
|---|---|
| Emplacement de la configuration | ServiceDefinition.csdef |
| Privilèges | « limités » ou « élevés » |
| Séquencement | « simple », « en arrière-plan », « au premier plan » |
Cloud Services
Dans les services cloud, un point d’entrée de démarrage est configuré pour chaque rôle dans le fichier ServiceDefinition.csdef.
<ServiceDefinition>
<Startup>
<Task commandLine="Startup.cmd" executionContext="limited" taskType="simple" >
<Environment>
<Variable name="MyVersionNumber" value="1.0.0.0" />
</Environment>
</Task>
</Startup>
...
</ServiceDefinition>
Service Fabric
Dans Service Fabric, un point d’entrée de démarrage est configuré pour chaque service dans le fichier ServiceManifest.xml :
<ServiceManifest>
<CodePackage Name="Code" Version="1.0.0">
<SetupEntryPoint>
<ExeHost>
<Program>Startup.bat</Program>
</ExeHost>
</SetupEntryPoint>
...
</ServiceManifest>
Remarque sur l’environnement de développement
Les services cloud et Service Fabric sont tous deux intégrés à Visual Studio avec les modèles de projet et la prise en charge du débogage, de la configuration et du déploiement, localement et sur Azure. Les services cloud et Service Fabric fournissent également tous deux un environnement local d’exécution de développement. La différence est que, tandis que l’exécution de développement du service cloud émule l’environnement Azure sur lequel il s’exécute, Service Fabric n’utilise pas d’émulateur, mais l’exécution Service Fabric dans son intégralité. L’environnement Service Fabric que vous exécutez sur votre machine de développement locale est le même que celui qui s’exécute en production.
Étapes suivantes
Découvrez plus en détail les services fiables Service Fabric et les différences fondamentales entre les services cloud et l’architecture d’application Service Fabric, afin de comprendre comment tirer parti de l’ensemble des fonctionnalités de Service Fabric.