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.
WebJobsya que se ejecutan dentro de un IHostcontenedor. Detalles adicionales están disponibles en mi respuesta.