Realizar solicitudes a localhost dentro de la aplicación Azure App Services


8

Tengo un trabajo web continuo que escucha las solicitudes que contienen información de diagnóstico.

Para probar la conectividad, intento realizar una comprobación de estado en mi trabajo web, pero no puedo hacer solicitudes a localhost según la documentación de los servicios de aplicaciones azules.

El siguiente código es lo que uso para verificar que puedo conectarme desde la aplicación que implemento:

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

Me sale esta excepción:

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

El trabajo web se instala a través de un script de instalación de extensión de sitio a través de Kudu (SCM), lo que significa que el trabajo web es en última instancia un proceso secundario de Kudu (SCM). La aplicación de trabajo web en el inicio se vincula al puerto 8989. Al iniciar la aplicación localmente en Windows, puedo acceder a mi comprobación de salud sin problemas.

La documentación de los servicios de aplicaciones azules dice que las solicitudes a localhost fallarán a menos que una aplicación dentro del mismo entorno limitado se una al puerto ( https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#local-address- solicitudes ).

La documentación de los servicios de aplicaciones azules indica que Kudu se ejecuta en el mismo entorno limitado que la aplicación principal ( https://github.com/projectkudu/kudu/wiki/Kudu-architecture#security-model ).

¿Cómo habilito la comunicación con mi trabajo web a través de http?

Preferiblemente sería algo que podría hacer desde un proceso de instalación de extensión de sitio, pero cualquier opción es buena.

Actualización 26-12-2019:

He intentado forzar a SCM y a la aplicación principal a ejecutarse en el mismo entorno limitado con WEBSITE_DISABLE_SCM_SEPARATION=true( https://github.com/projectkudu/kudu/wiki/Configurable-settings#use-the-same-process-for-the-user- sitio-y-el-sitio-scm ).

La documentación indica que ya se ejecutan en el mismo entorno limitado y que si un proceso escucha en un puerto en el mismo entorno limitado, esas solicitudes deberían funcionar. Es de destacar que el proceso SCM w3wp.exe real ha podido golpear localhost con http para mi trabajo web. Sin embargo, esta configuración no pareció mejorar la situación.

Actualización 04-02-2020:

Abandoné oficialmente la idea de usar un trabajo web y ahora comienzo el proceso como hijo de la instancia principal de la aplicación. Esto me permite comunicarme localhost:8989sin problemas.

Aunque ahora necesito administrar mi propia lógica de mantener vivo.

Todavía me encantaría saber si hay una manera de comunicarse a través de TCP con un trabajo web si eso es posible.


Esta es la pregunta más similar que he encontrado: stackoverflow.com/questions/56572039/…
colin-higgins

El problema de acceso podría deberse a la autenticación / autorización a Kudu. Amablemente, comparta detalles de la creación de la instancia del cliente.
Igwe Kalu

Esto es antes de que la solicitud incluso abandone el contexto de la aplicación
colin-higgins

1
Como sugerí en mi respuesta, las conexiones de socket no están habilitadas WebJobsya que se ejecutan dentro de un IHostcontenedor. Detalles adicionales están disponibles en mi respuesta.
Igwe Kalu

1
La documentación de Wiki en GitHub no siempre está actualizada. Tampoco la documentación oficial. Me pregunto si se supone que esto funcione ...
Sean Feldman

Respuestas:


0

¿Cómo habilito la comunicación con mi trabajo web a través de http?

No. No es posible que WebJob envíe solicitudes directamente al sitio a través de localhost . Esta limitación está documentada en la página sandbox como la que proporcionó.

Los intentos de conexión a direcciones locales (por ejemplo, localhost, 127.0.0.1) y la propia IP de la máquina fallarán, excepto si otro proceso en el mismo entorno limitado ha creado un socket de escucha en el puerto de destino.

Los intentos de conexión rechazados, como el siguiente ejemplo que intenta conectarse a 127.0.0.1:80, desde .NET generarán la excepción anterior.

Para más detalles, puede consultar este hilo SO .


Dices que el trabajo web no puede enviar solicitudes al sitio, pero quiero la dirección opuesta. Además, "excepto si otro proceso en el mismo entorno limitado ha creado un socket de escucha en el puerto de destino" me lleva a creer que ES posible.
colin-higgins

0

Creo que el problema está relacionado con el puerto asignado a su aplicación (8989). Deberá usar otro servicio (servicios en la nube antiguos), máquina virtual o Service Fabric para abrir y recibir solicitudes en el puerto 8989.

Más información al respecto:

Escucha de punto final de red La única forma de acceder a una aplicación

a través de Internet es a través de los puertos TCP (80) y HTTPS (443) TCP ya expuestos; Es posible que las aplicaciones no escuchen en otros puertos los paquetes que llegan de Internet. Sin embargo, las aplicaciones pueden crear un socket que puede escuchar las conexiones desde el sandbox. Por ejemplo, dos procesos dentro de la misma aplicación pueden comunicarse entre sí a través de sockets TCP; los intentos de conexión entrantes desde fuera del sandbox, aunque estén en la misma máquina, fallarán. Consulte el siguiente tema para obtener detalles adicionales.

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


Tampoco funcionó si elegí dinámicamente un puerto libre.
colin-higgins

0

No debe implementar un servidor HTTP en su WebJob, ya que no es así como deben ejecutarse.

Un WebJob se ejecuta básicamente dentro de un contenedor IHost diseñado para servicios sin cabeza que puede facilitar las tareas de procesamiento en segundo plano. A diferencia de un IWebHost , un IHost no es adecuado para alojamiento web.

En consecuencia, el WebJob en su creado puede no haberse vinculado efectivamente al puerto que mencionó. Si lo hiciera, lo más probable es que la política de seguridad del entorno limitado restringiría el acceso a sockets arbitrarios creados por un usuario que no sean los expuestos para acceder a su sitio y al servicio de kudu. Esto se indicó exactamente con " 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" en el fragmento de seguimiento de la pila de errores que compartió.

¿Cómo habilito la comunicación con mi trabajo web a través de http? - La comunicación con un WebJob se puede establecer a través de la API de WebJobs .

Es posible que tenga que crear varios WebJobs para cumplir con las diversas funcionalidades previstas por su intento de implementación del servidor HTTP.

Referencias

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.