Рекомендации по использованию службы "Конфигурация приложений Azure"

  • Статья

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

Группирование ключей

В службе "Конфигурация приложений" доступны два варианта упорядочения ключей:

  • Префиксы ключей
  • Наклейки

Для группирования ключей можно использовать один или оба варианта.

Префиксы ключей — это начальные части ключей. Набор ключей можно логически сгруппировать, используя в их именах один и тот же префикс. Префиксы могут содержать несколько компонентов с разделителем, например / (аналогично URL-путям), что позволяет сформировать пространство имен. Такие иерархии удобны при хранении ключей для многих приложений и микрослужб в одном хранилище службы «Конфигурация приложений».

Важно помнить, что для получения значений параметров код приложения ссылается именно на соответствующие ключи. Ключи не должны изменяться, иначе вам придется изменять код каждый раз, когда это происходит.

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

Комбинации "ключ-значение"

Служба "Конфигурация приложений" рассматривает все хранящиеся в ней ключи, как независимые сущности. Она не пытается определить связь между ключами или задать наследование значений ключей исходя из их иерархии. Однако можно агрегировать несколько наборов ключей, используя метки в сочетании с правильным стеком конфигураций в коде приложения.

Давайте рассмотрим пример. Предположим, у вас есть параметр с именем Asset1, значение которого может меняться в зависимости от среды разработки. Создайте ключ с именем Asset1 с пустой меткой и меткой Development. В первой метке вы помещаете значение по умолчанию для Asset1, а во второй — заданное значение для Development.

В коде сначала извлекаются значения ключей без меток, а затем значения для того же набора ключей извлекаются во второй раз с меткой Development. При извлечении значений во второй раз предыдущие значения ключей перезаписываются. Система конфигурации .NET Core позволяет "поместить в стек" несколько наборов данных конфигурации, расположив их друг над другом. Если ключ существует более чем в одном наборе, используется последний набор, содержащий его. Благодаря современной платформе программирования .NET Core вы получаете возможность создавать такие стеки бесплатно, если для доступа к службе "Конфигурация приложений" используется собственный поставщик конфигураций. В этом фрагменте кода показано, как можно реализовать создание такого стека в приложении .NET Core:

// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(configuration["connection_string"])
           .Select(KeyFilter.Any, LabelFilter.Null)
           .Select(KeyFilter.Any, "Development");
});

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

Ссылки на внешние данные

Служба «Конфигурация приложений» предназначена для хранения всех данных конфигурации, которые обычно сохраняются в файлах конфигурации или переменных среды. Однако некоторые типы данных лучше подходят для проживания в других источниках. Например, храните секреты в Key Vault, файлы в служба хранилища Azure, сведения о членстве в группах Microsoft Entra или списки клиентов в базе данных.

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

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

Начальная загрузка службы "Конфигурация приложений"

Для доступа к хранилищу службы "Конфигурация приложений" можно использовать строку подключения, которая доступна на портале Azure. Строки подключения содержат учетные данные, поэтому они относятся к секретам. Эти секреты должны храниться в Azure Key Vault, и код должен пройти проверку подлинности в Key Vault, чтобы получить их.

Лучше использовать функцию управляемых удостоверений в идентификаторе Microsoft Entra. При использовании управляемых удостоверений для получения начального доступа к хранилищу конфигурации приложений требуется только URL-адрес конечной точки службы "Конфигурация приложений". URL-адрес можно внедрить в код приложения, например в файл appsettings.json. Подробные сведения см. в статье Использование управляемых удостоверений для получения доступа к службе "Конфигурация приложений".

Доступ из Службы приложений или Функций Azure к Конфигурации приложений

Используйте поставщик Конфигурации приложений или библиотеки SDK для доступа из Конфигурации приложений непосредственно к приложению. Такой подход обеспечивает полный доступ к функциям Конфигурации приложений, в том числе к динамической конфигурации и управлению функциями. Приложение, работающее в Службе приложений или Функциях Azure, может получить доступ к хранилищу Конфигурации приложений с помощью любого из следующих методов:

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

Сокращение количества запросов к службе "Конфигурация приложений"

Избыточные запросы к службе "Конфигурация приложений" могут привести к превышению расходов или регулированию. Чтобы уменьшить число запросов. выполните следующие действия:

  • Увеличьте время ожидания обновления, особенно если значения конфигурации изменяются нечасто. Укажите новое время ожидания обновления с помощью метода SetCacheExpiration.

  • Просматривайте один ключ Sentinel, а не отдельные ключи. Обновляйте всю конфигурацию, только если изменился ключ Sentinel. См. пример в руководстве Использование динамической конфигурации в приложении ASP.NET Core.

  • Используйте службу "Сетка событий Azure" для получения уведомлений при изменении конфигурации. Это позволит отказаться от регулярных опросов о наличии изменений. Дополнительные сведения см. в разделе Использование Сетки событий для уведомлений об изменении данных в службе «Конфигурации приложений».

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

Импорт данных конфигурации в службу "Конфигурация приложений"

В службе "Конфигурация приложений" можно выполнить массовый импорт параметров конфигурации из текущих файлов конфигурации с помощью портала Azure или Azure CLI. Эти же варианты доступны для экспорта пар «ключ-значение» из службы «Конфигурация приложений», например, между связанными хранилищами. Если вы хотите настроить постоянную синхронизацию с репозиторием в GitHub или Azure DevOps, воспользуйтесь нашим действием GitHub или Задание передачи конвейера Azure. Это позволит вам по-прежнему применять существующие методы управления исходным кодом, одновременно используя преимущества, которые дает служба «Конфигурация приложений».

Развертывание в нескольких регионах в службе "Конфигурация приложений"

Если приложение развернуто в нескольких регионах, рекомендуется включить гео реплика для хранилища Конфигурация приложений. Вы можете разрешить приложению в первую очередь подключаться к реплика, соответствующей региону, в котором развертываются экземпляры приложения, и разрешить им выполнять отработку отказа в реплика в других регионах. Эта настройка сводит к минимуму задержку между приложением и Конфигурация приложений, распределяет нагрузку, так как каждая реплика имеет отдельные квоты регулирования и повышает устойчивость приложения к временным и региональным сбоям. Дополнительные сведения см. в разделе "Устойчивость и аварийное восстановление ".

Клиентские приложения в службе "Конфигурация приложений"

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

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

Мультитенантные приложения в службе "Конфигурация приложений"

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

Настройка в качестве кода

Конфигурация как код — это практическая методика управления файлами конфигурации в системе управления версиями, например репозитории Git. Она предоставляет такие преимущества, как отслеживаемость и процесс утверждения для всех изменений конфигурации. Если вы принимаете конфигурацию как код, Конфигурация приложений имеет средства для управления данными конфигурации в файлах и их развертывания в процессе сборки, выпуска или CI/CD. Таким образом ваши приложения смогут получить доступ к последним данным из ваших хранилищ службы «Конфигурация приложений».

Эта модель позволяет включить этапы проверки и тестирования перед фиксацией данных в службу «Конфигурация приложений». Если вы используете несколько хранилищ службы «Конфигурация приложений», можно передавать в них данные конфигурации поэтапно или все сразу.

Следующие шаги