Utilizzo dell'archiviazione oggetti compatibile con S3 di Scaleway

Supporto
1

Ciao,

Sto cercando di configurare Discourse per utilizzare l’archiviazione oggetti compatibile con S3 di Scaleway, ma non riesco a farla funzionare e non sono sicuro di dove sia il problema.

Ho verificato che entrambi i bucket funzionino tramite aws-cli e che le impostazioni CORS siano state configurate correttamente seguendo la documentazione ufficiale di Scaleway, quindi non credo che il problema risieda nei bucket stessi.

Queste sono le mie impostazioni S3 di Discourse (parte del nome del bucket oscurata):

discourse-admin-s3
discourse-admin-s31355×1654 348 KB

Quando apro la scheda dei backup, ricevo l’errore “Failed to list backups from S3: Aws::S3::Errors::BadRequest”.
E quando provo a caricare un’immagine, vedo questo nel log: “Job exception: Failed to open TCP connection to [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Name or service not known)”.

Sto eseguendo l’ultima versione di Discourse - 2.4.0.beta10 (14ae574bc5).

2

Il mio indovinello è che sono meno compatibili con S3 di quanto pensino?

La configurazione della regione S3 sembra influenzare anche le cose qui.

3

È possibile, ma l’URL non dovrebbe includere amazonaws.com se ho inserito l’endpoint, giusto?

4

Esatto, è strano. Forse è colpa del TLD hipster? Fammi dare un’occhiata.

@dino prova a rimuovere https:// dall’endpoint s3

5

La validazione non me lo consente: ‘s3_endpoint: Il valore non corrisponde al formato richiesto.’

6

Sì, era un’ipotesi sbagliata.

Non riesco a trovare un modo per terminare con un URL come il tuo leggendo il codice responsabile:

Questo riguarda solo i backup? Gli upload funzionano?

7

Beh, è diverso dal problema che ho avuto con i bucket GCP, ma potresti dare un’occhiata a Trouble with Google Bucket for backup - #4 by pfaffman.

Sono riuscito a determinare quale aggiornamento del gem aws-sdk-s3 ha impedito il funzionamento dei bucket GCP, anche se la soluzione scelta dal mio cliente è stata passare a un bucket AWS.

8

@Falco sì, sono bloccato anch’io.
L’errore relativo all’URL che contiene amazonaws si verifica specificamente per il caricamento dei file, non per i backup. Per i backup ricevo solo l’errore generico, quindi immagino che entrambi siano compromessi a causa del problema con l’URL.

Hai qualche altra idea?

@pfaffman grazie per il suggerimento - controllerò se cambiare la versione del gem aiuta.

9

Ehi @dino, alla fine ha funzionato? Sto riscontrando lo stesso problema e sto per arrendermi e passare ad Amazon S3.

10

Ciao @FroggyC,
alla fine non ho avuto tempo di debuggare questo problema, quindi non ho sperimentato la modifica delle versioni delle gem. Ho invece optato per l’utilizzo di Amazon S3 seguendo la documentazione ufficiale e tutto ha funzionato immediatamente.
Mi dispiace non essere riuscito a darti notizie migliori…

11

Grazie. Immagino che dovremo fare lo stesso. Grazie!

12

Stesso problema anche da noi. C’è qualcosa che possiamo fare per aiutare nel debug?

Ad esempio, accedere al bucket tramite CLI e inviare i file di log?

s3_region viene ignorato, giusto? Perché Scaleway utilizza valori diversi rispetto ad AWS.

13

Potresti provare a chiedere a Scaleway: l’onere della compatibilità è loro. Se non sono pienamente compatibili con AWS S3, dovrebbero risolvere il problema.

14

Stai insinuando che sia colpa loro, eppure finora hai ignorato il commento di @dino:

Finché l’URL di s3_endpoint (non alterato) non viene utilizzato così com’è, sarà difficile convincere Scaleway che l’errore sia dalla loro parte. Soprattutto perché altri client S3 riescono a connettersi.

15

Ok, dimostralo. Mostrami la documentazione e le tracce dei log che dimostrano che è così. Se puoi fornire prove concrete del problema dal nostro lato, me ne occuperò.

16

Certo, è esattamente ciò che intendevo con

Quindi, come posso dire a Discourse di registrare i tentativi di connessione a S3? Una volta che avremo la certezza dell’URL a cui vuole connettersi, potrò intercettare il traffico e condividere i risultati.

17

Il motivo per cui il caricamento/backup S3 non funziona è che la regione deve essere impostata su fr-par (o nl-ams), il che può essere fatto solo aggirando la convalida delle impostazioni del sito di Discourse:

(eseguendo ./launcher enter app e poi rails c)

SiteSetting.find_by(name: 's3_region').update_attribute(:value, 'fr-par')

dopo questa modifica, i caricamenti e i backup funzionano con l’Object Storage di Scaleway.

Documentazione di Scaleway sull’Object Storage

ovviamente, questo è un workaround e una volta reimpostata o modificata questa impostazione del sito tramite l’interfaccia web di amministrazione, non sarà possibile riportarla a uno stato funzionante (a meno di non utilizzare nuovamente la console Rails).

Immagino che il client AWS/S3 consenta tutti di impostare esplicitamente una stringa di regione (a differenza dello stato attuale dell’interfaccia web di amministrazione).

È anche piuttosto fuorviante nel caso del valore a discesa “EU (Parigi)” in Discourse, poiché questo fa riferimento allo schema di denominazione AWS eu-west-3 (o qualcosa di simile) e non al valore atteso per Scaleway.

18

Aha. Serve un campo di impostazioni del sito speciale “regione compatibile con S3” @falco? Questo permetterebbe agli utenti di inserire regioni completamente arbitrarie (e quindi ‘inventate’ dal punto di vista di Amazon)?

19

Non serve.

Gli utenti dei cloni di S3 devono impostare la variabile d’ambiente S3 Endpoint, che sovrascrive la regione S3.

Ho una guida completa che spiega come farlo con il clone S3 di Digital Ocean, ma sto aspettando che Digital Ocean corregga un bug nel loro CDN S3 prima di pubblicarla.

Se Scaleway è in una situazione migliore rispetto a Digital Ocean, penso che proverò e cercherò di basare la mia guida su di essa.

20

Giusto, ma come fanno a saperlo? La descrizione dell’impostazione del sito esistente lo menziona? Penso di sì. Puoi sistemarla?