Stiamo costruendo, testando e cercando intenzionalmente lacune nel nostro forum Discourse prima di spostare l’intera cosa in produzione. Ho appena migrato il mio forum di test, che aveva abilitato i caricamenti su S3, da un server a un altro e, al ripristino, tutti gli URL per qualsiasi allegato sono stati riscritti con l’URL del forum invece che con quello di S3…
Fortunatamente si tratta di un forum di test, quindi non ci preoccupiamo troppo dei dati, tuttavia vorrei:
A. Risolvere comunque il problema.
B. Trovare un modo per mitigare/prevenire che ciò accada in produzione.
Non sono stati solo i post, ma tutte le immagini, i media, i contenuti e gli avatar (cosa piuttosto drammatica) sono stati interessati da questo…
Prima di ripristinare, puoi configurare S3 sul sito di destinazione nel tuo app.yml (non tramite la dashboard di amministrazione). Una volta confermato che la configurazione è corretta e che è possibile raggiungere il bucket appropriato, puoi procedere con il ripristino e i media verranno collegati correttamente.
Abbiamo effettivamente fatto quello e così è finita in quella situazione.
Ho copiato l’app.yml così com’era nella destinazione e poi ho eseguito il backup dall’originale. Il problema è stato il ripristino: quando abbiamo ripristinato, gli URL sono stati riscritti, nonostante non fosse cambiato nulla e avessimo ancora gli upload su S3 abilitati.
Alla fine abbiamo risolto il problema con un rebake (creiamo, la cache di Discourse è molto aggressiva, quindi tra le tante soluzioni che abbiamo provato, non sappiamo davvero quale abbia funzionato), ma restano ancora senza risposta le domande su come effettuare le migrazioni con il minimo numero di problemi o persino su come ripristinare da un backup se necessario in produzione.
Sembra che tu abbia configurato S3 tramite le impostazioni del sito e non tramite le variabili d’ambiente, come suggerito da Kris. Il processo di ripristino deve conoscere le informazioni relative a S3, cosa non possibile con le impostazioni del sito.
Se lo desideri, puoi anche creare un backup senza i file caricati dalla riga di comando: discourse backup --sql_only
Il ripristino di un tale backup non riscriverà gli URL dei file caricati. Quindi, finché il tuo nuovo server ha accesso allo stesso bucket S3, questo metodo funziona.
La configurazione S3 si trova nel file app.yml, non nelle impostazioni del sito.
Modifica:
Mi rendo conto di non essere stato sufficientemente esplicativo e non intendo nascondere dettagli.
Utilizziamo OVH S3 ed è configurato in app.yml.
Ho eseguito un backup del nostro forum di test senza i file caricati, ma S3 era ancora abilitato in quel momento.
Poi l’ho ripristinato sul nuovo sito con lo stesso file app.yml e da lì è iniziato il problema. Per essere chiari, ora è risolto, ma non sono sicuro se sia dovuto al fatto che l’ho rigenerato diverse volte o alla cache aggressiva di Discourse. Ecco perché devo sapere come farlo correttamente e ottenere il risultato giusto al primo tentativo. Temo che, se dovessimo mai dover ripristinare un backup sulla nostra istanza di produzione e incontrassimo questo problema, devo sapere esattamente come risolverlo immediatamente prima che gli utenti se ne accorgano.
Come ho detto, se desideri ripristinare su un server che utilizza lo stesso bucket S3, assicurati di aver configurato S3 in app.yml e di creare un backup senza i file caricati (discourse backup --sql_only). Gli URL dei file caricati non verranno riscritti se il backup non contiene i file caricati.
Se desideri ripristinare su un server che utilizza un bucket S3 diverso o non ha alcuna configurazione S3, utilizza un backup completo con i file caricati. Gli URL dei file caricati verranno riscritti durante il ripristino.
Sei sicuro al 100% di aver configurato OVH S3 tramite variabili d’ambiente in app.yml su entrambi i server e di aver utilizzato un backup senza i file caricati (estensione del file .sql.gz)?
Quando l’ho inizialmente ripristinato con gli upload completati, si è effettivamente rotto, quindi ho dovuto cancellare tutto e ricominciare da capo, questa volta creando un backup senza gli upload. È lì che è iniziato il problema. Gli URL erano ancora scritti in modo errato.
Non sono sicuro di come sia successo. Il processo di ripristino salta tutto il codice relativo agli upload (inclusa la riscrittura degli URL degli upload) quando si ripristina un file .sql.gz.
Forse stiamo parlando di cose diverse? Io mi riferisco alla colonna url nella tabella uploads, che di solito è //your-s3-bucket/original/... rispetto a /uploads/original in locale.
Un aspetto da considerare nel ripristino di un file .sql.gz è che nessun URL viene riscritto. Si presuppone che il server sia raggiungibile tramite lo stesso hostname del server in cui è stato creato il backup. Dovrai rimappare gli URL se cambi hostname.
Nessun nome host è stato modificato. Sono stati aggiornati solo i record A, con backup eseguito e completato.
Gli avatar degli utenti mancavano (e ciò era dovuto al fatto che non avevo migrato la cartella uploads). Le immagini S3 per allegati e media sono state riscritte per l’URL del forum, non per l’URL del bucket.
Quindi, mentre mi aspettavo che gli URL per i caricamenti S3 sopra indicati fossero scritti come https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized, in realtà erano https://forum.somedomainhere.com/uploads/optimized, il che ovviamente non funzionerà.
Posso letteralmente avviare un’altra VM e eseguire un ripristino completo se desideri che verifichi tutti i passaggi che ho compiuto.
L’ho ripristinato semplicemente recuperando il file sql.gz archiviato su S3, e finora l’unico problema è stato con alcune avatar degli utenti e alcuni post, ma immagino che dipenda dal fatto che non erano stati caricati su S3 al momento della creazione.
In un ambiente di produzione, assumendo che tutto vada bene fin dal lancio e che tutto sia su S3… se ripristino da un backup, non avrò lo stesso strano problema di cui si parla nel primo post, è corretto?
