Tive que estacionar isso por enquanto, pois parecia que ia funcionar, mas então há algo estranho acontecendo com o R2 em termos de codificação de conteúdo com os ativos, seja no upload e não definindo o cabeçalho ou algo mais. Ele falhará com um ‘Token inválido ou inesperado’ dado o ativo gz de algo como browser-detect-7af298cd000a967d2bdc01b04807eda2924a388584ea38ad84919b726283c2ed.gz.js. O rake s3:upload_assets parece estar funcionando, mas os arquivos não estão sendo lidos corretamente no lado do navegador.
Eu realmente não entendo por que com o AWS S3 está tudo bem usar a URL do servidor local para ativos (eles não existem em nosso bucket S3 existente para uploads), mas para uso R2 ele quer usar DISCOURSE_S3_CDN_URL apenas para ativos. Se eu pudesse forçar os ativos a serem da URL do servidor, tudo isso provavelmente funcionaria.
EDIT: Conversando no CF, este parece ser o problema, e a partir de hoje por que o R2 não pode ser usado com Discourse sem algumas alterações. Eu poderia criar um script na etapa do hook de postagem para remover os ativos gz, mas sinto que já estou ‘fora do caminho’ o suficiente por hoje:
Arquivos que você comprime em gzip não são atualmente tratados corretamente pelo R2. Você tem que fazer upload de arquivos não compactados. O Cloudflare tem compressão transparente, eles escolhem identidade, gzip ou Brotli com base no que o cliente pode lidar. Isso é uma diferença do S3.
Obrigado por montar este guia! Tive algum sucesso usando o Minio.
Para quem mais estiver tentando configurá-lo localmente com Docker Compose, você pode dizer ao Docker para adicionar um alias de hostname para que funcione como um subdomínio, assim:
Neste caso, você definiria DISCOURSE_S3_ENDPOINT=http://minio.mydomain.com:9000, DISCOURSE_S3_CDN_URL=//assets.minio.mydomain.com:9000, e definiria seu arquivo local /etc/hosts/ para apontar o subdomínio para localhost.
Olá @Falco - Isso se refere à forma como o cabeçalho Content-Encoding: gzip funciona com a CDN do Spaces deles? Isso soa semelhante ao Cloudflare R2, no sentido de que a localização do ativo é feita para ser a mesma da CDN de uploads, então o gzip quebra? Aqui está o que acontece com o R2 hoje.
Pode valer a pena considerar uma opção para esse comportamento, ou seja, servir ativos da origem em vez de sempre DISCOURSE_S3_CDN_URL? Ficarei feliz em procurar como fazer isso, se for considerado como uma potencial mudança de configuração.
É isso que deveria acontecer se você omitir a configuração de DISCOURSE_S3_CDN_URL, mas como é um caso de uso peculiar e um erro potencialmente caro, não é uma configuração comum.
Sim, eu entendo isso. Uma nova entrada booleana S3_ORIGIN_ASSETS (ou S3_BROKEN_PROXY_FUDGE) em algum lugar por aqui, mais ou menos como o scripts de teste não são compactados permitiria que Digital Ocean Spaces e Cloudflare R2 funcionassem com Discourse imediatamente, o que é uma adição de recurso interessante com pouco esforço? Talvez para consideração futura, de qualquer forma.
Ah, eu vi nas notas de lançamento do 3.0.beta que algo foi adicionado. Vou tentar, a menos que eu entenda mal para que serve? Isso pode permitir que Cloudflare R2 e Digital Ocean Spaces sejam usados com suas CDNs fazendo aquelas coisas estranhas com gzip.
A configuração permitiu-me especificar o site local como a origem, para contornar a necessidade de os assets js estarem no site S3 (neste caso, Cloudflare ou Digital Ocean Spaces com CDN ativado). Graças a @david pela alteração, mesmo que essa não tenha sido a intenção.
Obrigado, verifiquei novamente e parece funcionar com configuração automática, mas não com o gerenciamento das minhas próprias chaves do gerenciamento S3.
isso parece ter sido corrigido recentemente.
No changelog de 16/03/2023 lista a correção de bug para o manuseio de arquivos gzip.
Estamos executando nosso fórum discourse em discourse.aosus.org com R2 no momento (ainda não executamos migrate_to_s3), e parece estar tudo bem!, sem problemas perceptíveis até agora.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-east-1" #alias para auto
#DISCOURSE_S3_INSTALL_CORS_RULE: true #deve ser suportado
DISCOURSE_S3_ENDPOINT: S3_API_URL
DISCOURSE_S3_ACCESS_KEY_ID: xxx
DISCOURSE_S3_SECRET_ACCESS_KEY: xxxx
DISCOURSE_S3_CDN_URL: sua url do cdn
DISCOURSE_S3_BUCKET: NOME_DO_BUCKET
há alguma maneira de especificar um host separado para backups?, seria ótimo se fosse possível deixar o R2 apenas para coisas de CDN.
É estranho que as configurações no ENV não se reflitam na interface do administrador. Ocorre substituição? Novas configurações do S3 na interface do administrador substituirão as do ambiente?
) em algum lugar por aqui, mais ou menos como o 