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

**URL:** https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916
**Category:** Self-Hosting
**Tags:** cdn, configuring, how-to, reference
**Created:** [Abril 22, 2020, 10:37pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916 "2020-04-22T22:37:37Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![Discourse](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/discourse/32/148734_2.png) [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [Abril 22, 2020, 10:37pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/1 "2020-04-22T22:37:38Z")

</div>

> :information_source: Este tópico aborda como configurar alguns provedores comuns de armazenamento de objetos compatíveis com S3 (clones do S3). Consulte [Set up file and image uploads to S3](https://meta.discourse.org/t/setting-up-file-and-image-uploads-to-s3/7229) para mais detalhes sobre a configuração do Amazon AWS S3, que é oficialmente suportado e usado internamente pelo Discourse para nossos serviços de hospedagem.

| Provedor | Nome do Serviço | Funciona com o Discourse? |
| --- | --- | --- |
| [Amazon AWS](https://meta.discourse.org/t/-/148916#p-738234-aws-s3-2) | S3 | Sim |
| [Digital Ocean](https://meta.discourse.org/t/-/148916#p-738234-digital-ocean-spaces-3) | Spaces | Sim |
| [Linode](https://meta.discourse.org/t/-/148916#p-738234-linode-object-storage-4) | Object Storage | Sim |
| [Google Cloud](https://meta.discourse.org/t/-/148916#p-738234-google-cloud-platform-storage-5) | Storage | Sim |
| [Scaleway](https://meta.discourse.org/t/-/148916#p-738234-scaleway-object-storage-6) | Object Storage | Sim |
| [Vultr](https://meta.discourse.org/t/-/148916#p-738234-vultr-object-storage-7) | Object Storage | Sim |
| [BackBlaze](https://meta.discourse.org/t/-/148916#p-738234-backblaze-b2-cloud-storage-8) | Cloud Storage | Sim\* |
| Auto-hospedado | [MinIO](https://meta.discourse.org/t/-/148916#p-738234-minio-storage-server-9) | Sim |
| [Azure Blob Storage](https://meta.discourse.org/t/-/148916#p-738234-azure-blob-storage-with-flexifyio-10) | [Flexify.IO](https://flexify.io/) | Sim |
| [Oracle Cloud](https://meta.discourse.org/t/-/148916#oracle-cloud-12) | Object Storage | Não [[1]](#fn1) |
| [Wasabi](https://meta.discourse.org/t/-/148916#p-738234-wasabi-11) | Object Storage | Talvez |
| [Cloudflare](https://meta.discourse.org/t/-/148916#p-738234-cloudflare-r2-13) | R2 | Sim |
| [Contabo](https://meta.discourse.org/t/-/148916#p-738234-contabo-15) | Object Storage | Não |

Se você conseguiu fazer um serviço diferente funcionar, adicione-o a esta wiki.

## Configuração

Para armazenar ativos estáticos do Discourse em seu armazenamento de objetos, adicione esta configuração em seu `app.yml` na seção `hooks`:

```yml
  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 precisa de uma CDN para servir o que é armazenado no bucket. Eu usei a CDN da StackPath em meus testes e, além de precisar definir `Dynamic Caching By Header: Accept-Encoding` em sua configuração, funciona bem.

> DISCOURSE\_CDN\_URL é uma CDN que aponta para o nome do host do seu Discourse e faz cache das solicitações. Será usada principalmente para ativos puxáveis: CSS e outros ativos de temas.
> 
> DISCOURSE\_S3\_CDN\_URL é uma CDN que aponta para o bucket do seu armazenamento de objetos e faz cache das solicitações. Será usada principalmente para ativos empurráveis: JS, imagens e uploads de usuários.
> 
> Recomendamos que sejam diferentes e que os administradores configurem ambas.

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 dentro do bucket. O nome do bucket foi definido como `falcoland-files` em meus exemplos.

Configurar essas variáveis de ambiente no seu `app.yml` é recomendado, pois é assim que a CDCK faz em sua infraestrutura, portanto, é 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ê deseja iniciar um Discourse que funcione corretamente com armazenamento de objetos desde o início, você precisa definir as variáveis de ambiente para que os ativos sejam enviados antes que o site seja iniciado.

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 oficialmente suportamos e usamos internamente. Sua oferta de CDN, Cloudfront, também funciona para servir os arquivos do bucket. Consulte [Set up file and image uploads to S3](https://meta.discourse.org/t/setting-up-file-and-image-uploads-to-s3/7229) para saber como configurar as permissões corretamente.

```yaml
  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 imediatamente. É seguro ativar a opção “Restrict File Listing” (Restringir listagem de arquivos). O único problema é que sua oferta de CDN está [terivelmente quebrada](https://docs.digitalocean.com/products/spaces/how-to/set-file-metadata/), então você precisa usar uma CDN diferente para os arquivos. Além disso, você não deve instalar a regra CORS, pois ela a reinstala a cada reconstrução.

Exemplo de configuração:

```yaml
  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:

```yaml
  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 ignorá-la para que os ativos funcionem. Além disso, ignore o CORS e configure-o manualmente.

:warning: Como você não pode listar arquivos, não poderá listar backups e os backups automáticos falharão, portanto, não recomendamos o 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 funcionam corretamente. Consulte [este tópico](https://meta.discourse.org/t/tips-on-google-cloud-s3/247555) para discussões específicas do Google Cloud.

Existe um plugin de terceiros para melhorar a integração em [Discourse GCS Helper](https://meta.discourse.org/t/discourse-gcs-helper/247705).

Exemplo de configuração:

```yaml
  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 tudo funciona bem na maioria das vezes.

:warning: Os uploads multipart da Scaleway suportam apenas um [máximo de 1.000 partes](https://www.scaleway.com/en/docs/storage/object/api-cli/multipart-uploads/). Isso não corresponde ao Amazon S3, que suporta um máximo de 10.000 partes. Para instâncias maiores, isso fará com que o Discourse [falhe nos backups](https://meta.discourse.org/t/backup-upload-to-s3-fails-on-scaleway-multipart-upload/177764) e o upload incompleto pode precisar ser [excluído manualmente](https://meta.discourse.org/t/add-s3-bucket-policy-automatically-delete-incomplete-multipart-upload-parts/188232) 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, entre em contato com eles.

Observe 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 seu 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:

```yaml
  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:

```yaml
  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](https://meta.discourse.org/t/backblaze-s3-issue-duplicated-uploads-after-delete/183313?u=falco) de que a função “limpar uploads órfãos” não funciona corretamente com a BackBlaze. Você deve [alterar as regras de ciclo de vida](https://meta.discourse.org/t/backblaze-s3-issue-duplicated-uploads-after-delete/183313/13?u=v1ktor) do seu bucket para que a limpeza de órfãos funcione.

Exemplo de configuração:

```yaml
  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 de 2.500 transações gratuitas diárias da classe C](https://meta.discourse.org/t/high-usage-of-s3-head-bucket-requests-during-initial-migration/268447). Você precisará adicionar um método de pagamento para remover os limites._

### MinIO Storage Server

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

1. Você tem uma instância de servidor [MinIO](https://min.io/) totalmente configurada
2. Você tem o suporte a domínio ativado na configuração do MinIO, para URLs de buckets baseados em domínio. **Esta é uma configuração obrigatória para MinIO e Discourse, pois o MinIO ainda suporta os estilos “path” legados do S3, que não são mais suportados no Discourse.**
3. Você tem a configuração de DNS corretamente definida para o MinIO, para que os subdomínios do bucket 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

* * *

1. Oracle Cloud [não oferece suporte a acesso ao estilo virtual-host para buckets](https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm) e [não funcionará](https://meta.discourse.org/t/ssl-connect-returned-1-errno-0-peeraddr-162-243-189-2-443-state-error-certificate-verify-failed-hostname-mismatch/269824/17) [↩︎](#fnref1)

---

<div class="post-metadata">

### Author: ![Richie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/richie/32/115110_2.png) [@Richie](https://meta.discourse.org/u/Richie)
#### Post date: [Fevereiro 14, 2021, 9:02pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/201 "2021-02-14T21:02:52Z")

</div>

Olá a todos,

Tenho usado o armazenamento S3 há vários anos _sem_ uma CDN.

Seguindo o conselho dado a mim em [outro tópico](https://meta.discourse.org/t/what-should-i-enter-in-the-s3-cdn-settings-if-i-dont-have-a-cdn/174610), configurei hoje a CDN CloudFront.

Antes de adicionar a URL da CDN ao meu painel de controle e reprocessar mais de 230.000 posts apenas para descobrir que cometi um erro na configuração da CloudFront e quebrar tudo, alguém pode confirmar se esse é o comportamento esperado para mim, por favor? :bowing_man:t2:

Atualmente, esta é uma URL de exemplo para uma imagem enviada por um usuário:

`https://greyarrows.s3.dualstack.eu-west-2.amazonaws.com/original/3X/8/3/8335cab232f512f4a979c7f0c8562e149c01b212.png`

Que exibe:

 ![](https://global.discourse-cdn.com/meta/original/3X/1/f/1fa000ef6169842ab15613437b3de9ad3a3648fd.png)

Meu “Nome de Domínio” da CloudFront é: `d1q8cepst0v8xp.cloudfront.net`

Se eu editar manualmente a URL de exemplo acima e substituir a parte atual do domínio `S3` pelo nome de domínio da minha CloudFront, obtenho:

`https://d1q8cepst0v8xp.cloudfront.net/original/3X/8/3/8335cab232f512f4a979c7f0c8562e149c01b212.png`

E, de fato, a imagem continua carregando corretamente:

 ![](https://global.discourse-cdn.com/meta/original/3X/1/f/1fa000ef6169842ab15613437b3de9ad3a3648fd.png)

Portanto, estou correto ao pensar que preciso apenas adicionar uma URL de CDN S3 de `d1q8cepst0v8xp.cloudfront.net` ao meu painel de controle do Discourse, reprocessar todos os posts e apenas relaxar e esperar que a mágica aconteça?

Obrigado antecipadamente, CDN é tudo novo para mim e não tenho um ambiente de desenvolvimento no qual possa testar isso com segurança :grimacing:

---

<div class="post-metadata">

### Author: ![Richie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/richie/32/115110_2.png) [@Richie](https://meta.discourse.org/u/Richie)
#### Post date: [Fevereiro 14, 2021, 9:10pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/202 "2021-02-14T21:10:14Z")

</div>

Eu também tenho a configuração `s3 configure tombstone policy` ativada:

![Screen Shot 2021-02-14 at 21.08.39](https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/meta/original/3X/6/7/676325f6b81d070a758aa6af2705cce4c3969a0a.png)

Isso será um problema? Já que agora estou usando uma CDN? Ou as verificações em segundo plano ainda estão acessando o bucket S3 original, em vez de uma URL da CDN?

Naturalmente, estou pensando na segunda opção, mas, novamente, não posso me dar ao luxo de prejudicar as uploads de fotos de centenas de milhares dos meus usuários :scream:

:blush:

---

<div class="post-metadata">

### Author: ![Richie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/richie/32/115110_2.png) [@Richie](https://meta.discourse.org/u/Richie)
#### Post date: [Fevereiro 15, 2021, 12:05pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/203 "2021-02-15T12:05:37Z")

</div>

> [@Richie](#):
>
> Portanto, estou correto em pensar que simplesmente preciso adicionar a URL do CDN S3 d1q8cepst0v8xp.cloudfront.net` ao meu painel de controle do Discourse, refazer todos os posts e apenas relaxar e esperar que a mágica aconteça?

A resposta é sim.

Para testar essa teoria, antes de refazer centenas de milhares de posts, fiz as seguintes verificações de sanidade:

- Fazer upload de uma imagem
- Alterar a configuração da URL do CDN S3
- Reconstruir o HTML do meu post de teste (via a interface)
- Atualizar a página no navegador
- Verificar a aba Rede do console do navegador para confirmar que a imagem estava sendo carregada via CloudFront
- Fazer upload de uma nova imagem de teste em um novo post
- Verificar a aba Rede do console do navegador para confirmar que a imagem estava sendo carregada via CloudFront

Agora estou refazendo _todos_ os posts neste momento :+1:t2:

---

<div class="post-metadata">

### Author: ![scottfsmith](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/scottfsmith/32/50976_2.png) [@scottfsmith](https://meta.discourse.org/u/scottfsmith)
#### Post date: [Fevereiro 23, 2021, 2:28pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/210 "2021-02-23T14:28:20Z")

</div>

Obrigado pelo relatório, Richie. Eu também tenho o armazenamento de imagens do AWS S3 em execução há vários anos e cheguei a esta postagem por meio da mensagem no console. Mas a descrição no topo não menciona nada sobre o caso em que você já tinha o S3 e só precisava de um CDN.

Para constar, aqui está o que fiz:

1. Acessei o console da AWS, em Rede e Entrega de Conteúdo, e selecionei o Cloudfront.
2. Cliquei no botão Criar distribuição.
3. Preenchi o formulário bastante óbvio; a única coisa que realmente precisava fazer era escolher seu bucket do AWS S3 onde estão as imagens no menu suspenso.
4. Esperei um pouco até que a configuração do Cloudfront terminasse.
5. Um domínio `<gibberish>.cloudfront.net` apareceu na coluna “Nome de Domínio” da lista de Distribuições do Cloudfront.
6. Copiei e colei esse domínio no campo `s3 cdn url` nas configurações de Arquivos do painel administrativo do meu site.
7. Fiz alguns testes:  
a. Criei uma nova postagem com um upload de imagem e, de fato, ela estava no Cloudfront.  
b. Cliquei em Reconstruir HTML em algumas postagens de imagens existentes aleatórias e vi que elas também foram reconstruídas com imagens do `cloudfront.net`.
8. Como tudo parecia estar correto, entrei e executei um rebake, o que levou várias horas, pois tenho cerca de meio milhão de postagens agora:

```plaintext
./launcher enter app
# rake posts:rebake

```

1. Tudo parece estar funcionando bem. Foram adicionadas muitas tarefas à fila do Sidekiq, uma por postagem, ao que parece, e elas levarão alguns dias para ser processadas, mas já estão sendo processadas em lotes.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Março 18, 2021, 1:55pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/212 "2021-03-18T13:55:38Z")

</div>

Tem certeza de que é esse o caso? Este site aqui usa assets de um CDN e não precisávamos limpar o cache. Além disso, é uma alteração do EmberCli que não deveria afetar a produção :thinking:

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Março 31, 2021, 4:07pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/224 "2021-03-31T16:07:28Z")

</div>

Ah, esses malditos otimizadores. Eu diria para desativá-los, se possível, pois o Discourse já vem com configurações otimizadas para cada ativo. Esses otimizadores são ótimos quando você está hospedando um software web de caixa preta dos anos 2000, mas falham miseravelmente em coisas modernas. Além disso, até mesmo o famoso otimizador da Cloudflare frequentemente quebra o Discourse, então não tenho esperanças para os outros. Eles podem funcionar um dia e quebrar no seguinte, deixando todos os seus visitantes com uma página em branco. Tudo isso sem nenhum benefício.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Maio 19, 2021, 8:12pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/232 "2021-05-19T20:12:01Z")

</div>

Há alguma chance de você ter ativado o `secure_uploads` nas configurações do site?

Também parece que isso foi relatado e corrigido hoje devido à compatibilidade com o Discourse:

> <https://github.com/minio/minio/issues/12320>
>
> \## Expected Behavior
> 
> In previous releases of Minio (prior to March 2021) a \`P…UT\` request to for example \`/path/to/some/file?acl\` with the header \`X-Amz-Acl: private\` would appear to succeed to a client. Minio is faking the success, which is fine. The behaviour is intended to make Minio compatible with applications that attempt to set an ACL. At least it's usable, with say, Discourse when secure media uploads are enabled.
> 
> \## Current Behavior
> 
> Commit 3ddd8b04d170a7d3cdf98694648a99f8802b5678 seems to have broken the dummy PutObjectACL route. All of the controller code is still there in acl-handlers.go - it's just never called. Instead, the request that previously worked (in a dummy way) not hits the \`notImplementedHandler\` in api-router.go. This results in the client receiving a \`501 Not Implemented\` response. Discourse is crippled, because new posts with attachments cannot be created.
> 
> \## Possible Solution
> 
> Restore the functionality prior to the mentioned commit.
> 
> \## Regression
> 
> Yes, this is a regression originating in 3ddd8b04d170a7d3cdf98694648a99f8802b5678 from PR #11674.
> 
> \## Your Environment
> 
> Minio 2018-05-18

> <https://github.com/minio/minio/pull/12321>
>
> \## Description
> fix: muxing order for rejected APIs
> 
> \## Motivation and Context…
> Order of registration matters in muxer,
> rejected APIs should be registered at 
> appropriate locations based on their routes.
> 
> This PR fixes #12320 
> 
> \## How to test this PR?
> As per #12320 using \`aws s3api put-object-acl\`
> 
> \## Types of changes
> \- \[x\] Bug fix (non-breaking change which fixes an issue)
> \- \[\] New feature (non-breaking change which adds functionality)
> \- \[\] Optimization (provides speedup with no functional changes)
> \- \[\] Breaking change (fix or feature that would cause existing functionality to change)
> 
> \## Checklist:
> \- \[\] Fixes a regression (If yes, please add \`commit-id\` or \`PR #\` here)
> \- \[\] Documentation updated
> \- \[\] Unit tests added/updated

---

<div class="post-metadata">

### Author: ![smlbiobot](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/smlbiobot/32/168715_2.png) [@smlbiobot](https://meta.discourse.org/u/smlbiobot)
#### Post date: [Junho 28, 2021, 7:05pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/234 "2021-06-28T19:05:35Z")

</div>

Existe alguma maneira de desativar esse aviso que aparece no meu painel de administração?

`O servidor está configurado para fazer upload de arquivos para o S3, mas não há um CDN S3 configurado.`

Tive problemas para configurar um CDN S3, mas como não custa uma fortuna, estou bem em usar o S3 diretamente. No entanto, o que eu adoraria ver é que essa notificação desaparecesse, pois estou plenamente ciente das consequências.

---

<div class="post-metadata">

### Author: ![tuanpembual](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tuanpembual/32/223553_2.png) [@tuanpembual](https://meta.discourse.org/u/tuanpembual)
#### Post date: [Agosto 11, 2021, 12:22pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/235 "2021-08-11T12:22:42Z")

</div>

Olá.

Quero apenas dar um atualização. Agora será possível configurar backups usando o GCS. Também postei [em outro tópico](https://meta.discourse.org/t/use-google-cloud-storage-instead-of-s3/40046/4). Espero que isso ajude outras pessoas que estão procurando essa solução com dificuldade.

Como fazer isso?  
Ative a configuração padrão para backups (ou você pode configurar pelo painel de administração).

```plaintext
DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
DISCOURSE_BACKUP_LOCATION: s3

```

Em seguida, defina as permissões do bucket como `Storage Legacy Object Owner`:

1. Acesse seu projeto no Google Cloud Console
2. Selecione Storage
3. Selecione seu bucket
4. Vá para a aba de permissões
5. Adicione uma nova permissão, preencha com o e-mail da sua conta de serviço. Para as funções, selecione `Storage Legacy Object Owner`
6. Salve e pronto.

Desculpe pela postagem duplicada, apenas queria compartilhar essa boa atualização.  
Obrigado

---

<div class="post-metadata">

### Author: ![tenzan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tenzan/32/42979_2.png) [@tenzan](https://meta.discourse.org/u/tenzan)
#### Post date: [Setembro 13, 2021, 9:29am UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/238 "2021-09-13T09:29:58Z")

</div>

Seria ótimo se você pudesse adicionar o [Wasabi](https://wasabi.com/) também…

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Setembro 13, 2021, 2:54pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/239 "2021-09-13T14:54:05Z")

</div>

Usei o Wasabi para backups por um tempo. No que diz respeito à configuração, ele “simplesmente funcionou”, então você pode tentar se quiser.

Mas, com certa frequência, os backups falhavam silenciosamente e ficavam armazenados na máquina local, ocupando espaço no disco. Analisei os erros do Wasabi e do Discourse, mas nunca encontrei uma explicação que permitisse que qualquer uma das partes “corrigisse” algo.

Não recomendo, pois não tenho certeza de que seja “excelente”.

---

<div class="post-metadata">

### Author: ![tenzan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tenzan/32/42979_2.png) [@tenzan](https://meta.discourse.org/u/tenzan)
#### Post date: [Setembro 13, 2021, 2:58pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/240 "2021-09-13T14:58:30Z")

</div>

Obrigado!  
Vou verificar como funciona desta vez.  
A frequência de backup padrão é de 7 dias entre os backups e até 5 backups.  
Vou compartilhar como fica.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Setembro 13, 2021, 2:59pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/241 "2021-09-13T14:59:25Z")

</div>

Eu fazia backups diários; não me lembro quantos eu tentava manter, mas o disco rígido local tinha espaço apenas para alguns poucos.

---

<div class="post-metadata">

### Author: ![tenzan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tenzan/32/42979_2.png) [@tenzan](https://meta.discourse.org/u/tenzan)
#### Post date: [Setembro 13, 2021, 3:12pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/242 "2021-09-13T15:12:07Z")

</div>

Qual armazenamento você recomendaria pessoalmente?  
Acho que AWS e Azure não são acessíveis para projetos pessoais.  
Não tenho certeza sobre o Azure, mas a AWS parece confusa e imprevisível…

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Setembro 13, 2021, 3:15pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/243 "2021-09-13T15:15:08Z")

</div>

Espero que o Wasabi seja bom para backups, pelo menos. O Backblaze S3 é acessível. Não acho que o tenha usado para uploads, mas funciona para backups (acho). Acredito que o único problema com o Backblaze é que (na última vez que testei) era necessário usar uma chave global (então não podia usá-la para clientes que pudessem ver a chave). Acredito que alguém postou recentemente uma correção para isso (algo sobre “legado”, em algum lugar). Para um projeto pessoal, é isso que eu tentaria em seguida, acho. (E se você estiver na Digital Ocean, o Spaces é bom, acho.)

---

<div class="post-metadata">

### Author: ![tenzan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tenzan/32/42979_2.png) [@tenzan](https://meta.discourse.org/u/tenzan)
#### Post date: [Setembro 14, 2021, 10:31am UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/244 "2021-09-14T10:31:24Z")

</div>

Estou no DO, mas em termos de custo, o Blackblaze/Wasabi é mais barato.  
O que você usou para os uploads?

---

<div class="post-metadata">

### Author: ![tenzan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tenzan/32/42979_2.png) [@tenzan](https://meta.discourse.org/u/tenzan)
#### Post date: [Setembro 18, 2021, 2:15pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/245 "2021-09-18T14:15:36Z")

</div>

Desculpe, não consegui entender.  
Por que precisamos especificar as configurações no `app.yml`, se podemos inserir essas informações diretamente em Discourse \> Configurações?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Setembro 19, 2021, 10:38am UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/246 "2021-09-19T10:38:38Z")

</div>

Por causa da forma como ele lida com a construção de assets quando o container é criado, eu acho. É bastante confuso que o comportamento seja diferente quando as configurações estão nas variáveis de ambiente e no banco de dados, mas é assim que funciona. Também é uma maneira melhor de gerenciá-las, pois significa que você pode construir e restaurar um novo site a partir da linha de comando.

---

<div class="post-metadata">

### Author: ![Zup](https://avatars.discourse-cdn.com/v4/letter/z/c37758/32.png) [@Zup](https://meta.discourse.org/u/Zup)
#### Post date: [Outubro 11, 2021, 9:25pm UTC](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916/247 "2021-10-11T21:25:09Z")

</div>

> [@Falco](#):
>
> É necessário um parâmetro de configuração extra, HTTP\_CONTINUE\_TIMEOUT, para o Vultr.

Onde devo definir isso? Não estou encontrando nas configurações de administração do Discourse?

[Next page](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916.md?page=2)
