Une seule chaîne de connexion, n'importe quelle plateforme : se connecter à Zaris

La moitié des bugs de connexion « fonctionne en développement, casse en production » se résument à la même chose : les détails de connexion ont été orthographiés de trois façons différentes à trois endroits différents. Le appsettings.json avait une liste d'hôtes, le runbook d'exploitation en a collé une autre dans une session PowerShell, et la chaîne copiée d'un wiki avait un token périmé incrusté en dur.

Zaris élimine toute cette catégorie de problèmes avec un format de chaîne de connexion unique et indépendant de la plateforme. La même chaîne exacte fonctionne quand votre application .NET la lit depuis la configuration, quand un opérateur la passe à une cmdlet PowerShell, et quand quelqu'un la copie directement depuis la console web. Une orthographe canonique, partout.

Cet article décompose la chaîne partie par partie, montre les trois façons de l'utiliser, et plaide pour la seule règle qui compte le plus en production : ne jamais mettre un token brut dans la chaîne.

La forme de la chaîne

Une chaîne de connexion Zaris est un URI. En voici une complète :

zariss://zaris-a.example.com:7861,zaris-b.example.com:7861/?store=orders&token=env:ZARIS_TOKEN

Chaque partie remplit un rôle :

• Schéma → sécurité du transport. zaris:// est en clair ; zariss:// est en TLS (le s supplémentaire, même convention que http/https). Le choix du schéma est la façon d'activer le chiffrement du transport — il n'y a pas de drapeau séparé à oublier.
• Hôtes séparés par des virgules → liste de basculement / d'amorçage. Vous pouvez lister plus d'un host:port, et le client les traite comme une liste d'amorçage pour le basculement. Il se connecte via l'amorce qui répond et découvre le reste du cluster à partir de là, de sorte qu'un seul nœud indisponible au démarrage ne vous bloque pas.
• Un nom de store obligatoire. Chaque connexion cible exactement un store, et le nom du store est obligatoire — il n'y a pas de valeur par défaut implicite. C'est délibéré : cela signifie qu'une chaîne indique toujours à quel store elle est destinée, et vous ne pouvez pas accidentellement pointer un job vers le mauvais parce que la cible aurait été laissée vide.
• Un token fourni en toute sécurité. Les tokens d'authentification sont des secrets, donc le format les garde hors de la chaîne littérale. Au lieu de coller le token, vous indiquez où le lire — token=env:ZARIS_TOKEN le lit depuis une variable d'environnement, et token=file:/path/to/token le lit depuis un fichier sur disque. Le secret ne se trouve jamais dans la chaîne elle-même, donc il n'atterrit jamais dans un contrôle de source, un historique de shell ou une capture d'écran.

Ce dernier point est celui qu'il vaut la peine d'intérioriser : la chaîne porte une référence vers l'identifiant, et non l'identifiant.

L'utiliser depuis .NET

Les applications .NET lisent la chaîne depuis la configuration standard ConnectionStrings — le même mécanisme appsettings.json / IConfiguration que vous utilisez déjà pour les bases de données. Placez-la là où vivent toutes les autres chaînes de connexion :

{
  "ConnectionStrings": {
    "Orders": "zariss://zaris-a.example.com:7861,zaris-b.example.com:7861/?store=orders&token=env:ZARIS_TOKEN"
  }
}

Puis lisez-la via la configuration comme n'importe quoi d'autre :

var connectionString = builder.Configuration.GetConnectionString("Orders");
var store = await ZarisStore.ConnectAsync(connectionString);

Comme le token est env:ZARIS_TOKEN, le appsettings.json versionné est sûr à committer — il nomme la variable d'environnement plutôt que de contenir le secret. Chaque environnement fournit son propre ZARIS_TOKEN, et la chaîne reste identique de l'ordinateur portable d'un développeur aux pods de production.

L'utiliser depuis PowerShell

Les cmdlets d'administration prennent la chaîne identique. Connect-ZrStore l'accepte directement avec -ConnectionString :

$conn = "zariss://zaris-a.example.com:7861,zaris-b.example.com:7861/?store=orders&token=env:ZARIS_TOKEN"
Connect-ZrStore -ConnectionString $conn

Notez qu'il s'agit de la même chaîne que celle qui se trouve dans appsettings.json. Un opérateur qui débogue un problème de production et un service qui s'exécute en production pointent vers le cluster exactement de la même manière — aucune étape de traduction où une différence subtile dans la liste d'hôtes ou le nom du store pourrait se glisser. L'indirection env: fonctionne ici aussi : définissez ZARIS_TOKEN dans l'environnement du shell et la cmdlet le résout au moment de la connexion.

Copiez-la directement depuis la console

La troisième source est la console web. Pour chaque store, la console affiche une chaîne de connexion copiable — une chaîne correcte, déjà orthographiée de façon canonique, avec les bons hôtes et le bon nom de store renseignés. Un opérateur qui doit se connecter n'assemble pas un URI de mémoire ; il copie la chaîne générée par la console et la colle dans la configuration de son application ou dans un appel Connect-ZrStore.

Cela boucle la boucle. La console produit la chaîne canonique, la configuration .NET la consomme, et PowerShell la consomme — trois surfaces, un format, aucune ré-orthographe.

La seule règle pour la production

Utilisez toujours l'indirection de token env: ou file: dans les déploiements réels. Ne collez jamais un token brut dans la chaîne.

Il est tentant, lors d'un test rapide, d'incruster l'identifiant juste pour voir que cela marche. Le problème est ce qui se passe ensuite : cette chaîne est copiée dans un fichier de configuration, committée, partagée dans un chat ou déposée dans un ticket — et désormais un identifiant actif se trouve quelque part où il ne devrait pas être, sans moyen simple de savoir partout où il a fuité. Les formes env: et file: existent précisément pour que la chaîne fonctionnelle et le secret voyagent séparément :

# Good — the secret lives in the environment, the string references it
zariss://zaris-a.example.com:7861/?store=orders&token=env:ZARIS_TOKEN

# Good — the secret lives in a mounted file, the string references it
zariss://zaris-a.example.com:7861/?store=orders&token=file:/var/run/secrets/zaris-token

Dans Kubernetes, file: s'associe naturellement à un secret monté ; dans une VM ou un conteneur, env: s'associe à ce qui injecte les variables d'environnement. Dans tous les cas, faire tourner le token revient à changer le secret, et non à éditer chaque chaîne de connexion.

Le bénéfice

Une seule chaîne canonique signifie un seul endroit où bien faire et une seule chose à raisonner. La liste d'hôtes, le choix TLS, le store et la source de l'identifiant sont tous encodés de la même manière, que le lecteur soit la configuration .NET, une cmdlet PowerShell ou un humain qui copie depuis la console. C'est ainsi que vous retirez le bug de connexion « fonctionne en développement, casse en production » : il n'existe tout simplement pas de deuxième orthographe de la connexion avec laquelle la production pourrait être en désaccord.