Комментарии 23
JSON хорош для передачи данных но для конфигурации он плох.
1. Отсутствие комментариев. Комментарии очень полезны для «документации» конфига. Но они также очень полезны для временного «отключения» частей конфига когда что то настраиваешь или экспериментируешь.
2. Тот факт что виндовые пути к файлам требуют двойной бекслеш. (например С:\\tmp\\server\\file1.txt) Совершенно непонятно почему микрософт считает это приемлемым для конфигов.
Не понятно какой формат нужно использовать. XML — всем надоел и его ненавидят (по не совсем понятным причинам). Возможно YAML но он тоже наверное не идеален?
Но JSON явно не подходит для конфигов да и придуман он был совсем не для этого.
Проблема новой конфигурации в том что микрософт решила использовать JSON как основной формат для конфигурационных файлов.
Это как раз не проблема "новой конфигурации", потому что новая конфигурация позволяет легко и просто заменить этот JSON на что угодно еще, например:
Вот в старой модели провернуть такое было бы очень непросто. А в этой, как видите, тривиально.
С:\\tmp\\server\\file1.txt
Попробуйте С:/tmp/server/file1.txt
как правило этот вариант работает и на винде
par = 0
[SECTION]
par = 1
[SECTION/LEAF]
par = 2а в коде писать
var par = ini["section/leaf/par", defaultvalue]где строка из .ini будет автоматически приводится к типу defaultvalue. А если значение «section/leaf/par» не найдётся, он попробует поискать его уровнем выше — в «section/par» и так далее.
1. Отсутствие комментариев. Комментарии очень полезны для «документации» конфига. Но они также очень полезны для временного «отключения» частей конфига когда что то настраиваешь или экспериментируешь.
Может я чего-то не понимаю, но ведь в JSON можно спокойно закомментировать ненужное обычным //
2) отличная статья охота такую про логирование, то там какой то ад.
что с этим сейчас?
По умолчанию — ничего нет (кроме, возможно, кусков hosting configuration, но это вам не надо), но вы можете легко добавить свой собственный слой, лежащий где угодно.
про логирование, то там какой то ад.
Ну не знаю, там все более-менее прозрачно со стороны потребителя. Проблемы там, если вы хотите свой хитрый расширенный провайдер написать, это да.
Я правильно понимаю, что в системе конфигурации .NET Core из коробки нет production-ready-хранилища секретов, которое не использует внешние сервисы? Т.е. либо user-secrets, предназначенный только для разработки, либо внешний сервис (либо писать что-то свое, но это так себе вариант). Просто не понятно, как можно доверить чувствительные данные какому-то стороннему сервису, у сотрудников которого «конечно нет доступа к этим данным»…
Я правильно понимаю, что в системе конфигурации .NET Core из коробки нет production-ready-хранилища секретов, которое не использует внешние сервисы?
А что такое в вашем понимании "хранилище секретов"?
Я имею ввиду некий зашифрованный контейнер, доступ к которому осуществляется по ключу — по сути то же самое, что и облачные сервисы типа KeyVault, только чтобы его можно было развернуть локально (например, на отдельной машине).
По вашему описанию — это сервис там, где вы хостите ваше приложение, какое отношение он имеет к .NET Core? .NET Core может только предоставить поддержку такого сервиса, если он есть и распространен.
А так — вы вполне можете читать зашифрованные файлы, для этого поддержка есть.
какое отношение он имеет к .NET Core?Microsoft могла бы сделать такой сервис, т.е. дать выбор — либо использовать KeyVault либо этот сервис, либо писать что-то свое или использовать сторонние сервисы.
Хочется понять, есть ли бесплатный сервис-хранилище ключей с возможностью локального развертывания и который можно использовать в .NET Core-приложении.
Вам же вроде выше предложили Vault и ZooKeeper. Для обоих из них есть плагины для Microsoft.Extensions.Configuration.
Microsoft могла бы сделать такой сервис
Но зачем им это?
Понимаете, в разумной части продакшн-окружений, на которые .NET Core ориентируется, такая функциональность уже есть — что в докере, что в Azure, что в AWS. Зачем им делать что-то еще, что будет востребовано очень узким кругом людей, и при этом не принесет им прямой прибыли?
Вот у меня вопрос какой. Для новых проектов всё шикарно. Что делать со старыми, которым надо поддерживать старую конфигурацию и эти самые сгенерированные классы. Можно ли их как-то заполнять используя Options или есть подход по лучше?
Можно ли их как-то заполнять используя Options или есть подход по лучше?
Можно. Инфраструктура Microsoft.Extensions.Options вообще позволяет конфигурировать практически что угодно. Если там есть (публичные) свойства с (публичными) сеттерами, то все, что вам нужно — это чтобы в IConfiguration, из котоорого вы делаете биндинг, были ключи с такими же названиями. Переложить значения из appSettings в IConfiguration — дело пары строчек кода с использованием in-memory-провайдера.
У вас уже есть в статье вариант как хранить секреты на dev машине.
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);Можно добавить в gitignore файл appsettings.Development.json и в нем хранить настройки и секреты
Лучше тогда $appsettings.{Environment.MachineName}.json и его в .gitignore.
appsettings.Development.json всё-таки шарить удобно внутри команды.
В таком случае в .gitignore будет n уникальных записей, по одному на каждый компьютер на котором ведётся разработка, и эти файлы там будут только копиться, потому что удалять будут забывать/забивать. Некоторые нерадивые иногда будут забывать добавлять свои уникальные файлы в .gitignore и коммитить их в репу.
Лучше использовать статичное имя, например appsettings.LocalDev.json и сразу прописать его в .gitignore.
Эволюция конфигурации .NET