Комментарии 14
Лайк за статью
Конфигурация - это хорошо, но причём тут ASP.NET (Core или не Core), совсем не понятно.
Жаль в .NET 6 не завезли возможности использования конфигурации в Multi-Tenant окружении.
А можно подробнее об этом почитать? Может есть ссылка на ишью гитхаба где это обсуждается?
Можете уточнить, что есть такого особенного в вашем мультитенанте, что в нём нельзя использовать стандартный IConfiguration?
В multi-tenant приложении нужна изоляция и разделение конфигурации (всей или отдельных слоев) для каждого tenant, а в совокупности с отсутствием контроля над временем жизни IOptions*<> (scope) в DI получается проще написать с нуля чем пытаться добавить Multitenancy в родную реализацию.
Не утверждаю, что это популярный сценарий, но факт остается фактом.
А можете рассказать случай, когда нужно применять multitenant конфигурацию? Я полагаю, что она нужна только для повышения безопасности приложения, правильно? Например, что бы в контроллере A была конфигурация Ca, а в контроллере B конфигурация Cb? Но почему в таком случае не разнести эти контроллеры в два приложения? В таком случае это будет и безопасно и гибко с точки зрения масштабируемости.
Multitenant прилежение это когда к одному приложению подключает несколько клиентов и каждый клиент имеет свой набор данных, пользователей, брендирование, конфигурацию и т.д.
В простейшем варианте под каждого tenant (под каждого клиента) разворачивали своё окружение и свой экземпляр приложения. Но, с переходам в облака становится актуальным вариант не физического разделения клинтов, а логическои изоляции. Таким образом экономят ресурсы и повышается эффективность горизонтального масштабирования.
При этом на уровне данных изоляция может осуществляться разделением баз данных или partitions в Azure CosmosDB. А код логики пишется общим, и с помощью DI и ещё одного LifetimeScope контроллируется время жизни объектов.
Например класс для отправки письма требует конфигурацию (на какой сервер отправлять) и само письмо, с его точки зрения неважно, что внутри письма, как получена конфигурация или к какому конкретно tenant она отностится. Поэтому если правильно реализовать IConfiguration<> (чтобы он учитывал контекст вызова - для какого tenant исполняется запрос) - сам класс отправки писем можно держать в Singleton Scope. А экземпляр конфигурацит каждого из Tenant в TenantScope (это такой SingletonScope Per Tenant).
Автор правильно именует ASP.NET Core, т.к. переименовывали только .Net Core, но не ASP.NET Core:
В 6-й версии переименований не было.
Например, знает ли он, что в шаблоне Generic Hoat (в котором используется IHostBuilder) конфигурация по-любому строится в два этапа: сначала — конфигурация построителя, она же — конфигурация размещения (хоста), а потом уже — конфигурация веб-приложения, причем на втором этапе конфигурация, созданная на первом этапе уже доступна — через свойство Configuration первого параметра (он имеет тип HostBuilderContext). Так что параметр конфигурации KeyVaultName можно было бы занести и в конфигурацию размещения (например, в соответствущую переменную окружения с префиксом ASPNETCORE_* — эти переменные читаются именно на стадии конфигурирования построителя.
А если знает — почему про это не пишет. Но раз это перевод — то вопросы, очевидно, останутся без ответа.
PS А Microsoft — в своем нынешнем репертуаре: вместо того, чтобы развивать существующие шаблоны — просто добавила новый.
Про Generic Host и его заместитель в .NET 6 будет во второй части.
В примере автор ссылается на рекомендуемую настройку конфигурации, указанную в документации Майкрософта https://docs.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-5.0#use-application-id-and-x509-certificate-for-non-azure-hosted-apps
Но у вас интересный вариант. А можете пример кода набросать для наглядности?
А можете пример кода набросать для наглядности?
Там и кода-то нет. Просто задаете снаружи программы переменную окружения ASPNETCORE_KeyVaultName со значением — именем хранилища, а дальше выкидываете построение промежуточной конфигурации и чиатете значение параметра KeyVaultName из конфигурации построителя (все это — в Generic Host, за Web Host — не скажу):
if (context.HostingEnvironment.IsProduction())
{
// чтение значения из конфигурации
string keyVaultName = context.Configuration["KeyVaultName"];
А если нужно все-таки хранить имя хранилища в appsettings.json, то, чтобы два раза не читать этот файл, можно построить конфигурацию из него одного, прочитать имя хранилища, а потом добавить уже построенную конфигурацию в список источников конфигурации с помощью configuration.AddConfiguration (как-то так, код писать лень).
А что до документации MS — там написан самый простой и всегда работающий вариант, но не оптимальный для конкретных условий.
PS Я тут, вообще-то, когда-то пару статей писал, про то, как происходит инициализация для Generic Host, возможно они для понимания полезны будут (хотя они и сами для понимания сложны).
вощем, бардак прямо в с фундамента
Исследуем .NET 6. Часть 1