Привет @moodya , вы ознакомились с документацией по адресу https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio ?

Если вы столкнулись с проблемой, сообщите нам об этом, и мы проведем расследование.

Да, я уже создал службу, которая работает как общая размещенная служба. Я перенес его на новый шаблон asp net core 3 и заставил его работать на самостоятельно размещенной пустельге, но в настоящее время рассматриваю возможность размещения его за iis и, надеюсь, развертывание в качестве службы приложений в Azure. Я не могу заставить бывшего (iis) работать.

Получите Outlook для Android https://aka.ms/ghei36

От кого: Эйлон Липтон ( [email protected] )
Отправлено: среда, 3 апреля 2019 г., 18:06:17
Кому: aspnet/AspNetCore
Копия: мудья; Упомянуть
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

Привет @moodya https://github.com/moodya , вы ознакомились с документацией по адресу https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=визуальная-студия ?

Если вы столкнулись с проблемой, сообщите нам об этом, и мы проведем расследование.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 или отключите звук в ветке https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

Я не могу найти примеры того, как это сделать, так что, возможно, это еще не поддерживается.

Получите Outlook для Android https://aka.ms/ghei36

От кого: Ален Муди [email protected]
Отправлено: среда, 3 апреля 2019 г., 18:11:06
Кому: aspnet/AspNetCore; аспнет/аспнеткоре
Копия: Упоминание
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

Да, я уже создал службу, которая работает как общая размещенная служба. Я перенес его на новый шаблон asp net core 3 и заставил его работать на самостоятельно размещенной пустельге, но в настоящее время рассматриваю возможность размещения его за iis и, надеюсь, развертывание в качестве службы приложений в Azure. Я не могу заставить бывшего (iis) работать.

Получите Outlook для Android https://aka.ms/ghei36

От кого: Эйлон Липтон ( [email protected] )
Отправлено: среда, 3 апреля 2019 г., 18:06:17
Кому: aspnet/AspNetCore
Копия: мудья; Упомянуть
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

Привет @moodya https://github.com/moodya , вы ознакомились с документацией по адресу https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore- 3.0&tabs=визуальная-студия ?

Если вы столкнулись с проблемой, сообщите нам об этом, и мы проведем расследование.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937 или отключите звук в ветке https://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ- pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG .

@shirhatti - есть идеи по этому поводу?

Не удается разместить gRPC в службе приложений IIS/Azure.
Реализация HTTP/2 Http.Sys не поддерживает конечные заголовки ответов HTTP, на которые опирается gRPC.

Спасибо за быстрый ответ. Как бы вы порекомендовали разместить службу grpc в производственном сценарии на данный момент? Кроме того, известны ли вам какие-либо временные рамки, когда служба grpc сможет размещаться в службе iis/app?

Получите Outlook для Android https://aka.ms/ghei36

От кого: Сурабх Ширхатти[email protected]
Отправлено: среда, 3 апреля 2019 г., 19:13:23
Кому: aspnet/AspNetCore
Копия: мудья; Упомянуть
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

Не удается разместить gRPC в службе приложений IIS/Azure.
Реализация HTTP/2 Http.Sys не поддерживает конечные заголовки ответов HTTP, на которые опирается gRPC.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479600486 или отключите звук в ветке https://github.com/notifications/unsubscribe-auth/AlUvPNHH4- HhNsSAtugTw0MzzNco6c76ks5vdO9DgaJpZM4cZ2SG .

Рекомендуемый подход — разместить службу gRPC в AKS.

Что касается сроков службы приложений, я бы уступил @stefsch

Спасибо, что вернулись ко мне. С точки зрения aks Vs service Fabric с точки зрения хостинга службы grpc, является ли aks лучшим выбором? Если да, то почему?

Получите Outlook для Android https://aka.ms/ghei36

От кого: Сурабх Ширхатти[email protected]
Отправлено: понедельник, 8 апреля 2019 г., 7:31:45
Кому: aspnet/AspNetCore
Копия: мудья; Упомянуть
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

Рекомендуемый подход — разместить службу gRPC в AKS.

Что касается сроков службы приложений, я бы отложил на @stefsch https://github.com/stefsch

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-480701227 или отключите звук в ветке https://github.com/notifications/unsubscribe-auth/AlUvPLwQW8HCp- YXsz6yNaK_RH7jbZzWks5veuJRgaJpZM4cZ2SG .

В настоящее время я ожидаю проблем, чтобы сделать это. У меня хорошо работает служба gRPC с использованием aspnetcore 3 preview 3 и Kestrel. Но при использовании IIS появляется ошибка о трейлерах, когда служба отправляет ответ (запрос хорошо принят):
ошибка gPRC => 2 НЕИЗВЕСТНО: статус не получен)
Ошибка Dotnet => «Трейлеры не поддерживаются для этого ответа» в Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer (ответ HttpResponse, String trailerName, StringValues ​​trailerValues) в Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

Согласно приведенным выше сообщениям, не думайте, что iis поддерживает размещение службы grpc.

Получите Outlook для Android https://aka.ms/ghei36

От: [email protected]
Отправлено: четверг, 25 апреля 2019 г., 10:57:42
Кому: aspnet/AspNetCore
Копия: мудья; Упомянуть
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

В настоящее время я ожидаю проблем, чтобы сделать это. У меня хорошо работает служба gRPC с использованием aspnetcore 3 preview 3 и Kestrel. Но при использовании IIS появляется ошибка о трейлерах, когда служба отправляет ответ (запрос хорошо принят):
ошибка gPRC => 2 НЕИЗВЕСТНО: статус не получен)
Ошибка Dotnet => «Трейлеры не поддерживаются для этого ответа» в Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer (ответ HttpResponse, String trailerName, StringValues ​​trailerValues) в Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486607635 или отключите ветку https://github.com/notifications/unsubscribe-auth/AJKS6PEAJ2UKKH2QIKNTCZDPSF6BNANCNFSM4HDHMSDA .

После этого обмена https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 кажется, что веб-сервер не несет ответственности за обработку gRPC. gPRC использует HTTP/2, IIS поддерживает HTTP/2, поэтому он должен работать. Если нет, то это ошибка IIS или, что более вероятно, dotnetcore.

По словам ребят из Microsoft в приведенных выше сообщениях, iis не поддерживает конечные заголовки, необходимые для размещения службы grpc. Это означает, что в данный момент вы не можете разместить его в службах iis или в качестве службы приложений.

Получите Outlook для Android https://aka.ms/ghei36

От: [email protected]
Отправлено: четверг, 25 апреля 2019 г., 11:39:08
Кому: aspnet/AspNetCore
Копия: мудья; Упомянуть
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

После этого обмена https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374 кажется, что веб-сервер не несет ответственности за обработку gRPC. gPRC использует HTTP/2, IIS поддерживает HTTP/2, поэтому он должен работать. Если нет, то это ошибка IIS или, что более вероятно, dotnetcore.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486620151 или отключите звук в ветке https://github.com/notifications/unsubscribe-auth/AJKS6PBQO4427EYN67SI7A3PSGC4ZANCNFSM4HDHMSDA .

Спасибо, я пропустил это, и это имеет смысл с моей проблемой.
@shirhatti поддержка запланирована в дорожной карте?

Мы (IIS) в настоящее время оцениваем, следует ли поддерживать трейлеры ответов HTTP. Пока нет дорожных карт/обязательств, о которых я могу говорить.

@shirhatti Учитывая, что gRPC, по-видимому, является основной функцией .NET Core 3 (https://github.com/grpc/grpc-dotnet), было бы очень жаль, если бы его нельзя было разместить в IIS/App Service, учитывая так много . NET веб-приложения размещаются на них. Я надеюсь, что доступность этой функции в .NET Core поможет вам в реализации вашей дорожной карты.

Я полностью согласен с @jbrantly. gRPC рекламируется как одна из основных функций .NET Core 3.
Он должен размещаться в службах приложений IIS/Azure.
@shirhatti, пожалуйста, рассмотрите возможность добавления этого в дорожную карту

Я также согласен.

Получите Outlook для Android https://aka.ms/ghei36

От: Tomasz [email protected]
Отправлено: пятница, 26 апреля 2019 г., 9:42:58
Кому: aspnet/AspNetCore
Копия: мудья; Упомянуть
Тема: Re: [aspnet/AspNetCore] Служба хоста grpc в iis или как служба приложений? (#9020)

Я полностью согласен с @jbrantly https://github.com/jbrantly . gRPC рекламируется как одна из основных функций .NET Core 3.
Он должен размещаться в службах приложений IIS/Azure.
@shirhatti https://github.com/shirhatti , рассмотрите возможность добавления этого в дорожную карту

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486977989 или отключите ветку https://github.com/notifications/unsubscribe-auth/AJKS6PENWT46GCJ7GQGEGPTPSK6BFANCNFSM4HDHMSDA .

Я не мог не согласиться.

Мы изучаем это. Для этого требуются как изменения ядра Windows, так и изменения IIS.

@davidfowl будет ли это возможно, когда будет выпущен .NET Core 3?
Возможность размещения GRPC в службах приложений для меня является препятствием.

Ну, 29 мая 2019 года, и пока нет никаких признаков того, что это будет возможно. Я ищу хост-службу GRPC в IIS и добавляю сертификат для использования HTTPS :(

Нет, это невозможно в IIS, мы работаем над получением изменений, но это будет медленный процесс (так как для этого требуется обновление Windows).

Я примерно потерял около 3 дней... спасибо iis

Привет @davidfowl
Любое обновление?

@davidfowl есть ли шанс, что это может быть добавлено до выпуска .NET Core 3.0? Или ждать 3.1 или 5.0?

Нет, так как это требует смены окон. Это не будет частью 3.0, и для получения этих функций потребуется последняя версия Windows (какой бы она ни была на данный момент). Расчетного времени прибытия нет

Хм, я как раз планирую реализацию сервисной фабрики, в которой будут использоваться службы без сохранения состояния на основе gRPC и надежные участники поверх dotnet core 3. Укусит ли это меня за задницу? Если я буду размещать на SF, я думаю, я буду использовать пустельгу в качестве ядра? Время прототипа.

@ Поднимаем ту же лодку здесь, но мы медленно движемся к контейнерам k8s + linux, так что в любом случае это помогает подтолкнуть нас к этому.

Я просто добавляю 1 к этому, так как я уже некоторое время играю с gRPC и хочу, наконец, начать применять его в некоторых моих клиентских проектах, поэтому я смотрел на рабочие процессы развертывания. Я немного обескуражен количеством операционных накладных расходов, которые потребовались бы для развертывания в производстве с ядром .net.

Также мне потребовались дни, чтобы понять, что проблема в IIS. На самом деле ищет исправления. Любые обходные пути?

@bingoo без поддержки Windows и IIS Вам не повезло. Вы можете использовать Service Fabric, но у меня нет с этим опыта. Я надеюсь, что его можно будет разместить на IIS или в Azure простым способом.
Для текущих проектов Grpc мне не подходит из-за этой проблемы.

Было бы неплохо, если бы это было большим смелым предупреждением в документах...

Хостинг IIS пока не поддерживается. Службы приложений используют Windows Server 2016 + IIS в качестве серверной части по умолчанию, но теперь они также поддерживают Linux/контейнеры. Если вы просто хотите развернуть GRPC в службе приложений Azure, вы можете сделать это сейчас с помощью контейнера Linux. Но план службы приложений нельзя использовать совместно с планом хостинга Windows. Вам нужно будет потратить дополнительные деньги на новый план службы приложений, поддерживаемый контейнером Linux.

Лучше всего использовать AKS, а затем использовать Ambassador. Ambassador — это API-шлюз на основе Envoy, который работает как контейнер внутри Kubernetes. Это позволяет вам проксировать как grpc, так и grpc-web, например. браузер на сервер grpc, а также клиент grpc, возможно, ac# на сервер grpc. Если вы хотите, чтобы внешний интерфейс js принимал вызовы gRPC, вам нужен grpc web и прокси-сервер, потому что браузеры также не поддерживают должным образом конечные заголовки ответа http2. Grpc Web использует Envoy по умолчанию, поэтому Ambassador лучше.

Если вы просто хотите развернуть GRPC в службе приложений Azure, вы можете сделать это сейчас с помощью контейнера Linux.

@EdiWang В настоящее время это не поддерживается в Службе приложений для Linux. В настоящее время мы работаем со службой приложений, чтобы включить это, но у меня нет информации о ожидаемом времени прибытия.

Привет хорошие люди
Я немного запутался, поэтому у нас не может быть службы grpc в лазури.
Но сама azure использует grpc, Azure Functions Language Worker Protobuf.
https://github.com/Azure/azure-functions-language-worker-protobuf
Или я что-то здесь упускаю?
Пытаюсь понять :confused:

@GoranHalvarsson У вас могут быть службы gRPC в Azure, но вы пока не можете запускать их в службах приложений Azure.

@markrendle Спасибо за ответ. Итак, как я могу использовать/настроить службу gRpc в Azure?

Было бы неплохо, если бы это было большим смелым предупреждением в документах...

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

@markrendle Спасибо за ответ. Итак, как я могу использовать/настроить службу gRpc в Azure?

Не используя IIS, что означает использование Service Fabric или AKS — оба используют необработанный Kestrel. СФ и АКС имеют разные характеристики. Поищите в Google «Service Fabric vs AKS» и выпейте большой кофе.

Я создал пошаговое руководство по созданию тестов и развертыванию службы grpc с использованием .NET Core 3.0.
https://github.com/rupeshtech/k8s-grpc-dotntecore

Я только что изучил эту проблему, поэтому еще ничего не пробовал; но кто-нибудь пробовал использовать Azure Web App для (контейнер https://azure.microsoft.com/en-us/services/app-service/containers/)?

Я запускаю множество микросервисов на основе докеров в Azure App Services, и у меня было очень мало проблем, и это позволило мне обойти другие ограничивающие характеристики предложения OOB App Service.

@ikemtz gRPC работает при использовании кестраля (то есть при работе в контейнерах).

@rupeshtech Спасибо, но ваша статья не имеет отношения к проблеме.

Эта проблема связана с размещением gRPC (или любого приложения, использующего конечные заголовки) в IIS или службе приложений Azure.

Было бы неплохо, если бы это было большим смелым предупреждением в документах...

aspnet/AspNetCore.Docs#14684

Сейчас это реализовано .

@ikemtz Я попытался запустить базовый тест для использования gRPC в контейнере Linux, работающем в веб-приложении Azure для контейнеров, но у меня это не сработало. Нигде не удалось найти никаких сообщений об ошибках, но контейнер даже не отвечал на HTTP-запросы.
Это позор. Я не готов переходить на AKS только для того, чтобы получить эту функциональность, поэтому, думаю, я пока останусь со старыми добрыми службами HTTP.

@searus , если вместо этого вы используете виртуальную машину (работает в лазурной среде)

@GoranHalvarsson Я не готов переходить с PaaS на IaaS только для того, чтобы использовать эту технологию. Я просто подожду, пока Служба приложений Azure сможет это поддерживать.

@davidfowl Любая дорожная карта по этому поводу?

Развертывание в контейнере с помощью Kestral — это хорошо, но это легко сказать
с помощью Lets Encrypt в IIS или службе приложений, которая действительно сдерживает меня.
Если есть какие-либо краткие руководства по запуску личного домена с помощью let
зашифровать на пустельге в контейнере, затем я прыгаю в gRPC головой вперед
иначе очень сложно оправдать накладные расходы на создание некоторых пользовательских
развертывание только для размещения нового стека.

В среду, 16 октября 2019 г., в 6:46 Рассел Симер, [email protected]
написал:

@GoranHalvarsson https://github.com/GoranHalvarsson Я не готов
перейти от PaaS к IaaS только для того, чтобы использовать эту технологию. я просто
подождите, пока служба приложений Azure не сможет это поддерживать.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/AspNetCore/issues/9020?email_source=notifications&email_token=AMNAZYUWLYLGC5ZGB4GAFITQO2TCFA5CNFSM4HDHMSDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLFDDI#issuecomment-5#issuecomment-5
или отписаться
https://github.com/notifications/unsubscribe-auth/AMNAZYTKUYYBWKSW6AMQDHTQO2TCFANCNFSM4HDHMSDA
.

При этом функции Azure и все остальное, что находится поверх службы приложений, не могут использовать gRPC и HTTP/2. Временная шкала была бы хороша даже для частных/публичных предварительных просмотров.

В настоящее время мы работаем над изменениями в http.sys. После этого нам нужно отреагировать на эти изменения в IIS и ARR. Затем нам нужно обновить версию Windows, работающую в службе приложений, чтобы воспользоваться этими изменениями в IIS.

Работа заявлена, но очень сложно оценить, сколько времени потребуется клиентам, чтобы получить ее. Мы будем держать вас в курсе, как продвигаются дела.

Я чувствую, что это то, чему я, к сожалению, не удивлен (что для реализации новых функций http требуются обновления ядра). Очевидно, что IIS не существует в Linux / macosx, но я был бы удивлен, если бы добавление поддержки grpc на другие серверы для других операционных систем... требовало многого для обновления ядра.

Может быть, это достойный аргумент/пример для разделения... Просто говорю

Я чувствую, что это то, чему я, к сожалению, не удивлен (что для реализации новых функций http требуются обновления ядра). Очевидно, что IIS не существует в Linux / macosx, но я был бы удивлен, если бы добавление поддержки grpc на другие серверы для других операционных систем... требовало многого для обновления ядра.

Может быть, это достойный аргумент/пример для разделения... Просто говорю

Я согласен. Вероятно, это как-то связано с тем, что в IIS запущен какой-то низкоуровневый протокол, напрямую связанный с ядром. Это кажется странным, но, по крайней мере, у нас есть подтверждение, что над этим работают и что усыновление не совсем ясное небо.

Помните, когда вам нужно было перейти на Windows 8, чтобы получить поддержку WebSocket? Я тоже 😄

Да, мы помним! Вот сенсация: gRPC выпущен в .NET-Core, и мы используем службы приложений Azure, поэтому важно иметь какой-то вариант, по крайней мере, для тестирования как можно скорее. Кто-нибудь может сказать нам, когда эта синхронизация с выпущенными возможностями .NET-Core произойдет в Azure App Services? Или допустимый обходной путь. Спасибо

Благодарим Вас за обращение к нам. В связи с отсутствием активности по этой проблеме мы закрываем ее, чтобы сохранить незавершенную работу. Если вы считаете, что существует проблема, связанная с платформой ASP.NET Core, которая еще не решена, сообщите о новой проблеме.

@anurse , как мы можем оставить эту проблему открытой?

Он был помещен в обсуждения и помечен как вопрос. Открыто.

Есть ли ETA по этому поводу?

Существуют ли жизнеспособные альтернативы для работы gRPC в производственной среде?
Я просмотрел кое-что, и кажется, что размещение на AKS — это вариант, я просто хочу убедиться, что мы не делаем ничего, что не поможет нам решить нашу проблему.

В настоящее время мы пытаемся запустить какую-то производственную среду для этого проекта:
Проект IdentityServer, взаимодействующий с API через gRPC.
5 веб-порталов, которые взаимодействуют с API через gRPC
API, который общается с ботом Discord (ASP.NET Core) через gRPC.

Мы пытались разместить их на VPS, но я не знаю, сможем ли мы разместить их в производственной среде, просто используя Kestrel, если мы хотим, чтобы все эти приложения работали на одном и том же VPS.

Есть ли у кого-нибудь возможность для нас, чтобы мы могли иметь несколько доменов (1 домен, остальные - поддомены) с 1 IP-адресом на 1 VPS, выполняя все проекты, используя только Kestrel (из-за ограничений в IIS, Http.Sys, окна).

(Или любой другой метод, который позволит нам разместить все это как можно скорее)

Заранее спасибо!

(РЕДАКТИРОВАТЬ)

Мы используем Let's Encrypt (https://github.com/natemcmaster/LetsEncrypt), чтобы получить SSL-сертификат.

(РЕДАКТИРОВАТЬ 2)
Мы также пытались связаться с @davidfowl по этому поводу в твиттере.
https://twitter.com/DapperDino4/status/1204119195765682177 и
https://twitter.com/DapperDino4/status/1204119695344971778

Есть ли ETA по этому поводу?

Добавление @shirhatti и @Tratcher , которые работали над этим.

Время этого сложно определить прямо сейчас. IIS является компонентом Windows и зависит от http.sys, который также является компонентом Windows. Ни IIS, ни http.sys не имеют достаточных функций HTTP/2 для поддержки gRPC. Мы очень тесно сотрудничали с этими командами, чтобы внести изменения, и все они находятся на пути к предстоящему выпуску, но не будут доступны до тех пор, пока не выйдет выпуск Windows Server с соответствующими изменениями.

@JamesNK , можете ли вы рассказать о наличии альтернатив, таких как gRPC-web?

Контекст для тех, кто не знает, что такое gRPC-Web: https://grpc.io/blog/state-of-grpc-web/. Поскольку он использует HTTP/1.1, к нему не применяются ограничения службы приложений Azure. Недостатком является отсутствие преимуществ HTTP/2 (мультиплексирование, сжатие заголовков), а также отсутствие клиентской или двунаправленной потоковой передачи.

Обратный прокси-сервер посланника gRPC-Web уже доступен, но его не так просто настроить. И нет клиента .NET gRPC-Web.

Команда ASP.NET Core еще не решила, собираемся ли мы официально поддерживать gRPC-Web. Сейчас я смотрю на gRPC-Web и на то, как это могло бы выглядеть в .NET Core. Через пару недель я смогу сказать больше, и, возможно, у меня будет экспериментальная предварительная версия, которую люди смогут опробовать в январе.

Поскольку IIS не поддерживает это, может ли служба netcore gRPC размещаться за Nginx?

@ Деннис-Петров Я делаю именно это. Я следовал этому документу https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-3.1 , и gRPC отлично работает.

Могу ли я задать глупый вопрос: почему это не работает в службе приложений Azure в плане службы приложений Linux?

Участвует ли IIS в этом процессе?

@searus Между интерфейсом и службами приложений есть общие уровни, независимо от Linux/Windows. Т.е. в настоящее время внешний интерфейс службы приложений получает соединения HTTP/2, а затем внутренние соединения проксируются как «старый» HTTP для отдельных работников службы приложений. Я уверен, что ведется работа по полной поддержке gRPC, но это требует некоторых усилий, поскольку внутренние компоненты необходимо обновлять, тестировать и выпускать.

Спасибо @devlead.
Я (возможно, наивно) думал, что план службы приложений Linux — это полностью Linux.
Я полностью ценю усилия, приложенные здесь, и спасибо, что нашли время, чтобы объяснить.

Я уверен, что мы работаем над полной поддержкой gRPC.

Он определенно находится в работе. Мы активно работаем над этим, но не можем гарантировать сроки (здесь есть несколько независимых команд, которые должны координировать свои действия). @devlead правильно говорит о поддержке Linux в службе приложений Azure. Интерфейсный прокси работает под управлением IIS. Он поддерживает получение HTTP/2 от клиента, но когда он проксирует трафик в ваше приложение, он понижается до HTTP/1.1. Это было нормально (хотя и не идеально) для обычных приложений, но, поскольку gRPC требует функций HTTP/2, он не подходит для них.

Да, я уже создал службу, которая работает как общая размещенная служба. Я перенес его на новый шаблон asp net core 3 и заставил его работать на самостоятельно размещенной пустельге, но в настоящее время рассматриваю возможность размещения его за iis и, надеюсь, развертывание в качестве службы приложений в Azure. Я не могу заставить бывшего (iis) работать.

@moodya , можешь поделиться с нами, как ты это сделал??

Да, я уже создал службу, которая работает как общая размещенная служба. Я перенес его на новый шаблон asp net core 3 и заставил его работать на самостоятельно размещенной пустельге, но в настоящее время рассматриваю возможность размещения его за iis и, надеюсь, развертывание в качестве службы приложений в Azure. Я не могу заставить бывшего (iis) работать.

@moodya , можешь поделиться с нами, как ты это сделал??

Шаблон gRPC по умолчанию является самостоятельным размещением пустельги. Это не будет работать в службе приложений по причинам, изложенным в этой теме.

Хотя он не может быть размещен в службе приложений, скажем, мы размещаем службу grpc на aks, есть ли проблема с вызовом grpc из службы приложений? Будет ли клиент grpc хотя бы работать в службе приложений?

Хотя он не может быть размещен в службе приложений, скажем, мы размещаем службу grpc на aks, есть ли проблема с вызовом grpc из службы приложений? Будет ли клиент grpc хотя бы работать в службе приложений?

Да, клиенты должны работать. Ограничение касается только входящих запросов, а не исходящих.

Возможно, глупый вопрос, но почему это работает, если я запускаю службу gRPC в режиме отладки с помощью IIS Express? Например, у меня есть веб-приложение (Razor Pages, .net core 3.1), которое звонит в службу gRPC [обновлено из приложения framework mvc, взаимодействующего со службой wcf, если кому-то интересно]. Если я отлаживаю их обоих на своей рабочей станции с помощью службы gRPC в IIS Express, веб-приложение может нормально общаться со службой. Из-за поведения проксирования @anurse , описанного выше, когда служба размещается в IIS, я получаю исключение, что gRPC требует HTTP/2. Прокси-сервер IIS Express для Kestrel отличается от IIS?

Кроме того, возможно, это не место для этого, но я хотел бы смиренно попросить, чтобы на странице ниже было дано небольшое объяснение поведения прокси службы IIS/App Service. Я (возможно, по глупости) потратил целый день, пытаясь перехитрить IIS, потому что думал, что смогу заставить его использовать прокси в HTTP/2, если приложение работает вне процесса в Kestrel https://docs.microsoft.com/en- мы/aspnet/core/grpc/aspnetcore?view=aspnetcore-3.1&tabs=visual-studio#integration -with-aspnet-core-apis

IIS Express не должен работать по тем же причинам, по которым не работает IIS.

@Tratcher Ах, да, ты прав. Я запускал службу gRPC как самостоятельную, а не IIS Express. Спасибо!

У кого-нибудь есть учебник о том, как заставить это работать в AKS? (бонусные баллы за локальную отладку с vs-кодом в aks без необходимости перестраивать контейнеры, чтобы у нас был весь стек с .net core dev, вплоть до развертывания в azure с помощью azure devops и aks).

Самое главное, что вы используете в AKS для проксирования веб-трафика на модули AKS без использования ngix в самом модуле (например, балансировщик нагрузки Azure или что-то в этом роде?)

Хотя он не может быть размещен в службе приложений, скажем, мы размещаем службу grpc на aks, есть ли проблема с вызовом grpc из службы приложений? Будет ли клиент grpc хотя бы работать в службе приложений?

Да, клиенты должны работать. Ограничение касается только входящих запросов, а не исходящих.

К сожалению, это не относится к веб-приложению на основе .Net Core 3.1, вызывающему службу grpc (в данном случае код Pyhton, работающий на виртуальной машине) при размещении в веб-приложениях Azure — тайм-аут. При запуске точно такого же кода с локального хоста вызов проходит (та же служебная виртуальная машина).

@lyulyok можешь собрать диагностику и открыть отдельную тему? Здесь нет известных проблем с клиентом.

У кого-нибудь есть учебник о том, как заставить это работать в AKS?

Пожалуйста, откройте новый вопрос, чтобы обсудить это, или спросите на Stack Overflow . Давайте продолжим эту ветку по теме, тем более, что многие люди интересуются состоянием gRPC в IIS и HTTP.sys, и каждый комментарий пингуется для каждого, кто в нем участвует. Я собираюсь скрыть комментарии не по теме, пожалуйста, не стесняйтесь публиковать новые вопросы , если у вас есть дополнительные вопросы.

Да, я уже создал службу, которая работает как общая размещенная служба. Я перенес его на новый шаблон asp net core 3 и заставил его работать на самостоятельно размещенной пустельге, но в настоящее время рассматриваю возможность размещения его за iis и, надеюсь, развертывание в качестве службы приложений в Azure. Я не могу заставить бывшего (iis) работать.

Теперь доступна экспериментальная поддержка gRPC-Web в .NET. gRPC-Web работает с HTTP/1.1 и HTTP/2 и работает в IIS и службе приложений Azure.

Мы продолжаем работать над HTTP/2 gRPC, работающим в службе приложений Azure, но gRPC-Web — это то, что вы можете использовать уже сегодня . Когда работа по поддержке HTTP/2 в IIS и Службе приложений Azure будет завершена, можно будет легко переключить приложение .NET с gRPC-Web на HTTP/2 gRPC.

Сообщение в блоге: https://devblogs.microsoft.com/aspnet/grpc-web-experiment
Документация: https://docs.microsoft.com/aspnet/core/grpc/browser .

У меня есть клиент grpc, работающий в службе приложений, и служба отлично работает в aks, на случай, если кто-то еще захочет попробовать

@ andrew-vdb Можете ли вы опубликовать конфигурацию, пожалуйста?

Привет @JamesNK ,
в связи с вашим комментарием https://github.com/dotnet/aspnetcore/issues/9020#issuecomment -579597202 и тем фактом, что gRpc-Web в настоящее время кажется _экспериментальным проектом, а не готовым продуктом._

• Нужен ли gRpc-Web для развертывания в IIS? Иначе разве это вообще невозможно?
• У вас есть ETA о том, когда можно будет выполнить развертывание в IIS без gRpc-Web?
• У вас есть ETA, когда Microsoft официально поддержит gRpc-Web?

Нужен ли gRpc-Web для развертывания в IIS? Иначе разве это вообще невозможно?

В настоящее время gRPC через HTTP/2 не работает в IIS. gRPC-Web работает.

У вас есть ETA о том, когда можно будет выполнить развертывание в IIS без gRpc-Web?

Нет. Чтобы внести изменения в Windows и опубликовать их, требуется время.

У вас есть ETA, когда Microsoft официально поддержит gRpc-Web?

Не в данный момент.

к вашему сведению
У меня есть приложение (ASP.Net Core 3.2.0-Preview1), в котором я заменил REST API DAL на gRPC-Web DAL. Я следовал указаниям в блоге Стива Сандерсона. Мое решение можно запускать либо как CSB, либо как SSB, и мне удалось успешно использовать gRPC-Web в обеих конфигурациях (мне пришлось перейти на более новую версию пакетов gRPC.* nuget).

Я по ошибке выполнил дальнейшие обновления из ночных сборок, и в настоящее время все мои пакеты gRPC имеют версию 2.28.0-dev202003020801. Я говорю ошибочно, потому что каждое из двух развертываний моего рабочего решения терпит неудачу.

SSB — клиент сообщает об ошибке «Компонент рендеринга необработанных исключений: не удалось загрузить файл или сборку System.Text.Json, версия = 4.0.1.1, культура = нейтральная, PublicKeyToken = cc7b13ffcd2ddd51». Система не может найти указанный файл. "
Просто добавив явный пакет nuget System.Text.Json (4.7.1) в мой проект веб-сервера, эта ошибка исчезает, и все работает.
[EDIT] Возврат к версиям 2.27.0/2.27.0-Pre1 для всех пакетов gRPC.* из фида NuGet решает эту проблему.

CSB — в тот же момент в клиенте при получении первого ответа gRPC-Web я получаю сообщение об ошибке «WASM: Grpc.Core.RpcException: Status (StatusCode = Internal, Detail = «Неверный ответ gRPC». Протокол ответа понижен до HTTP /1.1."")". У меня нет обходного пути для этого, но это не критично, так как мы поставляем SSB до тех пор, пока не будет выпущен CSB.
[EDIT] Возврат к версиям 2.27.0/2.27.0-Pre1 для всех пакетов gRPC.* из фида NuGet решает эту проблему.

Извините за многословие, но напоследок два вопроса:

• Можно ли использовать другой сериализатор/десериализатор json в gRPC/gRPC-Web?
• Будут ли пакеты gRPC/gRPC-Web «согласованы» с ASP.Net Core 3.2-Preview 2 или потребуется доступ к ночным сборкам?

Привет @JamesNK ,
Мой клиент перешел на gRpcWeb, но мы обнаружили важное ограничение (по которому я не нашел никакой документации): максимальный размер сообщения составляет 3067 символов.
Если из обычного client-service из базового gRpc-сервиса преобразовать в gRpc-Web, то эта строчка выдаст ошибку (т.к. строка 3068 символов, на 1 больше лимита):

// Настройте канал для использования gRPC-Web
var handler = новый GrpcWebHandler(GrpcWebMode.GrpcWebText, новый HttpClientHandler());
// Номер порта (5001) должен соответствовать порту сервера gRPC.
используя канал var = GrpcChannel.ForAddress (" https://localhost : 5001", новый GrpcChannelOptions
{
HttpClient = новый HttpClient (обработчик)
});
var client = новый Greeter.GreeterClient(канал);
var response = await client.SayHelloAsync (новый HelloRequest { Name = new string ('A', 3068 )});
Console.WriteLine("Приветствие: " + ответ.Сообщение);
Console.WriteLine("Нажмите любую клавишу для выхода...");
Консоль.ReadKey();

Я прикрепляю репро-решение, содержащее клиент и сервер.
GrpcWeb.zip

Эквивалентный проект с normale gRpc мог без проблем обрабатывать сообщения размером 20 КБ.
Не могли бы вы посоветовать мне, могу ли я настроить что-то, чтобы снять это ограничение?

@curia-damiano, можете ли вы создать новую проблему с этим? Давайте сохраним эту ветку для обсуждения особенностей поддержки gRPC ( без gRPC-Web) в службе приложений IIS/Azure. gRPC-Web поднимался ранее в этой ветке, потому что это хорошая альтернатива, но я бы хотел, чтобы эта ветка была сосредоточена на основной цели — встроенной поддержке gRPC.

@MarkStega , можете ли вы также создать новую проблему со своим вопросом? Давайте постараемся избежать перегрузки этой ветки несколькими возможными темами (даже если они связаны). Эта проблема связана с отслеживанием встроенной поддержки gRPC в службе приложений IIS/Azure.

Можем ли мы получить ETA, когда gRPC будет доступен в службе приложений Azure, пожалуйста?

У нас нет никаких обновлений ETA. Мы обновим эту ветку, когда у нас будет ETA. Для этого требуются изменения в Windows, и мы работаем с этой командой, чтобы попытаться установить их как можно скорее, но их график не находится под нашим непосредственным контролем.

Можем ли мы создать службу gRPC, упакованную в виде контейнера и работающую в веб-приложении для контейнеров в Azure?

@fgheysels Нет. Он по-прежнему отстает от IIS в качестве прокси-сервера, который не может обрабатывать необходимые функции HTTP/2.

На данный момент есть 3 способа сделать это:

1. Предоставьте общедоступный IP-адрес и используйте виртуальную машину.
2. Используйте Kubernetes с входом шлюза приложений Azure (инструкции не выполняются, потому что скрипт helm устарел, поэтому его нельзя использовать прямо сейчас) или используйте вход nginx (вы теряете брандмауэр и смягчение последствий DoS).
3. Используйте службы контейнеров Azure и предоставьте им доступ к общедоступному IP-адресу или используйте nginx для обратного прокси-сервера или используйте шлюз приложений Azure для обратного прокси-сервера.

Ничто другое не сработает.

@JohnGalt1717

Используйте службы контейнеров Azure и предоставьте им доступ к общедоступному IP-адресу или используйте nginx для обратного прокси-сервера или используйте шлюз приложений Azure для обратного прокси-сервера.

Шлюз приложений Azure в настоящее время не работает. Там такое же ограничение

Я думаю, мы могли бы запустить его в облаке gpogle с нашим кодом .net?

В среду, 1 апреля 2020 г., 7:26 Сурабх Ширхатти, уведомления@github.com
написал:

@JohnGalt1717 https://github.com/JohnGalt1717

Используйте службы контейнеров Azure и предоставьте им общедоступный IP-адрес или используйте nginx для
обратный прокси-сервер или используйте шлюз приложений Azure для обратного прокси-сервера.

Шлюз приложений Azure в настоящее время не работает. Он имеет то же самое
ограничение

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606855605 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7LVZJTQ2QPRHVB5G5TRKJGYLANCNFSM4HDHMSDA
.

@shirhatti Хорошо, так что становится только хуже. Microsoft фактически сделала так, что .NET с gRPC нельзя запускать в Microsoft Azure. Если бы это не было так грустно, это было бы КАК СМЕШНО.

Итак, вот обновленный список:

1. Предоставьте общедоступный IP-адрес и используйте виртуальную машину (поместите haproxy, nginx или что-то еще на виртуальную машину для обратного прокси-сервера)
2. Используйте Kubernetes (AKS) с входом nginx.

Я не верю, что ACS будет работать, потому что он по-прежнему ставит перед собой IIS, если мне не изменяет память.

И № 2 также может не работать, потому что балансировщик нагрузки может быть IIS и в Windows... Кто-нибудь действительно заставил это работать где-нибудь в Azure?

Я думаю, что этот билет на github определяет то, что я говорил в течение нескольких месяцев о команде .NET и о том, что происходит.

Microsoft фактически сделала так, что .NET с gRPC нельзя запускать в Microsoft Azure. Если бы это не было так грустно, это было бы КАК СМЕШНО.

Здесь нет ничего специфичного для .NET, ограничение находится в инфраструктуре Windows и Azure, связанной с HTTP/2. У вас будет такая же проблема с другими веб-стеками в Azure. Windows и Azure работают над тем, чтобы разблокировать нас, но для этого требуются изменения основных компонентов, повторное развертывание которых занимает много времени.

Это все напрямую связано с .net. на веб-сайтах azure и .net буквально написано, что .net — это язык azure.

Но вы не можете использовать этот язык с Azure, но можете легко использовать его в облаке AWS и Google.

Это смущение, как и в случае со многими массовыми ошибками со стороны команды .net в последнее время, но их высокомерие всегда высоко без причины.

И они даже не дали нам никаких обходных путей, кроме как использовать сеть gRPC, которая является poc, а не реальным продуктом.

Да, но мы можем запустить весь стек .net в облаке Google, .net поддерживает
с gRPC все в порядке. Так что я не против работать на GPC, пока они не исправят это.
на Азуре.
Я разрабатываю сервисы приложений или бессерверные приложения, меня не интересуют никакие
контейнерные решения, поскольку они слишком дороги для крупномасштабных развертываний
У меня есть.

В среду, 1 апреля 2020 г., в 9:57 Джеймс Хэнкок[email protected]
написал:

Это все напрямую связано с .net. это буквально говорит о лазури и
веб-сайты .net, на которых .net является языком Azure.

Но вы не можете использовать этот язык с Azure, но можете использовать его на AWS и
Облако Google легко.

Это смущение, как и с таким количеством серьезных ошибок от команды .net.
в последнее время, но их высокомерие всегда высоко без причины.

И они даже не дали нам никаких обходных путей, кроме как использовать
gRPC web, который является poc, а не реальным продуктом.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606927717 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7MRPFQBH52XDHUNP63RKJYMVANCNFSM4HDHMSDA
.

Во-первых, Microsoft должна быть в ужасе от того, что вы только что сказали.

Во-вторых, я только что перевел наши веб-материалы на azure kubernetes с использованием виртуальных узлов, и это стоит нам примерно половину того, что нам стоили службы приложений, и удвоило производительность.

Aks — это беспорядок, который не работает должным образом и имеет устаревшую документацию, но как только вы получите управляемые удостоверения и общедоступный IP-адрес, все остальное будет просто.

Да, но это действительно большое изменение для Microsoft! и мне нравится
простота gRPC, хотя я мог бы переключиться на http Rx. я не мог получить свой
websocket, чтобы решение работало, поскольку у него были проблемы с SSL/TLS.
Похоже, я могу получить лазурные кубы по той же цене, что и мои сервисы приложений S1,
надо проверить работоспособность.

В среду, 1 апреля 2020 г., в 10:13 Джеймс Хэнкок[email protected]
написал:

Во-первых, Microsoft должна быть в ужасе от того, что вы только что сказали.

Во-вторых, я только что перевел наш веб-материал на azure kubernetes, используя
виртуальные узлы, и это стоит нам примерно вдвое меньше, чем стоили сервисы приложений.
нас и имеет двойную производительность.

Акс — это куча вещей, которые не работают должным образом и устарели.
документации, но как только вы получите управляемые удостоверения и общедоступный IP-адрес
остальное прямо вперед.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606933338 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7O3N4XVCWM5MGCTS33RKJ2I7ANCNFSM4HDHMSDA
.

Это все напрямую связано с .net. на веб-сайтах azure и .net буквально написано, что .net — это язык azure.

Это явно неправда. Базовые стеки TCP и HTTP не написаны с использованием .NET. Microsoft работает над адаптацией своей основы для gRPC. Это сложная поставка, которая имеет эффект домино для всего, что работает на серверах Windows, включая саму Azure.

Это смущение, как и в случае со многими массовыми ошибками со стороны команды .net в последнее время, но их высокомерие всегда высоко без причины.

Эта манера непродуктивного, детского бессмысленного нытья совершенно не нужна. Это не имеет ничего общего с командой .NET. Они перенесли большую часть gRPC изначально, поэтому мы можем работать над нашими PoC и использовать обходные пути там, где это необходимо, и, как зрелые взрослые, мы будем ждать, пока базовая платформа не будет готова для доставки финальных частей.

@oising

.NET — это язык Azure. Microsoft продает его как таковой. .NET gRPC не может быть понят Azure. Это 100% правда. Это полный провал, что он не был доступен при выпуске и, что еще хуже, год спустя. Неважно, что стеки не пишутся командой .NET внутри Microsoft . Майкрософт есть Майкрософт . Меня не волнуют их маленькие вотчины, искусственные границы и несогласованные приоритеты. Я забочусь о самых лучших продуктах, которые действительно работают. Меня не волнует, что Microsoft утверждает, что, поскольку .NET имеет открытый исходный код, это почему-то больше не делает его платным продуктом. Это платный продукт. Я просто плачу за это косвенно, используя Azure, Office и Windows.

И нет, мы не будем ждать. Мы перейдем к другому облачному провайдеру, где он работает. Это то, что Microsoft бесконечно продвигает. Черт, у меня был человек службы поддержки Microsoft, скажем, и я цитирую: «Если вам не нравится [тот факт, что мы сломали это во время выполнения по дизайну], вы можете использовать чужой продукт» примерно 100 клиентам. Да, я знаю о 8, которые сделали именно то, что они предложили до сих пор, и еще 30-40, которые исследуют это. Предполагаемый упущенный доход для MS от этого одного агента поддержки составляет около 2,8 миллиона долларов США и продолжает расти.

Да, это именно то, что мы все собираемся сделать. Спасибо за совет Майкрософт. Мы покинем Azure и покинем .NET, если руководство не исправит ситуацию в ближайшее время.

Что им нужно беспокоиться, так это когда такие люди, как я, перестают жаловаться на эти массовые публичные провалы, когда они не берут на себя ответственность за них, и вместо этого они ничего не слышат и всем на них наплевать. Это произошло около года назад, когда Xamarin Forms в течение 18 недель не мог собраться в Apple Store, Android Store и Windows Store с той же сборкой Xamarin Forms и Xamarin в целом. Я написал, они это признали, и 18 недель спустя только 1 человек подписался на отчет об ошибке, несмотря на то, что это был полный прорыв, а не просто крайний случай. Почему? Никто не заботится о Xamarin Forms, и они ушли и начали использовать инструменты, отличные от Microsoft, а Microsoft потеряла настольный компьютер и мобильный телефон. (и продолжает пробовать тот же неудачный подход, чтобы отыграть его даже с Neo и Duo). Прямо сейчас люди все еще думают, что у них есть голос в .NET и что их жалобы не останутся без внимания, и эти вещи будут исправлены. Руководство .NET очень усердно работает, чтобы дать понять, что это не так, и результат будет идентичен Xamarin Forms.

Часть заголовков трейлера — это то, что нам нужно более срочно, чем мы думали для переполнения стека. Можем ли мы помочь с расстановкой приоритетов здесь?

Вариант использования

Мы делаем тайминги через заголовки сервера, чтобы зафиксировать их в наших журналах HTTP (в HAProxy). У нас есть несколько заголовков, таких как X-Sql-DurationMs , X-Sql-Count , X-Reds-DurationMs и т. д., чтобы мы могли записывать их в журнал и агрегировать по ним метрики. Если более подробная информация поможет, есть раздел в этом сообщении в блоге . Это работало достаточно хорошо в ASP.NET MVC 5 (полная структура), потому что весь ответ был буферизован. Поскольку мы делаем очень мало запросов в представлениях, это была стратегия с точностью ~99%, которая в целом работала хорошо.

Теперь мы работаем на .NET Core, и все работает в потоковом режиме. Проблема в том, что заголовки синхронизации отправляются до того, как они будут завершены, из-за отсутствия буферизации. Это суровый компромисс. Это можно было бы быстро исправить, если бы мы могли отправлять и фиксировать эти тайминги в виде заголовков трейлеров. Но похоже, что здесь мы столкнулись с блокировщиком IIS, и мы во власти его обновления (или отказа от IIS), чтобы заставить эту функциональность работать.

Лично у меня есть и другие применения, такие как MiniProfiler, отправляющий заголовок Server-Timing (он был готов и ждал около 3 лет ).

Как мы можем помочь с приоритетом в этом? Есть ли шанс, что дополнительные варианты использования помогут изменить его?

Спасибо @NickCraver. Эта работа уже имеет высокий приоритет и находится в процессе, но ее развертывание в таких службах, как AppService, сложно и все равно займет некоторое время.

Есть ли вероятность, что он скоро будет поддерживаться в IIS, независимо от развертывания Azure? -- Мне действительно нужен только клиент в IIS -- если это вообще имеет значение. Так может ли IIS быть клиентом http2?

Я должен согласиться, что это беспокоит, что для сотрудников Microsoft кажется невозможным взять свои ноги (или телефон в это время) и перейти к той другой команде. И просто насолить им настолько, что они выкладывают хотфикс за день.
Если бы команда asp/.net не настаивала на grpc, этот период ожидания был бы в порядке. Но поскольку вы продаете продукт, который нельзя использовать в производстве, к сожалению, пришло время для отчаянных мер и выхода из строя.

Если вам не все равно, вы сделаете это возможным.

Редактировать: я знаю, что «день» преувеличен, но это был год!

Есть ли какие-либо документы, объясняющие, как развернуть gRPC в Azure? хотя бы через АКС? Было бы неплохо иметь что-то.

Есть ли какие-либо документы, объясняющие, как развернуть gRPC в Azure? хотя бы через АКС? Было бы неплохо иметь что-то.

@lumogox Я создал пошаговое руководство по развертыванию gRPC в Azure.
https://github.com/rupeshtech/k8s-grpc-dotntecore

@rupeshtech Я действительно просмотрел ваше руководство, однако оно не работает, если вы хотите показать сообщение в корневом пути через порт 80.

Отличный материал, но я хочу развернуть его в службах приложений, а ожидаемого времени прибытия пока нет.
Один из других парней утверждал, что AKS дешевле, чем приложение.
услуги, мне трудно в это поверить?
В любом случае я хочу использовать только службы приложений или бессерверную инфраструктуру.

Во вторник, 12 мая 2020 г., в 17:51 Луис Молина[email protected]
написал:

@rupeshtech https://github.com/rupeshtech Я действительно взглянул на
ваш гид, однако, он не работает, если вы хотите показать сообщение в
корневой путь в порту 80.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627175783 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7MUWWWYCMEK2FH663RRD5YPANCNFSM4HDHMSDA
.

AKS: b12, кластер из 2 узлов стоит 176 долларов в месяц и обеспечивает производительность, как у p3.

Для выполнения этой работы вам понадобится следующее:

1. Вход nginx в качестве обратного прокси.
2. Докеризованное основное приложение .net
3. Шаблоны развертывания для вашего основного приложения .net
4. Шаблоны служб для этих развертываний
5. Входной шаблон, который сопоставляет ваши записи DNS
6. cert bot для k8s или ваш собственный сертификат для сопоставления с входом.
7. Отключите SSL только в вашем приложении .net, он испортит RP и включит поддержку прокси в ядре .net.
8. Публичный IP-адрес
9. Реестр контейнеров Azure

Процесс настройки в Azure прямо сейчас состоит из 30 частей, и практически ни одна из них не может быть выполнена через портал с графическим интерфейсом. Им не хватает связывания реестров контейнеров, настройки поставщиков входных данных (Azure Application Gateway, nginx, haproxy и т. д. не имеют графического интерфейса для его настройки. Ни один из компонентов субъекта-службы с другими ресурсами, ни управляемые идентификационные данные также не автоматизированы должным образом (и вы нужно и то, и другое по необъяснимым причинам).

Если вы используете подстановочный сертификат, вам также потребуется доступ к вашему DNS через одного из поставщиков DNS, поддерживаемых службой certbot k8s.

Вот наш сценарий для настройки среды, который может помочь вам начать работу:

Конфигурация Azure

1. Создать АКС
2. az ass install-cli (если вы еще этого не сделали)
3. az aks get-credentials --resource-group RGL-\ --имя ХХ-АКС-\
4. az network public-ip create --resource-group MC_RGL-\ _XX-АКС-\ _eastus --имя PIP-AKS-\ --sku Standard --allocation-method static --query publicIp.ipAddress -o tsv
5. Сопоставьте API, www, admin с общедоступным IP-адресом в DNS (например, beta.XX.com)
6. создание удостоверения az -g RGL-\ -n ХХ-МИ-АКС-\ -o json (запишите ClientId, PrincipalId, идентификатор и имя)
7. назначение роли az create --role Reader --assignee \ --scope /подписки/\ /группы ресурсов/РГЛ-\
8. Получите информацию о субъекте-службе из приложений Azure Active Directory: XX-AKS-\ SP-xxxx (имя записи, идентификатор клиента)
9. Создайте секрет клиента без срока действия и запишите его
10. назначение роли az create --role "Оператор управляемой идентификации" --assignee \ --объем "\ "
11. Получите идентификатор зоны DNS: az network dns zone list --query "[].{ id: id, name: name}"
12. назначение роли az создать --assignee \ --role Участник --scope \
13. назначение роли az создать --assignee \ --role Участник --scope \
14. az update -n XX-AKS-\ -g РГЛ-\ --attach-acr clcr\
15. Добавить управляемое удостоверение (XX-MI-AKS-\ ) в хранилище ключей

Kubernetes Давайте зашифруем (если не производство)

1. kubectl создать пространство имен ingress-basic
2. репозиторий helm добавить стабильную версию 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. Убедитесь, что потребовалось: kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-controller
5. kubectl применить --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
6. Обновите issuer.yaml с помощью подписки и ClientId принципа обслуживания.
7. Обновите сертификат.yaml на адрес DNS
8. Обновите ingress.yaml с информацией о домене и т. д.
9. Сделать версию основного секрета службы Base64: echo \ | база 64 OpenSSL
10. Обновите secure-dazuredns.yaml, указав секрет

ИЛИ Шлюз приложений Azure Kubernetes

1. Не работает. Полный беспорядок

Полная конфигурация Kubernetes

1. kubectl применить -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Обновите deploy-api с помощью реестра, хранилища ключей, среды и инструментария.
3. Обновить реестр в deploy-portal и deploy-admin
4. Обновите значения в identity-binding.yaml (ClientId также взят из управляемого удостоверения выше)
5. kubectl создать пространство имен XX
6. Конфигурация kubectl set-context --current --namespace=XX
7. kubectl применить -k ./\
8. Проверка наличия сертификата: kubectl описывает сертификат XX-tls-secret

Да, это действительно так тяжело. И нет более простого способа в k8s. Единственный другой вариант — виртуальная машина с общедоступным IP-адресом и использование RP перед вашим приложением. Вы можете использовать виртуальную машину Linux и запустить на ней докер, а также довольно легко установить HAproxy и свое приложение в контейнере докера с помощью одного файла для создания докера.

В противном случае вы облажались, пока они не начнут развертывать ядро ​​​​из Windows 2004 (весна 2020 г.) в Azure. (при условии, что он попал туда и не задерживается до ноября)

Вау, приятель, это невероятно, спасибо, но, поскольку я также очень большой поклонник
Azure Dev Ops с подходом NoOps Я действительно чувствую, что AKS просто не в
моя лига.
Особенно, когда я, вероятно, могу запустить приличный сервис приложений за гораздо меньшую сумму.
чем это. Или переключите его на функцию Azure. Я не мог получить свой веб-сокет
решение для развертывания в Azure.
Я также большой поклонник Reactive Extensions, и есть несколько хороших Rx.
инструменты там такие
https://github.com/lucassklp/Rx.Http
Не уверен в масштабируемости этого, хотя

Во вторник, 12 мая 2020 г., в 22:09 Джеймс Хэнкок[email protected]
написал:

AKS: b12, кластер из 2 узлов стоит 176 долларов в месяц и обеспечивает производительность, как у p3.

Для выполнения этой работы вам понадобится следующее:

1. Вход nginx в качестве обратного прокси.
2. Докеризованное основное приложение .net
3. Шаблоны развертывания для вашего основного приложения .net
4. Шаблоны служб для этих развертываний
5. Входной шаблон, который сопоставляет ваши записи DNS
6. cert bot для k8s или ваш собственный сертификат для сопоставления с входом.
7. Отключите SSL только в вашем приложении .net, он испортит RP и
   включить поддержку прокси в .net core.
8. Публичный IP-адрес
9. Реестр контейнеров Azure

Процесс настройки в Azure состоит из 30 этапов прямо сейчас и виртуально.
ничего из этого нельзя сделать через портал с графическим интерфейсом. Им не хватает ассоциации
реестры контейнеров, настройка поставщиков входящего трафика (Azure Application
У шлюза, nginx, haproxy и т. д. нет графического интерфейса для его настройки. Ни один из
Материалы субъекта-службы с другими ресурсами, а также элементы управляемого удостоверения
либо должным образом автоматизированы (и вам нужны оба по непостижимым причинам).

Если вы используете подстановочный сертификат, вам также потребуется доступ к вашему DNS.
через одного из DNS-провайдеров, поддерживаемых службой certbot k8s.

Вот наш сценарий для настройки среды, который может помочь вам получить
начал:
Конфигурация Azure

1. Создать АКС
2. az ass install-cli (если вы еще этого не сделали)
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. Сопоставьте API, www, admin с общедоступным IP-адресом в DNS (например, beta.XX.com)
6. az identity create -g RGL- -n XX-MI-AKS- -o json (запишите
   ClientId, PrincipalId, идентификатор и имя)
7. назначение роли az create --role Reader --assignee --scope
   /подписки//группы ресурсов/RGL-
8. Получите информацию о субъекте-службе из приложений Azure Active Directory:
   XX-AKS-SP-xxxx (имя записи, идентификатор клиента)
9. Создайте секрет клиента без срока действия и запишите его
10. Назначение роли az create --role "Оператор управляемой идентификации"
    --assignee --scope ""
11. Получите идентификатор зоны DNS: список зон DNS сети az --query "[].{ id:
    идентификатор, имя: имя}"
12. назначение роли az create --assignee --role Contributor --scope
13. назначение роли az create --assignee --role Contributor --scope
14. az aks update -n XX-AKS- -g RGL- --attach-acr clcr
15. Добавить управляемое удостоверение (XX-MI-AKS-) в Key Vault

Kubernetes Давайте зашифруем (если не производство)

1. kubectl создать пространство имен ingress-basic
2. репозиторий helm добавить стабильную версию
   https://kubernetes-charts.storage.googleapis.com/
3. helm установить nginx-ingress стабильный/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. Убедитесь, что потребовалось: kubectl --namespace ingress-basic get services -o
   широкий -w nginx-входной-контроллер
5. kubectl применить --validate=false -f
   https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
6. Обновите issuer.yaml с помощью подписки и ClientId принципа обслуживания.
7. Обновите сертификат.yaml на адрес DNS
8. Обновите ingress.yaml с информацией о домене и т. д.
9. Сделать версию основного секрета службы Base64: echo | openssl
   base64
10. Обновите secure-dazuredns.yaml, указав секрет

ИЛИ Шлюз приложений Azure Kubernetes

1. Не работает. Полный беспорядок

Полная конфигурация Kubernetes

1. kubectl применить -f
   https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Обновите deploy-api с реестром, хранилищем ключей, средой и
   инструментальный ключ
3. Обновить реестр в deploy-portal и deploy-admin
4. Обновите значения в identity-binding.yaml (ClientId также из
   управляемое удостоверение выше)
5. kubectl создать пространство имен XX
6. Конфигурация kubectl set-context --current --namespace=XX
7. kubectl применить -k ./
8. Проверка наличия сертификата: kubectl описывает сертификат XX-tls-secret

Да, это действительно так тяжело. И нет более простого способа в k8s. Твой
единственный другой вариант - это виртуальная машина с общедоступным IP-адресом и использование RP перед вашим
приложение. Вы можете использовать виртуальную машину Linux и запустить на ней докер, а также установить HAproxy и
ваше приложение в контейнере докеров с одним довольно красивым файлом для создания докеров
без труда.

Иначе тебе пиздец, пока не начнут выкатывать ядро ​​из
Windows 2004 (весна 2020 г.) в Azure. (при условии, что он попал туда и
не откладывается до ноября)

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627302354 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7P74W4DK5RP2BKKI7LRRE365ANCNFSM4HDHMSDA
.

Веб-сокеты, вероятно, являются хорошим запасным вариантом, если вы не зафиксировали gRPC и сосредоточились на службах приложений Azure.

После настройки k8s использовать Azure Devops несложно. Вы говорите ему собрать контейнер Docker и выполнить развертывание в репозиторий Azure с помощью тега build:id , а затем, чтобы выпустить, вы запускаете kubectl, чтобы сообщить ему обновить контейнер развертывания с помощью правильного тега для идентификатора сборки, и он просто прозрачно развернется новая версия. Единственное, что мы сделали, — это создали инструмент, который выполняет миграцию EF до того, как она это сделает, чтобы у вас не возникло ситуации, когда несколько реплик k8s одновременно вызывают сценарий миграции.

Волшебный приятель, большое спасибо, я также действительно увлекаюсь дизайном, управляемым доменом, поэтому я
думаю, теперь я могу добавить AKS в свой арсенал, но я хочу, чтобы мои клиенты перешли на
без сервера, я не понимаю, почему большинство людей не хотят переходить от
контейнеры?

Во вторник, 12 мая 2020 г., в 23:05 Джеймс Хэнкок[email protected]
написал:

Веб-сокеты, вероятно, являются хорошим запасным вариантом, если вы не перешли на gRPC.
и сосредоточены на службах приложений Azure.

После настройки k8s использовать Azure Devops несложно. Вы говорите ему построить
Docker-контейнер и выполнить развертывание в репозитории Azure с помощью build:id.
тег, а затем, чтобы выпустить, вы запускаете kubectl, чтобы сообщить ему об обновлении развертывания
контейнер с правильным тегом для идентификатора сборки, и он просто
прозрачно развернуть новую версию. Единственное, что мы сделали, это создали инструмент
который выполняет миграцию EF до того, как это произойдет, чтобы вы не получили
несколько реплик k8s одновременно вызывают сценарий миграции.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627329964 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7MW7NJUS475HICIJTTRRFCQBANCNFSM4HDHMSDA
.

Контейнеры @acrigney довольно широко считаются «бессерверной» технологией. Это определенно спорно, но строгого определения нет.

@acrigney Есть много причин, по которым бессерверные функции Azure нежелательны:

1. Функции Azure — это хрупкая дымящаяся куча дерьма, которая всегда отстает от исправлений безопасности с ядром .net.
2. Функции Azure — это черный ящик, и во многих случаях их трудно отлаживать.
3. Как только вы начнете использовать его полностью, это будет дороже, чем другие варианты, когда у вас постоянная нагрузка.
4. Нет ничего невозможного, кроме того, что вы можете делать в функциях Azure.
5. K8s предоставляет общую известную среду, которая работает на вашей локальной машине разработки так же, как и в любом облаке, которое вы хотите создать. Когда вы создаете ресурс, он работает. Неважно, поддерживает ли его Azure или AWS, он работает одинаково и последовательно, в отличие от функций Azure, которые мы регулярно получали в Azure и на локальном уровне.
6. K8s в загруженной системе стоит меньше, чем функции Azure.
7. K8s выполняет развертывание лучше, чем функции.
8. Как только вы начнете работать с кодом VS, удаленным в докер, вам не захочется возвращаться. Та же среда, та же конфигурация, что и в рабочей среде, для 100% согласованности. (Мы используем k8s внутри докера для разработки с докером WSL2 и разворачиваем k8s в linux, который прекрасно работает с Windows 10 2004, но скоро появится полная разработка в k8s)
9. k8s дает вам всю автономию виртуальных машин без необходимости управлять виртуальными машинами, балансировать нагрузку и т. д. Он просто работает.
10. Если вы правильно создадите свои образы докеров, используя таргетинг на платформу и IL, связывающие ваши микросервисы в k8s, они будут такими же маленькими, как и в функциях Azure, поэтому проблем с масштабированием не возникнет.

Это только краткий список. Функции Azure хороши в теории, но потом вы начинаете биться с ними головой о стену и обнаруживаете, что они того не стоят.

пока не начнут выкатывать ядро ​​из Windows 2004 (весна 2020) в Azure.

Необходимая работа для IIS все еще продолжается и недоступна в выпуске 2004 года.

@Тратчер Вау. Просто ой. Таким образом, прошло больше года с ядром .net, поддерживающим gRPC, а у Azure не было жизнеспособного способа его использования подавляющим большинством разработчиков в мире.

MS необходимо создать настоящие службы приложений на основе докеров, которые используют прокси-сервер nginx или ha, а не IIS для RP. Это безумие.

На самом деле, приятель, я думаю, что это натянуто, конечно, AKS может масштабироваться, но
особенно с учетом обмена сообщениями, необходимого для запуска нескольких
контейнеры для большого проекта я бы вряд ли рассматривал контейнеры в
придерживаясь идеалов бессерверных технологий. Я могу легко подключить и воспроизвести любой
бэкэнд-технологические микросервисы с серверами приложений и функциями, но был бы я
эта маневренность с контейнерами?

Во вторник, 12 мая 2020 г., в 23:31 [email protected]
написал:

Контейнеры @acrigney https://github.com/acrigney довольно широко распространены.
считается «бессерверной» технологией

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627347120 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7PPWZ7MPIETCXPEFYDRRFFUNANCNFSM4HDHMSDA
.

@acrigney Абсолютно верно. И у вас не будет ада зависимостей, которым являются функции Azure. (и вы можете легко использовать узел функций Azure в контейнерах и даже k8s, если хотите)

@acrigney Вы пытаетесь предоставить gRPC другим микросервисам, работающим в службе приложений? Как выглядит ваша топология?

Спасибо, приятель, но я думаю, что у тебя не было бы никакой зависимости, черт возьми, или жесткой
связь с функциями. Я создаю микросервисы с отслеживанием состояния, используя приложение DDD.
сервисы с помощью сервисов приложений Azure, и я создаю микросервисы без сохранения состояния с помощью
Службы приложений DDD в функциях Azure. Службы приложений DDD предоставляют
DTO и использовать объекты домена, а другие службы приложений могут наблюдать за
события, запускаемые этими объектами домена. Мне просто не нужны контейнеры и один раз
вы создаете контейнер, в нем будет много дублированного кода, который
потребуется в других контейнерах.

В среду, 13 мая 2020 г., в 00:09 Джеймс Хэнкок[email protected]
написал:

@acrigney https://github.com/acrigney Абсолютно верно. И ты
также не будет ада зависимостей, который является функциями Azure. (и вы можете
легко использовать узел функций Azure в контейнерах и даже k8s, если хотите)

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627369635 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7PQLO2K4RVWBQRGQS3RRFKCZANCNFSM4HDHMSDA
.

Предупреждение о том, что оно не запускается в IIS, должно быть размещено в верхней части страницы с использованием тега <marquee> : https://docs.microsoft.com/en-us/aspnet/core .

Это действительно inject profanity here , если вы занимались прототипированием, создавали прото-файлы, настраивали свой сервер, клиент, аутентификацию с помощью JWT и только что представили всю идею клиенту как «лучшее, что будет дальше». Поскольку нарезанный хлеб, чтобы узнать, что мы не можем использовать его в производстве, потому что мы работаем на IIS. :(

пока не начнут выкатывать ядро ​​из Windows 2004 (весна 2020) в Azure.

Необходимая работа для IIS все еще продолжается и недоступна в выпуске 2004 года.

Есть ли эта/дорожная карта?

Предупреждение о том, что оно не запускается в IIS, должно быть размещено в верхней части страницы с использованием тега <marquee> : https://docs.microsoft.com/en-us/aspnet/core .

Вы правы, я подал https://github.com/dotnet/AspNetCore.Docs/issues/18336 , чтобы уточнить.

Есть ли эта/дорожная карта?

Нет, слишком много движущихся частей, чтобы дать надежную оценку.

Есть ли у кого-нибудь документация по настройке nginx с помощью grpc и kestrel?

Привет всем, можем ли мы перенаправить некоторые запросы для gRPC в голосе пользователя AppService https://feedback.azure.com/forums/169385-web-apps?

Быстрый вопрос: поддержка IIS и службы приложений Azure связана вместе или они могут/будут поставляться отдельно?

Спасибо!

Они в какой-то мере связаны: вход в службу приложений Azure и хостинг Windows зависят от IIS, поэтому получение поддержки в IIS является предварительным требованием.

Затем необходимо развернуть службу приложений на основе сборки с этими исправлениями, поэтому служба приложений появится после поддержки IIS.

Быстрый вопрос: я развернул сервер gRPC на IIS (10.0) и теперь получаю сообщение об ошибке «Статус (StatusCode = Canceled, Detail = \» В ответе не найдено состояние grpc.\»)». Я использовал проект WebApi в качестве клиента gRPC. Кто-нибудь может мне помочь?

Быстрый вопрос: я развернул сервер gRPC на IIS (10.0) и теперь получаю сообщение об ошибке «Статус (StatusCode = Canceled, Detail = «В ответе не найден статус grpc».)». Я использовал проект WebApi в качестве клиента gRPC. Кто-нибудь может мне помочь?

Невозможно, gRCP не поддерживается IIS.

@lumogox @Dhananjay48 Примечание. GRPC-web поддерживается IIS, и по большей части вы теряете только клиентскую потоковую передачу. Так что это обходной путь, хотя и не очень хороший.

В противном случае, согласно тому, что я вижу, мы подождем по крайней мере до декабря, прежде чем это будет исправлено в IIS, поэтому уходите и используйте что-то еще, например nginx, в качестве обратного прокси-сервера.

Если вы просто хотите развернуть GRPC в службе приложений Azure, вы можете сделать это сейчас с помощью контейнера Linux.

@EdiWang В настоящее время это не поддерживается в Службе приложений для Linux. В настоящее время мы работаем со службой приложений, чтобы включить это, но у меня нет информации о ожидаемом времени прибытия.

Это потому, что перед веб-приложением все еще стоит HTTP.sys, хотя это контейнер докеров, работающий в Linux?

Насколько я понимаю, все сервисы приложений обратно проксируются iis. Следовательно, они не будут работать, пока это не будет исправлено.

Будет работать только что-то с общедоступным IP-адресом или rped от ha или nginx и т. д. (Linux). Например, Kubernetes с nginx или ha отлично работает, но шлюз приложений в качестве входа не работает.

Насколько я понимаю, все сервисы приложений обратно проксируются iis. Следовательно, они не будут работать, пока это не будет исправлено.

Будет работать только что-то с общедоступным IP-адресом или rped от ha или nginx и т. д. (Linux). Например, Kubernetes с nginx или ha отлично работает, но шлюз приложений в качестве входа не работает.

Это также мое понимание. На самом деле я оказался здесь, потому что читал, все ли службы приложений защищены IIS. Потому что в документах здесь: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse- прокси - он советует нам установить обратный прокси-сервер перед пустельгой, если вы собираетесь выставить пустельгу в Интернет :) Я знаю, что при работе в Windows есть IIS, но я не могу найти ни одного, чтобы проверить, что HTTP.sys или IIS также появляется при запуске докера в службе приложений. Эта тема самая близкая, к которой я когда-либо подходил. Забавно, что я подписываюсь на эту тему, потому что мне тоже очень интересно в gPRC :)

Я могу подтвердить, что iis также поддерживает службы приложений на основе контейнеров, включая службы Linux.

Ваши единственные варианты - это VMS, где вы сами сделали rp, или aks.

＠ Голос пользователя службы приложений davidfowl не получил должного внимания.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Может ли это быть причиной медленной реализации? Как вы видите эту проблему, я думаю, что поддержка gRPC важна.

Да, особенно потому, что я не мог заставить работать веб-сокеты, и я
беспокоит стоимость контейнеров, так как мне придется много бегать.

В пятницу, 12 июня 2020 г., в 21:58 Такекадзу Оми[email protected]
написал:

＠ Голос пользователя службы приложений davidfowl не получил должного внимания.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Может ли это быть причиной медленной реализации? Как вы видите это
Проблема, я думаю, что поддержка gRPC важна.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-643232429 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7L4452ZISXIPNAXWYLRWIKADANCNFSM4HDHMSDA
.

Добавление запроса туда по-прежнему очень важно.

@davidfowl Это гораздо легче сказать, чем сделать. Попробуйте войти на сайт под своей учетной записью Microsoft с новым краем. Всплывает новое окно и ничего не делает. Попробуйте войти в систему с моей электронной почтой, ну, я забыл пароль, электронная почта с паролем попадает в нежелательную почту для адреса электронной почты @outlook.com. Измените его, войдите в систему, и менеджер паролей не предложит сохранить пароль и т. Д.

Просто ВАУ плохо. Я предполагаю, что в результате команда Azure не получает хороших отзывов. Надеюсь, вы сможете передать это нужным людям, чтобы исправить этот беспорядок.

Может быть, это поможет кому-то разместить grpc на iis.
Вот пример работы grpcweb Blazor WebAssembly с подходом gRPC-Web code-first , который размещается на iis через удаленную публикацию, как шарм. Я предполагаю, что это может работать и другими способами. Я не проводил никаких тестов производительности, поэтому не могу комментировать это, но я думаю, что, по крайней мере, это будет хорошо работать на решениях вплоть до среднего размера.
Вот ссылка на гитхаб
Он также использует protobuf-net.Grpc.AspNetCore, что не является скучным объявлением protobuff. Как же хорошо, когда можно сразу перейти к реализации или добавить дополнительные методы к запросу/ответу.

Привет всем, мне нужно определить тип массива строк dataType в сообщении Grpc. не уверен, как это сделать. прямо сейчас я делаю это как
повторяющаяся строка Имя = 1,
здесь мне нужно поле имени как тип массива строк. Но он показывает ошибку, что это поле доступно только для чтения, когда в нем привязываются данные.

@ Dhananjay48 Это не StackOverflow. Пожалуйста, задайте свой вопрос там.
Давайте сохраним эту проблему для материалов, связанных с gRPC в службе приложений.

Насколько я понимаю, все сервисы приложений обратно проксируются iis. Следовательно, они не будут работать, пока это не будет исправлено.

Будет работать только что-то с общедоступным IP-адресом или rped от ha или nginx и т. д. (Linux). Например, Kubernetes с nginx или ha отлично работает, но шлюз приложений в качестве входа не работает.

Может ли решение «Kestrel, используемое в конфигурации обратного прокси-сервера» с nginx? https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy '

Я предложил @JamesNK включить в документы пример решения для хостинга:
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
Был объявлен недавно и может быть развернут в Azure.

В четверг, 25 июня 2020 г., в 13:48 [email protected] написал:

Насколько я понимаю, все сервисы приложений обратно проксируются iis.
Следовательно, они не будут работать, пока это не будет исправлено.

Только что-то с общедоступным IP-адресом или с помощью ha или nginx и т. д. (Linux) будет
работай. Kubernetes с nginx или ha отлично работает в качестве примера, но приложение
шлюз, так как вход не будет.

Может ли «Kestrel, используемая в конфигурации обратного прокси-сервера» с nginx, быть
решение?
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy
'

Я поместил предложение @JamesNK https://github.com/JamesNK в
docs, чтобы включить пример решения для хостинга:
точка/AspNetCore.Docs#18953
https://github.com/dotnet/AspNetCore.Docs/issues/18953

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-649198280 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABCSC7KBUALMCXDGUS2NV7LRYLCKNANCNFSM4HDHMSDA
.

@acrigney и упоминается здесь, в главе 9: https://youtu.be/T4RD3W2MgHQ?list=TLPQMjUwNjIwMjB6we-UTBA_VA&t=288 @shirhatti (https://twitter.com/sshirhatti)

Я просто хотел сообщить, что мы работаем с командой Windows, чтобы начать использовать эти сценарии. Вот сообщение в блоге от команды Windows об этом, и https://github.com/dotnet/aspnetcore/pull/24120 содержит некоторые последующие работы по раскрытию вещей в ASP.NET Core.

Пройдет еще некоторое время, прежде чем все это приземлится, но приятно иметь возможность сообщить, что мы, по крайней мере, добились прогресса.

Спасибо за продолжение, очень полезно и ценно!!

В среду, 22 июля 2020 г., в 11:17 Кевин Пилч, [email protected]
написал:

Я просто хотел сообщить, что мы работаем с командой Windows над
начните включать эти сценарии. Вот сообщение в блоге
https://aka.ms/grpcblogpost от команды Windows об этом и #24120
https://github.com/dotnet/aspnetcore/pull/24120 содержит некоторые из
последующая работа по раскрытию вещей в ASP.NET Core.

Пройдет еще некоторое время, прежде чем все эти земли появятся, но приятно иметь возможность
чтобы сообщить, что мы делаем успехи по крайней мере.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-662547810 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AAUKMASPCV3UE47OJZ6TIMDR44GKTANCNFSM4HDHMSDA
.

Я просто хотел сообщить, что мы работаем с командой Windows, чтобы начать использовать эти сценарии. Вот сообщение в блоге от команды Windows об этом, и # 24120 имеет некоторые последующие работы по раскрытию вещей в ASP.NET Core.

Пройдет еще некоторое время, прежде чем все это приземлится, но приятно иметь возможность сообщить, что мы, по крайней мере, добились прогресса.

Обратите внимание, что это уже было интегрировано в сервер AspNetCore HttpSys в предварительных версиях 5.0. Пожалуйста, попробуйте. Если мы сможем определить какие-либо проблемы на этом уровне сейчас, то у нас будет меньше проблем, когда мы добавим слой IIS поверх этого.

Означает ли это, что я могу использовать полный gRPC в IIS, если я использую предварительную версию ASP.NET Core для .NET 5?

Еще нет. Здесь куча разных частей:

1. Модуль Http.sys в Windows
2. Поддержка ASP.NET Core для этого в HttpSysServer
3. Поддержка IIS для этого в Windows
4. Поддержка ASP.NET Core для этого в IIS
5. Поддержка этого в обратном прокси-сервере, который использует служба приложений Azure.
6. Служба приложений Azure развертывает сборку Windows с версиями 1 и 3.
7. Служба приложений Azure развертывает сборку обратного прокси-сервера из 5
8. Служба приложений Azure развертывает сборку ASP.NET Core с версиями 2 и 4.

@Tratcher говорил, что 1 и 2 доступны в предварительных версиях .NET 5. Мы работаем над 3 и 4 прямо сейчас, но попытка 1 и 2 поможет нам узнать, будет ли это работать, поскольку Http. sys является основой поддержки IIS.

Надо было сказать, что 1 доступен в предварительных версиях Windows, а 2 — в предварительных версиях .NET 5.

Предварительная версия Windows Insider доступна с обновленным http.sys
https://techcommunity.microsoft.com/t5/networking-blog/windows-server-insiders-getting-grpc-support-in-http-sys/ba-p/1534273

Есть идеи, будет ли это доступно в виде обновления Windows для Windows Server 2016/2019?

И поддержка IIS теперь есть в последних сборках Windows Insider, анонсированных здесь .

Мы изучаем возможность переноса этих изменений в сервисную сборку, но это пока висит в воздухе. На данный момент единственный план записи состоит в том, что они будут в будущих релизах.