Как стать автором
Обновить

Комментарии 23

Проблема новой конфигурации в том что микрософт решила использовать JSON как основной формат для конфигурационных файлов.
JSON хорош для передачи данных но для конфигурации он плох.

1. Отсутствие комментариев. Комментарии очень полезны для «документации» конфига. Но они также очень полезны для временного «отключения» частей конфига когда что то настраиваешь или экспериментируешь.

2. Тот факт что виндовые пути к файлам требуют двойной бекслеш. (например С:\\tmp\\server\\file1.txt) Совершенно непонятно почему микрософт считает это приемлемым для конфигов.

Не понятно какой формат нужно использовать. XML — всем надоел и его ненавидят (по не совсем понятным причинам). Возможно YAML но он тоже наверное не идеален?
Но JSON явно не подходит для конфигов да и придуман он был совсем не для этого.
Проблема новой конфигурации в том что микрософт решила использовать JSON как основной формат для конфигурационных файлов.

Это как раз не проблема "новой конфигурации", потому что новая конфигурация позволяет легко и просто заменить этот JSON на что угодно еще, например:



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

С:\\tmp\\server\\file1.txt

Попробуйте С:/tmp/server/file1.txt
как правило этот вариант работает и на винде
Но ведь не обязательно же использовать стандартные решения? В своих проектах я использую давно написанный велосипед, где в .ini можно писать так

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 можно спокойно закомментировать ненужное обычным //
Может я чего-то не понимаю, но ведь в JSON можно спокойно закомментировать ненужное обычным //

Это не будет валидным JSON. Некоторые парсеры это понимают, а некоторые — нет.

1) раньше были переопределения в папке где то в programfile/dotnet и еще уровень в /system32 и еще уровень «конфигурация компьютера» (например там лежит Machine key который использовался для шифрования куки в asp.net ) что с этим сейчас?
2) отличная статья охота такую про логирование, то там какой то ад.
что с этим сейчас?

По умолчанию — ничего нет (кроме, возможно, кусков hosting configuration, но это вам не надо), но вы можете легко добавить свой собственный слой, лежащий где угодно.


про логирование, то там какой то ад.

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

А как в продакшене лучще/надежнее хранить секреты, если нет желания привязываться к платным хранилищам типа KeyVault?
В этом вопросе идет большая зависимость от доступной вам инфраструктуры. Если у вас Docker в Swarm, то существует готовое решение в виде Secrets. Если же у вас один сервер и\или один экземпляр приложения, то здесь применим другой набор вариантов. Некоторые хранилища предоставляют бесплатные версии, как например: Vault, Consul. Apache ZooKeeper же и вовсе бесплатный.
Спасибо за советы. Docker'a нет.
Я правильно понимаю, что в системе конфигурации .NET Core из коробки нет production-ready-хранилища секретов, которое не использует внешние сервисы? Т.е. либо user-secrets, предназначенный только для разработки, либо внешний сервис (либо писать что-то свое, но это так себе вариант). Просто не понятно, как можно доверить чувствительные данные какому-то стороннему сервису, у сотрудников которого «конечно нет доступа к этим данным»…
Если Вы имеете в виду готовый внешний сервис хранилища, то его нет.
Я правильно понимаю, что в системе конфигурации .NET Core из коробки нет production-ready-хранилища секретов, которое не использует внешние сервисы?

А что такое в вашем понимании "хранилище секретов"?

Я имею ввиду некий зашифрованный контейнер, доступ к которому осуществляется по ключу — по сути то же самое, что и облачные сервисы типа KeyVault, только чтобы его можно было развернуть локально (например, на отдельной машине).
Я имею ввиду некий зашифрованный контейнер, доступ к которому осуществляется по ключу — по сути то же самое, что и облачные сервисы типа KeyVault, только чтобы его можно было развернуть локально (например, на отдельной машине).

По вашему описанию — это сервис там, где вы хостите ваше приложение, какое отношение он имеет к .NET Core? .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.

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