Não consegui descobrir por que, na atualização mais recente, nossa instalação parou de servir ativos do CDN. Estamos usando o Cloudfront e ele funcionava bem para servir tanto uploads quanto ativos, mas parece que, na atualização mais recente, os ativos estão sendo servidos diretamente do servidor.
Outro problema que estamos enfrentando é que, ao passar a variável DISCOURSE_CDN_URL, o Discourse começa a solicitar ativos que não são gerados ou carregados pela tarefa s3:upload_assets (como folhas de estilo, por exemplo). Isso quebra completamente o site, exibindo uma página em branco. Este post menciona algo semelhante.
Removi o DISCOURSE_CDN_URL, que estava definido com o mesmo valor que DISCOURSE_S3_CDN_URL, pois isso quebrou o site (ele estava tentando buscar ativos que não existiam no S3).
Ao analisar o site em que eu estava tendo problemas, parece que eu havia esquecido o https:// na URL do CDN que estava usando. Não tenho certeza de como funcionou antes, ou, se nunca funcionou, como não percebi ao adicionar o valor incorreto.
@eatcodetravel, você, claro, precisa ocultar senhas do SMTP e chaves do S3, mas acho que precisará compartilhar pelo menos os valores do CDN para que alguém possa fazer qualquer suposição sobre qual pode ser o problema.
Sim, tive que remover DISCOURSE_CDN_URL. Ele começou a solicitar ativos que não estão sendo carregados no S3 pela tarefa rake s3:upload_assets, o que quebra completamente o site. Talvez essa tenha sido a parte que mudou e precisamos atualizar rake s3:upload_assets para que funcione corretamente novamente.
Sim, é possível usar a mesma URL de CDN tanto para DISCOURSE_CDN_URL quanto para DISCOURSE_S3_CDN_URL, mas isso exige muita configuração no CDN para usar a fonte correta para cada ativo com base na URL. Por exemplo, o CSS vem do aplicativo e o JS do S3, e este é apenas um caso; temos dezenas deles.
Portanto, a expectativa é que você configure ambos, onde o DISCOURSE_CDN_URL atua como um “proxy” para seu aplicativo web e o DISCOURSE_S3_CDN_URL é um proxy para seu bucket de armazenamento de objetos.
Ah, ok, isso é algo que mudou recentemente? Não tenho certeza se o Cloudfront suporta atuar como proxy reverso para nosso aplicativo em vez de um bucket S3. Vejo que você está usando o Cloudfront no meta. Há algo especial que você faz para executá-lo ou o próprio Discourse cuida de tudo?
Se você inspecionar esta página, verá que temos duas URLs diferentes do Cloudfront, então usamos o que mencionei acima: duas distribuições, uma para o CDN normal e outra para o S3.
O problema mencionado no título da postagem original é o seguinte: o CSS vem do aplicativo e o JS vem do S3. Você precisa de um CDN que saiba de onde vem cada ativo individual e possa acessar o local necessário, ou então dois CDNs. É por isso que temos duas configurações diferentes, afinal.
Embora isso faça todo o sentido agora que entendi, não tenho certeza de que isso esteja documentado. E você provavelmente vai se meter em problemas (pelo menos eu me meti!), pois a tarefa rake move-uploads-to-s3 exige que você tenha um s3_cdn. Isso explica por que, várias vezes, tentei mover coisas para o S3 e acabei desistindo.
Acho que seria legal se houvesse algum aviso do tipo “Cara, você não pode ter um CDN S3 sem um CDN de ativos” em algum lugar.
Ok, agora entendi o que você está dizendo; não sabia que isso era necessário. Posso perguntar por que o CSS precisa vir do aplicativo? Por que não podemos fazê-lo upload via a tarefa rake s3:upload_assets?
Vou pesquisar como fazer isso no Cloudfront e compartilhar aqui minhas descobertas e os obstáculos que encontrar.
Bem, talvez eu esteja explicando isso mal. Você pode. Mas é complicado, como seus tópicos e este aqui mostram.
O site do @eatcodetravel está rodando agora com apenas S3_CDN configurado, mas você acaba em um estado estranho onde o CSS (que bloqueia a renderização) é servido pelo seu servidor, enquanto as imagens nos posts não são, o que não faz sentido.
Porque Admin > Personalizar é uma coisa. As pessoas podem alterar o CSS no painel de administração. Snippets de JS personalizados que vivem em temas também são servidos pelo aplicativo, pelo que sei.
Acabei corrigindo isso criando uma segunda distribuição do CloudFront apontando para o servidor web e mantendo a outra apenas para o S3. Obrigado, @Falco, pelo feedback, mas concordo que isso precisa ser documentado de forma um pouco melhor.
