POST /v1/sandboxes:createFromFile démarre une sandbox à partir d’un fichier téléversé. Vous envoyez un type de fichier et le contenu binaire du fichier ; la passerelle des sandboxes convertit alors le document en spécification de sandbox et suit le même processus de création que POST /v1/sandboxes.
Docker Compose (SANDBOX_FILE_TYPE_COMPOSE) est le seul type de fichier accepté. Chaque service du fichier devient un conteneur au sein d’une même sandbox, et le service que vous désignez devient le conteneur principal de la sandbox. La passerelle ne stocke pas le contenu du fichier. GET /v1/sandboxes/{sandboxId} renvoie la spécification convertie.
Cette fonctionnalité n’offre pas une équivalence complète avec Docker Compose. Avant d’importer un projet existant, consultez Prise en charge de Compose.
Avant de commencer
Les exemples suivants utilisent une clé API Forge. Voir Premiers pas. Transmettez la clé dans l’en-têtex-wandb-api-key. Pour créer la sandbox dans une entity Forge autre que votre entity par défaut, transmettez également l’en-tête x-entity-id.
SANDBOX_USER, y compris pour le placement sur CKS. Suivez les instructions de la section Choisir et obtenir des identifiants d’authentification, puis définissez le jeton :
-H "x-wandb-api-key: $FORGE_API_KEY" par -H "Authorization: Bearer $CWSANDBOX_API_KEY" afin d’utiliser ce jeton. L’authentification et le format des erreurs sont les mêmes que pour le reste de l’API. Voir Aperçu de l’API.
Champs de la requête
La requête accepte également
mode, maxLifetimeSeconds, tags, network, objectStorageAccess, annotations, runnerIds et requestId, avec la même signification que pour POST /v1/sandboxes. networkIds renvoie UNIMPLEMENTED.
Pour un placement sur CKS, utilisez un jeton d’accès à l’API CoreWeave et configurez les champs de placement comme décrit dans Placement et débordement des sandboxes. Pour les prérequis liés au stockage d’objets, consultez Accorder aux sandboxes l’accès à AI Object Storage.
Cette liste de champs est exhaustive. Les volumes, le type d’instance, la classe de runtime, les identifiants d’authentification pour la récupération d’images et les services publiés ne sont pas disponibles sur ce point de terminaison. Utilisez POST /v1/sandboxes si vous en avez besoin.
Créer la sandbox
Écrivez un fichier Compose :Write compose.yaml
contents encodé en base64 :
Create a sandbox from compose.yaml
STATE_CREATING. Interrogez-la régulièrement à l’aide de son sandboxId jusqu’à ce qu’elle atteigne l’état STATE_RUNNING ou un état terminal :
Poll the sandbox
main, marqué comme principal, et HELPER_HOST, toujours défini sur helper. Dans le sandbox, helper est résolu en 127.0.0.1.
Pour relancer une création sans risque, envoyez requestId. Un même requestId associé aux mêmes entrées déclarées renvoie le sandbox existant. Un même requestId associé à des octets différents, y compris lorsque la modification ne porte que sur des caractères d’espacement, renvoie ALREADY_EXISTS avec le motif CWSANDBOX_REQUEST_ID_CONFLICT.
Prise en charge de Compose
Tous les services partagent un même pod et un même namespace réseau. Les noms de service sont résolus en127.0.0.1, si bien que des valeurs telles que HELPER_HOST: helper et API_BASE: http://main:8080 fonctionnent sans qu’il soit nécessaire de réécrire le fichier. La sandbox ne dispose ni d’adresses IP par service, ni de réseaux bridge, ni de répliques.
Les comportements suivants diffèrent de ceux de Docker Compose :
- Le démarrage est séquentiel. Les services non principaux démarrent les uns après les autres, avant le service principal. Dimensionnez
maxLifetimeSecondsen conséquence. Si un service ne devient jamais prêt, la sandbox reste dans l’étatSTATE_CREATING. RUNNINGne suit que le service principal. Le plantage d’un service auxiliaire après son démarrage ne fait pas échouer la sandbox.healthcheckdevient une sonde de démarrage de type exec uniquement.testdoit être une chaîne,CMD,CMD-SHELLouNONE, et les durées doivent être exprimées en secondes entières. Lorsque la sonde a épuisé ses tentatives, le conteneur est arrêté au lieu d’être marqué comme défaillant.- Les ports restent internes au pod.
exposeetportsdéclarent des ports d’écoute, mais rien n’est publié à l’extérieur. - Les images doivent pouvoir être récupérées. Chaque service doit avoir une clé
image:dans le fichier ou une entrée dansimageOverrides. Un service qui requiert encorebuild:renvoieUNIMPLEMENTED. commandetentrypointsuivent les formes shell et exec de Docker. Omettez-les pour utiliser les valeurs par défaut de l’image. Les valeurs explicitesnullet[]sont rejetées.- Les GPU sont réservés au service principal, via
deploy.resources.reservations.devicesavec la capacitégpuet un nombre entier positif. - Les noms doivent être des libellés DNS-1123 (
my-app, et nonMy_App) et ne peuvent pas utiliser les préfixes réservéscw-object-store-agent,cw-object-store-agent-restoreoudns-egress.
Clés non prises en charge
Le document doit être autonome : la passerelle ne lit pas votre disque et ne développe pas les variables de votre environnement. Les clés non reconnues ne sont pas ignorées, mais rejetées avec le chemin du champ en cause.
La passerelle ignore les clés
version, name du projet, labels et les clés d’extension x-*. Ne comptez pas sur la transmission des labels à la sandbox.
Erreurs courantes
Les violations de champ sont renvoyées sous forme de détailsBadRequest qui indiquent le chemin et la limite concernés. Elles ne reprennent pas le contenu de votre document.
Voir aussi
- Premiers pas : créez votre première sandbox à partir d’une spécification.
- Aperçu de l’API : authentification, gestion des versions et des erreurs.
- Variables d’environnement des sandboxes : ce que la plateforme injecte dans chaque conteneur.