Hola @moodya , ¿revisó los documentos en https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio ?

Si tiene algún problema, háganoslo saber y podemos investigar.

Sí, ya he creado un servicio que se ejecuta como un servicio alojado genérico. Lo transfirí a la nueva plantilla asp net core 3 y lo hice funcionar en un kestrel autohospedado, pero actualmente estoy buscando alojarlo detrás de iis y, con suerte, implementarlo como un servicio de aplicaciones en Azure. No puedo hacer que el anterior (iis) funcione.

Obtenga Outlook para Android https://aka.ms/ghei36

De: Eilon Lipton [email protected]
Enviado: miércoles, 3 de abril de 2019 6:06:17 p. m.
Para: aspnet/AspNetCore
Cc: moodya; Mencionar
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

Hola @moodya https://github.com/moodya , ¿revisó los documentos en https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=visual-studio ?

Si tiene algún problema, háganoslo saber y podemos investigar.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 o silencie el hilo https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

No puedo encontrar ningún ejemplo de cómo hacer esto, por lo que tal vez aún no sea compatible.

Obtenga Outlook para Android https://aka.ms/ghei36

De: Alain Moody [email protected]
Enviado: miércoles, 3 de abril de 2019 6:11:06 p. m.
Para: aspnet/AspNetCore; aspnet/AspNetCore
CC: Mención
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

Sí, ya he creado un servicio que se ejecuta como un servicio alojado genérico. Lo transfirí a la nueva plantilla asp net core 3 y lo hice funcionar en un kestrel autohospedado, pero actualmente estoy buscando alojarlo detrás de iis y, con suerte, implementarlo como un servicio de aplicaciones en Azure. No puedo hacer que el anterior (iis) funcione.

Obtenga Outlook para Android https://aka.ms/ghei36

De: Eilon Lipton [email protected]
Enviado: miércoles, 3 de abril de 2019 6:06:17 p. m.
Para: aspnet/AspNetCore
Cc: moodya; Mencionar
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

Hola @moodya https://github.com/moodya , ¿revisó los documentos en https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=visual-studio ?

Si tiene algún problema, háganoslo saber y podemos investigar.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 o silencie el hilo https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

@shirhatti : ¿alguna idea sobre esto?

No se puede hospedar gRPC en IIS/Azure App Service.
La implementación HTTP/2 de Http.Sys no admite los encabezados finales de respuesta HTTP en los que se basa gRPC.

Gracias por la pronta respuesta. ¿Cómo recomendaría hospedar un servicio grpc en un escenario de producción en este momento? Además, ¿conoce alguna escala de tiempo en la que un servicio grpc se pueda alojar en el servicio iis / app?

Obtenga Outlook para Android https://aka.ms/ghei36

De: Sourabh Shirhatti [email protected]
Enviado: miércoles, 3 de abril de 2019 7:13:23 p. m.
Para: aspnet/AspNetCore
Cc: moodya; Mencionar
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

No se puede hospedar gRPC en IIS/Azure App Service.
La implementación HTTP/2 de Http.Sys no admite los encabezados finales de respuesta HTTP en los que se basa gRPC.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479600486 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AlUvPNHH4- HhNsSAtugTw0MzzNco6c76ks5vdO9DgaJpZM4cZ2SG .

El enfoque recomendado es hospedar su servicio gRPC en AKS.

En cuanto a los plazos de App Service, me remito a @stefsch

Gracias por volver a mí. En términos de aks Vs service fabric en términos de alojamiento del servicio grpc, ¿aks es la mejor opción? Si es así, ¿por qué?

Obtenga Outlook para Android https://aka.ms/ghei36

De: Sourabh Shirhatti [email protected]
Enviado: lunes, 8 de abril de 2019 7:31:45 a. m.
Para: aspnet/AspNetCore
Cc: moodya; Mencionar
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

El enfoque recomendado es hospedar su servicio gRPC en AKS.

En cuanto a los plazos de App Service, me remito a @stefsch https://github.com/stefsch

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-480701227 o silencie el hilo https://github.com/notifications/unsubscribe-auth/AlUvPLwQW8HCp- YXsz6yNaK_RH7jbZzWks5veuJRgaJpZM4cZ2SG .

Actualmente estoy esperando problemas para hacer esto. Obtuve un servicio gRPC funcionando bien con aspnetcore 3 preview 3 y Kestrel. Pero aparece un error sobre los tráileres usando IIS cuando el servicio envía la respuesta (la solicitud es bien recibida):
gPRC error => 2 DESCONOCIDO: No se recibió ningún estado)
Error de Dotnet => "Los tráilers no son compatibles con esta respuesta" en Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(HttpResponse response, String trailerName, StringValues ​​trailerValues) en Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

Según los mensajes anteriores, no creo que iis admita alojar un servicio grpc

Obtenga Outlook para Android https://aka.ms/ghei36

De: notificaciones de [email protected]
Enviado: jueves, 25 de abril de 2019 10:57:42 a. m.
Para: aspnet/AspNetCore
Cc: moodya; Mencionar
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

Actualmente estoy esperando problemas para hacer esto. Obtuve un servicio gRPC funcionando bien con aspnetcore 3 preview 3 y Kestrel. Pero aparece un error sobre los tráileres usando IIS cuando el servicio envía la respuesta (la solicitud es bien recibida):
gPRC error => 2 DESCONOCIDO: No se recibió ningún estado)
Error de Dotnet => "Los tráilers no son compatibles con esta respuesta" en Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(HttpResponse response, String trailerName, StringValues ​​trailerValues) en Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486607635 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AJKS6PEAJ2UKKH2QIKNTCZDPSF6BNANCNFSM4HDHMSDA .

Después de este intercambio https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , parece que no es responsabilidad del servidor web manejar gRPC. gPRC usa HTTP/2, IIS admite HTTP/2, por lo que debe funcionar. Si no es así, es un error de IIS o, más posible, de dotnetcore.

De acuerdo con los chicos de Microsoft en los mensajes anteriores, iis no es compatible con los encabezados finales necesarios para alojar un servicio grpc. Esto significa que no puede alojar uno en iis o como un servicio de aplicaciones en este momento.

Obtenga Outlook para Android https://aka.ms/ghei36

De: notificaciones de [email protected]
Enviado: jueves, 25 de abril de 2019 11:39:08 a. m.
Para: aspnet/AspNetCore
Cc: moodya; Mencionar
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

Después de este intercambio https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , parece que no es responsabilidad del servidor web manejar gRPC. gPRC usa HTTP/2, IIS admite HTTP/2, por lo que debe funcionar. Si no es así, es un error de IIS o, más posible, de dotnetcore.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486620151 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AJKS6PBQO4427EYN67SI7A3PSGC4ZANCNFSM4HDHMSDA .

Gracias, me lo perdí y tiene sentido con mi problema.
@shirhatti, ¿ el soporte está planeado en la hoja de ruta?

Nosotros (IIS) estamos evaluando actualmente si se admitirán los tráileres de respuesta HTTP. No hay hojas de ruta/compromisos de los que pueda hablar todavía.

@shirhatti Teniendo en cuenta que gRPC parece ser una característica importante de .NET Core 3 (https://github.com/grpc/grpc-dotnet), sería una verdadera lástima si no se puede hospedar en IIS/App Service debido a tantos . Las aplicaciones web NET están alojadas en esos. Espero que la disponibilidad de esa característica en .NET Core ayude a impulsar su hoja de ruta.

Estoy totalmente de acuerdo con @jbrantly. gRPC se anuncia como una de las características principales de .NET Core 3.
Debe ser alojable en IIS/Azure App Services.
@shirhatti , considere agregar esto a la hoja de ruta

Yo tambien estoy de acuerdo.

Obtenga Outlook para Android https://aka.ms/ghei36

De: Tomasz Jagusz [email protected]
Enviado: viernes, 26 de abril de 2019 9:42:58 a. m.
Para: aspnet/AspNetCore
Cc: moodya; Mencionar
Asunto: Re: [aspnet/AspNetCore] ¿Aloja el servicio grpc en iis o como un servicio de aplicación? (#9020)

Estoy totalmente de acuerdo con @jbrantly https://github.com/jbrantly . gRPC se anuncia como una de las características principales de .NET Core 3.
Debe ser alojable en IIS/Azure App Services.
@shirhatti https://github.com/shirhatti , considere agregar esto a la hoja de ruta

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486977989 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AJKS6PENWT46GCJ7GQGEGPTPSK6BFANCNFSM4HDHMSDA .

No podría estar mas de acuerdo.

Lo estamos investigando. Requiere tanto cambios en el kernel de Windows como cambios en IIS.

@davidfowl , ¿será esto posible cuando se lance .NET Core 3?
La capacidad de alojar GRPC en App Services es un obstáculo para mí.

Pues es 29 de mayo de 2019 , y aún no hay señales de que esto vaya a ser posible. Estoy buscando alojar un servicio GRPC en IIS y agregar un certificado para usar HTTPS :(

No, no es posible en IIS, estamos trabajando para obtener cambios, pero será un proceso lento (ya que requiere una actualización de Windows).

Aproximadamente perdí unos 3 días... gracias iis

Hola @davidfowl
¿Cualquier actualización?

@davidfowl, ¿ hay alguna posibilidad de que esto se agregue antes de que se lance .NET Core 3.0? ¿O deberíamos esperar a 3.1 o 5.0?

No, ya que requiere cambios de Windows. No será parte de 3.0 y requerirá la última versión de Windows (cualquiera que sea en ese momento) para obtener estas características. No hay ETA

Hmm, estoy en medio de la planificación de una implementación de Service Fabric que utilizará servicios sin estado basados ​​en gRPC y actores confiables, además de dotnet core 3. ¿Esto me va a morder el trasero? Si alojo en SF, ¿supongo que usaré Kestrel en el núcleo? Tiempo de prototipo.

@oising mismo barco aquí - pero estamos rodando lentamente hacia contenedores k8s + linux, por lo que este tipo de ayuda nos empuja de todos modos.

Solo estoy haciendo esto porque he estado jugando con gRPC por un tiempo y finalmente quiero comenzar a adoptarlo en algunos de mis proyectos de clientes, así que estaba mirando los flujos de trabajo de implementación. Estoy un poco desanimado por la cantidad de gastos generales operativos que esto supondría implementar en producción con .net core.

También me tomó días darme cuenta de que IIS era el problema. Realmente buscando una solución. ¿Alguna solución?

@bingoo sin soporte de Windows e IIS No tiene suerte. Puede usar Service Fabric, pero no tengo experiencia con él. Espero que sea posible alojarlo en IIS o en Azure de forma sencilla.
Para los proyectos actuales, Grpc no es una opción para mí debido a este problema.

Sería bueno si esto fuera una gran advertencia audaz en los documentos...

El alojamiento IIS aún no es compatible. App Services usa Windows Server 2016 + IIS como backend de forma predeterminada, pero ahora también es compatible con Linux / Containers. Si solo desea implementar GRPC en Azure App Service, puede hacerlo ahora con un contenedor de Linux. Pero el plan App Service no se puede compartir con un plan de alojamiento de Windows. Tendrá que gastar dinero extra en un nuevo Plan de servicio de aplicaciones respaldado por Linux Container.

La mejor manera es usar AKS y luego usar Ambassador. Ambassador es una puerta de enlace api basada en Envoy que se ejecuta como un contenedor dentro de Kubernetes. Le permite usar proxy tanto en grpc como en grpc-web, p. browser al servidor grpc y también un cliente grpc, quizás ac# one a un servidor grpc. Si desea que frontend js reciba llamadas gRPC, necesita grpc web y un proxy porque los navegadores tampoco son compatibles con los encabezados finales de respuesta http2 correctamente. Grpc Web usa Envoy de forma predeterminada, por eso Ambassador es mejor.

Si solo desea implementar GRPC en Azure App Service, puede hacerlo ahora con un contenedor de Linux

@EdiWang Esto actualmente no es compatible con App Service para Linux. Actualmente estamos trabajando con App Service para habilitar esto, pero no tengo ninguna ETA para compartir

hola buena gente
Estoy un poco confundido, por lo que no podemos tener el servicio grpc en Azure.
Pero Azure en sí está usando grpc, el Protobuf de trabajador de lenguaje de Azure Functions.
https://github.com/Azure/azure-functions-language-worker-protobuf
¿O me estoy perdiendo algo aquí?
tratando de entender :confundido:

@GoranHalvarsson Puede tener servicios gRPC en Azure, pero todavía no puede ejecutarlos en Azure App Services.

@markrendle Gracias por responder. Entonces, ¿cómo puedo usar/configurar un servicio gRpc en Azure?

Sería bueno si esto fuera una gran advertencia audaz en los documentos...

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

@markrendle Gracias por responder. Entonces, ¿cómo puedo usar/configurar un servicio gRpc en Azure?

Al no usar IIS, lo que significa usar Service Fabric o AKS, ambos usan Kestrel sin formato. SF y AKS tienen características diferentes. Busque en Google "Service Fabric vs AKS" y tome un gran café.

He creado una guía paso a paso para crear un servicio de prueba e implementación grpc usando .NET Core 3.0
https://github.com/rupeshtech/k8s-grpc-dotntecore

Acabo de investigar este problema, por lo que aún no he probado nada; pero ¿alguien ha intentado usar Azure Web App para (Container https://azure.microsoft.com/en-us/services/app-service/containers/)?

Estoy ejecutando un montón de microservicios basados ​​en Docker en Azure App Services y he tenido muy pocos problemas y me han permitido solucionar otras características limitantes de la oferta de OOB App Service.

@ikemtz gRPC funciona cuando se usa kestral (es decir, cuando se ejecuta en contenedores).

@rupeshtech Gracias, pero su artículo no está relacionado con el problema.

Este problema es para hospedar gRPC (o cualquier aplicación que use encabezados finales) en IIS o Azure App Service.

Sería bueno si esto fuera una gran advertencia audaz en los documentos...

aspnet/AspNetCore.Docs#14684

Esto ya está implementado .

@ikemtz Intenté ejecutar una prueba básica para usar gRPC en un contenedor de Linux que se ejecuta en una aplicación web de Azure para contenedores y no funcionó para mí. No se pudo encontrar ningún error informado en ninguna parte, pero el contenedor ni siquiera respondía a los pings HTTP.
Es una pena. No estoy preparado para cambiarme a AKS solo para obtener esta funcionalidad, así que supongo que me quedaré con los buenos servicios HTTP antiguos por ahora.

@searus si usa una máquina virtual en su lugar (que se ejecuta en azul)

@GoranHalvarsson No estoy preparado para pasar de PaaS a IaaS solo para hacer uso de esta tecnología. Esperaré hasta que Azure App Service pueda admitir esto.

@davidfowl ¿ Alguna hoja de ruta sobre esto?

La implementación en un contenedor con Kestral está bien, pero es fácil de decir
usando Lets Encrypt en IIS o un servicio de aplicaciones que realmente me está frenando.
Si hay alguna guía concisa sobre cómo ejecutar un dominio personalizado con Lets
cifrar en kestrel en un contenedor y luego voy a saltar primero a gRPC
de lo contrario, es muy difícil justificar los gastos generales de crear algunos personalizados
implementación solo para acomodar la nueva pila.

El miércoles, 16 de octubre de 2019 a las 6:46 a. m. Russell Seamer [email protected]
escribió:

@GoranHalvarsson https://github.com/GoranHalvarsson No estoy preparado
pasar de PaaS a IaaS solo para hacer uso de esta tecnología. yo solo
espere hasta que Azure App Service pueda admitir esto.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/AspNetCore/issues/9020?email_source=notifications&email_token=AMNAZYUWLYLGC5ZGB4GAFITQO2TCFA5CNFSM4HDHMSDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLFDDI#issuecomment-54252
o darse de baja
https://github.com/notifications/unsubscribe-auth/AMNAZYTKUYYBWKSW6AMQDHTQO2TCFANCNFSM4HDHMSDA
.

Con esto, Azure Functions y cualquier otra cosa que se encuentre por encima de App Service realmente no puede usar gRPC y HTTP/2. Una línea de tiempo estaría bien, incluso para vistas previas públicas o privadas.

Actualmente estamos trabajando en los cambios en http.sys. Después de eso, debemos reaccionar a esos cambios en IIS y ARR. Luego, debemos actualizar la versión de Windows que se ejecuta en el servicio de aplicaciones para aprovechar esos cambios en IIS.

El trabajo ha dicho, pero es realmente difícil estimar cuánto tiempo les llevará a los clientes obtenerlo. Te mantendremos informado a medida que avancen las cosas.

Siento que esto es algo que lamentablemente no me sorprende (que implementar una nueva funcionalidad http requiere actualizaciones del kernel). Obviamente, IIS no existe en Linux/macosx, pero me sorprendería si agregar soporte para grpc a otros servidores para otros sistemas operativos... necesita mucho en cuanto a la actualización del kernel.

Tal vez este sea un argumento/ejemplo decente para desacoplar... Solo digo

Siento que esto es algo que lamentablemente no me sorprende (que implementar una nueva funcionalidad http requiere actualizaciones del kernel). Obviamente, IIS no existe en Linux/macosx, pero me sorprendería si agregar soporte para grpc a otros servidores para otros sistemas operativos... necesita mucho en cuanto a la actualización del kernel.

Tal vez este sea un argumento/ejemplo decente para desacoplar... Solo digo

Estoy de acuerdo. Esto probablemente tenga algo que ver con IIS ejecutando algún protocolo de bajo nivel que está vinculado directamente al kernel. Parece extraño, pero al menos tenemos la confirmación de que se está trabajando en esto y que la adopción no es completamente cielo azul.

¿Recuerdas cuando tuviste que actualizar a Windows 8 para obtener compatibilidad con WebSocket? yo tambien 😄

¡Sí, lo recordamos! Aquí está la primicia: gRPC se lanza en .NET-Core y usamos Azure App Services, por lo que es importante tener alguna opción, al menos para probar, lo antes posible. ¿Alguien puede decirnos cuándo ocurrirá esta sincronización con las funcionalidades lanzadas de .NET-Core en Azure App Services? O una solución factible. Gracias

Gracias por contactarnos. Debido a que no hay actividad en este tema, lo cerraremos en un esfuerzo por mantener limpio nuestro trabajo pendiente. Si cree que existe una inquietud relacionada con el marco ASP.NET Core, que aún no se ha abordado, envíe un nuevo problema.

@anurse , ¿cómo mantenemos este problema abierto?

Se puso en Discusiones y se etiquetó como pregunta. Reabierto.

¿Hay alguna ETA en esto todavía?

¿Existen alternativas viables para que gRPC funcione en un entorno de producción?
Revisé algunas cosas y parece que alojarlo en AKS es una opción, solo quiero asegurarme de que no estamos haciendo nada que no nos ayude a resolver nuestro problema.

Actualmente hemos estado tratando de ejecutar algún tipo de entorno de producción para estos proyectos:
Proyecto IdentityServer que habla con una API sobre gRPC
5 portales web que hablan con una API sobre gRPC
La API que se comunica con un bot de Discord (ASP.NET Core) a través de gRPC.

Intentamos alojarlos en un VPS, pero no sé si realmente podemos alojarlos en un entorno de producción simplemente usando Kestrel si queremos que todas estas aplicaciones vivan en el mismo VPS.

¿Alguien tiene una opción para nosotros para que podamos tener múltiples dominios (1 dominio, el resto son subdominios) con 1 dirección IP en 1 VPS ejecutando todos los proyectos usando solo Kestrel (debido a las limitaciones en IIS, Http.Sys, ventanas).

(O cualquier otro método que nos permita alojar todo esto lo antes posible)

¡Gracias por adelantado!

(EDITAR)

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

(EDITAR 2)
También intentamos contactar a @davidfowl sobre esto en twitter.
https://twitter.com/DapperDino4/status/1204119195765682177 y
https://twitter.com/DapperDino4/status/1204119695344971778

¿Hay alguna ETA en esto todavía?

Agregando @shirhatti y @Tratcher que han estado trabajando en esto.

El momento de esto es difícil de precisar en este momento. IIS es un componente de Windows y depende de http.sys, que también es un componente de Windows. Ni IIS ni http.sys tienen suficientes funciones HTTP/2 para admitir gRPC. Hemos estado trabajando muy de cerca con esos equipos para implementar los cambios, y todos están bien encaminados para una próxima versión, pero no estarán disponibles hasta que se publique una versión de Windows Server con los cambios apropiados.

@JamesNK , ¿puede hablar sobre la disponibilidad de alternativas como gRPC-web?

Contexto para personas que no saben qué es gRPC-Web: https://grpc.io/blog/state-of-grpc-web/. Debido a que usa HTTP/1.1, no se le aplicarán las restricciones de Azure App Service. La desventaja es que no hay beneficios de HTTP/2 (multiplexación, compresión de encabezado) y no hay transmisión de cliente o bidireccional.

El proxy inverso gRPC-Web envoy ya está disponible, pero no es fácil de configurar. Y no hay ningún cliente .NET gRPC-Web.

El equipo de ASP.NET Core aún no ha decidido si nos vamos a comprometer a admitir oficialmente gRPC-Web. Estoy viendo gRPC-Web ahora y cómo podría verse en .NET Core. En un par de semanas puedo decir más, y tal vez tener una vista previa experimental para que la gente pruebe en enero.

Dado que IIS no es compatible con esto, ¿se puede alojar el servicio netcore gRPC detrás de Nginx?

@Dennis-Petrov Hago exactamente esto. Seguí este documento https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-3.1 y gRPC funciona muy bien

¿Puedo hacer una pregunta estúpida: por qué esto no funciona en un servicio de aplicaciones de Azure en un plan de servicio de aplicaciones de Linux?

¿IIS también está involucrado en eso en algún lugar de la tubería?

@searus Hay capas comunes entre la interfaz y los servicios de aplicaciones, independientemente de Linux/Windows. Es decir, actualmente la interfaz de App Service recibe las conexiones HTTP/2, y luego las conexiones internas se envían como HTTP "antiguo" a los trabajadores individuales del servicio de aplicaciones. Estoy seguro de que está en proceso para admitir completamente gRPC, pero requiere un poco de esfuerzo ya que los componentes internos deben actualizarse, probarse y publicarse.

Gracias @devlead.
Yo (quizás ingenuamente) pensé que un plan de servicio de aplicaciones de Linux era todo Linux en todo momento.
Aprecio completamente el esfuerzo involucrado aquí, y gracias por tomarse el tiempo para explicar.

Estoy seguro de que está en proceso para admitir completamente gRPC

Definitivamente está en proceso. Estamos trabajando activamente en ello, pero no podemos garantizar un cronograma (hay varios equipos independientes que deben coordinarse aquí). @devlead tiene razón sobre la compatibilidad con Linux de Azure App Service. El proxy de front-end ejecuta IIS. Admite la recepción de HTTP/2 del cliente, pero cuando envía tráfico a su aplicación, cambia a HTTP/1.1. Esto estaba bien (aunque no era lo ideal) para aplicaciones normales, pero dado que gRPC requiere funciones HTTP/2, no es adecuado para ellas.

Sí, ya he creado un servicio que se ejecuta como un servicio alojado genérico. Lo transfirí a la nueva plantilla asp net core 3 y lo hice funcionar en un kestrel autohospedado, pero actualmente estoy buscando alojarlo detrás de iis y, con suerte, implementarlo como un servicio de aplicaciones en Azure. No puedo hacer que el anterior (iis) funcione.

@moodya , ¿puedes compartir con nosotros cómo lo hiciste?

Sí, ya he creado un servicio que se ejecuta como un servicio alojado genérico. Lo transfirí a la nueva plantilla asp net core 3 y lo hice funcionar en un kestrel autohospedado, pero actualmente estoy buscando alojarlo detrás de iis y, con suerte, implementarlo como un servicio de aplicaciones en Azure. No puedo hacer que el anterior (iis) funcione.

@moodya , ¿puedes compartir con nosotros cómo lo hiciste?

La plantilla de gRPC es Kestrel autohospedado de forma predeterminada. No funcionará en el servicio de aplicaciones por las razones descritas en este hilo.

Si bien no se puede alojar en el servicio de aplicaciones, digamos que alojamos el servicio grpc en aks, ¿hay algún problema para llamar a grpc desde el servicio de aplicaciones? ¿Trabajará el cliente grpc al menos en el servicio de aplicaciones?

Si bien no se puede alojar en el servicio de aplicaciones, digamos que alojamos el servicio grpc en aks, ¿hay algún problema para llamar a grpc desde el servicio de aplicaciones? ¿Trabajará el cliente grpc al menos en el servicio de aplicaciones?

Sí, los clientes deben trabajar. La limitación es solo para las solicitudes entrantes, no para las salientes.

Tal vez una pregunta estúpida, pero ¿por qué funciona si estoy ejecutando el servicio gRPC en Debug con IIS Express? Por ejemplo, tengo una aplicación web (Razor Pages, .net core 3.1) que realiza llamadas a un servicio gRPC [actualizado desde una aplicación framework mvc que habla con un servicio wcf, si a alguien le importa]. Si depuro ambos en mi estación de trabajo, con el servicio gRPC en IIS Express, la aplicación web puede comunicarse con el servicio sin problemas. Debido al comportamiento de proxy @anurse descrito anteriormente, cuando el servicio está alojado en IIS, obtengo la excepción de que gRPC requiere HTTP/2. ¿IIS Express representa a Kestrel de manera diferente a IIS?

Además, tal vez no sea el lugar para esto, pero me gustaría pedir humildemente que la página a continuación reciba una pequeña explicación del comportamiento de proxy de IIS/App Service. Yo (quizás tontamente) pasé un día entero tratando de burlar a IIS porque pensé que podría forzarlo a usar un proxy en HTTP/2 si la aplicación se estaba quedando sin proceso en Kestrel https://docs.microsoft.com/en- us/aspnet/core/grpc/aspnetcore?view=aspnetcore-3.1&tabs=visual-studio#integration -with-aspnet-core-apis

IIS Express no debería funcionar por las mismas razones por las que IIS no lo hace.

@Tratcher Ah, sí, tienes razón. Estaba ejecutando el servicio gRPC como autohospedado, no IIS Express. ¡Gracias!

¿Alguien tiene un tutorial sobre cómo hacer que esto funcione en AKS? (puntos de bonificación por depurar con código vs en aks localmente sin tener que reconstruir contenedores para que tengamos toda la pila con .net core dev, hasta implementar en azure usando azure devops y aks).

Lo que es más importante, ¿qué está usando en AKS para enviar el tráfico web a los pods de AKS sin tener que usar ngix en el pod (es decir, el equilibrador de carga azul o algo así)?

Si bien no se puede alojar en el servicio de aplicaciones, digamos que alojamos el servicio grpc en aks, ¿hay algún problema para llamar a grpc desde el servicio de aplicaciones? ¿Trabajará el cliente grpc al menos en el servicio de aplicaciones?

Sí, los clientes deben trabajar. La limitación es solo para las solicitudes entrantes, no para las salientes.

Desafortunadamente, este no parece ser el caso con la aplicación web basada en .Net Core 3.1 que llama a un servicio grpc (en este caso, el código Pyhton que se ejecuta en una VM) cuando está alojado en Azure Web Apps: se agota el tiempo de espera. Cuando se ejecuta exactamente el mismo código desde localhost, la llamada pasa (mismo servicio VM).

@lyulyok , ¿puede recopilar diagnósticos y abrir un problema separado? No hay problemas conocidos con el cliente aquí.

¿Alguien tiene un tutorial sobre cómo hacer que esto funcione en AKS?

Abra un nuevo problema para discutir esto o pregunte en Stack Overflow . Mantengamos este hilo en el tema, especialmente porque hay muchas personas interesadas en el estado de gRPC en IIS y HTTP.sys y cada comentario hace ping a todas las personas que están en él. Voy a ocultar los comentarios fuera de tema, no dude en publicar nuevos problemas si tiene más preguntas.

Sí, ya he creado un servicio que se ejecuta como un servicio alojado genérico. Lo transfirí a la nueva plantilla asp net core 3 y lo hice funcionar en un kestrel autohospedado, pero actualmente estoy buscando alojarlo detrás de iis y, con suerte, implementarlo como un servicio de aplicaciones en Azure. No puedo hacer que el anterior (iis) funcione.

El soporte experimental para gRPC-Web en .NET ya está disponible. gRPC-Web funciona con HTTP/1.1 y HTTP/2, y se ejecuta en IIS y Azure App Service.

Continuamos trabajando para ejecutar HTTP/2 gRPC en Azure App Service, pero gRPC-Web es algo que puede usar hoy . Cuando se complete el trabajo para admitir HTTP/2 en IIS y Azure App Service, será un proceso simple cambiar una aplicación .NET de gRPC-Web a HTTP/2 gRPC.

Publicación de blog: https://devblogs.microsoft.com/aspnet/grpc-web-experiment
Documentación: https://docs.microsoft.com/aspnet/core/grpc/browser

Tengo un cliente grpc ejecutándose en el servicio de aplicaciones y el servicio funciona bien en aks, en caso de que alguien más quiera intentarlo también

@andrew-vdb ¿Puedes publicar la configuración, por favor?

Hola @JamesNK ,
relacionado con su comentario https://github.com/dotnet/aspnetcore/issues/9020#issuecomment -579597202 y con el hecho de que gRpc-Web actualmente parece ser _un proyecto experimental, no un producto comprometido_.

• ¿Necesito gRpc-Web para implementar en IIS? De lo contrario, ¿no es posible en absoluto?
• ¿Tiene un ETA sobre cuándo será posible implementar en IIS sin gRpc-Web?
• ¿Tiene una ETA cuando gRpc-Web será oficialmente compatible con Microsoft?

¿Necesito gRpc-Web para implementar en IIS? De lo contrario, ¿no es posible en absoluto?

Actualmente gRPC sobre HTTP/2 no funciona en IIS. gRPC-Web funciona.

¿Tiene un ETA sobre cuándo será posible implementar en IIS sin gRpc-Web?

No. Se necesita tiempo para que los cambios se realicen en Windows y se publiquen al público.

¿Tiene una ETA cuando gRpc-Web será oficialmente compatible con Microsoft?

No en este momento.

para su información
Tengo una aplicación (ASP.Net Core 3.2.0-Preview1) en la que cambié un REST API DAL por gRPC-Web DAL. Seguí la guía de la publicación del blog de Steve Sanderson. Mi solución se puede ejecutar como CSB o SSB y tuve éxito con gRPC-Web en ambas configuraciones (tuve que avanzar a una versión más nueva de los paquetes nuget gRPC.*).

Por error hice más actualizaciones de las compilaciones nocturnas y actualmente mis paquetes de gRPC están todos en la versión 2.28.0-dev202003020801. Digo erróneamente porque mis dos implementaciones de soluciones de trabajo fallan.

SSB: el cliente informa un error de "Componente de representación de excepción no controlada: no se pudo cargar el archivo o ensamblado 'System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. El sistema no puede encontrar el archivo especificado. "
Simplemente agregando un paquete nuget explícito de System.Text.Json (4.7.1) a mi proyecto de servidor web, este error desaparece y todo funciona.
[EDITAR] Volver a las versiones 2.27.0/2.27.0-Pre1 para todos los paquetes gRPC.* del feed de NuGet resuelve este problema.

CSB: en el mismo punto en el cliente cuando recibo la primera respuesta de gRPC-Web, recibo un error de "WASM: Grpc.Core.RpcException: Estado (StatusCode = Interno, Detalle = "Respuesta de gRPC incorrecta. Protocolo de respuesta degradado a HTTP /1.1.")". No tengo una solución para esto, pero no es crítico ya que estamos enviando SSB hasta que se lance CSB.
[EDITAR] Volver a las versiones 2.27.0/2.27.0-Pre1 para todos los paquetes gRPC.* del feed de NuGet resuelve este problema.

Perdón por la verbosidad, pero finalmente, dos preguntas:

• ¿Es posible usar otro serializador/deserializador json en gRPC/gRPC-Web?
• ¿Se 'alinearán' los paquetes gRPC/gRPC-Web con ASP.Net Core 3.2-Preview 2 o será necesario acceder a las compilaciones nocturnas?

Hola @JamesNK ,
Mi cliente ha migrado a gRpcWeb, pero hemos encontrado una limitación importante (de la que no he encontrado documentación): el tamaño máximo del mensaje es de 3067 caracteres.
Si del servicio de cliente habitual del servicio gRpc básico, se convierte a gRpc-Web, esta línea fallará (porque la cadena tiene 3068 caracteres, 1 por encima del límite):

// Configurar un canal para usar gRPC-Web
var handler = new GrpcWebHandler(GrpcWebMode.GrpcWebText, new HttpClientHandler());
// El número de puerto (5001) debe coincidir con el puerto del servidor gRPC.
usando el canal var = GrpcChannel.ForAddress(" https://localhost :5001", nuevas GrpcChannelOptions
{
HttpClient = nuevo HttpClient (controlador)
});
var cliente = new Greeter.GreeterClient(canal);
var respuesta = espera cliente.SayHelloAsync(new HelloRequest { Name = new string('A', 3068 ) });
Console.WriteLine("Saludo: " + respuesta.Mensaje);
Console.WriteLine("Presione cualquier tecla para salir...");
Consola.ReadKey();

Adjunto una solución de repro que contiene cliente y servidor.
GrpcWeb.zip

El proyecto equivalente con normale gRpc pudo manejar mensajes de 20k sin ningún problema.
¿Me pueden aconsejar si puedo configurar algo para eliminar este límite?

@curia-damiano, ¿puedes presentar un nuevo problema con esto? Mantengamos este hilo para discutir la característica específica de admitir gRPC ( sin gRPC-Web) en IIS/Azure App Service. gRPC-Web se planteó anteriormente en este hilo porque es una buena alternativa, pero me gustaría mantener este hilo centrado en el objetivo principal de la compatibilidad nativa con gRPC.

@MarkStega , ¿también puede presentar un nuevo problema con su pregunta? Tratemos de evitar que este hilo se sobrecargue con múltiples temas posibles (incluso si están relacionados). Este problema está rastreando la compatibilidad nativa de gRPC en IIS/Azure App Service

¿Podemos tener una ETA cuando gRPC estará disponible en Azure App Service, por favor?

No tenemos ninguna actualización de ETA. Actualizaremos este hilo cuando tengamos una ETA. Esto requiere cambios en Windows y estamos trabajando con ese equipo para intentar implementarlos lo antes posible, pero su programación no está bajo nuestro control directo.

¿Podemos crear un servicio gRPC que se empaquete como un contenedor y se ejecute en una aplicación web para contenedores en Azure?

@fgheysels No. Todavía está detrás de IIS como un proxy que no puede manejar la funcionalidad HTTP/2 requerida.

Hay 3 formas de hacer esto ahora mismo:

1. Exponga una IP pública y use una VM.
2. Use Kubernetes con Azure Application Gateway Ingress (que las instrucciones fallan porque el script de helm está desactualizado, por lo que no se puede usar en este momento) o use nginx ingress (perderá el firewall y las mitigaciones DoS)
3. Use los servicios de Azure Container y expóngalo a una IP pública o use nginx para revertir el proxy o use Azure Application Gateway para revertir el proxy.

Nada más funcionará.

@JuanGalt1717

Use los servicios de Azure Container y expóngalo a una IP pública o use nginx para revertir el proxy o use Azure Application Gateway para revertir el proxy.

Azure Application Gateway no funcionará actualmente. tiene la misma limitacion

Supongo que podríamos ejecutarlo en la nube gpogle con nuestro código .net.

El miércoles 1 de abril de 2020 a las 7:26 a. m. Sourabh Shirhatti, [email protected]
escribió:

@JohnGalt1717 https://github.com/JohnGalt1717

Use los servicios de Azure Container y expóngalo a una IP pública o use nginx para
invierta el proxy o use Azure Application Gateway para revertir el proxy.

Azure Application Gateway no funcionará actualmente. tiene lo mismo
limitación

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606855605 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7LVZJTQ2QPRHVB5G5TRKJGYLANCNFSM4HDHMSDA
.

@shirhatti Ok, esto sigue empeorando. Microsoft lo hizo efectivamente para que .NET con gRPC no se pueda ejecutar en Microsoft Azure. Si no fuera tan triste, sería DIVERTIDO COMO EL INFIERNO.

Así que aquí está la lista actualizada:

1. Exponga una IP pública y use una VM (ponga haproxy, nginx o algo en la VM para revertir el proxy)
2. Use Kubernetes (AKS) con ingreso de nginx.

No creo que ACS funcione porque todavía pone IIS delante si la memoria no me falla.

Y es posible que el n. ° 2 tampoco funcione porque el equilibrador de carga también podría ser IIS en Windows ... ¿Alguien realmente hace que esto funcione en cualquier lugar de Azure?

Creo que este ticket de github define lo que he estado diciendo durante meses sobre el equipo de .NET y lo que está pasando.

Microsoft lo hizo efectivamente para que .NET con gRPC no se pueda ejecutar en Microsoft Azure. Si no fuera tan triste, sería DIVERTIDO COMO EL INFIERNO.

No hay nada aquí que sea específico de .NET, la limitación está en la infraestructura de Windows y Azure relacionada con HTTP/2. Tendría el mismo problema con otras pilas web en Azure. Windows y Azure están trabajando para desbloquearnos, pero requiere cambios en los componentes fundamentales que tardan mucho en volver a implementarse.

Todo esto está directamente relacionado con .net. literalmente dice en los sitios web de azure y .net que .net es el lenguaje de azure.

Pero no puede usar ese idioma con Azure, pero puede usarlo fácilmente en AWS y en la nube de Google.

Es una vergüenza con tantos errores masivos del equipo .net últimamente, pero su arrogancia está en su punto más alto sin razón.

Y ni siquiera nos han dado soluciones alternativas de ningún tipo que no sea usar gRPC web, que es un poc, no un producto real.

Sí, pero podemos ejecutar toda la pila .net en la nube de Google, admite .net
gRPC todo bien. Así que no me importa ejecutar en GPC hasta que puedan arreglar esto.
en azur.
Desarrollo servicios de aplicaciones o aplicaciones sin servidor, no estoy interesado en ninguna.
soluciones de contenedores, ya que son demasiado costosas para las implementaciones a gran escala
Tengo.

El miércoles 1 de abril de 2020 a las 9:57 a. m. James Hancock [email protected]
escribió:

Todo esto está directamente relacionado con .net. literalmente dice en el azul y
Sitios web .net que .net es el lenguaje de azure.

Pero no puede usar ese idioma con Azure, pero puede usarlo en AWS y
Nube de Google fácilmente.

Es una vergüenza con tantos errores masivos del equipo .net.
últimamente, sin embargo, su arrogancia está en su punto más alto sin razón.

Y ni siquiera nos han dado soluciones alternativas de otro tipo que no sea usar
gRPC web que es un poc, no un producto real.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606927717 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7MRPFQBH52XDHUNP63RKJYMVANCNFSM4HDHMSDA
.

Primero, Microsoft debería estar aterrorizado por lo que acabas de decir.

En segundo lugar, acabo de cambiar nuestro material web a Azure Kubernetes usando nodos virtuales y nos cuesta aproximadamente la mitad de lo que nos costaban los servicios de aplicaciones y tiene el doble de rendimiento.

Aks es un lío de cosas que no funcionan correctamente y la documentación está desactualizada, pero una vez que obtiene identidades administradas y una IP pública, el resto es sencillo.

¡Sí, pero este es un gran cambio para Microsoft! y me gusta el
simplicidad de gRPC aunque podría cambiar a http Rx. no pude conseguir mi
websocket a la solución para que funcione, ya que parecía tener problemas con SSL/TLS.
Parece que puedo obtener Azure Kubs al mismo costo que los servicios de mi aplicación S1,
hay que comprobar el rendimiento.

El miércoles 1 de abril de 2020 a las 10:13 a. m. James Hancock [email protected]
escribió:

Primero, Microsoft debería estar aterrorizado por lo que acabas de decir.

En segundo lugar, acabo de cambiar nuestro material web a Azure Kubernetes usando
nodos virtuales y nos cuesta aproximadamente la mitad de lo que costaban los servicios de aplicaciones
nosotros y tiene el doble de rendimiento.

Aks es un lío de cosas que no funcionan bien y están desactualizadas
documentación, pero una vez que obtenga identidades administradas y una IP pública en su lugar
el resto es sencillo.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606933338 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7O3N4XVCWM5MGCTS33RKJ2I7ANCNFSM4HDHMSDA
.

Todo esto está directamente relacionado con .net. literalmente dice en los sitios web de azure y .net que .net es el lenguaje de azure.

Esto claramente no es cierto. Las pilas TCP y HTTP subyacentes no se escriben con .NET. Microsoft está trabajando para adaptar su base para gRPC. Esta es una entrega compleja que tiene efectos colaterales para todo lo que se ejecuta en los servidores de Windows, incluido el propio Azure.

Es una vergüenza con tantos errores masivos del equipo .net últimamente, pero su arrogancia está en su punto más alto sin razón.

Esta forma de lloriqueo improductivo, infantil y sin sentido es completamente innecesaria. Esto no tiene nada que ver con el equipo de .NET. Consiguieron que la mayor parte de gRPC se transfiriera de forma nativa para que podamos trabajar en nuestras PoC y usar soluciones alternativas cuando sea necesario, y como adultos maduros, esperaremos hasta que la plataforma base esté lista para entregar las partes finales.

@oising

.NET es el lenguaje de Azure. Microsoft lo comercializa como tal. Azure no puede entender .NET gRPC. Es 100% cierto. Es un completo fracaso que no estuviera disponible en el lanzamiento y peor aún un año después. Es irrelevante que las pilas no estén escritas por el equipo de .NET dentro de Microsoft . Microsoft es Microsoft . No me importan sus pequeños feudos y fronteras artificiales y prioridades no alineadas. Me preocupo por los mejores productos posibles que realmente funcionan. No me importa que Microsoft afirme que debido a que .NET es de código abierto, de alguna manera ya no lo convierte en un producto pago. Es un producto de pago. Solo lo pago indirectamente usando Azure, Office y Windows.

Y no, no vamos a esperar. Nos mudaremos a otro proveedor de nube donde sí funcione. Que es lo que Microsoft está presionando sin cesar. Demonios, tuve una persona de soporte de Microsoft, y cito: "Si no le gusta [el hecho de que rompimos esto en tiempo de ejecución por diseño], puede usar el producto de otra persona" para unos 100 clientes. Sí, bueno, sé de 8 que hicieron exactamente lo que sugirieron hasta ahora y de 30 a 40 más que están investigando para hacerlo. La pérdida de ingresos estimada para MS de ese único agente de soporte es de aproximadamente 2,8 millones de dólares y sigue aumentando.

Sí, eso es exactamente lo que todos vamos a hacer. Gracias por el consejo Microsoft. Dejaremos Azure, y dejaremos .NET si los líderes no consiguen aclarar sus ideas pronto.

De lo que tienen que preocuparse es cuando la gente como yo deja de quejarse de estos fracasos públicos masivos en los que no se responsabilizan por ellos y, en cambio, no escuchan nada y a todos no les importa. Ocurrió hace aproximadamente un año cuando Xamarin Forms pasó 18 semanas sin poder compilar Apple Store, Android Store y Windows Store con la misma compilación de Xamarin Forms y Xamarin en general. Publiqué, lo admitieron, y 18 semanas después, solo 1 persona había seguido el informe de error a pesar de que se trataba de una ruptura total, no solo de un caso extremo. ¿Por qué? A nadie le importa Xamarin Forms y se fue y comenzó a usar herramientas que no son de Microsoft y Microsoft perdió el escritorio y el teléfono celular. (y sigue intentando el mismo enfoque fallido para recuperarlo incluso con Neo y Duo) En este momento, la gente todavía piensa que tiene una voz en .NET y que sus quejas no serán ignoradas y que esto se solucionará. El liderazgo de .NET está trabajando muy duro para dejar claro que ese no es el caso y que el resultado será idéntico al de Xamarin Forms.

La pieza de los encabezados del tráiler es algo que también necesitamos con más urgencia de lo que pensábamos para Stack Overflow. ¿Podemos ayudar con la priorización aquí?

caso de uso

Hacemos tiempos a través de encabezados de servidor para capturarlos en nuestros registros HTTP (en HAProxy). Tenemos varios encabezados como X-Sql-DurationMs , X-Sql-Count , X-Reds-DurationMs , etc. para que podamos capturarlos, registrarlos y agregar métricas sobre ellos. Si más detalles ayudan, hay una sección en esta publicación de blog . Esto funcionó lo suficientemente bien en ASP.NET MVC 5 (marco completo) porque se almacenó en búfer toda la respuesta. Dado que hacemos muy pocas consultas en las vistas, fue una estrategia de tiempo precisa de ~99% que funcionó bien en general.

Ahora estamos ejecutando .NET Core y todo se transmite. El problema con esto es que los encabezados de tiempo se envían antes de que estén completos, debido a la falta de almacenamiento en búfer. Es una dura compensación. Esto se solucionaría rápidamente si pudiéramos enviar y capturar esos tiempos como encabezados de tráiler. Pero parece que estamos en un bloqueador de IIS aquí y estamos a merced de que se actualice (o de que salgamos de IIS) para que esta funcionalidad funcione.

Personalmente, también tengo otros usos, como MiniProfiler que envía el encabezado Server-Timing (ha estado listo y esperando alrededor de 3 años ).

¿Cómo podemos ayudar con la prioridad en esto? ¿Hay alguna posibilidad de que casos de uso adicionales ayuden a cambiarlo?

Gracias @NickCraver. Este trabajo ya es de alta prioridad y está en progreso, pero implementarlo en servicios como AppService es complicado y aún llevará un tiempo.

¿Existe la posibilidad de que pronto sea compatible con IIS, independientemente de la implementación de Azure? -- Realmente solo necesito un cliente en IIS, si es que eso importa. Entonces, ¿puede IIS ser un cliente http2?

Debo estar de acuerdo, que es preocupante, que parece Imposible que los empleados de Microsoft, tomen sus piernas (O teléfono en este momento) y se pasen a ese otro equipo. Y simplemente molestarlos tanto que implementan una revisión en un día.
Si el equipo de asp / .net no hubiera presionado por grpc, este período de espera estaría bien. Pero dado que está comercializando un producto que no se puede usar en la producción, lamentablemente es hora de tomar medidas desesperadas y romper filas.

Si te importa, lo harás realidad.

Editar: Sé que "un día" es exagerado, ¡pero ha pasado un año!

¿Hay algún documento que explique cómo implementar gRPC en Azure? al menos usando AKS? Sería bueno tener algo.

¿Hay algún documento que explique cómo implementar gRPC en Azure? al menos usando AKS? Sería bueno tener algo.

@lumogox Creé una guía paso a paso para implementar gRPC en Azure.
https://github.com/rupeshtech/k8s-grpc-dotntecore

@rupeshtech De hecho, eché un vistazo a su guía, sin embargo, no funciona si desea mostrar un mensaje en la ruta raíz en el puerto 80.

Excelente material, pero quiero implementarlo en servicios de aplicaciones y todavía no tenemos ETA.
Uno de los otros chicos afirmó que AKS era más barato que la aplicación.
servicios, me parece difícil de creer?
De todos modos, solo quiero usar servicios de aplicaciones o infraestructura sin servidor.

El martes 12 de mayo de 2020 a las 17:51 Luis Molina [email protected]
escribió:

@rupeshtech https://github.com/rupeshtech De hecho, eché un vistazo a
su guía, sin embargo, no funciona si desea mostrar un mensaje en el
ruta raíz en el puerto 80.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627175783 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7MUWWWYCGMEK2FH663RRD5YPANCNFSM4HDHMSDA
.

AKS: b12, el clúster de 2 nodos cuesta $ 176 / mes y le brinda un rendimiento como un p3.

Necesitará lo siguiente para que esto funcione:

1. Entrada de nginx como proxy inverso.
2. Aplicación .net core dockerizada
3. Plantillas de implementación para su aplicación .net core
4. Plantillas de servicio para esas implementaciones
5. La plantilla de ingreso que mapea sus entradas de dns
6. cert bot para k8s o su propio certificado para asignar a la entrada.
7. Desactive SSL solo en su aplicación .net, arruinará el RP y activará el soporte de proxy en .net core.
8. IP pública
9. Registro de contenedores de Azure

Es un proceso de 30 partes configurar esto en Azure en este momento y prácticamente nada se puede hacer a través del portal GUI. Les falta asociar registros de contenedores, configurar proveedores de ingreso (Azure Application Gateway ni nginx ni haproxy, etc. tienen alguna interfaz gráfica de usuario para configurarlo. Ninguna de las cosas principales del servicio con otros recursos, ni las cosas de identidad administrada están debidamente automatizadas tampoco (y usted necesitan ambos por razones insondables).

Si está realizando un certificado comodín, también necesitará acceso a su DNS a través de uno de los proveedores de dns compatibles con el servicio certbot k8s.

Este es nuestro script para configurar un entorno que podría ayudarlo a comenzar:

Configuración de Azure

1. Crear AKS
2. az aks install-cli (si aún no lo ha hecho)
3. az aks get-credentials --resource-group RGL-\ --nombre XX-AKS-\
4. az network public-ip create --resource-group MC_RGL-\ _XX-AKS-\ _eastus --nombre PIP-AKS-\ --sku Standard --allocation-method static --query publicIp.ipAddress -o tsv
5. Asigne api, www, admin a la ip pública en DNS (es decir, beta.XX.com)
6. az identidad crear -g RGL-\ -n XX-MI-AKS-\ -o json (Registrar ClientId, PrincipalId, Id y Name)
7. az asignación de roles crear --role Reader --assignee \ --scope /suscripciones/\ /resourcegroups/RGL-\
8. Obtenga información de la entidad de servicio de las aplicaciones de Azure Active Directory: XX-AKS-\ SP-xxxx (Nombre de registro, ID de cliente)
9. Cree un secreto de cliente sin caducidad y regístrelo
10. az asignación de roles crear --role "Operador de identidad administrada" --assignee \ --alcance "\ "
11. Obtenga la identificación de la zona dns: az network dns zone list --query "[].{ id: id, name: name}"
12. az asignación de roles crear --assignee \ --rol Colaborador --alcance \
13. az asignación de roles crear --assignee \ --rol Colaborador --alcance \
14. az aks actualizar -n XX-AKS-\ -g RGL-\ --adjuntar-acr clcr\
15. Agregar identidad administrada (XX-MI-AKS-\ ) a Key Vault

Kubernetes Vamos a cifrar (si no es producción)

1. kubectl crear espacio de nombres ingreso-basic
2. helm repo agregar estable 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 controlador.servicio.loadBalancerIP="\ "
4. Verifique que tomó: 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. Actualizar issuer.yaml con suscripción y Principio de servicio ClientId
7. Actualice el certificado.yaml a la dirección dns
8. Actualice ingress.yaml con información de dominio, etc.
9. Hacer la versión Base64 de Service Principal Secret: echo \ | abressl base64
10. Actualice secure-dazuredns.yaml con el secreto

O Kubernetes Azure Application Gateway

1. no funciona Completo desastre

Configuración completa de Kubernetes

1. kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Actualizar deployment-api con registro, keyvault, entorno y clave de instrumentación
3. Actualizar registro en deployment-portal y deployment-admin
4. Actualice los valores en identity-binding.yaml (ClientId también es de la identidad administrada anterior)
5. kubectl crear espacio de nombres XX
6. conjunto de configuración de kubectl-context --current --namespace=XX
7. kubectl apply -k ./\
8. Verifique que el certificado esté disponible: kubectl describe el certificado XX-tls-secret

Sí, es realmente así de difícil. Y no, no hay una manera más fácil en k8s. Su única otra opción es una VM con una IP pública y usar un RP frente a su aplicación. Puede usar una VM de Linux y ejecutar Docker en ella, e instalar HAproxy y su aplicación en un contenedor de Docker con un único archivo de composición de Docker con bastante facilidad.

De lo contrario, estará jodido hasta que comiencen a implementar el kernel de Windows 2004 (primavera de 2020) en Azure. (suponiendo que llegue allí y no se retrase hasta noviembre)

Wow amigo, eso es increíble, gracias, pero como también soy un gran admirador de
Azure Dev Ops con un enfoque NoOps Realmente siento que AKS simplemente no está en
mi liga.
Especialmente cuando probablemente pueda ejecutar un servicio de aplicaciones decente por un poco menos
que eso. O cámbielo a una función de Azure. No pude obtener mi websocket
solución para implementar en Azure.
También soy un gran admirador de Reactive Extensions y hay algunos buenos Rx
herramientas por ahí como esta
https://github.com/lucassklp/Rx.Http
Aunque no estoy seguro de la escalabilidad de esto

El martes 12 de mayo de 2020 a las 22:09 James Hancock [email protected]
escribió:

AKS: b12, el clúster de 2 nodos cuesta $ 176 / mes y le brinda un rendimiento como un p3.

Necesitará lo siguiente para que esto funcione:

1. Entrada de nginx como proxy inverso.
2. Aplicación .net core dockerizada
3. Plantillas de implementación para su aplicación .net core
4. Plantillas de servicio para esas implementaciones
5. La plantilla de ingreso que mapea sus entradas de dns
6. cert bot para k8s o su propio certificado para asignar a la entrada.
7. Apague SSL solo en su aplicación .net, arruinará el RP y
   active la compatibilidad con proxy en .net core.
8. IP pública
9. Registro de contenedores de Azure

Es un proceso de 30 partes configurar esto en Azure ahora mismo y virtualmente
nada de esto se puede hacer a través del portal GUI. les falta asociar
registros de contenedores, configuración de proveedores de entrada (Azure Application
Gateway ni nginx ni haproxy, etc. tienen alguna interfaz gráfica de usuario para configurarlo. Ninguno de los
Las cosas de la entidad principal de servicio con otros recursos, ni las cosas de identidad administrada son
debidamente automatizado (y necesita ambos por razones insondables).

Si está realizando un certificado comodín, también necesitará acceso a su DNS
a través de uno de los proveedores de dns compatibles con el servicio certbot k8s.

Esta es nuestra secuencia de comandos para configurar un entorno que podría ayudarlo a obtener
empezado:
Configuración de Azure

1. Crear AKS
2. az aks install-cli (si aún no lo ha hecho)
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 Standard --allocation-method static --query
   direcciónIPpública.ipAddress -o tsv
5. Asigne api, www, admin a la ip pública en DNS (es decir, beta.XX.com)
6. az identidad crear -g RGL- -n XX-MI-AKS- -o json (Registrar el
   ClientId, PrincipalId, Id y Nombre)
7. az asignación de roles crear --role Reader --assignee --scope
   /suscripciones//grupos de recursos/RGL-
8. Obtenga información de la entidad de servicio de las aplicaciones de Azure Active Directory:
   XX-AKS-SP-xxxx (Nombre de registro, ID de cliente)
9. Cree un secreto de cliente sin caducidad y regístrelo
10. asignación de roles az create --role "Operador de identidad administrada"
    --asignado --ámbito ""
11. Obtenga la identificación de la zona dns: az network dns zone list --query "[].{ id:
    identificación, nombre: nombre}"
12. az asignación de roles crear --assignee --role Colaborador --scope
13. az asignación de roles crear --assignee --role Colaborador --scope
14. az aks actualizar -n XX-AKS- -g RGL- --attach-acr clcr
15. Agregar identidad administrada (XX-MI-AKS-) a Key Vault

Kubernetes Vamos a cifrar (si no es producción)

1. kubectl crear espacio de nombres ingreso-basic
2. helm repo agregar estable
   https://kubernetes-charts.storage.googleapis.com/
3. helm install nginx-ingress estable/nginx-ingress --namespace
   ingreso-basic --set controlador.replicaCount=2 --set
   controlador.nodeSelector."beta.kubernetes.io/os"=linux --set
   defaultBackend.nodeSelector."beta.kubernetes.io/os"=linux --set
   controlador.servicio.loadBalancerIP=""
4. Verifique que tomó: kubectl --namespace ingress-basic get services -o
   controlador de entrada de nginx de ala ancha
5. kubectl apply --validate=false -f
   https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
6. Actualizar issuer.yaml con suscripción y Principio de servicio ClientId
7. Actualice el certificado.yaml a la dirección dns
8. Actualice ingress.yaml con información de dominio, etc.
9. Hacer la versión Base64 de Service Principal Secret: echo | abressl
   base64
10. Actualice secure-dazuredns.yaml con el secreto

O Kubernetes Azure Application Gateway

1. no funciona Completo desastre

Configuración completa de Kubernetes

1. kubectl aplicar -f
   https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Actualice deployment-api con registro, keyvault, entorno y
   clave de instrumentación
3. Actualizar registro en deployment-portal y deployment-admin
4. Actualice los valores en Identity-binding.yaml (ClientId también es del
   identidad administrada arriba)
5. kubectl crear espacio de nombres XX
6. conjunto de configuración de kubectl-context --current --namespace=XX
7. kubectl apply -k ./
8. Verifique que el certificado esté disponible: kubectl describe el certificado XX-tls-secret

Sí, es realmente así de difícil. Y no, no hay una manera más fácil en k8s. Tu
la única otra opción es una VM con una IP pública y usar un RP frente a su
aplicación Puede usar una máquina virtual Linux y ejecutar Docker en ella, e instalar HAproxy y
su aplicación en un contenedor docker con un solo archivo docker-compose bastante
fácilmente.

De lo contrario, estás jodido hasta que comiencen a implementar el kernel desde
Windows 2004 (primavera de 2020) a Azure. (suponiendo que lo hizo allí y
no se retrasa hasta noviembre)

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627302354 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7P74W4DK5RP2BKKI7LRRE365ANCNFSM4HDHMSDA
.

Websockets es probablemente una buena alternativa si no se ha comprometido con gRPC y está enfocado en Azure App Services.

Una vez que haya configurado k8s, Azure Devops es fácil. Le dices que cree el contenedor docker y lo implemente en el repositorio azul con la etiqueta build:id y luego, para liberarlo, ejecuta kubectl para indicarle que actualice el contenedor de implementación con la etiqueta correcta para la identificación de compilación y se implementará de forma transparente. la nueva versión Lo único que hicimos fue crear una herramienta que realiza migraciones de EF antes de hacerlo para que no termine con varias réplicas de k8 llamando al script de migración al mismo tiempo.

Magic mate muchas gracias, también estoy muy interesado en el diseño basado en dominios, así que
supongo que puedo agregar AKS a mi arsenal ahora, pero quiero que mis clientes se muden a
serverless, no entiendo por qué la mayoría de la gente no parece querer pasar de
contenedores?

El martes 12 de mayo de 2020 a las 23:05 James Hancock [email protected]
escribió:

Websockets es probablemente una buena alternativa si no se ha comprometido con gRPC
y se centran en Azure App Services.

Una vez que haya configurado k8s, Azure Devops es fácil. Le dices que construya
el contenedor docker e implementarlo en el repositorio azul con build:id
etiqueta y luego para liberarlo, ejecute kubectl para indicarle que actualice la implementación
contenedor con la etiqueta correcta para la identificación de compilación y simplemente
implementar de forma transparente la nueva versión. Lo único que hicimos fue crear una herramienta
que hace migraciones de EF antes de hacer eso para que no termines con
múltiples réplicas de k8s llamando al script de migración al mismo tiempo.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627329964 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7MW7NJUS475HICIJTTRRFCQBANCNFSM4HDHMSDA
.

Los contenedores @acrigney se consideran ampliamente una tecnología 'sin servidor'. Definitivamente es discutible, pero no hay una definición estricta.

@acrigney Hay muchas razones por las que las funciones sin servidor, especialmente las de Azure, no son deseables:

1. Azure Functions es una pila de basura frágil y humeante que siempre está atrasada en los parches de seguridad con .net core.
2. Las funciones de Azure son en gran medida una caja negra y difíciles de depurar en muchos casos.
3. Una vez que comienza a utilizarlo por completo, es más costoso que otras opciones cuando tiene una carga constante.
4. No hay nada que no pueda hacer de otra manera que pueda hacer en las funciones de Azure
5. K8s proporciona un entorno genérico conocido que funciona igual en su máquina de desarrollo local que en cualquier nube que desee crear. Cuando creas un recurso, funciona. No importa si Azure o AWS lo respaldan, funciona de la misma manera y de manera consistente, a diferencia de Azure Functions, obtuvimos resultados diferentes en Azure que localmente de manera regular.
6. K8s, en un sistema cargado, cuesta menos que Azure Functions.
7. K8s hace la implementación mejor que las funciones.
8. Una vez que comience a trabajar con la comunicación remota del código VS en la ventana acoplable, no querrá volver atrás. Mismo entorno, misma configuración que la producción para una consistencia del 100 %. (Usamos k8s dentro de la ventana acoplable para desarrollar con la ventana acoplable WSL2 y hacemos girar k8s en linux, lo que funciona maravillosamente con Windows 10 2004, pero el desarrollo completo en k8s llegará pronto)
9. k8s le brinda toda la autonomía de las VM sin tener que administrar las VM, equilibrar la carga, etc. Simplemente funciona.
10. Si crea correctamente las imágenes de la ventana acoplable utilizando la orientación de la plataforma y la vinculación de IL, sus microservicios en k8s son tan pequeños como en las funciones de Azure, por lo que no hay problemas de escalado.

Esa es solo una lista corta. Las funciones de Azure son geniales en teoría, luego empiezas a golpearte la cabeza contra la pared y descubres que no vale mucho la pena.

hasta que comiencen a implementar el kernel de Windows 2004 (primavera de 2020) en Azure.

El trabajo necesario para IIS todavía está en progreso y no está disponible en la versión de 2004.

@Tratcher Guau. Sólo ay. Así que habrá pasado más de un año con .net core compatible con gRPC y Azure sin tener una forma viable para que la gran mayoría de los desarrolladores del mundo lo usen.

MS necesita crear verdaderos servicios de aplicaciones basados ​​en docker que usen nginx o ha proxy y no IIS para RP. Esto es una locura.

Realmente amigo, creo que eso lo está estirando, seguro que AKS puede escalar pero
especialmente con el acoplamiento de mensajería requerido para ejecutar múltiples
contenedores para un proyecto grande Difícilmente consideraría contenedores en
manteniendo los ideales de la tecnología sin servidor. Puedo enchufar y reproducir fácilmente cualquier
microservicios tecnológicos backend con funciones y servidores de aplicaciones, pero ¿tendría
esta agilidad con los contenedores?

El martes 12 de mayo de 2020 a las 23:31 cebolla martillo [email protected]
escribió:

@acrigney https://github.com/acrigney contenedores son bastante amplios
considerada una tecnología 'sin servidor'

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627347120 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7PPWZ7MPIETCXPEFYDRRFFUNANCNFSM4HDHMSDA
.

@acrigney Absolutamente lo harías. Y tampoco tendrías dependencias, eso es Azure Functions. (y puede usar fácilmente el host de Azure Function en contenedores e incluso k8 si lo desea)

@acrigney ¿Está tratando de exponer gRPC a otros microservicios que se ejecutan en el servicio de aplicaciones? ¿Cómo es su topología?

Gracias compañero, pero creo que no tendrías ninguna dependencia.
acoplamiento con funciones. Hago microservicios con estado usando la aplicación DDD
servicios con Azure app services y hago microservicios sin estado con
Servicios de aplicación DDD en funciones de Azure. Los servicios de la aplicación DDD exponen
DTO y usar los objetos de dominio y los otros servicios de aplicaciones pueden observar el
eventos desencadenados por estos objetos de dominio. Simplemente no necesito contenedores y una vez
construyes un contenedor, va a tener mucho código duplicado que
sería necesario en otros contenedores.

El miércoles 13 de mayo de 2020 a las 00:09 James Hancock [email protected]
escribió:

@acrigney https://github.com/acrigney Absolutamente lo harías. Y tú
tampoco tendría un infierno de dependencia, eso es Azure Functions. (y tu puedes
use fácilmente Azure Function host en contenedores e incluso k8s si lo desea)

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627369635 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7PQLO2K4RVWBQRGQS3RRFKCZANCNFSM4HDHMSDA
.

La advertencia de que no se ejecuta en IIS debe colocarse en la parte superior de la página con una etiqueta <marquee> : https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

Realmente es inject profanity here si ha estado creando prototipos, creando archivos de prototipos, configurando su servidor, cliente, autenticación usando JWT y acaba de presentar la idea completa a un cliente como esto-es-lo-mejor-siguiente- since-sliced-bread para descubrir que no podemos usarlo en producción porque estamos ejecutando IIS. :(

hasta que comiencen a implementar el kernel de Windows 2004 (primavera de 2020) en Azure.

El trabajo necesario para IIS todavía está en progreso y no está disponible en la versión de 2004.

¿Hay una eta / hoja de ruta?

La advertencia de que no se ejecuta en IIS debe colocarse en la parte superior de la página con una etiqueta <marquee> : https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

Tiene razón, he archivado https://github.com/dotnet/AspNetCore.Docs/issues/18336 para aclarar.

¿Hay una eta / hoja de ruta?

No, hay demasiadas partes móviles para dar una estimación confiable.

¿Alguien tiene alguna documentación sobre cómo configurar nginx con grpc y kestrel?

Hola a todos, ¿podemos redirigir algunas de las solicitudes de gRPC en la voz de usuario de AppService https://feedback.azure.com/forums/169385-web-apps?

Pregunta rápida: ¿El soporte para IIS y Azure App Service está acoplado o se puede/se entregará por separado?

¡Gracias!

Están algo acoplados: el ingreso de Azure App Service y el alojamiento de Windows se basan en IIS, por lo que obtener soporte en IIS es un requisito previo.

Luego, App Service debe implementarse en función de una compilación que tenga esas correcciones, por lo que App Service vendrá después de la compatibilidad con IIS.

Pregunta rápida: Implementé el servidor gRPC en IIS (10.0) y ahora obtengo el error "Estado (StatusCode = Cancelado, Detalle = \"No se encontró el estado de grpc en la respuesta.\")". He usado el proyecto WebApi como cliente gRPC. ¿Alguien puede ayudarme?

Pregunta rápida: implementé el servidor gRPC en IIS (10.0) y ahora obtengo el error "Estado (StatusCode = Cancelado, Detalle = "No se encontró el estado de grpc en la respuesta"). He usado el proyecto WebApi como cliente gRPC. ¿Alguien puede ayudarme?

No se puede hacer, gRCP no es compatible con IIS.

@lumogox @Dhananjay48 Nota: GRPC-web es compatible con IIS y solo pierde la transmisión del cliente en su mayor parte. Así que esa es una solución, aunque no excelente.

De lo contrario, de acuerdo con lo que estoy viendo, estamos esperando al menos hasta diciembre antes de que esto se solucione en IIS, así que muévase y use otra cosa como nginx como proxy inverso.

Si solo desea implementar GRPC en Azure App Service, puede hacerlo ahora con un contenedor de Linux

@EdiWang Esto actualmente no es compatible con App Service para Linux. Actualmente estamos trabajando con App Service para habilitar esto, pero no tengo ninguna ETA para compartir

¿Se debe a que todavía hay HTTP.sys delante de la aplicación web, aunque es un contenedor acoplable que se ejecuta en Linux?

Tengo entendido que todos los servicios de la aplicación tienen un proxy inverso de iis. Por lo tanto, no funcionarán hasta que esto se solucione.

Solo funcionará algo con una IP pública o rped por ha o nginx, etc. (Linux). Kubernetes con nginx o ha funciona bien como ejemplo, pero la puerta de enlace de aplicaciones como ingreso no lo hará.

Tengo entendido que todos los servicios de la aplicación tienen un proxy inverso de iis. Por lo tanto, no funcionarán hasta que esto se solucione.

Solo funcionará algo con una IP pública o rped por ha o nginx, etc. (Linux). Kubernetes con nginx o ha funciona bien como ejemplo, pero la puerta de enlace de aplicaciones como ingreso no lo hará.

También es mi entendimiento. De hecho, terminé aquí porque leí si todos los servicios de aplicaciones están liderados por un IIS. Porque en los documentos aquí: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse- proxy: nos aconseja instalar un proxy invertido delante de Kestrel si va a exponer Kestrel a Internet :) Sé que hay un IIS cuando se ejecuta en Windows, pero no puedo encontrar ninguno para validar HTTP.sys o IIS también está al frente cuando se ejecuta Docker en un servicio de aplicaciones. Este hilo es lo más cerca que he llegado. Lo curioso es que me suscribo a este hilo porque también soy bastante interesante en gPRC :)

Puedo confirmar que iis también ofrece servicios de aplicaciones basados ​​en contenedores, incluidos los de Linux.

Sus únicas opciones son VMS donde ha hecho el rp usted mismo o aks.

＠Davidfowl AppService User Voice no ha recibido mucha atención.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
¿Podría ser esta la razón de la lenta implementación? Como ve este problema, creo que la compatibilidad con gRPC es importante.

Sí, especialmente porque tampoco pude hacer que websockets funcionara y estoy
preocupado por el costo de los contenedores ya que tendría que correr mucho.

El viernes, 12 de junio de 2020 a las 21:58 Takekazu Omi [email protected]
escribió:

＠Davidfowl AppService User Voice no ha recibido mucha atención.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
¿Podría ser esta la razón de la lenta implementación? Como ves esto
Problema, creo que la compatibilidad con gRPC es importante.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-643232429 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7L4452ZISXIPNAXWYLRWIKADANNCNFSM4HDHMSDA
.

Agregar la solicitud allí sigue siendo muy importante.

@davidfowl Es mucho más fácil decirlo que hacerlo. Intente iniciar sesión en el sitio con su cuenta de Microsoft con New Edge. Aparece una nueva ventana y no hace nada. Intente iniciar sesión con mi correo electrónico, bueno, olvidé la contraseña, el correo electrónico de la contraseña va al correo no deseado para una dirección de correo electrónico de @outlook.com. Cámbielo, inicie sesión y no le solicite el administrador de contraseñas para almacenar la contraseña, etc.

Simplemente WOW mal. Supongo que, como resultado, el equipo de Azure no está recibiendo buenos comentarios. Espero que puedas reenviar esto a las personas adecuadas para arreglar ese lío.

Tal vez ayude a alguien alojar grpc en iis.
Este es un ejemplo de trabajo grpcweb Blazor WebAssembly con gRPC-Web enfoque de código primero que aloja a iis a través de publicación remota como un encanto. Supongo que podría funcionar de otras maneras también. No he realizado ninguna prueba de rendimiento, por lo que no puedo comentar sobre eso, pero creo que al menos funcionaría bien en soluciones de tamaño mediano.
Aquí hay un enlace a github
También usa protobuf-net.Grpc.AspNetCore, que no es una declaración aburrida de protobuff. Es tan bueno cuando puede ir directamente a la implementación o agregar métodos adicionales para solicitar/responder.

Hola a todos, necesito definir un tipo de datos de matriz de cadenas en el mensaje Grpc. no estoy seguro de cómo hacerlo. ahora mismo lo estoy haciendo como
cadena repetida Nombre = 1,
aquí necesito el campo de nombre como tipo de matriz de cadenas. Pero muestra el error de que lo es, el campo es de tipo de solo lectura cuando vincula datos en él.

@ Dhananjay48 Esto no es StackOverflow. Por favor, haga su pregunta allí.
Dejemos este problema para cosas relacionadas con gRPC en App Service.

Tengo entendido que todos los servicios de la aplicación tienen un proxy inverso de iis. Por lo tanto, no funcionarán hasta que esto se solucione.

Solo funcionará algo con una IP pública o rped por ha o nginx, etc. (Linux). Kubernetes con nginx o ha funciona bien como ejemplo, pero la puerta de enlace de aplicaciones como ingreso no lo hará.

¿Podría 'Kestrel utilizado en una configuración de proxy inverso' con nginx ser una solución? https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy '

Puse la sugerencia a @JamesNK en los documentos, para incluir una solución de alojamiento de ejemplo:
https://github.com/dotnet/AspNetCore.Docs/issues/18953

https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-disponible/?utm_source=vs_developer_news&utm_medium=referral
Se anunció recientemente y se puede implementar en Azure.

El jueves 25 de junio de 2020 a la 1:48 p. m. OzBob [email protected] escribió:

Tengo entendido que todos los servicios de la aplicación tienen un proxy inverso de iis.
Por lo tanto, no funcionarán hasta que esto se solucione.

Solo algo con una IP pública o rped por ha o nginx, etc. (Linux)
trabajo. Kubernetes con nginx o ha funciona bien como ejemplo, pero la aplicación
puerta de enlace ya que la entrada no lo hará.

¿Podría 'Kestrel utilizado en una configuración de proxy inverso' con nginx, ser un
¿solución?
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy
'

Puse la sugerencia a @JamesNK https://github.com/JamesNK en el
docs, para incluir una solución de hospedaje de ejemplo:
dotnet/AspNetCore.Docs#18953
https://github.com/dotnet/AspNetCore.Docs/issues/18953

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-649198280 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABCSC7KBUALMCXDGUS2NV7LRYLCKNANCNFSM4HDHMSDA
.

@acrigney y mencionado aquí en Ch9 también: https://youtu.be/T4RD3W2MgHQ?list=TLPQMjUwNjIwMjB6we-UTBA_VA&t=288 por @shirhatti (https://twitter.com/sshirhatti)

Solo quería señalar que hemos estado trabajando con el equipo de Windows para comenzar a habilitar estos escenarios. Aquí hay una publicación de blog del equipo de Windows al respecto, y https://github.com/dotnet/aspnetcore/pull/24120 tiene parte del trabajo de seguimiento para exponer cosas en ASP.NET Core.

Todavía pasará un tiempo antes de que todo esto aterrice, pero es bueno poder informar que al menos estamos progresando.

Gracias por el seguimiento, muy útil y apreciado!!

El miércoles 22 de julio de 2020 a las 11:17 Kevin Pilch [email protected]
escribió:

Solo quería señalar que hemos estado trabajando con el equipo de Windows para
comience a habilitar estos escenarios. Aquí hay una publicación de blog
https://aka.ms/grpcblogpost del equipo de Windows al respecto, y #24120
https://github.com/dotnet/aspnetcore/pull/24120 tiene algunos de los
trabajo de seguimiento para exponer cosas en ASP.NET Core.

Todavía pasará un tiempo antes de que todo esto aterrice, pero es bueno poder
para informar que estamos progresando al menos.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-662547810 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAUKMASPCV3UE47OJZ6TIMDR44GKTANCNFSM4HDHMSDA
.

Solo quería señalar que hemos estado trabajando con el equipo de Windows para comenzar a habilitar estos escenarios. Aquí hay una publicación de blog del equipo de Windows al respecto, y #24120 tiene parte del trabajo de seguimiento para exponer las cosas en ASP.NET Core.

Todavía pasará un tiempo antes de que todo esto aterrice, pero es bueno poder informar que al menos estamos progresando.

Tenga en cuenta que esto ya se ha integrado en el servidor HttpSys de AspNetCore en las vistas previas de 5.0. Por favor inténtalo. Si podemos identificar cualquier problema en esta capa ahora, deberíamos tener menos problemas cuando agreguemos la capa IIS encima de esto.

¿Significa esto que puedo hacer gRPC completo en IIS si uso ASP.NET Core para la vista previa de .NET 5?

Aún no. Hay un montón de partes diferentes aquí:

1. Módulo Http.sys en Windows
2. Soporte de ASP.NET Core para esto en HttpSysServer
3. Compatibilidad con IIS para esto en Windows
4. Compatibilidad con ASP.NET Core para esto en IIS
5. Soporte para esto en el proxy inverso que usa Azure App Service
6. Azure App Service implementando una compilación de Windows con 1 y 3.
7. Azure App Service implementando una compilación del proxy inverso de 5
8. Azure App Service implementando una compilación de ASP.NET Core con 2 y 4.

Lo que decía @Tratcher es que 1 y 2 están disponibles en versiones preliminares de .NET 5. Estamos trabajando en 3 y 4 en este momento, pero probar 1 y 2 nos ayudará a saber si funcionará, ya que Http. El soporte de sys es una base del soporte de IIS.

Debería haber dicho que 1 está disponible en las versiones preliminares de Windows y 2 está disponible en las versiones preliminares de .NET 5.

La vista previa de Windows Insider está disponible con http.sys actualizado
https://techcommunity.microsoft.com/t5/networking-blog/windows-server-insiders-getting-grpc-support-in-http-sys/ba-p/1534273

¿Alguna idea de si estará disponible como una actualización de Windows para Windows Server 2016/2019?

Y la compatibilidad con IIS ahora se encuentra en las últimas compilaciones de Windows Insider anunciadas aquí .

Estamos investigando si será posible retrotraer estos cambios a la compilación de servicio, pero eso aún está en el aire. A partir de ahora, el único plan registrado es que estarán en futuros lanzamientos.