POST /v1/sandboxes:createFromFile は、アップロードされたファイルからサンドボックスを起動します。ファイルタイプとファイルのバイト列を送信すると、サンドボックスのゲートウェイがドキュメントをサンドボックスの spec に変換し、POST /v1/sandboxes と同じ作成処理を実行します。
受け付けるファイルタイプは Docker Compose (SANDBOX_FILE_TYPE_COMPOSE) のみです。ファイル内の各サービスは、単一のサンドボックス内のコンテナーになり、指定した 1 つのサービスがサンドボックスのプライマリになります。ゲートウェイはファイルのバイト列を保存しません。GET /v1/sandboxes/{sandboxId} は変換された spec を返します。
これは Docker Compose と同等の機能を提供するものではありません。既存の project をインポートする前に、Compose のサポートをお読みください。
始める前に
以下の例では Forge APIキーを使用します。詳しくははじめにを参照してください。キーはx-wandb-api-key ヘッダーで送信します。デフォルト以外の Forge entity にサンドボックスを作成する場合は、x-entity-id も送信してください。
SANDBOX_USER action を持つ CoreWeave API アクセストークンを使用することもできます。これは CKS への配置にも使用できます。認証情報を選択して取得するの手順に従ったうえで、トークンを設定します。
-H "x-wandb-api-key: $FORGE_API_KEY" を -H "Authorization: Bearer $CWSANDBOX_API_KEY" に置き換えてください。認証方式とエラーの形式は、API のほかの部分と同じです。詳しくは、API の概要を参照してください。
リクエストフィールド
リクエストでは、
mode、maxLifetimeSeconds、tags、network、objectStorageAccess、annotations、runnerIds、requestId も受け入れます。意味は POST /v1/sandboxes と同じです。networkIds は UNIMPLEMENTED を返します。
CKS への配置では、CoreWeave API アクセストークンを使用し、サンドボックスの配置とスピルオーバー の説明に従って配置フィールドを設定してください。オブジェクトストレージの前提条件については、サンドボックスに AI Object Storage へのアクセスを許可する を参照してください。
指定できるフィールドはこの一覧に限られます。このエンドポイントでは、ボリューム、インスタンスタイプ、ランタイムクラス、イメージをプルするための認証情報、公開サービスは利用できません。これらが必要な場合は、POST /v1/sandboxes を使用してください。
サンドボックスを作成する
Compose ファイルを作成します。Write compose.yaml
contents を base64 エンコードして POST します。
Create a sandbox from compose.yaml
STATE_CREATING 状態のサンドボックスです。STATE_RUNNING または終端状態になるまで、その sandboxId をポーリングします。
Poll the sandbox
main はプライマリとして指定され、HELPER_HOST は引き続き helper に設定されています。サンドボックス内では、helper は 127.0.0.1 に解決されます。
作成を安全に再試行するには、requestId を送信します。同じ requestId と同じ宣言済みの入力を使用すると、既存のサンドボックスが返されます。同じ requestId でもバイト列が異なる場合は、空白のみの変更も含め、理由 CWSANDBOX_REQUEST_ID_CONFLICT とともに ALREADY_EXISTS が返されます。
Compose のサポート
すべてのサービスは、1 つの Pod と 1 つのネットワーク namespace を共有します。サービス名は127.0.0.1 に解決されるため、HELPER_HOST: helper や API_BASE: http://main:8080 などの値は、ファイルを書き換えずに使用できます。サンドボックスには、サービスごとの IP アドレス、ブリッジネットワーク、レプリカはありません。
以下の動作は Docker Compose と異なります。
- 起動は逐次実行されます。 プライマリ以外の各サービスは、プライマリより先に、順番に起動します。これを考慮して
maxLifetimeSecondsを設定してください。サービスが準備完了にならない場合、サンドボックスはSTATE_CREATINGのままになります。 RUNNINGはプライマリのみをトラッキングします。 起動後にヘルパーがクラッシュしても、サンドボックスは失敗しません。healthcheckは exec のみの起動プローブになります。testは string、CMD、CMD-SHELL、またはNONEである必要があり、期間は整数秒で指定する必要があります。プローブの再試行回数を使い切ると、コンテナーは異常とマークされるのではなく、停止されます。- ポートは Pod 内にとどまります。
exposeとportsは待ち受けポートを宣言しますが、外部には公開されません。 - イメージはプル可能である必要があります。 すべてのサービスで、ファイル内の
image:またはimageOverrides内のエントリが必要です。依然としてbuild:が必要なサービスは、UNIMPLEMENTEDを返します。 commandとentrypointは Docker のシェル形式と exec 形式に従います。 イメージのデフォルトを使用するには、これらを省略してください。明示的なnullと[]は拒否されます。- GPU はプライマリ専用です。
deploy.resources.reservations.devicesでgpu機能と正の整数の個数を指定します。 - 名前は DNS-1123 ラベルである必要があります (
My_Appではなくmy-app) 。また、予約済みの接頭辞cw-object-store-agent、cw-object-store-agent-restore、dns-egressは使用できません。
サポートされないキー
ドキュメントは自己完結している必要があります。ゲートウェイはディスクを読み取らず、環境変数も展開しません。認識されないキーは無視されず、問題のあるフィールドのパスとともに拒否されます。
ゲートウェイは
version、project の name、labels、x-* 拡張キーを無視します。labels がサンドボックスに渡されることを前提にしないでください。
よくあるエラー
フィールド違反は、パスと制限値を示すBadRequest の詳細として返されます。ドキュメントの内容は引用されません。
関連情報
- はじめに: spec から最初のサンドボックスを作成します。
- API の概要: 認証、バージョン管理、エラー処理について説明します。
- サンドボックスの環境変数: プラットフォームが各コンテナーに注入する環境変数について説明します。