Aspnetcore: Hospedar o serviço grpc no iis ou como um serviço de aplicativo?

Criado em 3 abr. 2019  ·  153Comentários  ·  Fonte: dotnet/aspnetcore

É possível fazer isso? Se sim como?


Atualização de 28/10/2020 - @JamesNK

Problema de voz do usuário

Há um problema de voz do usuário do Microsoft Azure para adicionar suporte gRPC ao Serviço de Aplicativo . Considere votar se este for um recurso importante para você.

gRPC-Web

gRPC-Web com .NET já está disponível. O gRPC-Web é compatível com o IIS e o Serviço de Aplicativo do Azure. Link para a postagem do blog com mais informações: https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-available/

IIS

O IIS é compatível com o .NET 5 e uma versão interna do Windows. Mais informações: https://github.com/dotnet/aspnetcore/issues/9020#issuecomment -713738181

area-grpc

Comentários muito úteis

@shirhatti Dado que o gRPC parece ser um recurso importante do .NET Core 3 (https://github.com/grpc/grpc-dotnet), seria uma pena se não fosse hospedável no IIS/App Service devido a tantos . NET são hospedados neles. Espero que a disponibilidade desse recurso no .NET Core ajude a direcionar seu roteiro.

Todos 153 comentários

Oi @moodya , você verificou os documentos em https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio ?

Se você estiver enfrentando um problema, informe-nos para que possamos investigar.

Sim, eu já construí um serviço que está sendo executado como um serviço hospedado genérico. Eu o portei para o novo modelo asp net core 3 e o fiz funcionar em kestrel auto-hospedado, mas atualmente olhando para hospedá-lo atrás do iis e, esperançosamente, implantá-lo como um serviço de aplicativo no Azure. Não consigo fazer o primeiro (iis) funcionar.

Obtenha o Outlook para Android https://aka.ms/ghi36


De: Eilon Lipton [email protected]
Enviado: quarta-feira, 3 de abril de 2019 18:06:17
Para: aspnet/AspNetCore
Cc: moodya; Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

Oi @moodya https://github.com/moodya , você verificou os documentos em https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=visual-studio ?

Se você estiver enfrentando um problema, informe-nos para que possamos investigar.


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

Não consigo encontrar nenhum exemplo de como fazer isso, então talvez ainda não seja suportado

Obtenha o Outlook para Android https://aka.ms/ghi36


De: Alain Moody [email protected]
Enviado: quarta-feira, 3 de abril de 2019 18:11:06
Para: aspnet/AspNetCore; aspnet/AspNetCore
CC: Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

Sim, eu já construí um serviço que está sendo executado como um serviço hospedado genérico. Eu o portei para o novo modelo asp net core 3 e o fiz funcionar em kestrel auto-hospedado, mas atualmente olhando para hospedá-lo atrás do iis e, esperançosamente, implantá-lo como um serviço de aplicativo no Azure. Não consigo fazer o primeiro (iis) funcionar.

Obtenha o Outlook para Android https://aka.ms/ghi36


De: Eilon Lipton [email protected]
Enviado: quarta-feira, 3 de abril de 2019 18:06:17
Para: aspnet/AspNetCore
Cc: moodya; Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

Oi @moodya https://github.com/moodya , você verificou os documentos em https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=visual-studio ?

Se você estiver enfrentando um problema, informe-nos para que possamos investigar.


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

@shirhatti - alguma ideia sobre isso?

Não é possível hospedar gRPC no IIS/Azure App Service.
A implementação HTTP/2 de Http.Sys não oferece suporte a cabeçalhos finais de resposta HTTP dos quais o gRPC depende.

Obrigado pela resposta rápida. Como você recomendaria hospedar um serviço grpc em um cenário de produção no momento? Além disso, você está ciente de quaisquer escalas de tempo em que um serviço grpc será capaz de hospedar no serviço iis/app?

Obtenha o Outlook para Android https://aka.ms/ghi36


De: Sourabh Shirhatti [email protected]
Enviado: quarta-feira, 3 de abril de 2019 19:13:23
Para: aspnet/AspNetCore
Cc: moodya; Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

Não é possível hospedar gRPC no IIS/Azure App Service.
A implementação HTTP/2 de Http.Sys não oferece suporte a cabeçalhos finais de resposta HTTP dos quais o gRPC depende.


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479600486 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AlUvPNHH4- HhNsSAtugTw0MzzNco6c76ks5vdO9DgaJpZM4cZ2SG .

A abordagem recomendada é hospedar seu serviço gRPC no AKS.

No que diz respeito aos cronogramas do Serviço de Aplicativo, eu adiaria para @stefsch

Obrigado por voltar para mim. Em termos de malha de serviço aks vs em termos de hospedagem do serviço grpc, é a melhor escolha? Se sim, por quê?

Obtenha o Outlook para Android https://aka.ms/ghi36


De: Sourabh Shirhatti [email protected]
Enviado: segunda-feira, 8 de abril de 2019 07:31:45
Para: aspnet/AspNetCore
Cc: moodya; Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

A abordagem recomendada é hospedar seu serviço gRPC no AKS.

No que diz respeito aos cronogramas do Serviço de Aplicativo, eu adiaria para @stefsch https://github.com/stefsch


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-480701227 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AlUvPLwQW8HCp- YXsz6yNaK_RH7jbZzWks5veuJRgaJpZM4cZ2SG .

No momento, estou esperando problemas para fazer isso. Eu tenho um serviço gRPC funcionando bem usando aspnetcore 3 preview 3 e Kestrel. Mas, um erro sobre trailers aparece usando o IIS quando o serviço envia a resposta (a solicitação é bem recebida):
Erro gPRC => 2 DESCONHECIDO: Nenhum status recebido)
Erro dotnet => "Trailers não são suportados para esta resposta" em Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(resposta HttpResponse, String trailerName, StringValues ​​trailerValues) em Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

De acordo com as mensagens acima, não pense que o iis suporta hospedar um serviço grpc

Obtenha o Outlook para Android https://aka.ms/ghi36


De: alustrement [email protected]
Enviado: quinta-feira, 25 de abril de 2019 10:57:42
Para: aspnet/AspNetCore
Cc: moodya; Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

No momento, estou esperando problemas para fazer isso. Eu tenho um serviço gRPC funcionando bem usando aspnetcore 3 preview 3 e Kestrel. Mas, um erro sobre trailers aparece usando o IIS quando o serviço envia a resposta (a solicitação é bem recebida):
Erro gPRC => 2 DESCONHECIDO: Nenhum status recebido)
Erro dotnet => "Trailers não são suportados para esta resposta" em Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(resposta HttpResponse, String trailerName, StringValues ​​trailerValues) em Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486607635 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AJKS6PEAJ2UKKH2QIKNTCZDPSF6BNANCNFSM4HDHMSDA .

Após esta troca https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , parece que não é responsabilidade do servidor web lidar com gRPC. gPRC usa HTTP/2, o IIS suporta HTTP/2, então deve funcionar. Se não for, é um bug do IIS ou, mais possível, do dotnetcore.

De acordo com o pessoal da Microsoft nas mensagens acima, o iis não suporta os cabeçalhos à direita necessários para hospedar um serviço grpc. Isso significa que você não pode hospedar um no iis ou como um serviço de aplicativo no momento.

Obtenha o Outlook para Android https://aka.ms/ghi36


De: alustrement [email protected]
Enviado: quinta-feira, 25 de abril de 2019 11:39:08
Para: aspnet/AspNetCore
Cc: moodya; Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

Após esta troca https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , parece que não é responsabilidade do servidor web lidar com gRPC. gPRC usa HTTP/2, o IIS suporta HTTP/2, então deve funcionar. Se não for, é um bug do IIS ou, mais possível, do dotnetcore.


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486620151 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AJKS6PBQO4427EYN67SI7A3PSGC4ZANCNFSM4HDHMSDA .

Obrigado, eu perdi e faz sentido com o meu problema.
@shirhatti o suporte está planejado no roteiro?

Nós (IIS) estamos avaliando atualmente se devemos oferecer suporte a trailers de resposta HTTP. Não há roteiros/compromissos com os quais eu possa falar ainda.

@shirhatti Dado que o gRPC parece ser um recurso importante do .NET Core 3 (https://github.com/grpc/grpc-dotnet), seria uma pena se não fosse hospedável no IIS/App Service devido a tantos . NET são hospedados neles. Espero que a disponibilidade desse recurso no .NET Core ajude a direcionar seu roteiro.

Concordo plenamente com @jbrantly. O gRPC é anunciado como um dos principais recursos do .NET Core 3.
Deve ser hospedável no IIS/Azure App Services.
@shirhatti , considere adicionar isso ao roteiro

Eu também concordo.

Obtenha o Outlook para Android https://aka.ms/ghi36


De: Tomasz Jagusz [email protected]
Enviado: sexta-feira, 26 de abril de 2019 09:42:58
Para: aspnet/AspNetCore
Cc: moodya; Menção
Assunto: Re: [aspnet/AspNetCore] Host grpc service no iis ou como um serviço de aplicativo? (#9020)

Concordo plenamente com @jbrantly https://github.com/jbrantly . O gRPC é anunciado como um dos principais recursos do .NET Core 3.
Deve ser hospedável no IIS/Azure App Services.
@shirhatti https://github.com/shirhatti considere adicionar isso ao roteiro


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486977989 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AJKS6PENWT46GCJ7GQGEGPTPSK6BFANCNFSM4HDHMSDA .

Eu não poderia concordar mais.

Estamos investigando. Requer alterações do kernel do Windows e alterações do IIS.

@davidfowl isso será possível quando o .NET Core 3 for lançado?
A capacidade de hospedar o GRPC no App Services é um bloqueador para mim.

Bem é 29 de maio de 2019 , e ainda não há sinal de que isso será possível. Estou procurando hospedar um serviço GRPC no IIS e adicionar um certificado para usar HTTPS :(

Não, não é possível no IIS, estamos trabalhando para obter as alterações, mas será um processo lento (já que requer uma atualização do Windows).

Eu perdi cerca de 3 dias... obrigado iis

Olá @davidfowl
Qualquer atualização?

@davidfowl alguma chance de isso ser adicionado antes do lançamento do .NET Core 3.0? Ou devemos esperar por 3.1 ou 5.0?

Não, pois requer alterações no Windows. Ele não fará parte do 3.0 e exigirá a versão mais recente do Windows (seja lá o que for no momento) para obter esses recursos. Não há HEC

Hmm, estou no meio do planejamento de uma implementação de malha de serviço que usará serviços sem estado baseados em gRPC e atores confiáveis, em cima do dotnet core 3. Isso vai me incomodar? Se eu hospedar no SF, acho que vou usar o Kestrel no núcleo? Hora de prototipar.

@oising mesmo barco aqui - mas estamos rolando lentamente em direção a contêineres k8s + linux, então isso ajuda a nos empurrar dessa maneira de qualquer maneira.

Estou apenas mais 1'ing isso, pois tenho brincado com gRPC agora por um tempo e quero finalmente começar a adotá-lo em alguns projetos de meus clientes, então estava analisando os fluxos de trabalho de implantação. Estou um pouco desanimado com a quantidade de sobrecarga operacional que seria implantar em produção com .net core.

Também me levou dias para descobrir que o IIS era o problema. Realmente procurando uma correção. Alguma solução alternativa?

@bingoo sem suporte ao Windows e IIS Você está sem sorte. Você pode usar o Service Fabric, mas não tenho experiência com isso. Espero que seja possível hospedá-lo no IIS ou no Azure de forma simples.
Para projetos atuais, o Grpc não é uma opção para mim por causa desse problema.

Seria bom se isso fosse um grande aviso ousado nos documentos ...

A hospedagem IIS ainda não é suportada. Os Serviços de Aplicativos usam o Windows Server 2016 + IIS como back-end por padrão, mas agora também suporta Linux/Contêineres. Se você deseja apenas implantar o GRPC no Azure App Service, pode fazê-lo agora com um contêiner do Linux. Mas o Plano de Serviço de Aplicativo não pode ser compartilhado com um plano de hospedagem do Windows. Você precisará gastar dinheiro extra para um novo Plano de Serviço de Aplicativo com suporte do Linux Container.

A melhor maneira é usar o AKS e depois o Ambassador. O Ambassador é um gateway de API baseado no Envoy que é executado como um contêiner dentro do Kubernetes. Ele permite que você faça proxy de grpc e grpc-web, por exemplo. navegador para servidor grpc e também um cliente grpc, talvez ac# um para um servidor grpc. Se você deseja que o frontend js receba chamadas gRPC, você precisa do grpc web e de um proxy porque os navegadores também não suportam os cabeçalhos à direita da resposta http2 corretamente. O Grpc Web usa o Envoy por padrão, por isso o Ambassador é o melhor.

Se você deseja apenas implantar o GRPC no Azure App Service, pode fazê-lo agora com um contêiner do Linux

@EdiWang No momento, isso não é compatível com o Serviço de Aplicativo para Linux. No momento, estamos trabalhando com o Serviço de Aplicativo para habilitar isso, mas não tenho ETA para compartilhar

Olá gente boa
Estou um pouco confuso, então não podemos ter serviço grpc no azure.
Mas o próprio azure está usando grpc, o Azure Functions Languge Worker Protobuf.
https://github.com/Azure/azure-functions-language-worker-protobuf
Ou estou perdendo alguma coisa aqui?
Tentando entender :confused:

@GoranHalvarsson Você pode ter serviços gRPC no Azure, mas ainda não pode executá-los nos Serviços de Aplicativo do Azure.

@markrendle Obrigado por responder. Então, como posso usar/configurar um serviço gRpc no Azure?

Seria bom se isso fosse um grande aviso ousado nos documentos ...

https://github.com/aspnet/AspNetCore.Docs/issues/14684

@markrendle Obrigado por responder. Então, como posso usar/configurar um serviço gRpc no Azure?

Ao não usar o IIS, o que significa usar o Service Fabric ou AKS - ambos usando o Kestrel bruto. SF e AKS têm características diferentes. Pesquise "Service Fabric vs AKS" no Google e tome um grande café.

Eu criei um guia passo a passo para criar teste e implantar serviço grpc usando .NET Core 3.0
https://github.com/rupeshtech/k8s-grpc-dotntecore

Acabei de analisar esse problema, então ainda não tentei nada; mas alguém tentou usar o Azure Web App para (Container https://azure.microsoft.com/en-us/services/app-service/containers/)?

Estou executando vários microsserviços baseados em docker nos Serviços de Aplicativo do Azure e tive muito poucos problemas e me permitiram contornar outras características limitantes da oferta do Serviço de Aplicativo OOB.

@ikemtz gRPC funciona ao usar kestral (ou seja: ao executar em contêineres).

@rupeshtech Obrigado, mas seu artigo não está relacionado ao problema.

Esse problema é para hospedar gRPC (ou qualquer aplicativo usando cabeçalhos à direita) no IIS ou no Serviço de Aplicativo do Azure.

Seria bom se isso fosse um grande aviso ousado nos documentos ...

aspnet/AspNetCore.Docs#14684

Isso agora está implementado .

@ikemtz Tentei executar um teste básico para usar gRPC em um contêiner Linux em execução em um aplicativo Web do Azure para contêineres e não funcionou para mim. Não foi possível encontrar nenhum erro relatado em nenhum lugar, mas o contêiner nem respondeu a pings HTTP.
É uma vergonha. Não estou preparado para mudar para o AKS apenas para obter essa funcionalidade, então acho que vou ficar com os bons serviços HTTP antiquados por enquanto.

@searus se você usar uma máquina virtual (executando no azure)

@GoranHalvarsson Não estou preparado para mudar de PaaS para IaaS apenas para usar essa tecnologia. Vou esperar até que o Serviço de Aplicativo do Azure possa dar suporte a isso.

@davidfowl Algum roteiro sobre isso?

A implantação em um contêiner usando o Kestral é boa, mas é fácil dizer
usando Lets Encrypt no IIS ou um serviço de aplicativo que realmente está me atrapalhando.
Se houver algum guia conciso sobre como executar um domínio personalizado com permite
criptografar no kestrel em um contêiner, então estou pulando de cabeça no gRPC
caso contrário, é muito difícil justificar a sobrecarga de criar alguns
implantação apenas para acomodar a nova pilha.

Na quarta-feira, 16 de outubro de 2019 às 6h46 Russell Seamer [email protected]
escrevi:

@GoranHalvarsson https://github.com/GoranHalvarsson Não estou preparado
mudar de PaaS para IaaS apenas para fazer uso dessa tecnologia. eu vou apenas
aguarde até que o Serviço de Aplicativo do Azure possa dar suporte a isso.


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aspnet/AspNetCore/issues/9020?email_source=notifications&email_token=AMNAZYUWLYLGC5ZGB4GAFITQO2TCFA5CNFSM4HDHMSDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLFDDI#comment-5WW2ZLOORPWSZGOEBLFDDI#comment-5WW2ZLOORPWSZGOEBLFDDI#comment-5 .
ou cancelar
https://github.com/notifications/unsubscribe-auth/AMNAZYTKUYYBWKSW6AMQDHTQO2TCFANCNFSM4HDHMSDA
.

Com isso, o Azure Functions e qualquer outra coisa que esteja no topo do Serviço de Aplicativo não pode realmente usar gRPC e HTTP/2. Uma linha do tempo seria boa, mesmo para visualizações privadas/públicas.

No momento, estamos trabalhando nas alterações em http.sys. Depois disso, precisamos reagir a essas mudanças no IIS e no ARR. Em seguida, precisamos atualizar a versão do Windows em execução no serviço de aplicativo para aproveitar essas alterações no IIS.

O trabalho foi declarado, mas é realmente difícil estimar quanto tempo levará para os clientes obtê-lo. Manteremos você informado à medida que as coisas progridem.

Sinto que isso é algo com o qual não estou surpreso (que a implementação de novas funcionalidades http requer atualizações do kernel). Obviamente, o IIS não existe no Linux / macosx, mas ficaria surpreso se adicionar suporte para grpc a outros servidores para outros sistemas operacionais ... precisar muito de atualização do kernela.

Talvez este seja um argumento/exemplo decente para desacoplar ... Apenas dizendo

Sinto que isso é algo com o qual não estou surpreso (que a implementação de novas funcionalidades http requer atualizações do kernel). Obviamente, o IIS não existe no Linux / macosx, mas ficaria surpreso se adicionar suporte para grpc a outros servidores para outros sistemas operacionais ... precisar muito de atualização do kernela.

Talvez este seja um argumento/exemplo decente para desacoplar ... Apenas dizendo

Eu concordo. Isso provavelmente tem a ver com o IIS executando algum protocolo de baixo nível que está vinculado diretamente ao kernal. Parece estranho, mas pelo menos temos a confirmação de que isso está sendo trabalhado e que a adoção não é completamente azul.

Lembra quando você teve que atualizar para o Windows 8 para obter suporte ao WebSocket? Eu também 😄

Sim, lembramos! Aqui está o furo: o gRPC é lançado em .NET-Core e usamos o Azure App Services, por isso é importante ter alguma opção, pelo menos para testar, o mais rápido possível. Alguém pode nos dizer quando essa sincronização com os recursos .NET-Core lançados acontecerá nos Serviços de Aplicativo do Azure? Ou uma solução viável. Obrigado

Obrigado por nos contatar. Devido a nenhuma atividade sobre esse problema, estamos fechando-o em um esforço para manter nossa lista de pendências limpa. Se você acredita que há uma preocupação relacionada à estrutura ASP.NET Core, que ainda não foi abordada, registre um novo problema.

@anurse como mantemos esse problema em aberto?

Ele foi colocado em Discussões e marcado pergunta. Reaberto.

Já existe algum ETA sobre isso?

Existem alternativas viáveis ​​para que o gRPC funcione em um ambiente de produção?
Analisei algumas coisas e parece que hospedá-lo no AKS é uma opção, só quero ter certeza de que não estamos fazendo coisas que não nos ajudarão a resolver nosso problema.

No momento, estamos tentando obter algum tipo de ambiente de produção em execução para estes projetos:
Projeto IdentityServer que se comunica com uma API por gRPC
5 portais da web que conversam com uma API sobre gRPC
A API que conversa com um Discord Bot (ASP.NET Core) sobre gRPC.

Tentamos hospedá-los em um VPS, mas não sei se podemos hospedá-los em um ambiente de produção apenas usando o Kestrel se quisermos que todos esses aplicativos vivam no mesmo VPS.

Alguém tem uma opção para nós para que possamos ter vários domínios (1 domínio, o resto são subdomínios) com 1 endereço IP em 1 VPS executando todos os projetos usando apenas o Kestrel (por causa das limitações no IIS, Http.Sys, janelas).

(Ou qualquer outro método que nos permita hospedar tudo isso o mais rápido possível)

Desde já, obrigado!

(EDITAR)

Usamos Let's Encrypt ( https://github.com/natemcmaster/LetsEncrypt ) para obter um certificado SSL

(EDIÇÃO 2)
Também tentamos entrar em contato com @davidfowl sobre isso no twitter
https://twitter.com/DapperDino4/status/1204119195765682177 e
https://twitter.com/DapperDino4/status/1204119695344971778

Já existe algum ETA sobre isso?

Adicionando @shirhatti e @Tratcher que estão trabalhando nisso.

O momento disso é difícil de definir agora. O IIS é um componente do Windows e depende de http.sys, que também é um componente do Windows. Nem o IIS nem o http.sys têm recursos HTTP/2 suficientes para dar suporte ao gRPC. Temos trabalhado muito de perto com essas equipes para obter as alterações, e todas estão no caminho certo para uma versão futura, mas não estarão disponíveis até que uma versão do Windows Server com as alterações apropriadas seja lançada.

@JamesNK você pode falar sobre a disponibilidade de alternativas como gRPC-web?

Contexto para quem não sabe o que é gRPC-Web: https://grpc.io/blog/state-of-grpc-web/. Como ele usa HTTP/1.1, as restrições do Serviço de Aplicativo do Azure não se aplicam a ele. A desvantagem é que não há benefícios HTTP/2 (multiplexação, compactação de cabeçalho) e nenhum cliente ou streaming bidirecional.

O proxy reverso gRPC-Web envoy já está disponível, mas não é fácil de configurar. E não há cliente .NET gRPC-Web.

A equipe do ASP.NET Core ainda não decidiu se vamos nos comprometer a oferecer suporte oficial ao gRPC-Web. Estou analisando o gRPC-Web agora e como ele poderia ser no .NET Core. Em algumas semanas eu posso dizer mais, e talvez ter uma prévia experimental para as pessoas experimentarem em janeiro.

Como o IIS não oferece suporte a isso, o serviço gRPC netcore pode ser hospedado por trás do Nginx?

@Dennis-Petrov Eu faço exatamente isso. Eu segui este documento https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-3.1 e o gRPC funciona muito bem

Posso fazer uma pergunta estúpida: Por que isso não funciona em um Azure App Service no linux App Service Plan?

O IIS também está envolvido nisso em algum lugar no pipeline?

@searus Existem camadas comuns entre os serviços de front-end e de aplicativos, independentemente do Linux/Windows. Ou seja, atualmente, o front-end do serviço de aplicativo recebe as conexões HTTP/2 e, em seguida, as conexões internas são proxies como HTTP "antigo" para trabalhadores de serviço de aplicativo individuais. Tenho certeza de que está em andamento para oferecer suporte total ao gRPC, mas é preciso algum esforço, pois os componentes internos precisam ser atualizados, testados e lançados.

Obrigado @devlead.
Eu (talvez ingenuamente) pensei que um Plano de Serviço de Aplicativo Linux era totalmente Linux.
Eu aprecio totalmente o esforço envolvido aqui e obrigado por dedicar um tempo para explicar.

Tenho certeza de que está em andamento para oferecer suporte total ao gRPC

Definitivamente está em obras. Estamos trabalhando ativamente nisso, mas não podemos garantir um cronograma (há várias equipes independentes que precisam coordenar aqui). @devlead está correto sobre o suporte ao Linux do Serviço de Aplicativo do Azure. O proxy front-end está executando o IIS. Ele suporta o recebimento de HTTP/2 do cliente, mas quando faz o proxy de tráfego para seu aplicativo, ele faz downgrade para HTTP/1.1. Isso foi bom (embora não seja o ideal) para aplicativos normais, mas como o gRPC requer recursos HTTP/2, não é adequado para eles.

Sim, eu já construí um serviço que está sendo executado como um serviço hospedado genérico. Eu o portei para o novo modelo asp net core 3 e o fiz funcionar em kestrel auto-hospedado, mas atualmente olhando para hospedá-lo atrás do iis e, esperançosamente, implantá-lo como um serviço de aplicativo no Azure. Não consigo fazer o primeiro (iis) funcionar.

@moodya você pode compartilhar conosco como você fez isso??

Sim, eu já construí um serviço que está sendo executado como um serviço hospedado genérico. Eu o portei para o novo modelo asp net core 3 e o fiz funcionar em kestrel auto-hospedado, mas atualmente olhando para hospedá-lo atrás do iis e, esperançosamente, implantá-lo como um serviço de aplicativo no Azure. Não consigo fazer o primeiro (iis) funcionar.

@moodya você pode compartilhar conosco como você fez isso??

O modelo gRPC é kestrel auto-hospedado por padrão. Não funcionará no serviço de aplicativo pelos motivos descritos neste tópico.

Embora não possa ser hospedado no serviço de aplicativo, digamos que hospedamos o serviço grpc no aks, há algum problema em chamar o grpc do serviço de aplicativo? O cliente grpc estará pelo menos trabalhando no serviço de aplicativo?

Embora não possa ser hospedado no serviço de aplicativo, digamos que hospedamos o serviço grpc no aks, há algum problema em chamar o grpc do serviço de aplicativo? O cliente grpc estará pelo menos trabalhando no serviço de aplicativo?

Sim, os clientes devem trabalhar. A limitação é apenas em solicitações de entrada, não de saída.

Talvez uma pergunta estúpida, mas por que funciona se estou executando o serviço gRPC no Debug with IIS Express? Por exemplo, eu tenho um aplicativo da web (Razor Pages, .net core 3.1) que faz chamadas para um serviço gRPC [atualizado de um aplicativo framework mvc conversando com um serviço wcf, se alguém se importa]. Se eu depurar os dois na minha estação de trabalho, com o serviço gRPC no IIS Express, o webapp pode conversar com o serviço muito bem. Devido ao comportamento de proxy @anurse descrito acima, quando o serviço é hospedado no IIS, recebo a exceção de que o gRPC requer HTTP/2. O proxy do IIS Express para o Kestrel é diferente do IIS?

Além disso, talvez não seja o lugar para isso, mas gostaria de humildemente pedir que a página abaixo receba uma pequena explicação do comportamento de proxy do IIS/Serviço de Aplicativo. Eu (talvez tolamente) passei um dia inteiro tentando enganar o IIS porque pensei que poderia forçá-lo a proxy no HTTP/2 se o aplicativo estivesse fora de processo no Kestrel https://docs.microsoft.com/en- us/aspnet/core/grpc/aspnetcore?view=aspnetcore-3.1&tabs=visual-studio#integration -with-aspnet-core-apis

O IIS Express não deve funcionar pelos mesmos motivos que o IIS não funciona.

@Tratcher Ah sim, você está correto. Eu estava executando o serviço gRPC como auto-hospedado, não IIS Express. Obrigado!

Alguém tem um tutorial sobre como fazer isso funcionar no AKS? (pontos de bônus para depuração com código vs em aks localmente sem ter que reconstruir contêineres para que tenhamos toda a pilha com .net core dev, até implantar no azure usando azure devops e aks).

Mais importante, o que você está usando no AKS para fazer proxy do tráfego da Web para os pods do AKS sem precisar usar o ngix no próprio pod (ou seja, balanceador de carga do Azure ou algo assim?)

Embora não possa ser hospedado no serviço de aplicativo, digamos que hospedamos o serviço grpc no aks, há algum problema em chamar o grpc do serviço de aplicativo? O cliente grpc estará pelo menos trabalhando no serviço de aplicativo?

Sim, os clientes devem trabalhar. A limitação é apenas em solicitações de entrada, não de saída.

Infelizmente, esse não parece ser o caso com o aplicativo Web baseado em .Net Core 3.1 chamando um serviço grpc (neste caso, código Pyhton em execução em uma VM) quando hospedado em aplicativos Web do Azure - tempo limite. Ao executar exatamente o mesmo código do localhost, a chamada passa (mesma VM de serviço).

@lyulyok você pode coletar diagnósticos e abrir um problema separado? Não há problemas conhecidos com o cliente aqui.

Alguém tem um tutorial sobre como fazer isso funcionar no AKS?

Abra um novo problema para discutir isso ou pergunte no Stack Overflow . Vamos manter este tópico no tópico, especialmente porque há muitas pessoas interessadas no status do gRPC no IIS e HTTP.sys e todos os comentários enviam ping para todas as pessoas que estão nele. Vou ocultar comentários fora do tópico, sinta-se à vontade para postar novos problemas se tiver mais dúvidas.

Sim, eu já construí um serviço que está sendo executado como um serviço hospedado genérico. Eu o portei para o novo modelo asp net core 3 e o fiz funcionar em kestrel auto-hospedado, mas atualmente olhando para hospedá-lo atrás do iis e, esperançosamente, implantá-lo como um serviço de aplicativo no Azure. Não consigo fazer o primeiro (iis) funcionar.

O suporte experimental para gRPC-Web em .NET já está disponível. O gRPC-Web funciona com HTTP/1.1 e HTTP/2 e é executado no IIS e no Serviço de Aplicativo do Azure.

Continuamos a trabalhar para HTTP/2 gRPC em execução no Serviço de Aplicativo do Azure, mas gRPC-Web é algo que você pode usar hoje . Quando o trabalho para dar suporte a HTTP/2 no IIS e no Serviço de Aplicativo do Azure estiver concluído, será um processo simples alternar um aplicativo .NET de gRPC-Web para HTTP/2 gRPC.

Postagem do blog: https://devblogs.microsoft.com/aspnet/grpc-web-experiment
Documentação: https://docs.microsoft.com/aspnet/core/grpc/browser

Eu tenho o cliente grpc rodando no serviço de aplicativo e o serviço rodando bem no aks, caso alguém queira tentar também

@andrew-vdb Você pode postar a configuração, por favor?

Olá @JamesNK ,
relacionado ao seu comentário https://github.com/dotnet/aspnetcore/issues/9020#issuecomment -579597202 e ao fato de que gRpc-Web atualmente parece ser _um projeto experimental, não um produto comprometido._

  • Preciso do gRpc-Web para implantar no IIS? Caso contrário, não é possível?
  • Você tem um ETA sobre quando será possível implantar no IIS sem gRpc-Web?
  • Você tem um ETA quando o gRpc-Web será oficialmente suportado pela Microsoft?

Preciso do gRpc-Web para implantar no IIS? Caso contrário, não é possível?

Atualmente, o gRPC sobre HTTP/2 não funciona no IIS. gRPC-Web funciona.

Você tem um ETA sobre quando será possível implantar no IIS sem gRpc-Web?

Não. Leva tempo para que as alterações sejam feitas no Windows e divulgadas ao público.

Você tem um ETA quando o gRpc-Web será oficialmente suportado pela Microsoft?

Não no momento.

Para sua informação
Eu tenho um aplicativo (ASP.Net Core 3.2.0-Preview1) no qual troquei uma API REST DAL por uma gRPC-Web DAL. Eu segui a orientação da postagem no blog de Steve Sanderson. Minha solução pode ser executada como CSB ou SSB e obtive sucesso com gRPC-Web em ambas as configurações (precisei avançar para uma versão mais recente dos pacotes gRPC.* nuget).

Por engano, fiz mais atualizações das compilações noturnas e, atualmente, meus pacotes gRPC estão todos na versão 2.28.0-dev202003020801. Digo erroneamente porque minhas duas implantações de solução de trabalho falham.

SSB - O cliente relata um erro de "Componente de renderização de exceção não tratada: não foi possível carregar o arquivo ou assembly 'System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. O sistema não pode localizar o arquivo especificado. "
Simplesmente adicionando um pacote nuget explícito de System.Text.Json (4.7.1) ao meu projeto de servidor web, esse erro desaparece e tudo funciona.
[EDIT] Retornar às versões 2.27.0/2.27.0-Pre1 para todos os pacotes gRPC.* do feed NuGet resolve esse problema.

CSB - No mesmo ponto no cliente ao receber a primeira resposta gRPC-Web estou recebendo um erro de "WASM: Grpc.Core.RpcException: Status(StatusCode=Internal, Detail="Bad gRPC response. Response protocol downgradeed to HTTP /1.1.")". Não tenho uma solução para isso, mas não é crítico, pois estamos enviando SSB até que o CSB seja lançado.
[EDIT] Retornar às versões 2.27.0/2.27.0-Pre1 para todos os pacotes gRPC.* do feed NuGet resolve esse problema.

Desculpe a verbosidade, mas para finalizar, duas perguntas:

  • É possível usar outro serializador/desserializador json no gRPC/gRPC-Web?
  • Os pacotes gRPC/gRPC-Web serão 'alinhados' com o ASP.Net Core 3.2-Preview 2 ou será necessário acessar compilações noturnas?

Olá @JamesNK ,
Meu cliente migrou para o gRpcWeb, mas encontramos uma limitação importante (da qual não encontrei nenhuma documentação): o tamanho máximo da mensagem é 3067 caracteres.
Se do serviço de cliente usual do serviço gRpc básico, convertido para gRpc-Web, esta linha falhará (porque a string tem 3068 caracteres, 1 acima do limite):

// Configure um canal para usar gRPC-Web
var handler = new GrpcWebHandler(GrpcWebMode.GrpcWebText, new HttpClientHandler());
// O número da porta (5001) deve corresponder à porta do servidor gRPC.
usando var channel = GrpcChannel.ForAddress(" https://localhost :5001", new GrpcChannelOptions
{
HttpClient = new HttpClient(manipulador)
});
var cliente = new Greeter.GreeterClient(canal);
var resposta = espera cliente.SayHelloAsync(new HelloRequest { Nome = new string('A', 3068 ) });
Console.WriteLine("Saudações: " + resposta.Mensagem);
Console.WriteLine("Pressione qualquer tecla para sair...");
Console.ReadKey();

Eu anexei uma solução de reprodução contendo cliente e servidor.
GrpcWeb.zip

O projeto equivalente com gRpc normale foi capaz de lidar com mensagens de 20k sem problemas.
Você pode me aconselhar se eu posso configurar algo para remover esse limite?

@curia-damiano você pode registrar um novo problema com isso? Vamos manter este tópico para discutir o recurso específico de suporte a gRPC ( sem gRPC-Web) no IIS/Azure App Service. O gRPC-Web foi levantado anteriormente neste encadeamento porque é uma boa alternativa, mas gostaria de manter este encadeamento focado no objetivo principal do suporte nativo ao gRPC.

@MarkStega você também pode registrar um novo problema com sua pergunta? Vamos tentar evitar que este tópico fique sobrecarregado com vários tópicos possíveis (mesmo que estejam relacionados). Este problema está acompanhando o suporte gRPC nativo no IIS/Azure App Service

Podemos ter um ETA quando o gRPC estará disponível no Azure App Service, por favor?

Não temos atualizações de ETA. Atualizaremos este tópico quando tivermos um ETA . Isso requer alterações no Windows e estamos trabalhando com essa equipe para tentar colocá-las em prática o mais rápido possível, mas a programação delas não está sob nosso controle direto.

Podemos construir um serviço gRPC empacotado como um contêiner e executado em um aplicativo Web para contêineres no Azure?

@fgheysels Não. Ele ainda está atrás do IIS como um proxy que não pode lidar com a funcionalidade HTTP/2 necessária.

Existem 3 maneiras de fazer isso agora:

  1. Exponha um IP público e use uma VM.
  2. Use Kubernetes com Entrada de Gateway de Aplicativo do Azure (que as instruções falham porque o script de leme está desatualizado, portanto, não pode ser usado agora) ou use entrada nginx (você perde o firewall e as mitigações de DoS)
  3. Use os serviços de Contêiner do Azure e exponha-o a um IP público ou use nginx para proxy reverso ou use o Gateway de Aplicativo do Azure para proxy reverso.

Nada mais funcionará.

@JohnGalt1717

Use os serviços de Contêiner do Azure e exponha-o a um IP público ou use nginx para proxy reverso ou use o Gateway de Aplicativo do Azure para proxy reverso.

O Gateway de Aplicativo do Azure não funcionará no momento. Tem a mesma limitação

eu acho que poderíamos executá-lo na nuvem gpogle com nosso código .net?

Quarta-feira, 1 de abril de 2020, 7h26 Sourabh Shirhatti, [email protected]
escrevi:

@JohnGalt1717 https://github.com/JohnGalt1717

Use os serviços do Azure Container e exponha-o a um IP público ou use nginx para
proxy reverso ou use o Gateway de Aplicativo do Azure para fazer o proxy reverso.

O Gateway de Aplicativo do Azure não funcionará no momento. Tem o mesmo
limitação


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606855605 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7LVZJTQ2QPRHVB5G5TRKJGYLANCNFSM4HDHMSDA
.

@shirhatti Ok, então isso continua piorando. A Microsoft efetivamente fez com que o .NET com gRPC não pudesse ser executado no Microsoft Azure. Se não fosse tão triste, seria ENGRAÇADO.

Então aqui está a lista atualizada:

  1. Exponha um IP público e use uma VM (coloque haproxy, nginx ou algo na VM para reverter o proxy)
  2. Use Kubernetes (AKS) com entrada nginx.

Eu não acredito que o ACS funcionará porque ele ainda coloca o IIS na frente dele se a memória servir.

E o número 2 também pode não funcionar porque o balanceador de carga também pode ser IIS no Windows ... Alguém realmente consegue que isso funcione em qualquer lugar do Azure?

Acho que esse ticket do github define o que venho dizendo há meses sobre a equipe .NET e o que está acontecendo.

A Microsoft efetivamente fez com que o .NET com gRPC não pudesse ser executado no Microsoft Azure. Se não fosse tão triste, seria ENGRAÇADO.

Não há nada aqui que seja específico para .NET, a limitação está na infraestrutura do Windows e do Azure relacionada ao HTTP/2. Você teria o mesmo problema com outras pilhas da Web no Azure. O Windows e o Azure estão trabalhando para nos desbloquear, mas isso requer alterações em componentes fundamentais que levam muito tempo para serem reimplantados.

Tudo isso está diretamente relacionado ao .net. literalmente diz nos sites azure e .net que .net é a linguagem do azure.

Mas você não pode usar esse idioma com o Azure, mas pode usá-lo na AWS e na nuvem do Google facilmente.

É um embaraço, como acontece com tantos erros maciços da equipe .net ultimamente, mas a arrogância deles está em alta sem razão.

E eles nem nos deram soluções de qualquer tipo além de usar o gRPC web, que é um poc e não um produto real.

Sim, mas podemos executar toda a pilha .net no google cloud, suporte para .net
gRPC tudo bem. Então, não me importo de rodar no GPC até que eles consertem isso
no Azure.
Eu desenvolvo serviços de aplicativos ou aplicativos sem servidor, não estou interessado em nenhum
soluções de contêiner, pois são muito caras para as implantações em grande escala
Eu tenho.

Quarta-feira, 1º de abril de 2020 às 9h57 James Hancock [email protected]
escrevi:

Tudo isso está diretamente relacionado ao .net. literalmente diz no azul e
sites .net que .net é o idioma do azure.

Mas você não pode usar esse idioma com o Azure, mas pode usá-lo na AWS e
Google nuvem facilmente.

É uma vergonha, como acontece com tantos erros enormes da equipe .net
ultimamente, mas sua arrogância está em alta sem razão.

E eles nem nos deram soluções de qualquer tipo além de usar
gRPC web que é um poc não é um produto real.


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606927717 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7MRPFQBH52XDHUNP63RKJYMVANCNFSM4HDHMSDA
.

Primeiro, a Microsoft deve estar aterrorizada com o que você acabou de dizer.

Em segundo lugar, acabei de mudar nosso material da web para o kubernetes do Azure usando nós virtuais e isso nos custa cerca de metade do que os serviços de aplicativos estavam nos custando e tem o dobro do desempenho.

Aks é uma bagunça de coisas que não funcionam direito e documentação desatualizada, mas uma vez que você obtém identidades gerenciadas e um IP público, o resto é direto.

Sim, mas esta é uma grande mudança para a Microsoft! e eu gosto do
simplicidade do gRPC, embora eu possa mudar para http Rx. não consegui meu
websocket para a solução funcionar, pois parecia ter problemas de SSL/TLS.
Parece que posso obter kubs do Azure pelo mesmo custo que meus serviços de aplicativo S1,
tem que verificar o desempenho.

Na quarta-feira, 1 de abril de 2020 às 10h13 James Hancock [email protected]
escrevi:

Primeiro, a Microsoft deve estar aterrorizada com o que você acabou de dizer.

Segundo, acabei de mudar nosso material da web para o kubernetes do Azure usando
nós virtuais e nos custa cerca de metade do que os serviços de aplicativos estavam custando
nós e tem o dobro do desempenho.

Aks é uma bagunça de coisas que não funcionam direito e desatualizado
documentação, mas depois de obter identidades gerenciadas e um IP público em vigor
o resto é direto.


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606933338 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7O3N4XVCWM5MGCTS33RKJ2I7ANCNFSM4HDHMSDA
.

Tudo isso está diretamente relacionado ao .net. literalmente diz nos sites azure e .net que .net é a linguagem do azure.

Isso claramente não é verdade. As pilhas TCP e HTTP subjacentes não são gravadas usando .NET. A Microsoft está trabalhando para adaptar sua base para gRPC. Essa é uma entrega complexa que tem efeitos indiretos para tudo o que é executado em servidores Windows, incluindo o próprio Azure.

É um embaraço, como acontece com tantos erros maciços da equipe .net ultimamente, mas a arrogância deles está em alta sem razão.

Esse tipo de choramingar improdutivo e infantil sem sentido é completamente desnecessário. Isso não tem nada a ver com a equipe .NET. Eles portaram a maior parte do gRPC nativamente para que possamos trabalhar em nossos PoCs e usar soluções alternativas quando necessário e, como adultos maduros, vamos esperar até que a plataforma base esteja pronta para entregar as partes finais.

@oising

.NET é a linguagem do Azure. A Microsoft o comercializa como tal. O .NET gRPC não pode ser entendido pelo Azure. É 100% verdade. É uma falha completa que não estava disponível no lançamento e ainda pior um ano depois. É irrelevante que as pilhas não sejam escritas pela equipe .NET dentro do Microsoft . Microsoft é Microsoft . Eu não me importo com seus pequenos feudos e fronteiras artificiais e prioridades não alinhadas. Eu me preocupo com os melhores produtos possíveis que realmente funcionam. Eu não me importo que a Microsoft afirme isso porque o .NET é de código aberto que de alguma forma não o torna mais um produto pago. É um produto pago. Eu apenas pago indiretamente usando Azure, Office e Windows.

E não, não vamos esperar. Vamos mudar para outro provedor de nuvem onde funciona. Que é o que a Microsoft está pressionando sem parar. Inferno, eu tinha uma pessoa de suporte da Microsoft, digamos e cito "Se você não gostar [do fato de termos quebrado isso em tempo de execução por design], você pode usar o produto de outra pessoa" Para cerca de 100 clientes. Sim, bem, eu sei de 8 que fizeram exatamente o que eles sugeriram até agora e mais 30-40 que estão investigando. A receita perdida estimada para MS desse agente de suporte é de cerca de 2,8 milhões de dólares e contando.

Sim, é exatamente isso que todos nós vamos fazer. Obrigado pela dica Microsoft. Deixaremos o Azure e sairemos do .NET se a liderança não endireitar a cabeça logo.

O que eles têm que se preocupar é quando pessoas como eu pararem de reclamar sobre esses enormes fracassos públicos em que eles não assumem a responsabilidade por eles e, em vez disso, eles não ouvem nada e todos não se importam. Aconteceu há cerca de um ano, quando o Xamarin Forms ficou 18 semanas sem poder compilar para a Apple Store, Android Store e Windows Store com a mesma compilação do Xamarin Forms e do Xamarin em geral. Eu postei, eles admitiram e, 18 semanas depois, apenas 1 pessoa seguiu o relatório do bug, apesar de ser uma pausa completa, não apenas um caso extremo. Por quê? Ninguém se importa com o Xamarin Forms e saiu e começou a usar ferramentas que não são da Microsoft e a Microsoft perdeu o desktop e o celular. (e continua tentando a mesma abordagem fracassada para reconquistá-lo mesmo com Neo e Duo) Agora as pessoas ainda pensam que têm uma voz no .NET e que suas reclamações não serão ignoradas e que essas coisas serão corrigidas. A liderança do .NET está trabalhando muito para deixar claro que esse não é o caso e o resultado será idêntico ao Xamarin Forms.

A peça de cabeçalho do trailer é algo que precisamos com mais urgência do que pensávamos para o Stack Overflow também. Podemos ajudar com a priorização aqui?

Caso de uso

Fazemos cronometragem por meio de cabeçalhos de servidor para capturá-los em nossos logs HTTP (no HAProxy). Temos vários cabeçalhos como X-Sql-DurationMs , X-Sql-Count , X-Reds-DurationMs , etc. para que possamos capturá-los, registrá-los e agregar métricas sobre eles. Se mais detalhes ajudarem, há uma seção nesta postagem do blog . Isso funcionou bem o suficiente no ASP.NET MVC 5 (estrutura completa) porque toda a resposta foi armazenada em buffer. Como fazemos poucas consultas nas visualizações, foi uma estratégia de tempo de ~99% precisa que funcionou bem no geral.

Agora estamos rodando no .NET Core e tudo é streaming. O problema com isso é que os cabeçalhos de tempo são enviados antes de serem concluídos, devido à falta de buffer. É uma troca dura. Isso seria resolvido rapidamente se pudéssemos enviar e capturar esses horários como cabeçalhos de trailer. Mas parece que estamos em um bloqueador do IIS aqui e estamos à mercê da atualização (ou da mudança do IIS) para que essa funcionalidade funcione.

Pessoalmente, também tenho outros usos, como o MiniProfiler enviando o cabeçalho Server-Timing (está pronto e esperando cerca de 3 anos ).

Como podemos ajudar com a prioridade sobre isso? Existe alguma chance de casos de uso adicionais ajudarem a mudar isso?

Obrigado @NickCraver. Esse trabalho já é de alta prioridade e está em andamento, mas implantá-lo em serviços como o AppService é complicado e ainda levará algum tempo.

Existe a possibilidade de ter suporte no IIS em breve, independentemente do lançamento do Azure? -- Eu realmente só preciso de um cliente no IIS - se isso importa. Então o IIS pode ser um cliente http2?

Devo concordar, que é preocupante, que parece impossível para os funcionários da Microsoft, pegar suas pernas (ou telefone neste momento) e ir para aquela outra equipe. E irritá-los tanto que eles implantam um hotfix em um dia.
Se a equipe asp / .net não tivesse empurrado para grpc este período de espera seria bom. Mas já que você está comercializando um produto que não pode ser usado na produção, infelizmente é hora de medidas desesperadas e quebrar fileiras.

Se você se importa, você vai fazer acontecer.

Edit: Eu sei que “um dia” é exagerado, mas já faz um ano!

Existe algum documento explicando como implantar o gRPC no Azure? pelo menos usando AKS? Seria bom ter algo.

Existe algum documento explicando como implantar o gRPC no Azure? pelo menos usando AKS? Seria bom ter algo.

@lumogox Criei um guia passo a passo para implantar o gRPC no Azure.
https://github.com/rupeshtech/k8s-grpc-dotntecore

@rupeshtech Na verdade, dei uma olhada no seu guia, no entanto, não funciona se você quiser mostrar uma mensagem no caminho raiz na porta 80.

Ótimas coisas, mas quero implantar em serviços de aplicativos e ainda não temos ETA.
Foi alegado por um dos outros caras que o AKS era mais barato que o aplicativo
serviços, acho isso difícil de acreditar?
De qualquer forma, eu só quero usar serviços de aplicativos ou infraestrutura sem servidor.

Em terça-feira, 12 de maio de 2020 às 17h51 Luis Molina [email protected]
escrevi:

@rupeshtech https://github.com/rupeshtech Eu realmente dei uma olhada
seu guia, no entanto, ele não funciona se você quiser mostrar uma mensagem no
caminho raiz na porta 80.


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627175783 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7MUWWWYCGMEK2FH663RRD5YPANCNFSM4HDHMSDA
.

AKS: b12, cluster de 2 nós custa US $ 176 / mês e oferece desempenho como um p3.

Você precisará do seguinte para fazer isso funcionar:

  1. entrada do nginx como proxy reverso.
  2. Aplicativo .net core dockerizado
  3. Modelos de implantação para seu aplicativo .net core
  4. Modelos de serviço para essas implantações
  5. O modelo de entrada que mapeia suas entradas de DNS
  6. cert bot para k8s ou seu próprio certificado para mapear para o ingresso.
  7. Desative o SSL apenas no seu app .net, ele vai ferrar com o RP e ativar o suporte de proxy no .net core.
  8. IP Público
  9. Registro de Contêiner do Azure

É um processo de 30 partes para configurar isso no Azure agora e praticamente nada disso pode ser feito por meio do portal da GUI. Eles não estão associando registros de contêiner, configurando provedores de entrada (Azure Application Gateway nem nginx nem haproxy etc. têm qualquer gui para configurá-lo. Nenhuma das coisas principais de serviço com outros recursos, nem coisas de identidade gerenciada são automatizadas adequadamente precisa de ambos por razões insondáveis).

Se você estiver fazendo um certificado curinga, também precisará de acesso ao seu DNS por meio de um dos provedores de DNS suportados pelo serviço certbot k8s.

Aqui está nosso script para configurar um ambiente que pode ajudá-lo a começar:

Configuração do Azure

  1. Criar AKS
  2. az aks install-cli (se você ainda não o fez)
  3. aks get-credentials --resource-group RGL-\ --name XX-AKS-\
  4. az network public-ip create --resource-group MC_RGL-\ _XX-AKS-\ _eastus --name PIP-AKS-\ --sku Standard --allocation-method static --query publicIp.ipAddress -o tsv
  5. Mapeie api, www, admin para o ip público no DNS (ou seja, beta.XX.com)
  6. az identity create -g RGL-\ -n XX-MI-AKS-\ -o json (Grava o ClientId, PrincipalId, Id e Name)
  7. az atribuição de função criar --role Reader --assignee \ --escopo /assinaturas/\ /resourcegroups/RGL-\
  8. Obtenha informações da entidade de serviço dos aplicativos do Azure Active Directory: XX-AKS-\ SP-xxxx (Nome do registro, ID do cliente)
  9. Crie um segredo do cliente sem expiração e registre-o
  10. az atribuição de função create --role "Operador de identidade gerenciada" --assignee \ --alcance "\ "
  11. Obtenha o id da zona dns: az network dns zone list --query "[].{ id: id, name: name}"
  12. az atribuição de função criar --assignee \ --role Colaborador --scope \
  13. az atribuição de função criar --assignee \ --role Colaborador --scope \
  14. az aks update -n XX-AKS-\ -g RGL-\ --attach-acr clcr\
  15. Adicionar identidade gerenciada (XX-MI-AKS-\ ) para o Cofre de Chaves

Kubernetes Vamos criptografar (se não for produção)

  1. kubectl cria namespace ingress-basic
  2. helm repo adicionar estável https://kubernetes-charts.storage.googleapis.com/
  3. helm install nginx-ingress stable/nginx-ingress --namespace ingress-basic --set controller.replicaCount=2 --set controller.nodeSelector."beta.kubernetes.io/os"=linux --set defaultBackend.nodeSelector." beta.kubernetes.io/os"=linux --set controller.service.loadBalancerIP="\ "
  4. Verifique se foi necessário: kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-controller
  5. kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
  6. Atualize o issuer.yaml com a assinatura e o Service Principle ClientId
  7. Atualizar certificate.yaml para o endereço dns
  8. Atualize ingress.yaml com informações de domínio etc.
  9. Faça a versão Base64 do Service Principal Secret: echo \ | openssl base64
  10. Atualize secure-dazuredns.yaml com o segredo

OU Kubernetes Azure Application Gateway

  1. Não funciona. bagunça completa

Configuração completa do Kubernetes

  1. kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
  2. Atualizar deploy-api com registro, keyvault, ambiente e chave de instrumentação
  3. Atualizar registro no deploy-portal e deploy-admin
  4. Atualizar valores em identity-binding.yaml (ClientId também é da identidade gerenciada acima)
  5. kubectl cria namespace XX
  6. kubectl config set-context --current --namespace=XX
  7. kubectl apply -k ./\
  8. Verifique se o certificado está disponível: kubectl describe certificate XX-tls-secret

Sim, é realmente tão difícil. E não, não há uma maneira mais fácil no k8s. Sua única outra opção é uma VM com um IP público e usar um RP na frente do seu aplicativo. Você pode usar uma VM Linux e executar o docker nela e instalar o HAproxy e seu aplicativo em um contêiner docker com um único arquivo de composição do docker com bastante facilidade.

Caso contrário, você está ferrado até que eles comecem a lançar o kernel do Windows 2004 (primavera de 2020) para o Azure. (supondo que chegou lá e não seja adiado até novembro)

Uau cara, isso é incrível, obrigado, mas como eu também sou um grande fã de
Azure Dev Ops com uma abordagem NoOps Eu realmente sinto que o AKS não está em
minha liga.
Especialmente quando eu provavelmente posso executar um serviço de aplicativo decente por um pouco menos
do que isso. Ou mude para uma função do Azure. Não consegui meu websocket
solução para implantar no Azure.
Eu também sou um grande fã de Extensões Reativas e há alguns bons Rx
ferramentas lá fora como esta
https://github.com/lucassklp/Rx.Http
Não tenho certeza sobre a escalabilidade disso embora

Em terça-feira, 12 de maio de 2020 às 22h09 James Hancock [email protected]
escrevi:

AKS: b12, cluster de 2 nós custa US $ 176 / mês e oferece desempenho como um p3.

Você precisará do seguinte para fazer isso funcionar:

  1. entrada do nginx como proxy reverso.
  2. Aplicativo .net core dockerizado
  3. Modelos de implantação para seu aplicativo .net core
  4. Modelos de serviço para essas implantações
  5. O modelo de entrada que mapeia suas entradas de DNS
  6. cert bot para k8s ou seu próprio certificado para mapear para o ingresso.
  7. Desative o SSL apenas no seu app .net, vai estragar com o RP e
    ative o suporte de proxy no .net core.
  8. IP Público
  9. Registro de Contêiner do Azure

É um processo de 30 partes para configurar isso no Azure agora e virtualmente
nada disso pode ser feito através do portal GUI. Eles estão faltando associando
registros de contêiner, configurando provedores de entrada (Azure Application
Gateway nem nginx nem haproxy etc. tem qualquer gui para configurá-lo. Nenhum dos
Material principal de serviço com outros recursos, nem material de identidade gerenciada é
automatizados corretamente (e você precisa de ambos por razões insondáveis).

Se você estiver fazendo um certificado curinga, também precisará acessar seu DNS
através de um dos provedores de DNS suportados pelo serviço certbot k8s.

Aqui está nosso script para configurar um ambiente que pode ajudá-lo a obter
iniciado:
Configuração do Azure

  1. Criar AKS
  2. az aks install-cli (se você ainda não o fez)
  3. az aks get-credentials --resource-group RGL- --name XX-AKS-
  4. az network public-ip create --resource-group MC_RGL-_XX-AKS-_eastus
    --name PIP-AKS- --sku Padrão --allocation-method estático --query
    publicIp.ipAddress -o tsv
  5. Mapeie api, www, admin para o ip público no DNS (ou seja, beta.XX.com)
  6. az identity create -g RGL- -n XX-MI-AKS- -o json (Grave o
    ClientId, PrincipalId, Id e Nome)
  7. az atribuição de função criar --role Reader --assignee --scope
    /subscriptions//resourcegroups/RGL-
  8. Obtenha informações da entidade de serviço dos aplicativos do Azure Active Directory:
    XX-AKS-SP-xxxx (nome do registro, ID do cliente)
  9. Crie um segredo do cliente sem expiração e registre-o
  10. az atribuição de função create --role "Operador de identidade gerenciada"
    --responsável --escopo ""
  11. Obtenha o ID da zona dns: az network dns zone list --query "[].{ id:
    id, nome: nome}"
  12. az atribuição de função criar --assignee --role Contribuidor --scope
  13. az atribuição de função criar --assignee --role Contribuidor --scope
  14. az aks update -n XX-AKS- -g RGL- --attach-acr clcr
  15. Adicionar identidade gerenciada (XX-MI-AKS-) ao cofre de chaves

Kubernetes Vamos criptografar (se não for produção)

  1. kubectl cria namespace ingress-basic
  2. repositório de leme adicionar estável
    https://kubernetes-charts.storage.googleapis.com/
  3. helm install nginx-ingress stable/nginx-ingress --namespace
    ingress-basic --set controller.replicaCount=2 --set
    controller.nodeSelector."beta.kubernetes.io/os"=linux --set
    defaultBackend.nodeSelector."beta.kubernetes.io/os"=linux --set
    controller.service.loadBalancerIP=""
  4. Verifique se foi necessário: kubectl --namespace ingress-basic get services -o
    wide -w nginx-ingress-controller
  5. kubectl apply --validate=false -f
    https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
  6. Atualize o issuer.yaml com a assinatura e o Service Principle ClientId
  7. Atualizar certificate.yaml para o endereço dns
  8. Atualize ingress.yaml com informações de domínio etc.
  9. Faça a versão Base64 do Service Principal Secret: echo | openssl
    base64
  10. Atualize secure-dazuredns.yaml com o segredo

OU Kubernetes Azure Application Gateway

  1. Não funciona. bagunça completa

Configuração completa do Kubernetes

  1. kubectl apply -f
    https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
  2. Atualize o deploy-api com registro, keyvault, ambiente e
    chave de instrumentação
  3. Atualizar registro no deploy-portal e deploy-admin
  4. Atualizar valores em identity-binding.yaml (ClientId também é do
    identidade gerenciada acima)
  5. kubectl cria namespace XX
  6. kubectl config set-context --current --namespace=XX
  7. kubectl apply -k ./
  8. Verifique se o certificado está disponível: kubectl describe certificate XX-tls-secret

Sim, é realmente tão difícil. E não, não há uma maneira mais fácil no k8s. Seu
única outra opção é uma VM com um IP público e usar um RP na frente do seu
aplicativo. Você pode usar uma VM Linux e executar o docker nela e instalar o HAproxy e
seu aplicativo em um contêiner docker com um único arquivo de composição do docker bastante
facilmente.

Caso contrário, você está ferrado até que eles comecem a lançar o kernel de
Windows 2004 (primavera de 2020) para Azure. (assumindo que chegou lá e
não é adiado até novembro)


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627302354 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7P74W4DK5RP2BKKI7LRRE365ANCNFSM4HDHMSDA
.

Os Websockets são provavelmente um bom substituto se você não se comprometeu com o gRPC e está focado nos Serviços de Aplicativo do Azure.

Depois de configurar o k8s, o Azure Devops é fácil. Você diz para compilar o contêiner docker e implantar no repositório do Azure com a tag build:id e, em seguida, para liberar, execute kubectl para informar para atualizar o contêiner do deploy com a tag correta para o id de compilação e ele será implementado de forma transparente a nova versão. A única coisa que fizemos foi criar uma ferramenta que faz migrações do EF antes de fazer isso para que você não acabe com várias réplicas k8s chamando o script de migração ao mesmo tempo.

Magic mate, obrigado, eu também gosto muito de Domain Driven Design, então eu
acho que posso adicionar AKS ao meu arsenal agora, mas quero que meus clientes se mudem para
serverless, não entendo por que a maioria das pessoas não parece querer seguir em frente
containers?

Em terça-feira, 12 de maio de 2020 às 23h05 James Hancock [email protected]
escrevi:

Websockets é provavelmente uma boa alternativa se você não se comprometeu com o gRPC
e estão focados nos Serviços de Aplicativo do Azure.

Depois de configurar o k8s, o Azure Devops é fácil. Você diz para construir
o contêiner docker e implante no repositório do Azure com o build:id
tag e, em seguida, para liberar, você executa o kubectl para informá-lo para atualizar o deploy
container com a tag certa para o id de compilação e ele apenas
lançar a nova versão de forma transparente. A única coisa que fizemos foi criar uma ferramenta
que faz migrações do EF antes de fazer isso para que você não acabe com
várias réplicas k8s chamando o script de migração ao mesmo tempo.


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627329964 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7MW7NJUS475HICIJTTRRFCQBANCNFSM4HDHMSDA
.

Os contêineres @acrigney são amplamente considerados uma tecnologia 'sem servidor'. É definitivamente discutível, mas não há uma definição estrita

@acrigney Existem muitas razões pelas quais as funções sem servidor, especialmente do Azure, não são desejáveis:

  1. O Azure Functions é uma pilha de porcaria frágil e fumegante que está sempre atrasada em patches de segurança com .net core.
  2. As funções do Azure são uma caixa preta e difíceis de depurar em muitos casos.
  3. Depois de começar a utilizá-lo totalmente, é mais caro do que outras opções quando você tem carga constante.
  4. Não há nada que você não possa fazer de outra forma que você possa fazer nas funções do Azure
  5. O K8s fornece um ambiente genérico conhecido que funciona da mesma forma em sua máquina de desenvolvimento local e em qualquer nuvem que você deseja criar. Quando você cria um recurso, ele funciona. Não importa se é o Azure ou a AWS o apoiando, ele funciona da mesma forma e consistentemente ao contrário do Azure Functions que obtivemos resultados diferentes no Azure do que localmente regularmente.
  6. K8s, em um sistema carregado custa menos que o Azure Functions.
  7. O K8s faz a implantação melhor do que as funções.
  8. Depois de começar a trabalhar com o código VS remotamente no docker, você não vai querer voltar. Mesmo ambiente mesma configuração que produção para 100% de consistência. (Usamos o k8s dentro do docker para desenvolver com o docker WSL2 e giramos o k8s no linux, que funciona maravilhosamente com o Windows 10 2004, mas o desenvolvimento completo no k8s está chegando em breve)
  9. O k8s dá a você toda a autonomia das VMs sem ter que gerenciar VMs, balanceamento de carga etc. Simplesmente funciona.
  10. Se você criar suas imagens docker corretamente usando o direcionamento de plataforma e a vinculação de IL, seus microsserviços no k8s serão tão pequenos quanto o mesmo nas funções do Azure, portanto, não haverá problemas de dimensionamento.

Isso é apenas uma pequena lista. As funções do Azure são ótimas em teoria, então você começa a bater a cabeça na parede com ela e descobre que não vale muito a pena.

até que eles comecem a distribuir o kernel do Windows 2004 (primavera de 2020) para o Azure.

O trabalho necessário para o IIS ainda está em andamento e não está disponível na versão 2004.

@Tratcher Uau. Apenas ai. Portanto, mais de um ano terá se passado com o .net core suportando gRPC e o Azure não tendo uma maneira viável para a grande maioria dos desenvolvedores do mundo usá-lo.

A MS precisa criar serviços de aplicativos baseados em docker verdadeiros que usam proxy nginx ou ha e não IIS para RP. Isso é loucura.

Realmente amigo, acho que isso está esticando, com certeza o AKS pode escalar, mas
especialmente com o acoplamento de mensagens necessário para executar vários
contêineres para um projeto grande eu dificilmente consideraria contêineres em
mantendo os ideais da tecnologia sem servidor. Eu posso facilmente conectar e reproduzir qualquer
microsserviços de tecnologia de back-end com servidores e funções de aplicativos, mas eu teria
essa agilidade com containers?

Em terça-feira, 12 de maio de 2020 às 23h31 onionhammer [email protected]
escrevi:

@acrigney https://github.com/acrigney containers são bastante amplos
considerada uma tecnologia 'serverless'


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627347120 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7PPWZ7MPIETCXPEFYDRRFFUNANCNFSM4HDHMSDA
.

@acrigney Absolutamente você faria. E você também não teria um inferno de dependência que é o Azure Functions. (e você pode usar facilmente o host do Azure Function em contêineres e até k8s, se desejar)

@acrigney Você está tentando expor o gRPC a outros microsserviços em execução no serviço de aplicativo? Como é a sua topologia?

Valeu amigo mas acho que você não teria nenhuma dependência infernal ou apertada
acoplamento com funções. Eu faço microsserviços com estado usando o aplicativo DDD
serviços com serviços de aplicativo do Azure e faço microsserviços sem estado com
Serviços de aplicativo DDD em funções do Azure. Os serviços do aplicativo DDD expõem
DTOs e usar os objetos de domínio e os outros serviços do aplicativo podem observar o
eventos disparados por esses objetos de domínio. Eu só não preciso de recipientes e uma vez
você construir um contêiner, ele terá muito código duplicado que
seria necessário em outros recipientes.

Na quarta-feira, 13 de maio de 2020 às 00h09 James Hancock [email protected]
escrevi:

@acrigney https://github.com/acrigney Absolutamente você faria. E você
também não teria o inferno de dependência que é o Azure Functions. (e você pode
use facilmente o host do Azure Function em contêineres e até k8s, se desejar)


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627369635 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7PQLO2K4RVWBQRGQS3RRFKCZANCNFSM4HDHMSDA
.

O aviso it-does-not-run-on-IIS deve ser colocado no topo da página usando uma tag <marquee> : https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

É realmente inject profanity here se você já fez protótipos, criou arquivos de protótipos, configurou seu servidor, cliente, autenticação usando JWT e acabou de lançar toda a ideia para um cliente como esta-é-a-melhor-próxima-coisa- since-sliced-bread para descobrir que não podemos usá-lo em produção porque estamos executando no IIS. :(

até que eles comecem a distribuir o kernel do Windows 2004 (primavera de 2020) para o Azure.

O trabalho necessário para o IIS ainda está em andamento e não está disponível na versão 2004.

Existe um eta / roteiro?

O aviso it-does-not-run-on-IIS deve ser colocado no topo da página usando uma tag <marquee> : https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

Você está certo, eu arquivei https://github.com/dotnet/AspNetCore.Docs/issues/18336 para esclarecer.

Existe um eta / roteiro?

Não, há muitas partes móveis para fornecer uma estimativa confiável.

Alguém tem alguma documentação de como configurar o nginx com grpc e kestrel?

Olá a todos, podemos redirecionar algumas das solicitações de gRPC na voz do usuário do AppService https://feedback.azure.com/forums/169385-web-apps?

Pergunta rápida: o suporte para o IIS e o Serviço de Aplicativo do Azure é acoplado ou eles podem/serão fornecidos separadamente?

Obrigado galera!

Eles são um pouco acoplados - a entrada do Serviço de Aplicativo do Azure e a hospedagem do Windows dependem do IIS, portanto, obter suporte para o IIS é um pré-requisito.

Em seguida, o Serviço de Aplicativo precisa ser implantado com base em uma compilação que tenha essas correções, portanto, o Serviço de Aplicativo virá após o suporte ao IIS.

Pergunta rápida: implantei o servidor gRPC no IIS (10.0) e agora estou recebendo o erro "Status(StatusCode=Cancelled, Detail=\"Nenhum grpc-status encontrado na resposta.\")". Eu usei o projeto WebApi como cliente gRPC. Alguém pode me ajudar?

Pergunta rápida: implantei o servidor gRPC no IIS (10.0) e agora estou recebendo o erro "Status(StatusCode=Cancelled, Detail="No grpc-status encontrado na resposta.")". Eu usei o projeto WebApi como cliente gRPC. Alguém pode me ajudar?

Não pode ser feito, o gRCP não é compatível com o IIS.

@lumogox @Dhananjay48 Nota: O GRPC-web é suportado pelo IIS e você perde apenas o streaming do cliente na maior parte. Então, isso é um trabalho em torno, embora não seja ótimo.

Caso contrário, de acordo com o que estou vendo, estamos esperando até pelo menos dezembro antes que isso seja corrigido no IIS, então saia e use outra coisa como nginx como proxy reverso.

Se você deseja apenas implantar o GRPC no Azure App Service, pode fazê-lo agora com um contêiner do Linux

@EdiWang No momento, isso não é compatível com o Serviço de Aplicativo para Linux. No momento, estamos trabalhando com o Serviço de Aplicativo para habilitar isso, mas não tenho ETA para compartilhar

Isso ocorre porque ainda há HTTP.sys na frente do webapp, mesmo sendo um contêiner docker rodando no Linux?

É meu entendimento que todos os serviços de aplicativos são proxy reversos por iis. Portanto, eles não funcionarão até que isso seja corrigido.

Apenas algo com um IP público ou rped por ha ou nginx etc (Linux) funcionará. Kubernetes com nginx ou ha funcionam bem como exemplo, mas o gateway de aplicativo como entrada não.

É meu entendimento que todos os serviços de aplicativos são proxy reversos por iis. Portanto, eles não funcionarão até que isso seja corrigido.

Apenas algo com um IP público ou rped por ha ou nginx etc (Linux) funcionará. Kubernetes com nginx ou ha funcionam bem como exemplo, mas o gateway de aplicativo como entrada não.

Também é meu entendimento. Na verdade, acabei aqui porque li se todos os serviços de aplicativos são liderados por um IIS. Porque nos documentos aqui: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse- proxy - ele nos aconselha a instalar um proxy reverso na frente do kestrel se você for expor o kestrel à Internet :) Eu sei que existe um IIS ao executar no Windows, mas não consigo encontrar nenhum para validar esse HTTP.sys ou IIS também está na frente ao executar o docker em um serviço de aplicativo. Este tópico é o mais próximo que eu já cheguei. O engraçado é que estou assinando este tópico porque também sou bastante interessante em gPRC :)

Posso confirmar que o iis também oferece serviços de aplicativos baseados em contêiner, incluindo os do Linux.

Suas únicas opções são VMS onde você fez o rp você mesmo ou aks.

@davidfowl AppService User Voice não recebeu muita atenção.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Poderia ser este o motivo da implementação lenta? Como você vê este problema, acho que o suporte gRPC é importante.

Sim, especialmente porque também não consegui que os websockets funcionassem e estou
preocupado com o custo dos contêineres, pois teria que correr muito.

Em sex, 12 de junho de 2020 às 21:58 Takekazu Omi [email protected]
escrevi:

@davidfowl AppService User Voice não recebeu muita atenção.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Poderia ser este o motivo da implementação lenta? Como você vê isso
Problema, acho que o suporte gRPC é importante.


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-643232429 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7L4452ZISXIPNAXWYLRWIKADANCNFSM4HDHMSDA
.

Adicionar a solicitação ainda é muito importante.

@davidfowl Isso é muito mais fácil falar do que fazer. Tente fazer login no site com sua conta microsoft com nova borda. Abre uma nova janela e não faz nada. Tente fazer login com meu e-mail, bem, esqueci a senha, o e-mail da senha vai para o lixo eletrônico para um endereço de e-mail @outlook.com. Altere-o, faça login e nenhum gerenciador de senhas solicita que armazene a senha, etc.

Apenas UAU ruim. Eu acho que a equipe do Azure não está recebendo bons comentários como resultado. Espero que você possa encaminhar isso para as pessoas certas para consertar essa bagunça.

Talvez ajude alguém hospedar grpc para iis.
Aqui está um exemplo de como trabalhar o grpcweb Blazor WebAssembly com a abordagem gRPC-Web code-first que hospeda o iis via publicação remota como um encanto. Eu suponho que poderia funcionar de outras maneiras também. Eu não fiz nenhum teste de desempenho, então não posso comentar sobre isso, mas acho que pelo menos funcionaria bem em qualquer solução de tamanho médio.
Aqui está o link para o github
Ele também usa protobuf-net.Grpc.AspNetCore que não é uma declaração de protobuff chata. É tão bom quando você pode ir diretamente para a implementação ou adicionar métodos extras para solicitação/resposta.

Oi pessoal, eu preciso definir um tipo de array de string dataType na mensagem Grpc. não tenho certeza de como fazer. agora eu estou fazendo isso como um
string repetida Nome = 1,
aqui eu preciso de campo de nome como tipo de matriz de string. Mas está mostrando erro que é, o campo é do tipo readonly ao vincular dados nele.

@ Dhananjay48 Isso não é StackOverflow. Por favor, faça sua pergunta lá.
Vamos manter esse problema para coisas relacionadas ao gRPC no Serviço de Aplicativo.

É meu entendimento que todos os serviços de aplicativos são proxy reversos por iis. Portanto, eles não funcionarão até que isso seja corrigido.

Apenas algo com um IP público ou rped por ha ou nginx etc (Linux) funcionará. Kubernetes com nginx ou ha funcionam bem como exemplo, mas o gateway de aplicativo como entrada não.

O 'Kestrel usado em uma configuração de proxy reverso' com nginx pode ser uma solução? https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when -to-use-kestrel-with-a-reverse-proxy'

Coloquei a sugestão para @JamesNK nos documentos, para incluir um exemplo de solução de hospedagem:
https://github.com/dotnet/AspNetCore.Docs/issues/18953

https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-available/?utm_source=vs_developer_news&utm_medium=referral
Foi anunciado recentemente e pode ser implantado no Azure.

Em qui, 25 de junho de 2020 às 13:48 OzBob [email protected] escreveu:

É meu entendimento que todos os serviços de aplicativos são proxy reversos por iis.
Portanto, eles não funcionarão até que isso seja corrigido.

Apenas algo com um IP público ou rped por ha ou nginx etc (Linux)
trabalhar. Kubernetes com nginx ou ha funcionam bem como exemplo, mas o aplicativo
gateway, pois o ingresso não.

Poderia 'Kestrel usado em uma configuração de proxy reverso' com nginx, ser um
solução?
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when -to-use-kestrel-with-a-reverse-proxy
'

Coloquei a sugestão para @JamesNK https://github.com/JamesNK no
docs, para incluir um exemplo de solução de hospedagem:
dotnet/AspNetCore.Docs#18953
https://github.com/dotnet/AspNetCore.Docs/issues/18953


Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-649198280 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABCSC7KBUALMCXDGUS2NV7LRYLCKNANCNFSM4HDHMSDA
.

@acrigney e mencionado aqui no Ch9 também: https://youtu.be/T4RD3W2MgHQ?list=TLPQMjUwNjIwMjB6we-UTBA_VA&t=288 por @shirhatti (https://twitter.com/sshirhatti)

Eu só queria dizer que estamos trabalhando com a equipe do Windows para começar a habilitar esses cenários. Aqui está uma postagem de blog da equipe do Windows sobre isso, e https://github.com/dotnet/aspnetcore/pull/24120 tem alguns dos trabalhos de acompanhamento para expor coisas no ASP.NET Core.

Ainda vai demorar um pouco para tudo isso chegar, mas é bom poder relatar que pelo menos estamos progredindo.

Obrigado pelo acompanhamento, muito útil e apreciado!!

Quarta-feira, 22 de julho de 2020 às 11h17 Kevin Pilch [email protected]
escrevi:

Eu só queria dizer que estamos trabalhando com a equipe do Windows para
comece a habilitar esses cenários. Aqui está uma postagem no blog
https://aka.ms/grpcblogpost da equipe do Windows sobre isso e #24120
https://github.com/dotnet/aspnetcore/pull/24120 tem alguns dos
trabalho de acompanhamento para expor coisas no ASP.NET Core.

Ainda vai demorar um pouco até tudo isso chegar, mas é bom poder
para informar que estamos fazendo progressos, pelo menos.


Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-662547810 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAUKMASPCV3UE47OJZ6TIMDR44GKTANCNFSM4HDHMSDA
.

Eu só queria dizer que estamos trabalhando com a equipe do Windows para começar a habilitar esses cenários. Aqui está uma postagem de blog da equipe do Windows sobre isso, e o nº 24120 tem alguns dos trabalhos de acompanhamento para expor coisas no ASP.NET Core.

Ainda vai demorar um pouco para tudo isso chegar, mas é bom poder relatar que pelo menos estamos progredindo.

Observe que isso já foi integrado ao servidor HttpSys da AspNetCore nas visualizações 5.0. Por favor, tente. Se pudermos identificar quaisquer problemas nessa camada agora, teremos menos problemas quando adicionarmos a camada IIS sobre ela.

Isso significa que posso fazer o gRPC completo no IIS se usar o ASP.NET Core visando a visualização do .NET 5?

Ainda não. Há um monte de partes diferentes aqui:

  1. Módulo HTTP.sys no Windows
  2. Suporte ASP.NET Core para isso em HttpSysServer
  3. Suporte IIS para isso no Windows
  4. Suporte ASP.NET Core para isso no IIS
  5. Suporte para isso no proxy reverso que o Serviço de Aplicativo do Azure usa
  6. Serviço de Aplicativo do Azure implantando uma compilação do Windows com 1 e 3.
  7. Serviço de Aplicativo do Azure implantando uma compilação do proxy reverso de 5
  8. Serviço de Aplicativo do Azure implantando uma compilação do ASP.NET Core com 2 e 4.

O que o @Tratcher estava dizendo é que 1 e 2 estão disponíveis nas visualizações do .NET 5. Estamos trabalhando em 3 e 4 agora, mas tentar 1 e 2 nos ajudará a dar feedback sobre se isso funcionará, já que o Http. sys suporte é uma base do suporte do IIS.

Deveria ter dito, 1 está disponível nas visualizações do Windows e 2 está disponível nas visualizações do .NET 5.

A visualização do Windows Insider está disponível com http.sys atualizado
https://techcommunity.microsoft.com/t5/networking-blog/windows-server-insiders-getting-grpc-support-in-http-sys/ba-p/1534273

Alguma ideia se isso estará disponível como uma atualização do Windows para o Windows Server 2016/2019?

E o suporte ao IIS agora está nas versões mais recentes do Windows Insider anunciadas aqui .

Estamos investigando se será possível fazer backport dessas mudanças para a compilação de manutenção, mas isso ainda está no ar. A partir de agora, o único plano de registro é que eles estarão em lançamentos futuros.

Esta página foi útil?
0 / 5 - 0 avaliações