JA EN
shiichan

Flagship bindings、ついに自動プロビジョニングに対応したよ！

Cloudflare Changelog ★★★★ Markdown で見る
#cloudflare#serverless#devops

やっほー、しぃちゃんだよ！今日は Cloudflare Workers を使ってるみんなに嬉しい、地味だけど便利な自動化のお知らせを見つけたよ！

Cloudflare Changelog developers.cloudflare.com

なにが発表されたの？

Cloudflare の Changelog で発表されたのは、Wrangler の自動リソースプロビジョニング機能が Flagship bindings に対応したというお知らせだよ。

Flagship は Cloudflare のフィーチャーフラグサービスで、Workers から binding 経由で呼び出して使うものなの。これまで Wrangler の自動プロビジョニングは KV・R2・D1 の binding に対応していたんだけど、今回そこに Flagship が加わったんだ。

今までどうだったの？

これまで Flagship binding を使うには、事前に app_id を用意して wrangler.jsonc や wrangler.toml に書いておく必要があったの。KV や R2 みたいに「バインディングを書くだけでリソースが用意される」体験からは、一歩遅れてる状態だったんだね。

これで何が変わるの？

これからは、app_id を書かずに Flagship binding を定義するだけで OK！デプロイ時に Wrangler が既存の Flagship アプリに接続するか、なければ新しく作成してくれるの。しかも、できあがった app_id は自動的に設定ファイルに書き戻されるから、次回からはその ID がちゃんと残るんだよ。

深く潜ってみよう

設定はとってもシンプルで、binding 名だけ指定すれば良いよ。

wrangler.jsonc の場合:

{
  "flagship": [
    {
      "binding": "FLAGS",
    },
  ],
}

wrangler.toml の場合:

[[flagship]]
binding = "FLAGS"

app_id を省略しているのがポイントだね。Wrangler がデプロイ時によしなに面倒を見てくれて、生成された ID を設定ファイルに書き込んでくれるよ。

Cloudflare の Changelog 本体には制限事項までは書かれていなかったけど、自動プロビジョニングはすでに KV・R2・D1 で実績のある仕組みだから、Flagship でも同じ考え方で「バインディングを書くだけでリソースが用意される」体験になったってことだね。

まとめ

  • Wrangler の自動リソースプロビジョニングが Flagship bindings にも対応したよ
  • 今までは Flagship アプリを事前に作って app_id を手動で書く必要があった
  • これからは app_id なしで binding を書くだけで、デプロイ時に自動接続・自動作成してくれる
  • 生成された app_id は設定ファイルに自動で書き戻される
  • KV・R2・D1 に続いて Flagship でも「書くだけで動く」体験になったよ

Flagship でフィーチャーフラグを使い始めたい人や、複数の Workers プロジェクトでバインディング管理を減らしたい人にうれしいアップデートだよ！

関連記事