Je suis en train de configurer l’image Docker officielle sur AWS ECS.
Alors qu’elle fonctionne parfaitement sur EC2, l’image Docker fonctionne parfaitement.
Cependant, après l’avoir lancée sur ECS avec la même configuration, je me retrouve avec des images d’avatar corrompues.
Erreurs associées :
Impossible de trouver le fichier dans le magasin situé à l'URL : //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg
et
Échec du traitement correct de la réponse détournée : FinalDestination::SSRFDetector::LookupFailedError : FinalDestination : échec de la recherche
Le fichier est dans le bucket et les droits d’accès sont les mêmes que pour l’instance EC2.
Quelqu’un pourrait-il m’indiquer où je peux creuser davantage pour trouver la cause première ?
Avez-vous créé une image avec le lanceur et poussé l’image vers un dépôt ? Et vous la lancez avec le même environnement que celui utilisé par le lanceur ?
Oui. J’utilise les variables d’environnement que la commande run-cmd génère. Je n’ai pas pu repérer d’erreur jusqu’à présent.
Malheureusement, je n’ai pas trouvé d’exemples ECS pour Discourse jusqu’à présent.
Vous êtes sur la bonne voie, mais la migration du standee et le téléchargement des ressources sont délicats. Je ne suis pas sûr de ce qui pourrait poser problème.
J’ai trouvé la cause première. En raison de ma configuration du plugin Discourse AI, j’avais ajouté une zone privée au VPC pour rendre les divers services disponibles en interne dans le VPC.
Lorsque Discourse s’exécute sur une instance EC2 dans un conteneur Docker, le conteneur obtient un nom d’hôte tel que 12-34-56-78-app. Cependant, lorsqu’il s’exécute en tant que tâche ECS, vous ne pouvez pas définir le nom d’hôte en mode awsvpc, ni configurer le domaine de recherche DNS. Cela conduit au fait que la résolution DNS est différente sur ECS, dans mon cas, en ajoutant un domaine de recherche tel que xxxx.internal.
Après avoir fouillé, j’ai découvert en utilisant tcpdump que Discourse essaie de résoudre son propre FQDN dans le cadre des vérifications SSRF. Si cela échoue, la vérification échoue. En tant qu’erreur subséquente, l’appel à S3 échoue avec le message d’erreur erroné ci-dessus.
La solution dans mon cas a été d’ajouter l’enregistrement FQDN, qui est un alias de ma distribution Cloudfront, à ma zone DNS privée.
Wow. C’est du bon débogage ! Et c’est pourquoi il s’agit d’une installation non prise en charge ! Il n’y avait pas beaucoup de moyens de deviner tout ça !
Salut @nodomain,
J’ai rencontré exactement la même erreur que dans votre publication ci-dessous. La requête pour l’avatar utilisateur, par exemple https://example.com/user_avatar/example.com/myself/96/215_2.png, répond avec un 500. Dans mon cas, le nom de domaine example.com n’est pas configuré dans le DNS public. En phase de test, j’usurpe example.com dans mon fichier hôte localement. Ce problème n’apparaîtra-t-il pas lorsque le nom de domaine example.com sera configuré dans le DNS public ?
