Configure um provedor de armazenamento de objetos compatível com S3 para uploads

[Discourse]

Este tópico aborda como configurar alguns provedores comuns de Armazenamento de Objetos compatíveis com S3 (clones S3). Consulte Set up file and image uploads to S3 para mais detalhes sobre a configuração do Amazon AWS S3, que é oficialmente suportada e usada internamente pelo Discourse para nossos serviços de hospedagem.

Provedor	Nome do Serviço	Funciona com o Discourse?
Amazon AWS	S3	Sim
Digital Ocean	Spaces	Sim
Linode	Object Storage	Sim
Google Cloud	Storage	Sim
Scaleway	Object Storage	Sim
Vultr	Object Storage	Sim
BackBlaze	Cloud Storage	Sim*
Auto-hospedado	MinIO	Sim
Azure Blob Storage	Flexify.IO	Sim
Oracle Cloud	Object Storage	Não [1]
Wasabi	Object Storage	Talvez
Cloudflare	R2	Não
Contabo	Object Storage	Não

Se você conseguiu fazer outro serviço funcionar, por favor, adicione-o a esta wiki.

Configuração

Para armazenar os ativos estáticos do Discourse no seu Armazenamento de Objetos, adicione esta configuração ao seu arquivo app.yml 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

Ao usar armazenamento de objetos, você também precisará de uma CDN para servir o que é armazenado no bucket. Usei a CDN StackPath em meus testes e, além de precisar definir Dynamic Caching By Header: Accept-Encoding na configuração deles, funciona bem.

DISCOURSE_CDN_URL é uma CDN que aponta para seu hostname do Discourse e armazena em cache as solicitações. Será usada principalmente para ativos recuperáveis: CSS e outros ativos de tema.

DISCOURSE_S3_CDN_URL é uma CDN que aponta para seu bucket de armazenamento de objetos e armazena em cache as solicitações. Será usada principalmente para ativos enviáveis: JS, imagens e uploads de usuários.

Recomendamos que sejam diferentes e que os administradores configurem ambos.

Não usar uma CDN (ou inserir a URL do bucket como a URL da CDN) provavelmente causará problemas e não é suportado.

Nos exemplos a seguir, https://falcoland-files-cdn.falco.dev é uma CDN configurada para servir os arquivos sob o bucket. O nome do bucket foi definido como falcoland-files em meus exemplos.

Recomenda-se configurar essas definições em variáveis de ambiente no seu app.yml, pois é assim que a CDCK faz em sua infraestrutura, o que significa que é bem testado. Além disso, a tarefa de upload de ativos ocorre após a compilação dos ativos, o que acontece em uma reconstrução. Se você quiser iniciar um Discourse que funcione corretamente com Armazenamento de Objetos desde o início, precisa definir as variáveis de ambiente para que os ativos sejam carregados antes que o site inicie.

Escolha seu provedor na lista abaixo e adicione essas configurações à seção env do seu arquivo app.yml, ajustando os valores conforme necessário:

AWS S3

O que suportamos oficialmente e usamos internamente. Sua oferta de CDN, a Cloudfront, também funciona para servir os arquivos do bucket. Consulte Set up file and image uploads to S3 para saber como configurar as permissões corretamente.

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-west-1
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Digital Ocean Spaces

A oferta da DO é boa e funciona prontamente. É seguro ativar a Restrição de Listagem de Arquivos. O único problema é que sua oferta de CDN está terrivelmente quebrada, então você precisa usar uma CDN diferente para os arquivos. Além disso, não instale a regra CORS, pois ela é reinstalada a cada reconstrução.

Exemplo de configuração:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false 

Linode Object Storage

Um parâmetro de configuração extra, HTTP_CONTINUE_TIMEOUT, é necessário para o Linode.

Exemplo de configuração:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east-1
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://us-east-1.linodeobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Google Cloud Platform Storage

A listagem de arquivos está quebrada, então você precisa de uma variável de ambiente extra para ignorar isso para que os ativos funcionem. Também ignore o CORS e configure-o manualmente.

Como você não pode listar arquivos, não conseguirá listar backups e os backups automáticos falharão. Não recomendamos seu uso para backups. No entanto, alguns sugerem que, se você alterar a função de Storage Legacy Object Owner para Storage Legacy Bucket Owner, os backups funcionarão corretamente. Consulte este tópico para discussão específica do Google Cloud.

Existe um plugin de terceiros para melhorar a integração em Discourse GCS Helper.

Exemplo de configuração:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east1
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  FORCE_S3_UPLOADS: 1
  DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  #DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  #DISCOURSE_BACKUP_LOCATION: s3

Scaleway Object Storage

A oferta da Scaleway também é muito boa e, na maior parte, tudo funciona bem.

Os uploads multipart da Scaleway suportam apenas um máximo de 1.000 partes. Isso não corresponde ao Amazon S3, que suporta um máximo de 10.000 partes. Para instâncias maiores, isso fará com que os backups do Discourse falhem e o upload incompleto pode precisar ser excluído manualmente antes de novas tentativas. Para instâncias pequenas, isso não é um problema. A Scaleway parece bastante aberta a feedback, então, se você quiser que esse limite seja alterado, deve entrar em contato com eles.

Note que para o parâmetro DISCOURSE_S3_ENDPOINT, o Discourse usa o endpoint de toda a região: https://s3.{region}.scw.cloud. O “Bucket endpoint” encontrado no painel da Scaleway vem no formato https://{bucketName}.s3.{region}.scw.cloud. Omita o subdomínio do nome do bucket para evitar erros de conexão.

Exemplo de configuração:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: fr-par
  DISCOURSE_S3_ENDPOINT: https://s3.fr-par.scw.cloud
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Vultr Object Storage

Um parâmetro de configuração extra, HTTP_CONTINUE_TIMEOUT, é necessário para o Vultr.

Exemplo de configuração:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://ewr1.vultrobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Backblaze B2 Cloud Storage

Você precisa ignorar o CORS e configurá-lo manualmente.

Há relatos de que a limpeza de uploads órfãos (clean up orphan uploads) não funciona corretamente com o BackBlaze. Você deve alterar as regras de ciclo de vida do seu bucket para que a limpeza de órfãos funcione.

Exemplo de configuração:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: "us-west-002"
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY: false
  DISCOURSE_S3_ENDPOINT: https://s3.us-west-002.backblazeb2.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Nota: Durante a migração inicial para o B2, você pode atingir o limite diário gratuito de 2500 transações da classe C. Você precisará adicionar um método de pagamento para remover os limites.

MinIO Storage Server

Existem algumas ressalvas e requisitos que você precisa garantir antes de poder usar o servidor de armazenamento MinIO como alternativa ao S3:

1. Você tem uma instância do servidor MinIO totalmente configurada
2. Você tem o suporte a Domínio ativado na configuração do MinIO, para URLs de bucket orientados a domínio. Esta é uma configuração obrigatória para MinIO e Discourse, pois o MinIO ainda suporta os estilos de “caminho” S3 legados que não são mais suportados no Discourse.
3. Você tem a configuração de DNS configurada corretamente para o MinIO, de modo que os subdomínios dos buckets resolvam corretamente para o servidor MinIO e o servidor MinIO esteja configurado com um domínio base (neste caso, minio.example.com)
4. O bucket discourse-data existe no servidor MinIO e tem uma política “pública” definida nele
5. Sua URL de CDN S3 aponta para uma CDN configurada corretamente que aponta para o bucket e armazena em cache as solicitações, conforme mencionado anteriormente neste documento.
6. Suas CDNs estão configuradas para realmente usar um cabeçalho “Host” da URL S3 principal — por exemplo, discourse-data.minio.example.com ao buscar dados — caso contrário, pode causar problemas de CORB.

Assumindo que as ressalvas e pré-requisitos acima foram atendidos, um exemplo de configuração seria algo assim:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: anything
  DISCOURSE_S3_ENDPOINT: https://minio.example.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://discourse-data-cdn.example.com
  DISCOURSE_S3_BUCKET: discourse-data
  DISCOURSE_S3_BACKUP_BUCKET: discourse-backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false

O CORS ainda será ativado no MinIO, mesmo que a regra não seja instalada pelo reconstrutor do app — por padrão, parece, o CORS está ativado em todos os verbos HTTP no MinIO, e o MinIO não suporta BucketCORS (API S3) como resultado.

Azure Blob Storage com Flexify.IO

O Azure Blob Storage não é um serviço compatível com S3, portanto, não pode ser usado com o Discourse. Existe um plugin, mas está quebrado.

A maneira mais fácil de expor uma interface compatível com S3 para Azure Blob Storage é adicionar um servidor Flexify.IO que traduz o protocolo de armazenamento do Azure para S3.

Até o momento desta escrita, o serviço é gratuito no Azure, e você só precisa de uma tier de VM muito básica (barata) para começar a executá-lo. No entanto, requer um pouco de configuração.

1. No portal do Azure, crie um novo recurso de Flexify.IO - Amazon S3 API for Azure Blob Storage.
2. Para uso leve, a configuração mínima de VM parece funcionar bem. Você pode aceitar a maioria das configurações padrão. Lembre-se de salvar o arquivo de chave PEM ao criar a VM.
3. Navegue até o link da VM Flexify.IO e entre no sistema. Siga as instruções configurando o provedor de dados Azure Blob Storage e o endpoint S3 gerado. Certifique-se de que a configuração do endpoint Public read access to all objects in virtual buckets esteja definida como verdadeira. Copie a URL do endpoint S3 e as chaves.
4. Pressione New Virtual Bucket e crie um bucket virtual. Pode ter o mesmo nome do seu container Azure Blob Storage ou um nome diferente. Vincule qualquer container(s) para mesclar neste bucket virtual. Este bucket virtual é usado para expor um bucket publicamente legível via S3.
5. Por padrão, o Flexify.IO instala um certificado SSL autoassinado, enquanto um endpoint S3 requer HTTPS. SSH na VM usando o arquivo de chave (o nome de usuário é, por padrão, azureuser) e substitua os seguintes arquivos pelos arquivos corretos:

• /etc/flexify/ssl/cert.pem - substitua pelo arquivo de certificado (codificação PEM)

• /etc/flexify/ssl/key.pem - substitua pelo arquivo de chave privada (codificação PKCS#8 PEM, que é o que começa com BEGIN PRIVATE KEY e não BEGIN RSA PRIVATE KEY, que é PKCS#1)

  Esses arquivos são do root, então você precisará usar sudo para substituí-los. É melhor garantir que os arquivos de substituição tenham a mesma propriedade e permissões que os originais, ou seja, root:root e permissão 600.

6. Por padrão, o Flexify.IO cria um serviço S3 de nível raiz com vários buckets. O Discourse requer suporte a subdomínio para buckets. Vá para: <your Flexify.IO VM IP>/flexify-io/manage/admin/engines/configs/1, o que abrirá uma página de configuração oculta!
7. Especifique o domínio base S3 (digamos que seja s3.mydomain.com) no campo Endpoint hostname, que deve estar em branco por padrão. Pressione Save para salvar a configuração.
8. Reinicie a VM Flexify.IO no portal do Azure.
9. No seu DNS, mapeie s3.mydomain.com e *.s3.mydomain.com para o IP da VM Flexify.IO.
10. No Discourse, defina o seguinte na página de administração (sim, não há necessidade de as configurações estarem no app.yml):

use s3: true
s3 region: anything
s3 endpoint: https://s3.mydomain.com
s3 access key: myaccesskey
s3 secret assess key: mysecret key
s3 cdn url: https://<azure-blob-account>.blob.core.windows.net/<container>
s3 bucket: <virtual bucket>
s3 backup bucket: <backup bucket>  (qualquer container serve, pois não requer leitura pública e o Flexify.IO os exporá automaticamente)
backup location: s3

Não é recomendado usar o mesmo bucket para produção e staging. Se você fizer isso mesmo assim, tome medidas para garantir que seu site de staging não exclua seus ativos de produção (defina s3 disable cleanup como mínimo e fique atento à exclusão de backups de produção).

Wasabi

@pfaffman tentou usar o Wasabi para backups, mas parecia falhar intermitentemente e silenciosamente, deixando backups no disco rígido e eventualmente preenchendo o disco. Nem o Wasabi nem o meta tinham pistas, então não recomendo, embora seus resultados possam variar. @pfaffman agora tem certeza de que esse problema foi devido a backups e reinicializações automáticas sendo agendados de alguma forma ao mesmo tempo; era usado apenas para backups, mas parecia funcionar bem. Se alguém quiser tentar e relatar aqui, deve funcionar, pelo menos para backups.

Oracle Cloud

O Oracle Cloud não oferece suporte ao acesso de estilo de host virtual para buckets e não funcionará

Cloudflare

A oferta da Cloudflare é incompatível. Nos testes, @fearlessfrog abriu um ticket com a Cloudflare e, em dezembro de 2022, eles disseram:

Arquivos que você compacta com gzip não são atualmente tratados corretamente pelo R2. Você precisa fazer upload de arquivos não compactados. A Cloudflare tem compressão transparente; ela escolhe identity, gzip ou Brotli com base no que o cliente consegue lidar. Isso é uma diferença em relação ao S3.

Contabo

@tuxed tentou fazer o Contabo Object Storage funcionar para uploads compatíveis com S3. Parece que, ao fazer o upload, ele adiciona um prefixo ao nome do repositório na URL e ele não conseguiu fazê-lo funcionar.

Uploads Seguros

Uploads seguros são suportados apenas para AWS S3. Se o seu rake uploads:migrate_to_s3 falhar, você deve inserir esses comandos para primeiro contar e depois marcar como não seguros aqueles uploads, dado que você sabe que eles não precisam ser seguros, caso em que você precisará usar AWS S3.

./launcher enter app
rails c
Upload.where(secure: true).count
Upload.where(secure: true).update_all(secure:false)

---

1. O Oracle Cloud não oferece suporte ao acesso de estilo de host virtual para buckets e não funcionará ↩︎