App.yml volumi condivisi per una configurazione con due siti web

Vorrei modificare il mio app.yml per poter avviare un’altra istanza di Discourse (contenitore separato, database separato, tutto separato immaginabile! - per la portabilità) sulla stessa macchina (in esecuzione dietro nginx).

Quindi, la mia prima configurazione è questa (le parti importanti):

## app.yml per site01
volumes:
  - volume:
      host: /var/discourse_site01/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse_site02/shared/standalone/log/var-log
      guest: /var/log

.. e funziona benissimo: l’istanza è online e tutto è a posto. Ora, vorrei ospitare un’altra istanza di Discourse, per la quale ho definito i volumi condivisi in questo modo in un altro app.yml:

## app.yml per site02
volumes:
  - volume:
      host: /var/discourse_site02/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse_site02/shared/standalone/log/var-log
      guest: /var/log

In questa seconda configurazione, ci sono possibili problemi? Sto eseguendo questa operazione su un server di produzione, quindi volevo verificare che questo app.yml sia corretto.

Consiglio vivamente di testarlo prima su una copia clonata o in staging, mai direttamente su un server live.

Puoi approfondire l’uso di nginx? Ci sono altri servizi di produzione sulla stessa macchina?

@Stephen: nginx è semplicemente un reverse proxy per la prima istanza di Discourse. Niente di complicato. In realtà, la configurazione è quella che ho seguito su meta.discourse per impostare nginx come server front-end.

Non ci sono altri servizi in esecuzione sulla macchina. In realtà, poiché si tratta di una macchina di produzione, ho impostato tutto in una cartella host completamente separata discourse_site02. Ha senso?

Vedi qualche problema nell’app.yml che ho descritto? O pensi che ci sia qualcosa di sbagliato nella mia configurazione?

Allora, c’è qualche motivo per cui non stai utilizzando un’installazione multisito con due container? Non credo che tu perda molta portabilità in questo modo; il metodo più rapido per spostare le istanze tra i server è migrare un backup.

Nel caso in cui dovessi spostare un’istanza, basterebbe avviare un nuovo server, impostare l’istanza vecchia come sola lettura, reindirizzare il DNS e ripristinare il backup. Con un servizio DNS a TTL basso come Cloudflare, un sito piccolo può essere migrato in pochi minuti. Gli utenti sperimenteranno un breve periodo di accesso in sola lettura, senza che vada perso alcun contenuto.

È molto più efficiente suddividere le risorse in questo modo: non finirai per eseguire due server database e due web server in container separati, eliminando completamente la necessità del reverse proxy nginx.

@Stephen: sì, ho visto il link che hai mostrato, ma per semplificare la configurazione (qui abbiamo un piccolo team con poca esperienza), preferirei procedere come ho descritto, il che comporta due database e due server web, ecc. In realtà, questa è esattamente la configurazione che preferisco.

Oltre alle inefficienze che hai evidenziato, ci sono altri problemi da considerare?
I due file app.yml che ho mostrato sono corretti?

Grazie per il tuo tempo e per questo software fantastico :smile:

Cordiali saluti

@Stephen: mi chiedevo solo, pensi che la mia configurazione sia corretta per l’impostazione a 2 container?

Come ho detto, non sto cercando di risparmiare risorse o essere efficiente :slight_smile: voglio solo sapere se va bene funzionare in questo modo, assumendo che non ci siano insidie che mi possano creare problemi in seguito.