Déployez la résolution des participants comme une infrastructure d'entreprise résiliente.
Exécutez Roster sur plusieurs instances avec PostgreSQL, routage selon l'état de disponibilité et mécanismes d'exploitation adaptés aux workflows critiques.
Commencez avec un seul conteneur. Passez à l'échelle lorsque la résolution des participants devient une composante critique de votre infrastructure.
Simple à déployer. Prêt à évoluer.
Roster prend en charge trois architectures de déploiement. Vous pouvez ainsi choisir celle qui correspond à vos exigences opérationnelles.
Une instance Roster avec SQLite intégré et stockage persistant dans /data. C'est la configuration la plus simple pour évaluer Roster ou exploiter une instance autonome. Aucune base de données externe n'est requise.
Une instance Roster Enterprise adossée à PostgreSQL. Utilisez une base de données administrée sans avoir à déployer plusieurs instances Roster.
Deux instances Roster identiques ou plus derrière un répartiteur de charge, avec PostgreSQL, un point de terminaison d'écriture et un ou plusieurs réplicas en lecture. Cette architecture est adaptée lorsque Roster prend en charge des agents, applications et workflows critiques en production.
Un point d'accès public. Plusieurs instances Roster.
Les clients continuent d'accéder à Roster par les mêmes interfaces : MCP, API REST, CLI et plateforme web. Le répartiteur de charge dirige les requêtes uniquement vers les instances Roster qui réussissent la sonde de disponibilité. Toutes les instances utilisent les mêmes points de terminaison PostgreSQL et partagent la même configuration d'exécution.
Les écritures et transactions sont dirigées vers le primaire PostgreSQL. Les lectures ordinaires admissibles sont réparties entre les réplicas.
Utilisez /health/ready pour diriger le trafic uniquement vers les instances qui peuvent joindre le primaire PostgreSQL et dont la configuration haute disponibilité est valide. Utilisez séparément /health/live pour vérifier que le processus Roster est en cours d'exécution.
Les écritures, transactions, contrôles de disponibilité, données d'authentification et décisions de sécurité restent dirigés vers le primaire PostgreSQL configuré.
Roster distribue les lectures ordinaires admissibles entre les réplicas PostgreSQL configurés.
PostgreSQL coordonne les limites de requêtes et les traitements en arrière-plan entre les différentes instances Roster. Les mécanismes de bail, de suivi d'activité et de récupération permettent à une autre instance de reprendre un traitement après une défaillance. Aucune affinité de session n'est requise.
Des mises en production contrôlées. Des accès d'exécution restreints.
Les déploiements en production doivent être planifiés et s'appuyer sur des comptes aux privilèges restreints.
Utilisez un compte applicatif aux privilèges restreints pour les instances Roster. Les réplicas peuvent utiliser un compte distinct en lecture seule.
Exécutez la même version immuable de l'image Roster et la même configuration sur toutes les instances.
Intégrez les sauvegardes, restaurations, objectifs de reprise, contrôles et responsabilités opérationnelles à vos procédures de production existantes.
Votre infrastructure reste sous votre contrôle.
Déployez Roster sur site, dans un cloud privé, dans votre propre compte de cloud public ou sur Kubernetes. Votre plateforme d'infrastructure prend en charge :
- La répartition de charge
- La réplication PostgreSQL
- La promotion automatique d'un réplica
- Les points de terminaison stables en lecture-écriture et en lecture seule
- Les sauvegardes et la restauration à un instant donné
- La répartition entre domaines de défaillance
- La centralisation des journaux et de la supervision
Roster se connecte à cette infrastructure et vérifie que sa propre configuration haute disponibilité est valide. Roster n'exploite pas la grappe PostgreSQL et n'en vérifie pas indépendamment la topologie.
Explorer les plateformes d'hébergementToutes les interfaces Roster évoluent avec votre déploiement.
Donnez aux agents un accès gouverné à la résolution des participants depuis les clients MCP qu'ils utilisent déjà.
Ajoutez la résolution des participants aux applications, workflows, plateformes d'automatisation et services internes.
Utilisez le même déploiement Roster depuis les scripts, terminaux et pipelines CI/CD.
Permettez aux administrateurs et responsables de projet autorisés de gérer les projets, participants, appartenances, libellés, associations d'annuaire et délégations.
Le passage d'une instance autonome à Roster Enterprise ne nécessite aucune nouvelle interface d'intégration.
Explorer les intégrationsLa sécurité par l'architecture.
Exécutez Roster dans l'infrastructure et les périmètres réseau contrôlés par votre organisation.
Conservez le contrôle des identifiants de base de données, d'annuaire, de fournisseur d'identité et de fournisseur de modèles.
Représentez les utilisateurs humains, agents IA et comptes de service avec des identités distinctes et des identifiants d'accès révocables indépendamment.
Déterminez les fonctionnalités, projets, participants, délégations et fiches d'annuaire accessibles à chaque identité.
Consultez les activités de la plateforme et les événements associés aux résolutions grâce aux fonctionnalités d'audit Enterprise.
Analysez l'utilisation des modèles et l'activité de résolution sans fournir aux agents un accès direct aux identifiants des annuaires sources.
Fonctionnalités Enterprise
| Capacité | Gratuit et Pro | Enterprise |
|---|---|---|
| Déploiement auto-hébergé | ✓ | ✓ |
| SQLite intégré | ✓ | ✓ |
| Web, REST, CLI et MCP | ✓ | ✓ |
| Fournisseur de modèles au choix | ✓ | ✓ |
| PostgreSQL | — | ✓ |
| Plusieurs instances Roster | — | ✓ |
| Mode haute disponibilité | — | ✓ |
| Répartition sur des réplicas en lecture | — | ✓ |
| Audit Enterprise | — | ✓ |
| SLA Enterprise | — | ✓ |
Roster prend en charge la couche applicative. Votre plateforme assure la reprise PostgreSQL.
Un déploiement Roster hautement disponible comporte deux couches indépendantes : deux instances Roster identiques ou plus derrière un répartiteur de charge, et un service PostgreSQL avec un primaire accessible en écriture, au moins un réplica en lecture, une promotion automatique et des points de terminaison stables.
Lorsqu'une instance Roster s'arrête, le répartiteur de charge la retire du routage et continue de transmettre les requêtes aux instances opérationnelles. Lorsque le primaire PostgreSQL s'arrête, le service de base de données doit promouvoir un réplica et déplacer le point de terminaison d'écriture. Roster redevient disponible lorsque ce point de terminaison est de nouveau accessible.
Roster ne fournit pas la réplication PostgreSQL ni la promotion du primaire.
Validation avant mise en production
Avant de diriger le trafic de production vers un déploiement hautement disponible, vérifiez que :
- Au moins deux instances Roster réussissent la sonde de disponibilité
- Les requêtes authentifiées continuent lorsque l'une des instances est retirée
- Le service PostgreSQL promeut un réplica et restaure le point de terminaison d'écriture
- Roster récupère sans modification de ROSTER_DATABASE_URL
- Les lectures ordinaires tolèrent le retard de réplication attendu
- Les traitements en arrière-plan reprennent correctement après la défaillance d'une instance
- Les sauvegardes et restaurations isolées ont été testées
- Les journaux, contrôles, alertes et responsabilités opérationnelles sont en place
La disponibilité dépend du système dans son ensemble, et non du seul conteneur Roster.