Licencier un logiciel qui s'exécute sur des agents de CI et de build éphémères sans épuiser les sièges

Les modèles de licence ont surtout été conçus pour des machines qui restent en place — un poste de travail, un serveur, une station. Les agents de CI et de build cloud violent cette hypothèse à dessein : ils existent le temps d’un job puis disparaissent, et le job suivant reçoit une VM ou un conteneur flambant neuf. Pointez une licence verrouillée au nœud sur cet environnement et elle fait exactement l’inverse de ce qu’il faut — chaque build ressemble à une nouvelle machine, s’active, consomme un siège, puis la machine est détruite sans jamais le libérer. Une licence de dix sièges peut être épuisée avant le déjeuner. La solution n’est pas un plus grand décompte de sièges ; c’est de licencier la dimension qui varie réellement.

Pourquoi l’éphémère casse le verrouillage au nœud

Le verrouillage au nœud dérive une empreinte du matériel d’une machine et lie la licence à elle, donc un siège représente un appareil distinct. C’est exactement juste pour les postes de travail et exactement faux pour le calcul éphémère, où « appareil distinct » est une unité dénuée de sens — il y en a un nouveau toutes les quelques minutes, aucun ne dure, et ce que vous voulez vraiment limiter n’est pas combien de machines mais combien d’usage concurrent (ou total).

Pire, l’hypothèse de nettoyage échoue aussi. Les sièges verrouillés au nœud sont normalement libérés par une désactivation explicite quand un utilisateur change de machine. Un runner de CI n’est pas désactivé ; il est supprimé. Son siège persiste donc jusqu’à ce que quelque chose le récupère, et dans un pipeline chargé les sièges sont consommés bien plus vite qu’aucun processus manuel ne les libère.

Trois modèles adaptés au calcul éphémère

Choisissez selon ce que vous voulez vraiment limiter.

Flottant / concurrence. Licenciez le nombre d’usages simultanés, pas de machines. Un pool de N leases concurrentes signifie qu’au plus N builds s’exécutent à la fois ; la lease d’un runner terminé (ou détruit) est récupérée et le build suivant la prend. C’est l’ajustement naturel quand le parallélisme est ce que vous vendez — voir licences flottantes concurrentes. Associez-le au reaping des leases par heartbeat pour qu’un runner qui disparaît sans se désactiver voie sa lease libérée après un court délai plutôt que de persister.

Droit cadré au build. Si vous devez seulement activer la fonctionnalité en CI (prouver que le client est licencié, sans compter les machines), validez un droit (entitlement) signé avec un jeton qui ne consomme aucun siège. Le build vérifie le droit hors ligne et s’exécute ; rien n’est verrouillé au nœud.

Builds mesurés. Si l’unité juste est le total des exécutions, mesurez-les — comptez les builds comme de l’usage contre un quota, avec une clé d’idempotence pour qu’un build réessayé ne compte pas double.

Détecter la CI et prendre le bon chemin

Le pivot d’implémentation est de laisser votre logiciel savoir qu’il est en CI pour qu’il prenne le chemin éphémère au lieu de celui de bureau :

static bool IsCi() =>
    Environment.GetEnvironmentVariable("CI") is "true" or "1"
    || Environment.GetEnvironmentVariable("GITHUB_ACTIONS") == "true"
    || Environment.GetEnvironmentVariable("GITLAB_CI") == "true"
    || Environment.GetEnvironmentVariable("TF_BUILD") == "true"      // Azure Pipelines
    || Environment.GetEnvironmentVariable("JENKINS_URL") is not null;

// In CI, validate against a concurrency/entitlement path — not a node-locked activation.
var result = IsCi()
    ? keyright.ValidateFloating()   // or a build-scoped entitlement check
    : keyright.Activate();          // normal desktop node-lock

L’expérience de bureau est inchangée ; le chemin de CI valide simplement la dimension qui y a du sens et n’écrit jamais une activation par machine qui échouerait un siège.

Le faire avec Keyright

Keyright prend en charge les trois modèles — concurrence flottante avec reaping par heartbeat, droits cadrés au build validés sans consommer de siège, et décompte de builds mesuré — pour que vous puissiez licencier la CI éphémère et les agents autoscalés par concurrence ou usage plutôt que par machine, et ne jamais voir un pipeline épuiser vos sièges. Chaque chemin valide hors ligne contre une charge signée, donc un runner à sortie réseau restreinte fonctionne quand même. Keyright est auto-hébergé, donc vos droits et données d’usage restent sur une infrastructure que vous contrôlez.

Consultez les offres, ou partez de licences flottantes concurrentes et ajoutez la détection de CI pour y router les runners.