Sono felice di condividere questo plugin di amministrazione per Discourse che aggiunge i nomi dei container (specificati nel file yml dell’app principale) alla scheda dei backup della pagina di amministrazione. Questo plugin utility è utile per gli amministratori di sistema di Discourse che eseguono configurazioni multi-container e desiderano vedere a colpo d’occhio quale container è in esecuzione.
Questo è un plugin semplice, ed è il mio primo “pubblico”, quindi commenti e PR sono molto benvenuti per migliorarlo. Le informazioni sul container provengono dalle variabili d’ambiente nel file yml, ad esempio:
Eseguiamo più container contemporaneamente in modo da poter ricostruire i container di Discourse e passare a essi con zero tempi di inattività (modificando la configurazione del reverse proxy), quindi per noi era meglio codificare questo valore nel file yml piuttosto che estrarlo da docker ps, poiché docker ps non ha modo di sapere quale container è abilitato dalla configurazione nel reverse proxy.
TODO
Le mie competenze in Ember sono scarse rispetto agli esperti di Discourse (sto ancora cercando di imparare Ember), quindi ho avuto alcuni problemi in due aree, quindi ci sono almeno due TODO aperti, e accolgo con favore una PR se qualcuno è interessato:
Quando l’app di Discourse (GUI) è in esecuzione e cambiamo container (tramite una modifica alla configurazione del reverse proxy), la pagina deve essere ricaricata (o il plugin disabilitato e riabilitato). Non sono riuscito a far aggiornare automaticamente la proprietà calcolata (ho provato molte tecniche diverse).
Non sono riuscito a far funzionare I18N come previsto, quindi l’elemento <span> è codificato nel codice JS invece di risiedere nella configurazione della lingua (ma ci sono i segnaposto per la bozza).
Come accennato, le PR sono benvenute, dato che sono ancora un principiante con i plugin di Discourse!
Commenti e aggiornamenti sono anche benvenuti qui:
Non ho idea di come rendere Ember reattivo con le computed properties quando i container vengono cambiati tramite un reverse proxy. È davvero un argomento interessante, in bocca al lupo.
Ho appena provato: ho cambiato container modificando la configurazione del reverse proxy e sono riuscito a far aggiornare la pagina disattivando e riattivando il plugin.
Comunque… grazie per questo plugin utility @neounix.
Grazie. Ma in realtà, questa utility è probabilmente utile per meno dell’1% di tutti gli amministratori di sistema di Discourse, dato che la maggior parte delle istanze di Discourse (una supposizione basata sui post su meta) esegue un singolo container senza un reverse proxy (la configurazione standard supportata da Discourse).
Sì, ho provato molti metodi diversi, e il problema per me, basandomi sulla mia “estrema inesperienza” nei plugin di Discourse, è che potevo leggere solo la variabile d’ambiente GlobalSetting dal file yml in Ruby, mentre il resto del plugin è scritto in Javascript.
Ho anche considerato di riscrivere il plugin al 100% in Ruby, ma non ho ancora intrapreso questa strada perché spero che qualcuno abbia un’idea migliore o addirittura contribuisca con una PR per rendere le informazioni del container reattive nel caso di switching del reverse proxy, in modo da non richiedere un ricaricamento dell’app (reinizializzazione del plugin).
