@schleifer Ehi, possiamo avere delle indicazioni dopo questo, per favore?
OK, è qualcosa con cui possiamo lavorare. Per prima cosa, sposta tutti i file da /default/* in /original/1X/*.
Questo è noto a noi, ma non al database. Il prossimo passaggio aggiornerà il percorso per tutti i caricamenti nel DB. Prima di modificare qualsiasi altra cosa, tuttavia, eseguiamo un controllo di coerenza.
Avvia la console del database:
cd /var/discourse
./launcher enter
rails db
Esegui questa query per esaminare i risultati:
select id,url from uploads where id > 0 and url not like '//PREFIX/original/%'
Dovrai sostituire PREFIX con BUCKET + ‘.s3.dualstack.’ + REGION + ‘.amazonaws.com’, il che darà qualcosa come //pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/%.
Questo dovrebbe restituire (0 righe). Se non è così, allora avremo passaggi aggiuntivi.
Ci sono 7 upload per la tua query e nessuno di essi proviene da S3.
Quindi tutti i link S3 puntano solo all’originale, giusto? I 7 upload risalgono a prima dell’inizio dell’uso di S3 per gli upload (ottobre 2018).
Dei link S3 (2614),
2368 utilizzano //pesioforum.s3.dualstack.ap-south-1.amazonaws.com
246 utilizzano //pesioforum.s3.ap-south-1.amazonaws.com
Entrambi i link funzionano, lo menziono qui perché potrebbe influire su eventuali espressioni regolari che potremmo utilizzare.
@schleifer Aiutaci a finire questo. 
OK, quindi dovresti essere libero di spostare i file da /default/ a /original/1X.
Puoi migrarli su S3 eseguendo rake s3:upload_assets
L’endpoint dualstack funziona sia per IPv6 che per IPv4. L’altro è solo per IPv4.
Nell’immagine è presente uno script per la ricomposizione delle stringhe nel database. Prima di eseguirlo, FAI SEMPRE UN BACKUP tramite /admin/backups (Menu hamburger → Admin → Backup).
Questo dovrebbe risolvere i 246:
discourse remap '//pesioforum.s3.ap-south-1.amazonaws.com/original/' '//pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/'
Dopo aver spostato tutto da /default/ a /original/1X/, possiamo ricomporre quei file nel DB. Ma prima di farlo, dobbiamo assicurarci che ogni cosa in /original/2X sia effettivamente presente.
Questa query restituisce lo stesso numero di righe del conteggio degli oggetti effettivi sotto quel percorso nel bucket?:
select url from uploads where url like '//pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/2X/%'
Ciao @schleifer
Puoi migrare quelli in S3 eseguendo
rake s3:upload_assets
Ho eseguito questo comando e ha caricato le risorse (js, css, ecc.) per il sito web. I 7 file non sono stati caricati.
Ho trovato rake uploads:migrate_to_s3, ma volevo confermare che fosse il task corretto per questo scopo.
C’è uno script nell’immagine per rimappare le stringhe nel database
Ha funzionato bene e non ci sono più vecchi link non dualstack nella tabella uploads.
Ma prima di questo, dovremmo assicurarci che tutto in
/original/2Xsia effettivamente presente.
Purtroppo non è così. Ci sono 521 file nel bucket S3, ma 2186 record nella tabella uploads.
Ho testato alcuni file che non si trovano in /original/2X/ come previsto e sono tutti in /default/.
Esempio: Dalla tabella uploads,
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/2X/8/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg non esiste, ma lo stesso file si trova in
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/default/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg
A questo punto, come soluzione temporanea una tantum, siamo d’accordo nel spostare semplicemente tutti i file da /original/2X/{}/ in /original/1X/ e aggiornare i post, ecc., con i nuovi link.
I nuovi caricamenti vengono comunque posizionati correttamente in 2X.
Aha, sì, era quello che intendevo effettivamente. Dovrebbe caricare gli ultimi sette.
Infatti, questa è l’opzione migliore al momento. Copia tutti i file dal loro prefisso /2X/ e sposta tutto in /1X/.
Dopo aver sistemato tutto, ecco un comando che dovrebbe aggiornare tutte le voci del database:
discourse remap --regex "//pesioforum\.doublestack\.s3\.ap-south-1\.amazonaws\.com/original/[1234]X/([0-9a-f]/){0,}" "//pesioforum.doublestack.s3.ap-south-1.amazonaws.com/original/1X/"
(Ricorda il precedente avviso sul creare un backup.)
Dopo di ciò, alcuni post potrebbero richiedere la ricostruzione della versione HTML tramite il menu a chiave inglese. Se ce ne sono più di un paio, puoi ricostruirli tutti con rake posts:rebake.
@schleifer ha funzionato! Con una regex modificata e una rigenerazione di tutti i post, la maggior parte delle immagini e dei file caricati funziona correttamente.
Alcune immagini (non post) puntano ancora a /optimized/, ma possiamo correggerle manualmente. Ad esempio: loghi in diversi temi, ecc.
Grazie mille per il tuo aiuto!
Ciao, abbiamo riscontrato un problema simile nel nostro ambiente e speravamo di ricevere aiuto per risolverlo.
Il nostro problema è simile a questo in molti aspetti:
- Abbiamo lo stesso valore elencato sotto
s3 upload bucketes3 backup bucket - Abbiamo riscontrato questo problema durante l’aggiornamento di Discourse:
Versione precedente: v2.3.0.beta3
Nuova versione: v2.5.0.beta6
- Ho eseguito l’accesso al container di Discourse e interrogato il database:
SELECT id,url FROM uploads where id > 0 and url not like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/%';
id | url
----+----------------------------------------------------------------------------------------------------
1 | /uploads/default/original/1X/eb17xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxc33.png
2 | /uploads/default/original/1X/b87fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv21.png
78 | //acme-forum.s3-us-west-2.amazonaws.com/original/1X/1205xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv045.png
(3 righe)
- Ho eseguito l’accesso al container di Discourse e interrogato il database:
select url from uploads where url like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/%';
//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/2/6267xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxf607c.jpeg
(7953 righe)
- Ho verificato quanti elementi ci sono in ./original/3X/, la risposta è
251elementi
Domanda:
- Stiamo utilizzando
dualstacke non voglio re-mappare i nostri URL per non utilizzarlo. - La nostra struttura delle cartelle è diversa, abbiamo cose come
3X/X/Y(ad esempio3X/7/a), quindi come posso spostare tutto dadefaulta3X/*, non verrà comunque mappato correttamente?
Il mio pensiero attuale è scrivere uno script che utilizzi l’output dal Passo 4 per capire dove spostare il file nuovamente nella cartella ./original/3X/X/Y.
L’unico problema è che quando l’ho fatto, dualstack non aveva ancora ospitato questo file. Cosa intendo: quando sostituisco il file in original/3X/X/Y, riesco a vederlo quando vado su:
Non funziona https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png
Aggiornamento: si è scoperto che l’endpoint dualstack non era mai stato rotto come pensavo, ho commesso un errore quando ho copiato inizialmente il file immagine in ./original/3X/6/b, dimenticando di abilitare la lettura per tutti.
Quindi la mia domanda è:
Sarebbe un’opzione praticabile per me spostare i file immagine da ./default a ./original/3X/x/y e poi non modificare affatto il database?
Ok, quindi ho un aggiornamento.
Sembra che riesca a prevedere dove dovrebbero andare le immagini ./original, ma non so come risolvere il problema delle immagini ./optimized.
Nel nostro forum, se navighi fino a uno dei nostri post, tenta di visualizzare l’immagine ./optimized.
Esiste un modo per sapere quale sia un’immagine optimized?
Il mio ragionamento è che le immagini ottimizzate terminano con _2_10x10.png; sarebbe un’ipotesi ragionevole? Se è così, sarebbe una soluzione praticabile utilizzare uno script per copiare tutto ciò che contiene qualcosa come _2_10x10.png nella cartella optimized e tutto il resto direttamente nella cartella ./original?
Esempio:
GET https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/optimized/3X/c/c/ccaxxxxxxxxxxxxxxxxxxxxxxxxxxxx85_2_690x268.png
[HTTP/1.1 403 Forbidden 0ms]
Grazie!
@41821 Se gli URL nella tabella uploads sono corretti e funzionanti, ma i post continuano a tentare di caricare le immagini ottimizzate, allora svuotare la tabella optimized_images e rifare il baking di tutti i post dovrebbe risolvere: discourse=> delete from optimized_images;
Grazie mille per il feedback. In realtà ho risolto (se si può chiamare così) scrivendo uno script per spostare l’immagine dalla directory /default a /optimized in base al nome del file. Sembra che abbia funzionato e non ho più alcun problema.
Se dovesse succedere di nuovo in futuro, però, farò come hai suggerito: cancellerò tutto da optimized_images e rifarò il baking.
Grazie!