Ciao,\n\nil team ha recentemente rimosso il supporto per la disabilitazione del long polling tramite l’interfaccia. Questo ha interrotto la funzionalità richiesta per l’immagine docker di bitnami, che utilizza passenger e non funziona, vedi https://github.com/bitnami/bitnami-docker-discourse/issues/177. L’immagine bitnami non passa direttamente i parametri ambientali, quindi questo è rotto finché qualcuno non estende l’immagine bitnami, vedi Sign in to GitHub · GitHub, mi è sorta la domanda, dato che discourse è già distribuito solo con un container docker: c’è qualche possibilità che il team mantenga un’immagine docker “cloud native”?\n\nLa grande differenza tra l’immagine bitnami e la vostra è la modalità operativa. L’infrastruttura moderna si aspetta che sia possibile automatizzare l’installazione. Di solito in k8s si fa con helm, ma anche le distribuzioni ansible in ambienti piuttosto tradizionali con VM produrrebbero lo stesso risultato. Quindi, ciò che renderebbe discourse alla pari con l’immagine bitnami piuttosto trascurata sarebbe l’aggiunta di una routine di installazione automatica e forse anche l’adattamento del template helm.\n\nDato che sono già qui, vorrei lasciare un feedback su discourse stesso e sulla sua “prontezza per il cloud”:\n\nIn generale, quando abbiamo cercato di integrare discourse in una configurazione riproducibile per un attuale progetto cliente, è emerso abbastanza rapidamente che discourse non è mai stato creato secondo gli aspetti dell’infrastruttura moderna. Un esempio è la necessità di uno storage NFS condiviso. Questo non è né affidabile né scalabile. Fortunatamente, la maggior parte di questo può già essere reindirizzato a un S3, ma rimangono parti che sono i plugin.\n\nCi sono tre modi per risolvere il problema dei plugin:\n - Codice valutato memorizzato nel database (non consigliato)\n - Container sidecar pre-pacchettizzati (in termini kubernetes verrebbero usati come initContainers che scrivono su un emptyDir) che scrivono su uno storage volatile (cioè tmpfs) prima dell’avvio del container discourse (consigliato, anche se non super comodo)\n - Una routine di installazione, che recupera le informazioni sui plugin correnti e i loro comandi di installazione dal db all’avvio e una routine di watcher/listener per installare i plugin anche a runtime (non consigliato, perché super lento e soggetto a errori)
Penso che questo sia stato discusso in modo piuttosto approfondito qui:
Onestamente, dato che bitnami lo ha risolto facilmente, non c’è molto motivo di discuterne così tanto. Non sarebbe fantascienza rendere Discourse facilmente distribuibile.
Voglio solo far notare che gestiamo molti siti Discourse in ambienti cloud e non utilizziamo uno storage NFS. Asset e upload sono gestiti tramite object storage (S3) mentre il codice sorgente (core e plugin) sono persistiti nell’immagine del container avviata.
Bene, a questo è già stato risposto: Fortunatamente la maggior parte di questo può già essere reindirizzato a un S3, ma rimangono parti che sono i plugin. Costruire un container in anticipo da utilizzare è una cattiva pratica poiché aumenta il rischio di non aggiornare correttamente tramite gli helm chart utilizzati.
Puoi per favore elaborare su questo? Non capisco come i plugin richiedano uno storage NFS condiviso.
Mi dispiace molto, ma abbiamo già questo epico argomento di cui discutere.
Non voglio separarlo. Se ci sono idee, dovrebbero essere discusse su: