Anforderungen an localhost in der Azure App Services-Anwendung stellen

Ich habe einen fortlaufenden Webjob, der auf Anfragen mit Diagnoseinformationen wartet.

Um die Konnektivität zu testen, versuche ich, in meinem Webjob eine Integritätsprüfung durchzuführen, kann jedoch keine Anforderungen an localhost gemäß der Dokumentation der Azure App Services stellen.

Mit dem folgenden Code überprüfe ich, ob ich über die von mir bereitgestellte Anwendung eine Verbindung herstellen kann:

    var uri = new Uri("http://localhost:8989/ping");
    var response = await client.GetAsync(uri);

Ich bekomme diese Ausnahme:

System.Net.Http.HttpRequestException: An error occurred while sending the request. 
---> System.Net.WebException: Unable to connect to the remote server 
---> System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:8989

Der Webjob wird über ein Installationsskript für Site-Erweiterungen über Kudu (SCM) installiert. Dies bedeutet, dass der Webjob letztendlich ein untergeordneter Prozess von Kudu (SCM) ist. Die Webjob-Anwendung bindet sich beim Start an Port 8989. Wenn ich die Anwendung lokal unter Windows starte, kann ich meine Integritätsprüfung problemlos durchführen.

In der Dokumentation zu den Azure App Services heißt es, dass Anforderungen an localhost fehlschlagen, es sei denn, eine Anwendung in derselben Sandbox wird an den Port gebunden ( https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#local-address- Anfragen ).

In der Dokumentation zu den Azure App Services wird angegeben, dass Kudu in derselben Sandbox wie die Hauptanwendung ausgeführt wird ( https://github.com/projectkudu/kudu/wiki/Kudu-architecture#security-model ).

Wie aktiviere ich die Kommunikation mit meinem Webjob über http?

Am besten wäre es etwas, was ich mit einem Installationsprozess für Site-Erweiterungen tun könnte, aber alle Optionen sind gut.

Update 26.12.2019:

Ich habe versucht, SCM und die Hauptanwendung zu zwingen, in derselben Sandbox mit WEBSITE_DISABLE_SCM_SEPARATION=true( https://github.com/projectkudu/kudu/wiki/Configurable-settings#use-the-same-process-for-the-user-) ausgeführt zu werden. site-and-the-scm-site ).

In der Dokumentation wird angegeben, dass sie bereits in derselben Sandbox ausgeführt werden und dass diese Anforderungen funktionieren sollten, wenn ein Prozess einen Port in derselben Sandbox überwacht. Bemerkenswert ist, dass der eigentliche SCM-Prozess w3wp.exe in der Lage war, localhost mit http für meinen Webjob zu treffen. Diese Einstellung schien die Situation jedoch nicht zu verbessern.

Update 04-02-2020:

Ich habe die Idee, einen Webjob zu verwenden, offiziell aufgegeben und beginne den Prozess jetzt als untergeordnetes Element der Hauptanwendungsinstanz. Dadurch kann ich problemlos kommunizieren localhost:8989.

Obwohl ich jetzt meine eigene Keep-Alive-Logik verwalten muss.

Ich würde immer noch gerne wissen, ob es eine Möglichkeit gibt, über TCP mit einem Webjob zu kommunizieren, falls dies jemals möglich ist.

— Colin-Higgins
quelle

Dies ist die ähnlichste Frage, die ich gefunden habe: stackoverflow.com/questions/56572039/…

— colin-higgins

Das Zugriffsproblem kann sich aus der Authentifizierung / Autorisierung bei Kudu ergeben. Bitte teilen Sie Details der Clientinstanzerstellung mit.

— Igwe Kalu

Dies ist, bevor die Anfrage überhaupt den Kontext der Anwendung verlässt

— Colin-Higgins

Wie ich in meiner Antwort vorgeschlagen habe, sind die Socket-Verbindungen nicht aktiviert, WebJobsda sie in einem IHostContainer ausgeführt werden. Weitere Details finden Sie in meiner Antwort.

— Igwe Kalu

Die Wiki-Dokumentation auf GitHub ist nicht immer aktuell. Auch keine offizielle Dokumentation. Ich

— Sean Feldman

Antworten:

Wie aktiviere ich die Kommunikation mit meinem Webjob über http?

Nein. Es ist dem WebJob nicht möglich, Anforderungen direkt über localhost an die Site zu senden . Diese Einschränkung wird auf der von Ihnen angegebenen Sandbox- Seite dokumentiert .

Verbindungsversuche zu lokalen Adressen (z. B. localhost, 127.0.0.1) und der eigenen IP des Computers schlagen fehl, es sei denn, ein anderer Prozess in derselben Sandbox hat einen Überwachungssocket am Zielport erstellt.

Abgelehnte Verbindungsversuche wie das folgende Beispiel, in dem versucht wird, eine Verbindung zu 127.0.0.1:80 über .NET herzustellen, führen zu der obigen Ausnahme.

Weitere Informationen finden Sie in diesem SO-Thread .

— Joey Cai
quelle

Sie sagen, der Webjob kann keine Anfragen an die Site senden, aber ich möchte die entgegengesetzte Richtung. Auch "außer wenn ein anderer Prozess in derselben Sandbox einen Listening-Socket am Zielport erstellt hat" lässt mich glauben, dass dies möglich ist.

— Colin-Higgins

Ich glaube, das Problem hängt mit dem Port zusammen, der Ihrer App zugewiesen ist (8989). Sie müssen einen anderen Dienst (alte Cloud-Dienste), eine virtuelle Maschine oder Service Fabric verwenden, um Anforderungen an Port 8989 zu öffnen und zu empfangen.

Weitere Infos dazu:

Abhören des Netzwerkendpunkts Nur so kann auf eine Anwendung zugegriffen werden

über das Internet erfolgt über die bereits exponierten HTTP (80) - und HTTPS (443) -TCP-Ports; Anwendungen warten möglicherweise nicht an anderen Ports auf Pakete, die aus dem Internet ankommen. Anwendungen können jedoch einen Socket erstellen, der Verbindungen innerhalb der Sandbox abhören kann. Beispielsweise können zwei Prozesse innerhalb derselben App über TCP-Sockets miteinander kommunizieren. Verbindungsversuche, die von außerhalb der Sandbox eingehen, schlagen fehl, obwohl sie sich auf demselben Computer befinden. Weitere Informationen finden Sie im nächsten Thema.

https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox

— Thiago Custodio
quelle

Es hat auch nicht funktioniert, wenn ich dynamisch einen freien Port ausgewählt habe.

— Colin-Higgins

Sie sollten keinen HTTP-Server in Ihrem WebJob implementieren, da diese nicht so ausgeführt werden sollen.

Ein WebJob wird grundsätzlich in einem IHost- Container ausgeführt, der für kopflose Dienste ausgelegt ist und Hintergrundverarbeitungsaufgaben erleichtern kann. Im Gegensatz zu einem IWebHost , einem IHost nicht für das Webhosting geeignet.

Infolgedessen hat sich der von Ihnen erstellte WebJob möglicherweise nicht effektiv an den von Ihnen genannten Port gebunden. In diesem Fall würde die Sicherheitsrichtlinie der Sandbox höchstwahrscheinlich den Zugriff auf beliebige Sockets einschränken, die von einem anderen Benutzer als den für den Zugriff auf Ihre Site und Ihren Kudu-Dienst bereitgestellten erstellt wurden. Dies wurde genau durch " " angezeigtSystem.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:8989 in dem von Ihnen freigegebenen Fehlerstapel-Trace-Snippet .

Wie aktiviere ich die Kommunikation mit meinem Webjob über http? - Die Kommunikation mit einem WebJob kann über die WebJobs-API hergestellt werden .

Möglicherweise müssen Sie mehrere erstellen WebJobs , um die verschiedenen Funktionen zu erfüllen, die von Ihrer versuchten HTTP-Server-Implementierung beabsichtigt sind.

Verweise

— Igwe Kalu
quelle