Хранение параметров конфигурации в Azure Service Fabric и приложениях MVC

Я достиг точки, когда мне нужно развернуть свой кластер Service Fabric в Azure :) Помимо служб с отслеживанием состояния/без сохранения состояния, у меня есть 2 приложения MVC. В настоящее время у меня есть несколько настроек в файлах web.config (в основном строки подключения).

Я планирую настроить непрерывную сборку/развертывание с помощью Visual Studio Online, но пока не стал этого делать.

Где рекомендуется хранить параметры конфигурации. Мне понадобятся настройки для 3 разных сред (dev/test/prod).

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

Какие-либо официальные документы или лучшие практики по этому поводу, о которых я должен знать?


comment
stackoverflow.com/questions/33928204/ Я сохраняю свои значения конфигурации, используя метод, аналогичный этому, а затем использую замену токена в VSTS перед публикацией. Может быть лучший способ, поэтому я не публикую это как ответ!   -  person Mardoxx    schedule 13.06.2017
comment
Спасибо. Я думаю, что это единственный способ избежать производственного пароля как части исходного кода, что является большой ошибкой.   -  person Tony    schedule 14.06.2017
comment
После некоторого размышления я пришел к выводу, что лучше хранить значения в лазурном хранилище ключей. Это даст мне лучшие возможности для сценариев/развертывания/тестирования по сравнению с сохранением значений в определении сборки.   -  person Tony    schedule 12.07.2017


Ответы (1)


Вы можете использовать профили депубликации и параметры приложения проекта Service Fabric для хранения настроек для каждой среды.

В моем случае у меня есть среда разработки, гомолог и производственная среда с разными строками подключения к базе данных, поэтому я создал профили публикации с именами Cloud.Homolog.xml, Cloud.Production.xml, а для среды разработки я все еще использую Local.5Node. XML.

Затем, когда я хочу развернуть в некоторых из этих сред, я выбираю правильный профиль публикации.

Вот документация по управлению несколькими средами:

Ссылка

person Renan Fagundes    schedule 13.06.2017
comment
Я не доволен этим решением, так как производственный пароль будет проверен в системе управления версиями, и это именно то, чего я хочу избежать. Спасибо за ссылку кстати. Он действительно содержит много полезной полной информации. - person Tony; 14.06.2017
comment
Это решение, которое я использую в сочетании с сохранением настроек приложения в хранилище Azure. Таким образом, эта информация остается конфиденциальной, потому что она не будет проверена в системе управления версиями, поскольку код будет содержать только ссылки на ключи вместо значений. docs.microsoft.com/en- мы/azure/service-fabric/ - person Tony; 12.07.2017
comment
Хранилище ключей тоже очень интересно, если вы обнаружите, как хранить пароли в хранилище ключей и сочетать их с этим, пожалуйста, поделитесь своим решением, потому что я уже пытался сохранить в хранилище ключей, но я не обнаружил, как получить доступ к хранилищу ключей и восстановить это значение. - person Renan Fagundes; 12.07.2017