Reconstruir exibição ao usar minio como armazenamento de objetos
I, [2022-09-01T00:37:48.192311 #1] INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::BadRequest: Ocorreu um erro ao analisar a solicitação HTTP PUT em '/'
Todos os domínios são devidamente credenciados e a tentativa de conectar à conta usando Cyberduck usando s3.example.com ou bucket.s3.example.com está disponível para upload e download de arquivos.
Pesquisei problemas relacionados e não os resolvi, funciona bem se usar o armazenamento de objetos vultr. Então, é que minio e discourse não funcionam bem juntos, mas já vi pessoas usando minio com sucesso. Pergunto a todos, acredito que este problema será resolvido em breve.
O problema não foi resolvido, o que me incomoda é que a conexão com a conta minio usando o protocolo de transporte amazon s3 do Cyberduck está disponível e acho que minhas configurações do minio parecem estar funcionando bem.
Você confirmou que sua configuração do MinIO funciona em geral com outros mecanismos, como o cliente MinIO ou o ? E que você está usando os URLs e a configuração corretos contra o MinIO?
Minha sugestão é garantir que tudo esteja em conformidade com os clientes de linha de comando MinIO e s3cmd primeiro - eu nunca ouvi falar desse cliente “Cyberduck” (por um bom motivo: é Windows e Mac, eu sou um cara do Linux), e não posso confirmar que ele está em conformidade com o MinIO e outras coisas, pois diz “AWS S3” em seu item e provavelmente foi projetado para a API S3 completa da Amazon, não para itens compatíveis/conformes com S3. Configure o cliente minio (mcli) na linha de comando na caixa onde você está tentando trabalhar ou perto dela e, em seguida, tente enviar um arquivo manualmente para seus buckets.
Além disso, lembre-se de que DISCOURSE_S3_BACKUP_BUCKET com MinIO é projetado para ser seu próprio bucket, não um subcaminho dentro de um bucket existente (pelo que sei). É possível que isso também quebre coisas na configuração atual, é por isso que o exemplo que escrevi e o link para o meu “Como fazer” que você forneceu o têm como um bucket separado.
O que não tenho aqui são informações sobre a solicitação específica que foi feita - o caminho do URL, etc. que foi usado pelo sistema quando ele fez essa consulta com o BadRequest. Parece que é porque é apenas um log de nível INFO. Não há como obter um nível de depuração de log durante o processo rake, certo @pfaffman (ou outros que são mais familiarizados com o lado do Discourse)?
ALÉM DISSO, certifique-se de também passar DISCOURSE_S3_INSTALL_CORS_RULE: false para sua configuração do Discourse - se o reconstrutor/padeiro do aplicativo tentar enviar regras CORS, isso resultará em uma mensagem de erro.
Vejo o arquivo enviado no bucket, isso significa que instalei o minio com os passos corretos? Instalei o minio usando docker compose e meu arquivo docker-compose.yml
DISCOURSE_S3_BACKUP_BUCKET: Tentei usar um bucket separado e configurei o encaminhamento de nome de domínio para a porta 9000 para o bucket, mas não funciona
Encaminhar quais portas? 80/443 para que http/https funcionem? Isso é tudo que precisa, você NUNCA deve configurar a porta 9000 em uma porta separada. O bucket separado terá o mesmo endpoint que s3.example.com - não é algo separado, então você está configurando ISSO errado. Não se esqueça também que, no jargão do MinIO, se você estiver usando autenticação de caminho, você acabará com s3.example.com/NOME_DO_BUCKET ou com autenticação DNS como você deveria usar BUCKET.s3.example.com para os endpoints de URL que você precisa aceitar no lado do nginx e encaminhar para a porta interna 9000. Você não precisa configurar isso do seu lado, isso precisa ser configurado do lado do MinIO.
O cliente MinIO suporta configuração no estilo path e dns. Pelo que sei, o Discourse usa um mecanismo baseado em URL para identificação de bucket, não configurações de estilo de caminho (sinta-se à vontade para me corrigir, desenvolvedores do Discourse). Portanto, o comportamento ‘padrão’ que você está configurando está incorreto.
Agora, meu MinIO não está em docker, mas para estar em conformidade aqui com o Discourse, você precisa usar o roteamento no estilo DNS, ou seja, você precisa adicionar na variável de ambiente MINIO_DOMAIN=BASEDOMAINHERE para que o roteamento no estilo DNS que o Discourse quer usar funcione. No seu exemplo seria MINIO_DOMAIN=s3.example.com e então seu NGINX precisaria ser configurado para passar o cabeçalho Host para o backend na porta 9000 ou onde quer que os componentes base do servidor não-console sejam executados. Você então precisa garantir que o NGINX aceite para *.s3.example.com e o encaminhe corretamente para o contêiner MinIO. Isso faz parte da configuração de Federação do MinIO, mas para instâncias de nó único com vários nomes de bucket em uma URL base, você precisa garantir que esteja configurado corretamente de qualquer maneira se quiser que funcione com o Discourse.
Infelizmente, porém, é aqui que você tem que começar a se aprofundar nas configurações do MinIO. E um dos pré-requisitos que especifico no documento é que você tenha uma instância MinIO totalmente funcional e configurada corretamente, o que está além do escopo do site do Discourse. Acredito que seu MinIO não está configurado corretamente para resolução de bucket no estilo DNS como a AWS S3 faz (bucket.s3.example.com, por exemplo) e, como tal, não funciona.
Note que eu executo a instância do Discourse para o Lubuntu Project (lubuntu.me) (uma variante do Ubuntu que usa LXQt) usando um MinIO com resolução de URL de bucket no estilo DNS para que funcione corretamente com o Discourse, caso contrário, uma solicitação para BUCKET.basedomain.example.com falharia.
Curiosidade, eu até afirmo que você precisa que seu MinIO esteja configurado corretamente para caminhos no estilo DNS, se você não incluiu o MINIO_DOMAIN durante a configuração do MinIO, ele não fará caminhos no estilo DNS. O que ele precisa aqui para o Discourse, de acordo com o item 3 na seção de ressalvas que escrevi:
Oi mano, configurar o MINIO_DOMAIN faz os erros acima desaparecerem, mas novos aparecem
Aws::S3::Errors::MalformedXML: O XML que você forneceu não estava bem formado ou não validou contra nosso esquema publicado.
Sinto que estou prestes a ter sucesso, porque o discourse pode acessar meu minio corretamente, tento excluir todos os buckets do minio, reconstruo o discourse, ele solicitará que o bucket especificado não existe
O problema é resolvido não adicionando variáveis de armazenamento de objetos via app.yml. Caso contrário, ocorrerá um erro MalformedXML, basta adicionar o parâmetro s3 às configurações. A variável MINIO_DOMAIN precisa ser adicionada ao instalar o minio (estou usando implantação de nó único).
MINIO_DOMAIN precisa ser adicionado para que buckets no estilo DNS ocorram, e é por isso que o PUT inválido acontece. Assim que avançarmos, veremos as falhas no XML em relação ao que é permitido nos esquemas. Certifique-se de NUNCA colocar qualquer política que tenha variáveis não suportadas no conjunto suportado que o MinIO realmente suporta.
Lembre-se: compatível com S3 NÃO significa que seja uma correspondência de 100% para todas as variáveis/endpoints/valores da API AWS S3 suportados.
