#azure #asp.net-core #azure-devops #web-deployment
#azure #asp.net-core #azure-devops #веб-развертывание
Вопрос:
Я получил решения Visual Studio с несколькими проектами (функциональные приложения и веб-API) и уровнем данных, который является общим для всех проектов. Я настроил решение таким образом, чтобы все проекты использовали одну и ту же конфигурацию ( appsettings.json ) на основе этой статьи: https://andrewlock.net/sharing-appsettings-json-configuration-files-between-projects-in-asp-net-core/
Все проекты основаны на .net core.
Я настроил конвейер сборки и выпуска для среды разработки. Но мне нужна тестовая и производственная среда. Как мне преобразовать общую конфигурацию перед выпуском ее в тестовую и производственную среду?
Ответ №1:
Вы этого не делаете. Конфигурация работает не так в ASP.NET Ядро. Конфигурация переопределена, а не преобразована. Существует порядок операций применения различных источников конфигурации, который в основном соответствует порядку, в котором они зарегистрированы. По умолчанию используется JSON < JSON, зависящий от среды < Пользовательские секреты < Переменные среды < Аргументы командной строки.
Если вам нужно, чтобы конфигурация зависела от среды, вы будете полагаться на JSON-файлы для конкретной среды (для общей конфигурации) или переменные среды и / или что-то вроде Azure Key Vault (для секретов). Поскольку все это появляется позже при регистрации конфигурации, любое значение, которое вы там зададите, переопределит значения в вашем appsettings.json .
Для таких вещей, как JSON для конкретной среды, загружаемый параметр зависит от значения ASPNETCORE_ENVIRONMENT , которое может быть задано как переменная среды или передано в качестве аргумента командной строки --environment . В любом случае установленное значение соответствует {environment} части appsettings.{environment}.json . Другими словами, если вы установите среду как Production , то appsettings.Production.json она будет загружена в конфигурацию, если она присутствует. Переменные среды привязаны к самой среде, поэтому не зависят от какого-либо конкретного значения среды.
Комментарии:
1. Итак, мне нужно будет иметь наборы приложений для каждой среды в каждом из моих проектов? Я пытаюсь избежать необходимости дублировать наборы приложений.
2. Я не совсем уверен, что вы делаете, но при использовании общих настроек отдельными приложениями возникает вопрос о том, должны ли они вообще быть отдельными приложениями.
3. Все функциональные приложения являются отдельными проектами веб-api, все они полагаются на некоторые репозитории. Таким образом, приложения должны иметь строку подключения и т.д. После ее развертывания.
4. Смотрите, это прекрасный пример. Если всем приложениям требуется одна и та же строка подключения, значит, вы неправильно абстрагировали свою зависимость от данных и / или вы на самом деле не разделяете свой домен. Другими словами, у вас все еще есть монолитное приложение, просто разбитое на отдельные проекты.
5. Определенно существуют варианты использования для совместного использования конфигурации в нескольких доменах. Возможно, вашей системе захочется предоставить общую конфигурацию ведения журнала, строку подключения к SQL Server, объединительную плату Redis, служебную шину Azure и т.д. Это никоим образом не нарушает принципы проектирования. В Azure даже существуют целые решения, построенные на основе этой концепции, которые называются Azure App Configuration