Ho avuto qualche idea casuale che mi è venuta in mente, e una di queste era un plugin per installare plugin. Ciò richiede una ricostruzione del forum. C’è un modo per ricostruire usando Ruby? Non voglio davvero provare:
p `cd ../../`
p `. /launcher rebuild app`
In un’installazione standard, Discourse (e quindi i plugin) viene eseguito all’interno di un container Docker. Quel container non ha accesso completo al filesystem dell’host, quindi non può accedere alla directory /var/discourse dell’host per modificare app.yml o eseguire launcher.
E anche se potesse… c’è una piccola dipendenza circolare qui. L’esecuzione di ./launcher rebuild ucciderebbe il container Docker… che ucciderebbe il launcher rebuild che hai avviato dal plugin 
Ci sono potenziali soluzioni qui. Ad esempio, aggiungere ulteriori montaggi di volumi Docker, in modo che la configurazione/launcher possa essere accessibile dall’interno del container. Ma non è banale.
Se ricordo bene, qualcuno una volta ha creato un plugin ‘plugin manager’… che richiedeva alcune modifiche ad app.yml per aggiungere cose come il montaggio del volume. Ma non riesco più a trovare argomenti a riguardo, quindi presumo che non sia più mantenuto. Forse qualcun altro può condividere un link se riesce a trovarlo? (o forse era tutto un sogno 
)
Dal lato CDCK, tendiamo decisamente a utilizzare temi quando vogliamo che i clienti possano installare/aggiornare/disinstallare a piacimento. Consentire alle persone di installare arbitrariamente plugin non è un’opzione, perché ciò influirebbe su altri clienti che utilizzano lo stesso server.
Sì, eccolo:
Hmm… Capisco.
Oh, oops, non ci avevo pensato!
Dashboard.literatecomputing.com installerà e rimuoverà i plugin modificando app.yml (o web_only.yml) ed eseguendo la ricostruzione (in realtà, bootstrap, destroy, rebuild). Su un’installazione a due container, il tempo di inattività è minimo.
Fa anche cose come aggiornare docker e postgres, docker prune, e così via. Poiché gestisce un’installazione standard, non sei vincolato ad essa e non può rompere nulla a meno che non stia effettivamente facendo qualcosa (come installare un plugin non valido).
È un plugin di discourse (privato) che pilota un playbook Ansible. Puoi unirti al gruppo di prova gratuito e usarlo gratuitamente (con supporto limitato).
Questo plugin sembra semplicemente clonare il repository nella directory /plugins. Interessante.
ProCourse Installer è stato fantastico! È un peccato che abbia causato problemi ad alcuni plugin.
Puoi fare qualcosa di simile all’interno del container per aggiungere un plugin a un container esistente:
cd /var/www/discourse/plugins
git clone my-plugin-url
rake db:migrate assets:precompile
sv restart unicorn
Ma ci sono i problemi di mantenere i plugin nel container e in app.yml per la prossima ricostruzione.
Sono stato scottato un numero di volte facendo ./launcher destroy app;./launcher start app per applicare nuove variabili ENV da app.yml solo per scoprire che il container “nuovo” è indietro rispetto alla versione del database. È ancora peggio se qualcuno ha aggiornato solo alcuni plugin nel container che funzionavano con la versione di Discourse che era nel vecchio container, ma non con quella che ottieni quando ricostruisci. . .
Ecco perché il plugin ProCouese ha solo clonato i repository e può essere rimosso solo tramite quella pagina del plugin per eseguire rm -rf la cartella del plugin clonato.
In realtà ha funzionato abbastanza bene come prova di concetto. Potrebbe necessitare di alcuni aggiustamenti, poiché è stato detto che potrebbe rendere la risoluzione dei problemi più difficile. Quindi, forse sono necessarie alcune informazioni dalla riga di comando su come accedere all’installer di proccourse. Forse un file di log migliore.
Il vantaggio è che puoi disabilitare tutti i plugin semplicemente rimuovendo/commentando l’installer di proccourse. Anche se ora è rotto.
Joe ha delle idee molto lungimiranti. Se non ricordo male, ha creato il plugin iniziale Post Voting?