Container 付きのアプリケーションをデプロイすると、イメージは Cloudflare の Registry にアップロードされ、Cloudflare のネットワークへグローバルに配布されます。Cloudflare はインスタンスを事前スケジュールし、イメージを世界中で事前取得します。同時実行の Container インスタンス数をスケールアウトするときに、素早く起動できるようにするためです。
Worker のコードはデプロイ時に本番へ出ます。Container インスタンスは ロールアウト で更新されます。Container をデプロイする を参照してください。
Container は Durable Objects と Workers の上に構築されています。リクエストはまず Worker を経由します。通常は、リクエスト元のユーザーとのレイテンシが最も小さいロケーションのデータセンターが処理します。Smart Placement が有効な場合や、最寄りロケーションの負荷が高い場合は、全体のレイテンシを最適化するために別のデータセンターが選ばれることがあります。
Container へのリクエストはすべて Worker を通るため、エンドユーザーは Container インスタンスに HTTP 以外の TCP や UDP リクエストを送れません。エンドユーザーからの受信 TCP または UDP が必要なユースケースがある場合は、お知らせください ↗。
Worker から、リクエストは Durable Object インスタンスを通ります（Container クラス は Durable Object クラスを拡張します）。各 Durable Object インスタンスは、コードを実行して状態を保存できる、グローバルにルーティング可能な isolate です。これにより、配置場所に関係なく特定の Container インスタンスへ簡単にアドレス指定してルーティングし、Container の状態変化時のフックを定義して実行し、インスタンスの定期チェックを実行し、各インスタンスに紐づく永続状態を保存できます。
Durable Object インスタンスが新しい Container インスタンスの起動を要求すると、イメージを事前取得済みの、最も近いロケーション が選ばれます。
追加の Container インスタンスを起動すると、イメージを事前取得済みの他のロケーションが使われます。Cloudflare は、さらにスケールしてコールドスタートを速くするため、舞台裏で追加のマシンの準備を自動的に始めます。事前ウォーム済みのロケーション数には限りがあるため、一部の Container インスタンスはエンドユーザーから遠いロケーションで起動することがあります。これは、インスタンスを素早く起動するためです。課金対象は稼働中のインスタンスだけです。使っていない事前ウォーム済みイメージには課金されません。
コールドスタートは、完全に停止した状態から Container インスタンスを起動することです。まったく新しい ID で env.MY_CONTAINER.get(id) を呼び出し、このインスタンスを初めて起動すると、コールドスタートになります。このとき、Container イメージはエントリポイントから初めて起動します。起動にかかる時間は、エントリポイントの処理内容によって変わります。
Container のコールドスタートは 1〜3 秒程度になることが多いですが、イメージサイズやコードの実行時間など、さまざまな要因に依存します。
リクエストが新しい Container インスタンスを 起動する とき、イメージを事前取得済みの最も近いロケーションが選ばれます。その後、そのインスタンスへの後続リクエストは、発信元に関係なく、インスタンスが生きている限りこのロケーションへルーティングされます。
ただし、その Container インスタンスが停止して再起動すると、以降のリクエストは 別の ロケーションへルーティングされることがあります。このロケーションは再び、発信元リクエストに最も近く、イメージを事前取得済みの場所になります。
各 Container インスタンスは、専用の VM 内で動作します。これにより、Cloudflare のネットワーク上で動く他のワークロードから強く隔離されます。Container は linux/amd64 アーキテクチャ向けにビルドし、サイズ制限 内に収めてください。
ログ、メトリクス収集、ネットワーキング は、開発者が設定した内容に従い、各 Container で自動的にセットアップされます。
Container クラスは、デフォルトで sleepAfter を 10 分に設定します。デフォルトの onActivityExpired() 実装は、その期間アクティビティがなければ Container に停止を合図します。期間を変更したり、フックを上書きしたりできます。
自分で Container インスタンスを止めるには、stop() または destroy() を使います。
プラットフォームが Container インスタンスを停止する直前には、次の処理を行います。
- Container 内のメインプロセスへ
SIGTERMを送ります。 - そのプロセスが終了するまで最大 15 分待ちます。
- プロセスがまだ動いていれば
SIGKILLを送ります。
終了前にクリーンアップが必要な場合は、イメージ内で SIGTERM を処理してください。ロールアウト が新しいイメージで Container インスタンスを置き換えるときも、同じ手順が走ります。
Container クラス は、Container の状態が変わったときに Worker コードを実行するフックを提供します。
onStart()— Container が起動したあとに実行されます。onStop()— Container プロセスが終了したあとに実行されます。終了コードと停止理由を受け取ります。onActivityExpired()— 受信リクエストがないままsleepAfterタイマーが切れたときに実行されます。デフォルト実装はstop()を呼び出して Container をシャットダウンします。特定の条件のときだけ停止する、といった使い方ができます。onError()— Container がエラーで終了したときに実行されます。
完全な実装は ステータスフックの例 を参照してください。
ディスクはすべてエフェメラルです。Container インスタンスがスリープすると、次に起動したときは Container イメージで定義された新しいディスクになります。
スナップショットは近日公開予定です。Container 全体またはディレクトリからディスクを素早く永続化して復元できます。
FUSE を使って、ディスクを R2 や他のオブジェクトストレージバックエンドへ永続化することもできます。ただし、FUSE 利用時にネイティブ SSD 並みの性能は期待しないでください。
- 開発者が Container をデプロイします。Cloudflare はネットワーク全体でインスタンスを自動的に準備します。
- アルゼンチンのバリローチェにいるクライアントからリクエストが送られます。近くのアルゼンチン・ネウケンにある Cloudflare ロケーションの Worker に届きます。
- この Worker リクエストは
getContainer(env.MY_CONTAINER, "session-1337")を呼び出します。内部では Durable Object が立ち上がり、その Durable Object がthis.ctx.container.startを呼び出します。 - 最も近い空き Container インスタンスが要求されます。Cloudflare はアルゼンチンのブエノスアイレスに空きインスタンスがあると認識し、そこで起動します。
- 別のユーザーが同じ Container へルーティングする必要があります。このユーザーのリクエストは、米国サンディエゴの Cloudflare ロケーションで動く Worker に届きます。
- Worker は再び
getContainer(env.MY_CONTAINER, "session-1337")を呼び出します。 - 最初の Container インスタンスがまだ動いていれば、リクエストは元のブエノスアイレスへルーティングされます。最初の Container がスリープしていれば、Cloudflare は再び最も近い「空き」インスタンスを探し、おそらく北米のインスタンスを起動します。