Ring Promoter est le moderne du Workstation Plan de contrôle de promotion CI/CD — l'outil à ne pas manquer Déploiements basés sur l'IA. Il déplace les versions de nombreuses applications à travers des anneaux de déploiement ordonnés int → test → acc → prod avec des contrôles de santé en direct, une vérification de version facultative, une restauration automatique et une piste d'audit complète. Site produit : https://www.ringpromoter.com/ · source: github.com/bwalia/ring-promoter. Compagnon: bloguer · fiche produit : /promoteur-anneau.
- Quoi: Pipeline en anneau partagé pour la promotion multi-applications avec sauts sécurisés et restauration automatique.
- OMS: Agents d'expédition des équipes de plateforme, SRE, DevOps et IA/ML, API, passerelles et services classiques.
- Contrôle: Interface utilisateur Web intégrée + JSON REST API ; Historique Postgres par (application, sonnerie).
- Déployeurs : kubectl, répartition du flux de travail GitHub Actions ou exécuteurs de tâches Kubernetes – par application.
- Slogan : Chaque version rapporte de la production.
1. Positionnement : CI/CD à l’ère de l’expédition par l’IA
Les plateformes d’IA ne sont pas livrées comme un seul monolithe. Vous faites la promotion des services d'inférence, des environnements d'exécution d'agent, des passerelles MCP, des RAG API et de la prise en charge des microservices sur différentes horloges, souvent à partir de différents dépôts et de différents mécanismes de déploiement (Kubernetes vs VM CI). Les pipelines classiques de « fusion vers principal et espoir » sautent les anneaux, faussent la santé verte et ne laissent aucun protocole de promotion partagé entre les applications.
Ring Promoter est le plan de contrôle manquant : un ensemble ordonné d'anneaux, de nombreuses applications, des règles de promotion strictes et des déployeurs échangeables. Il est suffisamment petit pour fonctionner sur des k3, suffisamment sérieux pour l'historique de production et les verrous entre répliques, et conçu pour que les charges de travail d'IA et les services classiques partagent le même langage de promotion.
2. Le modèle de bague
Les bagues sont partagé et commandé (défini une fois). Chaque application gérée déclare, par anneau, où elle se trouve et comment y accéder : espace de noms, déploiement, conteneur, référentiel d'images et URL d'intégrité. Cette cartographie vit dans configuration, pas du code.
| Anneau | Rôle | Utilisation typique de l'IA |
|---|---|---|
| int | Intégration | Premier atterrissage pour les builds agent/API |
| test | Test | Suites d'évaluation, trafic canari, fumée de chargement |
| acc | Acceptation | Partie prenante / porte d'étape |
| prod | Production | IA orientée client et API |
3. Règles de promotion (non négociable)
- Une sonnerie à la fois ; ne sautez jamais.
promote {from_ring}vise toujours le suivant anneau dans le pipeline. - La source doit être saine avant le début de la promotion (bilan de santé en direct).
- Après le déploiement, le service exécute un bilan de santé avec tentatives configurables.
- Si la cible reste en mauvais état après plusieurs tentatives, c'est automatiquement annulé à la version précédente.
- Chaque graine/promotion/rollback est écrit dans histoire, le succès ou l'échec.
- Promotion automatique (facultatif, par sonnerie) : un atterrissage sain peut continuer dans la même opération verrouillée - par ex. promotion automatique sur
testdoncint → testcontinue àacc, alors queaccreste fermé aux humains avantprod.
4. Santé vérifiée par version (critique pour l'IA)
Une simple vérification d'URL peut être trompée : le déploiement « réussit », mais un ancien side-car d'inférence ou un binaire d'agent précédent répond toujours. 200 OK. Si une bague se met health_version_field (Champ JSON dans la réponse sanitaire, par ex. version ou en pointillé build.version) ou health_version_header (par ex. X-App-Version), chaque vérification post-déploiement nécessite également que le point de terminaison signaler la version exacte qui vient d'être déployée - sinon la vérification échoue et la restauration automatique entre en jeu. La même source vérifie le source ring exécute réellement la version sur le point d'être promue.
Sur un bague épinglée (ref: release) la version attendue n'est pas connaissable à l'avance — le pipeline décide de ce que la référence expédie — donc le champ est utilisé dans l'autre sens : après un déploiement sain de l'anneau enregistre la version des rapports du point de terminaison au lieu du nom de la référence.
5. Déployeurs et exécuteurs
Des interfaces claires maintiennent le moteur de promotion stable pendant que les backends échangent :
| Préoccupation | Implémentations de production |
|---|---|
| Déployer | KubectlDeployer, GitHubActionsDeployer, k8sjob |
| Exécution | Exécuteur d’actions GitHub ; Exécuteur de jobs Kubernetes |
| Santé | HTTPChecker (dev : des contrefaçons toujours saines) |
| Persistance | Postgres (prod) / mémoire (dév) |
- KubectlDeployer - débourse pour
kubectl set image+rollout status, authentification dans le cluster via ServiceAccount. - GitHubActionsDeployer — pour les applications VM/CI qui disposent déjà d'un pipeline : déclencheurs répartition du flux de travail, attend la conclusion, puis applique la même logique santé + restauration.
- k8sjob — exécute l'amorçage/la promotion/la restauration en tant que travail dans
ring-exec; env. coureur (RP_APP,RP_RING,RP_VERSION, …); flux stdout vers les journaux d'étape ; le code de sortie décide du succès.
Le déployeur est sélectionné par demande, de sorte qu'un plan de contrôle peut promouvoir côte à côte les applications Kubernetes et les applications VM/CI, ce qui est utile lorsque les tâches de formation d'IA restent sur les VM tout en diffusant des exécutions sur Kubernetes.
6. Concurrence et fiabilité
- Les opérations sur la même application sont sérialisées par un verrou de magasin. Postgres utilise un verrouillage des conseils de session, donc la sérialisation est valable sur les répliques.
- L'amorçage/promotion/rollback s'exécute dans un contexte détaché de la requête HTTP et délimité par
operation_timeout— une déconnexion client ne peut pas abandonner un déploiement en cours ou sa restauration automatique. - L'état stocké est mis à jour dès qu'un déploiement arrive, de sorte qu'il ne soit jamais en retard sur le cluster, même si une vérification de l'état et une restauration ultérieures échouent.
7. Pourquoi Workstation propose Ring Promoter pour l'IA
Workstation crée des postes de travail IA, une IA privée, des plates-formes d'agents et des produits de pointe (y compris le proxy Workstation WSL). Ces piles ont besoin d'un protocole de promotion qui traite les « déploiements basés sur l'IA » comme étant de première classe : de nombreuses applications, des déployeurs mixtes, une santé honnête en termes de versions et des portes humaines là où cela compte. Ring Promoter est ce protocole – ouvert à ringpromoter.com et intégré aux conversations de la solution Workstation en tant que plan de contrôle CI/CD moderne à ne pas manquer.
Operators / CI / Agents
→ Ring Promoter (UI + REST API)
→ seed / promote / rollback
→ Deployer (kubectl | GitHub Actions | k8sjob)
→ Health (HTTP + optional version verify)
→ Store (Postgres history + locks)
Rings: int → test → acc → prod
8. Pour commencer
- Visite https://www.ringpromoter.com/ pour le contexte du produit et les démos.
- Cloner github.com/bwalia/ring-promoter et exécuté localement ou sur k3.
- Lire le Workstation fiche produit et le résumé du blog.
- Parlez à Workstation de CI/CD pour les plateformes d'IA via contact.
Publié par Workstation. Documents en amont : README et notes de conception dans le référentiel Ring Promoter.
Site produit : https://www.ringpromoter.com/
