Service Fabric Reverse Proxy

Question

Je suis confronté à des problèmes d'obtention de proxy inverse droit. Je continue à obtenir "504 Getaway Timeout" lorsque j'utilise le proxy inverse. J'ai suivi un microsoft's example pour configurer le cluster. À mon humble avis, je pense que la configuration du cluster est correcte, la seule différence est que j'ai spécifié le port 80 pour le proxy et je n'ai pas utilisé le protocole SSL pour le test env. Je l'essaie sur l'environnement de test pour l'instant, mais l'environnement de production exécute les mêmes services, sans proxy inverse et c'est très bien. En outre, j'ai exposé un point de terminaison pour l'un des services sur test env, j'ai essayé de l'appeler sans proxy inverse et cela a fonctionné.

J'ai lu que c'était could be caused by the containers, mais j'utilise Windows 2012 RC2 DataCenter. Pour autant que je sache, il n'utilise pas de conteneurs Windows nat. En outre, j'ai lu qu'il pourrait être provoqué par l'erreur 404 (#case 2 dans l'exemple doc) où il essaye de le recharger et expire simplement en essayant.

Voici quelques-unes des résumés des détails qui pourraient être importants pour savoir

• service Version Tissu: 5.5.219.0
• OS: Windows
• SKU: 2012 R2 Datacenter
• Les services utilisent WebListener
• Tous les ports sont autorisés
• 1 NodeType (stateless)
• services créés avec ASP.NET base modèle API Web
• VS 2015 Enterprise

points de terminaison de service sont configurés comme suit: Protocole Endpoint = "http" Name = "ServiceEndpoint" type = "Entrée"

Tous les services et la grappe sont en bonne santé.

Toute aide serait appréciée!

Answer 1

J'ai trouvé une cause à ce délai. C'était juste moi qui n'obtenait pas le changement requis dans l'url de la demande.

Tous mes services contiennent des contrôleurs MVC nommés d'après le nom du service. Donc, chaque fois que je les appelais sans proxy inverse mon url demande serait quelque chose comme http://mycluster.westeurope.cloudapp.azure.com:8280/Notifications/TestMethod

et ce serait suffisant car il pourrait trouver Controller par port unique. La façon dont je l'ai essayé de l'appeler avec proxy inverse était http://mycluster.westeurope.cloudapp.azure.com/SomeName.API.Services/Notifications/TestMethod

Cela ne suffit pas que « notifications » est analysé comme un nom du service de et non le contrôleur. Donc, j'appelais le service et une action sans spécifier de contrôleur. La manière correcte de l'appeler est d'inclure le nom de service deux fois, puisque j'ai appelé mes contrôleurs comme le service (je pourrais changer cela). Voici une URL correcte, je dois utiliser http://mycluster.westeurope.cloudapp.azure.com/SomeName.API.Services/Notifications/Notifications/TestMethod

Je l'ai pensé à elle en regardant l'exemple de code reverse proxy.