Discourse Automation は非常にクールで便利ですが、利用可能な自動化はかなり限られています。その多くは、汎用的なツールというよりは、特定のCDCK顧客の特定のユースケースに対処するために作られた、使い捨てのハック[1] のように見えます。
カスタム自動化を作成する ことは可能ですが、ホストされている顧客がそれらを配置する方法は、私が見る限りありません。さらに、それらはかなり危険である可能性があるようです。私が書いた自動化を展開するために、親切なDiscourseスタッフと協力できることは確かですが、それは双方にとってかなりの労力のように思えます。
そこで、私のアイデアは次のとおりです。
- 管理インターフェイス[2] で、OCI[3] イメージへのリンク（
registry.example.org/imagename:tagを使用）を提供できるようにする。 - そのイメージにAPIキーを関連付ける方法（既存のAPIキー管理ページにリンク）。
- そのイメージにWebhookを関連付ける方法（既存のWebhook管理ページにリンク）。
- これに定期的なスケジュールオプションを追加するか、または（より良いと思います！）それをWebhookに一般的に追加する。
ブローカー/ディスパッチャーは、Webhookを受信して一致するコンテナに転送し、APIキーをシークレットとして、ペイロードを標準入力またはHTTPポートに提供します。（これらは「使い捨て」になるものが多く、コンテナが起動し、1つのイベントを処理して終了すると思いますが、永続的なもの（または、終了する前にN秒間リッスンするオプション）も考えられます。）
コンテナは、合理的なリソース制限で実行され、永続ストレージがないか、同じストレージプールのアタッチメントやその他のものが格納される場所にアクセスできるようにします。ホストされているサイトの場合、自動化CPU時間を、ページビュー、メール、ストレージと並ぶ別のプラン制限として想像できます。
サイトAPIの場所は、環境変数または別のシークレットとして提供できます。他のネットワークアクセスはデフォルトで禁止されますが、特定の送信接続を許可することは可能であるはずです。
もちろん、このようなものを「サイド」でセットアップすることは可能ですが、APIおよびWebhook管理インターフェイスと統合されていれば、非常に洗練されたものになります（そして、シークレットを管理するという問題を基本的に完全に解決します）。さらに、ディスパッチャー/ブローカーのセットアップは少し複雑です。