Utiliser Consul en tant que fournisseur d’appartenances

Consul est une plateforme de découverte de services distribuée, hautement disponible et prenant en charge les centres de données. Elle comprend l’inscription simple des services, la vérification d’intégrité, la détection de défaillances et le stockage de données clé-valeur. Elle repose sur le principe suivant : chaque nœud du centre de données exécute un agent Consul, qui agit en tant que serveur ou client. Chaque agent communique via un protocole Gossip évolutif.

Vous trouverez une vue d’ensemble détaillée de Consul, notamment des comparaisons avec des solutions similaires, ici.

Consul est écrit en Go et est open source. Les téléchargements compilés sont disponibles pour macOS X FreeBSD, Linux, Solaris et Windows

Pourquoi choisir Consul ?

En tant que fournisseur d’appartenances Orleans, Consul est un bon choix quand vous devez fournir une solution locale qui n’oblige pas vos clients potentiels à disposer d’une infrastructure existante et d’un fournisseur informatique coopératif. Consul est un exécutable unique léger, qui n’a aucune dépendance et peut donc facilement être intégré à votre solution middleware (intergiciel). Quand Consul est votre solution pour la découverte, la vérification et la maintenance de vos microservices, il est logique de l’intégrer complètement à l’appartenance Orleans pour des raisons de simplicité et de facilité d’utilisation. Il existe également une table d’appartenance dans Consul (également appelée « Magasin système personnalisé Orleans »), qui s’intègre entièrement à la Gestion des clusters d’Orleans.

Configurer Consul

Il existe une documentation complète sur Consul.io concernant la configuration d’un cluster Consul stable. Il n’est donc pas utile de la répéter ici. Cependant, pour des raisons de commodité, nous avons inclus ce guide pour vous permettre de faire fonctionner rapidement Orleans avec un agent Consul autonome.

  1. Créez un dossier dans lequel installer Consul (par exemple C:\Consul).

  2. Créez un sous-dossier : C:\Consul\Data (Consul ne le crée pas s’il n’existe pas).

  3. Téléchargez et décompressez Consul.exe dans C:\Consul.

  4. Ouvrez une invite de commandes dans C :\Consul, puis exécutez la commande suivante :

    ./consul.exe agent -server -bootstrap -data-dir "C:\Consul\Data" -client='0.0.0.0'
    

    Dans la commande précédente :

    • agent : indique à Consul d’exécuter le processus d’agent qui héberge les services. Sans ce commutateur, le processus Consul tente d’utiliser RPC pour configurer un agent qui s’exécute.
    • -server : définit l’agent en tant que serveur et non en tant que client (un client Consul est un agent qui héberge la totalité des services et des données, mais qui n’a aucun droit de vote pour décider, et qui ne peut pas devenir le leader du cluster.
    • -bootstrap : le premier (et seulement le premier !) nœud d’un cluster doit avoir démarré pour pouvoir prendre la direction du cluster.
    • -data-dir [path] : spécifie le chemin où toutes les données de Consul sont stockées, notamment la table d’appartenance du cluster.
    • -client='0.0.0.0' : indique à Consul l’adresse IP sur laquelle ouvrir le service.

    Il existe de nombreux autres paramètres ainsi que la possibilité d’utiliser un fichier config JSON. Pour obtenir la liste complète des options, consultez la documentation Consul.

  5. Vérifiez que Consul est en cours d’exécution et qu’il est prêt à accepter les demandes d’appartenance d’Orleans en ouvrant le point de terminaison des services dans votre navigateur à l’adresse http://localhost:8500/v1/catalog/services. Quand il fonctionne correctement, le navigateur affiche le code JSON suivant :

    {
        "consul": []
    }
    

Configurer Orleans

Pour configurer Orleans afin d’utiliser Consul comme fournisseur d’appartenances, votre projet de silo doit référencer le package NuGet Microsoft.Orleans.Clustering.Consul. Une fois cette opération effectuée, vous pouvez configurer le fournisseur d’appartenance dans le fichier Program.cs de votre silo comme suit :

IHostBuilder builder = Host.CreateDefaultBuilder(args)
    .UseOrleans(silo =>
    {
        silo.UseConsulSiloClustering(options =>
        {
            // The address of the Consul server
            var address = new Uri("http://localhost:8500");
            options.ConfigureConsulClient(address);
        });
    })
    .UseConsoleLifetime();

using IHost host = builder.Build();
host.Run();

Le code précédent :

Pour configurer le client, référencez le même package NuGet et appelez la méthode d’extension UseConsulClientClustering.

Kit de développement logiciel (SDK) client

Si vous souhaitez utiliser Consul pour la découverte de vos services, il existe des kits SDK clients pour les langages les plus populaires.

Détails de l’implémentation

Le fournisseur de tables d’appartenance utilise la fonctionnalité de magasin de données clé-valeur de Consul avec les opérations CAS (Vérifier et définir). Lorsque chaque silo démarre, il enregistre deux entrées clé-valeur, l’une qui contient les détails du silo, et l’autre qui contient la dernière fois que le silo a signalé qu’il était actif. Cela dernier point fait référence aux entrées de diagnostic « Je suis actif » et non aux pulsations de détection de défaillance, qui sont envoyées directement entre les silos et qui ne sont pas écrites dans la table. Toutes les écritures dans la table sont effectuées via des opérations CAS pour permettre le contrôle de la concurrence, comme le nécessite le protocole de gestion des clusters d’Orleans.

Une fois le silo en cours d’exécution, vous pouvez voir ces entrées dans votre navigateur web à l’adresse http://localhost:8500/v1/kv/?keys&pretty. Elles ressemblent à ceci :

[
    "orleans/default/192.168.1.11:11111@43165319",
    "orleans/default/192.168.1.11:11111@43165319/iamalive",
    "orleans/default/version"
]

Toutes les clés sont précédées de orleans, qui est codé en dur dans le fournisseur et est destiné à éviter toute collision d’espace de clés avec d’autres utilisateurs de Consul. Vous pouvez utiliser n’importe laquelle de ces clés pour récupérer des informations supplémentaires. Chacune de ces clés peut être lue en ajoutant son nom de clé (sans guillemets) à la racine consul KV à l’adresse http://localhost:8500/v1/kv/. Ainsi, vous obtenez le JSON suivant :

[
    {
        "LockIndex": 0,
        "Key": "orleans/default/192.168.1.11:11111@43165319",
        "Flags": 0,
        "Value": "[BASE64 UTF8 Encoded String]",
        "CreateIndex": 321,
        "ModifyIndex": 322
    }
]

Le décodage de la chaîne Value encodée en UTF-8 Base64 vous donne les données d’appartenance réelles Orleans :

http://localhost:8500/v1/KV/orleans/default/[SiloAddress]

{
    "Hostname": "[YOUR_MACHINE_NAME]",
    "ProxyPort": 30000,
    "StartTime": "2023-05-15T14:22:00.004977Z",
    "Status": 3,
    "SiloName": "Silo_fcad0",
    "SuspectingSilos": []
}

http://localhost:8500/v1/KV/orleans/default/[SiloAddress]/IAmAlive

"2023-05-15T14:27:01.1832828Z"

Quand les clients se connectent, ils lisent les informations du magasin de données KV de tous les silos du cluster dans un HTTP GET à l’aide de l’URI http://192.168.1.26:8500/v1/KV/orleans/default/?recurse.

Limites

Il existe quelques limitations à connaître lors de l’utilisation de Consul en tant que fournisseur d’appartenances.

Protocole d’appartenance étendu d’Orleans (version et ETag de la table)

Le magasin de données KV de Consul ne prend pas en charge les mises à jour atomiques. Ainsi, Consul, le fournisseur d’appartenances d’Orleans, implémente seulement le protocole d’appartenance de base d’Orleans, comme décrit dans Gestion des clusters d’Orleans, et il ne prend pas en charge le protocole d’appartenance étendu. Ce protocole étendu a été introduit en tant que validation supplémentaire (mais non essentielle) de la connectivité des silos, et en tant que base d’une fonctionnalité qui n’a pas encore été implémentée.

Plusieurs centres de données

Les paires clé-valeur dans Consul ne sont pas répliquées entre les centres de données Consul pour le moment. Il existe un projet distinct pour résoudre cet effort de réplication, mais il n’a pas encore été prouvé qu’il prend en charge Orleans.

En cas d’exécution sur Windows

Quand Consul démarre sur Windows, il journalise le message suivant :

==> WARNING: Windows is not recommended as a Consul server. Do not use in production.

Ce message d’avertissement s’affiche en raison d’un nombre insuffisant de tests menés dans un environnement d’exécution Windows, et non pour de réels problèmes connus. Lisez cette discussion avant de décider si Consul est le bon choix pour vous.

Améliorations futures potentielles

  1. Prouver que le projet de réplication des clés-valeurs de Consul peut prendre en charge un cluster Orleans dans un environnement WAN entre plusieurs centres de données Consul.
  2. Implémenter la table de rappel dans Consul.
  3. Implémenter le protocole d’appartenance étendu. L’équipe responsable de Consul prévoit d’implémenter les opérations atomiques. Une fois cette fonctionnalité disponible, il sera possible de supprimer les limitations du fournisseur.