Eu recebi um aviso na minha linha de comando sobre espaço em disco antes de reconstruir meu container enquanto instalava um plugin do Discourse. Tive que executar alguns comandos para remover versões mais antigas do Linux no meu droplet da DigitalOcean, mas ainda estou acima de 50% da capacidade do SSD.
À medida que meu site Discourse cresceu, comecei a analisar soluções de armazenamento. Atualmente, estou em um droplet da DigitalOcean de 5 dólares e li sobre o armazenamento em bloco da DigitalOcean e o Amazon S3. Vejo as configurações do S3 integradas às configurações do Discourse, então imagino que seja mais fácil de configurar.
O que você usa para seu site? Qual tem velocidades de carregamento melhores, S3 ou blocos da DigitalOcean? Qual opção é mais barata? A camada gratuita do S3 não o tornaria mais barato que os blocos da DigitalOcean? Você armazena suas imagens E backups? Ou recomenda outra opção fora da DigitalOcean e da Amazon?
Há muitos provedores que oferecem soluções de armazenamento compatíveis com S3. Você pode usar qualquer um deles. Eu já usei alguns e posso recomendar que o Digital Ocean Spaces funciona muito bem.
Se você já está hospedando na DO, recomendo usar o Spaces, pois é rápido e confiável.
No entanto, existem algumas preocupações relacionadas ao CDN deles, então você pode precisar considerar um CDN de terceiros.
O plano gratuito do Cloudflare funcionaria como CDN na frente do bucket? Eu já os uso com as configurações do meu domínio para proteção gratuita contra DDoS.
Notei que a DigitalOcean anuncia que seu serviço Spaces é mais barato do que os outros provedores bem conhecidos. Então, isso é definitivamente uma vantagem.
Como a CDN que vem com o DigitalOcean Spaces não funciona corretamente com o Discourse, estou pensando em optar por um dos outros provedores da sua lista. Assim, não preciso pagar pelo DigitalOcean Spaces e por um serviço de CDN separado.
A falta de content-encoding na implementação do CDN da DO é definitivamente frustrante, mas isso só ocorre ao definir todos os parâmetros S3 dentro do app.yml. Se esses parâmetros forem definidos nas configurações do site via console de administração web, a DO servirá apenas os uploads S3 via CDN, enquanto os ativos do site ainda serão servidos da origem.
Parece que isso é intencional, pois a variável de ambiente DISCOURSE_S3_CDN_URL, se definida no app.yml, substitui a configuração do CDN também para os ativos, enquanto essa mesma configuração, quando declarada apenas nas configurações do site, não faz isso?
Isso é um pouco inconsistente, mas permite que o CDN da DO seja usado apenas para uploads S3, sem quebrar o site:
Existem duas maneiras de fazer isso:
declarar todos os configurações S3 apenas nas configurações do site
rails c
SiteSetting.s3_upload_bucket="<bucket_name>/<uploads_folder>"
SiteSetting.s3_backup_bucket="<bucket_name>/<backups_folder>"
SiteSetting.enable_s3_uploads=true
SiteSetting.s3_access_key_id="<key>"
SiteSetting.s3_secret_access_key="<secret_key>"
SiteSetting.s3_endpoint="https://<sfo2>.digitaloceanspaces.com"
SiteSetting.s3_cdn_url="https://<bucket_name>.<sfo2>.cdn.digitaloceanspaces.com/<uploads_folder>"
SiteSetting.backup_location="s3"
replicar todas as configurações S3 excetoDISCOURSE_S3_CDN_URL no app.yml, e declarar o CDN da DO em SiteSetting.s3_cdn_url
Todos os outros provedores, até mesmo a AWS, exigem uma CDN. Oferecer uma gratuita que está quebrada é apenas uma peculiaridade; podemos ignorá-la e tratá-la como um serviço padrão de Armazenamento de Objetos.
Não tenho certeza se o detalhe de implementação de definir S3 CDN URL no arquivo yml e nas configurações do site, resultando em comportamentos diferentes, é algo que queremos promover, pois pode ser corrigido a qualquer momento.
Não testei, mas posso garantir que funciona com serviços de CDN reais, como KeyCDN, Cloudfront, StackPath, etc.