Solução de problemas de uploads S3: site trava após reconstrução, ativos JS falham ao carregar com net::ERR_... em R2 e GCS

[Ryze_Chen]

Olá Equipe e Comunidade Discourse,

Tenho tentado configurar minha instância Discourse auto-hospedada para usar um armazenamento de objetos compatível com S3 externo, mas me deparei com um problema muito persistente e incomum. Ficaria muito grato por qualquer ajuda.

Meu Ambiente:

• Versão do Discourse: Instalação Docker padrão, última tests-passed.

• Host: [SEU PROVEDOR DE VPS e OS] (请在这里填入您的服务商和系统)

• Proxy Reverso: Caddy

Objetivo: Meu objetivo é mover todos os uploads (uploads de usuários e ativos do site) do armazenamento local para um provedor externo.

Resumo do Problema: Após configurar o app.yml para S3 (Cloudflare R2 ou Google Cloud Storage) e executar ./launcher rebuild app, o site fica travado na tela de carregamento inicial (o spinner azul). As ferramentas de desenvolvedor do navegador mostram que a maioria dos ativos JavaScript principais falha ao carregar do URL da CDN externa com um erro de rede genérico (net::ERR_...).

Etapas de Depuração Realizadas:

1. Tentativa com Cloudflare R2:

   • Configurei um bucket Cloudflare R2, criei um Token de API (Leitura e Gravação de Objetos) e conectei um domínio personalizado (s3.ryzelan.sbs) via Cloudflare DNS.
   • Configurei o app.yml com as credenciais R2, o domínio personalizado como o endpoint/URL da CDN e defini DISCOURSE_FORCE_HTTPS: true e DISCOURSE_S3_FORCE_PATH_STYLE: true.

2. Teste Crucial - Mudança para Google Cloud Storage:

   • Para descartar um problema específico do Cloudflare, reverti todas as alterações e fiz uma nova configuração com o Google Cloud Storage usando chaves de interoperabilidade S3.
   • Após reconstruir com a configuração do GCS, encontrei o mesmo padrão de falha de carregamento de JavaScript que com o R2.

Status Atual:

• O processo ./launcher rebuild app é concluído sem erros exibidos no terminal.
• O contêiner app está em execução corretamente após a reconstrução (verificado com docker ps).
• O comando ./launcher logs app não mostra erros; todos os serviços internos (unicorn, redis, postgres) parecem estar em execução normalmente.
• O problema parece ser uma falha em nível de rede quando o navegador tenta buscar ativos JS do URL da CDN externa configurada, e isso acontece independentemente do provedor (R2 ou GCS) usado.

Aqui está o bloco de configuração final do app.yml que usamos para R2 (o do GCS foi semelhante):

— Cloudflare R2 S3 Configuration START (Final Version) —

DISCOURSE_FORCE_HTTPS: true
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: “us-east-1”
DISCOURSE_S3_ENDPOINT: “https://s3.ryzelan.sbs”
DISCOURSE_S3_CDN_URL: “https://s3.ryzelan.sbs”
DISCOURSE_S3_ACCESS_KEY_ID: “REDACTED”
DISCOURSE_S3_SECRET_ACCESS_KEY: “REDACTED”
DISCOURSE_S3_BUCKET: “ryzelan-discourse”
DISCOURSE_S3_FORCE_PATH_STYLE: true

— Cloudflare R2 S3 Configuration END —

Minha Pergunta: O que poderia causar uma reconstrução nova do Discourse falhar consistentemente ao carregar seus próprios ativos de dois provedores de nuvem diferentes e importantes com um erro de rede? Existe algum problema conhecido com certos ambientes de rede de VPS, rede Docker ou Caddy que possa estar causando isso?

Obrigado pelo seu tempo e por quaisquer insights que possa fornecer.

[pfaffman (Jay Pfaffman)]

@Ryze_Chen

o site trava na tela de carregamento inicial (o spinner azul).

Você incluiu o código para fazer upload desses ativos para o S3?

@Discourse

Para armazenar os ativos estáticos do Discourse em seu Object Storage, adicione esta configuração em seu app.yml na seção hooks:

  after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

Se você não fizer isso, nenhum dos ativos estará no S3 e o site não carregará.

[tobiaseigen]

@Ryze_Chen você conseguiu resolver seu problema?