段階的デプロイ

段階的デプロイを使用すると、トラフィックをバージョン間で分割することで、Workersの新しいバージョンを段階的にデプロイすることができます。

段階的デプロイ

段階的デプロイを使用すると、以下のことができます：

新しいバージョンのWorkerにトラフィックを徐々にシフトする。
分析とロギングツールを使用して、バージョン間のエラー率や例外を監視する。
新しいバージョンをデプロイする際に問題が発生した場合、以前の安定したバージョンにロールバックする。

段階的デプロイの使用

以下のセクションでは、段階的デプロイの使用例を案内します。あなたは、WranglerまたはCloudflareダッシュボードを使用して：

新しいWorkerを作成する。
そのWorkerの新しいバージョンをデプロイせずに公開する。
2つのバージョン間で段階的デプロイを作成する。
新しいバージョンのデプロイをトラフィックの100%に進める。

Wranglerを使用して

1. 新しいWorkerを作成してデプロイする

create-cloudflare CLI (C3)を使用して新しい「Hello World」Workerを作成し、デプロイします。

npm create cloudflare@latest <NAME> -- --type=hello-world

TypeScriptを使用するかどうかに対してyesまたはnoで答えます。アプリケーションをデプロイする際にはyesと答えます。これがあなたのWorkerの最初のバージョンです。

2. Workerの新しいバージョンを作成する

Workerの新しいバージョンを作成するには、Workerコードを編集してResponseの内容を希望のテキストに変更し、wrangler versions uploadコマンドを使用してWorkerをアップロードします。

npx wrangler versions upload

これにより、自動的にデプロイされない新しいバージョンのWorkerが作成されます。

3. 新しいデプロイメントを作成する

wrangler versions deployコマンドを使用して、Workerの2つのバージョン間でトラフィックを分割する新しいデプロイメントを作成します。インタラクティブなプロンプトに従って、ステップ#1とステップ#2でアップロードしたバージョンを使用してデプロイメントを作成します。各バージョンの希望のパーセンテージを選択します。

npx wrangler versions deploy

4. 分割デプロイメントをテストする

Workerに対してcURLコマンドを実行して分割デプロイメントをテストします。

for j in {0..10}
do
    curl -s https://$WORKER_NAME.$SUBDOMAIN.workers.dev
done

10のレスポンスが表示されるはずです。レスポンスは、デプロイメント内のバージョンによって返される内容を反映します。レスポンスは、ステップ#3で設定したパーセンテージに応じて異なります。

特定のバージョンをターゲットにしてテストすることも、バージョンオーバーライドを使用して行えます。

5. 新しいバージョンを100%デプロイメントに設定する

再度wrangler versions deployを実行し、インタラクティブなプロンプトに従います。ステップ2でアップロードしたバージョンを選択し、100%デプロイメントに設定します。

npx wrangler versions deploy

Cloudflareダッシュボードを使用して

Cloudflareダッシュボード ↗にログインし、アカウントを選択します。
Workers & Pagesに移動します。
アプリケーションを作成 > Hello Worldテンプレート > Workerをデプロイします。
Workerがデプロイされたら、コードを編集を通じてオンラインコードエディタに移動します。Workerコードを編集し（Responseの内容を変更）、Workerをアップロードします。
変更を保存するには、デプロイの隣にある下矢印を選択し、保存を選択します。これにより、新しいバージョンのWorkerが作成されます。
ステップ3と5で作成された2つのバージョン間でトラフィックを分割する新しいデプロイメントを作成するには、デプロイメントに移動し、バージョンをデプロイを選択します。
WorkerにcURLを実行して分割デプロイメントをテストします。

for j in {0..10}
do
    curl -s https://$WORKER_NAME.$SUBDOMAIN.workers.dev
done

10のレスポンスが表示されるはずです。レスポンスは、デプロイメント内のバージョンによって返される内容を反映します。レスポンスは、ステップ#6で設定したパーセンテージに応じて異なります。

バージョンの親和性

デフォルトでは、段階的デプロイを使用する際に設定されたパーセンテージはリクエストごとに操作されます — リクエストは、デプロイメント内の2つのWorkerのいずれかを呼び出すX%の確率を持ちます。

特定の識別子（ユーザー、セッション、または任意のユニークIDなど）に関連付けられたリクエストが、Workerの一貫したバージョンによって処理されることを望むかもしれません。これにより、バージョンスキューを防ぐことができます。バージョンスキューは、互換性のない複数のバージョンのアプリケーションがデプロイされると発生します。リクエストごとにWorkerのバージョンが前後に変わるのを防ぐために、バージョンの親和性を設定できます。

これは、Workerへの受信リクエストにCloudflare-Workers-Version-Keyヘッダーを設定することで行えます。例えば：

curl -s https://$SCRIPT_NAME.$SUBDOMAIN.workers.dev -H 'Cloudflare-Workers-Version-Key: foo'

特定のデプロイメントに対して、バージョンキーがfooに設定されたすべてのリクエストは、同じWorkerのバージョンによって処理されます。バージョンキーfooに対応するWorkerの特定のバージョンは、デプロイメント内で各Workerバージョンに設定したパーセンテージによって決まります。

Cloudflare-Workers-Version-Keyヘッダーは、インターネットからWorkerへの外部リクエストを行う際や、サービスバインディングを使用して1つのWorkerから別のWorkerへのサブリクエストを行う際に設定できます。

ルールセットエンジンを使用した`Cloudflare-Workers-Version-Key`の設定

リクエストの特定のプロパティ（URL、ヘッダー、またはクッキーなど）からバージョンキーを抽出したい場合があります。これを行うために、ゾーンにルールセットエンジンルールを設定できます。これにより、リクエストを行う外部クライアントを変更することなく、これらのプロパティに基づいてバージョンの親和性を指定できます。

例えば、あなたのWorkerがURIパス/assets/の下でビデオアセットを提供し、各ユニークアセットへのリクエストを一貫したバージョンで処理したい場合、次のリクエストヘッダーの変更ルールを定義できます：

式エディタのテキスト：

starts_with(http.request.uri.path, "/asset/")

リクエストヘッダーを変更の下で選択した操作：動的に設定

ヘッダー名：Cloudflare-Workers-Version-Key

値：regex_replace(http.request.uri.path, "/asset/(.*)", "${1}")

バージョンオーバーライド

バージョンオーバーライドを使用して、段階的デプロイメント内の特定のWorkerのバージョンにリクエストを送信できます。

リクエストでバージョンオーバーライドを指定するには、WorkerへのリクエストにCloudflare-Workers-Version-Overridesヘッダーを設定できます。例えば：

curl -s https://$SCRIPT_NAME.$SUBDOMAIN.workers.dev -H 'Cloudflare-Workers-Version-Overrides: my-worker-name="dc8dcd28-271b-4367-9840-6c244f84cb40"'

Cloudflare-Workers-Version-Overridesは辞書構造ヘッダー ↗です。

辞書には複数のキーと値のペアを含めることができます。各キーは、オーバーライドを適用すべきWorkerの名前を示します。値は使用すべきバージョンIDを示し、文字列 ↗でなければなりません。

バージョンオーバーライドは、指定されたバージョンが現在のデプロイメントに存在する場合にのみ適用されます。現在のデプロイメント内のバージョンは、wrangler deployments listコマンドまたはWorkersダッシュボード ↗のWorker > デプロイメント > アクティブデプロイメントで確認できます。

リクエストのバージョンオーバーライドが適用されない理由はいくつかあります。例えば：

指定されたバージョンを含むデプロイメントがまだ伝播していない可能性があります。
ヘッダー値が有効な辞書 ↗でない可能性があります。

リクエストのバージョンオーバーライドが適用されない場合、リクエストは段階的デプロイメント設定で設定されたパーセンテージに従ってルーティングされます。

リクエストのバージョンオーバーライドが正しく適用されたことを確認するには、観察して、呼び出されたWorkerのバージョンを確認できます。このチェックを自動化するために、ランタイムバインディングを使用してWorkerのレスポンスにバージョンを返すこともできます。

例

新しいバージョンを段階的にデプロイする前に、プロダクションでテストしたい場合があります。

この例では、デプロイメントは最初にすべてのトラフィックを単一のバージョンにルーティングするように設定されています：

バージョンID	パーセンテージ
db7cd8d3-4425-4fe7-8c81-01bf963b6067	100%

wrangler versions deployを使用して新しいデプロイメントを作成し、新しいバージョンのパーセンテージを0%に設定し、以前のバージョンを100%のままにします。

バージョンID	パーセンテージ
dc8dcd28-271b-4367-9840-6c244f84cb40	0%
db7cd8d3-4425-4fe7-8c81-01bf963b6067	100%

新しいバージョンをテストするには、バージョンオーバーライドを使用して、徐々に新しいバージョンを100%に進める前に行います：

curl -s https://$SCRIPT_NAME.$SUBDOMAIN.workers.dev -H 'Cloudflare-Workers-Version-Overrides: my-worker-name="dc8dcd28-271b-4367-9840-6c244f84cb40"'

Durable Objectsのための段階的デプロイ

グローバルユニーク性のため、各Durable Objectは同時に1つのバージョンしか実行できません。これにより、Durable Objectsの段階的デプロイは少し異なります。

Durable Object Workerの新しい段階的デプロイを作成すると、各Durable Objectインスタンスは、デプロイメントで設定したパーセンテージに基づいてWorkerバージョンが割り当てられます。このバージョンは、新しいデプロイメントを作成するまで変更されません。

段階的デプロイ Durable Objects

例

この例では、以前に3つのDurable Objectsを作成し、それらのIDを名前から導出した ↗と仮定します。「foo」、「bar」、「baz」。

あなたのWorkerは現在、バージョン「A」にあり、新しいバージョン「B」を段階的にデプロイしたいと考えています。

段階的デプロイを進めるにつれて、Durable Objectsのバージョンがどのように変化するかは次のとおりです：

デプロイメント設定	”foo"	"bar"	"baz”
バージョンA: 100%	A	A	A
バージョンB: 20% バージョンA: 80%	B	A	A
バージョンB: 50% バージョンA: 50%	B	B	A
バージョンB: 100%	B	B	B

これはあくまで例であり、Durable Objectsに割り当てられるバージョンは異なる場合があります。ただし、以下のことは保証されます：

特定のデプロイメントに対して、各Durable Objectへのリクエストは常に同じWorkerバージョンを使用します。
前のデプロイメントと同じ順序で各バージョンを指定し、バージョンのパーセンテージを増加させると、以前にそのバージョンが割り当てられていたDurable Objectsは異なるバージョンに割り当てられません。この例では、Durable Object「foo」はバージョン「B」からバージョン「A」に戻ることはありません。
Durable Objectは異なるバージョンに割り当てられたときにのみリセットされるため、この例では各Durable Objectは1回だけリセットされます。

可観測性

段階的デプロイを使用する際には、新しいバージョンをデプロイする影響を把握するために、Workersの呼び出しを特定のバージョンに帰属させたい場合があります。

Logpush

新しい ScriptVersion オブジェクトが Workers Logpush で利用可能です。 ScriptVersion は現在、Logpush API を通じてのみ追加できます。サンプルAPIコール：

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/logpush/jobs' \
-H 'Authorization: Bearer <TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"name": "workers-logpush",
"output_options": {
    "field_names": ["Event", "EventTimestampMs", "Outcome", "Logs", "ScriptName", "ScriptVersion"],
},
"destination_conf": "<DESTINATION_URL>",
"dataset": "workers_trace_events",
"enabled": true
}'| jq .

ScriptVersion は以下の構造を持つオブジェクトです：

scriptVersion: {
    id: "<UUID>",
    message: "<MESSAGE>",
    tag: "<TAG>"
}

ランタイムバインディング

Version metadata binding を使用して、Worker内でバージョンIDまたはバージョンタグにアクセスします。

制限

デプロイメントの制限

最後にアップロードされた10バージョンのWorkerでのみ、新しいデプロイメントを作成できます。

Cloudflare Dashboard Discord Community Learning Center Support Portal

Cookie Settings

段階的デプロイ

段階的デプロイの使用

Wranglerを使用して

1. 新しいWorkerを作成してデプロイする

2. Workerの新しいバージョンを作成する

3. 新しいデプロイメントを作成する

4. 分割デプロイメントをテストする

5. 新しいバージョンを100%デプロイメントに設定する

Cloudflareダッシュボードを使用して

バージョンの親和性

ルールセットエンジンを使用したCloudflare-Workers-Version-Keyの設定

バージョンオーバーライド

例

Durable Objectsのための段階的デプロイ

例

可観測性

Logpush

ランタイムバインディング

制限

デプロイメントの制限

ルールセットエンジンを使用した`Cloudflare-Workers-Version-Key`の設定