Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

ロールアウト

最終更新 Markdown で表示Agent セットアップ

ロールアウトの仕組み

ロールアウトは、Containers を使う Worker を デプロイ したあと、対象のコンテナアプリケーション設定を適用します。対象には、イメージ、インスタンスタイプ、制限、配置、その他のコンテナ設定の変更が含まれます。

コンテナインスタンスは、Cloudflare のネットワーク上で動いているコンテナイメージの 1 つのコピーです。イメージが起動するプロセス(Dockerfile の ENTRYPOINT/CMD、またはベースイメージの既定)を実行します。対象がイメージを変えると、ロールアウトはコンテナインスタンスを、対象イメージを実行するコピーに置き換えます。ロールアウトは Durable Object のストレージを変更しません。

既存のコンテナアプリケーションの実効設定が変わると、wrangler deploy は次を行います。

  1. Durable Object クラスのコードを含む、新しい Worker バージョンをアップロードして有効化します。
  2. 必要に応じて Dockerfile イメージをビルドしてプッシュするか、設定したレジストリイメージ参照を使います。
  3. 対象のコンテナ設定を適用するロールアウトを開始します。

Worker は、イメージとロールアウトの手順が始まる前に有効になります。これらの手順はトランザクションではないため、後続のイメージまたはロールアウト手順が失敗しても、Worker は有効のままになります。デプロイ成功は、ロールアウトが始まったことを意味します。すべてのコンテナインスタンスの置き換え完了ではありません。初回デプロイはコンテナアプリケーションを直接作成します。実効的なコンテナ変更がないデプロイでは、ロールアウトは始まりません。

イメージが変わると、ロールアウトが終わるまで、新しい Worker コードは以前のイメージ上のコンテナインスタンスに到達できます。その期間中も両立する Worker とイメージの変更を選ぶか、プラットフォームが許す最短の混在期間にしたい場合は immediate を使います。

フィールド名と許可される値は Containers configuration にあります。

既定値

設定 既定値
rollout_step_percentage max_instances が省略されているか 2 未満なら 100。それ以外は [10, 100]
rollout_active_grace_period 0
コンテナインスタンス置き換え時の停止順 メインプロセスへ SIGTERM。終了しなければ 15 分後に SIGKILL

段階的ロールアウト

既定では、Wrangler は rollout_step_percentage を使ってローリングロールアウトを開始します。max_instances が省略されているか 2 未満なら、Wrangler は 100 の 1 ステップを使います。それ以外は [10, 100] を要求します。

  1. 新しい設定のコンテナインスタンスを、おおよそ 10% を対象にします。設定した max_instances で少なくとも 1 インスタンスになるよう、プラットフォームが必要に応じてこの割合を上げます。
  2. 新しい設定のコンテナインスタンスを 100% 対象にします。

ステップは Wrangler の rollout_step_percentage で設定します。1 回のデプロイだけ既定プランを上書きするには --containers-rollout を使います。

コンテナインスタンスの置き換え方法

ロールアウトが更新対象のコンテナインスタンスを選ぶと、次の順で進みます。

  1. 猶予期間(設定している場合)。 rollout_active_grace_period0 より大きい場合、Durable Object に接続して間もないコンテナインスタンスは、その期間を過ぎるまでスキップされます。既定の 0 では追加の待機はありません。ロールアウトのアクティブ猶予期間 を参照してください。
  2. 停止シグナル。 プラットフォームはコンテナ内のメインプロセスへ SIGTERM を送ります。新しい作業の受付を止め、実行中の作業を終えられます。終了前にクリーンアップが必要なら、イメージ側で SIGTERM を処理してください。
  3. ドレイン。 プロセスは SIGTERM のあと、最大 15 分で終了できます。
  4. 必要なら強制停止。 15 分後もプロセスが動いていれば、プラットフォームは SIGKILL を送ります。
  5. 終了後。 コンテナプロセスが終了すると、Worker で Container クラスの onStop フックが実行されることがあります。
  6. 対象イメージで新しいコンテナインスタンスを起動します。 データをコンテナファイルシステム外に保存しない限り、ディスクは エフェメラル です。

選ばれた各コンテナインスタンスは、それぞれ独自のタイミングでこの手順を進みます。フリート全体が一斉に再起動するわけではありません。

コンテナインスタンス起動中のリクエスト

新しいコンテナインスタンスは、プロセスを起動する必要があります。起動には、イメージサイズと起動時の処理に応じて、秒単位の時間がかかることが多いです。コールドスタート を参照してください。

そのコンテナインスタンスを必要とするリクエストは、コンテナの準備完了まで待つか、クライアントまたは Worker のタイムアウトが起動より短い場合は失敗します。起動処理は短くし、設定している場合はポートの準備確認を使い、起動時間を踏まえてタイムアウトを設定してください。

ロールアウトのアクティブ猶予期間

rollout_active_grace_period は、ロールアウト中にプラットフォームが置き換えるコンテナインスタンスを選ぶときだけ適用されます。

Containers は Durable Objects を基盤にします。実行中の各コンテナインスタンスは、起動してトラフィックを送る Durable Object インスタンスに紐づきます。猶予期間は、ロールアウトがそのコンテナを停止する前に、その接続がすでに継続している必要がある時間です。デプロイ完了からの計測ではありません。

効果
0(既定) 追加の保護はありません。選ばれたコンテナインスタンスは、ロールアウトが到達した時点で置き換えられます。
0 より大きい値(例: 300 Durable Object への接続がこの秒数未満のコンテナインスタンスは、期間を過ぎるまでそのままにします。

短いセッションを、ロールアウトがコンテナを置き換える前に終えたい場合は、0 以外の値を使います。接続が期間を超えたコンテナインスタンスは、期間経過後に置き換えられます。

rollout_active_grace_periodimmediate を含む、すべてのロールアウトモードで適用されます。

ロールアウトモード

--containers-rolloutwrangler deploy にだけ適用されます。wrangler versions upload には適用されません。

フルデプロイでは、Wrangler はコンテナイメージとロールアウトを処理する前に Worker を有効化します。ロールアウトモードは、対象のコンテナ設定の適用方法を制御します。

モード フラグ コンテナインスタンス
Gradual(既定) フラグなし rollout_step_percentage を使います。ステップは 1 つまたは複数です
Immediate --containers-rollout=immediate コンテナインスタンスの 100% を 1 ステップで対象にします
None --containers-rollout=none イメージと実行中のコンテナインスタンスは変えず、Worker コードだけデプロイします

Immediate

Immediate は、ロールアウト計画を、コンテナインスタンスの 100% を対象とする 1 ステップにします。中間の割合での待機はありません。

npx wrangler deploy --containers-rollout=immediate

Worker コードとコンテナイメージの互換性を保ちたいとき、混在期間をプラットフォームが許す最短にしたいときに Immediate を使います。たとえば、Worker がイメージ内プロセスと話す方法が破壊的に変わる場合です。

動作は次のとおりです。

  • 新しい Worker バージョンは、コンテナイメージとロールアウトの処理より先に有効化されます。
  • そのあとロールアウトは、段階的モードと同じ 置き換え手順 でコンテナインスタンスを 100% に向けて置き換えます。猶予期間を設定している場合も含みます。
  • 置き換えは実時間で進みます。所要時間は、実行中のコンテナインスタンス数、各インスタンスの停止と起動にかかる時間、猶予期間に依存します。
  • イメージが変わる場合、Immediate は新しい Worker が以前のイメージ上のインスタンスに到達する期間を最短にしますが、なくすことはできません。
  • デプロイ成功は、ロールアウトが始まったことを意味します。置き換え完了ではありません。

None

None は、イメージと実行中のコンテナインスタンスを変えず、Worker コードだけデプロイします。

新しいイメージの公開や、コンテナインスタンスのロールアウトを始めないデプロイに使います。image が Dockerfile パスで Docker が使えない場合、コンテナ手順をスキップするためにこのフラグ、または動作する Docker 環境が必要になることがあります。

設定例

rollout_active_grace_period を 300 秒(5 分)、ステップを [10, 100] にする例です。

{
	"containers": [
		{
			"max_instances": 10,
			"class_name": "MyContainer",
			"image": "./Dockerfile",
			"rollout_active_grace_period": 300,
			"rollout_step_percentage": [10, 100],
		},
	],
	"durable_objects": {
		"bindings": [
			{
				"name": "MY_CONTAINER",
				"class_name": "MyContainer",
			},
		],
	},
	"migrations": [
		{
			"tag": "v1",
			"new_sqlite_classes": ["MyContainer"],
		},
	],
}
[[containers]]
max_instances = 10
class_name = "MyContainer"
image = "./Dockerfile"
rollout_active_grace_period = 300
rollout_step_percentage = [ 10, 100 ]

[[durable_objects.bindings]]
name = "MY_CONTAINER"
class_name = "MyContainer"

[[migrations]]
tag = "v1"
new_sqlite_classes = [ "MyContainer" ]

関連

役に立ちましたか?