Workers
Pour les modèles d'utilisation et les topologies de déploiement, consultez la page Workers.
Variables d'environnementLien direct vers Variables d'environnement
MASTRA_WORKERSLien direct vers mastra_workers
Détermine quels Workers démarrent dans le processus actuel.
| Valeur | Comportement |
|---|---|
| (non définie) | Les Workers par défaut sont créés automatiquement en fonction de la configuration |
"false" | Désactive le traitement des événements par les Workers. Le processus répond aux requêtes HTTP et peut toujours publier des événements vers PubSub, par exemple le démarrage de workflows, sans les consommer. |
"orchestration" | Démarre uniquement l'OrchestrationWorker |
"scheduler" | Démarre uniquement le SchedulerWorker |
"backgroundTasks" | Démarre uniquement le BackgroundTaskWorker |
"orchestration,scheduler" | Démarre plusieurs Workers, séparés par des virgules |
Utilisez cette variable pour exécuter différents types de Workers dans des conteneurs distincts à partir du même artefact de build.
MASTRA_STEP_EXECUTION_URLLien direct vers mastra_step_execution_url
URL de base du serveur d'API, utilisée par l'OrchestrationWorker pour exécuter à distance les étapes d'un workflow. Elle est obligatoire lorsque l'OrchestrationWorker s'exécute dans un processus distinct de l'API.
MASTRA_STEP_EXECUTION_URL=http://api:4111/api
Utilisez des URL HTTPS en production. Consultez les recommandations de sécurité.
L'OrchestrationWorker envoie les requêtes d'exécution des étapes à l'adresse suivante :
${MASTRA_STEP_EXECUTION_URL}/workflows/:workflowId/runs/:runId/steps/execute
MASTRA_WORKER_AUTH_TOKENLien direct vers mastra_worker_auth_token
Jeton bearer envoyé par l'OrchestrationWorker lorsqu'il appelle l'endpoint d'exécution des étapes de l'API. Le fournisseur d'authentification configuré pour l'API doit reconnaître ce jeton. Consultez l'authentification des Workers.
MASTRA_WORKER_AUTH_TOKEN=sk-worker-secret-token
Types de WorkersLien direct vers Types de Workers
OrchestrationWorkerLien direct vers OrchestrationWorker
Traite les événements de workflow provenant du topic PubSub workflows. Nécessite un système PubSub compatible avec le mode pull, comme @mastra/redis-streams ou @mastra/google-cloud-pubsub, configuré avec un abonnement pull.
- Nom :
orchestration - Topic PubSub :
workflows - Groupe de consommateurs :
mastra-orchestration
SchedulerWorkerLien direct vers SchedulerWorker
Interroge le stockage pour détecter les planifications cron arrivées à échéance et publie des événements workflow.start.
- Nom :
scheduler - Une seule instance : exécutez exactement une instance pour éviter les déclenchements en double
BackgroundTaskWorkerLien direct vers BackgroundTaskWorker
Exécute les appels de Tools en arrière-plan envoyés par les Agents.
- Nom :
backgroundTasks - Topic PubSub :
background-tasks - Groupe de consommateurs :
background-task-workers - Prise en charge de plusieurs réplicas : les instances partagent le groupe de consommateurs
Backends de stockage pris en chargeLien direct vers Backends de stockage pris en charge
Un déploiement qui exécute tous les types de Workers nécessite un backend de stockage implémentant les domaines workflows, backgroundTasks et schedules. Le domaine schedules est spécifiquement requis par le SchedulerWorker. Si vous n'utilisez pas de workflows planifiés, les backends qui n'implémentent pas ce domaine peuvent tout de même prendre en charge l'orchestration et les tâches d'arrière-plan. Les backends suivants prennent en charge les trois domaines :
| Backend | Package |
|---|---|
| PostgreSQL | @mastra/pg |
| LibSQL | @mastra/libsql |
| MySQL | @mastra/mysql |
| MongoDB | @mastra/mongodb |
| Spanner | @mastra/spanner |
| Convex | @mastra/convex |
Les autres backends de stockage, notamment Upstash, DynamoDB, Cloudflare D1, ClickHouse et Redis, prennent en charge les workflows et certaines fonctionnalités des Workers, mais pas le domaine schedules. Ils peuvent néanmoins être utilisés pour l'orchestration et les Workers de tâches d'arrière-plan si vous ne déployez pas le SchedulerWorker.