Partager via

Cycle de vie des applications Service Fabric

  • Article

Comme pour les autres plateformes, une application sur Azure Service Fabric passe généralement par les phases suivantes : conception, développement, test, déploiement, mise à niveau, maintenance et suppression. Service Fabric offre une excellente prise en charge du cycle de vie complet des applications cloud : du développement au retrait éventuel, en passant par le déploiement, la gestion quotidienne et la maintenance. Le modèle de service permet à différents rôles de participer indépendamment au cycle de vie des applications. Cet article fournit une vue d'ensemble des API et de la façon dont elles sont utilisées par les différents rôles pendant les phases du cycle de vie des applications Service Fabric.

Consultez cette page pour obtenir une vidéo de formation qui décrit comment gérer le cycle de vie de votre application :

Important

Deux utilitaires CLI sont utilisés pour interagir avec Service Fabric. Azure CLI est utilisé pour gérer les ressources Azure, comme un cluster Service Fabric hébergé par Azure. Service Fabric CLI est utilisé pour se connecter directement au cluster Service Fabric (peu importe où il est hébergé) et gérer le cluster, les applications et les services.

Rôles de modèle de service

Les rôles de modèle de service sont les suivants :

  • Développeur de service : développe des services génériques et modulaires qui peuvent être réaffectés et utilisés dans plusieurs applications du même type ou de différents types. Par exemple, un service de file d'attente peut être utilisé pour la création d'une application de gestion de tickets (support technique) ou d'une application de commerce électronique (panier).
  • Développeur d’application : crée des applications en intégrant un ensemble de services pour répondre à des scénarios ou exigences spécifiques. Par exemple, un site web de commerce électronique peut intégrer un service frontal sans état JSON, un service sans état d’enchères et un service avec état de file d’attente pour créer une solution de vente aux enchères.
  • Administrateur d’application : prend des décisions sur la configuration de l’application (indication des paramètres de modèle de configuration), le déploiement (mappage aux ressources disponibles) et la qualité de service. Par exemple, un administrateur d’application détermine la langue locale de l’application (anglais pour les États-Unis ou japonais pour le Japon, par exemple). Une application déployée différente peut avoir différents paramètres.
  • Opérateur : déploie des applications basées sur la configuration et les spécifications définies par l’administrateur d’application. Par exemple, un opérateur met en service et déploie l'application et s'assure qu'elle s'exécute dans Azure. Les opérateurs surveillent les informations d'intégrité et de performances des applications et gèrent l'infrastructure physique en fonction des besoins.

Développer

  1. Un développeur de service développe différents types de services à l’aide du modèle de programmation Reliable Actors ou Reliable Services.
  2. Un développeur de service décrit de manière déclarative les types de service développés dans un fichier de manifeste de service comprenant au moins un package de code, de configuration et de données.
  3. Un développeur d'application crée ensuite une application à l'aide de différents types de service.
  4. Un développeur d'application décrit de manière déclarative le type d'application dans un manifeste d'application en référençant les manifestes de service des services constitutifs et en remplaçant et paramétrant correctement les différents paramètres de configuration et de déploiement des services constitutifs.

Pour obtenir des exemples, consultez Prise en main de Reliable Actors et Prise en main de Reliable Services.

Déployer

  1. Un administrateur d’application personnalise le type d’application en une application spécifique en vue de son déploiement sur un cluster Service Fabric en spécifiant les paramètres appropriés de l’élément ApplicationType du manifeste d’application.
  2. Un opérateur charge le package d’application vers le magasin d’images du cluster à l’aide de la méthode CopyApplicationPackage ou de l’applet de commande Copy-ServiceFabricApplicationPackage. Le package d'application contient le manifeste d'application et la collection de packages de service. Service Fabric déploie les applications à partir du package d’application stocké dans le magasin d’images, qui peut être un magasin d’objets blob Azure ou le service système Service Fabric.
  3. Ensuite, l’opérateur provisionne le type d’application dans le cluster cible à partir du package d’application chargé à l’aide de la méthode ProvisionApplicationAsync, de la cmdlet Register-ServiceFabricApplicationType ou de l’opération REST de provisionnement d’une application.
  4. Une fois l’application approvisionnée, un opérateur la démarre avec les paramètres fournis par l’administrateur d’application à l’aide de la méthode CreateApplicationAsync, de l’applet de commande New-ServiceFabricApplication ou de l’opération REST de création d’application.
  5. Une fois l’application déployée, un opérateur utilise la méthode CreateServiceAsync, l’applet de commande New-ServiceFabricService ou l’opération REST de création de service pour créer des instances de service pour l’application en fonction des types de services disponibles.
  6. À ce stade, l'application est en cours d'exécution dans le cluster Service Fabric.

Pour obtenir des exemples, consultez Déployer une application .

Test

  1. Après le déploiement sur le cluster de développement local ou sur un cluster de test, un développeur de service exécute le scénario de test de basculement intégré à l’aide des classes FailoverTestScenarioParameters et FailoverTestScenario ou de l’applet de commande Invoke-ServiceFabricFailoverTestScenario. Le scénario de test de basculement exécute un service spécifié en procédant à des transitions et à des basculements intensifs pour s’assurer de sa disponibilité et de son bon fonctionnement.
  2. Le développeur de service exécute ensuite le scénario de test de chaos intégré à l’aide des classes ChaosTestScenarioParameters et ChaosTestScenario ou de l’applet de commande Invoke-ServiceFabricChaosTestScenario. Le scénario de test chaos provoque aléatoirement plusieurs défaillances de nœud, de package de code et de réplica dans le cluster.
  3. Le développeur de service teste la communication entre les services en créant des scénarios de test qui déplacent des réplicas principaux dans le cluster.

Consultez la rubrique Introduction au service d’analyse des erreurs pour plus d'informations.

Mettre à niveau

  1. Un développeur de service met à jour les services constitutifs de l’application instanciée et/ou corrige les bogues et fournit une nouvelle version du manifeste de service.
  2. Un développeur d'application substitue et ajuste les paramètres de configuration et de déploiement des services constitutifs et fournit une nouvelle version du manifeste d'application. Le développeur d'application intègre ensuite les nouvelles versions des manifestes de service à l'application et fournit une nouvelle version du type d'application dans un package d'application mis à jour.
  3. Un administrateur d'application incorpore la nouvelle version du type d'application dans l'application cible en mettant à jour les paramètres appropriés.
  4. Un opérateur charge le package d’application mis à jour vers le magasin d’images du cluster à l’aide de la méthode CopyApplicationPackage ou de l’applet de commande Copy-ServiceFabricApplicationPackage. Le package d'application contient le manifeste d'application et la collection de packages de service.
  5. Un opérateur approvisionne la nouvelle version de l’application dans le cluster cible à l’aide de la méthode ProvisionApplicationAsync, de l’applet de commande Register-ServiceFabricApplicationType ou de l’opération REST d’approvisionnement d’une application.
  6. Un opérateur met à niveau l’application cible vers la nouvelle version à l’aide de la méthode UpgradeApplicationAsync, de l’applet de commande Start-ServiceFabricApplicationUpgrade ou de l’opération REST de mise à niveau d’une application.
  7. Un opérateur vérifie la progression de la mise à niveau à l’aide de la méthode GetApplicationUpgradeProgressAsync, de l’applet de commande Get-ServiceFabricApplicationUpgrade ou de l’opération REST d’obtention de la progression de la mise à niveau d’une application.
  8. Si nécessaire, l’opérateur modifie et applique de nouveau les paramètres de la mise à niveau d’application actuelle à l’aide de la méthode UpdateApplicationUpgradeAsync, de l’applet de commande Update-ServiceFabricApplicationUpgrade ou de l’opération REST de mise à jour d’une mise à niveau d’application.
  9. Si nécessaire, l’opérateur restaure la mise à niveau d’application actuelle à l’aide de la méthode RollbackApplicationUpgradeAsync, de l’applet de commande Start-ServiceFabricApplicationRollback ou de l’opération REST de restauration d’une mise à niveau d’application.
  10. Service Fabric met à niveau l'application cible en cours d'exécution dans le cluster sans perdre la disponibilité des services qui la composent.

Pour obtenir des exemples, consultez Didacticiel de mise à niveau d’application .

Maintenance

  1. Pour les mises à niveau et les correctifs du système d'exploitation, Service Fabric interagit avec l'infrastructure Azure pour garantir la disponibilité de toutes les applications en cours d'exécution dans le cluster.
  2. Pour les mises à niveau et les correctifs de la plateforme Service Fabric, Service Fabric se met à niveau sans perdre la disponibilité des applications en cours d’exécution dans le cluster.
  3. Un administrateur d'application approuve l'ajout ou la suppression de nœuds d'un cluster après avoir analysé les données historiques relatives à l'utilisation des capacités et estimé la demande future.
  4. Un opérateur ajoute et supprime des nœuds spécifiés par l’administrateur d’application.
  5. Quand de nouveaux nœuds sont ajoutés au cluster ou que des nœuds existants sont supprimés de celui-ci, Service Fabric équilibre automatiquement la charge des applications en cours d’exécution sur tous les nœuds du cluster pour obtenir des performances optimales.

Supprimer

  1. Un opérateur peut supprimer une instance spécifique d’un service en cours d’exécution dans le cluster sans supprimer l’ensemble de l’application à l’aide de la méthode DeleteServiceAsync, de l’applet de commande Remove-ServiceFabricService ou de l’opération REST de suppression d’un service.
  2. Un opérateur peut également supprimer une instance d’application et tous ses services à l’aide de la méthode DeleteApplicationAsync, de l’applet de commande Remove-ServiceFabricApplication ou de l’opération REST de suppression d’une application.
  3. Une fois que l’application et les services sont arrêtés, l’opérateur peut déprovisionner le type d’application à l’aide de la méthode UnprovisionApplicationAsync, de la cmdlet Unregister-ServiceFabricApplicationType ou de l’opération REST de déprovisionnement d’une application. L’annulation de la mise en service du type d’application ne supprime pas le package d’application du magasin d’images.
  4. Un opérateur supprime le package d’application du magasin d’images à l’aide de la méthode RemoveApplicationPackage ou de l’applet de commande Remove-ServiceFabricApplicationPackage.

Pour obtenir des exemples, consultez Déployer une application .

Préservation de l’espace disque dans le magasin d’images du cluster

ImageStoreService conserve les packages copiés et provisionnés, ce qui peut entraîner une accumulation de fichiers. L’accumulation de fichiers peut entraîner le remplissage du disque par le service ImageStoreService (fabric:/System/ImageStoreService) et augmenter le temps de génération pour les réplicas ImageStoreService.

Pour éviter l’accumulation de fichiers, utilisez la séquence de provisionnement suivante :

  1. Copier le package dans ImageStore et utiliser l’option de compression

  2. Provisionner le package

  3. Supprimer le package dans le magasin d’images

  4. Mettre à niveau l’application/le cluster

  5. Annuler le provisionnement de l’ancienne version

Les étapes 3 et 5 de la procédure ci-dessus empêchent l’accumulation de fichiers dans le magasin d’images.

Configuration pour le nettoyage automatique

Vous pouvez automatiser l’étape 3 ci-dessus à l’aide de PowerShell ou XML. Cela entraîne la suppression automatique du package d’application après l’inscription réussie du type d’application.

PowerShell :

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML :

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

Vous pouvez automatiser l’étape 5 ci-dessus à l’aide de XML. Cela entraîne la désinscription automatique des types d’applications inutilisés.

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

Nettoyer les fichiers et les données sur les nœuds

À terme, la réplication des fichiers d’application entraînera la répartition des fichiers sur tous les nœuds en fonction des actions d’équilibrage. Cela peut exercer une pression sur le disque en fonction du nombre d’applications et de la taille de leurs fichiers. Même si aucune instance active n’est en cours d’exécution sur un nœud, les fichiers d’une ancienne instance sont conservés. Il en va de même pour les données provenant de collections fiables utilisées par les services avec état. Cela permet d’accroître la disponibilité. En cas de nouvelle instance d’une application sur le même nœud, aucun fichier ne doit être copié. Pour les collections fiables, seul le delta doit être répliqué.

Pour supprimer complètement les fichiers binaires d’application, vous devez annuler l’inscription du type d’application.

Recommandations à suivre pour réduire la pression exercée sur le disque :

  1. Remove-ServiceFabricApplicationPackage supprime le package de l’emplacement de chargement temporaire.
  2. Unregister-ServiceFabricApplicationType libère de l’espace de stockage en supprimant les fichiers de type d’application du service de stockage d’images et de tous les nœuds. Par défaut, le gestionnaire de suppression s’exécute toutes les heures.
  3. CleanupUnusedApplicationTypes nettoie automatiquement les anciennes versions inutilisées des applications. 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage supprime les anciens fichiers binaires d’installation du runtime inutilisés.

Notes

Une fonctionnalité est en cours de développement pour permettre à Service Fabric de supprimer les dossiers d’application une fois l’application évacuée du nœud.

Étapes suivantes

Pour plus d'informations sur le développement, le test et la gestion des services et des applications Service Fabric, consultez :