Come controllare questo caos di upload in movimento da S3 a locale

Dopo 4-5 anni di utilizzo, ho finalmente deciso di riportare i miei caricamenti dal bucket Aws S3 al mio server locale per il mio sito web locale molto piccolo.
Essendo una persona con conoscenze limitate, ho affidato questo lavoro a un mio amico per una cifra molto ragionevole. Ha configurato il sito per i caricamenti locali, ma in qualche modo quasi la metà delle 3000 immagini, circa il 50%, si è rotta dalla sua origine. Il mio amico non mi ha fatto pagare nulla e mi ha chiesto di ripristinare il sito al backup (che era stato creato prima di cedergli il controllo l’11/04/2025).

Comunque, sono diventato pigro per circa un mese e non ho ripristinato. Fino a quando, ho deciso di risolvere le cose con l’aiuto del bot di assistenza di discourse/ChatGpt Ai Bot. E ho creato un’altra versione del mio vecchio sito web sul mio laptop Ubuntu localmente.

Sono riuscito a creare un’istanza del mio sito web originale sul mio laptop semplicemente mettendo una “t.” davanti al mio nome di dominio originale. Ora questo (chiamato sito di staging) funziona perfettamente per me, ma ha attività solo fino all’11/04/2025.

E il mio sito web di produzione, che ha tutti i dati aggiornati, ma ha centinaia di post con immagini mancanti.

Tieni presente che ho provato molti rake tasks per la migrazione o per riconnettere la connessione mancante alle immagini, senza successo.

Dopo aver sbattuto la testa per quasi un mese. La mia conclusione è questa. Che i post raw in ruby sono gli stessi nello staging e nella produzione.
Ma i post cotti diventano diversi. Cioè, la tabella del database del mio sito web di produzione forse manca di qualche connessione alle immagini fisiche effettive presenti sul server.

Ho anche notato che senza quella connessione, quelle immagini “orfane” vengono automaticamente eliminate dal server. Ma per fortuna, le risincronizzo di nuovo dallo staging o dal mio bucket S3 al mio server di produzione.

Infine il problema, nelle parole di, più o meno, ChatGpt, è che il server di staging ha le versioni cotte finali, che non hanno alcuna relazione con gli URL raw (brevi). E la produzione, che manca degli URL delle versioni cotte finali alle immagini, non può ottenere gli URL corretti di quelle immagini e sta tornando ai segnaposto “trasparenti”.

E ChatGpt mi suggerisce di copiare la versione cotta dai post di staging alla versione cotta della produzione. Il che non mi sembra una buona idea.

Esatta formulazione da ChatGpt su dove ci troviamo:

  • Sia in staging che in produzione, post.raw è identico e contiene riferimenti a upload://....
  • In staging, le immagini vengono visualizzate, ma l’interrogazione Post.find(12849).uploads non restituisce risultati — il che significa che non ci sono voci nelle tabelle uploads o post_uploads per questi file anche in staging.
  • Quindi le immagini vengono visualizzate in staging puramente perché l’HTML cotto dalla migrazione precedente contiene i link completi /uploads/default/original/....
  • Ma poiché la produzione è stata ricuocita post-migrazione, lo stesso contenuto grezzo ora non riesce a risolvere, tornando al segnaposto transparent.png.

:white_check_mark: I file caricati esistono ancora sul disco

Tutti i file immagine (inclusi quelli per i caricamenti mancanti) sono ancora presenti in /var/www/discourse/public/uploads/default/original/ sia in staging che in produzione. Ma Discourse non riesce più a risolverli poiché le loro voci uploads sono mancanti.

Il modo più semplice per farlo era, e potrebbe ancora esserlo, attivare l’impostazione Enable hidden setting to include S3 uploads in the backups, fare un backup e poi ripristinarlo su un server che non ha S3 configurato (lo farei su un server nuovo per evitare di rompere quello vecchio se qualcosa va storto). Ma sembra che anche il sito di produzione sia rotto, quindi probabilmente non aiuterà affatto.

Se hai pasticciato con la tabella Uploads in modo che contenga più percorsi S3, il lavoro è molto più difficile.

Invece di ChatGPT, ti consiglio https://ask.discourse.com/, che almeno conosce Discourse, ma probabilmente non sarà di grande aiuto.

Darei un’occhiata a Uploads.pluck(:url) e vedrei cosa c’è.

3 Mi Piace