Come posso includere discourse nel mio stack di sviluppo locale?

La mia organizzazione gestisce un’applicazione web, un forum e alcune altre applicazioni come Bitwarden. Ho containerizzato tutto per ottenere la parità tra sviluppo e produzione e una configurazione di sviluppo semplice utilizzando Docker Compose. Utilizziamo un file compose molto simile per eseguire il tutto in produzione, e funziona molto bene per il nostro caso d’uso di base.

Vorrei passare il nostro forum a Discourse, ma sto faticando a capire come mantenere la parità tra sviluppo e produzione e una configurazione di sviluppo semplice.

La documentazione suggerisce che, anche se Discourse utilizza Docker per l’installazione e l’esecuzione, in realtà non si adatta al paradigma dei container come gli altri container Docker: non è possibile aggiungerlo a uno stack Compose, Swarm o Kubernetes per eseguirlo, collegandolo a container di database e Redis come si farebbe con un altro container applicativo. Le soluzioni alternative o i suggerimenti in tal senso sono fortemente sconsigliati per evitare di frammentare la comunità, quindi non sono qui per mettere in discussione questo approccio.

Ho accettato che, invece di eseguire e gestire Discourse come faccio con il resto del mio stack, dovrò utilizzare una VM dedicata in produzione e gestirla in modo diverso. Ma sono curioso di sapere come raggiungere i miei obiettivi fondamentali: una configurazione di sviluppo semplice che offra una buona parità con l’ambiente di produzione.

Per contestualizzare, la mia attuale configurazione di sviluppo è “installa Docker, clona questo repository ed esegui docker-compose up”. Se ho capito correttamente dalla guida all’installazione locale, ora saranno necessarie 9 dipendenze di sistema (Ruby, PostgreSQL, ecc.) prima di clonare e configurare manualmente Discourse. A mio avviso, uno dei vantaggi di Docker (e Docker Compose) è che non è necessario avere PostgreSQL e Redis in esecuzione sul proprio sistema (e i relativi problemi di configurazione quando gli sviluppatori utilizzano Windows); è possibile eseguire semplicemente uno stack e i processi sono isolati in container effimeri. Esiste un modo per mantenere questo vantaggio?

L’altro svantaggio è che, dato che siamo un piccolo team di volontari, la maggior parte degli altri sviluppatori utilizza Windows 10 Home, che, per quanto ne so, non supporta WSL, il che significa che non saranno comunque in grado di seguire le istruzioni di installazione per Windows (Docker funziona su Windows 10 Home).

Beh, la buona notizia è che, nella maggior parte dei casi, non dovrai farlo!

A meno che tu non stia sviluppando integrazioni specifiche per il forum o creando temi per il forum stesso, il sito Discourse può funzionare in modo autonomo, al di fuori del resto della tua infrastruttura.

Esistono opzioni per un’installazione di sviluppo basata su Docker su Linux e WSL; non consigliamo questa procedura su macOS a causa di problemi legati alle prestazioni del filesystem.

In realtà è piuttosto critico, perché voglio utilizzare Discourse come sistema di accesso per le mie applicazioni. Senza di esso, gli utenti non potranno accedere localmente.

In tal caso, ti consiglio di configurare l’SSO con un sito di staging attivo.

Crea una seconda copia di Discourse sullo stesso hosting (o simile), assegna i privilegi di amministratore a tutti e genera le chiavi segrete del provider SSO per localhost:3000, localhost:4000, localhost:4001, *.cluster.local e altri domini necessari.

Tutti i membri del team di sviluppo saranno in grado di generare payload di autenticazione da questo sito, quindi è fondamentale documentare questa circostanza e utilizzare il sito di produzione reale per l’autenticazione effettiva.