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.
fuente
WebJobsya que se ejecutan dentro de unIHostcontenedor. Detalles adicionales están disponibles en mi respuesta.Respuestas:
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ó.
Para más detalles, puede consultar este hilo SO .
fuente
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:
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
fuente
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ó.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
fuente