Je couronne une image de Rabbitmq Docker (Rabbitmq: 3-Gestion) dans AWS ECS. Ça marche bien sans problème.
Puis j'ai ajouté un peu plus de complexité et j'ai créé un service avec le même rabbbitmq mais maintenant connecté à l'équilibreur de chargement de réseau AWS (mon objectif ultime est de créer un cluster de rabbbitmq, donc j'ai besoin de quelques instances. derrière l'équilibreur de charge). Le groupe cible est configuré avec le port 5672 et utilise le même port pour les contrôles de santé. Intervalle entre les contrôles de santé est de 30 secondes (c'est maximum disponible). Seuil est 5.
Dans la configuration du service dans ECS Période de grâce de la vérification de la santé est de 120 secondes. Devrait être suffisant pour commencer le service.
Ce qui se passe, c'est que lorsque je gère le service après quelques minutes, il est tué et redémarré: 'Quelques minutes' signifie 2 ou 5 ou 9 ... il varie. Cela n'arrive pas à commencer mais après un moment.
De plus, je vois que la rabbbitmq fonctionne bien (dans les journaux et dans le panneau de gestion). C'est donc exactement elb qui provoque son redémarrage. Non que le premier rabbbitmq est mort et puis elb le redémara, non. Donc, ma question est de savoir ce que je fais mal et que je peux atteindre un travail stable de rabbbitmq dans la CES en paire? L'idée d'utiliser le port 5672 pour Helth Vérifie-t-elle mal? Mais quel port alors à utiliser? 15672? Désolé si je n'ai pas fourni suffisamment de détails. J'ai désrogué ceux qui me semblaient pertinents. Si vous avez besoin de quelque chose de plus, je serai heureux d'élaborer. Merci!
3 Réponses :
Votre URL HealthCheck fonctionne-t-elle? Cela m'est arrivé avec alb. Mon cas était
/ API / Profils => Conteneur: 4000, mais
Mon conteneur n'a pas eu de route pour serveur API / Profils . Parce que
Alb n'a pas réécris le chemin comme pour ex nginx. Il cherchait la
API / Profils Route dans le conteneur et mon itinéraire était juste
/ profils . J'ai donc changé le chemin dans le Nginx, puis cela a fonctionné.
Comment diagnostiquer
- Activez les journaux CloudWatch, puis vous verrez le problème réel, espérons-le.
- Si ce n'est pas passer par la liste entière ici ici HTTPS : //docs.aws.amazon.com/elasticchartBalancement/Latest/Network/load -Balancer-TroubleShooTing.html
Merci pour vos commentaires. Mais j'utilise l'équilibreur de chargement réseau, pas alb. Et NLB fonctionne avec TCP, pas http. Donc, il pings a donné le port pour la vérification de la santé. Il est tout simplement impossible de spécifier une URL là-bas.
Ceci est très important pour spécifier le chemin de contrôle de santé ou le port lors de la connexion de votre service avec ALB.
alb ne vérifie pas le corps de réponse, mais il vérifie le code d'état, donc le seul appel qui vous retournera tandis que 15672 reviendra 200. aussi , Vérifiez la vérification de la santé du groupe cible souhaitée de la tâche ECS, indique-t-il le port correct de l'instance.
Dans ce cas, votre santé sera ci-dessous est le code que nous utilisons pour une telle tâche ECS où nous avons besoin Pour vérifier plusieurs port. pour la surveillance de lapin, vous pouvez explorer Surveillance de la RabbitMQ. 200 Code d'état est Curl -i http://127.0.0.1:15672 Le repos nécessitera une authentification ou 404 ou 403 quelle marque LB cible malsaine. 
/ ping et le port sera 3007
J'utilise un équilibreur de charge réseau qui fonctionne avec TCP, pas HTTP. Par conséquent, vous n'avez pas à (et ne pouvez pas) fournir une URL pour la vérification de la santé. Par défaut, il pings a donné le port. Oui, je peux ajouter plus sophistiqué HealthCheck pour conteneur. En fait, j'en ai même eu un au début de mes explorations. Il était basé sur des outils de diagnostic intégrés à rabbbitmq. Mais ensuite, j'ai fini avec le port par défaut Ping depuis lors, lors de la création de Cluster Rabbitmq doit être arrêté à certains moments. Un tel chèque de santé échouera donc à ce moment-là, ce qui n'est pas le comportement souhaité.
Vous pouvez donc configurer un port de vérification de la santé 15672, accédez à votre groupe cible et remplacez votre port de vérification de la santé, car ce port répondra avec 200 code d'état.
Le problème était dans des groupes de sécurité. C'était un peu pas évident avec NLB mais toujours. Le plient voir ma propre réponse à la question de la question. :-)
Je l'ai eu, NLB n'a pas de groupe de sécurité son groupe de sécurité d'utilisation de l'instance
Apparemment, le problème était avec la configuration du groupe de sécurité de service rabbbitmq avec IP de NLB. Cette idée n'est pas venue à moi immédiatement parce que
Plus de détails sont ici:
https://forums.aws.amazon.com/thread.jspa ? Threadid = 263245
et ici: