Discourse Automation ist wirklich cool und nützlich, aber die verfügbaren Automatisierungen sind ziemlich begrenzt. Viele von ihnen scheinen einmalige Hacks zu sein[1], die darauf abzielen, den spezifischen Anwendungsfall eines bestimmten CDCK-Kunden zu lösen, anstatt allgemeine Werkzeuge zu sein.
Es ist möglich, benutzerdefinierte Automatisierungen zu erstellen, aber es gibt keine Möglichkeit für gehostete Kunden, diese einzubinden, soweit ich sehen kann. Außerdem scheinen sie ziemlich gefährlich zu sein. Ich bin sicher, ich könnte mit dem freundlichen Discourse-Personal zusammenarbeiten, um eine von mir geschriebene Automatisierung bereitzustellen, aber das scheint für beide Seiten viel Arbeit zu sein.
Hier ist also meine Idee:
- Eine Admin-Oberfläche[2], in der man Links zu OCI[3]-Images angeben könnte (mit
registry.example.org/imagename:tag). - Eine Möglichkeit, einen API-Schlüssel mit diesem Image zu verknüpfen (verknüpft mit der bestehenden Admin-Seite für API-Schlüssel).
- Eine Möglichkeit, einen Webhook mit diesem Image zu verknüpfen (verknüpft mit der bestehenden Admin-Seite für Webhooks).
- Entweder eine Option für wiederkehrende Zeitpläne hinzufügen oder (was ich besser finde!) dies generell zu Webhooks hinzufügen.
Ein Broker/Dispatcher würde auf die Webhooks lauschen, sie an den passenden Container weiterleiten, den API-Schlüssel als Secret und die Payload entweder über stdin oder an einen HTTP-Port übergeben. (Ich stelle mir vor, dass viele davon “Einmal-Jobs” wären – der Container würde starten, ein Ereignis verarbeiten und beenden – aber es könnte eine Option für persistente Container geben (oder vielleicht, um N Sekunden lang zu lauschen, bevor er beendet wird).
Die Container würden mit angemessenen Ressourcenlimits ausgeführt werden, und entweder ohne persistenten Speicher oder mit Zugriff auf dieselben Speicher-Pool-Anhänge und Dinge, in die sie gehen. Für gehostete Websites kann ich mir die Automatisierungs-CPU-Zeit als eine weitere Begrenzung pro Plan vorstellen, neben Seitenaufrufen, E-Mails und Speicherplatz.
Der Speicherort der Website-API könnte entweder als Umgebungsvariable oder als weiteres Secret angegeben werden. Andere Netzwerkzugriffe wären standardmäßig verboten, obwohl es möglich sein sollte, bestimmte ausgehende Verbindungen zuzulassen.
Man kann so etwas natürlich jetzt schon “nebenbei” einrichten, aber die Integration mit den Admin-Oberflächen für API und Webhooks wäre wirklich elegant (und würde das Problem der Verwaltung von Secrets ansonsten praktisch vollständig lösen). Außerdem ist die Einrichtung des Dispatcher/Brokers etwas kompliziert.