Usando almacenamiento de objetos compatible con S3 de Scaleway

Soporte
1

Hi,

I’m trying to set up Discourse to use Scaleways S3-compatible Object Storage, but I can’t seem to get it to work and I’m not sure where the problem is.

I’ve verified that the both of the buckets work using aws-cli and that the CORS settings are properly set up by following the official docs from Scaleway so I don’t think the buckets themselves are the problem.

These are my Discourse S3 settings (part of bucket name redacted):

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

When I open the backups tab I get ‘Failed to list backups from S3: Aws::S3::Errors::BadRequest’
And when I try to upload an image, I see this in the log: 'Job exception: Failed to open TCP connection to [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Name or service not known) '.

I’m running the latest Discourse - 2.4.0.beta10 (14ae574bc5).

2

My guess is they are less s3 compatible than they think they are?

The s3 region setting seems like it is influencing things here as well.

1 me gusta
3

That’s possible, but the url shouldn’t include amazonaws.com if I entered the endpoint - right?

4

Exactly, this is weird. Maybe because of the hipster TLD? Let me take a look.

@dino try removing the https:// from s3 endpoint

3 Me gusta
5

The validation won’t let me do that: ‘s3_endpoint: Value doesn’t match the required format.’

1 me gusta
6

Yeah, that was a bad guess.

I can’t find a way to end with a URL like yours by reading the code responsible for it:

Is this only affecting backups? Are uploads working?

1 me gusta
7

Well, that’s different from the issue that I had with GCP buckets, but you might have a look at Trouble with Google Bucket for backup - #4 by pfaffman.

I was able to determine which upgrade of the aws-sdk-s3 gem caused using GCP Buckets not to work, though the solution my client chose was to switch to an AWS bucket.

8

@Falco yeah, I’m stumped too.
The error with the url which contains amazonaws is specifically for the file upload, not backups. For backups I only get the generic error, so I guess both are broken because of the url issue.

Can you think of anything else?

@pfaffman thanks for the tip - I’ll see if changing the version of the gem helps.

1 me gusta
9

Hey @dino, did that end up helping out? I’m having the same problem here and I’m about to give up and switch to Amazon S3.

10

Hey @FroggyC,
I actually ran out of time to debug this so I didn’t experiment with changing the gem vesions after all. I switched to using Amazon S3 using the official docs and things worked right away.
Sorry it’s not better news…

1 me gusta
11

Thank you. I guess we will have to do the same. Thank you!

12

El mismo problema aquí. ¿Hay algo que podamos hacer para ayudar a depurar esto?

Por ejemplo, ¿acceder al bucket mediante la CLI y enviar archivos de registro?

¿Se ignora s3_region, verdad? Porque Scaleway utiliza valores diferentes que AWS.

13

Podrías intentar preguntar a Scaleway: la responsabilidad de la compatibilidad recae sobre ellos. Si no son totalmente compatibles con AWS S3, deberían solucionarlo.

14

Estás insinuando que es culpa de ellos, pero hasta ahora has ignorado el comentario de @dino:

Mientras la URL de s3_endpoint (sin modificaciones) no se utilice tal cual, será difícil convencer a Scaleway de que el error está de su lado. Especialmente porque otros clientes S3 pueden conectarse sin problemas.

15

De acuerdo, demuéstralo. Muéstrame la documentación y los registros de trazas que demuestren que este es el caso. Si puedes proporcionar evidencia real del problema de nuestro lado, lo revisaré.

16

Claro, eso es lo que quise decir con

Entonces, ¿cómo puedo indicarle a Discourse que registre sus intentos de conexión con S3? Una vez que tengamos la certeza de la URL a la que desea conectarse, podré interceptar el tráfico y compartir los resultados.

1 me gusta
17

El motivo por el que la carga/respaldo de S3 no funciona es que la región debe configurarse en fr-par (o nl-ams), lo cual solo puede hacerse evitando la validación de SiteSetting de Discourse:

(vía ./launcher enter app y luego rails c)

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

Después de este cambio, las cargas y respaldos funcionan correctamente con el almacenamiento de objetos de Scaleway.

Documentación de Scaleway sobre Almacenamiento de Objetos

Por supuesto, esto es una solución temporal; si restableces o modificas esta configuración del sitio a través del Administrador Web, no podrás volver a un estado funcional (a menos que uses nuevamente la consola de Rails).

Supongo que el cliente de AWS/S3 permite establecer explícitamente una cadena de región (a diferencia del estado actual del administrador web).

También es algo engañoso en el caso del valor desplegable “EU (París)” en Discourse, ya que este se refiere al esquema de nombres de AWS eu-west-3 (o algo similar) y no al valor esperado para Scaleway.

5 Me gusta
18

Ajá. ¿Necesitamos un campo especial de configuración del sitio “región compatible con S3” @falco? Eso permitiría a los usuarios ingresar regiones completamente arbitrarias (y por tanto, ‘inventadas’ desde la perspectiva de Amazon).

19

No es necesario.

Las personas que usan clones de S3 deben establecer la variable de entorno S3 Endpoint, lo que sobrescribe la región de S3.

Tengo una guía completa explicando esto con el clon de S3 de Digital Ocean, pero estoy esperando a que Digital Ocean corrija un error en su CDN de S3 antes de publicarla.

Si Scaleway está en mejor estado que Digital Ocean, creo que lo probaré y trataré de basar mi guía en él.

4 Me gusta
20

Correcto, pero ¿cómo saben que deben hacer eso? ¿La descripción del ajuste de sitio existente menciona esto? Creo que debería. ¿Puedes hacerlo?

3 Me gusta