O suporte/compatibilidade do Contabo S3 será adicionado? ou alguém encontrou uma solução alternativa para fazê-lo funcionar?
2 curtidas
Nós, os mantenedores do Discourse, apenas oferecemos suporte à AWS S3. Os provedores listados aqui foram testados por nós ou pela comunidade para verificar se implementam o suficiente da API S3 para serem compatíveis com o Discourse.
Conforme o OP, @tuxed testou o Contabo e o considerou deficiente. Cabe ao Contabo evoluir sua implementação em conformidade com a S3, se considerarem alinhado aos seus interesses comerciais, não algo que nós possamos fazer.
4 curtidas
Isso ainda está com bugs? Por que a CDN da Digitalocean não é boa?
1 curtida
Você seguiu os links?
Parece que o CDN não sabe sobre metadados. Mas você poderia tentar e ver se funciona! Nos avise se você o fizer. Eu estava me perguntando se já tinha sido corrigido outro dia. Pelo que parece na documentação, não vou tentar tão cedo.
2 curtidas
Estou procurando uma maneira fácil de adicionar suporte a CDN ao meu fórum no DigitalOcean. Se o S3 for mais fácil, optarei por essa opção.
Não quero correr o risco com uma configuração que não funcionou bem antes.
2 curtidas
A solução recomendada é simplesmente não usar o CDN deles. Você pode usar o Spaces, se seguir as instruções acima, e algo como o bunny.net para o CDN. É barato e fácil.
O Aws S3 é o que o cdck usa, então é um pouco mais testado e suportado, mas a menos que você já tenha experiência com a AWS, o bucket Spaces é uma boa solução. Apenas não use o CDN da Digital Ocean.
2 curtidas
Acabei de passar por isso - configuração de CDN, mantendo as imagens locais por enquanto - primeiro com Fastly, depois com outro que não me lembro. Optei pelo Bunny.net. muito fácil de configurar. Eles têm um guia específico para Discourse. Estamos auto-hospedados no DO com mais de 100 GB de imagens. Taxa de acerto de cache de 65% e subindo.
2 curtidas
a política de tumba de configuração s3 funciona apenas em aws.amazon?
1 curtida
Não. É um problema apenas no Backblaze.
2 curtidas
3 posts foram divididos para um novo tópico: Explorando Soluções para Problemas de Upload de Foto de Perfil do Usuário
Ufa, por onde começo? Então, estou usando o Cloudflare para cache e DNS, e o Backblaze B2 para armazenamento. Consegui fazer funcionar, mas apenas parcialmente. Durante um ./launcher rebuild app, vi que ele estava carregando assets, então fiquei super animado que parecia estar funcionando. Após a reconstrução ser concluída com sucesso, não consegui acessar o site. Eu apenas vejo alguns pontos se movendo no meio da página.
Com base no artigo da Backblaze Entregar Conteúdo Público do Backblaze B2 Através do CDN do Cloudflare, configurei um registro CNAME Proxied que aponta para a origem do URL Amigável f000.backblazeb2.com chamado gtech-cdn.
CNAME gtech-cdn –\u003e f000.backblazeb2.com
O artigo também fala sobre Regras de Página; tentei ativá-las e desativá-las sem sucesso.
Aqui estão os itens de configuração pertinentes:
DISCOURSE_HOSTNAME: mmhmm.com
DISCOURSE_CDN_URL: https://mmhmm.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-000
DISCOURSE_S3_ENDPOINT: https://s3.us-west-000.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <secret>
DISCOURSE_S3_SECRET_ACCESS_KEY: <secret>
DISCOURSE_S3_CDN_URL: https://gtech-cdn.mmhmm.com
DISCOURSE_S3_BUCKET: gtech-uploads
DISCOURSE_S3_BACKUP_BUCKET: gtech-uploads/backups
DISCOURSE_BACKUP_LOCATION: s3
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
Uma das coisas que me confunde é o que colocar nas duas variáveis DISCOURSE_S3_CDN_URL e DISCOURSE_CDN_URL. Eu as configurei corretamente com base nas informações que forneci?
Olhando no console de ferramentas de desenvolvedor do navegador, estou recebendo erros 404 em scripts .js. O URL não parece estar sendo construído corretamente. Não deveria ter /file/ antes de /assets? Se eu adicionar isso manualmente para criar um URL adequado, funciona:
https://gtech-cdn.mmhmm.com/file/gtech-uploads/assets/google-universal-analytics-v4-e154af4adb3c483a3aba7f9a7229b8881cdc5cf369290923d965a2ad30163ae8.br.js
Obrigado por qualquer ajuda, é muito apreciada!!!
1 curtida
https://gtech-cdn.mmhmm.com não resolve, então essa é a primeira coisa a consertar.
Não tenho certeza se você pode usar o Cloudflare como um CDN dessa forma, mas talvez eu esteja enganado.
1 curtida
Desculpe, eu deveria ter mencionado que mmhmm.com é um domínio falso. Ele responde a um ping.
Quanto ao Cloudflare não poder ser usado como CDN, acho que não estou entendendo. O artigo que linkei claramente é para usá-lo como CDN. Se isso não for verdade, então, novamente, quais valores devem ser usados nas duas variáveis DISCOURSE_S3_CDN_URL e DISCOURSE_CDN_URL?
Abraços,
Se você fornecer URLs falsas, só poderá obter respostas falsas.
A URL serve os dados esperados? Você consegue recuperá-la da URL do fórum?
Eu acho que o CDN S3 deveria funcionar. Ele está usando a URL do fórum para o CDN do fórum, que eu não tenho certeza.
Um CDN normal é uma URL diferente da do fórum e o CDN pode contar com os dados sendo estáticos em vez de ter que adivinhar o que é dinâmico.
1 curtida
Faço o meu melhor para não espalhar minhas informações por vários fóruns, então, por favor, desculpe meu segredo sobre o assunto.
O fórum fica em “https://mmhmm.com”, que é um registro DNS do Cloudflare que é proxy (em cache). Antes de configurar o Discourse para usar o Backblaze, tudo funcionava corretamente.
“https://gtech-cdn.mmhmm.com”, como afirmado anteriormente, resolve e também responde a um ping. O destino do registro CNAME, f000.backblazeb2.com, também resolve. Essa origem de URL amigável B2 é o que o artigo instrui você a usar. Essa não é a questão, porém. A questão é que o Discourse está servindo URLs para os arquivos .js usando uma URL inválida que nunca funcionará, pois falta a parte “/file/gtech-cdn” do caminho. Se você pegar uma dessas URLs .js incompletas e adicionar manualmente as informações que faltam, ela carregará o texto do arquivo .js sem problemas.
Claro, ainda estou tentando entender como tudo isso deveria funcionar com essas duas variáveis. Sou mais um aprendiz visual e realmente poderia usar um fluxograma ou algo assim para me ajudar a entender o que deveria estar acontecendo com as interações entre Cloudflare CDN, Discourse e Backblaze B2.
Obrigado pela sua ajuda.
Ah, e tentarei abordar sua última frase sobre um CDN normal…
O artigo da Backblaze faz com que você crie duas regras de página por bucket (no meu caso, 1 bucket é usado), que, se estou entendendo corretamente, é algo como uma regra de firewall na forma como processa.
A Regra 1 diz que https://gtech-cdn.mmhmm.com/file/*/* deve usar cache padrão (que é definido em outro lugar no Cloudflare para 1 mês)
A Regra 2 redireciona qualquer coisa (302 - redirecionamento temporário) que não corresponda ao padrão da Regra 1.
Portanto, nem tudo será armazenado em cache ao acessar mmhmm.com… pelo menos é o que eu entendo.
EDITAR: Isso não funcionou.
Focando um pouco mais nisso, decidi, por razões óbvias, usar o URL do S3 como destino do CNAME em vez do URL Amigável que o artigo do Backblaze sugeriu. Agora estou apenas esperando o TTL do registro DNS expirar.
Com relação a este hook:
Não vejo nada com s3 no dump do rake --tasks. Isso ainda é relevante ou estou perdendo algum plugin?
Também estou vendo isso quando executo manualmente:
uploads:migrate_to_s3
rake aborted!
FileStore::ToS3MigrationError: Alguns uploads não puderam ser migrados para o novo esquema. Você precisa corrigir isso manualmente. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management.rb:21:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(See full trace by running task with --trace)
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse#
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse# rake uploads:migrate_to_s3
Please note that migrating to S3 is currently not reversible!
6 posts foram divididos em um novo tópico: Cloudflare R2: Navegando na Configuração e Tratando Erros de Configuração
Parece que o Cloudflare funciona agora:
Veja Cloudflare R2: Navigating Setup and Handling Configuration Errors - #13 by pfaffman
2 curtidas