Exécuter Keyright auto-hébergé sur plusieurs nœuds pour la haute disponibilité

Un serveur de licences a une tâche ingrate mais impitoyable : il se trouve sur le chemin d’activation de vos clients, et lorsqu’il est injoignable au mauvais moment, quelqu’un ne peut pas démarrer le logiciel qu’il a payé. Une bonne conception côté client atténue cela avec la grâce hors ligne — un bail en cache couvre une brève panne — mais « brève » porte beaucoup de poids dans cette phrase. Si votre unique nœud de licences est hors service pendant un après-midi de correctifs, ou si sa VM est en cours de migration, ou s’il est simplement tombé, vous comptez sur le fait que la fenêtre de grâce de chaque client soit plus longue que votre panne. Ce n’est pas un plan. La haute disponibilité, si.

La bonne nouvelle, c’est que rendre Keyright auto-hébergé hautement disponible est presque anticlimatique, parce que l’application a été conçue pour cela. Cet article explique précisément pourquoi, et comment monter un déploiement à deux ou trois nœuds.

À retenir : Keyright auto-hébergé est un service ASP.NET Core sans état — tout l’état vit dans votre PostgreSQL — si bien que la haute disponibilité se résume à exécuter deux ou trois réplicas derrière un répartiteur de charge sans affinité de session. Ce qu’il faut réellement rendre hautement disponible, c’est Postgres. La HA multinœud est un déploiement Pro ou Enterprise (tous deux couvrent jusqu’à trois nœuds de production) ; Standard couvre un seul nœud.

Pourquoi un serveur de licences a besoin de HA dès le départ

Pensez à l’endroit où se situe réellement le service. Chaque nouvelle activation, chaque réclamation de siège, chaque revérification en ligne d’un bail passe par lui. Pour la plupart de vos clients, ce trafic est irrégulier et invisible — jusqu’au moment où il ne l’est plus, parce que quelqu’un met en service une nouvelle machine, ou qu’un bail a expiré et que le client le renouvelle. Si le serveur est en panne à ce moment-là, cette personne précise est bloquée, et être-bloqué-à-l’activation est le pire moment possible pour l’être. Cela devient un ticket de support en quelques minutes.

Vous atténuez déjà le cas courant avec la validation hors ligne entre les activations et les fenêtres de grâce en cas de panne. La HA, c’est l’autre moitié : au lieu d’espérer qu’une panne reste à l’intérieur de la grâce de chacun, vous supprimez le point de défaillance unique pour qu’il n’y ait plus de panne à gracier. Deux nœuds signifient que l’un peut mourir, recevoir des correctifs ou être replanifié tandis que l’autre continue de répondre.

L’architecture qui rend cela facile

Keyright auto-hébergé a exactement deux pièces mobiles : une application sans état, et votre base de données.

L’application est l’image ghcr.io/delta1-labs/keyright — un service ASP.NET Core à l’écoute sur le port 8080. L’image est application seule : il n’y a pas de base de données à l’intérieur. Elle ne conserve aucun état entre les requêtes. Licences, activations, sièges, crédits, journal d’audit, clés de signature — tout cela vit dans PostgreSQL, vers lequel vous pointez l’application avec la chaîne de connexion KEYRIGHT_DB. L’application crée et migre son propre schéma au premier démarrage ; il n’y a donc aucun SQL à exécuter à la main.

Cette unique décision de conception — application sans état, tout l’état dans votre base de données — est ce qui rend la HA triviale. Comme rien n’est épinglé à un processus particulier, vous pouvez exécuter autant de copies de l’application que vous voulez, et n’importe quelle copie peut répondre à n’importe quelle requête. Pas de session en mémoire, pas de cache de vérité local au nœud, rien à perdre quand un nœud disparaît. Faire passer l’application à l’échelle, c’est juste exécuter le même conteneur plus d’une fois.

Exécuter plusieurs réplicas

Si vous êtes sur Docker Compose, mettre à l’échelle la couche applicative est un drapeau :

docker compose up -d --scale keyright=3

Cela vous donne trois conteneurs d’application identiques, tous lisant le même KEYRIGHT_DB et portant tous la même configuration. Placez un répartiteur de charge devant (ci-dessous) et vous avez un déploiement à trois nœuds.

Sur Kubernetes avec le chart Helm, c’est une valeur :

# values.yaml
replicaCount: 3

helm upgrade --install keyright delta1/keyright -f values.yaml

Kubernetes planifie trois pods, le Service répartit la charge entre eux, et comme les pods sont sans état, vous pouvez les ajouter ou les drainer librement. Répartissez-les entre nœuds ou zones de disponibilité avec une anti-affinité de pods si vous voulez survivre à la perte d’une machine ou d’une zone entière.

Une chose reste identique sur chaque réplica : la clé d’auto-licence. Keyright est fail-closed — il a besoin d’une clé d’auto-licence (ou d’essai) valide pour servir le moindre trafic — et chaque nœud s’exécute avec la même clé. Il n’y a pas d’enregistrement par nœud ni de poignée de main de décompte de nœuds ; un renouvellement ou un changement d’édition revient simplement à échanger la clé dans votre configuration et à redémarrer les nœuds. Déployer la clé est un changement de configuration, pas une danse de licensing.

Le répartiteur de charge et les sondes de santé

Placez n’importe quel répartiteur de charge HTTP devant les nœuds d’application — le répartiteur L7 de votre cloud, un contrôleur d’ingress, nginx, HAProxy, ce que vous exploitez déjà. Deux choses à bien faire :

Pas d’affinité de session. N’activez pas les sessions persistantes. Comme l’application est sans état et que les clients valident hors ligne entre les activations, il n’y a rien d’attaché à un nœud que l’affinité devrait préserver. Envoyez n’importe quelle requête à n’importe quel nœud. Activer l’affinité ne fait que concentrer la charge et ruine l’intérêt. La concurrence entre nœuds est sûre sans elle : les sièges et les crédits utilisent une vérification-et-déduction sérialisable dans Postgres, de sorte que deux nœuds ne peuvent physiquement pas dépenser deux fois le même siège ni le même solde.

Sondes de santé. Keyright expose deux points de terminaison précisément pour cela :

• GET /health — liveness. Un 200 statique qui ne sort jamais un nœud du pool pour un hoquet transitoire de la base de données. Utilisez-le pour décider si le processus est vivant.
• GET /health/ready — readiness. Celui-ci vérifie aussi la connectivité à la base de données et renvoie 503 lorsque Postgres est injoignable. Utilisez-le pour décider si un nœud doit recevoir du trafic.

Une sonde de répartiteur typique :

health check: GET /health/ready   interval 10s   healthy 2   unhealthy 3

Terminez TLS au répartiteur et transmettez X-Forwarded-For (l’IP réelle du client) et X-Forwarded-Proto (pour que le tableau de bord et le portail génèrent des URL https) — l’application honore les deux. N’exposez publiquement que le :443 via le répartiteur ; gardez /admin/* et /internal/* joignables uniquement depuis l’intérieur de votre réseau. Vos clients n’ont jamais besoin que du chemin /v1/*.

PostgreSQL est le véritable goulot d’étranglement

Voici la partie que les gens prennent à l’envers. Mettre à l’échelle l’application est quasiment gratuit ; ce n’est donc pas là que votre attention devrait aller. Ce qui doit être fiable — et ce qui limite réellement jusqu’où vous passez à l’échelle — c’est PostgreSQL, parce que c’est là que vit chaque octet d’état.

Investissez donc là. Pour tout ce qui dépasse l’évaluation, n’exécutez pas la base de données intégrée que les kits proposent par commodité ; pointez KEYRIGHT_DB vers un Postgres géré ou hautement disponible — un primaire avec un secondaire, un basculement automatique et de vraies sauvegardes. Une application sans état devant une unique base de données fragile n’est pas hautement disponible ; vous avez simplement descendu le point de défaillance unique d’une couche. Faites de la base de données le composant HA et la couche applicative suit gratuitement. À très grande échelle (vers les millions de licences actives), ajoutez PgBouncer pour le pooling de connexions et donnez plus de cœurs à Postgres — le guide de mise à l’échelle dans la documentation d’exploitation propose un dimensionnement concret par niveau.

La raison pour laquelle l’application peut se permettre d’être si légère, c’est la forme de la charge de travail. Le chemin chaud — /v1/activate et /v1/validate — est une vérification de signature plus un décompte de sièges, et les clients mettent en cache un bail signé et valident hors ligne entre les activations. Vous ne recevez pas une requête HTTP à chaque lancement de l’application ; vous en recevez une à l’activation, puis périodiquement quand un bail se renouvelle. C’est une charge petite, irrégulière et légère en CPU, ce qui explique exactement pourquoi deux ou trois nœuds modestes couvrent confortablement un déploiement avec des centaines de milliers de licences actives.

Un bonus gratuit : les mises à jour sans interruption

Une fois que vous exécutez 2+ nœuds, les mises à jour cessent d’être une panne. Comme l’application est rétrocompatible au sein d’une ligne mineure et que les migrations s’appliquent automatiquement au démarrage, vous pouvez renouveler un nœud à la fois : drainez-le, tirez la nouvelle image, laissez-le revenir et passer ready, puis passez au suivant. Le répartiteur continue de servir depuis les nœuds sains tout du long. La même propriété qui vous donne la HA face à la défaillance vous donne la HA face à la maintenance — qui, en pratique, est la panne que vous planifiez effectivement le plus souvent.

Quelle édition vous faut-il

Keyright auto-hébergé est facturé par déploiement, et les éditions diffèrent par le nombre de nœuds :

• Standard couvre un seul nœud de production — très bien pour un déploiement simple, mais par définition pas hautement disponible.
• Pro et Enterprise couvrent tous deux jusqu’à trois nœuds de production — ce qu’exige la HA multinœud.

Standard et Pro exécutent le même exact moteur de fonctionnalités ; le nombre de nœuds est la seule chose qui les sépare, si bien que « je veux de la HA » est simplement une raison d’être sur Pro plutôt que sur Standard. Enterprise ajoute le SSO, la personnalisation en marque blanche et les blocs de crédit isolés (air-gapped) par-dessus la même allocation de trois nœuds. Le nombre de nœuds est une clause contractuelle — le logiciel ne compte ni n’impose les nœuds, et la même clé d’auto-licence s’exécute sur tous les réplicas. Consultez les tarifs pour les chiffres actuels.

Où Keyright s’inscrit

Comme Keyright est un seul produit dans les deux modes de déploiement, l’architecture application-sans-état-plus-votre-base-de-données est la même que vous évaluiez sur un ordinateur portable ou que vous exécutiez trois nœuds en production — rien dans votre intégration ne change à mesure que vous passez à l’échelle. Si vous hésitez encore à auto-héberger, les compromis entre auto-hébergé et cloud exposent la décision, et si vous quittez un système maison, migrer sans casser vos clients est le mode d’emploi. Quand vous serez prêt à monter la HA, le guide d’exploitation contient les détails de sauvegarde, de mise à jour et de dimensionnement qui transforment deux nœuds en marche en un déploiement de production derrière lequel vous pouvez dormir tranquille.