Hallo @moodya , hast du dir die Dokumentation unter https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio angesehen?

Wenn Sie auf ein Problem stoßen, teilen Sie uns dies bitte mit, damit wir es untersuchen können.

Ja, ich habe bereits einen Dienst erstellt, der als generischer gehosteter Dienst ausgeführt wird. Ich habe es auf die neue asp net core 3-Vorlage portiert und es auf dem selbst gehosteten Kestrel zum Laufen gebracht, aber derzeit überlege ich, es hinter iis zu hosten und hoffentlich als App-Dienst in Azure bereitzustellen. Ich kann das erstere (iis) nicht zum Laufen bringen.

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: Eilon Lipton [email protected]
Gesendet: Mittwoch, 3. April 2019, 18:06:17 Uhr
An: aspnet/AspNetCore
Cc: Moodya; Erwähnen
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

Hallo @moodya https://github.com/moodya , haben Sie sich die Dokumentation unter https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- angesehen.

Wenn Sie auf ein Problem stoßen, teilen Sie uns dies bitte mit, damit wir es untersuchen können.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

Ich kann keine Beispiele dafür finden, also wird es vielleicht noch nicht unterstützt

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: Alain Moody [email protected]
Gesendet: Mittwoch, 3. April 2019, 18:11:06 Uhr
An: aspnet/AspNetCore; aspnet/AspNetCore
CC: Erwähnung
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

Ja, ich habe bereits einen Dienst erstellt, der als generischer gehosteter Dienst ausgeführt wird. Ich habe es auf die neue asp net core 3-Vorlage portiert und es auf dem selbst gehosteten Kestrel zum Laufen gebracht, aber derzeit überlege ich, es hinter iis zu hosten und hoffentlich als App-Dienst in Azure bereitzustellen. Ich kann das erstere (iis) nicht zum Laufen bringen.

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: Eilon Lipton [email protected]
Gesendet: Mittwoch, 3. April 2019, 18:06:17 Uhr
An: aspnet/AspNetCore
Cc: Moodya; Erwähnen
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

Hallo @moodya https://github.com/moodya , haben Sie sich die Dokumentation unter https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- angesehen.

Wenn Sie auf ein Problem stoßen, teilen Sie uns dies bitte mit, damit wir es untersuchen können.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

@shirhatti - irgendeine Idee dazu?

gRPC kann nicht in IIS/Azure App Service gehostet werden.
Die HTTP/2-Implementierung von Http.Sys unterstützt keine HTTP-Antwort-Trailing-Header, auf die gRPC angewiesen ist.

Danke für die prompte Antwort. Wie würden Sie im Moment das Hosten eines GrPC-Dienstes in einem Produktionsszenario empfehlen? Sind Ihnen auch Zeiträume bekannt, in denen ein GrPC-Dienst auf IIS / App-Diensten gehostet werden kann?

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: Sourabh Shirhatti [email protected]
Gesendet: Mittwoch, 3. April 2019 19:13:23 Uhr
An: aspnet/AspNetCore
Cc: Moodya; Erwähnen
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

gRPC kann nicht in IIS/Azure App Service gehostet werden.
Die HTTP/2-Implementierung von Http.Sys unterstützt keine HTTP-Antwort-Trailing-Header, auf die gRPC angewiesen ist.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479600486 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AlUvPNHH4- HhNsSAtugTw0MzzNco6c76ks5vdO9DgaJpZM4cZ2SG .

Der empfohlene Ansatz besteht darin, Ihren gRPC-Dienst auf AKS zu hosten.

Was die Zeitpläne von App Service betrifft, würde ich auf @stefsch zurückgreifen

Danke, dass Sie sich bei mir gemeldet haben. In Bezug auf aks vs. Service Fabric in Bezug auf das Hosting des grpc-Dienstes ist aks die bessere Wahl? Wenn ja warum?

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: Sourabh Shirhatti [email protected]
Gesendet: Montag, 8. April 2019 7:31:45 Uhr
An: aspnet/AspNetCore
Cc: Moodya; Erwähnen
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

Der empfohlene Ansatz besteht darin, Ihren gRPC-Dienst auf AKS zu hosten.

Was die Zeitpläne von App Service betrifft, würde ich auf @stefsch https://github.com/stefsch verweisen

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-480701227 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AlUvPLwQW8HCp- YXsz6yNaK_RH7jbZzWks5veuJRgaJpZM4cZ2SG .

Ich erwarte derzeit Probleme, dies zu tun. Ich habe einen gRPC-Dienst mit Aspnetcore 3 Preview 3 und Kestrel zum Laufen gebracht. Bei der Verwendung von IIS wird jedoch ein Fehler zu Trailern angezeigt, wenn der Dienst die Antwort sendet (die Anfrage wird gut angenommen):
gPRC error => 2 UNKNOWN: Kein Status empfangen)
Dotnet-Fehler => „Trailer werden für diese Antwort nicht unterstützt“ in Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer (HttpResponse-Antwort, String trailerName, StringValues ​​trailerValues) bei Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

Denken Sie gemäß den obigen Meldungen nicht, dass iis das Hosten eines Grpc-Dienstes unterstützt

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: alustrement [email protected]
Gesendet: Donnerstag, 25. April 2019 10:57:42 Uhr
An: aspnet/AspNetCore
Cc: Moodya; Erwähnen
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

Ich erwarte derzeit Probleme, dies zu tun. Ich habe einen gRPC-Dienst mit Aspnetcore 3 Preview 3 und Kestrel zum Laufen gebracht. Bei der Verwendung von IIS wird jedoch ein Fehler zu Trailern angezeigt, wenn der Dienst die Antwort sendet (die Anfrage wird gut angenommen):
gPRC error => 2 UNKNOWN: Kein Status empfangen)
Dotnet-Fehler => „Trailer werden für diese Antwort nicht unterstützt“ in Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer (HttpResponse-Antwort, String trailerName, StringValues ​​trailerValues) bei Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486607635 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AJKS6PEAJ2UKKH2QIKNTCZDPSF6BNANCNFSM4HDHMSDA .

Nach diesem Austausch https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , scheint es, dass der Webserver nicht dafür verantwortlich ist, gRPC zu handhaben. gPRC verwendet HTTP/2, IIS unterstützt HTTP/2, also muss es funktionieren. Wenn dies nicht der Fall ist, handelt es sich um einen Fehler von IIS oder, was wahrscheinlicher ist, von dotnetcore.

Laut den Microsoft-Leuten in den obigen Meldungen unterstützt iis die abschließenden Header nicht, die zum Hosten eines grpc-Dienstes erforderlich sind. Dies bedeutet, dass Sie derzeit keine in IIS oder als App-Dienst hosten können.

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: alustrement [email protected]
Gesendet: Donnerstag, 25. April 2019 11:39:08 Uhr
An: aspnet/AspNetCore
Cc: Moodya; Erwähnen
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

Nach diesem Austausch https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 , scheint es, dass der Webserver nicht dafür verantwortlich ist, gRPC zu handhaben. gPRC verwendet HTTP/2, IIS unterstützt HTTP/2, also muss es funktionieren. Wenn dies nicht der Fall ist, handelt es sich um einen Fehler von IIS oder, was wahrscheinlicher ist, von dotnetcore.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486620151 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AJKS6PBQO4427EYN67SI7A3PSGC4ZANCNFSM4HDHMSDA .

Danke, ich habe es übersehen und es macht Sinn mit meinem Problem.
@shirhatti ist die Unterstützung auf der Roadmap geplant?

Wir (IIS) prüfen derzeit, ob HTTP-Antwort-Trailer unterstützt werden sollen. Keine Roadmaps/Verpflichtungen, zu denen ich noch sprechen kann.

@shirhatti Angesichts der Tatsache, dass gRPC ein Hauptmerkmal von .NET Core 3 (https://github.com/grpc/grpc-dotnet) zu sein scheint, wäre es eine echte Schande, wenn es angesichts so vieler . NET-Webanwendungen werden auf diesen gehostet. Ich hoffe, dass die Verfügbarkeit dieser Funktion in .NET Core Ihre Roadmap vorantreibt.

Ich stimme @jbrantly voll und ganz zu. gRPC wird als eines der Hauptfeatures von .NET Core 3 beworben.
Es sollte in IIS/Azure App Services gehostet werden können.
@shirhatti bitte ziehen Sie in Betracht, dies der Roadmap hinzuzufügen

Ich stimme auch zu.

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: Tomasz Jagusz [email protected]
Gesendet: Freitag, 26. April 2019 09:42:58 Uhr
An: aspnet/AspNetCore
Cc: Moodya; Erwähnen
Betreff: Betreff: Re: [aspnet/AspNetCore] Grpc-Dienst in IIS oder als App-Dienst hosten? (#9020)

Ich stimme @jbrantly https://github.com/jbrantly voll und ganz zu. gRPC wird als eines der Hauptfeatures von .NET Core 3 beworben.
Es sollte in IIS/Azure App Services gehostet werden können.
@shirhatti https://github.com/shirhatti Bitte erwägen Sie, dies der Roadmap hinzuzufügen

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486977989 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AJKS6PENWT46GCJ7GQGEGPTPSK6BFANCNFSM4HDHMSDA .

Ich könnte nicht mehr zustimmen.

Wir untersuchen es. Es erfordert sowohl Windows-Kerneländerungen als auch IIS-Änderungen.

@davidfowl wird dies möglich sein, wenn .NET Core 3 veröffentlicht wird?
Die Möglichkeit, GRPC in App Services zu hosten, ist für mich ein Hindernis.

Nun, es ist der 29. Mai 2019 , und doch gibt es kein Signal, dass dies möglich sein wird. Ich suche nach einem GRPC -Dienst in IIS und füge ein Zertifikat hinzu, um HTTPS zu verwenden :(

Nein, es ist auf IIS nicht möglich, wir arbeiten daran, Änderungen zu erhalten, aber es wird ein langsamer Prozess sein (da es ein Windows-Update erfordert).

Ich habe ungefähr 3 Tage verloren ... danke iis

Hallo @davidfowl
Irgendein Update?

@davidfowl besteht die Möglichkeit, dass dies hinzugefügt wird, bevor .NET Core 3.0 veröffentlicht wird? Oder sollten wir auf 3.1 oder 5.0 warten?

Nein, da Windows-Änderungen erforderlich sind. Es wird nicht Teil von 3.0 sein und es wird die neueste Version von Windows (was auch immer das zu diesem Zeitpunkt ist) erforderlich sein, um diese Funktionen zu erhalten. Es gibt keine ETA

Hmm, ich bin mitten in der Planung einer Service Fabric-Implementierung, die gRPC-basierte zustandslose Dienste und zuverlässige Akteure zusätzlich zu dotnet Core 3 verwenden wird. Wird mich das in den Arsch beißen? Wenn ich auf SF hoste, werde ich wohl Kestrel im Kern verwenden? Zeit zum Prototypen.

@oising dasselbe Boot hier - aber wir rollen langsam in Richtung k8s + Linux-Container, also hilft uns diese Art sowieso, uns in diese Richtung zu drängen.

Ich füge das nur hinzu, da ich jetzt schon eine Weile mit gRPC herumgespielt habe und es endlich in einigen meiner Kundenprojekte übernehmen möchte, also habe ich mich mit Bereitstellungs-Workflows befasst. Ich bin ein wenig entmutigt über die Höhe des Betriebsaufwands, den die Bereitstellung in der Produktion mit .net Core bedeuten würde.

Ich brauchte auch Tage, um herauszufinden, dass IIS das Problem war. Wirklich auf der Suche nach einer Lösung. Irgendwelche Problemumgehungen?

@bingoo ohne Windows-Unterstützung und IIS Sie haben Pech. Sie können Service Fabric verwenden, aber ich habe keine Erfahrung damit. Ich hoffe, dass es möglich sein wird, es auf einfache Weise auf IIS oder in Azure zu hosten.
Für aktuelle Projekte ist Grpc wegen dieses Problems keine Option für mich.

Wäre schön, wenn dies eine große mutige Warnung in den Dokumenten wäre ...

IIS-Hosting wird noch nicht unterstützt. App Services verwenden standardmäßig Windows Server 2016 + IIS als Backend, unterstützen jetzt aber auch Linux/Container. Wenn Sie GRPC nur auf Azure App Service bereitstellen möchten, können Sie dies jetzt mit einem Linux-Container tun. Der App Service-Plan kann jedoch nicht mit einem Windows-Hostingplan geteilt werden. Sie müssen zusätzliches Geld für einen neuen App Service-Plan ausgeben, der von Linux Container unterstützt wird.

Der beste Weg ist, AKS und dann Ambassador zu verwenden. Ambassador ist ein Envoy-basiertes API-Gateway, das als Container in Kubernetes ausgeführt wird. Es ermöglicht Ihnen, sowohl grpc als auch grpc-web als Proxy zu verwenden, z. Browser zum GrPC-Server und auch einen GrPC-Client, vielleicht einen zu einem GrPC-Server. Wenn Sie möchten, dass Frontend-js gRPC-Aufrufe empfängt, benötigen Sie grpc web und einen Proxy, da Browser auch die HTTP2-Antwort-Trailing-Header nicht richtig unterstützen. Grpc Web verwendet standardmäßig Envoy, deshalb ist Ambassador am besten.

Wenn Sie GRPC nur auf Azure App Service bereitstellen möchten, können Sie dies jetzt mit einem Linux-Container tun

@EdiWang Dies wird derzeit von App Service für Linux nicht unterstützt. Wir arbeiten derzeit mit App Service daran, dies zu ermöglichen, aber ich habe keine voraussichtliche Ankunftszeit zum Teilen

Hallo gute Leute
Ich bin ein bisschen verwirrt, also können wir keinen GrPC-Dienst in Azure haben.
Aber Azure selbst verwendet grpc, das Azure Functions Languge Worker Protobuf.
https://github.com/Azure/azure-functions-language-worker-protobuf
Oder übersehe ich hier etwas?
Versuch zu verstehen :confused:

@GoranHalvarsson Sie können gRPC-Dienste in Azure haben, Sie können sie nur noch nicht in Azure App Services ausführen.

@markrendle Danke für die Antwort. Wie kann ich also einen gRpc-Dienst in Azure verwenden/einrichten?

Wäre schön, wenn dies eine große mutige Warnung in den Dokumenten wäre ...

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

@markrendle Danke für die Antwort. Wie kann ich also einen gRpc-Dienst in Azure verwenden/einrichten?

Indem Sie IIS nicht verwenden, was bedeutet, dass Sie Service Fabric oder AKS verwenden – beide verwenden rohes Kestrel. SF und AKS haben unterschiedliche Eigenschaften. Googlen Sie nach „Service Fabric vs. AKS“ und holen Sie sich einen großen Kaffee.

Ich habe eine Schritt-für-Schritt-Anleitung zum Erstellen von Test- und Bereitstellungsgrpc-Diensten mit .NET Core 3.0 erstellt
https://github.com/rupeshtech/k8s-grpc-dotntecore

Ich habe mich gerade mit diesem Problem befasst, also habe ich noch nichts ausprobiert. aber hat jemand versucht, Azure Web App für (Container https://azure.microsoft.com/en-us/services/app-service/containers/) zu verwenden?

Ich führe eine Reihe von Docker-basierten Microservices auf Azure App Services aus und hatte nur sehr wenige Probleme und konnte andere einschränkende Merkmale des OOB App Service-Angebots umgehen.

@ikemtz gRPC funktioniert bei Verwendung von Kestral (dh bei Ausführung in Containern).

@rupeshtech Vielen Dank, aber Ihr Artikel bezieht sich nicht auf das Problem.

Dieses Problem betrifft das Hosten von gRPC (oder jeder App, die nachgestellte Header verwendet) in IIS oder Azure App Service.

Wäre schön, wenn dies eine große mutige Warnung in den Dokumenten wäre ...

aspnet/AspNetCore.Docs#14684

Dies wird nun umgesetzt .

@ikemtz Ich habe versucht, einen grundlegenden Test für die Verwendung von gRPC in einem Linux-Container auszuführen, der in einer Azure-Web-App für Container ausgeführt wird, und es würde bei mir nicht funktionieren. Konnte nirgendwo gemeldete Fehler finden, aber der Container reagierte nicht einmal auf HTTP-Pings.
Es ist Schande. Ich bin nicht bereit, zu AKS zu wechseln, nur um diese Funktionalität zu erhalten, also bleibe ich wohl vorerst bei den guten, altmodischen HTTP-Diensten.

@searus , wenn Sie stattdessen eine virtuelle Maschine verwenden (in Azure ausgeführt)

@GoranHalvarsson Ich bin nicht bereit, von PaaS zu IaaS zu wechseln, nur um diese Technologie zu nutzen. Ich warte einfach, bis Azure App Service dies unterstützen kann.

@davidfowl Irgendeine Roadmap dazu?

Die Bereitstellung in einem Container mit Kestral ist in Ordnung, aber es ist einfach zu sagen
die Verwendung von Lets Encrypt in IIS oder einem App-Dienst, der mich wirklich zurückhält.
Wenn es kurze Anleitungen zum Ausführen einer benutzerdefinierten Domäne mit lets
auf Kestrel in einem Container verschlüsseln, dann springe ich kopfüber in gRPC
Andernfalls ist es sehr schwierig, den Aufwand für die Erstellung einer benutzerdefinierten zu rechtfertigen
Bereitstellung, nur um den neuen Stack aufzunehmen.

Am Mittwoch, 16. Oktober 2019 um 6:46 Uhr Russell Seamer [email protected]
schrieb:

@GoranHalvarsson https://github.com/GoranHalvarsson Ich bin nicht vorbereitet
von PaaS zu IaaS zu wechseln, nur um diese Technologie zu nutzen. ich werde nur
Warten Sie, bis Azure App Service dies unterstützen kann.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aspnet/AspNetCore/issues/9020?email_source=notifications&email_token=AMNAZYUWLYLGC5ZGB4GAFITQO2TCFA5CNFSM4HDHMSDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLFDDI#issuecomment-5425278
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AMNAZYTKUYYBWKSW6AMQDHTQO2TCFANCNFSM4HDHMSDA
.

Damit können Azure Functions und alles andere, was auf App Service aufsetzt, gRPC und HTTP/2 nicht wirklich verwenden. Eine Zeitleiste wäre schön, auch für private/öffentliche Vorschauen.

Wir arbeiten derzeit an den Änderungen in http.sys. Danach müssen wir auf diese Änderungen in IIS und ARR reagieren. Dann müssen wir die Version von Windows aktualisieren, die im App-Dienst ausgeführt wird, um diese Änderungen in IIS zu nutzen.

Die Arbeit hat angegeben, aber es ist wirklich schwer abzuschätzen, wie lange es dauern wird, bis die Kunden es erhalten. Wir halten Sie über den Fortgang der Dinge auf dem Laufenden.

Ich habe das Gefühl, dass ich darüber leider nicht überrascht bin (dass die Implementierung neuer HTTP-Funktionen Kernel-Updates erfordert). Offensichtlich existiert IIS nicht unter Linux / Macosx, aber ich wäre überrascht, wenn das Hinzufügen von Unterstützung für grpc zu anderen Wir-Servern für andere Betriebssysteme ... viel Kernel-Update erfordern würde.

Vielleicht ist dies ein anständiges Argument / Beispiel für die Entkopplung ... Nur gesagt

Ich habe das Gefühl, dass ich darüber leider nicht überrascht bin (dass die Implementierung neuer HTTP-Funktionen Kernel-Updates erfordert). Offensichtlich existiert IIS nicht unter Linux / Macosx, aber ich wäre überrascht, wenn das Hinzufügen von Unterstützung für grpc zu anderen Wir-Servern für andere Betriebssysteme ... viel Kernel-Update erfordern würde.

Vielleicht ist dies ein anständiges Argument / Beispiel für die Entkopplung ... Nur gesagt

Ich stimme zu. Dies hat wahrscheinlich etwas damit zu tun, dass IIS ein Low-Level-Protokoll ausführt, das direkt mit dem Kernel verbunden ist. Es scheint seltsam, aber zumindest haben wir die Bestätigung, dass daran gearbeitet wird und dass die Adoption nicht ganz blauer Himmel ist.

Erinnern Sie sich, als Sie auf Windows 8 aktualisieren mussten, um WebSocket-Unterstützung zu erhalten? Ich auch 😄

Ja, wir erinnern uns! Hier ist der Knüller: gRPC wird in .NET-Core veröffentlicht und wir verwenden Azure App Services, daher ist es wichtig, zumindest zum Testen so schnell wie möglich eine Option zu haben. Kann uns jemand sagen, wann diese Synchronisierung mit den veröffentlichten .NET-Core-Funktionen in Azure App Services stattfinden wird? Oder ein praktikabler Workaround. Danke

Danke, dass Sie uns kontaktiert haben. Da es zu diesem Problem keine Aktivitäten gibt, schließen wir es, um unseren Rückstand sauber zu halten. Wenn Sie der Meinung sind, dass es Bedenken im Zusammenhang mit dem ASP.NET Core-Framework gibt, die noch nicht behoben wurden, reichen Sie bitte ein neues Problem ein.

@anurse wie halten wir dieses Thema offen?

Es wurde in die Diskussionen aufgenommen und mit Frage markiert. Wiedereröffnet.

Gibt es dazu schon eine ETA?

Gibt es praktikable Alternativen, um gRPC in einer Produktionsumgebung zum Laufen zu bringen?
Ich habe mir einige Dinge angesehen und es scheint, als wäre das Hosten auf AKS eine Option. Ich möchte nur sicherstellen, dass wir keine Dinge tun, die uns nicht bei der Lösung unseres Problems helfen.

Wir haben derzeit versucht, eine Art Produktionsumgebung für dieses Projekt zum Laufen zu bringen:
IdentityServer-Projekt, das über gRPC mit einer API kommuniziert
5 Webportale, die über gRPC mit einer API kommunizieren
Die API, die über gRPC mit einem Discord Bot (ASP.NET Core) kommuniziert.

Wir haben versucht, sie auf einem VPS zu hosten, aber ich weiß nicht, ob wir sie tatsächlich in einer Produktionsumgebung hosten können, indem wir einfach Kestrel verwenden, wenn wir möchten, dass alle diese Anwendungen auf demselben VPS laufen.

Hat jemand eine Option für uns, damit wir mehrere Domänen (1 Domäne, der Rest sind Subdomänen) mit 1 IP-Adresse auf 1 VPS haben können, auf dem alle Projekte ausgeführt werden, indem nur Kestrel verwendet wird (aufgrund der Einschränkungen in IIS, Http.Sys, Fenster).

(Oder jede andere Methode, die es uns ermöglicht, all dies so schnell wie möglich zu hosten)

Vielen Dank im Voraus!

(BEARBEITEN)

Wir verwenden Let's Encrypt (https://github.com/natemcmaster/LetsEncrypt), um ein SSL-Zertifikat zu erhalten

(BEARBEITEN 2)
Wir haben auch versucht, @davidfowl diesbezüglich auf Twitter zu kontaktieren
https://twitter.com/DapperDino4/status/1204119195765682177 und
https://twitter.com/DapperDino4/status/1204119695344971778

Gibt es dazu schon eine ETA?

Hinzufügen von @shirhatti und @Tratcher , die daran gearbeitet haben.

Der Zeitpunkt dafür ist im Moment schwierig festzulegen. IIS ist eine Windows-Komponente und hängt von http.sys ab, das ebenfalls eine Windows-Komponente ist. Weder IIS noch http.sys verfügen über ausreichende HTTP/2-Features, um gRPC zu unterstützen. Wir haben sehr eng mit diesen Teams zusammengearbeitet, um die Änderungen einzuführen, und sie sind alle auf einem guten Weg für eine kommende Version, werden aber erst verfügbar sein, wenn eine Windows Server-Version mit den entsprechenden Änderungen live geht.

@JamesNK können Sie mit der Verfügbarkeit von Alternativen wie gRPC-Web sprechen?

Kontext für Leute, die nicht wissen, was gRPC-Web ist: https://grpc.io/blog/state-of-grpc-web/. Da HTTP/1.1 verwendet wird, gelten die Azure App Service-Einschränkungen nicht dafür. Der Nachteil sind keine HTTP/2-Vorteile (Multiplexing, Header-Komprimierung) und kein Client- oder bidirektionales Streaming.

Der gRPC-Web Envoy-Reverse-Proxy ist jetzt verfügbar, aber das ist nicht einfach einzurichten. Und es gibt keinen .NET gRPC-Web-Client.

Das ASP.NET Core-Team hat noch nicht entschieden, ob wir uns verpflichten, gRPC-Web offiziell zu unterstützen. Ich schaue mir jetzt gRPC-Web an und wie es in .NET Core aussehen könnte. In ein paar Wochen kann ich mehr sagen und vielleicht eine experimentelle Vorschau haben, die die Leute im Januar ausprobieren können.

Da IIS dies nicht unterstützt, kann der netcore gRPC-Dienst hinter Nginx gehostet werden?

@Dennis-Petrov Ich mache genau das. Ich habe dieses Dokument befolgt https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-3.1 und gRPC läuft großartig

Darf ich eine dumme Frage stellen: Warum funktioniert das nicht in einem Azure App Service unter Linux App Service Plan?

Ist IIS auch irgendwo in der Pipeline daran beteiligt?

@searus Es gibt gemeinsame Ebenen zwischen Frontend- und App-Diensten, unabhängig von Linux/Windows. Das heißt, derzeit empfängt das App Service-Frontend die HTTP/2-Verbindungen, und dann werden Verbindungen intern als "altes" HTTP an einzelne App Service-Worker weitergeleitet. Ich bin mir sicher, dass es in Arbeit ist, gRPC vollständig zu unterstützen, aber es erfordert einige Anstrengungen, da interne Komponenten aktualisiert, getestet und veröffentlicht werden müssen.

Danke @devlead.
Ich dachte (vielleicht naiv), dass ein Linux App Service-Plan durchweg Linux wäre.
Ich weiß den Aufwand, der hiermit verbunden ist, voll und ganz zu schätzen, und danke, dass Sie sich die Zeit genommen haben, dies zu erklären.

Ich bin sicher, dass es in Arbeit ist, gRPC vollständig zu unterstützen

Es ist definitiv in Arbeit. Wir arbeiten aktiv daran, können aber keinen Zeitplan garantieren (es gibt mehrere unabhängige Teams, die sich hier koordinieren müssen). @devlead hat Recht mit der Linux-Unterstützung von Azure App Service. Auf dem Front-End-Proxy wird IIS ausgeführt. Es unterstützt den Empfang von HTTP/2 vom Client, aber wenn es Datenverkehr an Ihre App weiterleitet, wird es auf HTTP/1.1 herabgestuft. Dies war für normale Apps in Ordnung (wenn auch nicht ideal), aber da gRPC HTTP/2-Funktionen erfordert , ist es für diese nicht geeignet.

Ja, ich habe bereits einen Dienst erstellt, der als generischer gehosteter Dienst ausgeführt wird. Ich habe es auf die neue asp net core 3-Vorlage portiert und es auf dem selbst gehosteten Kestrel zum Laufen gebracht, aber derzeit überlege ich, es hinter iis zu hosten und hoffentlich als App-Dienst in Azure bereitzustellen. Ich kann das erstere (iis) nicht zum Laufen bringen.

@moodya kannst du uns sagen, wie du das gemacht hast??

Ja, ich habe bereits einen Dienst erstellt, der als generischer gehosteter Dienst ausgeführt wird. Ich habe es auf die neue asp net core 3-Vorlage portiert und es auf dem selbst gehosteten Kestrel zum Laufen gebracht, aber derzeit überlege ich, es hinter iis zu hosten und hoffentlich als App-Dienst in Azure bereitzustellen. Ich kann das erstere (iis) nicht zum Laufen bringen.

@moodya kannst du uns sagen, wie du das gemacht hast??

Die gRPC-Vorlage ist standardmäßig ein selbstgehosteter Kestrel. Aus den in diesem Thread beschriebenen Gründen wird es im App-Dienst nicht funktionieren.

Es kann zwar nicht im App-Dienst gehostet werden, nehmen wir an, wir hosten den Grpc-Dienst auf Aks. Gibt es ein Problem, GrPC vom App-Dienst aus aufzurufen? Wird der grpc-Client zumindest am App-Dienst arbeiten?

Es kann zwar nicht im App-Dienst gehostet werden, nehmen wir an, wir hosten den Grpc-Dienst auf Aks. Gibt es ein Problem, GrPC vom App-Dienst aus aufzurufen? Wird der grpc-Client zumindest am App-Dienst arbeiten?

Ja, Clients sollten funktionieren. Die Beschränkung gilt nur für eingehende Anforderungen, nicht für ausgehende.

Vielleicht dumme Frage, aber warum funktioniert es, wenn ich den gRPC-Dienst in Debug mit IIS Express ausführe? ZB habe ich eine Web-App (Razor Pages, .net Core 3.1), die einen gRPC-Dienst aufruft [von einer Framework-MVC-App aktualisiert, die mit einem WCF-Dienst kommuniziert, falls es jemanden interessiert]. Wenn ich sie beide auf meiner Workstation mit dem gRPC-Dienst in IIS Express debugge, kann die Webapp problemlos mit dem Dienst kommunizieren. Aufgrund des oben beschriebenen Proxying-Verhaltens @anurse erhalte ich die Ausnahme, dass gRPC HTTP/2 erfordert, wenn der Dienst in IIS gehostet wird. Proxyt IIS Express anders als IIS an Kestrel?

Auch vielleicht nicht der richtige Ort dafür, aber ich möchte demütig darum bitten, dass die folgende Seite eine kleine Erklärung des IIS/App Service-Proxy-Verhaltens enthält. Ich habe (vielleicht dummerweise) einen ganzen Tag damit verbracht, IIS zu überlisten, weil ich dachte, ich könnte es zwingen, in HTTP/2 zu Proxy zu werden, wenn die App in 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 sollte aus denselben Gründen nicht funktionieren wie IIS.

@ Tratcher Ah ja, du hast Recht. Ich habe den gRPC-Dienst als selbst gehostet ausgeführt, nicht als IIS Express. Danke!

Hat jemand ein Tutorial, wie man das in AKS zum Laufen bringt? (Bonuspunkte für das lokale Debuggen mit VS-Code in Aks, ohne dass Container neu erstellt werden müssen, sodass wir den gesamten Stack mit .net Core Dev haben, bis hin zur Bereitstellung in Azure mit Azure Devops und Aks).

Am wichtigsten ist, was Sie in AKS verwenden, um den Webdatenverkehr an die AKS-Pods weiterzuleiten, ohne ngix im Pod selbst verwenden zu müssen (dh Azure Load Balancer oder so etwas?).

Es kann zwar nicht im App-Dienst gehostet werden, nehmen wir an, wir hosten den Grpc-Dienst auf Aks. Gibt es ein Problem, GrPC vom App-Dienst aus aufzurufen? Wird der grpc-Client zumindest am App-Dienst arbeiten?

Ja, Clients sollten funktionieren. Die Beschränkung gilt nur für eingehende Anforderungen, nicht für ausgehende.

Leider scheint dies bei .Net Core 3.1-basierten Web-Apps, die einen Grpc-Dienst aufrufen (in diesem Fall Pyhton-Code, der auf einer VM ausgeführt wird), nicht der Fall zu sein, wenn sie auf Azure-Web-Apps gehostet wird – Zeitüberschreitung. Beim Ausführen des exakt gleichen Codes von localhost geht der Aufruf durch (gleiche Dienst-VM).

@lyulyok kannst du Diagnosen sammeln und ein separates Problem eröffnen? Hier sind keine Probleme mit dem Client bekannt.

Hat jemand ein Tutorial, wie man das in AKS zum Laufen bringt?

Bitte öffnen Sie ein neues Thema, um dies zu diskutieren, oder fragen Sie auf Stack Overflow . Bleiben wir in diesem Thread beim Thema, zumal es viele Leute gibt, die sich für den Status von gRPC auf IIS und HTTP.sys interessieren und jeder Kommentar jeden anpingt, der daran teilnimmt. Ich werde Off-Topic-Kommentare ausblenden, bitte zögern Sie nicht, neue Themen zu posten, wenn Sie weitere Fragen haben.

Ja, ich habe bereits einen Dienst erstellt, der als generischer gehosteter Dienst ausgeführt wird. Ich habe es auf die neue asp net core 3-Vorlage portiert und es auf dem selbst gehosteten Kestrel zum Laufen gebracht, aber derzeit überlege ich, es hinter iis zu hosten und hoffentlich als App-Dienst in Azure bereitzustellen. Ich kann das erstere (iis) nicht zum Laufen bringen.

Experimentelle Unterstützung für gRPC-Web in .NET ist jetzt verfügbar. gRPC-Web funktioniert mit HTTP/1.1 und HTTP/2 und wird in IIS und Azure App Service ausgeführt.

Wir arbeiten weiterhin an der Ausführung von HTTP/2 gRPC in Azure App Service, aber gRPC-Web ist etwas, das Sie bereits heute verwenden können. Wenn die Arbeiten zur Unterstützung von HTTP/2 in IIS und Azure App Service abgeschlossen sind, ist es ein einfacher Prozess, eine .NET-App von gRPC-Web auf HTTP/2 gRPC umzustellen.

Blogbeitrag: https://devblogs.microsoft.com/aspnet/grpc-web-experiment
Dokumentation: https://docs.microsoft.com/aspnet/core/grpc/browser

Ich habe den grpc-Client, der im App-Dienst ausgeführt wird, und den Dienst, der in aks einwandfrei ausgeführt wird, falls jemand anderes es auch versuchen möchte

@andrew-vdb Kannst du bitte die Konfiguration posten?

Hallo @JamesNK ,
im Zusammenhang mit Ihrem Kommentar https://github.com/dotnet/aspnetcore/issues/9020#issuecomment -579597202 und der Tatsache, dass gRpc-Web derzeit _ein experimentelles Projekt zu sein scheint, kein festgelegtes Produkt._

• Benötige ich gRpc-Web für die Bereitstellung in IIS? Sonst geht das gar nicht?
• Haben Sie eine ETA darüber, wann die Bereitstellung auf IIS ohne gRpc-Web möglich sein wird?
• Haben Sie eine ETA, wann gRpc-Web offiziell von Microsoft unterstützt wird?

Benötige ich gRpc-Web für die Bereitstellung in IIS? Sonst geht das gar nicht?

Derzeit funktioniert gRPC über HTTP/2 nicht in IIS. gRPC-Web funktioniert.

Haben Sie eine ETA darüber, wann die Bereitstellung auf IIS ohne gRpc-Web möglich sein wird?

Nein. Es dauert einige Zeit, bis Änderungen an Windows vorgenommen und veröffentlicht werden.

Haben Sie eine ETA, wann gRpc-Web offiziell von Microsoft unterstützt wird?

Nicht im Moment.

FYI
Ich habe eine Anwendung (ASP.Net Core 3.2.0-Preview1), in der ich eine REST-API-DAL durch eine gRPC-Web-DAL ersetzt habe. Ich folgte der Anleitung des Blogposts von Steve Sanderson. Meine Lösung kann entweder als CSB oder als SSB ausgeführt werden, und ich war mit gRPC-Web in beiden Konfigurationen erfolgreich (ich musste zu einer neueren Version der gRPC.*-Nuget-Pakete vorrücken).

Ich habe irrtümlicherweise weitere Updates von den Nightly Builds durchgeführt und derzeit sind meine gRPC-Pakete alle auf Version 2.28.0-dev202003020801. Ich sage fälschlicherweise, weil meine beiden funktionierenden Lösungsbereitstellungen jeweils fehlschlagen.

SSB – Der Client meldet den Fehler „Unbehandelte Ausnahme-Rendering-Komponente: Datei oder Assembly 'System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' konnte nicht geladen werden. Das System kann die angegebene Datei nicht finden. "
Durch einfaches Hinzufügen eines expliziten Nuget-Pakets von System.Text.Json (4.7.1) zu meinem Webserverprojekt verschwindet dieser Fehler und alles funktioniert.
[BEARBEITEN] Die Rückkehr zu den Versionen 2.27.0/2.27.0-Pre1 für alle gRPC.*-Pakete aus dem NuGet-Feed behebt dieses Problem.

CSB – An der gleichen Stelle im Client, wenn ich die erste gRPC-Web-Antwort erhalte, erhalte ich die Fehlermeldung „WASM: Grpc.Core.RpcException: Status(StatusCode=Internal, Detail="Bad gRPC response. Response protocol downgradeed to HTTP /1.1.")". Ich habe keine Problemumgehung dafür, aber es ist nicht kritisch, da wir SSB versenden, bis CSB veröffentlicht wird.
[BEARBEITEN] Die Rückkehr zu den Versionen 2.27.0/2.27.0-Pre1 für alle gRPC.*-Pakete aus dem NuGet-Feed behebt dieses Problem.

Entschuldigung für die Ausführlichkeit, aber zum Schluss noch zwei Fragen:

• Ist es möglich, einen anderen JSON-Serializer/Deserializer in gRPC/gRPC-Web zu verwenden?
• Werden die gRPC/gRPC-Web-Pakete auf ASP.Net Core 3.2-Preview 2 ausgerichtet oder ist der Zugriff auf nächtliche Builds erforderlich?

Hallo @JamesNK ,
Mein Kunde ist zu gRpcWeb migriert, aber wir haben eine wichtige Einschränkung festgestellt (von der ich keine Dokumentation gefunden habe): Die maximale Nachrichtengröße beträgt 3067 Zeichen.
Wenn der übliche Client-Service vom grundlegenden gRpc-Dienst in gRpc-Web konvertiert wird, schlägt diese Zeile fehl (weil die Zeichenfolge 3068 Zeichen lang ist, 1 über dem Limit):

// Konfigurieren Sie einen Kanal zur Verwendung von gRPC-Web
var handler = new GrpcWebHandler(GrpcWebMode.GrpcWebText, new HttpClientHandler());
// Die Portnummer (5001) muss mit dem Port des gRPC-Servers übereinstimmen.
mit var channel = GrpcChannel.ForAddress(" https://localhost :5001", new GrpcChannelOptions
{
HttpClient = neuer HttpClient(Handler)
});
var client = new Greeter.GreeterClient(channel);
var answer = await client.SayHelloAsync(new HelloRequest { Name = new string('A', 3068 ) });
Console.WriteLine("Gruß: " + Antwort.Nachricht);
Console.WriteLine("Zum Beenden eine beliebige Taste drücken...");
Console.ReadKey();

Ich hänge eine Repro-Lösung an, die Client und Server enthält.
GrpcWeb.zip

Das äquivalente Projekt mit normalem gRpc konnte Nachrichten von 20k ohne Probleme verarbeiten.
Können Sie mir bitte raten, ob ich etwas konfigurieren kann, um dieses Limit zu entfernen?

@curia-damiano kannst du damit ein neues Problem einreichen? Bleiben wir in diesem Thread bei der Erörterung der speziellen Funktion zur Unterstützung von gRPC ( ohne gRPC-Web) in IIS/Azure App Service. gRPC-Web wurde früher in diesem Thread angesprochen, weil es eine gute Alternative ist, aber ich möchte diesen Thread weiterhin auf das primäre Ziel der nativen gRPC-Unterstützung konzentrieren.

@MarkStega kannst du mit deiner Frage auch ein neues Problem einreichen? Versuchen wir zu vermeiden, dass dieser Thread mit mehreren möglichen Themen überladen wird (auch wenn sie verwandt sind). Dieses Problem verfolgt die native gRPC -Unterstützung in IIS/Azure App Service

Können wir bitte eine ETA haben, wann gRPC auf Azure App Service verfügbar sein wird?

Wir haben keine ETA-Updates. Wir werden diesen Thread aktualisieren, wenn wir eine ETA haben. Dies erfordert Windows-Änderungen, und wir arbeiten mit diesem Team zusammen, um zu versuchen, sie so schnell wie möglich umzusetzen, aber ihr Zeitplan liegt nicht in unserer direkten Kontrolle.

Können wir einen gRPC-Dienst erstellen, der als Container verpackt ist und in einer Web-App für Container in Azure ausgeführt wird?

@fgheysels Nein. Es ist immer noch hinter IIS als Proxy, der die erforderliche HTTP/2-Funktionalität nicht verarbeiten kann.

Dafür gibt es jetzt 3 Möglichkeiten:

1. Geben Sie eine öffentliche IP-Adresse frei und verwenden Sie eine VM.
2. Verwenden Sie Kubernetes mit Azure Application Gateway Ingress (bei dem die Anweisungen fehlschlagen, da das Helm-Skript veraltet ist und daher derzeit nicht verwendet werden kann) oder verwenden Sie nginx ingress (Sie verlieren die Firewall und die DoS-Abwehr).
3. Verwenden Sie Azure Container-Dienste und stellen Sie es einer öffentlichen IP-Adresse zur Verfügung, oder verwenden Sie nginx, um es umzukehren, oder verwenden Sie Azure Application Gateway, um es umzukehren.

Nichts anderes wird funktionieren.

@JohnGalt1717

Verwenden Sie Azure Container-Dienste und stellen Sie es einer öffentlichen IP-Adresse zur Verfügung, oder verwenden Sie nginx, um es umzukehren, oder verwenden Sie Azure Application Gateway, um es umzukehren.

Azure Application Gateway funktioniert derzeit nicht. Es hat die gleiche Einschränkung

Ich denke, wir könnten es mit unserem .net-Code in der gpogle-Cloud ausführen?

Am Mittwoch, 1. April 2020, 7:26 Uhr, Sourabh Shirhatti, [email protected]
schrieb:

@JohnGalt1717 https://github.com/JohnGalt1717

Verwenden Sie Azure Container-Dienste und stellen Sie sie einer öffentlichen IP-Adresse zur Verfügung oder verwenden Sie nginx für
Reverse-Proxy oder verwenden Sie Azure Application Gateway zum Reverse-Proxy.

Azure Application Gateway funktioniert derzeit nicht. Es hat das gleiche
Einschränkung

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606855605 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7LVZJTQ2QPRHVB5G5TRKJGYLANCNFSM4HDHMSDA
.

@shirhatti Ok, das wird also immer schlimmer. Microsoft hat es effektiv so gestaltet, dass .NET mit gRPC nicht auf Microsoft Azure ausgeführt werden kann. Wenn es nicht so traurig wäre, wäre es HÖLLIG LUSTIG.

Hier also die aktualisierte Liste:

1. Geben Sie eine öffentliche IP-Adresse frei und verwenden Sie eine VM (setzen Sie Haproxy, Nginx oder etwas auf die VM, um den Proxy umzukehren)
2. Verwenden Sie Kubernetes (AKS) mit Nginx-Ingress.

Ich glaube nicht, dass ACS funktionieren wird, weil es immer noch IIS davor stellt, wenn der Speicher dient.

Und Nr. 2 funktioniert möglicherweise auch nicht, weil der Load Balancer unter Windows auch IIS sein könnte ... Hat jemand das tatsächlich irgendwo in Azure zum Laufen gebracht?

Ich denke, dieses Github-Ticket definiert, was ich seit Monaten über das .NET-Team sage und was vor sich geht.

Microsoft hat es effektiv so gestaltet, dass .NET mit gRPC nicht auf Microsoft Azure ausgeführt werden kann. Wenn es nicht so traurig wäre, wäre es HÖLLIG LUSTIG.

Hier gibt es nichts Spezifisches für .NET, die Beschränkung liegt in der Windows- und Azure-Infrastruktur im Zusammenhang mit HTTP/2. Sie hätten das gleiche Problem mit anderen Webstacks in Azure. Windows und Azure arbeiten daran, uns zu entsperren, aber es erfordert Änderungen an grundlegenden Komponenten, deren erneute Bereitstellung viel Zeit in Anspruch nimmt.

Das alles steht in direktem Zusammenhang mit .net. Auf den Azure- und .net-Websites steht wörtlich, dass .net die Sprache von Azure ist.

Aber Sie können diese Sprache nicht mit Azure verwenden, aber Sie können sie problemlos in AWS und Google Cloud verwenden.

Es ist eine Peinlichkeit, wie bei so vielen massiven Fehlern des .net-Teams in letzter Zeit, aber ihre Arroganz ist ohne Grund auf einem Allzeithoch.

Und sie haben uns noch nicht einmal andere Problemumgehungen gegeben, als gRPC-Web zu verwenden, das ein Poc und kein echtes Produkt ist.

Ja, aber wir können den gesamten .net-Stack auf Google Cloud ausführen, .net unterstützt
gRPC alles in Ordnung. Es macht mir also nichts aus, auf GPC zu laufen, bis sie das behoben haben
auf Azur.
Ich entwickle App-Dienste oder serverlose Apps, ich interessiere mich für keine
Containerlösungen, da sie für groß angelegte Bereitstellungen zu kostspielig sind
Ich habe.

Am Mittwoch, 1. April 2020 um 9:57 Uhr James Hancock [email protected]
schrieb:

Das alles steht in direktem Zusammenhang mit .net. es heißt wörtlich auf dem azurblauen und
.net-Websites, dass .net die Sprache von Azure ist.

Aber Sie können diese Sprache nicht mit Azure verwenden, aber Sie können sie auf AWS und verwenden
Google Cloud ganz einfach.

Es ist peinlich, wie bei so vielen massiven Fehlern des .net-Teams
In letzter Zeit ist ihre Arroganz ohne Grund auf einem Allzeithoch.

Und sie haben uns nicht einmal Workarounds irgendeiner Art gegeben, außer zu verwenden
gRPC-Web, das ein Poc ist, kein echtes Produkt.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606927717 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7MRPFQBH52XDHUNP63RKJYMVANCNFSM4HDHMSDA
.

Zuerst sollte Microsoft entsetzt sein über das, was Sie gerade gesagt haben.

Zweitens habe ich gerade unsere Web-Sachen mithilfe virtueller Knoten auf Azure Kubernetes umgestellt, und es kostet uns etwa die Hälfte dessen, was uns App-Dienste gekostet haben, und hat die doppelte Leistung.

Aks ist ein Durcheinander von Dingen, die nicht richtig funktionieren, und veraltete Dokumentation, aber sobald Sie verwaltete Identitäten und eine öffentliche IP-Adresse erhalten haben, ist der Rest einfach.

Ja, aber das ist eine wirklich große Veränderung für Microsoft! und ich mag die
Einfachheit von gRPC, obwohl ich vielleicht auf http Rx umsteige. Ich konnte meine nicht bekommen
websocket to solution to work, da es SSL/TLS-Probleme zu geben schien.
Sieht so aus, als könnte ich Azure-Kubs zum gleichen Preis wie meine S1-App-Dienste erhalten,
muss die Leistung prüfen.

Am Mittwoch, 1. April 2020 um 10:13 Uhr James Hancock [email protected]
schrieb:

Zuerst sollte Microsoft entsetzt sein über das, was Sie gerade gesagt haben.

Zweitens habe ich gerade unsere Web-Sachen auf Azure Kubernetes umgestellt
virtuelle Knoten und es kostet uns etwa die Hälfte dessen, was App-Dienste gekostet haben
uns und hat die doppelte Leistung.

Aks ist ein Durcheinander von Dingen, die nicht richtig funktionieren und veraltet sind
Dokumentation, aber sobald Sie verwaltete Identitäten und eine öffentliche IP-Adresse erhalten haben
der Rest ist direkt.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606933338 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7O3N4XVCWM5MGCTS33RKJ2I7ANCNFSM4HDHMSDA
.

Das alles steht in direktem Zusammenhang mit .net. Auf den Azure- und .net-Websites steht wörtlich, dass .net die Sprache von Azure ist.

Dies ist offensichtlich nicht wahr. Die zugrunde liegenden TCP- und HTTP-Stacks werden nicht mit .NET geschrieben. Microsoft arbeitet daran, seine Grundlage für gRPC anzupassen. Dies ist eine komplexe Bereitstellung, die Auswirkungen auf alles hat, was auf Windows-Servern ausgeführt wird, einschließlich Azure selbst.

Es ist eine Peinlichkeit, wie bei so vielen massiven Fehlern des .net-Teams in letzter Zeit, aber ihre Arroganz ist ohne Grund auf einem Allzeithoch.

Diese Art von unproduktivem, kindisch unsinnigem Jammern ist völlig unnötig. Das hat nichts mit dem .NET-Team zu tun. Sie haben den größten Teil von gRPC nativ portiert, damit wir an unseren PoCs arbeiten und bei Bedarf Problemumgehungen verwenden können, und wie erwachsene Erwachsene warten wir, bis die Basisplattform bereit ist, die letzten Teile zu liefern.

@oising

.NET ist die Sprache von Azure. Microsoft vermarktet es als solches. .NET gRPC kann von Azure nicht verstanden werden. Es ist 100% wahr. Es ist ein kompletter Fehlschlag, dass es bei der Veröffentlichung nicht verfügbar war und noch schlimmer ein Jahr später. Es ist irrelevant, dass die Stacks nicht vom .NET-Team innerhalb von Microsoft geschrieben werden. Microsoft ist Microsoft . Ich kümmere mich nicht um ihre kleinen Lehen und künstlichen Grenzen und unangepassten Prioritäten. Mir sind die bestmöglichen Produkte wichtig, die tatsächlich funktionieren. Es ist mir egal, dass Microsoft behauptet, .NET sei Open Source, was es irgendwie nicht mehr zu einem kostenpflichtigen Produkt macht. Es ist ein kostenpflichtiges Produkt. Ich zahle nur indirekt dafür, indem ich Azure, Office und Windows verwende.

Und nein, wir werden nicht warten. Wir wechseln zu einem anderen Cloud-Anbieter, wo es funktioniert. Das ist es, was Microsoft endlos vorantreibt. Zum Teufel, ich hatte einen Microsoft-Support-Mitarbeiter, der sagte und ich zitiere: "Wenn Sie nicht mögen [die Tatsache, dass wir dies zur Laufzeit absichtlich kaputt gemacht haben], können Sie das Produkt eines anderen verwenden." An etwa 100 Kunden. Ja, nun, ich kenne 8, die genau das getan haben, was sie bisher vorgeschlagen haben, und 30-40 weitere, die dies untersuchen. Die geschätzten entgangenen Einnahmen für MS durch diesen einen Supportagenten belaufen sich auf etwa 2,8 Millionen USD, Tendenz steigend.

Ja, genau das werden wir alle tun. Danke für den Tipp Microsoft. Wir werden Azure verlassen, und wir werden .NET verlassen, wenn die Führung ihre Köpfe nicht bald klarmacht.

Worüber sie sich Sorgen machen müssen, ist, wenn Leute wie ich aufhören, sich über diese massiven öffentlichen Fehler zu beschweren, für die sie keine Verantwortung übernehmen, und stattdessen nichts hören und es allen egal ist. Es geschah vor etwa einem Jahr, als Xamarin Forms 18 Wochen lang ohne die Möglichkeit lief, mit dem gleichen Build von Xamarin Forms und Xamarin im Allgemeinen für den Apple Store, den Android Store und den Windows Store zu erstellen. Ich habe gepostet, sie haben es zugegeben, und 18 Wochen später hatte nur 1 Person den Fehlerbericht verfolgt, obwohl es sich um eine vollständige Pause handelte, nicht nur um einen Grenzfall. Warum? Niemand kümmert sich um Xamarin Forms und verließ das Unternehmen und begann mit der Verwendung von Nicht-Microsoft-Tools, und Microsoft verlor den Desktop und das Mobiltelefon. (und versucht immer wieder den gleichen gescheiterten Ansatz, um es zurückzugewinnen, sogar mit Neo und Duo) Im Moment denken die Leute immer noch, dass sie eine Stimme in .NET haben und dass ihre Beschwerden nicht auf taube Ohren stoßen und diese Dinge behoben werden. Die .NET-Führung arbeitet sehr hart daran, deutlich zu machen, dass dies nicht der Fall ist und das Ergebnis mit Xamarin Forms identisch sein wird.

Das Stück Trailer-Header brauchen wir auch für Stack Overflow dringender als gedacht. Können wir hier bei der Priorisierung helfen?

Anwendungsfall

Wir führen Timings über Server-Header durch, um sie in unseren HTTP-Protokollen (in HAProxy) zu erfassen. Wir haben mehrere Header wie X-Sql-DurationMs , X-Sql-Count , X-Reds-DurationMs usw., damit wir sie erfassen, protokollieren und Metriken für sie aggregieren können. Wenn mehr Details helfen, gibt es einen Abschnitt in diesem Blogbeitrag . Dies funktionierte in ASP.NET MVC 5 (vollständiges Framework) gut genug, da die gesamte Antwort gepuffert wurde. Da wir nur sehr wenige Abfragen in Ansichten durchführen, war es eine zu 99 % genaue Timing-Strategie, die insgesamt gut funktionierte.

Jetzt laufen wir auf .NET Core und alles wird gestreamt. Das Problem dabei ist, dass die Timing-Header aufgrund der fehlenden Pufferung gesendet werden, bevor sie vollständig sind. Es ist ein harter Kompromiss. Dies wäre schnell zu beheben, wenn wir diese Timings als Trailer-Header senden und erfassen könnten. Aber es scheint, als wären wir hier an einem IIS-Blocker und wir sind dem Upgrade ausgeliefert (oder wir entfernen uns von IIS), um diese Funktionalität zum Laufen zu bringen.

Persönlich habe ich auch andere Verwendungszwecke, wie MiniProfiler, der den Server-Timing -Header sendet (es ist jetzt seit etwa 3 Jahren fertig und wartet).

Wie können wir dabei helfen, dies zu priorisieren? Gibt es eine Chance, dass zusätzliche Anwendungsfälle dazu beitragen würden, es zu verschieben?

Danke @NickCraver. Diese Arbeit hat bereits hohe Priorität und ist im Gange, aber die Bereitstellung für Dienste wie AppService ist kompliziert und wird noch eine Weile dauern.

Besteht die Möglichkeit, dass es unabhängig von der Azure-Einführung bald in IIS unterstützt wird? -- Ich brauche wirklich nur einen Client in IIS - wenn das überhaupt wichtig ist. Kann IIS also ein http2-Client sein?

Ich muss zustimmen, dass es besorgniserregend ist, dass es für Microsoft-Mitarbeiter unmöglich erscheint, ihre Beine zu nehmen (oder zu diesem Zeitpunkt zu telefonieren) und zu diesem anderen Team zu gehen. Und ärgern sie nur so sehr, dass sie innerhalb eines Tages einen Hotfix bereitstellen.
Wenn das asp / .net-Team nicht auf grpc gedrängt hätte, wäre diese Wartezeit in Ordnung. Aber da Sie ein Produkt vermarkten, das nicht in der Produktion verwendet werden kann, ist es leider an der Zeit für verzweifelte Maßnahmen und das Aufbrechen der Reihen.

Wenn es dir wichtig ist, wirst du es schaffen.

Edit: Ich weiß, „ein Tag“ ist übertrieben, aber es war ein Jahr!

Gibt es überhaupt Dokumente, die erklären, wie gRPC in Azure bereitgestellt wird? zumindest mit AKS? Wäre schön etwas zu haben.

Gibt es überhaupt Dokumente, die erklären, wie gRPC in Azure bereitgestellt wird? zumindest mit AKS? Wäre schön etwas zu haben.

@lumogox Ich habe eine Schritt-für-Schritt-Anleitung zum Bereitstellen von gRPC in Azure erstellt.
https://github.com/rupeshtech/k8s-grpc-dotntecore

@rupeshtech Ich habe mir tatsächlich Ihren Leitfaden angesehen, aber es funktioniert nicht, wenn Sie eine Nachricht im Root-Pfad in Port 80 anzeigen möchten.

Tolle Sachen, aber ich möchte App-Dienste bereitstellen und wir haben noch keine voraussichtliche Ankunftszeit.
Einer der anderen behauptete, AKS sei billiger als App
Dienstleistungen, ich kann das kaum glauben?
Wie auch immer, ich möchte nur App-Dienste oder serverlose Infrastruktur verwenden.

Am Di, 12. Mai 2020 um 17:51 Uhr Luis Molina [email protected]
schrieb:

@rupeshtech https://github.com/rupeshtech habe ich mir tatsächlich angesehen
Ihre Anleitung funktioniert jedoch nicht, wenn Sie eine Nachricht in der anzeigen möchten
Root-Pfad in Port 80.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627175783 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7MUWWWYCGMEK2FH663RRD5YPANCNFSM4HDHMSDA
.

AKS: b12, 2-Knoten-Cluster kostet 176 $ / Monat und bringt Ihnen eine Leistung wie ein p3.

Sie benötigen Folgendes, damit dies funktioniert:

1. nginx-Ingress als Reverse-Proxy.
2. Dockerisierte .net-Core-App
3. Bereitstellungsvorlagen für Ihre .net Core-App
4. Dienstvorlagen für diese Bereitstellungen
5. Die Ingress-Vorlage, die Ihre DNS-Einträge abbildet
6. cert bot für k8s oder Ihr eigenes Zertifikat, um es dem Ingress zuzuordnen.
7. Deaktivieren Sie nur SSL in Ihrer .net-App, es wird mit dem RP schrauben und die Proxy-Unterstützung im .net-Kern aktivieren.
8. Öffentliche IP
9. Azure Container Registry

Es ist ein 30-teiliger Prozess, dies jetzt in Azure zu konfigurieren, und praktisch nichts davon kann über das GUI-Portal durchgeführt werden. Ihnen fehlt das Zuordnen von Containerregistrierungen, das Konfigurieren von Eingangsanbietern (Azure Application Gateway, nginx oder haproxy usw. haben keine GUI zum Einrichten. Weder das Dienstprinzipalmaterial mit anderen Ressourcen noch das verwaltete Identitätsmaterial sind ordnungsgemäß automatisiert (und Sie brauche beides aus unergründlichen Gründen).

Wenn Sie ein Platzhalterzertifikat durchführen, benötigen Sie auch Zugriff auf Ihr DNS über einen der vom certbot k8s-Dienst unterstützten DNS-Anbieter.

Hier ist unser Skript zum Einrichten einer Umgebung, die Ihnen den Einstieg erleichtern könnte:

Azure-Konfiguration

1. AKS erstellen
2. az aks install-cli (falls noch nicht geschehen)
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 publicIp.ipAddress -o tsv
5. Ordnen Sie api, www, admin der öffentlichen IP im DNS zu (z. B. beta.XX.com)
6. az identity create -g RGL-\ -n XX-MI-AKS-\ -o json (Notieren Sie ClientId, PrincipalId, ID und Name)
7. az Rollenzuweisung create --role Reader --assignee \ --scope /subscriptions/\ /resourcegroups/RGL-\
8. Rufen Sie Dienstprinzipalinformationen von Azure Active Directory-Apps ab: XX-AKS-\ SP-xxxx (Datensatzname, Client-ID)
9. Erstellen Sie ein Client-Secret ohne Ablaufdatum und zeichnen Sie es auf
10. az-Rollenzuweisung create --role "Managed Identity Operator" --assignee \ --Umfang "\ "
11. Rufen Sie die DNS-Zonen-ID ab: az network dns zone list --query "[].{ id: id, name: name}"
12. az Rollenzuweisung create --assignee \ --role Mitwirkender --scope \
13. az Rollenzuweisung create --assignee \ --role Mitwirkender --scope \
14. az aks update -n XX-AKS-\ -g RGL-\ --attach-acr clcr\
15. Verwaltete Identität hinzufügen (XX-MI-AKS-\ ) in Key Vault

Kubernetes Let’s encrypt (wenn nicht Produktion)

1. kubectl erstellt den Namespace ingress-basic
2. Helm-Repo stabil hinzufügen 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. Überprüfen Sie, ob dies erforderlich war: 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. Issuer.yaml mit Abonnement und Dienstprinzipal-Client-ID aktualisieren
7. Aktualisieren Sie certificate.yaml auf die DNS-Adresse
8. Aktualisieren Sie ingress.yaml mit Domäneninformationen usw.
9. Erstellen Sie eine Base64-Version des geheimen Dienstprinzipals: echo \ | opensslbase64
10. Aktualisieren Sie secure-dazuredns.yaml mit dem Geheimnis

ODER Kubernetes Azure Application Gateway

1. Funktioniert nicht. Komplettes Durcheinander

Schließen Sie die Kubernetes-Konfiguration ab

1. kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Aktualisieren Sie die Bereitstellungs-API mit Registrierung, Schlüsseltresor, Umgebung und Instrumentierungsschlüssel
3. Aktualisieren Sie die Registrierung in deploy-portal und deploy-admin
4. Aktualisieren Sie die Werte in der Datei identity-binding.yaml (ClientId stammt ebenfalls von der verwalteten Identität oben)
5. kubectl erstellt Namespace XX
6. kubectl config set-context --current --namespace=XX
7. kubectl apply -k ./\
8. Überprüfen Sie, ob das Zertifikat verfügbar ist: kubectl beschreiben Sie das Zertifikat XX-tls-secret

Ja, es ist wirklich so schwer. Und nein, es gibt keinen einfacheren Weg in k8s. Ihre einzige andere Option ist eine VM mit einer öffentlichen IP und die Verwendung eines RP vor Ihrer App. Sie können eine Linux-VM verwenden und Docker darauf ausführen und HAproxy und Ihre App in einem Docker-Container mit einer einzigen Docker-Compose-Datei ziemlich einfach installieren.

Andernfalls sind Sie aufgeschmissen, bis sie beginnen, den Kernel von Windows 2004 (Frühjahr 2020) auf Azure auszurollen. (vorausgesetzt, es hat es dort hinein geschafft und wird nicht bis November verzögert)

Wow, Kumpel, das ist unglaublich, danke, aber da bin ich auch ein wirklich großer Fan von
Azure Dev Ops mit einem NoOps-Ansatz Ich habe wirklich das Gefühl, dass AKS einfach nicht in ist
meine Liga.
Vor allem, wenn ich wahrscheinlich einen anständigen App-Dienst für ein bisschen weniger betreiben kann
als die. Oder wechseln Sie zu einer Azure-Funktion. Ich konnte meinen Websocket nicht abrufen
Lösung für die Bereitstellung in Azure.
Ich bin auch ein großer Fan von Reactive Extensions und es gibt einige nette Rx
Tools da draußen wie diese
https://github.com/lucassklp/Rx.Http
Ich bin mir jedoch nicht sicher, ob dies skalierbar ist

Am Dienstag, 12. Mai 2020 um 22:09 Uhr James Hancock [email protected]
schrieb:

AKS: b12, 2-Knoten-Cluster kostet 176 $ / Monat und bringt Ihnen eine Leistung wie ein p3.

Sie benötigen Folgendes, damit dies funktioniert:

1. nginx-Ingress als Reverse-Proxy.
2. Dockerisierte .net-Core-App
3. Bereitstellungsvorlagen für Ihre .net Core-App
4. Dienstvorlagen für diese Bereitstellungen
5. Die Ingress-Vorlage, die Ihre DNS-Einträge abbildet
6. cert bot für k8s oder Ihr eigenes Zertifikat, um es dem Ingress zuzuordnen.
7. Deaktivieren Sie SSL nur in Ihrer .net-App, es wird mit dem RP schrauben und
   Schalten Sie die Proxy-Unterstützung in .net Core ein.
8. Öffentliche IP
9. Azure Container Registry

Es ist ein 30-teiliger Prozess, dies jetzt und virtuell in Azure zu konfigurieren
Nichts davon kann über das GUI-Portal durchgeführt werden. Ihnen fehlt das Assoziieren
Containerregistrierungen, Konfigurieren von Eingangsanbietern (Azure Application
Gateway, Nginx, Haproxy usw. haben keine GUI, um es einzurichten. Keiner dieser
Service-Principal-Zeug mit anderen Ressourcen, noch verwaltetes Identitäts-Zeug ist
entweder richtig automatisiert (und Sie brauchen beides aus unergründlichen Gründen).

Wenn Sie ein Wildcard-Zertifikat durchführen, benötigen Sie auch Zugriff auf Ihr DNS
über einen der vom certbot k8s-Dienst unterstützten DNS-Anbieter.

Hier ist unser Skript zum Einrichten einer Umgebung, die Ihnen dabei helfen könnte
gestartet:
Azure-Konfiguration

1. AKS erstellen
2. az aks install-cli (falls noch nicht geschehen)
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
   öffentlicheIp.ipAdresse -o tsv
5. Ordnen Sie api, www, admin der öffentlichen IP im DNS zu (z. B. beta.XX.com)
6. az identity create -g RGL- -n XX-MI-AKS- -o json (Aufzeichnen der
   Kunden-ID, Prinzipal-ID, ID und Name)
7. az Rollenzuweisung create --role Reader --assignee --scope
   /subscriptions//resourcegroups/RGL-
8. Rufen Sie Dienstprinzipalinformationen von Azure Active Directory-Apps ab:
   XX-AKS-SP-xxxx (Datensatzname, Kunden-ID)
9. Erstellen Sie ein Client-Secret ohne Ablaufdatum und zeichnen Sie es auf
10. az-Rollenzuweisung create --role „Managed Identity Operator“
    --assignee --scope ""
11. Rufen Sie die DNS-Zonen-ID ab: az network dns zone list --query "[].{ id:
    ID, Name: Name}"
12. az Rollenzuweisung create --assignee --role Contributor --scope
13. az Rollenzuweisung create --assignee --role Contributor --scope
14. az aks update -n XX-AKS- -g RGL- --attach-acr clcr
15. Verwaltete Identität (XX-MI-AKS-) zu Key Vault hinzufügen

Kubernetes Let’s encrypt (wenn nicht Produktion)

1. kubectl erstellt den Namespace ingress-basic
2. helm repo stabil hinzufügen
   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. Überprüfen Sie, ob dies erforderlich war: 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. Issuer.yaml mit Abonnement und Dienstprinzipal-Client-ID aktualisieren
7. Aktualisieren Sie certificate.yaml auf die DNS-Adresse
8. Aktualisieren Sie ingress.yaml mit Domäneninformationen usw.
9. Erstellen Sie eine Base64-Version des geheimen Dienstprinzipals: echo | openssl
   base64
10. Aktualisieren Sie secure-dazuredns.yaml mit dem Geheimnis

ODER Kubernetes Azure Application Gateway

1. Funktioniert nicht. Komplettes Durcheinander

Schließen Sie die Kubernetes-Konfiguration ab

1. kubectl anwenden -f
   https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Aktualisieren Sie die Bereitstellungs-API mit Registrierung, Schlüsseltresor, Umgebung und
   Instrumentierungsschlüssel
3. Aktualisieren Sie die Registrierung in deploy-portal und deploy-admin
4. Aktualisieren Sie die Werte in identity-binding.yaml (ClientId stammt ebenfalls aus der
   verwaltete Identität oben)
5. kubectl erstellt Namespace XX
6. kubectl config set-context --current --namespace=XX
7. kubectl apply -k ./
8. Überprüfen Sie, ob das Zertifikat verfügbar ist: kubectl beschreiben Sie das Zertifikat XX-tls-secret

Ja, es ist wirklich so schwer. Und nein, es gibt keinen einfacheren Weg in k8s. Dein
Die einzige andere Option ist eine VM mit einer öffentlichen IP und die Verwendung einer RP vor Ihrer
App. Sie können eine Linux-VM verwenden und Docker darauf ausführen und HAproxy und installieren
Ihre App in einem Docker-Container mit einer einzigen Docker-Compose-Datei ziemlich
leicht.

Sonst ist man verarscht bis man den Kernel ausrollt
Windows 2004 (Frühjahr 2020) zu Azure. (vorausgesetzt, es hat es dort hinein geschafft und
verzögert sich nicht bis November)

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627302354 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7P74W4DK5RP2BKKI7LRRE365ANCNFSM4HDHMSDA
.

Websockets ist wahrscheinlich eine gute Alternative, wenn Sie sich nicht für gRPC entschieden haben und sich auf Azure App Services konzentrieren.

Sobald Sie k8s konfiguriert haben, ist Azure Devops einfach. Sie weisen es an, den Docker-Container zu erstellen und mit dem build:id -Tag im Azure-Repository bereitzustellen, und dann führen Sie zur Freigabe kubectl aus, um es anzuweisen, den Container der Bereitstellung mit dem richtigen Tag für die Build-ID zu aktualisieren, und es wird einfach transparent eingeführt die neue Version. Wir haben lediglich ein Tool erstellt, das EF-Migrationen vornimmt, damit Sie nicht mit mehreren k8s-Replikaten enden, die das Migrationsskript gleichzeitig aufrufen.

Magischer Kumpel, vielen Dank, ich stehe auch wirklich auf Domain Driven Design, also ich
Ich schätze, ich kann AKS jetzt zu meiner Waffenkammer hinzufügen, aber ich möchte, dass meine Kunden dorthin wechseln
serverlos verstehe ich nicht, warum die meisten Leute anscheinend nicht weitermachen wollen
Behälter?

Am Dienstag, 12. Mai 2020 um 23:05 Uhr James Hancock [email protected]
schrieb:

Websockets ist wahrscheinlich ein guter Fallback, wenn Sie sich nicht zu gRPC verpflichtet haben
und konzentrieren sich auf Azure App Services.

Sobald Sie k8s konfiguriert haben, ist Azure Devops einfach. Du sagst ihm, er soll bauen
den Docker-Container und stellen Sie sie mit der build:id im Azure-Repository bereit
-Tag und dann zum Freigeben führen Sie kubectl aus, um es anzuweisen, die Bereitstellung zu aktualisieren
Container mit dem richtigen Tag für die Build-ID und es wird einfach
die neue Version transparent ausrollen. Wir haben lediglich ein Tool erstellt
das führt EF-Migrationen durch, bevor es das tut, damit Sie nicht damit enden
mehrere k8s-Repliken, die das Migrationsskript gleichzeitig aufrufen.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627329964 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7MW7NJUS475HICIJTTRRFCQBANCNFSM4HDHMSDA
.

@acrigney- Container werden allgemein als „serverlose“ Technologie angesehen. Es ist definitiv umstritten, aber es gibt keine strenge Definition

@acrigney Es gibt viele Gründe, warum serverlose, insbesondere Azure-Funktionen, nicht wünschenswert sind:

1. Azure Functions ist ein spröder, dampfender Misthaufen, der bei Sicherheitspatches mit .net Core immer hinterherhinkt.
2. Azure-Funktionen sind in vielen Fällen eine Blackbox und schwer zu debuggen.
3. Sobald Sie beginnen, es vollständig zu nutzen, ist es teurer als andere Optionen, wenn Sie eine konstante Last haben.
4. Es gibt nichts, was Sie in Azure-Funktionen nicht anders machen könnten
5. K8s bietet eine generische bekannte Umgebung, die auf Ihrem lokalen Entwicklungscomputer genauso funktioniert wie in jeder Cloud, die Sie erstellen möchten. Wenn Sie eine Ressource erstellen, funktioniert es. Es spielt keine Rolle, ob es von Azure oder AWS unterstützt wird, es funktioniert gleich und konsequent im Gegensatz zu Azure Functions, dass wir in Azure regelmäßig andere Ergebnisse als lokal erhalten.
6. K8s kostet auf einem ausgelasteten System weniger als Azure Functions.
7. K8s bietet eine bessere Bereitstellung als Funktionen.
8. Sobald Sie anfangen, mit VS-Code-Remoting in Docker zu arbeiten, möchten Sie nicht mehr zurück. Gleiche Umgebung, gleiche Konfiguration wie Produktion für 100 % Konsistenz. (Wir verwenden k8s im Docker, um mit dem WSL2-Docker zu entwickeln, und drehen k8s in Linux hoch, was wunderbar mit Windows 10 2004 funktioniert, aber die vollständige Entwicklung in k8s kommt bald)
9. k8s bietet Ihnen die gesamte Autonomie von VMs, ohne VMs verwalten, Lastenausgleich usw. durchführen zu müssen. Es funktioniert einfach.
10. Wenn Sie Ihre Docker-Images mithilfe von Plattform-Targeting und IL-Verknüpfung richtig erstellen, sind Ihre Mikrodienste in k8s genauso klein wie in Azure-Funktionen, sodass es keine Skalierungsprobleme gibt.

Das ist nur eine kurze Liste. Azure-Funktionen sind in der Theorie großartig, dann fängt man an, damit den Kopf gegen die Wand zu schlagen und stellt fest, dass es sich nicht viel lohnt.

bis sie mit dem Rollout des Kernels von Windows 2004 (Frühjahr 2020) nach Azure beginnen.

Die notwendige Arbeit für IIS ist noch im Gange und ist in der Version 2004 nicht verfügbar.

@Tracher Wow. Nur autsch. Es wird also mehr als ein Jahr vergangen sein, in dem .net Core gRPC unterstützt und Azure keine praktikable Möglichkeit für die überwiegende Mehrheit der Entwickler weltweit hat, es zu verwenden.

MS muss echte Docker-basierte App-Dienste erstellen, die nginx oder ha Proxy und nicht IIS für RP verwenden. Das ist verrückt.

Wirklich Kumpel, ich denke, das dehnt es aus, sicher, AKS kann aber skalieren
insbesondere bei der Kopplung von Messaging erforderlich, um mehrere auszuführen
Container für ein großes Projekt würde ich Container kaum in Betracht ziehen
im Einklang mit den Idealen der serverlosen Technologie. Ich kann einfach Plug-and-Play alle
Backend-Tech-Microservices mit App-Servern und Funktionen, aber hätte ich
diese Agilität mit Containern?

Am Di, 12. Mai 2020 um 23:31 Uhr onionhammer [email protected]
schrieb:

@acrigney https://github.com/acrigney Container sind ziemlich weit gefasst
als „serverlose“ Technologie angesehen

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627347120 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7PPWZ7MPIETCXPEFYDRRFFUNANCNFSM4HDHMSDA
.

@acrigney Auf jeden Fall würdest du. Und Sie hätten auch keine Abhängigkeitshölle, die Azure Functions ist. (und Sie können den Azure-Funktionshost problemlos in Containern und sogar k8s verwenden, wenn Sie möchten)

@acrigney Versuchen Sie, gRPC für andere Mikrodienste verfügbar zu machen, die im App-Dienst ausgeführt werden? Wie sieht deine Topologie aus?

Danke, Kumpel, aber ich denke, Sie hätten keine Abhängigkeit von der Hölle oder der Enge
Kopplung mit Funktionen. Ich erstelle zustandsbehaftete Microservices mit der DDD-Anwendung
Services mit Azure App Services und ich mache zustandslose Microservices mit
DDD-Anwendungsdienste in Azure-Funktionen. Die DDD-App-Dienste werden verfügbar gemacht
DTOs und die Verwendung der Domänenobjekte und der anderen App-Dienste können dies beobachten
Ereignisse, die von diesen Domänenobjekten ausgelöst werden. Ich brauche einfach keine Behälter und einmal
Sie bauen einen Container, der viel doppelten Code haben wird
in anderen Behältern benötigt würden.

Am Mittwoch, 13. Mai 2020 um 00:09 Uhr James Hancock [email protected]
schrieb:

@acrigney https://github.com/acrigney Auf jeden Fall würden Sie. Und du
hätte auch keine Abhängigkeitshölle, die Azure Functions ist. (und du kannst
Verwenden Sie ganz einfach den Azure-Funktionshost in Containern und sogar k8s, wenn Sie möchten)

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627369635 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7PQLO2K4RVWBQRGQS3RRFKCZANCNFSM4HDHMSDA
.

Die it-does-not-run-on-IIS-Warnung sollte mit einem <marquee> -Tag oben auf der Seite platziert werden: https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

Es ist wirklich inject profanity here , wenn Sie Prototypen erstellt, Prototypdateien erstellt, Ihren Server, Client und die Authentifizierung mit JWT konfiguriert und gerade einem Kunden die ganze Idee vorgestellt haben, da dies das Beste als nächstes ist. since-sliced-bread, um herauszufinden, dass wir es nicht in der Produktion verwenden können, weil wir auf IIS laufen. :(

bis sie mit dem Rollout des Kernels von Windows 2004 (Frühjahr 2020) nach Azure beginnen.

Die notwendige Arbeit für IIS ist noch im Gange und ist in der Version 2004 nicht verfügbar.

Gibt es eine Eta / Roadmap?

Die it-does-not-run-on-IIS-Warnung sollte mit einem <marquee> -Tag oben auf der Seite platziert werden: https://docs.microsoft.com/en-us/aspnet/core /grpc/?view=aspnetcore-3.1

Sie haben Recht, ich habe https://github.com/dotnet/AspNetCore.Docs/issues/18336 zur Klärung eingereicht.

Gibt es eine Eta / Roadmap?

Nein, es gibt zu viele bewegliche Teile, um eine verlässliche Schätzung abgeben zu können.

Hat jemand eine Dokumentation zur Konfiguration von Nginx mit Grpc und Kestrel?

Hallo zusammen, können wir einige der Anfragen für gRPC in der AppService-Benutzerstimme umleiten https://feedback.azure.com/forums/169385-web-apps?

Kurze Frage: Ist der Support für IIS und Azure App Service gekoppelt oder können/werden sie separat bereitgestellt?

Danke!

Sie sind etwas gekoppelt – das Ingress- und Windows-Hosting von Azure App Service basiert auf IIS, daher ist die Unterstützung von IIS eine Voraussetzung.

Dann muss App Service basierend auf einem Build mit diesen Fixes bereitgestellt werden, sodass App Service nach der IIS-Unterstützung kommt.

Kurze Frage: Ich habe den gRPC-Server auf IIS (10.0) bereitgestellt und bekomme jetzt die Fehlermeldung „Status(StatusCode=Cancelled, Detail=\"No grpc-status found on response.\")“. Ich habe das WebApi-Projekt als gRPC-Client verwendet. Wer kann mir helfen?

Kurze Frage: Ich habe den gRPC-Server auf IIS (10.0) bereitgestellt und erhalte jetzt die Fehlermeldung „Status(StatusCode=Cancelled, Detail="No grpc-status found on response.")". Ich habe das WebApi-Projekt als gRPC-Client verwendet. Wer kann mir helfen?

Geht nicht, gRCP wird von IIS nicht unterstützt.

@lumogox @Dhananjay48 Hinweis: GRPC-Web wird von IIS unterstützt und Sie verlieren größtenteils nur das Client-Streaming. Das ist also eine Umgehung, wenn auch keine großartige.

Ansonsten warten wir nach dem, was ich sehe, bis mindestens Dezember, bevor dies in IIS behoben wird, also fahren Sie fort und verwenden Sie etwas anderes wie nginx als Reverse-Proxy.

Wenn Sie GRPC nur auf Azure App Service bereitstellen möchten, können Sie dies jetzt mit einem Linux-Container tun

@EdiWang Dies wird derzeit von App Service für Linux nicht unterstützt. Wir arbeiten derzeit mit App Service daran, dies zu ermöglichen, aber ich habe keine voraussichtliche Ankunftszeit zum Teilen

Liegt das daran, dass immer noch HTTP.sys vor der Webapp steht, obwohl es sich um einen Docker-Container handelt, der unter Linux läuft?

Soweit ich weiß, werden alle App-Dienste von IIS als Reverse-Proxy ausgeführt. Daher werden sie nicht funktionieren, bis dies behoben ist.

Nur etwas mit einer öffentlichen IP oder einem Rped von ha oder nginx usw. (Linux) funktioniert. Kubernetes mit nginx oder ha funktioniert als Beispiel gut, aber Application Gateway als Ingress nicht.

Soweit ich weiß, werden alle App-Dienste von IIS als Reverse-Proxy ausgeführt. Daher werden sie nicht funktionieren, bis dies behoben ist.

Nur etwas mit einer öffentlichen IP oder einem Rped von ha oder nginx usw. (Linux) funktioniert. Kubernetes mit nginx oder ha funktioniert als Beispiel gut, aber Application Gateway als Ingress nicht.

Es ist auch mein Verständnis. Ich bin tatsächlich hier gelandet, weil ich gelesen habe, ob allen App-Diensten ein IIS vorangestellt ist. Denn in den Dokumenten hier: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse- Proxy - es rät uns, einen umgekehrten Proxy vor Kestrel zu installieren, wenn Sie Kestrel dem Internet aussetzen wollen :) Ich weiß, dass es einen IIS gibt, wenn er unter Windows ausgeführt wird, aber ich kann keinen finden, um diese HTTP.sys oder IIS zu validieren ist auch Fronting, wenn Docker in einem App-Dienst ausgeführt wird. Dieser Thread ist der nächste, dem ich je gekommen bin. Das Lustige ist, dass ich diesen Thread abonniere, weil ich mich auch ziemlich für gPRC interessiere :)

Ich kann bestätigen, dass iis auch Container-basierte App-Dienste unterstützt, einschließlich Linux-Dienste.

Ihre einzigen Optionen sind VMS, wo Sie das Rp selbst gemacht haben, oder fragt.

＠davidfowl AppService User Voice hat nicht viel Aufmerksamkeit erhalten.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Könnte dies der Grund für die langsame Implementierung sein? Wie Sie dieses Problem sehen, denke ich, dass gRPC-Unterstützung wichtig ist.

Ja, zumal ich Websockets auch nicht zum Laufen bringen konnte und das bin ich
besorgt über die Kosten der Container, da ich viel laufen müsste.

Am Freitag, 12. Juni 2020 um 21:58 Uhr Takekazu Omi [email protected]
schrieb:

＠davidfowl AppService User Voice hat nicht viel Aufmerksamkeit erhalten.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Könnte dies der Grund für die langsame Implementierung sein? Wie Sie das sehen
Problem, ich denke, gRPC-Unterstützung ist wichtig.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-643232429 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7L4452ZISXIPNAXWYLRWIKADANCNFSM4HDHMSDA
.

Das Hinzufügen der Anfrage dort ist immer noch sehr wichtig.

@davidfowl Das ist viel leichter gesagt als getan. Versuchen Sie, sich mit Ihrem Microsoft-Konto mit New Edge auf der Website anzumelden. Öffnet ein neues Fenster und tut nichts. Versuchen Sie, sich mit meiner E-Mail-Adresse anzumelden, nun, ich habe das Passwort vergessen, die Passwort-E-Mail geht an Junk-Mail für eine @outlook.com-E-Mail-Adresse. Ändern Sie es, melden Sie sich an, und kein Passwortmanager fordert Sie auf, das Passwort usw. zu speichern.

Einfach WOW schlecht. Ich vermute, dass das Azure-Team dadurch kein gutes Feedback erhält. Ich hoffe, Sie können dies an die richtigen Leute weiterleiten, um dieses Chaos zu beheben.

Vielleicht hilft es jemandem, grpc auf iis zu hosten.
Hier ist ein Beispiel für die Arbeit mit grpcweb Blazor WebAssembly mit gRPC-Web-Code-First-Ansatz , der iis per Remote-Veröffentlichung wie einen Zauber hostet. Ich nehme an, es könnte auch anders funktionieren. Ich habe keine Leistungstests durchgeführt, daher kann ich das nicht kommentieren, aber ich denke, es würde zumindest bei Lösungen bis hin zu mittelgroßen Lösungen gut funktionieren.
Hier ist der Link zu github
Es verwendet auch protobuf-net.Grpc.AspNetCore, was keine langweilige Protobuff-Deklaration ist. Es ist so gut, wenn Sie direkt zur Implementierung gehen oder zusätzliche Methoden zur Anfrage/Antwort hinzufügen könnten.

Hallo zusammen, ich muss in der Grpc-Nachricht einen String-Array-Typ dataType definieren. nicht sicher, wie zu tun. im Moment mache ich es als
wiederholte Zeichenfolge Name = 1,
Hier brauche ich das Namensfeld als String-Array-Typ. Aber es zeigt einen Fehler, dass es sich um ein schreibgeschütztes Feld handelt, wenn Daten darin gebunden werden.

@ Dhananjay48 Dies ist kein StackOverflow. Bitte stellen Sie dort Ihre Frage.
Behalten wir dieses Problem für Dinge im Zusammenhang mit gRPC in App Service.

Soweit ich weiß, werden alle App-Dienste von IIS als Reverse-Proxy ausgeführt. Daher werden sie nicht funktionieren, bis dies behoben ist.

Nur etwas mit einer öffentlichen IP oder einem Rped von ha oder nginx usw. (Linux) funktioniert. Kubernetes mit nginx oder ha funktioniert als Beispiel gut, aber Application Gateway als Ingress nicht.

Könnte „Kestrel in einer Reverse-Proxy-Konfiguration verwendet“ mit nginx eine Lösung sein? https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy '

Ich habe den Vorschlag an @JamesNK in die Dokumentation gestellt, um eine Beispiel-Hosting-Lösung aufzunehmen:
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
Wurde kürzlich angekündigt und kann in Azure bereitgestellt werden.

Am Donnerstag, 25. Juni 2020 um 13:48 Uhr schrieb OzBob [email protected] :

Soweit ich weiß, werden alle App-Dienste von IIS als Reverse-Proxy ausgeführt.
Daher werden sie nicht funktionieren, bis dies behoben ist.

Nur etwas mit einer öffentlichen IP oder rped von ha oder nginx etc (Linux) wird
Arbeit. Kubernetes mit nginx oder ha funktioniert gut als Beispiel, aber als Anwendung
Gateway als Ingress nicht.

Könnte 'Kestrel in einer Reverse-Proxy-Konfiguration verwendet' mit nginx sein, a
Lösung?
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy
'

Ich habe den Vorschlag an @JamesNK https://github.com/JamesNK in die
docs, um eine beispielhafte Hosting-Lösung einzufügen:
dotnet/AspNetCore.Docs#18953
https://github.com/dotnet/AspNetCore.Docs/issues/18953

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-649198280 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABCSC7KBUALMCXDGUS2NV7LRYLCKNANCNFSM4HDHMSDA
.

@acrigney und auch hier auf Ch9 erwähnt: https://youtu.be/T4RD3W2MgHQ?list=TLPQMjUwNjIwMjB6we-UTBA_VA&t=288 von @shirhatti (https://twitter.com/sshirhatti)

Ich wollte nur darauf hinweisen, dass wir mit dem Windows-Team daran gearbeitet haben, diese Szenarien zu ermöglichen. Hier ist ein Blogbeitrag des Windows-Teams darüber, und https://github.com/dotnet/aspnetcore/pull/24120 enthält einige der Folgearbeiten, um Dinge in ASP.NET Core offenzulegen.

Es wird noch eine Weile dauern, bis all das landet, aber es ist schön, berichten zu können, dass wir zumindest Fortschritte machen.

Vielen Dank für die Nachbereitung, sehr hilfreich und geschätzt !!

Am Mittwoch, 22. Juli 2020 um 11:17 Uhr Kevin Pilch [email protected]
schrieb:

Ich wollte nur darauf hinweisen, dass wir mit dem Windows-Team daran gearbeitet haben
Beginnen Sie mit der Aktivierung dieser Szenarien. Hier ist ein Blogbeitrag
https://aka.ms/grpcblogpost vom Windows-Team darüber und #24120
https://github.com/dotnet/aspnetcore/pull/24120 hat einige der
Nachfolgearbeiten, um Dinge in ASP.NET Core verfügbar zu machen.

Es wird noch eine Weile dauern, bis all das landet, aber es ist schön, dazu in der Lage zu sein
zu berichten, dass wir zumindest Fortschritte machen.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-662547810 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAUKMASPCV3UE47OJZ6TIMDR44GKTANCNFSM4HDHMSDA
.

Ich wollte nur darauf hinweisen, dass wir mit dem Windows-Team daran gearbeitet haben, diese Szenarien zu ermöglichen. Hier ist ein Blogbeitrag des Windows-Teams darüber, und #24120 enthält einige der Folgearbeiten, um Dinge in ASP.NET Core offenzulegen.

Es wird noch eine Weile dauern, bis all das landet, aber es ist schön, berichten zu können, dass wir zumindest Fortschritte machen.

Beachten Sie, dass dies bereits in den HttpSys-Server von AspNetCore in den 5.0-Vorschauen integriert wurde. Bitte versuchen Sie es. Wenn wir jetzt Probleme auf dieser Ebene identifizieren können, sollten wir weniger Probleme haben, wenn wir die IIS-Ebene darüber hinzufügen.

Bedeutet dies, dass ich vollständiges gRPC auf IIS ausführen kann, wenn ich ASP.NET Core verwende, das auf die .NET 5-Vorschau abzielt?

Noch nicht. Hier gibt es verschiedene Teile:

1. Http.sys-Modul in Windows
2. ASP.NET Core-Unterstützung dafür in HttpSysServer
3. IIS-Unterstützung dafür in Windows
4. ASP.NET Core-Unterstützung hierfür auf IIS
5. Unterstützung dafür im Reverseproxy, den Azure App Service verwendet
6. Azure App Service stellt einen Build von Windows mit 1 und 3 bereit.
7. Azure App Service stellt einen Build des Reverseproxys von 5 bereit
8. Azure App Service stellt einen Build von ASP.NET Core mit 2 und 4 bereit.

Was @Tratcher gesagt hat, ist, dass 1 und 2 in Vorschauversionen von .NET 5 verfügbar sind. Wir arbeiten gerade an 3 und 4, aber das Ausprobieren von 1 und 2 wird uns helfen, Feedback darüber zu geben, ob das funktionieren wird, da Http. sys-Unterstützung ist eine Untermauerung der IIS-Unterstützung.

Hätte sagen sollen, dass 1 in Vorschauen von Windows verfügbar ist und 2 in Vorschauen von .NET 5 verfügbar ist.

Die Windows-Insider-Vorschau ist mit aktualisierter http.sys verfügbar
https://techcommunity.microsoft.com/t5/networking-blog/windows-server-insiders-getting-grpc-support-in-http-sys/ba-p/1534273

Irgendwelche Ideen, ob dies als Windows-Update für Windows Server 2016/2019 verfügbar sein wird?

Und die IIS-Unterstützung ist jetzt in den neuesten hier angekündigten Windows Insider-Builds enthalten.

Wir untersuchen, ob es möglich sein wird, diese Änderungen in den Service-Build zurückzuportieren, aber das steht noch in den Sternen. Ab sofort ist der einzige Plan, dass sie in zukünftigen Versionen enthalten sein werden.