サンドボックスのライフサイクル

アプリは サンドボックス ID でサンドボックスを指定します。コマンドを実行し、ローカルファイルを保持する Linux 環境が コンテナ です。ID は、個々のコンテナより長く残ることがあります。

この区別は、プロセス、ターミナル、ファイル、およびアイドル停止や置換のあとの復旧に関わります。

多くのアプリは、ユーザーまたはタスクごとに 1 つのサンドボックスを使います。

const sandbox = getSandbox(env.Sandbox, "user-123");

const sandbox = getSandbox(env.Sandbox, "user-123");

同じサンドボックス ID でも、同じコンテナとは限りません。 コンテナが停止または置換されたあと、その ID 向けの次の処理は新しいコンテナで動くことがあります。

getSandbox() はすぐに戻ります。この呼び出しだけではコンテナは起動しません。

コンテナは、操作が必要になったときに起動します。たとえば exec()、createTerminal()、ファイルの書き込みです。デプロイ後またはアイドル後の初回起動は、ウォームな呼び出しより時間がかかることがあります。コンテナがまだ準備できていない場合、SDK は ContainerUnavailableError を投げることがあります。このエラーは、操作がコンテナ内で開始されなかったことを意味します。エラーと復旧 を参照してください。

サンドボックス ID 向けにコンテナが起動しているあいだ:

• プロセスとターミナルは、終了するか、停止するまで動き続けます。
• ローカルファイルは、そのコンテナ内で使えます。
• あとからの Worker リクエストは、その コンテナにリソースが残っているかぎり、getProcess または getTerminal を呼んで続行できます。

プロセスの詳細: プロセスの存続期間。ターミナル: ターミナル。

コンテナは永続しません。Cloudflare は、アイドル時間が過ぎると停止することがあります。障害のあとや、通常運用での置換時（一部のデプロイ後など）にも停止します。

その場合:

• アプリは、同じサンドボックス ID を使い続けます。
• 古いコンテナのプロセスとターミナルはなくなります。ID とライブのログバッファーも含みます。
• 古いコンテナのローカルファイルは、アプリが復元しないかぎりなくなります（バックアップ やマウントしたバケットなど）。
• 次に実際の作業が走ると、同じサンドボックス ID 向けに 新しい コンテナが起動することがあります。
• 以前のコンテナのハンドルはフェイルクローズします。リソースが現在のコンテナにない場合、getProcess と getTerminal は null を返します。これらの照会は、答えを返すためだけにコンテナを起動しません。

あとで作業を続けるには、プロセス ID やターミナル ID だけでなく、ジョブ（実行内容、cwd、env、アプリのチェックポイント）を保存します。

アイドル停止または置換のあと、次に実際の作業が走ると、同じサンドボックス ID 向けに 新しい コンテナが起動することがあります。古いプロセスとターミナルのハンドルは無効です。復旧手順: エラーと復旧。

keepAlive と sleepAfter はアイドル動作を変えます。1 つのコンテナインスタンスを永続させるわけではありません。安定版の ライフサイクル API と サンドボックスオプション を参照してください（@next では transport と default-session のオプションは無視します）。

アプリ が保持（または復元）したものだけが、新しいコンテナでも残ります。

• プロセスの実行
• ターミナル
• エラーと復旧
• コンテナのライフサイクル
• 安定版: サンドボックスのライフサイクル