No se pudo encontrar el archivo en el almacén ubicado en la url: //s3-bucket/prefix/file.jpeg

Instalación
1

Estoy actualmente en proceso de configurar la imagen oficial de Docker en AWS ECS.
Mientras se ejecuta en EC2, la imagen de Docker funciona perfectamente.

Sin embargo, después de iniciarlo en ECS con la misma configuración, termino con imágenes de avatar rotas.

Errores relacionados:

No se pudo encontrar el archivo en el almacén ubicado en la url: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

y

Error al procesar la respuesta interceptada correctamente: FinalDestination::SSRFDetector::LookupFailedError: FinalDestination: búsqueda fallida

El archivo está en el bucket y los derechos de acceso son los mismos que para la instancia EC2.

¿Alguien podría indicarme dónde puedo investigar más a fondo y encontrar la causa raíz?

Gracias

2

¿Creaste una imagen con el lanzador y la subiste a un repositorio? ¿Y la estás ejecutando con el mismo entorno que utiliza el lanzador?

3

Sí. Utilizo las variables de entorno que genera el comando run-cmd. No he podido detectar ningún error hasta ahora.
Lamentablemente, hasta ahora no he encontrado ejemplos de ECS para Discourse.

4

Vas por buen camino, pero es complicado migrar el soporte y subir los activos. No estoy seguro de cuál podría ser el problema.

5

Encontré la causa raíz. Debido a mi configuración del plugin Discourse AI, había agregado una Zona privada a la VPC para hacer que los diversos servicios estuvieran disponibles internamente en la VPC.

Cuando se ejecuta Discourse en una instancia EC2 en un contenedor Docker, el contenedor obtiene un nombre de host como 12-34-56-78-app. Sin embargo, cuando se ejecuta como una tarea ECS, no se puede establecer el nombre de host cuando está en modo awsvpc, ni se puede configurar el dominio de búsqueda DNS. Esto lleva al hecho de que la resolución DNS es diferente en ECS, en mi caso, agregando un dominio de búsqueda como xxxx.internal.

Después de investigar, descubrí usando tcpdump que Discourse intenta resolver su propio FQDN como parte de las comprobaciones SSRF. Si esto falla, la comprobación falla. Como error posterior, la llamada a S3 falla con el mensaje de error falso mencionado anteriormente.

La solución en mi caso fue agregar el registro FQDN, que es un alias a mi distribución de Cloudfront, a mi zona DNS privada.

2 Me gusta
6

¡Vaya! ¡Eso es una buena depuración! ¡Y por eso esta es una instalación no compatible! ¡No hay muchas maneras de adivinar todo eso!

1 me gusta
7

Al final es como siempre: si no funciona, siempre es DNS :joy:

8

Hola @nodomain,

Experimenté el mismo error que en tu publicación a continuación. La solicitud al avatar del usuario, por ejemplo, https://example.com/user_avatar/example.com/myself/96/215_2.png, responde con 500. En mi caso, el nombre de dominio example.com no está configurado en DNS público; en la etapa de prueba, falsifico example.com en mi archivo de host localmente. ¿No aparecerá este problema cuando el nombre de dominio example.com esté configurado en DNS público?