Não foi possível encontrar o arquivo na loja localizada no URL: //s3-bucket/prefix/file.jpeg

Instalação
1

Estou atualmente configurando a imagem oficial do Docker no AWS ECS.
Ao rodar no EC2, a imagem do docker funciona perfeitamente.

No entanto, após iniciá-la no ECS com a mesma configuração, acabo com imagens de avatar quebradas.

Erros relacionados:

Could not find file in the store located at url: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

e

Failed to process hijacked response correctly : FinalDestination::SSRFDetector::LookupFailedError : FinalDestination: lookup failed

O arquivo está no bucket e os direitos de acesso são os mesmos da instância EC2.

Alguém pode me indicar onde posso investigar mais a fundo e encontrar a causa raiz?

Obrigado.

2

Você criou uma imagem com o launcher e enviou a imagem para um repositório? E você a está iniciando com o mesmo ambiente que o launcher usa?

3

Sim. Eu uso as variáveis de ambiente que o comando run-cmd gera. Não consegui identificar nenhum erro até agora.
Infelizmente, não consegui encontrar exemplos de ECS para Discourse até agora.

4

Você está no caminho certo, mas é complicado migrar o expositor e fazer o upload dos ativos. Não tenho certeza qual pode ser o problema.

5

Encontrei a causa raiz. Devido à minha configuração do plugin Discourse AI, adicionei uma Zona privada à VPC para disponibilizar os diversos serviços internamente na VPC.

Ao executar o Discourse em uma instância EC2 em um contêiner Docker, o contêiner recebe um nome de host como 12-34-56-78-app. Ao executar como uma tarefa ECS, no entanto, você não pode definir o nome do host quando está no modo awsvpc, nem pode configurar o domínio de pesquisa DNS. Isso leva ao fato de que a resolução DNS é diferente no ECS, no meu caso, adicionando um domínio de pesquisa como xxxx.internal.

Após investigar, descobri usando tcpdump que o Discourse tenta resolver seu próprio FQDN como parte das verificações SSRF. Se isso falhar, a verificação falha. Como um erro subsequente, a chamada para S3 falha com a mensagem de erro inválida acima.

A correção no meu caso foi adicionar o registro FQDN, que é um alias para minha distribuição Cloudfront, à minha zona DNS privada.

2 curtidas
6

Uau. Isso é uma boa depuração! E é por isso que esta é uma instalação não suportada! Não havia muita maneira de adivinhar tudo isso!

1 curtida
7

No final, é como sempre: se não funciona, a culpa é sempre do DNS :joy:

8

Olá @nodomain,
Experimentei exatamente o mesmo erro que no seu post abaixo. A solicitação para o avatar do usuário, por exemplo, https://example.com/user_avatar/example.com/myself/96/215_2.png responde com 500. No meu caso, o nome de domínio example.com não está configurado no DNS público; na fase de testes, eu falsifico o example.com no meu arquivo host localmente. Este problema não aparecerá quando o nome de domínio example.com for configurado no DNS público?