Idea irrealizzabile: script di automazione arbitrari tramite immagine Docker

Discourse Automation è davvero fantastico e utile, ma le automazioni disponibili sono piuttosto limitate. Molte di esse sembrano soluzioni “one-off”[1] create per soddisfare il caso d’uso specifico di un particolare cliente CDCK, piuttosto che strumenti generici.

È possibile creare automazioni personalizzate, ma non vedo alcun modo per i clienti con hosting di inserirle. Inoltre, sembrano poter essere piuttosto pericolose. Sono sicuro che potrei collaborare con il cordiale staff di Discourse per implementare un’automazione che ho scritto, ma ciò sembrerebbe un sacco di lavoro per entrambe le parti.

Quindi, ecco la mia idea:

  1. Un’interfaccia di amministrazione[2] dove si potrebbero fornire link a immagini OCI[3] (utilizzando registry.example.org/imagename:tag).
  2. Un modo per associare una chiave API a quell’immagine (collegata alla pagina di amministrazione delle chiavi API esistenti).
  3. Un modo per associare un webhook a quell’immagine (collegata alla pagina di amministrazione dei webhook esistenti).
  4. Aggiungere un’opzione di pianificazione ricorrente per questo, o (meglio, secondo me!) aggiungerla ai webhook in modo generico.

Un broker/dispatcher ascolterebbe i webhook e li inoltrerebbe al container corrispondente, fornendo la chiave API come segreto e il payload tramite stdin o a una porta http. (Immagino che molti di questi sarebbero “usa e getta” — il container si avviarebbe, elaborerebbe un evento ed uscirebbe — ma potrebbe esserci un’opzione per quelli persistenti (o, forse, per ascoltare per N secondi prima di uscire).

I container verrebbero eseguiti con limiti di risorse ragionevoli e senza storage persistente o accesso agli stessi allegati del pool di storage e alle cose che vi finiscono. Per i siti ospitati, posso immaginare il tempo CPU dell’automazione come un altro limite per piano oltre a pageview, email e storage.

La posizione dell’API del sito potrebbe essere fornita come variabile d’ambiente o come altro segreto. Altro accesso di rete sarebbe vietato per impostazione predefinita, anche se dovrebbe essere possibile consentire connessioni in uscita specifiche.

Si può, ovviamente, configurare una cosa del genere al momento “a parte”, ma averla integrata con le interfacce di amministrazione API e Webhook sarebbe davvero elegante (e si occuperebbe fondamentalmente della gestione dei segreti). Inoltre, la configurazione del dispatcher/broker è un po’ complicata.


  1. Non intendo in senso negativo ↩︎

  2. probabilmente nella sezione API ↩︎

  3. "Docker" ↩︎

2 Mi Piace

Inoltre, questo avrebbe un pulsante “redeploy” e, possibilmente, un’opzione per verificare automaticamente le nuove versioni dei container al deploy di Discourse o a un altro trigger.