@Falco - Seria bom adicionar um aviso para a Scaleway, de que ela suporta apenas 1.000 partes para upload multipart, enquanto a AWS suporta 10.000. Isso não é um problema para uploads regulares, mas é um problema para uploads de backup acima de um certo tamanho, pois o SDK S3 usará 10.000 partes, a menos que modificado manualmente, e falhará.
4 curtidas
Ótima descoberta! Por favor, adicione-a à wiki do OP, se puder.
4 curtidas
Obrigado, também gostaria de acrescentar que você pode usar qualquer uma dessas ferramentas para copiar de nuvem para nuvem, especialmente de/para armazenamento de objetos compatível com S3, por exemplo, Rclone, Shargate, Gs Richcopy360 e GoodSync. todas essas são compatíveis com nuvens semelhantes.
1 curtida
Descobrimos um problema, o Cloudflare R2 não permite leitura pública do URL do endpoint S3, mas sim apenas o domínio personalizado ou um domínio r2.dev aleatório.
(Downloads pré-assinados funcionam, apenas o acesso público direto não é suportado.)
Mas o Discourse usa apenas o URL da CDN para imagens incorporadas, e não para downloads diretos, que usam o URL do endpoint S3.
Existe alguma maneira de fazer com que ele use o URL da CDN para todos os arquivos, ou forçar o uso de uma URL pré-assinada?
Relacionado:
A solução alternativa mencionada nesse post funciona, adicionar ?dl=1 corrige isso, porque força o Discourse a usar uma URL S3 pré-assinada.
1 curtida
Corrigido em 2023-03-16 agora o R2 funciona com o Discourse perfeitamente com o plano gratuito
3 curtidas
Eu também vejo isso com alguma frequência (a cada poucos meses), embora meu Discourse esteja rodando no AWS Lightsail e eu esteja enviando para o AWS S3. Então não tenho certeza se é culpa do wasabi.
Seria possível capturar esse erro e alertar o administrador? Eu verifico o espaço em disco e removo backups antigos quando faço o upgrade, mas às vezes é tarde demais e o fórum fica inativo por falta de espaço em disco.
1 curtida
Tenho quase certeza de que o problema era que reinicializações automáticas do sistema operacional para atualizações de segurança estavam ocorrendo enquanto o backup estava em execução. Certifique-se de agendar suas reinicializações do sistema operacional e seus backups em horários diferentes. Foi depois que mudei esse site do wasabi que cheguei a essa explicação, mas tenho certeza de que foi isso.
2 curtidas
O uptime diz que está ativo há 300 dias, então não acho que esse seja o problema. Mas, em linhas semelhantes, eu tinha backups do Discourse agendados para as 2:00 da manhã e snapshots do Lightsail para as 2:30 da manhã, então talvez o upload às vezes não seja concluído e o snapshot interfira. Separei as duas operações em uma hora - veremos se isso faz diferença.
Independentemente disso, acho razoável alertar os administradores se o upload falhar, por qualquer motivo.
2 curtidas
Acho que é hora de fazer atualizações de kernel e reiniciar. 
Você pode estar ficando sem RAM?
Após implementar backups remotos do Backblaze, vejo este erro no meu painel:
O servidor está configurado para enviar arquivos para o S3, mas não há um CDN S3 configurado. Isso pode levar a custos S3 caros e desempenho mais lento do site. Veja "Usando Armazenamento de Objetos para Uploads" para saber mais.
Eu não configurei o upload de arquivos, apenas configurei backups através desta configuração:
DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3
Eu fiz algo errado?
Algo parece mal configurado, notei que ao tentar enviar um arquivo para uma postagem, recebi este erro:
Valor não suportado para canned acl ‘public-read’
Qualquer ajuda seria apreciada.
2 curtidas
Remova isso se você não quiser que os uploads vão para o s3.
4 curtidas
Você salvou o dia, irmão. 
Muito obrigado!
2 curtidas
Isso pareceu funcionar?
1 curtida
Isso aconteceu uma vez no último mês desde que separei os dois processos por uma hora, então não “consertou”, e não acontece com frequência suficiente para dizer se ajudou.
Pelo lado positivo, notei que há uma seção de status de backup na página de administração que mostra o espaço livre em disco, o que me poupa de abrir constantemente um terminal e executar um df apenas para verificar se há backups travados. Personalizei o texto para me lembrar que espero cerca de 80 GB livres.
1 curtida
Essa é uma boa ideia.
Eu vi a imagem antes de ler que você tinha personalizado o texto e estava me perguntando qual lógica estava em jogo para determinar que isso era “bom”!
1 curtida
Eu simplesmente não consegui fazer isso funcionar com a Scaleway usando a imagem Bitnami Discourse.
As variáveis de ambiente foram definidas, mas claramente não estavam sendo lidas/aplicadas corretamente (ou de forma alguma?).
Então, defini as variáveis S3 no painel de administração e defini a região diretamente no console do Rails (ainda esperando que isso se torne apenas um campo de texto):
SiteSetting.s3_region="fr-par"
Isso me deu um erro de validação, mas eu apenas comentei a verificação de validação antes de atualizar a configuração e, em seguida, a inseri novamente.
1 curtida
A imagem Bitnami não é empacotada por nós e não segue nossas recomendações. Tudo o que está documentado aqui é testado apenas com a instalação oficial.
4 curtidas
Isso foi resolvido habilitando “s3 use cdn url for all uploads”, uma opção adicionada recentemente pelo discourse.
Como estávamos usando R2 antes, precisávamos usar discourse remap para substituir manualmente os links quebrados, sincronizamos os arquivos s3 por precaução e, em seguida, reprocessamos todas as postagens.
1 curtida
Estou tentando configurar isso com o idrive e2, que é compatível com s3. No entanto, estou recebendo um erro/stack trace nada útil no final de ./launcher rebuild app:
I, [2023-10-14T15:08:08.026184 #1] INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: We encountered an internal error, please try again.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1] INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js
Esta é a configuração que tenho usado, mas também tentei com DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY e DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: Dallas
DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
DISCOURSE_S3_ACCESS_KEY_ID: <snip>
DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
DISCOURSE_S3_BUCKET: discourse
DISCOURSE_S3_INSTALL_CORS_RULE: false
Note que não estou usando para backups (isso já está configurado na UI com backblaze) nem DISCOURSE_CDN_URL porque não tenho certeza se o idrive suporta isso - planejei experimentar isso assim que tivesse alguns arquivos reais no bucket.
1 curtida
Parece que não é compatível o suficiente com o S3 para as necessidades do Discourse.
Se quiser investigar mais, o próximo passo seria reproduzir isso em uma instalação de desenvolvimento e obter a chamada de API exata que falha.
2 curtidas