Então, configurei um bucket do Amazon S3 para armazenar os recursos do meu fórum, coloquei-o em um domínio personalizado e configurei o CloudFlare CDN para armazenar em cache o conteúdo.
Tudo está funcionando corretamente. Se eu adicionar uma imagem à pasta principal do bucket, consigo recuperá-la na minha URL personalizada, ou seja, http://forum-storage.com/test.jpg retorna a imagem, com os cabeçalhos do CloudFlare.
Três perguntas fáceis…
#1
Agora preciso dizer ao Discourse para usar essa nova URL como meu bucket S3. O que devo colocar nestes 3 campos?
Atualmente, tenho imagens nas postagens do fórum que estão em outro bucket S3, e também tenho imagens armazenadas localmente. (Minhas URLs de imagens estão espalhadas por toda parte.)
Assim que fizer as alterações corretas (acima), isso significa que toda mídia NOVA adicionada ao meu fórum irá para o novo bucket, mas as imagens existentes não serão movidas e continuarão sendo acessadas onde estão atualmente, correto?
#3
Agora que isso está funcionando para todas as imagens daqui para frente, como posso dizer ao Discourse para MOVER todas as imagens antigas que não estão neste novo bucket para dentro dele (e reprocessar as postagens conforme necessário)?
O objetivo é colocar tudo em um único bucket, este novo, atrás do CDN.
Crie um novo bucket que não tenha um ponto no nome. Você enfrentará sofrimento interminável se continuar, devido ao modo como os certificados SSL curinga funcionam.
Hmm, isso é legal, mas você quer ter um CDN, como o CloudFront, na frente do bucket, que receberá o CNAME, então essa não é uma funcionalidade útil no momento.
Não ter um CDN resultará na mesma conta de transferência exorbitante.
Certo. Acho que estamos na mesma página? Para ser mais claro, pelo que entendi, existem 3 tipos de maneiras de conectar o Discourse ao S3:
Fazer o Discourse usar a nuvem S3 diretamente. Pró: super fácil de configurar. Contra: torna-se rapidamente caro.
Fazer o Discourse usar a nuvem S3 através de um domínio personalizado (como forum-storage.com) para que eu possa usar um CDN. Prós: muito fácil de configurar com o S3 se o nome do bucket corresponder exatamente ao domínio personalizado (ou seja, forum-storage.com.s3-amazon-aws.com). Contras: o SSL não fica feliz.
Fazer o Discourse usar a nuvem S3 através de um domínio personalizado (novamente, para que eu possa usar um CDN), mas configurar o bucket S3 de modo que ele não tenha um ponto extra no nome (ou seja, forum-storage-com.s3-amazon-aws.com). Prós: o SSL fica feliz. Contras: não é tão fácil de configurar com o Amazon S3.
Então… eu estava usando a opção #1 até receber a conta depois descobri que a #2 era uma opção, configurei, comecei este tópico e, imediatamente, descobri que a #2 não era realmente uma opção.
Agora estou trabalhando na #3. Acho que tenho que usar o serviço DNS “Route 53” da Amazon, ou algo assim. Ainda estou tentando entender. Todas as minhas pesquisas no Google retornam informações sobre como fazer a #2, mas ninguém parece ter escrito instruções claras para a #3.
Por favor, corrija-me se eu estiver errado ou mal interpretando algo…
Adicionei um registro CNAME apontando para a URL <long id>.cloudfront.net da distribuição CDN Cloudfront à nossa configuração DNS do bokeh.org (que, no nosso caso, está no Cloudflare, mas isso não deve importar).
Como referência, nosso bucket S3 não tem pontos no nome, mas também não me lembro de nenhum problema específico na configuração da CDN por causa disso (ou de problemas ao criar o bucket; ele apenas precisa de um nome único).
Isso é, sem dúvida, a coisa mais frustrante de todas. Não consigo, de forma alguma, descobrir como conectar um bucket do Amazon S3 (sem ponto no nome do bucket!), meu domínio personalizado e o CloudFlare para fazê-los funcionar juntos. Se eu pudesse colocar um ponto no nome do bucket, não haveria problema. Mas, por enquanto, está tudo muito confuso. Ughhhhhh, alguém pode me ajudar ou me indicar uma maneira simples de configurar o CloudFlare com um bucket S3 que não tenha o mesmo nome do domínio?
Tentei as informações do StackPath acima — acho que fiz algo similar no CloudFlare, mas não tenho certeza. Não funcionou. Tentei ler as informações do CloudFlare sobre como adicionar o CDN a um bucket da Amazon, mas, é claro, eles exigem que o nome do bucket seja igual ao nome do domínio, o que me disseram ser uma péssima ideia e não posso fazer isso.
Realmente parece se resumir a isso:
Se o nome do bucket for igual ao nome do domínio (com um ponto), o Amazon S3 cuida de tudo por mim, lindo, maravilhoso, exceto que isso causa problemas com SSL, então não devo fazer isso.
Se o nome do bucket NÃO corresponder ao nome do domínio, tudo fica muito mais complicado e não consigo resolver.
Alguém pode ajudar ou dar conselhos? Enquanto isso, estou recebendo contas de mais de US$ 100 por mês pelo meu armazenamento S3. Isso é terrível. Posso pagar US$ 200 agora mesmo para alguém resolver tudo isso? Blargh.
Você já leu isso? Eu também tive dificuldades para configurar o S3 e o Cloudflare, mas finalmente consegui resolver. Você ainda pode usar o Cloudflare pelo benefício de segurança, mas tenho quase certeza de que precisará de um serviço de CDN separado também. O Cloudflare não é como uma CDN normal, ele funciona de maneira diferente. Você deve migrar para um serviço S3 mais barato; a Amazon é cara.
Usar o Cloudflare para armazenar em cache um bucket S3 significa que você precisa manipular o cabeçalho de origem nas solicitações. Esse recurso está disponível no plano empresarial do Cloudflare, portanto, usar qualquer outra CDN pode ser mais fácil.
O ponto no nome do bucket não é irrelevante, já que as imagens serão armazenadas em cache via CDN de qualquer forma? O único fator importante é ter um certificado válido que cubra as imagens servidas pelo Cloudflare.
Acho que ele precisa se concentrar nos servidores do Cloudflare, no DNS e no certificado para cobrir esses aspectos. Não acredito que o usuário ou o navegador jamais saberão que a origem dessas imagens é um bucket S3. O Cloudflare armazenará em cache e fará o proxy da imagem em si, certo?
@riking Tudo o que o Discourse parece exigir é um nome de bucket, correto? O upload e a gestão podem ser feitos via URLs da AWS com seus certificados, caso HTTPS seja realmente necessário. Até agora, há algum motivo para estarmos falando sobre certificados de segurança?
O OP pode, então, verificar separadamente o que precisa fazer para permitir que sua CDN ou solução de cache busque as imagens do S3. Seguro ou não, não importa, a menos que o OP ou a CDN tenham requisitos específicos, certo? O Discourse se importa com a configuração dele entre o S3 e a CDN?
Por fim, o OP precisa garantir que as imagens sejam servidas pela CDN com um certificado válido. Isso tem alguma relação com o Discourse, além do OP fornecer a URL base onde as imagens ficarão hospedadas? Uma vez que sua CDN ou cache busque as imagens do S3, a AWS, os buckets, etc., saem completamente da equação.
Entendo que há questões relacionadas ao ponto nos nomes de buckets do S3 se você pretende servir as imagens diretamente de lá, mas o OP NÃO pretende. Portanto, tudo se resume ao OP escolher qualquer nome de bucket que o Discourse aceite, desde que não interfira em sua configuração com a CDN.
Embora seja possível evitar URLs de bucket no domínio, elas não são realmente evitadas devido à forma como o SDK do AWS S3 é utilizado e à dificuldade de configurá-lo.
Novamente, essas operações contornam a CDN; a única maneira de corrigi-las está no código-fonte do Discourse. Elas podem ser corrigidas, mas atualmente não estão. Muitos dos problemas também não ocorrem no caminho crítico e só aparecem mais tarde. Portanto, até que isso mude, não use nomes de bucket com pontos.
Então, para simplificar ao máximo… a pergunta do OP era o que preencher em três configurações:
(1) NOME DO BUCKET – então está sendo dito que pontos não são… recomendados? não permitidos? Suspeito que isso pode não ser um problema para o OP. (Ele só precisa descobrir separadamente uma maneira para o CDN dele obter imagens em cache e servi-las.) Então, estamos todos na mesma página, certo?
(2) ENDEREÇO S3 – deixe em branco, nada é necessário se ele estiver usando AWS; caso contrário, ele pode preencher para outro provedor?
(3) URL DO CDN S3 – isso é simplesmente a URL base que o Discourse vai adicionar ao caminho da imagem? Se for, então é simples e direto, e o OP pode configurar seu CDN e fornecer essa URL base aqui.
Não vejo onde certificados SSL curinga entram nisso. O OP foi informado de que um ponto na configuração do Discourse é ruim porque quebrará o certificado dele. Mas se ele estiver usando um CDN ou cache, o nome do bucket pode muito bem ser irrelevante para o certificado, certo? Se isso quebrar o Discourse de outra forma, é útil saber.
Não tenho certeza se estou acompanhando tudo isso tão de perto, mas para dar um passo atrás, talvez esse conjunto simples de requisitos ajude:
Os objetivos:
Não armazenar minhas imagens do Discourse no meu servidor Discourse
Ter um bucket S3 para armazenar imagens (deve ser S3, já que é o que o Discourse suporta)
Não ter cobranças caras do S3
Um CDN não é obrigatório, mas é um bônus legal, pois pode ajudar a reduzir (ou ser a única maneira de eliminar) as cobranças caras do S3 e também oferece melhor disponibilidade em todo o mundo, um backup caso o servidor principal fique offline, etc., etc.
Por favor, corrija-me se algo disso estiver errado
Limitações/requisitos:
O armazenamento externo de imagens precisa suportar o protocolo S3 (já que é assim que o Discourse funciona), mas, estritamente falando, não precisa ser o S3 da Amazon.
O Discourse exige que o nome do bucket S3 não tenha pontos.
A fonte das imagens (S3 ou CDN) deve servir via https://, pois um navegador reclamará se a página for https, mas as imagens não forem.
Por favor, corrija-me se algo disso estiver errado
Soluções:
Anteriormente, eu servia diretamente do Amazon S3. Funcionava muito bem, exceto pelas cobranças da Amazon por DataTransfer-Out-Bytes, que são super caras. Isso gerou contas mensais altas da Amazon! Então, eu voltei a usar o servidor principal. Duas possíveis correções para isso: colocar um CDN na frente do bucket do Amazon S3 para que o CDN gerencie toda a transferência de dados e/ou mudar para um provedor S3 diferente.
Tentei colocar o CDN do CloudFlare na frente do bucket do Amazon S3, mas rapidamente encontrei muitos problemas que não consegui resolver.
Como referência, servi ~300 GB do S3 nos últimos 30 dias. Parte disso são backups do site, e muito são imagens estáticas. É MUITO difícil para mim separar como medir essas coisas na Amazon… a interface de relatórios de faturamento deles—como tudo o mais na Amazon AWS—é realmente confusa para administrar.
Acredito que a solução mais simples seja AWS e KeyCDN, seguindo as orientações em Usando Armazenamento de Objetos para Uploads (S3 e Clones). Se seus usuários não estiverem na América do Sul, o KeyCDN é bastante acessível e fácil de configurar.
Uma solução potencialmente menos cara pode ser Como Configurar o BackBlaze S3 com o BunnyCDN. Tenho ficado satisfeito com o BackBlaze em meus testes iniciais para backups, mas ainda não o testei para uploads.
Ficamos completamente distraídos com um ponto no nome do bucket e com certificados de navegador, mas acredito que toda essa discussão seja totalmente irrelevante. QUALQUER CDN permitirá a configuração HTTPS, então não há NENHUM PROBLEMA com o problema do “certificado curinga” e com a presença ou ausência de um ponto no nome do bucket, QUANTO AO CERTIFICADO DE NAVEGADOR DO USUÁRIO FINAL. Porque, novamente, QUALQUER CDN certamente permitirá isso.
Então, o OP pode simplesmente…
(1) escolher uma solução de armazenamento compatível com S3 e CDN e configurar o endpoint e o nome do bucket nas configurações do Discourse.
(2) Configurar a CDN para buscar imagens no S3. Com segurança ou sem segurança. Acredito que ao OP não importe, desde que a CDN sirva ao usuário via HTTPS.
Por favor, alguém me corrija se estiver deixando algo passar. Acredito que o problema do certificado de navegador do usuário final + ponto no nome do bucket seja um problema APENAS se você for servir as imagens DIRETAMENTE do bucket. Irrelevante para servir via CDN.
PARE AGORA 
Obrigado pela dica, 
depois descobri que a 
NÃO coloque um ponto (ponto final) no nome do seu bucket