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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

// 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 Kubernetes доступ к Конфигурация приложений

Следующие параметры доступны для рабочих нагрузок, размещенных в Служба Azure Kubernetes (AKS), для доступа к Конфигурация приложений Azure. Эти параметры также применяются к Kubernetes в целом.

  • Добавьте Конфигурация приложений Azure поставщика Kubernetes в кластер AKS. Поставщик Kubernetes выполняется в качестве модуля pod в кластере. Он может создавать конфигурацию Карты и секреты из ключевых значений и ссылок Key Vault в хранилище Конфигурация приложений. ConfigMap и Secret используются как переменные среды или подключенные файлы без каких-либо изменений в коде приложения. Если у вас несколько приложений, работающих в одном кластере AKS, они могут получить доступ к созданной конфигурации Карты и секретам, устраняя необходимость Конфигурация приложений отдельных запросов. Поставщик Kubernetes также поддерживает динамические обновления конфигурации. Это рекомендуемый вариант, если это возможно для вас.

  • Обновите приложение, чтобы использовать библиотеки поставщиков Конфигурация приложений Azure. Библиотеки поставщиков доступны во многих платформах и языках, таких как ASP.NET, .NET, Java Spring, JavaScript/Node.js и Python. Такой подход обеспечивает полный доступ к функциям Конфигурации приложений, в том числе к динамической конфигурации и управлению функциями. У вас есть детальный контроль над тем, какие данные нужно загружать и из которых Конфигурация приложений хранить для каждого приложения.

  • Интеграция с развертыванием Kubernetes с помощью Helm. Если вы не хотите обновлять приложение или добавлять новый модуль pod в кластер AKS, вы можете добавлять данные из Конфигурация приложений в кластер Kubernetes с помощью Helm через развертывание. Этот подход позволяет приложению продолжать доступ к конфигурации из переменных Kubernetes и секретов. Обновление Helm можно запускать всякий раз, когда вы хотите, чтобы приложение включало новые изменения конфигурации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание приложений с высокой устойчивостью

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

  • Подготовка в регионах с поддержкой зоны доступности Azure. Зоны доступности позволяют приложениям быть устойчивыми к сбоям центра обработки данных. Конфигурация приложений предлагает избыточность зон для всех клиентов без дополнительных расходов. Рекомендуется создать хранилище Конфигурация приложений в регионах с поддержкой зон доступности. Вы можете найти список регионов, где Конфигурация приложений включила поддержку зоны доступности.
  • Включите гео реплика tion и разрешите приложению отработку отказа между реплика. Эта настройка предоставляет модель для обеспечения масштабируемости и повышенной устойчивости к временным сбоям и региональным сбоям. Дополнительные сведения см. в разделе "Устойчивость и аварийное восстановление ".
  • Развертывание конфигурации с помощью методов безопасного развертывания. Неправильные или случайные изменения конфигурации могут часто вызывать простой приложения. Не следует вносить изменения конфигурации, влияющие непосредственно на рабочую среду, например, портал Azure всякий раз, когда это возможно. В методах безопасного развертывания (SDP) используется модель развертывания прогрессивного воздействия, чтобы свести к минимуму потенциальный радиус взрыва проблем, вызванных развертыванием. При внедрении SDP можно создать и проверить моментальный снимок конфигурации перед развертыванием в рабочей среде. Во время развертывания можно обновить экземпляры приложения, чтобы постепенно получить новый моментальный снимок. Если обнаружены проблемы, можно откатить изменение, повторно разверните последний известный моментальный снимок (LKG). Моментальный снимок неизменяем, гарантирующий согласованность во всех развертываниях. Моментальные снимки можно использовать вместе с динамической конфигурацией. Используйте моментальный снимок для базовой конфигурации и динамической конфигурации для переопределения конфигурации аварийного реагирования и флагов компонентов.
  • Включите конфигурацию в приложение. Если вы хотите убедиться, что приложение всегда имеет доступ к копии конфигурации или если вы предпочитаете избежать зависимости среды выполнения от Конфигурация приложений в целом, вы можете извлечь конфигурацию из Конфигурация приложений во время сборки или выпуска и включить ее в приложение. Чтобы узнать больше, проверка примеры интеграции Конфигурация приложений с конвейером CI/CD или развертыванием Kubernetes.
  • Используйте поставщики Конфигурация приложений. Приложения играют важную роль в достижении высокой устойчивости, так как они могут учитывать проблемы, возникающие во время выполнения, такие как сетевые проблемы, и реагировать на сбои быстрее. Поставщики Конфигурация приложений предлагают ряд встроенных функций устойчивости, включая автоматическое обнаружение реплика, реплика отработку отказа, повторные попытки запуска с настраиваемыми тайм-аутами, кэшированием конфигурации и адаптивными стратегиями для надежного обновления конфигурации. Настоятельно рекомендуется использовать поставщики Конфигурация приложений, чтобы воспользоваться этими функциями. Если это не вариант, следует рассмотреть возможность реализации аналогичных функций в пользовательском решении, чтобы обеспечить высокий уровень устойчивости.

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

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

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

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

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

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

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

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

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