Multisito vs. contenitori multipli

Qualcuno conosce i pro e i contro di multisite rispetto a container multipli?

Attualmente ho tre istanze di Discourse come container separati e sto pensando di convertire altri due, forse tre forum a Discourse. Saranno sullo stesso server (64 GB di RAM, con SSD in esecuzione), quindi mi chiedo quale sia il modo migliore per procedere.

Preferirei che fossero il più indipendenti possibile, in modo che ciascuno possa essere aggiornato singolarmente, backuppato e ripristinato singolarmente, e che problemi su uno non influenzino gli altri.

Cosa suggerisci? Ci sono pro e contro da tenere d’occhio?

Con un multisito non potrai eseguire aggiornamenti individuali, né potrai segmentare i plugin utilizzati. Tutto ciò è definito dal multisito principale. Tuttavia, le impostazioni, i temi e i backup possono essere gestiti separatamente.

In generale, avrai anche bisogno di un proxy davanti per gestire i certificati SSL.

3 Mi Piace

In realtà, ho trovato un modo per ottenere certificati Let’s Encrypt per più domini senza reindirizzare al dominio principale. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ, saresti interessato a testare la mia guida? Sono quasi certo che funzioni, ma è passato qualche settimana dall’ultimo test e non sono completamente sicuro che le istruzioni siano valide anche per qualcun altro oltre a me.

Se vuoi che tutti i siti abbiano gli stessi plugin e vengano aggiornati tutti contemporaneamente, la configurazione multisito è ottima.

3 Mi Piace

Potrei semplicemente disattivare eventuali plugin non utilizzati tramite l’ACP (e penso che ce ne sia solo uno che uno dei forum non avrà bisogno), quindi immagino dipenda da: ci sono vantaggi nell’utilizzare multisite? Nello specifico, prestazioni e/o stabilità?

Credo di aver letto che @Blake abbia pubblicato una volta che è folle non eseguire PG in un proprio container (è diverso da multisite?), ed è per questo che ho pensato di farlo. A proposito, non prendete per oro colato ciò che ha detto Blake, potrei averlo semplicemente sognato :rofl:

Utilizzo HAProxy che si occupa dei nostri certificati SSL, quindi ‘penso’ che potrebbe andare bene.

Penso che dipenderà dai vantaggi, Jay: se non c’è molta differenza, non mi dispiacerebbe continuare come ho fatto finora, dato che ormai è diventato relativamente semplice da configurare e gestire; ma se ci sono grandi vantaggi nell’adozione di multisite, sarei decisamente interessato :sunglasses:

Un altro vantaggio è che stai eseguendo solo un’ulteriore copia di Rails e Nginx, quindi la RAM aggiuntiva richiesta è molto inferiore. Hai comunque molta RAM, quindi optare per ciò che funziona già sta iniziando a sembrare l’idea migliore.

2 Mi Piace

Ciao. È possibile combinare gli utenti da un multisito in modo che un utente possa essere registrato su tutti i multisiti contemporaneamente registrandosi su uno dei siti (come in magento). O una supervariante dell’uso di discourse, simile al federation. In modo che gli avvisi funzionino in modo sincrono e l’utente del sito numero 1 possa ricevere avvisi dal sito numero 2? Lo stesso vale per la chat.
Ho 4 community della stessa grande direzione, ma con argomenti diversi, e vorrei che queste community fossero strettamente integrate tra loro

Puoi rendere un sito il server di autenticazione di discourse connect e far autenticare tutti gli altri contro di esso.

2 Mi Piace

Sto cercando di capire se ho bisogno di una configurazione multisito, di più container o di qualcos’altro.

Attualmente ho 3 community indipendenti, due delle quali simili (entrambe sullo sport universitario ma per due scuole separate) e la terza sulla cucina e la pasticceria.

Vorrei che fossero tutte sullo stesso server (a causa delle limitazioni dell’indirizzo IP del mio ISP), ma su URL separati, un po’ come questo:

foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking

team1.bar.com che reindirizza a foo.bar.com/team1, ecc., o a server virtuali separati, andrebbe bene anche. (So che Apache può farlo, quindi presumo che anche nginx possa farlo, direttamente o con un server proxy davanti.)

Idealmente, foo.bar.com stesso fungerebbe da gateway per queste community indipendenti, spiegando cosa sono e come raggiungerle. Alcune categorie di ogni community potrebbero essere leggibili pubblicamente e accessibili dai crawler web in modo che appaiano nei risultati di ricerca web.

Si tratta di una configurazione multisito o di una configurazione multi-container, o di qualcos’altro interamente?

Ci sono delle insidie note nella progettazione dei plugin quando si esegue Multisite?

Sembra che il mio Chatbot non supporti Multisite (quindi è un problema noto), ma vorrei capire perché: sta funzionando bene nell’installazione standard.

In particolare, sembrano esserci problemi con il setup db task e potenzialmente con questo job.

1 Mi Piace

Vorrei fornire un aggiornamento sulla mia situazione.

Dopo alcuni studi, ho deciso che avevo bisogno di una configurazione multisito (un container a questo punto) con un sito nginx ‘esterno’ per spiegare la configurazione e indirizzare persone e traffico ai diversi siti discourse. In questo modo potrei rendere entrambi i siti aperti per l’accesso in sola lettura (e ai crawler web) senza che le persone su list1 debbano occuparsi del contenuto di list2. Potrei dover armeggiare con robots.txt per rendere felici i crawler web.

Gli esempi di configurazione multisito sono stati istruttivi, ma non sono riuscito a farlo funzionare con un socket unix (errore gateway), quindi ho finito per reindirizzarli a un’altra porta e reindirizzare quella porta a 443 all’interno del container.

Nel mio file app.yml ho abilitato il template SSL ma non quello letsencrypt.

Sono riuscito a far funzionare il sito di test, ora sto cercando eventuali problemi che potrebbero sorgere quando convertirò il sito di produzione, si spera più tardi questo mese o il prossimo.

Mi sto occupando del problema del certificato sul lato del server esterno, ma mi sono imbattuto nel problema ‘non sicuro’ che ho risolto richiedendo https nel container. Ho un’attività che eseguirò tramite cron per copiare l’ultimo certificato e la chiave nella directory /shared/ssl del container (come ssl.crt e ssl.key). Non sono sicuro se dovrò forzare un ricaricamento di nginx all’interno del container per assicurarmi che un nuovo certificato venga caricato quando cambia (a luglio, credo).

Mi sono imbattuto in un altro intoppo di discourse:

Nel file del container /etc/nginx/conf.d/discourse.conf c’è questo frammento di codice (nome del dominio modificato):

if ($http_host != ‘site1.my.domain’) {
rewrite (.*) https://site1.my.domain$1 permanent
}

Questo stava causando il reindirizzamento di site2.my.domain a site1.my.domain, quindi ho dovuto commentarlo.

NOTA: La ricostruzione del container richiede di rifare questa modifica, c’è un modo per evitarlo?

E questo ha portato a un intoppo del browser, perché ora firefox aveva contrassegnato quel reindirizzamento come permanente, quindi ho dovuto cancellare la cache del browser. (Ci è voluto troppo tempo per capirlo!)

Ho trovato un’altra cosa strana.

Sul mio sito di test, il parametro per richiedere https non era selezionato per nessuno dei due siti. Sul mio sito di produzione quel parametro non è nemmeno presente nel file delle impostazioni. Suppongo che abbia a che fare con le differenze tra i due siti.