Edge Forms

日本語

English

日本語

English

配色

Edge Forms ​

Worker、ストレージ、キュー、ワークフロー、Actorの設定と振る舞いを定めるForm定義です。コードのバージョン、トラフィック、データ、実行のきっかけを分けて組み合わせ、変更したい部分を指定できます。各ページで用途、組み合わせ、設定項目、正確なパッケージ参照を確認できます。

共通モデルとAPIの説明先 ​

このサイトでは、Edge Formsの公開元が提供する契約と、パッケージに含まれる正確な例を確認できます。公開元に共通するモデルとHost APIは、別のTakoformのサイトとHost APIリファレンスで説明しています。FormごとのdefinitionVersionはAPIプロトコルの版とは別です。クライアントライブラリとTerraform/OpenTofuプロバイダーも、それぞれ独立した版で公開されます。これらを同期させる独立した仕様の版はありません。

Workerアプリケーション ​

ModuleWorker → WorkerVersion → WorkerDeploymentの順に、アプリケーションの識別子、コードと設定のバージョン、トラフィックの割り振りを定義します。 WorkerBundleはコードの成果物を特定します。WorkerEndpointとWorkerCustomDomainは、デプロイへの接続方法を定義します。

やりたいことから選ぶ ​

ストレージは、SQLでの検索やトランザクションならSQLite、オブジェクト本体と書き込み後の強い読み取り一貫性ならObjectBucket、反映の遅れを許容できるキー・バリューデータならEdgeKVNamespaceを選びます。

Queue・Workflow・Actorの違い ​

  • AtLeastOnceQueue 0.1.0: 画像処理などの独立したジョブを貯め、受信側で処理する。順序を保証しない、少なくとも1回の配信。重複を安全に処理する。
  • DurableWorkflow 0.1.0: レポート生成 → 承認待ち → 配信など、進捗を保って続きを実行する。記録済みの結果を再利用するが、記録前の副作用は重複し得る。冪等性とコード変更時の再実行互換性が必要。
  • ActorNamespace 0.1.0: 部屋やセッションのIDごとに状態を持ち、呼び出しを順番に扱う。Formで設定するのは名前空間とクラス。ActorのIDごとにインフラのリソースを作らない。

組み合わせの流れ ​

  • HTTP：Workerの識別子を作り、コードのArtifactを確定し、両方を参照するバージョンを作成します。Deploymentでトラフィックを割り当て、EndpointまたはCustomDomainでそのWorkerの有効なデプロイへHTTPを接続します。バージョンを作るだけでは公開されません。
  • Queue：WorkerVersionの送信側Binding → AtLeastOnceQueue → QueueConsumer → ModuleWorkerのqueueハンドラー。送信と受信は別の接続で、QueueConsumerは送信側Bindingではありません。送信側と受信側に別のWorkerを使えます。
  • SQL：順序付きSQLをマイグレーションのArtifactとして定義し、SQLiteMigrationSetで特定し、SQLiteMigrationApplicationでそのセットとデータベースを指定します。コードからの接続は、別にWorkerVersionのBindingで行います。Applicationを削除してもSQLは元に戻りません。

現在のForms ​

署名付きのEdge Formsは17種類です。公開パッケージの内容を取得して検証済みです。

Form用途
ActorNamespace 0.1.0IDごとに状態を保存し、処理を順番に実行するActorの名前空間を定義します。
AtLeastOnceQueue 0.1.0順序を保証せず、少なくとも1回配信するメッセージをキューに保存します。
DurableWorkflow 0.1.0プロセスが終了しても、インスタンスの処理を再開できる複数段階のワークフローを定義します。
EdgeKVNamespace 0.1.0キーと値のバイト列を、結果整合性のストレージに保存します。
ModuleWorker 0.1.0Workerアプリケーションに、変わらない識別子を付けます。
ObjectBucket 0.1.0書き込み後の強い読み取り一貫性を持つオブジェクトを保存・ストリーミングします。
QueueConsumer 0.1.0キューのメッセージをWorkerのqueueハンドラーに配信します。
SQLiteDatabase 0.1.0edge.sql Interfaceを通してリレーショナルデータを扱います。
SQLiteMigrationApplication 0.1.0一つのデータベースに、指定したマイグレーションセットを適用します。
SQLiteMigrationSet 0.1.0順序が固定された、変更不可のSQLマイグレーション履歴を指定します。
StaticAssetBundle 0.1.0Workerと一緒に配信する、変更不可の静的ファイルを指定します。
WorkerBundle 0.1.0Workerコードの変更不可のビルド成果物を指定します。
WorkerCronTrigger 0.1.0UTCのcronスケジュールに従ってWorkerのscheduledハンドラーを呼び出します。
WorkerCustomDomain 0.1.0管理しているホスト名を、Workerの有効なデプロイに接続します。
WorkerDeployment 0.2.0トラフィックを受け取るWorkerのバージョンを選びます。
WorkerEndpoint 0.1.0有効なデプロイを、Hostが割り当てたHTTPSアドレスで公開します。
WorkerVersion 0.3.0コード・ハンドラー・設定の組み合わせを、変更不可のバージョンとして定義します。

定義を使う ​

Formを選び、利用するHostがその正確なバージョンに対応しているかを確認し、設定のスキーマをクライアントで使います。掲載している例はJSONデータであり、OpenTofuの設定や完全なHost APIリクエストではありません。

まず設定例を見る場合は、パッケージに含まれるWorkerVersion 0.3.0のJSON例をご覧ください。どの例も設定の形を示すデータで、Host APIのリクエストやOpenTofuの設定ではありません。

Hostの対応や受け入れ判断は、パッケージの公開とは別です。パッケージを読むだけでリソースが作成されたり、ホスティングが提供されたりすることはありません。 検証方法はTakoformの導入ガイド、クライアントやHostの実装は実装ガイドを参照してください。

  • アプリを作る：利用するHostのドキュメントで接続先・認証・対応する正確なFormRefを確認し、そのHostで使うOpenTofuの案内またはGoクライアントの手順へ進みます。ここに載せたJSONは設定の形を読む例で、配備手順ではありません。
  • Hostやクライアントを実装する：Coreの実装ガイドで共通APIと検証の手順を確認します。各Formの振る舞いを実装する必要があり、Schemaの検証だけでは対応済みになりません。
  • 定義を検証する：各ページのパッケージ参照から、正確なタグ・ダイジェスト・Schemaを照合します。パッケージ検証は利用するHostへの接続なしで試せます。

過去のバージョン ​

以前の定義も元のURLで取得できます。現在の署名セットには含まれません。