Multisito vs. contenitori multipli

Does anyone know the pros and cons of multisite vs multiple containers?

I currently have three Discourse instances as separate containers, and am thinking about converting two, maybe three more forums to Discourse - they’ll be on the same server (64GB RAM, running SSDs) so I’m wondering what might be the best way forward.

I’d prefer them to be as independent as possible, so each can be upgraded individually, backed up and restored individually, and issues with one should not affect another.

What do you suggest? Any pros and cons to look out for?

You won’t be able to upgrade individually with multisite, nor will you be able to segment plugins used. All of that is defined by the root multisite. Settings, themes, and backups can all happen separately, though.

Generally you’ll need a proxy in front to help with SSL certs, too.

3 Mi Piace

Actually, I’ve worked out a way to get let’s encrypt to get certs for multiple domains and not redirect to the primary domain. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ, would you be interested in testing my howto? I’m 90% sure that it works, but it was some weeks ago that I last tested and I’m not entirely sure that the instructions “work” for someone who’s not me.

If you want all the sites to have the same plugins and be upgraded all at the same time, multisite is great.

3 Mi Piace

I could just switch off any unused plugins via the ACP (and I think there’s only one that one of the forums won’t need) so I guess it depends on are there any benefits to doing multisite? Specifically, performance and/or stability?

I think I read @Blake once post that it’s insane not to run PG in it’s own container (is that different to multisite?) hence why I’ve been thinking about doing this. Btw don’t quote me on what Blake said I could have well dreamt it :rofl:

I use HAProxy which deals with our SSL certs so I ‘think’ that may be ok.

I think it will depend on the benefits Jay - if there’s not much difference then I don’t mind carrying on as I have been as it’s become relatively easy to set-up and manage, but if there are some big advantages to going multisite I would definitely be interested :sunglasses:

The other advantage is that you’re running just one more copy of rails and nginx, so the additional RAM required is much less. You’ve got lots of RAM, though, so going with what works already is starting to sound like the best idea.

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.