Não parece ter permissão de edição wiki, mas usei com sucesso um provedor diferente.
OVHcloud
Nome do serviço: Armazenamento de Objetos
Regiões correspondem a data centers que são identificados por um código de três letras. Se você não sabe onde criou seu bucket, verifique na aba de armazenamento de objetos no seu portal do cliente.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: [código do data center]
DISCOURSE_S3_ENDPOINT: https://s3.[código do data center].io.cloud.ovh.net/
DISCOURSE_S3_ACCESS_KEY_ID: [chave]
DISCOURSE_S3_SECRET_ACCESS_KEY: [chave]
DISCOURSE_S3_BUCKET: [nome do bucket]
DISCOURSE_S3_BACKUP_BUCKET: [nome do bucket]
DISCOURSE_BACKUP_LOCATION: s3
Inicialmente, tanto na minha versão de teste, mas fui para a produção apenas com backups, já que a máquina de produção tem muito espaço de qualquer maneira.
Ela é muito compatível com o S3, mas há algumas coisas faltando, como regras de ciclo de vida para deletar arquivos antigos ou movê-los para armazenamento frio, que estão sendo ativamente trabalhadas pela OVH. Funciona bem para servir arquivos, contudo.
Então, para backups, eu simplesmente usei a opção do Discourse de deletar backups antigos por conta própria.
Esta é uma resposta realmente decepcionante e completamente inútil. Qual exatamente é o problema? Ligar para um documento de suporte que muda significa que ninguém pode realmente dizer qual é a “terrível quebra” mencionada neste tópico aqui.
Você menciona “metadados” e que a CDN “não sabe sobre isso”. Que metadados? Seria útil saber o que não está funcionando.
Eu só queria adicionar a esta postagem minhas instruções sobre como usar o E2 do iDrive.
Parece haver algo que o iDrive ativou recentemente que faz com que as chaves de acesso atribuídas a apenas um bucket falhem, a menos que uma verificação de autenticação de bucket seja ignorada.
Você pode ignorar isso ao usar rclone com no_check_bucket = true no arquivo rclone.conf, mas não tenho certeza se existe uma configuração de ENV semelhante para a compilação do Discourse.
Como resultado, com o iDrive E2, você atualmente deve usar uma chave que tenha acesso para gravar em todos os seus buckets, em vez de apenas um.
Por que outra pessoa saberia o problema exato para um provedor que ela não usa?
De qualquer forma, parece que estamos quase lá com o Cloudflare R2. Conforme:
Quando inseri todas as informações na UI da Web, novos uploads foram para o armazenamento S3 corretamente e os backups estão indo para o S3 corretamente. Uploads atuais obviamente não se moveram.
Então, fui para o app.yml e inseri estas informações:
## Este conjunto de linhas permite que arquivos hospedados no R2 S3 sejam enviados e baixados..
DISCOURSE_CDN_URL: https://eufiles.technospider.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_ENDPOINT: https://randomnumber.r2.cloudflarestorage.com
DISCOURSE_S3_CDN_URL: https://eufiles.technospider.com
DISCOURSE_S3_BACKUP_BUCKET: exotics-unlimited-backups
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_BUCKET: exotics-unlimited
DISCOURSE_S3_REGION: auto
DISCOURSE_S3_ACCESS_KEY_ID: randomnumbers
DISCOURSE_S3_SECRET_ACCESS_KEY: randomnumbers
DISCOURSE_S3_INSTALL_CORS_RULE: false
## O contêiner Docker é sem estado; todos os dados são armazenados em /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
## Plugins vão aqui
## veja https://meta.discourse.org/t/19157 para detalhes
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
# - git clone https://github.com/discourse/discourse-subscriptions.git
- git clone https://github.com/discourse/discourse-follow.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/communiteq/discourse-private-topics.git
# - git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/tknospdr/discourse-auto-remove-group.git
- git clone https://github.com/discourse/discourse-topic-voting.git
- git clone https://github.com/discourse/discourse-livestream.git
# - git clone https://github.com/discourse/discourse-calendar.git
- git clone https://github.com/jannolii/discourse-topic-trade-buttons.git
## - git clone https://github.com/tknospdr/force-tag-group-order.git
## Hooks para S3
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
Após uma reconstrução, meu site ficou quebrado devido a vários arquivos ausentes, então tentei migrá-los para o servidor e recebi este erro para cada arquivo:
root@talk-app:/var/www/discourse# rake uploads:migrate_to_s3
Por favor, note que a migração para S3 atualmente não é reversível!
[CTRL+c] para cancelar, [ENTER] para continuar
Migrando uploads para S3 para 'default'...
Enviando arquivos para S3...
- Listando arquivos locais
. => 31 arquivos
- Listando arquivos S3
. => 4 arquivos
- Sincronizando arquivos para S3
#<Thread:0x00007ff89dcbcb20 /var/www/discourse/lib/file_store/to_s3_migration.rb:212 run> terminou com exceção (report_on_exception é true):
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call': You can only specify one non-default checksum at a time. (Aws::S3::Errors::InvalidRequest)
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/dualstack.rb:21:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/accelerate.rb:43:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/checksum_algorithm.rb:169:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:16:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/invocation_id.rb:16:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/request_callback.rb:89:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/response_target.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `block in call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/telemetry/no_op.rb:29:in `in_span'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:53:in `span_wrapper'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/request.rb:72:in `send_request'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/client.rb:17315:in `put_object'
from /var/www/discourse/lib/file_store/to_s3_migration.rb:215:in `block (2 levels) in migrate_to_s3'
Gostaria muito de algum conselho para finalizar isso de uma forma ou de outra.
Os arquivos ausentes são provavelmente ativos, então você precisa da tarefa rake que os envia para o s3 (s3:upload_assets – está perto do topo)
Mas seus erros são provavelmente devido à nova biblioteca aws s3 quebrando um monte de serviços. Então você precisará se esforçar para rebaixar o gem da aws ou usar outro serviço.
Acho que pode haver um tópico sobre como fazer isso. Eu fiz isso em um ou dois sites, mas não tenho certeza de como ou onde foi documentado.
Preciso executá-lo mesmo que isso faça parte das alterações que coloquei no arquivo app.yml? Pensei que estivesse lá para enviar os arquivos automaticamente durante uma reconstrução.
Você não deveria, mas essas são as coisas que fariam seu site ficar “quebrado” (ou “quebrado” significa “imagens faltando” para você?) O upload de imagens com migrate_to_s3 afeta apenas as imagens.
Não consigo explicar exatamente como os assets já foram todos enviados (o que estava quebrado no site? Como eles foram enviados se sua configuração S3 está quebrada?)
Atualmente não consigo fazer nada no site.
Sinta-se à vontade para dar uma olhada e ver. https://eu.technospider.com
Como tudo parece estar lá no meu bucket, provavelmente há alguma variável de ambiente que precisa ser atualizada para que tudo funcione corretamente.
Se conseguirmos resolver isso, podemos dizer que o R2 está pronto para uso.
Onde “extra-locales” deveria estar? Não vejo em ‘public’ ou ‘assets’, nem mesmo dentro do container. Onde devo procurar?
Desculpe pelas perguntas bobas, mas esta é uma empreitada totalmente nova para mim.
O que é meu CDN ou meu bucket?
Com os traços iniciais e todas as aspas simples e duplas? Eu não tenho nada disso no meu arquivo app.yml. Devo adicioná-los e reconstruir para testar?
É exatamente assim que meu arquivo se parece, com recuo de 2 espaços cada:
## Este conjunto de linhas permite que arquivos hospedados em R2 S3 sejam carregados e baixados..
DISCOURSE_CDN_URL: https://eufiles.technospider.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_ENDPOINT: https://randomnumber.r2.cloudflarestorage.com
DISCOURSE_S3_CDN_URL: https://eufiles.technospider.com
DISCOURSE_S3_BACKUP_BUCKET: exotics-unlimited-backups
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_BUCKET: exotics-unlimited
DISCOURSE_S3_REGION: auto
DISCOURSE_S3_ACCESS_KEY_ID: randomnumbers
DISCOURSE_S3_SECRET_ACCESS_KEY: randomnumbers
DISCOURSE_S3_INSTALL_CORS_RULE: false
Funcionou quando eu tinha as configurações inseridas pela interface web, depois quando coloquei tudo no arquivo app.yml, obtive o que você viu quando acessou o site.
Aqui está o que vejo quando acesso um dos seus ativos:
Este objeto não existe ou não é acessível publicamente neste URL. Verifique o URL do objeto que você está procurando ou entre em contato com o proprietário para habilitar o acesso público.
Você pode ver se https://eufiles.technospider.com/extra-locales/ca382c69f8e6b85162b2ba58f2ce100bfe741966/en/mf.js?__ws=eu.technospider.com funciona se você alterar o nome do host para o seu endpoint do Cloudflare.
Você consegue encontrar esse arquivo no seu bucket? Você consegue acessá-lo?
Não sei, mas é um URL que copiei das ferramentas do desenvolvedor no meu navegador.
Então, primeiro encontre esse arquivo no seu bucket e veja se ele está lá e, em seguida, você pode descobrir por que a CDN não consegue encontrá-lo.
Não. Eu uso uma ferramenta diferente para configuração, mas essas são as configurações de ENV que tenho certeza que funcionaram para mim em algum momento.
Este arquivo XML não parece ter nenhuma informação de estilo associada a ele. A árvore do documento é mostrada abaixo.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Um bucket é o “diretório principal” que você criou e onde todos os arquivos ficam. CDN são vários servidores ao redor do mundo e eles recebem uma cópia desse bucket. O seu é identificado usando a URL que você forneceu quando essa conexão foi criada, como, por exemplo, cdn.example.com.
Parece que com o R2 o CDN é criado automaticamente se você der um domínio personalizado ao bucket. Isso foi um pouco confuso, pois eu não precisei fazer nada com o CDN.
Este arquivo XML não parece ter nenhuma informação de estilo associada a ele. A árvore do documento é mostrada abaixo.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Me dá:
Como o erro fala sobre autorização, investiguei um pouco e encontrei esta pérola:
Observação
Por padrão, apenas certos tipos de arquivo são armazenados em cache. Para armazenar todos os arquivos em seu bucket em cache, você deve definir uma regra de página “Cache tudo”.
Para mais informações sobre o comportamento padrão de cache e como personalizá-lo, consulte Comportamento Padrão de Cache
Desta página:
Criei uma regra de “cache tudo”, mas sem alteração.
