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

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

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

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

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

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

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

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

Метки позволяют создавать варианты ключа, например различные версии или параметры среды. Назначая метки, можно поддерживать несколько значений для одного и того же ключа. Затем приложение может получить различные наборы значений ключей, указав соответствующую метку, что позволит вашим ключевым ссылкам в коде оставаться согласованными.

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

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

Рассмотрим пример, когда у вас есть параметр конфигурации с именем TestApp:MySetting, значение которого зависит от среды. Вы можете создать два ключа с одинаковым именем, но назначить разные метки — один без метки (по умолчанию) и другой с меткой Разработка. Незначимый ключ содержит значение по умолчанию, а помеченный ключ содержит значение для конкретной среды.

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

В следующем примере демонстрируется, как реализовать композицию «ключ-значение» в приложении .NET.

configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and compose with two different labels
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .Select(keyFilter: "TestApp:*", labelFilter: "Development");
});

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

Обновление конфигурации

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

Мониторинг всех выбранных ключей

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

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh when any selected key changes.
               refreshOptions.RegisterAll();
           });
});

const appConfig = await load(endpoint, credential, {
    selectors: [{ keyFilter: "TestApp:*" }],
    refreshOptions: {
        enabled: true
    }
});

apiVersion: azconfig.io/v1
kind: AzureAppConfigurationProvider
metadata:
  name: appconfigurationprovider-sample
spec:
  endpoint: <your-app-configuration-store-endpoint>
  target:
    configMapName: configmap-created-by-appconfig-provider
  configuration:
    selectors:
      - keyFilter: TestApp*
    refresh:
      enabled: true

Мониторинг сторожевого ключа

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

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh only if the `SentinelKey` changes.
               refreshOptions.Register("SentinelKey", refreshAll: true);
           });
});

const appConfig = await load(endpoint, credential, {
    selectors: [{ keyFilter: "TestApp:*" }],
    refreshOptions: {
        enabled: true,
        watchedSettings: [{ key: "SentinelKey" }]
    }
});

apiVersion: azconfig.io/v1
kind: AzureAppConfigurationProvider
metadata:
  name: appconfigurationprovider-sample
spec:
  endpoint: <your-app-configuration-store-endpoint>
  target:
    configMapName: configmap-created-by-appconfig-provider
  configuration:
    selectors:
      - keyFilter: TestApp*
    refresh:
      enabled: true
      monitoring:
        keyValues:
          - key: SentinelKey

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

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

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

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

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

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

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

Чтобы получить доступ к хранилищу конфигураций приложений Azure, можно пройти проверку подлинности с помощью строки подключения или идентификатора Microsoft Entra. Хотя строки подключения доступны на портале Azure, они содержат учетные данные и должны рассматриваться как секреты. Если вы выберете этот подход, сохраните строку подключения безопасно в Azure Key Vault и убедитесь, что приложение проходит проверку подлинности в Key Vault, чтобы получить его.

Более безопасный и рекомендуемый подход — использовать проверку подлинности Идентификатора Microsoft Entra. Если приложение размещено в Azure, например в службе Azure Kubernetes, службе приложений или Функциях Azure, можно использовать управляемые удостоверения, предоставляемые идентификатором Microsoft Entra. Управляемые удостоверения устраняют необходимость явного управления секретами. В этом методе приложению требуется только URL-адрес конечной точки конфигурации приложения, который можно безопасно внедрить в код приложения или файлы конфигурации.

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

Служба Azure Kubernetes доступ к Конфигурация приложений

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

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

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

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

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

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

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

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

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

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

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

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

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

• Используйте поставщик kubernetes Конфигурация приложений при выполнении нескольких рабочих нагрузок в кластере Kubernetes, каждый из которых извлекает данные из Конфигурация приложений по отдельности. Поставщик Kubernetes получает данные из Конфигурация приложений и делает его доступным как Kubernetes ConfigMaps и Секреты. Таким образом рабочие нагрузки могут получать доступ к данным через ConfigMaps и Секреты без необходимости извлекать данные из Конфигурация приложений отдельно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Для GitHub можно импортировать файлы конфигурации из репозитория GitHub в хранилище Конфигурация приложений с помощью GitHub Actions
• Для Azure DevOps можно включить Конфигурация приложений Azure Импорт, задачу конвейера Azure в конвейер сборки или выпуска для синхронизации данных.
• Для других пользователей можно импортировать файлы конфигурации в конфигурацию приложений с помощью Azure CLI в рамках системы CI/CD. Дополнительные сведения см. в разделе az appconfig kv Import.

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

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

• Ключи и значения