> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Gérer les exécuteurs avec Terraform

> Déployez, configurez et importez des exécuteurs gérés CoreWeave Sandbox avec le fournisseur Terraform de CoreWeave.

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é](/platform/terraform/resources/sandbox_managed_runner). Pour les flux de travail CLI et REST correspondants, consultez [Déployer et gérer un exécuteur](/fr/products/sandboxes/operations/managed-runners).

## Avant de commencer

Vous avez besoin des ressources et outils suivants :

* Terraform et le [fournisseur Terraform CoreWeave](/platform/terraform). 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](https://console.coreweave.com/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](/security/authn-authz/manage-api-access-tokens) et [Gérer les politiques d’accès](/security/iam/access-policies/manage).
* 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](#import-an-existing-runner) 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 :

```bash theme={"system"}
export COREWEAVE_API_TOKEN="$CW_API_KEY"
```

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.

```terraform title="main.tf" theme={"system"}
terraform {
  required_providers {
    coreweave = {
      source  = "coreweave/coreweave"
      version = "~> 0.26"
    }
  }
}

provider "coreweave" {}

variable "runner_id" {
  type        = string
  description = "Runner identifier, unique within your organization."
}

variable "cluster_id" {
  type        = string
  description = "UUID of the existing CKS cluster."
}

variable "zone" {
  type        = string
  description = "Availability Zone of the existing CKS cluster."
}

resource "coreweave_sandbox_managed_runner" "runner" {
  runner_id  = var.runner_id
  cluster_id = var.cluster_id
  zone       = lower(var.zone)

  spec = {
    release_channel = "RELEASE_CHANNEL_STABLE"
    maintenance_policy = {
      windows = [{ cron = "0 2 * * SAT", duration_seconds = 3600 }]
    }
    overrides = {
      resources = {
        cpu_request    = "1"
        memory_request = "2Gi"
        cpu_limit      = "4"
        memory_limit   = "8Gi"
      }
    }
  }

  policy = {
    display_name = "Sandbox constraints"
    constraints = {
      resources = {
        default_cpu    = "1"
        default_memory = "2Gi"
        max_cpu        = "8"
        max_memory     = "32Gi"
        max_gpu_count  = 0
      }
      lifecycle = { default_lifetime_seconds = 3600 }
    }
  }
}

output "runner_status" {
  value = {
    runner_id           = coreweave_sandbox_managed_runner.runner.runner_id
    install_status      = coreweave_sandbox_managed_runner.runner.install_status
    connection_status   = coreweave_sandbox_managed_runner.runner.connection_status
    active_revision     = coreweave_sandbox_managed_runner.runner.active_revision
    target_revision     = coreweave_sandbox_managed_runner.runner.target_revision
    rollout_in_progress = coreweave_sandbox_managed_runner.runner.rollout_in_progress
  }
}
```

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](/fr/products/sandboxes/profiles/configure).

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 title="terraform.tfvars" theme={"system"}
runner_id  = "[RUNNER-ID]"
cluster_id = "[CLUSTER-ID]"
zone       = "[ZONE]"
```

## 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 :

   ```bash theme={"system"}
   terraform init
   terraform validate
   ```

2. Examinez et appliquez le plan :

   ```bash theme={"system"}
   terraform plan -out=runner.tfplan
   terraform apply runner.tfplan
   ```

   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 :

   ```bash theme={"system"}
   terraform plan -refresh-only -out=runner-status.tfplan
   terraform apply runner-status.tfplan
   terraform output runner_status
   ```

   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](/fr/products/sandboxes/operations/managed-runners#example-configure-runner-affinity). 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 :

```terraform title="Affinity attribute inside spec.overrides" theme={"system"}
affinity = jsonencode({
  nodeAffinity = {
    preferredDuringSchedulingIgnoredDuringExecution = [{
      weight = 100
      preference = {
        matchExpressions = [{
          key      = "example.com/capacity-class"
          operator = "In"
          values   = ["on-demand"]
        }]
      }
    }]
  }
})
```

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](/fr/products/sandboxes/operations/node-allocation-budgets).

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 :

```bash theme={"system"}
terraform init
terraform import coreweave_sandbox_managed_runner.runner '[RUNNER-ID]'
terraform plan
```

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 :

* [Référence de la ressource d’exécuteur géré](/platform/terraform/resources/sandbox_managed_runner).
* [Déployer et gérer un exécuteur](/fr/products/sandboxes/operations/managed-runners).
* [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure).