Automatisation Discourse est vraiment géniale et utile, mais les automatismes disponibles sont assez limités. Beaucoup d’entre eux semblent être des solutions ponctuelles[1] destinées à répondre à des cas d’utilisation spécifiques de clients CDCK, plutôt que des outils à usage général.
Il est possible de créer des automatismes personnalisés, mais il n’y a aucun moyen pour les clients hébergés de les intégrer, à ma connaissance. De plus, ils semblent pouvoir être assez dangereux. Je suis sûr que je pourrais travailler avec le personnel sympathique de Discourse pour faire déployer un automatisme que j’ai écrit, mais cela semble demander beaucoup de travail des deux côtés.
Voici donc mon idée :
- Une interface d’administration[2] où l’on pourrait fournir des liens vers des images OCI[3] (en utilisant
registry.example.org/imagename:tag). - Un moyen d’associer une clé API à cette image (lié à la page d’administration existante des clés API).
- Un moyen d’associer un webhook à cette image (lié à la page d’administration existante des webhooks).
- Soit ajouter une option de planification récurrente pour cela, soit (mieux, je pense !) l’ajouter aux webhooks de manière générique.
Un broker/dispatcher écouterait les webhooks, les transmettrait au conteneur correspondant, en fournissant la clé API comme secret et la charge utile via stdin ou à un port http. (J’imagine que beaucoup d’entre eux seraient "à usage unique" — le conteneur démarrerait, traiterait un événement et se terminerait — mais il pourrait y avoir une option pour des conteneurs persistants (ou, peut-être, pour écouter pendant N secondes avant de se terminer).
Les conteneurs seraient exécutés avec des limites de ressources raisonnables, et soit sans stockage persistant, soit avec un accès aux mêmes pièces jointes de pool de stockage et autres éléments. Pour les sites hébergés, j’imagine le temps CPU d’automatisation comme une autre limite par plan, en plus des pages vues, des e-mails et du stockage.
L’emplacement de l’API du site pourrait être fourni soit comme variable d’environnement, soit comme un autre secret. Les autres accès réseau seraient interdits par défaut, bien qu’il devrait être possible d’autoriser des connexions sortantes spécifiques.
On peut, bien sûr, mettre en place une telle chose dès maintenant "à côté", mais l’avoir intégrée aux interfaces d’administration de l’API et des Webhooks serait vraiment élégant (et réglerait pratiquement entièrement le problème de la gestion des secrets). De plus, la configuration du dispatcher/broker est un peu compliquée.