Tenho um trabalho contínuo na Web que escuta solicitações que contêm informações de diagnóstico.
Para testar a conectividade, tento fazer uma verificação de integridade no meu trabalho na Web, mas não consigo fazer solicitações ao host local por documentação dos serviços de aplicativos do azure.
O código abaixo é o que eu uso para verificar se consigo me conectar a partir do aplicativo que implanto:
var uri = new Uri("http://localhost:8989/ping");
var response = await client.GetAsync(uri);
Eu recebo esta exceção:
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
O trabalho da Web é instalado por meio de um script de instalação de extensão de site por meio do Kudu (SCM), o que significa que o trabalho da Web é basicamente um processo filho do Kudu (SCM). O aplicativo de trabalho da Web na inicialização se vincula à porta 8989. Iniciando o aplicativo localmente no Windows, posso executar minha verificação de saúde sem problemas.
A documentação do azure app services diz que as solicitações ao host local falharão, a menos que um aplicativo dentro da mesma sandbox seja vinculado à porta ( https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#local-address- pedidos ).
A documentação dos serviços de aplicativos do azure afirma que o Kudu é executado na mesma caixa de proteção do aplicativo principal ( https://github.com/projectkudu/kudu/wiki/Kudu-architecture#security-model ).
Como habilito a comunicação com meu trabalho na Web via http?
De preferência, seria algo que eu poderia fazer a partir de um processo de instalação de extensão de site, mas todas as opções são boas.
Atualização 12-26-2019:
Tentei forçar o SCM e o aplicativo principal a serem executados na mesma sandbox com WEBSITE_DISABLE_SCM_SEPARATION=true
( https://github.com/projectkudu/kudu/wiki/Configurable-settings#use-the-same-process-for-the-user- site-e-o-scm-site ).
A documentação afirma que eles já são executados na mesma caixa de proteção e que, se um processo escutar em uma porta na mesma caixa de proteção, essas solicitações deverão funcionar. Observe que o processo real do SCM w3wp.exe conseguiu acessar o host local com http para o meu trabalho na web. Essa configuração não parece melhorar a situação.
Atualização 04-02-2020:
Abandonei oficialmente a idéia de usar um trabalho na Web e agora inicio o processo como um filho da instância principal do aplicativo. Isso me permite comunicar localhost:8989
sem problemas.
Embora agora eu precise gerenciar minha própria lógica de manter viva.
Eu ainda adoraria saber se existe uma maneira de se comunicar via TCP com um trabalho na Web, se isso for possível.
WebJobs
pois são executadas dentro de um IHost
contêiner. Detalhes adicionais estão disponíveis na minha resposta.