Déploiements auto-hébergés

Un déploiement auto-hébergé exécute votre code sur une infrastructure que vous opérez (machines virtuelles, Kubernetes, votre cloud privé). Vous démarrez vous-même les workloads, et Mistral les orchestre : le routage des exécutions, la durabilité et la mise à l'échelle restent assurés par la plateforme.

L'auto-hébergement d'un déploiement ne revient pas à exécuter l'ensemble de la plateforme Studio dans vos propres locaux. Pour cela, consultez la documentation on-premises dédiée.

Le développement local et l'auto-hébergement exécutent le même code de la même manière. La différence réside dans l'endroit où s'exécute le workload :

• Développement local : le workload s'exécute sur votre machine, pour itérer. Il s'enregistre auprès de la plateforme comme n'importe quel autre déploiement, ce qui vous permet de le déclencher et de l'observer dans Studio. Il s'arrête quand vous fermez votre ordinateur portable.
• Auto-hébergés : le workload s'exécute en continu sur une infrastructure que vous opérez. Il s'agit de la forme de production de l'exécution de votre propre code.

Le même nom de déploiement, le même code et les mêmes commandes fonctionnent dans les deux cas. Pour déplacer un déploiement de votre ordinateur portable vers votre infrastructure, démarrez-y le même workload. Vous ne modifiez pas le code.

L'auto-hébergement est une décision que vous prenez pour l'exécution en production. Pendant que vous construisez (généralement avec un agent de codage sur votre machine), vous exécutez un déploiement local pour tester et itérer. Les déploiements locaux et auto-hébergés exécutent le même code de la même façon ; la page d'auto-hébergement de chaque système détaille ce qui change quand vous passez à une infrastructure de production.

Optez pour l'auto-hébergement lorsque vous avez besoin de contrôler l'endroit où votre code s'exécute :

• Localisation des données : maintenez l'exécution dans une région ou un réseau que vous contrôlez.
• Connectivité privée : accédez aux API et aux bases de données internes que Mistral Cloud ne peut pas joindre.
• Ressources de calcul existantes : utilisez des clusters Kubernetes, des GPU ou des capacités que vous payez déjà.
• Maîtrise des coûts : exécutez des charges de travail stables sur une infrastructure qui vous appartient.

Si aucun de ces cas ne s'applique, utilisez plutôt des déploiements gérés : les concepts de déploiement, le routage et l'observabilité sont identiques, et il n'y a rien à gérer.

Les applications s'exécutent uniquement sur Mistral Cloud : il n'existe pas de chemin auto-hébergé pour les applications. Déployez une application avec les déploiements managés pour les applications.

Vos workloads se connectent à Mistral via l'API, et la plateforme conserve :

• Routage : le travail est envoyé au déploiement qui le possède.
• Durabilité : l'état survit aux crashs et aux redémarrages des workloads.
• Scaling : exécutez plus de workloads sous le même déploiement pour augmenter le débit ; la plateforme répartit les tâches entre eux.
• Observabilité : les exécutions, les logs et les traces sont visibles dans Studio.

Vos workloads s'authentifient avec une clé API d'espace de travail, ou avec un compte de service, y compris via la fédération d'identité de workload. L'identité de workload permet à un workload de votre cluster de s'authentifier sans clé de longue durée.

Configurez les variables d'environnement dans l'environnement du workload. Pour les identifiants, utilisez le Secrets Manager de l'espace de travail et résolvez les références au démarrage, pour qu'aucune valeur de secret ne soit codée en dur dans votre code.

Les déploiements durcis restreignent les utilisateurs et les comptes de service autorisés à enregistrer des workflows sur un déploiement. Le durcissement est requis pour les workflows on-behalf-of, qui agissent avec les autorisations de l'utilisateur déclencheur.

Aller plus loin