Таким образом, мы находимся в процессе преобразования нашего стека продуктов следующего поколения для работы в Azure (состоит из углового клиентского уровня, веб-API-слоя, набора функций Azure для внутренней обработки и базы данных Azure sql, а также нескольких других Azure PAAS такие службы, как Stream Analytics, Event Grid, таблицы Azure, BLOB-объекты и т. д.).
Первым шагом была полная поддержка DI в ASP.NET Core. Следующим шагом было перенести нашу модель конфигурации с использования appsettings.json на использование хранилища ключей Azure для любых параметров, которые содержат секреты или должны использоваться другими службами Azure, которые могут совместно использовать пакеты среднего уровня и нуждаются в строках подключения, секретах и другой общей конфигурации. (т.е. один источник конфигурации).
Стратегия заключалась в использовании поставщика конфигурации хранилища ключей Azure с идентификаторами управляемых служб. Мы подумали, что сможем «поднять и переместить» большинство наших возможных разделов конфигурации в appsettings.json, которые будут секретами в хранилище ключей Azure, введя их по имени раздела конфигурации в Key Vault, где секретным значением является JSON, скопированный и вставленный из appsettings.json в секретное значение в хранилище ключей без каких-либо дополнительных изменений кода.
Мы надеялись, что при этом мы сможем использовать разделы, поступающие из хранилища ключей, точно так же, как мы это делали, когда они хранились в appsettings.json. Наши объекты конфигурации - это не просто пары ключ: значение 1: 1, а фактически строго типизированные сущности. С appsettings.json это работает чисто, используя IConfiguration.Bind вызовы или в случае строк подключения IConfiguration.GetConnectionString вызовы. Аналогично с services.Configure<T>(Configuration.GetSection("SectionName")) звонки для регистрации разделов конфигурации для поддержки IOptions.
После прохождения этого процесса мы обнаружили, что при попытке использовать секции конфигурации из Key Vault, содержащие JSON, мы не можем использовать методы IConfiguration.Bind и IConfiguration.GetConnectionString как есть, потому что они, похоже, не распознают приходящее значение вернуться в JSON и, следовательно, не связываться, если мы не сделаем что-то вроде JsonConvert.DeserializeObject<T>(Configuration.GetSection("SectionName").Value)
В результате наша services.Configure<T>(Configuration.GetSection("SectionName")); выглядит примерно так ...
services.Configure<T>(options =>
{
var config = JsonConvert.DeserializeObject<T>(Configuration.GetSection("ConfigTypeName").Value);
options.Property = config.Property;
});
Это работает, но похоже на запах кода ... Теперь в любое время нам нужно расширить тип ConfigType, мы также должны убедиться, что мы обновляем код в Startup.cs, чтобы гарантировать, что вызовы services.Configure<T> копируют все свойства через options => переопределить. Это также означает, что нашему стартовому коду необходимо знать, поступает ли свойство конфигурации из хранилища ключей или appsettings.json
Вопрос в том, делаем ли мы это неправильно? Есть ли другой способ, которым мы должны подходить к этому? Кажется очевидным, что поставщик конфигурации хранилища ключей Azure теоретически должен вести себя как любой другой поставщик, например, поставщик файлов для appsettings.json. Рад узнать, что нам не хватает чего-то очевидного здесь, и любопытно узнать, почему это не работает так, как будто «похоже, что должно».