よくある質問

ダッシュボードでログを取得するには（ライブテールを含む）、Worker の wrangler 設定で observability を true にします。

{
	"observability": {
		"enabled": true
	}
}

[observability]
enabled = true

ログには Worker ログと同じ制限 が適用されます。保持期間は Free プランで 3 日、Paid プランで 7 日です。

料金の詳細は Workers Logs Pricing を参照してください。

Enterprise ユーザーは、Logpush でコンテナログを任意の送信先へエクスポートできます。

Container を最初にデプロイすると、Cloudflare はネットワーク上の複数の場所を選び、インスタンスを配置します。これらの場所は複数リージョンにまたがります。

this.ctx.container.start でコンテナインスタンスが要求されると、事前初期化された場所から、最も近い空きコンテナインスタンスが選ばれます。外部リクエストと同じリージョンになることが多いですが、そうならない場合もあります。コンテナインスタンスが動き始めると、以降のリクエストはその最初の場所へルーティングされます。

例:

• 利用者が Container をデプロイします。Cloudflare はネットワーク全体でインスタンスを自動的に準備します。
• アルゼンチンのバリローチェにいるクライアントからリクエストが来ます。アルゼンチンのネウケンにある Cloudflare の場所の Worker に到達します。
• この Worker リクエストは MY_CONTAINER.get("session-1337") を呼び、Durable Object を起動し、その Durable Object が this.ctx.container.start を呼びます。
• 最も近い空き Container インスタンスを要求します。
• Cloudflare は、アルゼンチンのブエノスアイレスに空きインスタンスがあることを認識し、そこで起動します。
• 別の利用者が同じコンテナへルーティングする必要があります。この利用者のリクエストは、サンディエゴにある Cloudflare の場所の Worker に到達します。
• Worker は再び MY_CONTAINER.get("session-1337") を呼びます。
• 最初のコンテナインスタンスがまだ動いていれば、リクエストはブエノスアイレスの場所へルーティングされます。最初のコンテナがスリープしていれば、Cloudflare は再び最も近い「空き」Container インスタンスを探します。北米のインスタンスになることが多く、そこでインスタンスを起動します。

wrangler deploy では、まず Worker が有効になります。コンテナインスタンスは、既定では段階的ロールアウトで更新されます。ステップ、猶予期間、モードは ロールアウト を参照してください。デプロイの実行は Deploy Containers を参照してください。

本番ブランチでは、イメージとコンテナインスタンスを更新できるよう、Workers Builds は wrangler deploy を実行してください。本番以外の Workers Builds の既定は wrangler versions upload で、イメージは更新しません。Containers の Worker は Durable Objects を実装するため、プレビュー URL は生成されません。Deploy Containers を参照してください。

Containers は、特定のインスタンスを作成するか、そのインスタンスを指定してスケールします。交換可能な固定数のインスタンスへステートレスにルーティングするには、getRandom ヘルパーを使います。

詳細は スケーリングとルーティング を参照してください。

現時点では使えません。Cloudflare は将来のリリースで組み込みオートスケールを追加する予定です。

それまでは、単純なステートレスルーティングには getRandom を使い、コンテナのライフサイクルを明示的に制御したい場合は特定のインスタンス ID を使います。

コールドスタートは、完全に停止した状態からコンテナインスタンスを起動することです。

まったく新しい ID で env.MY_CONTAINER.get(id) を呼び、そのインスタンスを初めて起動すると、コールドスタートになります。

このとき、コンテナイメージはエントリポイントから初めて起動します。エントリポイントの処理内容によって、起動時間は変わります。

コンテナのコールドスタートは 1〜3 秒程度になることが多いですが、イメージサイズやコードの実行時間など、複数の要因に依存します。

Image management を参照してください。

ディスクはすべてエフェメラルです。Container インスタンスがスリープしたあと、次に起動すると、コンテナイメージで定義された新しいディスクになります。

スナップショットは近日対応予定です。コンテナ全体またはディレクトリからディスクをすばやく永続化して復元できます。

ディスクを R2 や他のオブジェクトストレージバックエンドへ永続化するには、FUSE も使えます。ただし、FUSE 利用時にネイティブ SSD 並みの性能は期待しないでください。

メモリ不足になると、インスタンスは Out of Memory（OOM）エラーを投げ、再起動されます。

Containers はスワップメモリを使いません。

Cloudflare は、固定の最大実行時間でコンテナインスタンスを停止しません。Container クラスは sleepAfter の既定を 10 分にします。既定の onActivityExpired() 実装は、その期間アクティビティがなければコンテナに停止を通知します。期間の変更やフックの上書きもできます。フックでインスタンスを動かし続けても、別のプラットフォームイベントで停止することがあります。その一例がホストサーバーの再起動で、不定期に発生します。Cloudflare は、コンテナインスタンスが一定時間動き続けることを保証しません。

プラットフォームがコンテナインスタンスを停止する直前（ホストがサーバーから作業を移す前を含む）は、次を行います。

1. コンテナ内のメインプロセスへ SIGTERM を送ります。
2. そのプロセスが終了するまで最大 15 分待ちます。
3. まだ動いていれば SIGKILL を送ります。

終了前にクリーンアップが必要なら、イメージ側で SIGTERM を処理してください。ホスト停止のあと、トラフィックが再び必要になると、別のサーバーで新しいコンテナインスタンスが起動することがあります。

デプロイ中のイメージ更新も、同じ停止手順を使います。ロールアウト を参照してください。

Worker のシークレットは Worker Secrets または Secrets Store で定義できます。

実装の詳細は Environment variables and secrets を参照してください。

できます。Containers は root 権限なしで動くため、docker:dind-rootless ベースイメージを使います。

Containers は iptables の操作に対応していないため、Docker デーモン起動時は iptables を無効にしてください。

FROM docker:dind-rootless

# Start dockerd with iptables disabled, then run your app
ENTRYPOINT ["sh", "-c", "dockerd-entrypoint.sh dockerd --iptables=false --ip6tables=false & exec /path/to/your-app"]

アプリケーションが Docker を使う前に dockerd の準備完了を待つ必要がある場合は、上のインラインコマンドではなくエントリポイントスクリプトを使います。

#!/bin/sh
set -eu

# Wait for dockerd to be ready
until docker version >/dev/null 2>&1; do
  sleep 0.2
done

exec /path/to/your-app

動作する完全な例は Docker-in-Docker Containers example ↗ を参照してください。

アウトバウンドトラフィックとインターネットアクセスの制御は Handle outbound traffic を参照してください。