Bonjour @moodya , avez-vous consulté la documentation sur https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio ?

Si vous rencontrez un problème, veuillez nous en informer et nous pourrons enquêter.

Oui, j'ai déjà créé un service qui s'exécute en tant que service hébergé générique. Je l'ai porté sur le nouveau modèle asp net core 3 et je l'ai fait fonctionner sur Kestrel auto-hébergé, mais je cherche actuellement à l'héberger derrière iis et, espérons-le, à le déployer en tant que service d'application dans Azure. Je n'arrive pas à faire fonctionner l'ancien (iis).

Obtenez Outlook pour Android https://aka.ms/ghei36

De : Eilon Lipton [email protected]
Envoyé : mercredi 3 avril 2019 18:06:17
À : aspnet/AspNetCore
Cc : moodya ; Mention
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

Bonjour @moodya https://github.com/moodya , avez-vous consulté la documentation sur https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=visual-studio ?

Si vous rencontrez un problème, veuillez nous en informer et nous pourrons enquêter.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

Je ne trouve aucun exemple de la façon de procéder, alors peut-être que ce n'est pas encore pris en charge

Obtenez Outlook pour Android https://aka.ms/ghei36

De : Alain Moody [email protected]
Envoyé : mercredi 3 avril 2019 18:11:06
À : aspnet/AspNetCore ; aspnet/AspNetCore
Cc : Mentionner
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

Oui, j'ai déjà créé un service qui s'exécute en tant que service hébergé générique. Je l'ai porté sur le nouveau modèle asp net core 3 et je l'ai fait fonctionner sur Kestrel auto-hébergé, mais je cherche actuellement à l'héberger derrière iis et, espérons-le, à le déployer en tant que service d'application dans Azure. Je n'arrive pas à faire fonctionner l'ancien (iis).

Obtenez Outlook pour Android https://aka.ms/ghei36

De : Eilon Lipton [email protected]
Envoyé : mercredi 3 avril 2019 18:06:17
À : aspnet/AspNetCore
Cc : moodya ; Mention
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

Bonjour @moodya https://github.com/moodya , avez-vous consulté la documentation sur https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=visual-studio ?

Si vous rencontrez un problème, veuillez nous en informer et nous pourrons enquêter.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

@shirhatti - une idée à ce sujet ?

Impossible d'héberger gRPC dans IIS/Azure App Service.
L'implémentation HTTP/2 de Http.Sys ne prend pas en charge les en-têtes de fin de réponse HTTP sur lesquels repose gRPC.

Merci pour la réponse rapide. Comment recommanderiez-vous d'héberger un service grpc dans un scénario de production pour le moment ? En outre, êtes-vous au courant des délais dans lesquels un service grpc pourra être hébergé sur le service iis/app ?

Obtenez Outlook pour Android https://aka.ms/ghei36

De : Sourabh Shirhatti [email protected]
Envoyé : mercredi 3 avril 2019 19:13:23
À : aspnet/AspNetCore
Cc : moodya ; Mention
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

Impossible d'héberger gRPC dans IIS/Azure App Service.
L'implémentation HTTP/2 de Http.Sys ne prend pas en charge les en-têtes de fin de réponse HTTP sur lesquels repose gRPC.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479600486 ou désactivez le fil de discussion https://github.com/notifications/unsubscribe-auth/AlUvPNHH4- HhNsSAtugTw0MzzNco6c76ks5vdO9DgaJpZM4cZ2SG .

L'approche recommandée consiste à héberger votre service gRPC sur AKS.

En ce qui concerne les délais d'App Service, je m'en remettrais à @stefsch

Merci de m'avoir répondu. En termes de structure de service aks Vs en termes d'hébergement, le service grpc est-il le meilleur choix ? Si oui, pourquoi?

Obtenez Outlook pour Android https://aka.ms/ghei36

De : Sourabh Shirhatti [email protected]
Envoyé : lundi 8 avril 2019 07:31:45
À : aspnet/AspNetCore
Cc : moodya ; Mention
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

L'approche recommandée consiste à héberger votre service gRPC sur AKS.

En ce qui concerne les délais d'App Service, je m'en remettrais à @stefsch https://github.com/stefsch

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-480701227 ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AlUvPLwQW8HCp- YXsz6yNaK_RH7jbZzWks5veuJRgaJpZM4cZ2SG .

Je m'attends actuellement à des problèmes pour le faire. J'ai un service gRPC qui fonctionne bien en utilisant aspnetcore 3 preview 3 et Kestrel. Mais, une erreur sur les trailers apparaît en utilisant IIS lorsque le service envoie la réponse (la requête est bien reçue) :
erreur gPRC => 2 UNKNOWN : aucun état reçu)
Erreur Dotnet => "Les bandes-annonces ne sont pas prises en charge pour cette réponse" dans Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(HttpResponse response, String trailerName, StringValues ​​trailerValues) à Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

Selon les messages ci-dessus, ne pensez pas que iis prend en charge l'hébergement d'un service grpc

Obtenez Outlook pour Android https://aka.ms/ghei36

De : alustrement [email protected]
Envoyé : jeudi 25 avril 2019 10:57:42
À : aspnet/AspNetCore
Cc : moodya ; Mention
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

Je m'attends actuellement à des problèmes pour le faire. J'ai un service gRPC qui fonctionne bien en utilisant aspnetcore 3 preview 3 et Kestrel. Mais, une erreur sur les trailers apparaît en utilisant IIS lorsque le service envoie la réponse (la requête est bien reçue) :
erreur gPRC => 2 UNKNOWN : aucun état reçu)
Erreur Dotnet => "Les bandes-annonces ne sont pas prises en charge pour cette réponse" dans Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(HttpResponse response, String trailerName, StringValues ​​trailerValues) à Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486607635 ou désactivez le fil de discussion https://github.com/notifications/unsubscribe-auth/AJKS6PEAJ2UKKH2QIKNTCZDPSF6BNANCNFSM4HDHMSDA .

Suite à cet échange https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , il semble que ce n'est pas la responsabilité du serveur web de gérer gRPC. gPRC utilise HTTP/2, IIS prend en charge HTTP/2, donc cela doit fonctionner. Si ce n'est pas le cas, c'est un bogue d'IIS ou, plus possible, de dotnetcore.

Selon les gars de Microsoft dans les messages ci-dessus, iis ne prend pas en charge les en-têtes de fin requis pour héberger un service grpc. Cela signifie que vous ne pouvez pas en héberger un dans iis ou en tant que service d'application pour le moment.

Obtenez Outlook pour Android https://aka.ms/ghei36

De : alustrement [email protected]
Envoyé : jeudi 25 avril 2019 11:39:08 AM
À : aspnet/AspNetCore
Cc : moodya ; Mention
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

Suite à cet échange https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , il semble que ce n'est pas la responsabilité du serveur web de gérer gRPC. gPRC utilise HTTP/2, IIS prend en charge HTTP/2, donc cela doit fonctionner. Si ce n'est pas le cas, c'est un bogue d'IIS ou, plus possible, de dotnetcore.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486620151 , ou désactivez le fil de discussion https://github.com/notifications/unsubscribe-auth/AJKS6PBQO4427EYN67SI7A3PSGC4ZANCNFSM4HDHMSDA .

Merci, je l'ai raté et cela a du sens avec mon problème.
@shirhatti l'accompagnement est prévu sur la feuille de route ?

Nous (IIS) évaluons actuellement la prise en charge des bandes-annonces de réponse HTTP. Aucune feuille de route / aucun engagement dont je puisse parler pour le moment.

@shirhatti Étant donné que gRPC semble être une fonctionnalité majeure de .NET Core 3 (https://github.com/grpc/grpc-dotnet), ce serait vraiment dommage s'il n'est pas hébergeable dans IIS/App Service étant donné tant de fichiers . Les applications Web NET sont hébergées sur ceux-ci. J'espère que la disponibilité de cette fonctionnalité dans .NET Core vous aidera à piloter votre feuille de route.

Je suis entièrement d'accord avec @jbrantly. gRPC est annoncé comme l'une des principales fonctionnalités de .NET Core 3.
Il doit pouvoir être hébergé dans IIS/Azure App Services.
@shirhatti s'il vous plaît envisager d'ajouter ceci à la feuille de route

Je suis également d'accord.

Obtenez Outlook pour Android https://aka.ms/ghei36

De : Tomasz Jagusz [email protected]
Envoyé : vendredi 26 avril 2019 09:42:58
À : aspnet/AspNetCore
Cc : moodya ; Mention
Objet : Re : [aspnet/AspNetCore] Héberger le service grpc dans iis ou en tant que service d'application ? (#9020)

Je suis entièrement d'accord avec @jbrantly https://github.com/jbrantly . gRPC est annoncé comme l'une des principales fonctionnalités de .NET Core 3.
Il doit pouvoir être hébergé dans IIS/Azure App Services.
@shirhatti https://github.com/shirhatti , veuillez envisager de l'ajouter à la feuille de route

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486977989 ou désactivez le fil de discussion https://github.com/notifications/unsubscribe-auth/AJKS6PENWT46GCJ7GQGEGPTPSK6BFANCNFSM4HDHMSDA .

Je ne pourrais pas être plus d'accord.

Nous examinons la question. Il nécessite à la fois des modifications du noyau Windows et des modifications IIS.

@davidfowl cela sera-t-il possible lorsque .NET Core 3 sortira ?
La possibilité d'héberger GRPC dans App Services est un obstacle pour moi.

Eh bien, c'est le 29 mai 2019 , et pourtant rien n'indique que ce sera possible. Je cherche à héberger un service GRPC dans IIS et à ajouter un certificat pour utiliser HTTPS :(

Non, ce n'est pas possible sur IIS, nous travaillons sur les modifications mais ce sera un processus lent (car il nécessite une mise à jour de Windows).

J'ai perdu environ 3 jours... merci iis

Salut @davidfowl
Toute mise à jour?

@davidfowl a-t-il une chance que cela soit ajouté avant la sortie de .NET Core 3.0 ? Ou faut-il attendre la 3.1 ou la 5.0 ?

Non car cela nécessite des changements de fenêtres. Cela ne fera pas partie de la version 3.0 et il faudra la dernière version de Windows (quelle qu'elle soit à l'époque) pour obtenir ces fonctionnalités. Il n'y a pas d'heure d'arrivée prévue

Hmm, je suis en train de planifier une implémentation de service fabric qui va utiliser des services sans état basés sur gRPC et des acteurs fiables, en plus de dotnet core 3. Est-ce que ça va me mordre le cul ? Si j'héberge sur SF, je suppose que je vais utiliser Kestrel au cœur? Il est temps de prototyper.

@oising même bateau ici - mais nous roulons lentement vers les conteneurs k8s + linux, donc ce genre de choses nous aide de toute façon à nous pousser dans cette direction.

Je suis juste plus 1'ing cela car je joue avec gRPC depuis un certain temps maintenant et je veux enfin commencer à l'adopter dans certains de mes projets clients, donc je regardais les flux de travail de déploiement. Je suis un peu découragé par la quantité de frais généraux opérationnels que cela impliquerait de déployer en production avec .net core.

Il m'a également fallu des jours pour comprendre qu'IIS était le problème. Vraiment à la recherche d'une solution. Des solutions de contournement ?

@bingoo sans support Windows et IIS Vous n'avez pas de chance. Vous pouvez utiliser Service Fabric mais je n'en ai aucune expérience. J'espère qu'il sera possible de l'héberger sur IIS ou dans Azure de manière simple.
Pour les projets en cours, Grpc n'est pas une option pour moi à cause de ce problème.

Ce serait bien si c'était un gros avertissement audacieux sur les docs...

L'hébergement IIS n'est pas encore pris en charge. App Services utilise Windows Server 2016 + IIS comme backend par défaut, mais maintenant il prend également en charge Linux / Containers. Si vous souhaitez simplement déployer GRPC sur Azure App Service, vous pouvez le faire maintenant avec un conteneur Linux. Mais le plan App Service ne peut pas être partagé avec un plan d'hébergement Windows. Vous devrez dépenser de l'argent supplémentaire pour un nouveau plan de service d'application soutenu par Linux Container.

La meilleure façon est d'utiliser AKS puis d'utiliser Ambassador. Ambassador est une passerelle API basée sur Envoy qui s'exécute comme un conteneur dans Kubernetes. Il vous permet de proxy à la fois grpc et grpc-web, par exemple. navigateur vers le serveur grpc et également un client grpc, peut-être ac # un vers un serveur grpc. Si vous souhaitez que js frontal reçoive des appels gRPC, vous avez besoin de grpc web et d'un proxy, car les navigateurs ne prennent pas non plus en charge correctement les en-têtes de fin de réponse http2. Grpc Web utilise Envoy par défaut, c'est pourquoi Ambassador est le meilleur.

Si vous souhaitez simplement déployer GRPC sur Azure App Service, vous pouvez le faire maintenant avec un conteneur Linux

@EdiWang Ceci n'est actuellement pas pris en charge sur App Service pour Linux. Nous travaillons actuellement avec App Service pour activer cela, mais je n'ai pas d'ETA à partager

Salut les braves gens
Je suis un peu confus, nous ne pouvons donc pas avoir de service grpc dans azur.
Mais azur lui-même utilise grpc, le Azure Functions Languge Worker Protobuf.
https://github.com/Azure/azure-functions-language-worker-protobuf
Ou est-ce que je manque quelque chose ici?
Essayer de comprendre :confuse:

@GoranHalvarsson Vous pouvez avoir des services gRPC dans Azure, mais vous ne pouvez pas encore les exécuter dans Azure App Services.

@markrendle Merci d'avoir répondu. Alors, comment puis-je utiliser/configurer un service gRpc dans Azure ?

Ce serait bien si c'était un gros avertissement audacieux sur les docs...

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

@markrendle Merci d'avoir répondu. Alors, comment puis-je utiliser/configurer un service gRpc dans Azure ?

En n'utilisant pas IIS, ce qui signifie utiliser Service Fabric, ou AKS - tous deux utilisant Kestrel brut. SF et AKS ont des caractéristiques différentes. Google pour "Service Fabric vs AKS" et prenez un grand café.

J'ai créé un guide étape par étape pour créer un test et déployer un service grpc à l'aide de .NET Core 3.0
https://github.com/rupeshtech/k8s-grpc-dotntecore

Je viens de me pencher sur ce problème, donc je n'ai encore rien essayé; mais quelqu'un a-t-il essayé d'utiliser Azure Web App pour (Container https://azure.microsoft.com/en-us/services/app-service/containers/) ?

J'exécute un tas de microservices basés sur docker sur Azure App Services et j'ai eu très peu de problèmes et m'a permis de contourner d'autres caractéristiques limitantes de l'offre OOB App Service.

@ikemtz gRPC fonctionne lors de l'utilisation de kestral (c'est-à-dire lors de l'exécution dans des conteneurs).

@rupeshtech Merci, mais votre article n'est pas lié au problème.

Ce problème concerne l'hébergement de gRPC (ou de toute application utilisant des en-têtes de fin) dans IIS ou Azure App Service.

Ce serait bien si c'était un gros avertissement audacieux sur les docs...

aspnet/AspNetCore.Docs#14684

C'est désormais implémenté .

@ikemtz J'ai tenté d'exécuter un test de base pour utiliser gRPC dans un conteneur Linux exécuté dans une application Web Azure pour conteneurs et cela ne fonctionnerait pas pour moi. Impossible de trouver des erreurs signalées nulle part, mais le conteneur ne répondait même pas aux pings HTTP.
C'est dommage. Je ne suis pas prêt à passer à AKS juste pour obtenir cette fonctionnalité, donc je suppose que je vais m'en tenir aux bons services HTTP à l'ancienne pour le moment.

@searus si vous utilisez une machine virtuelle à la place (fonctionnant en azur)

@GoranHalvarsson Je ne suis pas prêt à passer de PaaS à IaaS juste pour utiliser cette technologie. Je vais juste attendre qu'Azure App Service puisse prendre en charge cela.

@davidfowl Une feuille de route à ce sujet ?

Déployer dans un conteneur à l'aide de Kestral, c'est bien, mais c'est facile à dire
en utilisant Lets Encrypt dans IIS ou un service d'application qui me retient vraiment.
S'il existe des guides concis sur la façon d'exécuter un domaine personnalisé avec Lets
chiffrer sur Kestrel dans un conteneur, puis je saute dans gRPC la tête la première
sinon, il est très difficile de justifier les frais généraux liés à la création de produits personnalisés
déploiement juste pour accueillir la nouvelle pile.

Le mer. 16 octobre 2019 à 06h46 Russell Seamer [email protected]
a écrit:

@GoranHalvarsson https://github.com/GoranHalvarsson Je ne suis pas préparé
de passer du PaaS à l'IaaS juste pour utiliser cette technologie. je vais juste
attendez qu'Azure App Service puisse le prendre en charge.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aspnet/AspNetCore/issues/9020?email_source=notifications&email_token=AMNAZYUWLYLGC5ZGB4GAFITQO2TCFA5CNFSM4HDHMSDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLFDDI5#issuecomment-5422
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/AMNAZYTKUYYBWKSW6AMQDHTQO2TCFANCNFSM4HDHMSDA
.

Avec cela, Azure Functions et tout ce qui se trouve au-dessus d'App Service ne peuvent pas vraiment utiliser gRPC et HTTP/2. Une chronologie serait bien, même pour les aperçus privés/publics.

Nous travaillons actuellement sur les changements dans http.sys. Après cela, nous devons réagir à ces changements dans IIS et ARR. Ensuite, nous devons mettre à jour la version de Windows exécutée dans le service d'application pour tirer parti de ces modifications dans IIS.

Le travail a été annoncé, mais il est vraiment difficile d'estimer combien de temps il faudra aux clients pour l'obtenir. Nous vous tiendrons au courant de l'avancement des choses.

J'ai l'impression que c'est quelque chose dont je ne suis malheureusement pas surpris (que l'implémentation de nouvelles fonctionnalités http nécessite des mises à jour du noyau). De toute évidence, IIS n'existe pas sur Linux / macosx, mais je serais surpris si l'ajout de la prise en charge de grpc à d'autres serveurs we pour d'autres systèmes d'exploitation... nécessite beaucoup de mise à jour du noyau.

Peut-être que c'est un argument/exemple décent pour le découplage... Il suffit de dire

J'ai l'impression que c'est quelque chose dont je ne suis malheureusement pas surpris (que l'implémentation de nouvelles fonctionnalités http nécessite des mises à jour du noyau). De toute évidence, IIS n'existe pas sur Linux / macosx, mais je serais surpris si l'ajout de la prise en charge de grpc à d'autres serveurs we pour d'autres systèmes d'exploitation... nécessite beaucoup de mise à jour du noyau.

Peut-être que c'est un argument/exemple décent pour le découplage... Il suffit de dire

Je suis d'accord. Cela a probablement quelque chose à voir avec IIS exécutant un protocole de bas niveau directement lié au noyau. Cela semble étrange, mais au moins nous avons la confirmation que cela est en cours d'élaboration et que l'adoption n'est pas complètement un ciel bleu.

Vous souvenez-vous quand vous avez dû effectuer une mise à niveau vers Windows 8 pour bénéficier de la prise en charge de WebSocket ? moi aussi 😄

Oui, on s'en souvient ! Voici le scoop : gRPC est publié dans .NET-Core et nous utilisons Azure App Services, il est donc important d'avoir une option, au moins pour tester, dès que possible. Quelqu'un peut-il nous dire quand cette synchronisation avec les fonctionnalités .NET-Core publiées se produira dans Azure App Services ? Ou une solution de contournement réalisable. Merci

Merci de nous contacter. En raison de l'absence d'activité sur ce problème, nous le fermons afin de garder notre arriéré propre. Si vous pensez qu'il existe un problème lié au framework ASP.NET Core, qui n'a pas encore été résolu, veuillez signaler un nouveau problème.

@anurse , comment gardons-nous ce problème ouvert ?

Il a été mis dans Discussions et question étiquetée. Rouvert.

Y a-t-il encore une ETA à ce sujet ?

Existe-t-il des alternatives viables pour faire fonctionner gRPC dans un environnement de production ?
J'ai regardé certaines choses et il semble que l'héberger sur AKS est une option, je veux juste m'assurer que nous ne faisons pas des choses qui ne nous aideront pas à résoudre notre problème.

Nous essayons actuellement de faire fonctionner une sorte d'environnement de production pour ces projets :
Projet IdentityServer qui communique avec une API via gRPC
5 portails Web qui communiquent avec une API via gRPC
L'API qui communique avec un bot Discord (ASP.NET Core) via gRPC.

Nous avons essayé de les héberger sur un VPS mais je ne sais pas si nous pouvons réellement les héberger dans un environnement de production en utilisant simplement Kestrel si nous voulons que toutes ces applications vivent sur le même VPS.

Quelqu'un a-t-il une option pour nous afin que nous puissions avoir plusieurs domaines (1 domaine, les autres sont des sous-domaines) avec 1 adresse IP sur 1 VPS exécutant tous les projets en utilisant uniquement Kestrel (en raison des limitations dans IIS, Http.Sys, les fenêtres).

(Ou toute autre méthode qui nous permettra d'héberger tout cela dès que possible)

Merci d'avance!

(ÉDITER)

Nous utilisons Let's Encrypt ( https://github.com/natemcmaster/LetsEncrypt ) pour obtenir un certificat SSL

(MODIFICATION 2)
Nous avons également essayé de contacter @davidfowl à ce sujet sur Twitter
https://twitter.com/DapperDino4/status/1204119195765682177 et
https://twitter.com/DapperDino4/status/1204119695344971778

Y a-t-il encore une ETA à ce sujet ?

Ajout de @shirhatti et @Tratcher qui ont travaillé dessus.

Le timing est difficile à cerner pour le moment. IIS est un composant Windows et dépend de http.sys, qui est également un composant Windows. Ni IIS ni http.sys ne disposent de fonctionnalités HTTP/2 suffisantes pour prendre en charge gRPC. Nous avons travaillé en étroite collaboration avec ces équipes pour obtenir les modifications, et elles sont toutes sur la bonne voie pour une prochaine version, mais ne seront pas disponibles avant la mise en ligne d'une version de Windows Server avec les modifications appropriées.

@JamesNK pouvez-vous parler de la disponibilité d'alternatives comme gRPC-web ?

Contexte pour les personnes qui ne savent pas ce qu'est gRPC-Web : https://grpc.io/blog/state-of-grpc-web/. Comme il utilise HTTP/1.1, les restrictions Azure App Service ne s'y appliquent pas. L'inconvénient est l'absence d'avantages HTTP/2 (multiplexage, compression d'en-tête) et l'absence de streaming client ou bidirectionnel.

Le proxy inverse gRPC-Web Envoy est disponible dès maintenant, mais ce n'est pas facile à configurer. Et il n'y a pas de client .NET gRPC-Web.

L'équipe ASP.NET Core n'a pas encore décidé si nous allons nous engager officiellement à prendre en charge gRPC-Web. Je regarde maintenant gRPC-Web et à quoi il pourrait ressembler dans .NET Core. Dans quelques semaines, je pourrai en dire plus, et peut-être avoir un aperçu expérimental que les gens pourront essayer en janvier.

Comme IIS ne le prend pas en charge, le service netcore gRPC peut-il être hébergé derrière Nginx ?

@ Dennis-Petrov Je fais exactement cela. J'ai suivi ce document https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-3.1 et gRPC fonctionne très bien

Puis-je poser une question stupide : pourquoi cela ne fonctionne-t-il pas dans un Azure App Service sur Linux App Service Plan ?

IIS est-il également impliqué quelque part dans le pipeline ?

@searus Il existe des couches communes entre les services frontend et App indépendamment de Linux/Windows. C'est-à-dire qu'actuellement, l'interface App Service reçoit les connexions HTTP/2, puis les connexions internes sont transmises en tant qu'"ancien" HTTP aux agents de service d'application individuels. Je suis sûr que la prise en charge complète de gRPC est en cours, mais cela demande un certain effort car les composants internes doivent être mis à jour, testés et publiés.

Merci @devlead.
Je pensais (peut-être naïvement) qu'un plan de service d'application Linux était entièrement Linux.
J'apprécie pleinement l'effort impliqué ici, et merci d'avoir pris le temps d'expliquer.

Je suis sûr qu'il est en cours pour prendre pleinement en charge gRPC

C'est définitivement en chantier. Nous y travaillons activement mais ne pouvons pas garantir un calendrier (il y a plusieurs équipes indépendantes qui doivent se coordonner ici). @devlead a raison concernant la prise en charge d'Azure App Service Linux. Le proxy frontal exécute IIS. Il prend en charge la réception HTTP/2 du client, mais lorsqu'il transmet le trafic par proxy à votre application, il rétrograde vers HTTP/1.1. C'était OK (mais pas idéal) pour les applications normales, mais comme gRPC nécessite des fonctionnalités HTTP/2, il ne convient pas à celles-ci.

Oui, j'ai déjà créé un service qui s'exécute en tant que service hébergé générique. Je l'ai porté sur le nouveau modèle asp net core 3 et je l'ai fait fonctionner sur Kestrel auto-hébergé, mais je cherche actuellement à l'héberger derrière iis et, espérons-le, à le déployer en tant que service d'application dans Azure. Je n'arrive pas à faire fonctionner l'ancien (iis).

@moodya peux-tu partager avec nous comment tu as fait ça ??

Oui, j'ai déjà créé un service qui s'exécute en tant que service hébergé générique. Je l'ai porté sur le nouveau modèle asp net core 3 et je l'ai fait fonctionner sur Kestrel auto-hébergé, mais je cherche actuellement à l'héberger derrière iis et, espérons-le, à le déployer en tant que service d'application dans Azure. Je n'arrive pas à faire fonctionner l'ancien (iis).

@moodya peux-tu partager avec nous comment tu as fait ça ??

Le modèle gRPC est crécerelle auto-hébergé par défaut. Cela ne fonctionnera pas dans le service d'application pour les raisons décrites dans ce fil.

Bien qu'il ne puisse pas être hébergé dans le service d'application, disons que nous hébergeons le service grpc sur aks, y a-t-il un problème pour appeler grpc à partir du service d'application ? Le client grpc fonctionnera-t-il au moins sur le service d'application ?

Bien qu'il ne puisse pas être hébergé dans le service d'application, disons que nous hébergeons le service grpc sur aks, y a-t-il un problème pour appeler grpc à partir du service d'application ? Le client grpc fonctionnera-t-il au moins sur le service d'application ?

Oui, les clients doivent travailler. La limitation concerne uniquement les demandes entrantes, pas les demandes sortantes.

Peut-être une question stupide, mais pourquoi cela fonctionne-t-il si j'exécute le service gRPC dans Debug avec IIS Express ? Par exemple, j'ai une application Web (Razor Pages, .net core 3.1) qui appelle un service gRPC [mis à niveau à partir d'une application framework mvc parlant à un service wcf, si quelqu'un s'en soucie]. Si je les débogue tous les deux sur mon poste de travail, avec le service gRPC dans IIS Express, l'application Web peut très bien communiquer avec le service. En raison du comportement de proxy @anurse décrit ci-dessus, lorsque le service est hébergé dans IIS, j'obtiens l'exception selon laquelle gRPC nécessite HTTP/2. IIS Express proxy vers Kestrel est-il différent de IIS ?

De plus, ce n'est peut-être pas l'endroit pour cela, mais j'aimerais humblement demander que la page ci-dessous reçoive une petite explication du comportement de proxy IIS/App Service. J'ai (peut-être bêtement) passé une journée entière à essayer de déjouer IIS parce que je pensais pouvoir le forcer à utiliser le proxy dans HTTP/2 si l'application fonctionnait hors processus dans 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 ne devrait pas fonctionner pour les mêmes raisons que IIS.

@Tratcher Ah oui, vous avez raison. J'exécutais le service gRPC en tant qu'auto-hébergé, pas IIS Express. Merci!

Quelqu'un a-t-il un tutoriel sur la façon de faire fonctionner cela dans AKS? (points bonus pour le débogage avec vs code dans aks localement sans avoir à reconstruire les conteneurs afin que nous ayons toute la pile avec .net core dev, jusqu'au déploiement sur azur en utilisant azur devops et aks).

Plus important encore, qu'utilisez-vous dans AKS pour envoyer par proxy le trafic Web vers les pods AKS sans avoir à utiliser ngix dans le pod lui-même (c'est-à-dire un équilibreur de charge azur ou quelque chose ?)

Bien qu'il ne puisse pas être hébergé dans le service d'application, disons que nous hébergeons le service grpc sur aks, y a-t-il un problème pour appeler grpc à partir du service d'application ? Le client grpc fonctionnera-t-il au moins sur le service d'application ?

Oui, les clients doivent travailler. La limitation concerne uniquement les demandes entrantes, pas les demandes sortantes.

Malheureusement, cela ne semble pas être le cas avec l'application Web basée sur .Net Core 3.1 appelant un service grpc (dans ce cas, le code Pyhton s'exécutant sur une machine virtuelle) lorsqu'il est hébergé sur Azure Web Apps - expire. Lors de l'exécution exacte du même code à partir de localhost, l'appel passe (même service VM).

@lyulyok pouvez-vous collecter des diagnostics et ouvrir un problème séparé ? Il n'y a aucun problème connu avec le client ici.

Quelqu'un a-t-il un tutoriel sur la façon de faire fonctionner cela dans AKS?

Veuillez ouvrir un nouveau sujet pour en discuter ou demander sur Stack Overflow . Gardons ce fil sur le sujet, d'autant plus que de nombreuses personnes s'intéressent au statut de gRPC sur IIS et HTTP.sys et que chaque commentaire envoie un ping à chaque personne qui s'y trouve. Je vais cacher les commentaires hors sujet, n'hésitez pas à poster de nouveaux problèmes si vous avez d'autres questions.

Oui, j'ai déjà créé un service qui s'exécute en tant que service hébergé générique. Je l'ai porté sur le nouveau modèle asp net core 3 et je l'ai fait fonctionner sur Kestrel auto-hébergé, mais je cherche actuellement à l'héberger derrière iis et, espérons-le, à le déployer en tant que service d'application dans Azure. Je n'arrive pas à faire fonctionner l'ancien (iis).

La prise en charge expérimentale de gRPC-Web dans .NET est désormais disponible. gRPC-Web fonctionne avec HTTP/1.1 et HTTP/2, et s'exécute dans IIS et Azure App Service.

Nous continuons à travailler vers HTTP/2 gRPC exécuté dans Azure App Service, mais gRPC-Web est quelque chose que vous pouvez utiliser aujourd'hui . Lorsque le travail de prise en charge de HTTP/2 dans IIS et Azure App Service sera terminé, il sera simple de faire basculer une application .NET de gRPC-Web vers HTTP/2 gRPC.

Billet de blog : https://devblogs.microsoft.com/aspnet/grpc-web-experiment
Documentation : https://docs.microsoft.com/aspnet/core/grpc/browser

J'ai un client grpc en cours d'exécution dans le service d'application et le service fonctionne très bien dans aks, au cas où quelqu'un d'autre voudrait essayer aussi

@andrew-vdb Pouvez-vous publier la configuration s'il vous plaît ?

Salut @JamesNK ,
lié à votre commentaire https://github.com/dotnet/aspnetcore/issues/9020#issuecomment -579597202 et au fait que gRpc-Web semble actuellement être _un projet expérimental, pas un produit engagé._

• Ai-je besoin de gRpc-Web pour déployer sur IIS ? Sinon, ce n'est pas du tout possible ?
• Disposez-vous d'une ETA indiquant quand il sera possible de déployer sur IIS sans gRpc-Web ?
• Avez-vous un ETA lorsque gRpc-Web sera officiellement pris en charge par Microsoft ?

Ai-je besoin de gRpc-Web pour déployer sur IIS ? Sinon, ce n'est pas du tout possible ?

Actuellement, gRPC sur HTTP/2 ne fonctionne pas dans IIS. gRPC-Web fonctionne.

Disposez-vous d'une ETA indiquant quand il sera possible de déployer sur IIS sans gRpc-Web ?

Non. Il faut du temps pour que les modifications soient apportées à Windows et rendues publiques.

Avez-vous un ETA lorsque gRpc-Web sera officiellement pris en charge par Microsoft ?

Pas pour le moment.

pour votre information
J'ai une application (ASP.Net Core 3.2.0-Preview1) dans laquelle j'ai remplacé une API REST DAL par une DAL gRPC-Web. J'ai suivi les conseils du blog de Steve Sanderson. Ma solution peut être exécutée en tant que CSB ou SSB et j'ai réussi avec gRPC-Web dans les deux configurations (j'ai dû passer à une version plus récente des packages gRPC.* nuget).

J'ai fait par erreur d'autres mises à jour à partir des versions nocturnes et actuellement mes packages gRPC sont tous à la version 2.28.0-dev202003020801. Je dis par erreur parce que mes deux déploiements de solution de travail échouent chacun.

SSB - Le client signale une erreur de "Composant de rendu d'exception non géré : Impossible de charger le fichier ou l'assembly 'System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. Le système ne peut pas trouver le fichier spécifié. "
En ajoutant simplement un package nuget explicite de System.Text.Json (4.7.1) à mon projet de serveur Web, cette erreur disparaît et tout fonctionne.
[EDIT] Le retour aux versions 2.27.0/2.27.0-Pre1 pour tous les packages gRPC.* du flux NuGet résout ce problème.

CSB - Au même point dans le client lors de la réception de la première réponse gRPC-Web, j'obtiens une erreur de "WASM : Grpc.Core.RpcException : Status(StatusCode=Internal, Detail="Bad gRPC response. Response protocol downgraded to HTTP /1.1.")". Je n'ai pas de solution de contournement pour cela, mais ce n'est pas critique puisque nous expédions SSB jusqu'à ce que CSB soit publié.
[EDIT] Le retour aux versions 2.27.0/2.27.0-Pre1 pour tous les packages gRPC.* du flux NuGet résout ce problème.

Désolé pour la verbosité, mais enfin, deux questions :

• Est-il possible d'utiliser un autre sérialiseur/désérialiseur json dans gRPC/gRPC-Web ?
• Les packages gRPC/gRPC-Web seront-ils "alignés" sur ASP.Net Core 3.2-Preview 2 ou l'accès aux versions nocturnes sera-t-il nécessaire ?

Salut @JamesNK ,
Mon client a migré vers gRpcWeb, mais nous avons trouvé une limitation importante (dont je n'ai trouvé aucune documentation) : la taille maximale des messages est de 3067 caractères.
Si à partir du service client habituel du service gRpc de base, converti en gRpc-Web, cette ligne échouera (car la chaîne est de 3068 caractères, 1 au-dessus de la limite) :

// Configurer un canal pour utiliser gRPC-Web
var handler = new GrpcWebHandler(GrpcWebMode.GrpcWebText, new HttpClientHandler());
// Le numéro de port (5001) doit correspondre au port du serveur gRPC.
en utilisant var channel = GrpcChannel.ForAddress(" https://localhost :5001", new GrpcChannelOptions
{
HttpClient = nouveau HttpClient (gestionnaire)
});
var client = new Greeter.GreeterClient(canal);
var réponse = attendre client.SayHelloAsync(new HelloRequest { Nom = nouvelle chaîne('A', 3068 ) });
Console.WriteLine("Salut : " + réponse.Message);
Console.WriteLine("Appuyez sur n'importe quelle touche pour quitter...");
Console.ReadKey();

Je joins une solution repro contenant client et serveur.
GrpcWeb.zip

Le projet équivalent avec gRpc normal était capable de gérer des messages de 20k sans aucun problème.
Pouvez-vous s'il vous plaît me conseiller si je peux configurer quelque chose pour supprimer cette limite?

@curia-damiano pouvez-vous déposer un nouveau problème avec ça ? Gardons ce fil pour discuter de la fonctionnalité spécifique de prise en charge de gRPC ( sans gRPC-Web) sur IIS/Azure App Service. gRPC-Web a été soulevé plus tôt sur ce fil parce que c'est une bonne alternative, mais j'aimerais garder ce fil concentré sur l'objectif principal de la prise en charge native de gRPC.

@MarkStega pouvez-vous également déposer un nouveau problème avec votre question ? Essayons d'éviter que ce fil ne soit surchargé de plusieurs sujets possibles (même s'ils sont liés). Ce problème suit la prise en charge native de gRPC sur IIS/Azure App Service

Pouvons-nous avoir une ETA lorsque gRPC sera disponible sur Azure App Service, s'il vous plaît ?

Nous n'avons pas de mises à jour ETA. Nous mettrons à jour ce fil lorsque nous aurons un ETA. Cela nécessite des modifications de Windows et nous travaillons avec cette équipe pour essayer de les mettre en place dès que possible, mais leur calendrier n'est pas sous notre contrôle direct.

Pouvons-nous créer un service gRPC qui est packagé en tant que conteneur et s'exécute dans une application Web pour conteneurs dans Azure ?

@fgheysels Non. Il est toujours derrière IIS en tant que proxy qui ne peut pas gérer la fonctionnalité HTTP/2 requise.

Il y a 3 façons de le faire maintenant :

1. Exposez une adresse IP publique et utilisez une machine virtuelle.
2. Utilisez Kubernetes avec Azure Application Gateway Ingress (dont les instructions échouent car le script helm est obsolète et ne peut donc pas être utilisé pour le moment) ou utilisez nginx ingress (vous perdez le pare-feu et les atténuations DoS)
3. Utilisez les services Azure Container et exposez-le à une adresse IP publique ou utilisez nginx pour le proxy inverse ou utilisez Azure Application Gateway pour le proxy inverse.

Rien d'autre ne fonctionnera.

@JohnGalt1717

Utilisez les services Azure Container et exposez-le à une adresse IP publique ou utilisez nginx pour le proxy inverse ou utilisez Azure Application Gateway pour le proxy inverse.

Azure Application Gateway ne fonctionnera pas actuellement. Il a la même limitation

Je suppose que nous pourrions l'exécuter sur le cloud gpogle avec notre code .net ?

Le mercredi 1er avril 2020, 7 h 26 Sourabh Shirhatti, [email protected]
a écrit:

@JohnGalt1717 https://github.com/JohnGalt1717

Utilisez les services Azure Container et exposez-les à une adresse IP publique ou utilisez nginx pour
inversez-le par proxy ou utilisez Azure Application Gateway pour inverser le proxy.

Azure Application Gateway ne fonctionnera pas actuellement. Il a le même
limitation

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606855605 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7LVZJTQ2QPRHVB5G5TRKJGYLANCNFSM4HDHMSDA
.

@shirhatti Ok, donc ça ne fait qu'empirer. Microsoft a effectivement fait en sorte que .NET avec gRPC ne puisse pas être exécuté sur Microsoft Azure. Si ce n'était pas si triste, ce serait FUNNY AS HELL.

Voici donc la liste mise à jour :

1. Exposez une adresse IP publique et utilisez une machine virtuelle (mettez haproxy, nginx ou quelque chose sur la machine virtuelle pour inverser le proxy)
2. Utilisez Kubernetes (AKS) avec nginx ingress.

Je ne crois pas qu'ACS fonctionnera car il place toujours IIS devant lui si ma mémoire est bonne.

Et # 2 pourrait ne pas fonctionner non plus car l'équilibreur de charge pourrait également être IIS sous Windows ... Quelqu'un a-t-il réellement réussi à faire fonctionner cela n'importe où dans Azure?

Je pense que ce ticket github définit ce que je dis depuis des mois sur l'équipe .NET et ce qui se passe.

Microsoft a effectivement fait en sorte que .NET avec gRPC ne puisse pas être exécuté sur Microsoft Azure. Si ce n'était pas si triste, ce serait FUNNY AS HELL.

Il n'y a rien ici de spécifique à .NET, la limitation se trouve dans l'infrastructure Windows et Azure liée à HTTP/2. Vous auriez le même problème avec d'autres webstacks dans Azure. Windows et Azure travaillent pour nous débloquer mais cela nécessite des modifications des composants fondamentaux qui mettent beaucoup de temps à se redéployer.

Tout cela est directement lié à .net. il est littéralement indiqué sur les sites Web azur et .net que .net est le langage d'azur.

Mais vous ne pouvez pas utiliser ce langage avec Azure, mais vous pouvez l'utiliser facilement sur AWS et Google Cloud.

C'est embarrassant comme avec tant de ratés massifs de la part de l'équipe .net ces derniers temps, mais leur arrogance est à son plus haut niveau sans raison.

Et ils ne nous ont même pas donné de solution de rechange autre que l'utilisation du Web gRPC, qui est un poc et non un vrai produit.

Oui, mais nous pouvons exécuter toute la pile .net sur Google Cloud, .net prend en charge
gRPC tout va bien. Donc, cela ne me dérange pas de courir sur GPC jusqu'à ce qu'ils puissent résoudre ce problème
sur Azur.
Je développe des services d'application ou des applications sans serveur, je ne suis intéressé par aucun
solutions de conteneurs car elles sont trop coûteuses pour les déploiements à grande échelle
J'ai.

Le mer. 1er avril 2020 à 9h57 James Hancock [email protected]
a écrit:

Tout cela est directement lié à .net. il dit littéralement sur l'azur et
sites Web .net que .net est le langage d'azur.

Mais vous ne pouvez pas utiliser ce langage avec Azure, mais vous pouvez l'utiliser sur AWS et
Google cloud facilement.

C'est embarrassant comme avec tant de ratés massifs de la part de l'équipe .net
ces derniers temps, mais leur arrogance est à un niveau record sans raison.

Et ils ne nous ont même pas donné de solution de contournement d'autre type que d'utiliser
gRPC web qui est un poc pas un vrai produit.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606927717 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7MRPFQBH52XDHUNP63RKJYMVANCNFSM4HDHMSDA
.

Tout d'abord, Microsoft devrait être terrifié par ce que vous venez de dire.

Deuxièmement, je viens de faire passer nos éléments Web à azure kubernetes en utilisant des nœuds virtuels et cela nous coûte environ la moitié de ce que les services d'application nous coûtaient et double les performances.

Aks est un gâchis de choses qui ne fonctionnent pas correctement et une documentation obsolète, mais une fois que vous obtenez des identités gérées et une adresse IP publique en place, le reste est simple.

Oui mais c'est vraiment un gros changement pour Microsoft ! et j'aime le
simplicité de gRPC bien que je puisse passer à http Rx. je n'ai pas pu obtenir mon
websocket à la solution pour fonctionner car il semblait avoir des problèmes SSL/TLS.
On dirait que je peux obtenir des kubs azur au même prix que mes services d'application S1,
il faut vérifier les performances.

Le mer. 1er avril 2020 à 10 h 13 James Hancock [email protected]
a écrit:

Tout d'abord, Microsoft devrait être terrifié par ce que vous venez de dire.

Deuxièmement, je viens de passer nos trucs Web à Azure kubernetes en utilisant
nœuds virtuels et cela nous coûte environ la moitié de ce que coûtaient les services d'application
nous et a le double de la performance.

Aks est un gâchis de choses qui ne fonctionnent pas correctement et qui sont obsolètes
documentation, mais une fois que vous obtenez des identités gérées et une adresse IP publique en place
le reste est simple.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606933338 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7O3N4XVCWM5MGCTS33RKJ2I7ANCNFSM4HDHMSDA
.

Tout cela est directement lié à .net. il est littéralement indiqué sur les sites Web azur et .net que .net est le langage d'azur.

Ce n'est manifestement pas vrai. Les piles TCP et HTTP sous-jacentes ne sont pas écrites à l'aide de .NET. Microsoft travaille à adapter sa base pour gRPC. Il s'agit d'une livraison complexe qui a des répercussions sur tout ce qui s'exécute sur les serveurs Windows, y compris Azure lui-même.

C'est embarrassant comme avec tant de ratés massifs de la part de l'équipe .net ces derniers temps, mais leur arrogance est à son plus haut niveau sans raison.

Cette manière de pleurnicher improductif, enfantin et absurde est totalement inutile. Cela n'a rien à voir avec l'équipe .NET. Ils ont porté la plupart de gRPC de manière native afin que nous puissions travailler sur nos PoC et utiliser des solutions de contournement si nécessaire, et comme des adultes matures, nous attendrons que la plate-forme de base soit prête à livrer les pièces finales.

@oising

.NET est le langage d'Azure. Microsoft le commercialise comme tel. .NET gRPC ne peut pas être compris par Azure. C'est 100% vrai. C'est un échec complet qu'il n'était pas disponible à la sortie et pire encore un an plus tard. Il n'est pas pertinent que les piles ne soient pas écrites par l'équipe .NET au sein de Microsoft . Microsoft est Microsoft . Je me fiche de leurs petits fiefs, de leurs frontières artificielles et de leurs priorités non alignées. Je me soucie des meilleurs produits possibles qui fonctionnent réellement. Peu m'importe que Microsoft prétende que parce que .NET est open source, cela n'en fait plus un produit payant. C'est un produit payant. Je le paie indirectement en utilisant Azure, Office et Windows.

Et non, nous n'attendrons pas. Nous allons passer à un autre fournisseur de cloud où cela fonctionne. C'est ce que Microsoft pousse sans cesse. Enfer, j'avais une personne du support Microsoft, qui disait et je cite "Si vous n'aimez pas [le fait que nous ayons cassé cela au moment de l'exécution par conception], vous pouvez utiliser le produit de quelqu'un d'autre" Pour environ 100 clients. Oui, eh bien, j'en connais 8 qui ont fait exactement ce qu'ils ont suggéré jusqu'à présent et 30 à 40 autres qui enquêtent sur le faire. La perte de revenus estimée pour MS à partir de cet agent de support est d'environ 2,8 millions USD et continue.

Oui, c'est exactement ce que nous allons tous faire. Merci pour le conseil Microsoft. Nous quitterons Azure, et nous quitterons .NET si la direction ne se fait pas avoir la tête bien vite.

Ce dont ils doivent s'inquiéter, c'est lorsque des gens comme moi cessent de se plaindre de ces échecs publics massifs où ils n'en assument pas la responsabilité, et au lieu de cela ils n'entendent rien et tout le monde s'en fiche. Cela s'est produit il y a environ un an lorsque Xamarin Forms a passé 18 semaines sans pouvoir se développer sur l'Apple Store, l'Android Store et le Windows Store avec la même version de Xamarin Forms et de Xamarin en général. J'ai posté, ils l'ont admis, et 18 semaines plus tard, une seule personne avait suivi le rapport de bogue alors qu'il s'agissait d'une pause complète, pas seulement d'un cas marginal. Pourquoi? Personne ne se soucie de Xamarin Forms et est parti et a commencé à utiliser des outils non Microsoft et Microsoft a perdu le bureau et le téléphone portable. (et continue d'essayer la même approche ratée pour le reconquérir même avec Neo et Duo) À l'heure actuelle, les gens pensent toujours qu'ils ont une voix dans .NET et que leurs plaintes ne resteront pas dans l'oreille d'un sourd et que tout cela sera corrigé. La direction de .NET travaille très dur pour préciser que ce n'est pas le cas et que le résultat sera identique à Xamarin Forms.

La pièce d'en-tête de la bande-annonce est également quelque chose dont nous avons besoin de manière plus urgente que prévu pour Stack Overflow. Pouvons-nous aider à la priorisation ici ?

Cas d'utilisation

Nous effectuons des chronométrages via les en-têtes de serveur pour les capturer dans nos journaux HTTP (dans HAProxy). Nous avons plusieurs en-têtes comme X-Sql-DurationMs , X-Sql-Count , X-Reds-DurationMs , etc. afin que nous puissions les capturer, les enregistrer et agréger les métriques sur eux. Si plus de détails vous aident, il y a une section dans cet article de blog . Cela a assez bien fonctionné dans ASP.NET MVC 5 (framework complet) car la réponse entière a été mise en mémoire tampon. Étant donné que nous effectuons très peu d'interrogations dans les vues, il s'agissait d'une stratégie de synchronisation précise d'environ 99 % qui a bien fonctionné dans l'ensemble.

Maintenant, nous fonctionnons sur .NET Core et tout est en streaming. Le problème avec cela est que les en-têtes de synchronisation sont envoyés avant qu'ils ne soient terminés, en raison du manque de mise en mémoire tampon. C'est un compromis difficile. Ce serait rapidement réparable si nous pouvions envoyer et capturer ces horaires sous forme d'en-têtes de bande-annonce. Mais il semble que nous soyons ici dans un bloqueur IIS et que nous soyons à la merci de la mise à niveau (ou du retrait d'IIS) pour que cette fonctionnalité fonctionne.

Personnellement, j'ai aussi d'autres utilisations, comme MiniProfiler envoyant l'en-tête Server-Timing (il est prêt et attend depuis environ 3 ans maintenant ).

Comment pouvons-nous aider avec la priorité à ce sujet? Y a-t-il une chance que des cas d'utilisation supplémentaires aident à le déplacer ?

Merci @NickCraver. Ce travail est déjà hautement prioritaire et en cours, mais le déployer sur des services comme AppService est compliqué et prendra encore un certain temps.

Est-il possible qu'il soit bientôt pris en charge dans IIS, quel que soit le déploiement d'Azure ? -- Je n'ai vraiment besoin que d'un client dans IIS - si cela compte du tout. Alors, IIS peut-il être un client http2 ?

Je dois convenir, que c'est inquiétant, qu'il semble impossible pour les employés de Microsoft, de prendre leurs jambes (ou de téléphoner en ce moment) et de passer à cette autre équipe. Et les ennuyer tellement qu'ils déploient un correctif en une journée.
Si l'équipe asp / .net n'avait pas poussé pour grpc, cette période d'attente serait bien. Mais puisque vous commercialisez un produit qui ne peut pas être utilisé en production, il est malheureusement temps de prendre des mesures désespérées et de rompre les rangs.

Si vous vous en souciez, vous y arriverez.

Edit : je sais "un jour" c'est exagéré mais ça fait un an !

Existe-t-il des documents expliquant comment déployer gRPC sur Azure ? au moins en utilisant AKS? Ce serait bien d'avoir quelque chose.

Existe-t-il des documents expliquant comment déployer gRPC sur Azure ? au moins en utilisant AKS? Ce serait bien d'avoir quelque chose.

@lumogox J'ai créé un guide étape par étape pour déployer gRPC sur Azure.
https://github.com/rupeshtech/k8s-grpc-dotntecore

@rupeshtech J'ai en fait jeté un coup d'œil à votre guide, cependant, cela ne fonctionne pas si vous souhaitez afficher un message dans le chemin racine du port 80.

Super truc mais je veux déployer sur les services d'application et nous n'avons toujours pas d'ETA.
Il a été affirmé par l'un des autres gars qu'AKS était moins cher que l'application
services, j'ai du mal à y croire?
Quoi qu'il en soit, je souhaite uniquement utiliser des services d'application ou une infrastructure sans serveur.

Le mar. 12 mai 2020 à 17:51 Luis Molina [email protected]
a écrit:

@rupeshtech https://github.com/rupeshtech J'ai en fait jeté un coup d'œil à
votre guide, cependant, cela ne fonctionne pas si vous souhaitez afficher un message dans le
chemin racine dans le port 80.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627175783 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7MUWWWYCGMEK2FH663RRD5YPANCNFSM4HDHMSDA
.

AKS : b12, le cluster à 2 nœuds coûte 176 $/mois et vous procure des performances comparables à celles d'un p3.

Vous aurez besoin des éléments suivants pour que cela fonctionne :

1. Ingress nginx en tant que proxy inverse.
2. Application de base .net dockerisée
3. Modèles de déploiement pour votre application principale .net
4. Modèles de service pour ces déploiements
5. Le modèle d'entrée qui mappe vos entrées DNS
6. cert bot pour k8s ou votre propre cert pour mapper à l'ingress.
7. Désactivez SSL uniquement dans votre application .net, il se foutra du RP et activera la prise en charge du proxy dans le noyau .net.
8. IP publique
9. Registre de conteneurs Azure

C'est un processus en 30 parties pour le configurer dans Azure en ce moment et pratiquement rien de tout cela ne peut être fait via le portail GUI. Il leur manque l'association des registres de conteneurs, la configuration des fournisseurs d'entrée (Azure Application Gateway ni nginx ni haproxy, etc. n'ont d'interface graphique pour le configurer. Aucun des éléments du principal du service avec d'autres ressources, ni des éléments d'identité gérés n'est correctement automatisé non plus (et vous besoin des deux pour des raisons insondables).

Si vous effectuez un certificat générique, vous aurez également besoin d'accéder à votre DNS via l'un des fournisseurs de DNS pris en charge par le service certbot k8s.

Voici notre script pour configurer un environnement qui pourrait vous aider à démarrer :

Configuration Azure

1. Créer un AKS
2. az aks install-cli (si vous ne l'avez pas déjà fait)
3. az aks get-credentials --resource-group RGL-\ --nom XX-AKS-\
4. réseau az public-ip créer --resource-group MC_RGL-\ _XX-AKS-\ _eastus --name PIP-AKS-\ --sku Standard --allocation-method statique --query publicIp.ipAddress -o tsv
5. Mappez api, www, admin à l'adresse IP publique dans le DNS (c'est-à-dire beta.XX.com)
6. az identité créer -g RGL-\ -n XX-MI-AKS-\ -o json (Enregistrer le ClientId, PrincipalId, Id et Name)
7. affectation de rôle az créer --role Reader --assignee \ --scope /abonnements/\ /resourcegroups/RGL-\
8. Obtenir des informations sur le principal du service à partir des applications Azure Active Directory : XX-AKS-\ SP-xxxx (Nom d'enregistrement, ID client)
9. Créez un secret client sans expiration et enregistrez-le
10. az affectation de rôle créer --role "Opérateur d'identité gérée" --assignee \ --portée "\ "
11. Obtenez l'identifiant de la zone DNS : az network dns zone list --query "[].{ id : id, name: name}"
12. affectation de rôle az créer --assignee \ --role Contributeur --scope \
13. affectation de rôle az créer --assignee \ --role Contributeur --scope \
14. mise à jour az aks -n XX-AKS-\ -g RGL-\ --attach-acr clcr\
15. Ajouter une identité gérée (XX-MI-AKS-\ ) au coffre à clés

Kubernetes Let's encrypt (Si ce n'est pas la production)

1. kubectl créer un espace de noms ingress-basic
2. helm repo ajouter stable 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. Vérifiez que cela a pris : 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. Mettre à jour issuer.yaml avec l'abonnement et l'ID client du principe de service
7. Mettre à jour certificate.yaml vers l'adresse DNS
8. Mettez à jour ingress.yaml avec les informations de domaine, etc.
9. Créer une version Base64 du secret principal du service : echo \ | openssl base64
10. Mettre à jour secure-dazuredns.yaml avec le secret

OU Kubernetes Azure Application Gateway

1. Ne fonctionne pas. Désordre complet

Configuration complète de Kubernetes

1. kubectl appliquer -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Mettre à jour deploy-api avec le registre, le coffre de clés, l'environnement et la clé d'instrumentation
3. Mettre à jour le registre dans deploy-portal et deploy-admin
4. Mettre à jour les valeurs dans identity-binding.yaml (ClientId provient également de l'identité managée ci-dessus)
5. kubectl créer un espace de noms XX
6. kubectl config set-context --current --namespace=XX
7. kubectl appliquer -k ./\
8. Vérifier que le certificat est disponible : kubectl describe certificate XX-tls-secret

Oui, c'est vraiment difficile. Et non, il n'y a pas de moyen plus simple dans les k8. Votre seule autre option est une machine virtuelle avec une adresse IP publique et utilisez un RP devant votre application. Vous pouvez utiliser une machine virtuelle Linux et exécuter docker dessus, et installer HAproxy et votre application dans un conteneur docker avec un seul fichier docker-compose assez facilement.

Sinon, vous êtes foutu jusqu'à ce qu'ils commencent à déployer le noyau de Windows 2004 (printemps 2020) vers Azure. (en supposant qu'il soit arrivé là-bas et qu'il ne soit pas retardé jusqu'en novembre)

Wow mon pote c'est incroyable merci mais comme je suis aussi un très grand fan de
Azure Dev Ops avec une approche NoOps J'ai vraiment l'impression qu'AKS n'est tout simplement pas dans
ma ligue.
Surtout quand je peux probablement exécuter un service d'application décent pour un peu moins
que ça. Ou basculez-le vers une fonction Azure. Je n'ai pas pu obtenir mon websocket
solution à déployer sur Azure.
Je suis aussi un grand fan des extensions réactives et il y a de bons Rx
outils là-bas comme ça
https://github.com/lucassklp/Rx.Http
Pas sûr de l'évolutivité de cela cependant

Le mar. 12 mai 2020 à 22h09 James Hancock [email protected]
a écrit:

AKS : b12, le cluster à 2 nœuds coûte 176 $/mois et vous procure des performances comparables à celles d'un p3.

Vous aurez besoin des éléments suivants pour que cela fonctionne :

1. Ingress nginx en tant que proxy inverse.
2. Application de base .net dockerisée
3. Modèles de déploiement pour votre application principale .net
4. Modèles de service pour ces déploiements
5. Le modèle d'entrée qui mappe vos entrées DNS
6. cert bot pour k8s ou votre propre cert pour mapper à l'ingress.
7. Désactivez SSL uniquement dans votre application .net, il se foutra du RP et
   activez la prise en charge du proxy dans .net core.
8. IP publique
9. Registre de conteneurs Azure

Il s'agit d'un processus en 30 étapes pour le configurer dans Azure dès maintenant et virtuellement
rien de tout cela ne peut être fait via le portail GUI. Il leur manque l'association
registres de conteneurs, configuration des fournisseurs d'entrée (Azure Application
Gateway ni nginx ni haproxy, etc. n'ont d'interface graphique pour le configurer. Aucun des
Les éléments de principal de service avec d'autres ressources, ni les éléments d'identité gérés ne sont
correctement automatisé soit (et vous avez besoin des deux pour des raisons insondables).

Si vous faites un certificat générique, vous aurez également besoin d'accéder à votre DNS
via l'un des fournisseurs de DNS pris en charge par le service certbot k8s.

Voici notre script pour configurer un environnement qui pourrait vous aider à obtenir
a débuté:
Configuration Azure

1. Créer un AKS
2. az aks install-cli (si vous ne l'avez pas déjà fait)
3. az aks get-credentials --resource-group RGL- --name XX-AKS-
4. réseau az public-ip créer --resource-group MC_RGL-_XX-AKS-_eastus
   --name PIP-AKS- --sku Standard --allocation-method static --query
   publicIp.ipAddress -o tsv
5. Mappez api, www, admin à l'adresse IP publique dans le DNS (c'est-à-dire beta.XX.com)
6. az identity create -g RGL- -n XX-MI-AKS- -o json (Enregistrer le
   ClientId, PrincipalId, Id et Nom)
7. affectation de rôle az créer --role Reader --assignee --scope
   /abonnements//groupes de ressources/RGL-
8. Obtenez des informations sur le principal du service à partir des applications Azure Active Directory :
   XX-AKS-SP-xxxx (Nom d'enregistrement, ID client)
9. Créez un secret client sans expiration et enregistrez-le
10. affectation de rôle az créer --role "Opérateur d'identité gérée"
    --assignee --portée ""
11. Obtenez l'identifiant de la zone DNS : az network dns zone list --query "[].{ id :
    id, nom : nom}"
12. affectation de rôle az créer --assignee --role Contributor --scope
13. affectation de rôle az créer --assignee --role Contributor --scope
14. az aks update -n XX-AKS- -g RGL- --attach-acr clcr
15. Ajouter une identité gérée (XX-MI-AKS-) à Key Vault

Kubernetes Let's encrypt (Si ce n'est pas la production)

1. kubectl créer un espace de noms ingress-basic
2. helm repo ajouter stable
   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. Vérifiez que cela a pris : kubectl --namespace ingress-basic get services -o
   large -w nginx-ingress-controller
5. kubectl appliquer --validate=false -f
   https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
6. Mettre à jour issuer.yaml avec l'abonnement et l'ID client du principe de service
7. Mettre à jour certificate.yaml vers l'adresse DNS
8. Mettez à jour ingress.yaml avec les informations de domaine, etc.
9. Créer une version Base64 du secret principal du service : echo | ouvre SSL
   base64
10. Mettre à jour secure-dazuredns.yaml avec le secret

OU Kubernetes Azure Application Gateway

1. Ne fonctionne pas. Désordre complet

Configuration complète de Kubernetes

1. kubectl appliquer -f
   https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Mettre à jour deploy-api avec le registre, le coffre de clés, l'environnement et
   clé d'instrumentation
3. Mettre à jour le registre dans deploy-portal et deploy-admin
4. Mettre à jour les valeurs dans identity-binding.yaml (ClientId provient également du
   identité managée ci-dessus)
5. kubectl créer un espace de noms XX
6. kubectl config set-context --current --namespace=XX
7. kubectl appliquer -k ./
8. Vérifier que le certificat est disponible : kubectl describe certificate XX-tls-secret

Oui, c'est vraiment difficile. Et non, il n'y a pas de moyen plus simple dans les k8. Ton
la seule autre option est une machine virtuelle avec une adresse IP publique et utilise un RP devant votre
application. Vous pouvez utiliser une machine virtuelle Linux et exécuter docker dessus, et installer HAproxy et
votre application dans un conteneur docker avec un seul fichier docker-compose joli
facilement.

Sinon, vous êtes foutu jusqu'à ce qu'ils commencent à déployer le noyau à partir de
Windows 2004 (printemps 2020) vers Azure. (en supposant qu'il soit arrivé là-dedans et
n'est pas retardé jusqu'en novembre)

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627302354 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7P74W4DK5RP2BKKI7LRRE365ANCNFSM4HDHMSDA
.

Websockets est probablement une bonne alternative si vous ne vous êtes pas engagé sur gRPC et que vous vous concentrez sur Azure App Services.

Une fois que vous avez configuré k8s, Azure Devops est facile. Vous lui dites de construire le conteneur docker et de le déployer dans le référentiel azur avec la balise build:id , puis de vous libérer, exécutez kubectl pour lui dire de mettre à jour le conteneur de déploiement avec la bonne balise pour l'id de construction et il se déroulera de manière transparente la nouvelle version. La seule chose que nous avons faite est de créer un outil qui effectue les migrations EF avant cela afin que vous ne vous retrouviez pas avec plusieurs répliques k8s appelant le script de migration en même temps.

Magic mate merci beaucoup, je suis aussi vraiment dans la conception pilotée par domaine, donc je
Je suppose que je peux ajouter AKS à mon arsenal maintenant, mais je veux que mes clients passent à
sans serveur, je ne comprends pas pourquoi la plupart des gens ne semblent pas vouloir passer de
conteneurs ?

Le mar. 12 mai 2020 à 23h05 James Hancock [email protected]
a écrit:

Websockets est probablement une bonne solution si vous ne vous êtes pas engagé dans gRPC
et se concentrent sur Azure App Services.

Une fois que vous avez configuré k8s, Azure Devops est facile. Tu lui dis de construire
le conteneur docker et le déployer dans le référentiel azur avec le build:id
tag puis pour libérer vous exécutez kubectl pour lui dire de mettre à jour le déploiement
conteneur avec la bonne balise pour l'identifiant de construction et il suffira
déployer la nouvelle version en toute transparence. La seule chose que nous avons faite est de créer un outil
qui effectue les migrations EF avant de le faire afin que vous ne vous retrouviez pas avec
plusieurs répliques k8s appelant le script de migration en même temps.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627329964 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7MW7NJUS475HICIJTTRRFCQBANCNFSM4HDHMSDA
.

Les conteneurs @acrigney sont assez largement considérés comme une technologie "sans serveur". C'est certainement discutable, mais il n'y a pas de définition stricte

@acrigney Il existe de nombreuses raisons pour lesquelles les fonctions sans serveur, en particulier Azure, ne sont pas souhaitables :

1. Azure Functions est un tas de merde fragile et fumant qui est toujours en retard sur les correctifs de sécurité avec le noyau .net.
2. Les fonctions Azure sont vraiment une boîte noire et difficiles à déboguer dans de nombreux cas.
3. Une fois que vous commencez à l'utiliser pleinement, il est plus cher que d'autres options lorsque vous avez une charge constante.
4. Il n'y a rien que vous ne puissiez faire autrement que vous pouvez faire dans les fonctions Azure
5. K8s fournit un environnement générique connu qui fonctionne de la même manière sur votre machine de développement locale que sur n'importe quel cloud que vous souhaitez créer. Lorsque vous créez une ressource, cela fonctionne. Peu importe qu'il s'agisse d'Azure ou d'AWS, cela fonctionne de la même manière et de manière cohérente, contrairement aux fonctions Azure, où nous obtenons régulièrement des résultats différents dans Azure que localement.
6. K8s, sur un système chargé, coûte moins cher qu'Azure Functions.
7. K8s déploie mieux que fonctionne.
8. Une fois que vous aurez commencé à travailler avec le code VS distant dans Docker, vous ne voudrez plus revenir en arrière. Même environnement même configuration que la production pour une cohérence à 100 %. (Nous utilisons k8s à l'intérieur du docker pour développer avec le docker WSL2 et faire tourner k8s sous linux qui fonctionne à merveille avec Windows 10 2004, mais le développement complet dans k8s arrive bientôt)
9. k8s vous donne toute l'autonomie des VM sans avoir à gérer les VM, à équilibrer la charge, etc. Cela fonctionne, tout simplement.
10. Si vous créez correctement vos images Docker à l'aide du ciblage de plate-forme et de la liaison IL, vos micro-services dans k8 sont tout aussi petits que les mêmes dans les fonctions Azure, il n'y a donc pas de problèmes de mise à l'échelle.

C'est juste une courte liste. Les fonctions Azure sont géniales en théorie, puis vous commencez à vous taper la tête contre le mur et vous découvrez que cela n'en vaut pas la peine.

jusqu'à ce qu'ils commencent à déployer le noyau de Windows 2004 (printemps 2020) vers Azure.

Le travail nécessaire pour IIS est toujours en cours et n'est pas disponible dans la version 2004.

@Tratcher Waouh. Juste aïe. Ainsi, plus d'un an se sera écoulé avec le noyau .net prenant en charge gRPC et Azure n'ayant pas de moyen viable pour la grande majorité des développeurs du monde de l'utiliser.

MS doit créer de véritables services d'application basés sur docker qui utilisent nginx ou ha proxy et non IIS pour RP. C'est fou.

Vraiment mon pote, je pense que ça l'étire, bien sûr AKS peut évoluer mais
notamment avec le couplage de la messagerie nécessaire pour exécuter plusieurs
conteneurs pour un grand projet, je n'envisagerais guère de conteneurs dans
conformément aux idéaux de la technologie sans serveur. Je peux facilement brancher et jouer n'importe quel
microservices technologiques backend avec serveurs d'applications et fonctions, mais aurais-je
cette agilité avec les conteneurs ?

Le mar. 12 mai 2020 à 23h31 onionhammer [email protected]
a écrit:

@acrigney https://github.com/acrigney les conteneurs sont assez largement
considérée comme une technologie "sans serveur"

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627347120 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7PPWZ7MPIETCXPEFYDRRFFUNANCNFSM4HDHMSDA
.

@acrigney Absolument. Et vous n'auriez pas non plus l'enfer des dépendances qu'est Azure Functions. (et vous pouvez facilement utiliser l'hôte Azure Function dans des conteneurs et même k8 si vous le souhaitez)

@acrigney Essayez-vous d'exposer gRPC à d'autres microservices exécutés dans le service d'application ? À quoi ressemble votre topologie ?

Merci mon pote mais je pense que tu n'aurais pas de dépendance infernale ou serrée
couplage avec les fonctions. Je crée des microservices avec état en utilisant l'application DDD
services avec les services d'application Azure et je crée des microservices sans état avec
Services d'application DDD dans les fonctions Azure. Les services d'application DDD exposent
DTO et utiliser les objets de domaine et les autres services d'application peuvent observer le
événements déclenchés par ces objets de domaine. Je n'ai juste pas besoin de conteneurs et une fois
vous construisez un conteneur, il va avoir beaucoup de code dupliqué qui
serait nécessaire dans d'autres conteneurs.

Le mer. 13 mai 2020 à 00h09 James Hancock [email protected]
a écrit:

@acrigney https://github.com/acrigney Absolument vous le feriez. Et vous
n'aurait pas non plus l'enfer des dépendances qui est Azure Functions. (et tu peux
utilisez facilement l'hôte Azure Function dans des conteneurs et même des k8 si vous le souhaitez)

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627369635 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7PQLO2K4RVWBQRGQS3RRFKCZANCNFSM4HDHMSDA
.

L' avertissement it-does-not-run-on-IIS doit être placé en haut de la page à l'aide d'une balise <marquee> : https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

C'est vraiment inject profanity here si vous avez prototypé, créé des fichiers proto, configuré votre serveur, client, authentification à l'aide de JWT et que vous venez de présenter l'idée à un client car c'est-la-meilleure-prochaine-chose- since-sliced-bread pour savoir que nous ne pouvons pas l'utiliser en production car nous fonctionnons sur IIS. :(

jusqu'à ce qu'ils commencent à déployer le noyau de Windows 2004 (printemps 2020) vers Azure.

Le travail nécessaire pour IIS est toujours en cours et n'est pas disponible dans la version 2004.

Existe-t-il une ETA / feuille de route ?

L' avertissement it-does-not-run-on-IIS doit être placé en haut de la page à l'aide d'une balise <marquee> : https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

Vous avez raison, j'ai déposé https://github.com/dotnet/AspNetCore.Docs/issues/18336 pour clarifier.

Existe-t-il une ETA / feuille de route ?

Non, il y a trop de pièces mobiles pour donner une estimation fiable.

Quelqu'un a-t-il de la documentation sur la configuration de nginx avec grpc et crécerelle ?

Salut à tous, pouvons-nous rediriger certaines des demandes de gRPC dans la voix de l'utilisateur AppService https://feedback.azure.com/forums/169385-web-apps ?

Question rapide : la prise en charge d'IIS et d'Azure App Service est-elle couplée ou peuvent-elles/seront-elles fournies séparément ?

Merci à tous !

Ils sont quelque peu couplés - l'entrée d'Azure App Service et l'hébergement Windows reposent sur IIS, donc l'obtention d'une prise en charge dans IIS est une condition préalable.

Ensuite, App Service doit se déployer en fonction d'une version contenant ces correctifs. App Service viendra donc après la prise en charge d'IIS.

Question rapide : j'ai déployé le serveur gRPC sur IIS (10.0) et j'obtiens maintenant l'erreur "Status(StatusCode=Cancelled, Detail=\"No grpc-status found on response.\")". J'ai utilisé le projet WebApi en tant que client gRPC. Est-ce que quelqu'un peut m'aider?

Question rapide : j'ai déployé le serveur gRPC sur IIS (10.0) et j'obtiens maintenant l'erreur "Status(StatusCode=Cancelled, Detail="No grpc-status found on response.")". J'ai utilisé le projet WebApi en tant que client gRPC. Est-ce que quelqu'un peut m'aider?

Impossible, gRCP n'est pas pris en charge par IIS.

@lumogox @Dhananjay48 Remarque : GRPC-web est pris en charge par IIS et vous ne perdez que le streaming client pour la plupart. C'est donc une solution de contournement, même si elle n'est pas excellente.

Sinon, d'après ce que je vois, nous attendons au moins décembre avant que cela ne soit corrigé dans IIS, alors partez et utilisez autre chose comme nginx comme proxy inverse.

Si vous souhaitez simplement déployer GRPC sur Azure App Service, vous pouvez le faire maintenant avec un conteneur Linux

@EdiWang Ceci n'est actuellement pas pris en charge sur App Service pour Linux. Nous travaillons actuellement avec App Service pour activer cela, mais je n'ai pas d'ETA à partager

Est-ce parce qu'il y a toujours HTTP.sys devant l'application Web, même s'il s'agit d'un conteneur Docker fonctionnant sous Linux ?

D'après ce que j'ai compris, tous les services d'application sont inversés par proxy par iis. Par conséquent, ils ne fonctionneront pas tant que cela ne sera pas corrigé.

Seul quelque chose avec une adresse IP publique ou rped par ha ou nginx etc (Linux) fonctionnera. Kubernetes avec nginx ou ha fonctionne bien comme exemple, mais la passerelle d'application en tant qu'entrée ne le fera pas.

D'après ce que j'ai compris, tous les services d'application sont inversés par proxy par iis. Par conséquent, ils ne fonctionneront pas tant que cela ne sera pas corrigé.

Seul quelque chose avec une adresse IP publique ou rped par ha ou nginx etc (Linux) fonctionnera. Kubernetes avec nginx ou ha fonctionne bien comme exemple, mais la passerelle d'application en tant qu'entrée ne le fera pas.

C'est aussi ma compréhension. En fait, je me suis retrouvé ici parce que j'ai lu si tous les services d'application sont dirigés par un IIS. Parce que dans la documentation ici : https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse- proxy - il nous conseille d'installer un proxy inversé devant Kestrel si vous allez exposer Kestrel à Internet :) Je sais qu'il existe un IIS lors de l'exécution sur Windows, mais je n'en trouve aucun pour valider ce HTTP.sys ou IIS est également utilisé lors de l'exécution de docker dans un service d'application. Ce fil est le plus proche que je connaisse. Ce qui est drôle, c'est que je m'abonne à ce fil parce que je suis aussi très intéressant dans gPRC :)

Je peux confirmer qu'iis fait également face à des services d'application basés sur des conteneurs, y compris ceux de Linux.

Vos seules options sont VMS où vous avez fait le rp vous-même ou aks.

＠davidfowl AppService User Voice n'a pas reçu beaucoup d'attention.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Cela pourrait-il être la raison de la lenteur de la mise en œuvre ? Comme vous voyez ce problème, je pense que la prise en charge de gRPC est importante.

Oui d'autant plus que je n'arrivais pas non plus à faire fonctionner les websockets et je suis
inquiète du coût des conteneurs car je devrais courir beaucoup.

Le ven. 12 juin 2020 à 21 h 58 Takekazu Omi [email protected]
a écrit:

＠davidfowl AppService User Voice n'a pas reçu beaucoup d'attention.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Cela pourrait-il être la raison de la lenteur de la mise en œuvre ? Comme tu vois ça
Problème, je pense que la prise en charge de gRPC est importante.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-643232429 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7L4452ZISXIPNAXWYLRWIKADANCNFSM4HDHMSDA
.

L'ajout de la requête est toujours très important.

@davidfowl C'est beaucoup plus facile à dire qu'à faire. Essayez de vous connecter au site avec votre compte Microsoft avec un nouvel avantage. Ouvre une nouvelle fenêtre et ne fait rien. Essayez de vous connecter avec mon e-mail, eh bien j'ai oublié le mot de passe, l'e-mail de mot de passe va dans le courrier indésirable pour une adresse e-mail @outlook.com. Changez-le, connectez-vous et aucun gestionnaire de mot de passe ne vous invite à stocker le mot de passe, etc.

Juste WOW mauvais. Je suppose que l'équipe Azure n'obtient pas de bons commentaires en conséquence. J'espère que vous pourrez transmettre cela aux bonnes personnes pour réparer ce gâchis.

Peut-être que cela aidera quelqu'un d'héberger grpc sur iis.
Voici un exemple de fonctionnement de grpcweb Blazor WebAssembly avec l'approche gRPC-Web code-first qui héberge iis via via la publication à distance comme un charme. Je suppose que cela pourrait fonctionner d'autres façons aussi. Je n'ai fait aucun test de performance, donc je ne peux pas commenter cela, mais je pense qu'au moins cela fonctionnerait bien sur n'importe quoi jusqu'aux solutions de taille moyenne.
Voici le lien vers github
Il utilise également protobuf-net.Grpc.AspNetCore qui n'est pas une déclaration de protobuff ennuyeuse. C'est tellement bien quand vous pouvez passer directement à la mise en œuvre ou ajouter des méthodes supplémentaires pour demander/répondre.

Salut à tous, j'ai besoin de définir un dataType de type tableau de chaînes dans le message Grpc. je ne sais pas comment faire. en ce moment je le fais en tant que
chaîne répétée Nom = 1,
ici, j'ai besoin d'un champ de nom en tant que type de tableau de chaînes. Mais il montre une erreur, le champ est de type lecture seule lors de la liaison des données qu'il contient.

@ Dhananjay48 Ce n'est pas StackOverflow. Veuillez y poser votre question.
Gardons ce problème pour les éléments liés à gRPC dans App Service.

D'après ce que j'ai compris, tous les services d'application sont inversés par proxy par iis. Par conséquent, ils ne fonctionneront pas tant que cela ne sera pas corrigé.

Seul quelque chose avec une adresse IP publique ou rped par ha ou nginx etc (Linux) fonctionnera. Kubernetes avec nginx ou ha fonctionne bien comme exemple, mais la passerelle d'application en tant qu'entrée ne le fera pas.

"Kestrel utilisé dans une configuration de proxy inverse" avec nginx pourrait-il être une solution ? https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when -to-use-kestrel-with-a-reverse-proxy'

J'ai mis la suggestion à @JamesNK dans les docs, pour inclure un exemple de solution d'hébergement :
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
A été annoncé récemment et peut être déployé sur Azure.

Le jeudi 25 juin 2020 à 13h48, OzBob [email protected] a écrit :

D'après ce que j'ai compris, tous les services d'application sont inversés par proxy par iis.
Par conséquent, ils ne fonctionneront pas tant que cela ne sera pas corrigé.

Seul quelque chose avec une adresse IP publique ou rped par ha ou nginx etc (Linux) sera
travailler. Kubernetes avec nginx ou ha fonctionne bien comme exemple mais application
passerelle car l'entrée ne le sera pas.

'Kestrel utilisé dans une configuration de proxy inverse' avec nginx pourrait-il être un
Solution?
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when -to-use-kestrel-with-a-reverse-proxy
'

J'ai mis la suggestion à @JamesNK https://github.com/JamesNK dans le
docs, pour inclure un exemple de solution d'hébergement :
dotnet/AspNetCore.Docs#18953
https://github.com/dotnet/AspNetCore.Docs/issues/18953

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-649198280 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABCSC7KBUALMCXDGUS2NV7LRYLCKNANCNFSM4HDHMSDA
.

@acrigney et également mentionné ici sur Ch9 : https://youtu.be/T4RD3W2MgHQ?list=TLPQMjUwNjIwMjB6we-UTBA_VA&t=288 par @shirhatti (https://twitter.com/sshirhatti)

Je voulais juste signaler que nous avons travaillé avec l'équipe Windows pour commencer à activer ces scénarios. Voici un article de blog de l'équipe Windows à ce sujet, et https://github.com/dotnet/aspnetcore/pull/24120 a une partie du travail de suivi pour exposer des choses dans ASP.NET Core.

Il faudra encore un certain temps avant que tout cela n'arrive, mais c'est bien de pouvoir signaler que nous faisons au moins des progrès.

Merci pour le suivi, très utile et apprécié !!

Le mer. 22 juillet 2020 à 11 h 17 Kevin Pilch [email protected]
a écrit:

Je voulais juste signaler que nous avons travaillé avec l'équipe Windows pour
commencer à activer ces scénarios. Voici un article de blog
https://aka.ms/grpcblogpost de l'équipe Windows à ce sujet, et #24120
https://github.com/dotnet/aspnetcore/pull/24120 a certains des
travail de suivi pour exposer des choses dans ASP.NET Core.

Il faudra encore un certain temps avant que tout cela n'arrive, mais c'est agréable de pouvoir
signaler que nous faisons au moins des progrès.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-662547810 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/AAUKMASPCV3UE47OJZ6TIMDR44GKTANCNFSM4HDHMSDA
.

Je voulais juste signaler que nous avons travaillé avec l'équipe Windows pour commencer à activer ces scénarios. Voici un article de blog de l'équipe Windows à ce sujet, et # 24120 a une partie du travail de suivi pour exposer les choses dans ASP.NET Core.

Il faudra encore un certain temps avant que tout cela n'arrive, mais c'est bien de pouvoir signaler que nous faisons au moins des progrès.

Notez que cela a déjà été intégré au serveur HttpSys d'AspNetCore dans les aperçus 5.0. Veuillez essayer. Si nous pouvons identifier des problèmes au niveau de cette couche maintenant, nous devrions avoir moins de problèmes lorsque nous ajouterons la couche IIS par-dessus.

Cela signifie-t-il que je peux effectuer un gRPC complet sur IIS si j'utilise ASP.NET Core ciblant l'aperçu .NET 5 ?

Pas encore. Il y a un tas de pièces différentes ici:

1. Module HTTP.sys sous Windows
2. Prise en charge d'ASP.NET Core pour cela dans HttpSysServer
3. Prise en charge d'IIS pour cela dans Windows
4. Prise en charge d'ASP.NET Core pour cela sur IIS
5. Prise en charge de cela dans le proxy inverse utilisé par Azure App Service
6. Azure App Service déployant une build de Windows avec 1 et 3.
7. Azure App Service déployant une build du proxy inverse à partir de 5
8. Azure App Service déployant une build d'ASP.NET Core avec 2 et 4.

Ce que @Tratcher disait, c'est que 1 et 2 sont disponibles dans les aperçus de .NET 5. Nous travaillons actuellement sur 3 et 4, mais essayer 1 et 2 nous aidera à savoir si cela fonctionnera, depuis le Http. La prise en charge de sys est un fondement de la prise en charge d'IIS.

Aurait dû dire, 1 est disponible dans les aperçus de Windows, et 2 est disponible dans les aperçus de .NET 5.

L'aperçu de Windows Insider est disponible avec http.sys mis à jour
https://techcommunity.microsoft.com/t5/networking-blog/windows-server-insiders-getting-grpc-support-in-http-sys/ba-p/1534273

Des idées si cela sera disponible en tant que mise à jour Windows vers Windows Server 2016/2019 ?

Et la prise en charge d'IIS est désormais disponible dans les dernières versions de Windows Insider annoncées ici .

Nous étudions s'il sera possible de rétroporter ces modifications sur la version de maintenance, mais cela reste en suspens. Pour l'instant, le seul plan d'enregistrement est qu'ils seront dans les prochaines versions.