Cloudflare Containers

概要

輸送用コンテナを思い浮かべてください。アプリ全体と、それが必要とするすべてが一つの密閉された箱に詰め込まれ、どこでも同じように動きます。Cloudflare Containers を使うと、完全な Linux コンテナ — まさにその密閉された箱 — を Cloudflare のネットワーク内部、Workers のすぐ隣で実行できます。Worker が単独ではできないこと — より重いランタイム、特定のプログラムファイル、Workers のサンドボックスに収まらない言語やライブラリ — を必要とするとき、その作業をユーザーの近くで起動するコンテナに引き渡せます。コンテナを定義すると、Worker がインスタンスの起動、停止、スケールのタイミングを制御します。

強み

• 実際のコンテナイメージを実行するため、Workers のサンドボックスでは動かないツールやランタイムを使えます。
• Cloudflare のグローバルネットワーク上で Workers の隣に存在するため、両者間の往復が短くて済みます。
• Worker がコンテナをオーケストレーションするため、すでに持っているルーティング、認証、エッジロジックを維持できます。
• バッチジョブ、メディア処理、ヘッドレスブラウザ、既存の Docker ベースのコードの移植に適しています。
• 需要に応じてスケールし、また縮小するため、アイドル状態のサーバーに四六時中支払う必要がありません。

トレードオフ

• 素の Worker より重く、起動が遅い — コールドスタート（cold start。リクエストが届いたのに何も動いていないときの、立ち上がりの遅れ）は現実に存在するため、あらゆるリクエスト向けではありません。
• 可動部品が増えます。スクリプトだけでなく、イメージ、そのビルド、そしてライフサイクルを管理することになります。
• 同じ単純なタスクに対しては純粋な Worker よりコストがかかります。本当にコンテナが必要なときだけ使いましょう。
• Workers よりまだ新しいため、ツールや制限は進化し続けると考えておきましょう。

使うべきとき

ジョブが本当にフルの OS（オペレーティングシステム）や、エッジでは提供できないランタイムを必要とするとき — 既存の CLI（コマンドラインインターフェース）ツール（コマンドを打ち込んで操作するプログラム）の実行、Workers が対応していない言語、計算負荷の高いステップ — に、エッジネイティブな入り口を Worker に保ちつつコンテナを使いましょう。

バイブコーディングとの相性

これは AI 支援のきれいな対象です。形が馴染みあるものだからです。Dockerfile（コンテナをビルドするレシピ）に加え、それを起動する小さな Worker。汎用的なクラウド VM（仮想マシン。クラウド上で借りるコンピューター）を想定するのではなく、Worker からコンテナへのバインディングを正しく配線できるよう、Cloudflare Containers を使っていることをエージェントに伝えましょう。

// wrangler.jsonc — bind a container to a Worker
{
  "name": "my-app",
  "main": "src/index.ts",
  "containers": [
    { "class_name": "MyContainer", "image": "./Dockerfile" }
  ]
}