Partager via

Service DNS dans Azure Service Fabric

  • Article

Le service DNS est un service système facultatif que vous pouvez activer dans votre cluster pour détecter d’autres services utilisant le protocole DNS.

De nombreux services, en particulier les services en conteneur, sont adressables via une URL préexistante. Il est souhaitable d’être en mesure de résoudre ces services à l’aide du protocole DNS standard, plutôt qu’avec le protocole Service Fabric Naming Service. Le service DNS vous permet de mapper les noms DNS à un nom de service et, par conséquent, de résoudre les adresses IP des points de terminaison. Cette fonctionnalité conserve la portabilité des services en conteneur sur différentes plateformes et peut simplifier les scénarios de type « lift and shift », en vous laissant utiliser des URL de service existantes sans réécrire le code pour tirer parti du Service de nommage.

Le service DNS mappe les noms DNS aux noms de service, qui sont à leur tour résolus par le service de nommage pour retourner le point de terminaison de service. Le nom DNS du service est fourni au moment de la création. Le schéma suivant illustre le mode de fonctionnement du service DNS pour des services sans état. Par souci de concision, les diagrammes n’affichent qu’un seul point de terminaison pour les services, bien que chaque service puisse avoir plusieurs points de terminaison.

Diagramme montrant comment les noms DNS sont mappés aux noms de service par le service DNS pour les services sans état.

À compter de la version 6.3 de Service Fabric, le protocole DNS de Service Fabric a été étendu pour inclure un schéma d’adressage des services partitionnés avec état. Ces extensions permettent de résoudre des adresses IP de partition spécifiques à l’aide d’une combinaison composée à la fois du nom DNS du service avec état et du nom de la partition. Les trois schémas de partitionnement sont pris en charge :

  • Partitionnement nommé
  • Partitionnement par plages de valeurs
  • Partitionnement singleton

Le schéma suivant montre le fonctionnement du service DNS pour des services partitionnés avec état.

Diagramme montrant comment les noms DNS sont mappés aux noms de service par le service DNS pour les services sans état partitionnés.

Pour plus d’informations sur les requêtes partitionnée, reportez-vous à la section ci-dessous.

Prise en charge du système d’exploitation

Le service DNS est pris en charge sur les clusters Windows et Linux, bien que la prise en charge de Linux soit actuellement limitée aux services conteneurisés et ne puisse pas être activée via Portail Azure. Toutefois, Windows prend en charge tous les types de services et modèles de déploiement.

Activer le service DNS

Notes

L’activation du service DNS remplace certains paramètres DNS sur les nœuds. Si vous rencontrez des problèmes lors de la connexion à Internet, vérifiez vos paramètres DNS.

Nouveaux clusters

Clusters utilisant des modèles ARM

Pour déployer un nouveau cluster avec des modèles ARM, vous pouvez utiliser les exemples de modèles ou écrire les vôtres. Si ce n’est pas déjà fait, le service DNS peut être activé dans les modèles à l’aide des versions d’API minimales prises en charge et en ajoutant les paramètres appropriés. Vous trouverez plus d’informations sur la façon de procéder ci-dessous dans les points 1 et 2 de la liste numérotée.

Clusters utilisant Portail Azure

Si vous créez un cluster standard dans le portail, le service DNS est activé par défaut dans l’option Inclure le service DNS sous la section Ajouter des fonctionnalités.

Capture d’écran de l’activation du service DNS pour un cluster standard via le portail.

Si vous créez un cluster managé dans le portail, le service DNS est activé par défaut dans l’option service DNS sous la section Ajouter des fonctionnalités.

Capture d’écran de l’activation du service DNS pour un cluster managé via le portail.

Clusters existants

Si vous mettez à jour un cluster managé existant pour activer le service DNS, vous pouvez le faire à partir du portail en accédant à la page Services complémentaires à partir de la page des ressources de cluster. Sinon, vous pouvez activer le service DNS à l’aide d’autres méthodes référencées ci-dessous :

  • Utilisez le modèle ARM utilisé pour déployer le cluster, le cas échéant.
  • Accédez au cluster sur Azure Resource Explorer et mettez à jour la ressource de cluster, comme indiqué dans les étapes ci-dessous (à partir de l’étape 2 et ultérieure).
  • Accédez au cluster sur le portail, puis cliquez sur Exporter le modèle. Pour plus d’informations, consultez Exportation du modèle à partir d’un groupe de ressources.

Une fois que vous avez un modèle, vous pouvez activer le service DNS en effectuant les étapes suivantes :

  1. Pour les clusters standards, vérifiez que apiVersion a la valeur 2017-07-01-preview ou plus pour la ressource Microsoft.ServiceFabric/clusters ; dans le cas contraire, procédez à une mise à jour comme indiqué dans l’exemple suivant :

    {
    "apiVersion": "2017-07-01-preview",
    "type": "Microsoft.ServiceFabric/clusters",
    "name": "[parameters('clusterName')]",
    "location": "[parameters('clusterLocation')]",
    ...
}

    Pour les clusters managés, vérifiez que apiVersion a la valeur 2020-01-01-preview ou plus pour la ressource Microsoft.ServiceFabric/managedClusters ; dans le cas contraire, procédez à une mise à jour comme indiqué dans l’exemple suivant :

    {
    "apiVersion": "2020-01-01-preview",
    "type": "Microsoft.ServiceFabric/managedClusters",
    "name": "[parameters('clusterName')]",
    "location": "[parameters('clusterLocation')]",
    ...
}

  2. Vous pouvez maintenant activer le service DNS en procédant de l’une des manières suivantes :

    • Pour activer le service DNS avec les paramètres par défaut, ajoutez-le à la section addonFeatures à l’intérieur de la section properties, comme indiqué dans l’exemple suivant :

      "properties": {
  ...
  "addonFeatures": [
    "DnsService"
    ],
  ...
}

    • Pour activer le service avec d’autres paramètres que les paramètres par défaut, ajoutez une section DnsService à la section fabricSettings à l’intérieur de la section properties. Dans ce cas, vous n’avez pas besoin d’ajouter le DnsService à addonFeatures. Pour en savoir plus sur les propriétés que vous pouvez définir pour le service DNS, consultez les Paramètres du service DNS.

      "properties": {
 ...
 "fabricSettings": [
   ...
   {
     "name": "DnsService",
     "parameters": [
       {
         "name": "IsEnabled",
         "value": "true"
       },
       {
         "name": "<key>",
         "value": "<value>"
       }
     ]
   },
   ...
 ]
}

  3. Après avoir mis à jour le modèle de cluster avec ces modifications, appliquez-les et laissez la mise à niveau s’accomplir. Une fois la mise à niveau terminée, le service DNS démarre votre cluster. Le nom du service est fabric:/System/DnsService. Il est mentionné dans la section Système de Service Fabric explorer.

Notes

Lors de la mise à niveau du DNS de désactivé à activé, Service Fabric Explorer peut ne pas refléter le nouvel état. Pour résoudre ce problème, redémarrez les nœuds en modifiant la stratégie de mise à niveau dans votre modèle.

Configuration du nom DNS de votre service

Vous pouvez définir des noms DNS pour vos services avec des modèles ARM, avec des services par défaut dans le fichier ApplicationManifest.xml ou avec des commandes PowerShell.

Le nom DNS de votre service ne peut pas être résolu au sein du cluster, c’est pourquoi il est important de garantir l’unicité du nom DNS au sein du cluster.

Nous vous recommandons vivement d’utiliser un schéma de nommage <ServiceName>.<AppName>, par exemple service1.application1. Si une application est déployée à l’aide de Docker Compose, des noms DNS sont affectés automatiquement aux services à l’aide de ce schéma de nommage.

Définition du nom DNS avec le modèle ARM

Si vous utilisez des modèles ARM pour déployer vos services, vous pouvez ajouter la propriété serviceDnsName à la section appropriée et lui attribuer une valeur. Vous trouverez des exemples ci-dessous :

Clusters standard

Pour les clusters standards, vérifiez que apiVersion a la valeur 2019-11-01-preview ou plus pour la ressource Microsoft.ServiceFabric/clusters/applications/services ; dans le cas contraire, procédez à une mise à jour comme indiqué dans l’exemple suivant :

{
  "apiVersion": "2019-11-01-preview",
  "type": "Microsoft.ServiceFabric/clusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/clusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "provisioningState": "Default",
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "correlationScheme": [],
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "serviceDnsName": "[parameters('serviceDnsName')]"
  }
}

Clusters managés

Pour les clusters managés, vérifiez que apiVersion a la valeur 2022-10-01-preview ou plus pour la ressource Microsoft.ServiceFabric/managedclusters/applications/services ; dans le cas contraire, procédez à une mise à jour comme indiqué dans l’exemple suivant :

{
  "apiVersion": "2022-10-01-preview",
  "type": "Microsoft.ServiceFabric/managedclusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "correlationScheme": [],
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "serviceDnsName": "[parameters('serviceDnsName')]"
  }
}

Définition du nom DNS pour un service par défaut du paramètre dans le fichier ApplicationManifest.xml

Ouvrez votre projet dans Visual Studio ou dans votre éditeur favori, puis ouvrez le fichier ApplicationManifest.xml. Accédez à la section des services par défaut puis, pour chaque service, ajoutez l’attribut ServiceDnsName. L’exemple suivant montre comment définir le nom DNS du service sur stateless1.application1

<Service Name="Stateless1" ServiceDnsName="stateless1.application1">
  <StatelessService ServiceTypeName="Stateless1Type" InstanceCount="[Stateless1_InstanceCount]">
    <SingletonPartition />
  </StatelessService>
</Service>

L’exemple suivant définit sur stateful1.application1 le nom DNS d’un service avec état. Le service utilise un schéma de partitionnement nommé. Notez que les noms de partition sont en minuscules. Il est nécessaire de respecter la casse pour les partitions qui seront ciblés dans les requêtes DNS ; pour plus d’informations, consultez la section Exécution de requêtes DNS sur une partition de service avec état.

<Service Name="Stateful1" ServiceDnsName="stateful1.application1" />
  <StatefulService ServiceTypeName="Stateful1Type" TargetReplicaSetSize="2" MinReplicaSetSize="2">
    <NamedPartition>
      <Partition Name="partition1" />
      <Partition Name="partition2" />
    </NamedPartition>
  </StatefulService>
</Service>

Définition du nom DNS d’un service à l’aide de PowerShell

Vous pouvez définir le nom DNS d’un service lors de sa création à l’aide de la commande PowerShell New-ServiceFabricService. L’exemple suivant permet de créer un service sans état avec le nom DNS stateless1.application1 :

New-ServiceFabricService `
    -Stateless `
    -PartitionSchemeSingleton `
    -ApplicationName fabric:/application1 `
    -ServiceName fabric:/application1/stateless1 `
    -ServiceTypeName Stateless1Type `
    -InstanceCount 1 `
    -ServiceDnsName stateless1.application1

Vous pouvez également mettre à jour un service existant à l’aide de la commande PowerShell Update-ServiceFabricService. L’exemple suivant met à jour un service sans état existant pour ajouter le nom DNS stateless1.application1 :

Update-ServiceFabricService `
    -Stateless `
    -ServiceName fabric:/application1/stateless1 `
    -ServiceDnsName stateless1.application1

Vérifiez qu’un nom DNS est défini dans Service Fabric Explorer

Une fois le service déployé avec le nom DNS, Service Fabric Explorer affiche le nom DNS du service, comme illustré dans la figure suivante :

Capture d’écran du nom DNS dans Service Fabric Explorer.

Notes

Cette vue peut être différente en fonction de la version de Service Fabric Explorer utilisée, mais le champ nom DNS doit être visible sous une forme quelconque sur la page du service.

Exécution de requêtes DNS sur une partition de service avec état

À partir de Service Fabric version 6.3, le service DNS prend en charge les requêtes pour les partitions de service. Pour activer la prise en charge des requêtes de service partitionnés, les paramètres du service DNS doivent être mis à jour pour définir l’option EnablePartitionedQuery sur true.

Pour les partitions qui seront utilisées dans les requêtes DNS, les restrictions d’affectation de noms suivantes s’appliquent :

  • Les noms de partition doivent être compatibles avec DNS.
  • Les noms de partition à appellations multiples contenant un point ou «.» ne doivent pas être utilisés.
  • Les noms de partition doivent être en minuscules.

Les requêtes DNS qui ciblent une partition sont formatées comme suit :

    <First-Label-Of-Partitioned-Service-DNSName><PartitionPrefix><Target-Partition-Name><PartitionSuffix>.<Remaining-Partitioned-Service-DNSName>

Où :

  • First-Label-Of-Partitioned-Service-DNSName est la première partie du nom de votre service DNS.
  • PartitionPrefix est une valeur qui peut être définie dans la section DnsService du manifeste du cluster ou via le modèle ARM du cluster. La valeur par défaut est « -- ». Pour plus d’informations, consultez les paramètres du service DNS.
  • Target-Partition-Name est le nom de la partition.
  • PartitionSuffix est une valeur qui peut être définie dans la section DnsService du manifeste du cluster ou via le modèle ARM du cluster. La valeur par défaut est une chaîne vide. Pour plus d’informations, consultez les paramètres du service DNS.
  • Remaining-Partitioned-Service-DNSName est la partie restante du nom DNS de votre service.

Les exemples suivants illustrent des requêtes DNS pour des services partitionnés exécutés sur un cluster qui utilise les paramètres par défaut pour PartitionPrefix et PartitionSuffix :

  • Pour résoudre la partition « 0 » d’un service avec le nom DNS backendrangedschemesvc.application qui utilise un schéma de partitionnement par plages de valeurs, utilisez backendrangedschemesvc--0.application.
  • Pour résoudre la partition « first » d’un service avec le nom DNS backendnamedschemesvc.application qui utilise un schéma de partitionnement nommé, utilisez backendnamedschemesvc--first.application.

Le service DNS renvoie l’adresse IP du point de terminaison associé au réplica principal de la partition. Si aucune partition n’est spécifiée, le service DNS sélectionne une partition de manière aléatoire.

Utilisation de noms DNS dans vos services

Si vous déployez des services avec des noms DNS, vous pouvez trouver l’adresse IP des points de terminaison exposés en référençant le nom DNS. Le service DNS fonctionne pour les services sans état et, à compter de la version 6.3 de Service Fabric, pour les services avec état. Pour les services avec état exécutés sur des versions de Service Fabric antérieures à la version 6.3, vous pouvez utiliser le service de proxy inverse intégré pour les appels HTTP afin d’appeler une partition de service particulière.

Les ports dynamiques ne sont pas pris en charge par le service DNS. Vous pouvez utiliser le service de proxy inverse pour résoudre des services qui utilisent des ports dynamiques.

Le code suivant montre comment appeler un service sans état via DNS. Il s’agit d’un simple appel HTTP standard dans lequel vous fournissez le nom DNS, le port et un chemin d’accès facultatif dans le cadre de l’URL.

public class ValuesController : Controller
{
    // GET api
    [HttpGet]
    public async Task<string> Get()
    {
        string result = "";
        try
        {
            Uri uri = new Uri("http://stateless1.application1:8080/api/values");
            HttpClient client = new HttpClient();
            var response = await client.GetAsync(uri);
            result = await response.Content.ReadAsStringAsync();

        }
        catch (Exception e)
        {
            Console.Write(e.Message);
        }

        return result;
    }
}

Le code suivant montre un appel sur une partition spécifique d’un service avec état. Dans ce cas, le nom DNS contient le nom de la partition (partition1). L’appel suppose que le cluster utilise les valeurs par défaut pour PartitionPrefix et PartitionSuffix.

public class ValuesController : Controller
{
    // GET api
    [HttpGet]
    public async Task<string> Get()
    {
        string result = "";
        try
        {
            Uri uri = new Uri("http://stateful1--partition1.application1:8080/api/values");
            HttpClient client = new HttpClient();
            var response = await client.GetAsync(uri);
            result = await response.Content.ReadAsStringAsync();

        }
        catch (Exception e)
        {
            Console.Write(e.Message);
        }

        return result;
    }
}

Requêtes récursives

Pour les noms DNS que le service DNS ne peut pas résoudre par lui-même (par exemple, un nom DNS public), il transmet la requête aux serveurs DNS récursifs préexistants sur les nœuds.

Diagramme montrant comment les requêtes DNS pour les noms publics sont résolues.

Avant la version 9.0 de Service Fabric, ces serveurs étaient interrogés en série avec un délai d’attente fixe de 5 secondes jusqu’à ce qu’une réponse soit reçue. Si un serveur ne répondait pas dans le délai imparti, le serveur suivant (le cas échéant) était interrogé. Lorsque ces serveurs DNS rencontraient des problèmes, l’exécution des requêtes DNS prenait plus de 5 secondes, ce qui n’était pas idéal.

À partir de la version 9.0 de Service Fabric, une prise en charge des requêtes récursives parallèles a été ajoutée. Avec les requêtes parallèles, tous les serveurs DNS récursifs peuvent être contactés en même temps, la première réponse l’emportant. Cela permet d’obtenir des réponses plus rapides dans le scénario mentionné précédemment. Cette option n'est pas activée par défaut.

Des options précises ont également été introduites dans Service Fabric 9.0 pour contrôler le comportement des requêtes récursives, y compris les délais d’attente et les tentatives d’interrogation. Ces options peuvent être définies dans les paramètres du service DNS :

  • RecursiveQuerySerialMaxAttempts : nombre maximum d’interrogations en série qui seront tentées. Si ce nombre est supérieur à celui des serveurs DNS de transfert, l’interrogation s’arrête une fois que tous les serveurs ont été essayés exactement une fois.
  • RecursiveQuerySerialTimeout : valeur du délai d’attente, en secondes, pour chaque tentative d’interrogation en série.
  • RecursiveQueryParallelMaxAttempts : nombre de tentatives d’interrogations parallèles. Les interrogations parallèles sont exécutées une fois le nombre maximum de tentatives d’interrogations en série épuisé.
  • RecursiveQueryParallelTimeout : valeur du délai d’attente, en secondes, pour chaque tentative d’interrogation parallèle.

Limitations et problèmes connus

  • Les ports dynamiques ne sont pas pris en charge par le service DNS. Pour résoudre des services exposés sur des ports dynamiques, utilisez le service de proxy inverse.
  • La prise en charge de Linux est actuellement limitée aux services conteneurisés. Actuellement, les services basés sur des processus sur Linux ne peuvent pas utiliser le service DNS.
  • Le service DNS pour les clusters Linux ne peut pas être activé via Portail Azure.
  • Si un nom DNS est modifié pour un service, les mises à jour de noms peuvent ne pas être immédiatement visibles dans certains scénarios. Pour résoudre le problème, les instances de service DNS doivent être redémarrées sur le cluster.

Étapes suivantes

Pour en savoir plus sur la communication de service au sein du cluster, consultez l’article Se connecter aux services et communiquer avec eux dans Service Fabric