Dal link sopra, posso vedere che immagini e allegati sono archiviati in una cartella condivisa più profonda nell’installazione di Discourse, non all’interno del docker. Dato che vorrei utilizzare una cartella di immagini collegata simbolicamente dal mio secondo storage, che monto tramite NFS su altri server. E, su un server secondario, vorrei eseguire il container docker di Discourse, come mezzo di bilanciamento del carico / failover…, e vorrei utilizzare la stessa cartella di immagini dal mount NFS. Ho già il DB da un altro server di rete, per sicurezza.
Ho appena testato l’impostazione, ma il risultato non è buono. Ho copiato tutti i file immagine da /var/discourse/shared/standalone/uploads a /var/www/image/uploads
Quindi,
Creati collegamenti simbolici alla cartella immagini montata NFS
chmod & chown con www-data:www-data e 755 per le cartelle /uploads
Vedo le immagini sul server primario dove la cartella immagini è montata nativamente, ma non è così sul server secondario montato NFS. Le immagini mancano con dimensione contenitore.
Inoltre, anche sul server primario, posso vederle, ma non posso più scaricarle.
Suppongo sia dovuto ai permessi dei file. Mi chiedo quale sia l’impostazione ideale.
Non sono sicuro se sia vanilla o dovuto a decine di rebuild, ma le immagini nella cartella predefinita sono 755/644 (cartella/file) e main_id:www-data sul mio server. Ho anche copiato la stessa strategia, ma non ha funzionato. Potrebbe essere un problema specifico di symlink o NFS, ma non riesco più a tracciarlo.
Invece di un symlink, modifica il mount di docker in modo che punti al tuo mount nfs.
Tuttavia, ottenere la sincronizzazione dei permessi all’interno del container, all’esterno del container e sul server nfs remoto può essere certamente complicato.
Questo è stato il mio primo tentativo. All’interno del docker, ho scoperto che il file system era piuttosto incasinato, cosa che avevo già notato. Era nidificato /uploads/uploads/uploads prima che venisse visualizzato /default/. Non sono sicuro di cosa sia successo realmente, ma ho copiato tutti i file dall’interno nel mio mount dell’immagine e ho aggiunto la cartella di mount come volume.
Qui, la situazione non era molto diversa da un symlink. Le autorizzazioni dei file creano effettivamente lo stesso problema. Dopo aver capito che i file sono effettivamente archiviati al di fuori del container Docker, ho pensato che un symlink potesse essere una soluzione molto più semplice.
Per entrambi, sono quasi sicuro che si tratti di autorizzazioni dei file, ma una CDN personalizzata solo con un blocco server Nginx sembra una soluzione molto più semplice di un volume Docker, purché il symlink non funzioni.
Sono abbastanza sicuro che non ci sia nulla di buono nell’usare i symlink. Un problema è che è difficile che il symlink sia lo stesso all’interno e all’esterno del container, e immagino che il tuo problema di upload annidati sia correlato a questo. Ho visto consigliare di non usare i symlink e penso che questo sia il motivo.
Discourse supporta CDN personalizzati basati su CNAME? Ricordo di aver visto la configurazione S3 nell’amministratore e post su Meta per Fastly, ma non riesco a ricordare la configurazione CDN personalizzata.
Trovato il post. Suppongo che dovrò configurare una versione self-hosted di una CDN compatibile con S3. Un semplice server di immagini Nginx non è sufficiente.