Skip to main content
Utilisez la ressource coreweave_sandbox_managed_runner pour gérer un exécuteur et sa politique de sandbox sur un cluster CoreWeave Kubernetes Service (CKS). Terraform enregistre la configuration souhaitée, détecte les dérives et applique les modifications de configuration via l’API des exécuteurs gérés. Pour le schéma complet des attributs, consultez la référence de la ressource d’exécuteur géré. Pour les flux de travail CLI et REST correspondants, consultez Déployer et gérer un exécuteur.

Avant de commencer

Vous avez besoin des ressources et outils suivants :
  • Terraform et le fournisseur Terraform CoreWeave. Les exemples utilisent la version 0.26.0 ou ultérieure du fournisseur, dans la série 0.x.
  • Un cluster CKS existant, son identifiant unique universel (UUID) et son Availability Zone. Ces valeurs figurent sur la page Clusters de la Cloud Console.
  • Un jeton d’accès à l’API CoreWeave disposant de l’autorisation SANDBOX_ADMIN. Voir Gérer les jetons d’accès à l’API et Gérer les politiques d’accès.
  • Un backend d’état Terraform doté de contrôles d’accès. Terraform peut stocker dans l’état les valeurs de remplacement de l’environnement de l’exécuteur ainsi que les valeurs de politique, même s’il les marque comme sensibles.
Chaque cluster CKS peut héberger au plus un exécuteur géré. Si votre cluster en possède déjà un, importez-le avant d’appliquer la configuration.

Configurer l’authentification

Le fournisseur lit la variable COREWEAVE_API_TOKEN. Si vous avez déjà exporté votre jeton sous le nom CW_API_KEY, définissez la variable d’environnement attendue par le fournisseur :
Par défaut, le fournisseur utilise https://api.coreweave.com. L’authentification ne dépend pas de la connexion à CoreWeave Intelligent CLI. N’incluez pas le jeton dans vos fichiers de configuration Terraform.

Définir l’exécuteur

Enregistrez la configuration suivante dans un fichier main.tf. Elle crée un exécuteur associé au canal de publication stable, avec une fenêtre de maintenance hebdomadaire et une politique qui définit les valeurs par défaut des ressources des sandboxes ainsi qu’une durée de vie par défaut.
main.tf
Les deux sections de ressources ont des rôles distincts :
  • spec configure l’exécuteur. Dans cet exemple, spec.overrides.resources dimensionne les Pods propres à l’exécuteur, et la fenêtre de maintenance commence le samedi à 2 h UTC.
  • policy configure les bacs à sable desservis par l’exécuteur. Cet exemple plafonne le CPU et la mémoire de chaque conteneur de sandbox, interdit les GPU avec max_gpu_count = 0 et définit une durée de vie par défaut d’une heure. Cette durée de vie par défaut ne constitue pas une durée de vie maximale. Pour adapter les contraintes à vos charges de travail, consultez Configurer une politique de sandbox.
L’objet policy est requis. N’utilisez un objet vide explicite que si vous souhaitez réellement une politique vide. La valeur zone doit être en minuscules, ce que garantit lower(var.zone). Remplacez [RUNNER-ID], [CLUSTER-ID] et [ZONE] par l’identifiant de votre exécuteur, l’UUID de votre cluster CKS et votre Availability Zone, puis enregistrez les valeurs dans un fichier terraform.tfvars :
terraform.tfvars

Appliquer et vérifier le déploiement

Pour appliquer la configuration et vérifier le déploiement de l’exécuteur, procédez comme suit :
  1. Initialisez le fournisseur et validez la configuration :
  2. Examinez et appliquez le plan :
    Si l’application réussit, cela signifie que l’API a accepté la configuration. L’installation et le déploiement de l’exécuteur se poursuivent de manière asynchrone.
  3. Actualisez le statut observé et examinez la sortie :
    L’exécuteur est prêt lorsque install_status vaut RUNNER_INSTALL_STATUS_READY, que connection_status vaut RUNNER_CONNECTION_STATUS_CONNECTED et que active_revision est égal à target_revision. Si le provisionnement est toujours en cours, actualisez de nouveau une fois que le déploiement a progressé. En cas d’échec de l’installation, l’attribut calculé install_error en précise la cause.

Mettre à jour la configuration

Modifiez la ressource dans le fichier main.tf, examinez un nouveau plan, puis appliquez-le. Conservez dans Terraform l’intégralité de la politique souhaitée et des paramètres de remplacement, afin que les applications ultérieures respectent la configuration voulue. Les modifications effectuées via la CLI ou l’API peuvent apparaître comme une dérive, et une application Terraform ultérieure risque de les annuler. La suppression d’un paramètre facultatif dans spec réinitialise ce paramètre au moyen d’un masque de mise à jour explicite de l’API. Toute modification des remplacements remplace l’objet spec.overrides dans son ensemble : conservez donc les autres remplacements que vous souhaitez garder. Le deployment_spec résolu est en lecture seule. Une modification simultanée de la politique peut faire échouer une application, car le fournisseur utilise un jeton de révision de politique (etag). Actualisez l’état et examinez un nouveau plan avant toute nouvelle tentative. La modification de runner_id, cluster_id ou zone entraîne le remplacement de l’exécuteur au lieu de sa mise à jour sur place.

Configurer l’affinité des exécuteurs

L’affinité nécessite une version du fournisseur qui inclut spec.overrides.affinity. La version 0.26.0 du fournisseur n’inclut pas cet attribut. En attendant qu’une version compatible soit disponible, utilisez l’exemple d’affinité REST. Coordonnez les modifications effectuées via REST avec la configuration Terraform afin qu’elles ne soient pas écrasées lors des applications Terraform ultérieures. Une fois un fournisseur compatible installé, fusionnez l’attribut suivant dans l’objet spec.overrides existant. Remplacez l’étiquette fournie à titre d’exemple par une étiquette utilisée par les nœuds de votre cluster :
Affinity attribute inside spec.overrides
L’attribut accepte du JSON Affinity Kubernetes, y compris l’affinité de nœud, l’affinité de Pod et l’anti-affinité de Pod. Les clés à l’intérieur de jsonencode() suivent la convention camelCase de Kubernetes. Cette règle préférentielle laisse disponibles les autres nœuds éligibles et ne garantit pas un placement prioritaire sur les nœuds à la demande. Les sélecteurs de nœuds et les tolérances existants continuent de s’appliquer. L’affinité ne contrôle que les Pods des exécuteurs. Elle ne configure ni le placement des Pods de sandbox ni les budgets d’allocation de nœuds. L’affinité est remplacée dans son intégralité. Définissez affinity = jsonencode({}) pour effacer toutes les règles, y compris l’affinité héritée. Supprimez l’attribut pour restaurer les valeurs par défaut de la plateforme. Dans les deux cas, conservez dans spec.overrides les autres attributs dont vous avez encore besoin.

Importer un exécuteur existant

Définissez la ressource et les variables en reprenant l’exemple de configuration d’exécuteur, puis adaptez sa politique et sa spécification à l’exécuteur existant avant d’appliquer la configuration. Remplacez [RUNNER-ID] par l’identifiant de l’exécuteur dans l’organisation associée à votre jeton API :
L’importation enregistre l’exécuteur existant dans l’état Terraform sans créer de nouvel exécuteur. Examinez le plan et réconciliez la configuration avec les valeurs importées avant de l’appliquer. Terraform utilise l’identifiant de l’exécuteur comme ID d’importation, et non l’UUID du cluster.

Supprimer un exécuteur

Retirez de votre configuration la ressource ainsi que toutes les références à celle-ci, y compris la sortie runner_status. Examinez ensuite le plan obtenu, puis appliquez-le. La suppression de la ressource entraîne la mise hors service de l’exécuteur géré. Le fournisseur attend jusqu’à 30 minutes la fin de la suppression avant de retirer la ressource de l’état.

Voir aussi

Pour les flux de travail associés et les informations de référence, consultez les pages suivantes :
Dernière modification le 20 octobre 2026