Discourse Automation — это действительно крутой и полезный инструмент, но доступные автоматизации довольно ограничены. Многие из них выглядят как разовые хаки[1], призванные решить конкретную задачу клиента CDCK, а не как универсальные инструменты.
Создать кастомные автоматизации возможно, но, насколько я вижу, для хостинговых клиентов нет способа просто развернуть их. Кроме того, они могут быть довольно опасными. Я уверен, что мог бы договориться с дружелюбной командой Discourse о развертывании написанной мной автоматизации, но это кажется слишком трудозатратным для обеих сторон.
Поэтому у меня есть идея:
- Административный интерфейс[2], где можно будет указывать ссылки на образы OCI[3] (в формате
registry.example.org/imagename:tag). - Возможность привязать API-ключ к этому образу (ссылка на существующую страницу управления API-ключами).
- Возможность привязать вебхук к этому образу (ссылка на существующую страницу управления вебхуками).
- Либо добавить опцию повторяющегося расписания для этого, либо (что, на мой взгляд, лучше!) добавить такую возможность для вебхуков в целом.
Брокер/диспетчер будет слушать вебхуки и перенаправлять их в соответствующий контейнер, передавая API-ключ как секрет, а полезную нагрузку — либо через stdin, либо на HTTP-порт. (Предполагаю, что многие из таких решений будут работать по принципу «один раз»: контейнер запускается, обрабатывает одно событие и завершает работу, но можно предусмотреть опцию для постоянных контейнеров (или, возможно, для работы в течение N секунд перед завершением)).
Контейнеры будут запускаться с разумными ограничениями ресурсов, без постоянного хранилища либо с доступом к тому же пулу хранилища, где хранятся вложения и прочее. Для хостинговых сайтов я могу представить, что время работы автоматизаций на CPU будет еще одним лимитом в рамках тарифного плана, наряду с просмотрами страниц, отправкой писем и объемом хранилища.
Расположение API сайта можно указывать либо как переменную окружения, либо как отдельный секрет. Доступ к другим сетям по умолчанию будет запрещен, хотя должна быть возможность разрешить конкретные исходящие соединения.
Конечно, можно настроить такую систему самостоятельно «на стороне», но интеграция с административными интерфейсами API и вебхуков была бы очень элегантным решением (и практически полностью решила бы проблему управления секретами). Кроме того, настройка диспетчера/брокера немного сложна.