Estou tentando configurar o Discourse para usar o Armazenamento de Objetos compatível com S3 da Scaleway, mas não consigo fazê-lo funcionar e não tenho certeza de onde está o problema.
Verifiquei que ambos os buckets funcionam usando o aws-cli e que as configurações de CORS estão corretamente configuradas seguindo a documentação oficial da Scaleway, então não acredito que os próprios buckets sejam o problema.
Estas são minhas configurações de S3 do Discourse (parte do nome do bucket censurada):
Quando abro a aba de backups, recebo o erro: ‘Falha ao listar backups no S3: Aws::S3::Errors::BadRequest’.
E quando tento fazer upload de uma imagem, vejo isso no log: ‘Exceção no Job: Falha ao abrir conexão TCP para [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Nome ou serviço desconhecido)’.
Estou executando a versão mais recente do Discourse - 2.4.0.beta10 (14ae574bc5).
Consegui determinar qual atualização do gem aws-sdk-s3 fez com que o uso de buckets do GCP deixasse de funcionar, embora a solução escolhida pelo meu cliente tenha sido migrar para um bucket da AWS.
@Falco sim, estou sem ideias também.
O erro com a URL que contém amazonaws é específico para o upload de arquivo, não para backups. Para backups, recebo apenas o erro genérico, então acho que ambos estão quebrados por causa do problema com a URL.
Consegue pensar em mais alguma coisa?
@pfaffman obrigado pela dica - vou ver se mudar a versão do gem ajuda.
Oi @FroggyC,
Na verdade, acabei ficando sem tempo para depurar isso, então não experimentei mudar as versões do gem de qualquer maneira. Migrei para usar o Amazon S3 seguindo a documentação oficial e tudo funcionou imediatamente.
Desculpe não ser uma notícia melhor…
Você pode tentar perguntar à Scaleway — a responsabilidade pela compatibilidade é deles. Se eles não forem totalmente compatíveis com o AWS S3, devem corrigir isso.
Você está insinuando que é culpa deles, mas até agora você tem ignorado o comentário do @dino:
Enquanto a URL do s3_endpoint (inalterada) não for usada como está, será difícil convencer a Scaleway de que o erro está do lado deles. Especialmente porque outros clientes S3 conseguem se conectar.
OK, prove. Mostre-me a documentação e os registros de log que demonstrem que este é o caso. Se você puder fornecer evidências reais de que o problema está do nosso lado, eu vou analisar.
Então, como posso instruir o Discourse a registrar suas tentativas de conexão com o S3? Assim que tivermos certeza de qual URL ele deseja conectar, posso interceptar o tráfego e compartilhar os resultados.
O motivo pelo qual o upload/backup do S3 não funciona é que a região precisa ser definida como fr-par (ou nl-ams), o que só pode ser feito contornando a validação de SiteSetting do Discourse:
É claro, isso é uma solução alternativa e, uma vez que você redefinir ou alterar essa configuração de site via Web Admin, não será possível retorná-la a um estado funcional (a menos que use o console do rails novamente).
Acredito que o cliente AWS/S3 permita definir explicitamente uma string de região (ao contrário do estado atual do webadmin).
Também é meio enganoso no caso do valor de dropdown “EU (Paris)” no Discourse, já que isso se refere ao esquema de nomenclatura da AWS eu-west-3 (ou algo assim) e não ao valor esperado para a Scaleway.
Aha. Precisamos de um campo de configuração do site especial “região compatível com S3” @falco? Isso permitiria que as pessoas inserissem regiões completamente arbitrárias (e, portanto, ‘inventadas’ sob a perspectiva da Amazon)?
Usuários de clones do S3 precisam definir a variável de ambiente S3 Endpoint, que sobrescreve a região do S3.
Tenho um tutorial completo explicando isso com o clone do S3 da Digital Ocean, mas estou aguardando a Digital Ocean corrigir um bug em seu CDN do S3 antes de divulgá-lo.
Se o Scaleway estiver em melhor situação que a Digital Ocean, acho que vou tentar e basear meu guia nele.
