Конфигурация приложений Azure. Вопросы и ответы

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

Конфигурация приложений поддерживает:

• Иерархические пространства имен
• Добавление меток
• расширенные запросы;
• Пакетное извлечение
• специализированные операции управления;
• пользовательский интерфейс управления функциями.

Конфигурация приложений дополняет Key Vault, и в большинстве развертываний приложений следует использовать эти две службы параллельно.

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

Вы можете создать Конфигурация приложений значения ключей, ссылающиеся на секреты, хранящиеся в Key Vault. Дополнительные сведения см. в руководстве по использованию ссылок Key Vault в приложении ASP.NET Core.

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

Служба приложений Azure позволяет определять параметры приложений для каждого экземпляра Службы приложений. Эти параметры передаются в код приложения в виде переменных среды. При желании вы можете связать любой параметр с конкретным слотом развертывания. Дополнительные сведения см. в разделе Настройка параметров приложения.

В свою очередь, Конфигурация приложений Azure позволяет определять параметры, которые могут совместно использоваться в нескольких приложениях. Это могут быть приложения, работающие не только в Службе приложений, но и на других платформах. Код приложения обращается к этим параметрам через поставщики конфигураций для .NET и Java, через пакет SDK для Azure или напрямую через REST API.

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

Для каждой пары "ключ-значение", включая такие атрибуты, как метка, тип содержимого, теги и другие метаданные, действует ограничение в 10 КБ.

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

Дополнительные сведения см. в статье Подписка Azure и ограничения службы.

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

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

Рекомендации на эту тему см. здесь.

Есть две ценовые категории:

• Уровень служб "Бесплатный"
• Уровень служб "Стандартный"

Если вы создали хранилище до появления уровня категории "Стандартный", оно будет автоматически перемещено на уровень "Бесплатный" после выхода общедоступной версии. Вы можете обновить его до уровня "Стандартный" или оставить на уровне "Бесплатный".

Переход с уровня "Стандартный" на уровень "Бесплатный" не поддерживается. Но вы можете создать новое хранилище на уровне "Бесплатный" и импортировать нужные данные конфигурации в это хранилище.

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

Ниже приведены рекомендации по выбору уровня.

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

• служба хранилища на ресурс. На уровне "Бесплатный" каждое хранилище конфигурации ограничено 10 МБ регулярного хранилища и 10 МБ хранилища моментальных снимков. На стандартном уровне каждый хранилище конфигурации может использовать до 1 ГБ регулярного хранилища и дополнительное 1 ГБ хранилища моментальных снимков.

• Журнал редакций. Конфигурация приложений хранит журнал всех изменений, которые вносятся в ключи. На уровне "Бесплатный" этот журнал хранится в течение семи дней. На уровне "Стандартный" он хранится в течение 30 дней.

• Квоты запросов. На уровне "Бесплатный" хранилища обслуживают не более 1000 запросов в день. Когда для хранилища достигается ограничение в 1000 запросов, в ответ на любые запросы вплоть до наступления полуночи в формате UTC оно возвращает код состояния HTTP 429.

  На уровне "Стандартный" хранилища обслуживают до 30 000 запросов в час. После исчерпания квоты до окончания часа запросы могут возвращать код состояния HTTP 429, указывающий на слишком большое количество запросов. При отправке большего числа запросов, превышающих квоту, эти запросы в большем количестве случаев могут возвращать код состояния 429.

• Соглашение об уровне обслуживания: уровень "Стандартный" имеет соглашение об уровне обслуживания 99,9 % и доступность 99,95 % с поддержкой гео-реплика tion. На уровне "Бесплатный" соглашение об уровне обслуживания не предусмотрено.

• Функции. Оба уровня включают функции, включая шифрование с помощью ключей, управляемых Корпорацией Майкрософт, проверку подлинности с помощью ключа доступа или идентификатора Microsoft Entra, управления доступом на основе ролей Azure (RBAC), управляемого удостоверения, тегов служб и избыточности зоны доступности. Уровень "Стандартный" предоставляет дополнительные функциональные возможности, включая поддержку Приватный канал, шифрование с помощью ключей, управляемых клиентом, защиту обратимого удаления и возможность гео-реплика tion.

• Стоимость. Для хранилищ уровня "Стандартный" взимается плата за каждый день использования. В ежемесячную плату входит только 200 000 запросов в день. За запросы сверх этого ежедневного ограничения взимается дополнительная плата. За использование хранилища на уровне "Бесплатный" плата не взимается.

Вы можете в любой момент перейти с уровня "Бесплатный" на уровень "Стандартный".

Переход с уровня "Стандартный" на уровень "Бесплатный" не поддерживается. Но вы можете создать новое хранилище на уровне "Бесплатный" и импортировать нужные данные конфигурации в это хранилище.

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

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

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

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

Хранилища конфигурации на уровне "Бесплатный" обслуживают не более 1000 запросов в день. Для хранилищ конфигурации на уровне "Стандартный" может временно применяться регулирование, если количество поступающих запросов превышает 30 000 в час.

Когда хранилище достигает ограничения уровня "Стандартный", оно может возвращать код состояния HTTP 429 для некоторых запросов, отправленных до истечения часа. Заголовок retry-after-ms в ответе содержит рекомендуемое время ожидания (в миллисекундах) до повторного выполнения запроса.

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

Вы будете получать ответы с кодом состояния HTTP 429 в следующих обстоятельствах:

• превышение ежедневного ограничения на запросы в хранилище уровня "Бесплатный";
• Превышение лимита на количество запросов в час в хранилище уровня "Стандартный".
• Кратковременное регулирование количества запросов в связи с большим количеством запросов†.
• Краткое регулирование из-за чрезмерного использования пропускной способности†.
• Попытка создать или изменить ключ при превышении квоты на размер хранилища.

Конкретная причина невыполнения запроса будет указана в тексте ответа с кодом 429.

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

Давайте рассмотрим пример и предположим, что у вас есть приложение с 1000 параметрами конфигурации. Приложение загружает все эти параметры из Конфигурация приложений при запуске. После этого он проверка для ключа sentinel для изменения конфигурации каждые 30 секунд. Независимо от того, работаете ли вы на виртуальных машинах Kubernetes, Служба приложений или виртуальных машинах, предположим, что у вас есть 50 экземпляров приложения, работающих одновременно.

Во-первых, давайте рассмотрим запросы на мониторинг конфигурации. Каждый экземпляр приложения отправляет один запрос на ключ sentinel в Конфигурация приложений каждые 30 секунд, поэтому он будет отправлять запросы 120 (=3600/30) в час. Учитывая, что у вас есть 50 экземпляров приложения, приложение отправляет 6000 (=120x50) общих запросов каждый час для мониторинга конфигурации. Обратите внимание, что поскольку запросы на ключ sentinel часто и в основном не изменяются, большинство из них не будут учитываться в отношении ограничений квоты почасовой квоты хранилища†.

Во-вторых, давайте рассмотрим запросы на загрузку и перезагрузку конфигурации. Приложение загружает все параметры при запуске или при обнаружении изменения ключа sentinel. Каждый запрос к Конфигурация приложений может получить до 100 значений ключей, поэтому для загрузки всех параметров потребуется 10 (=1000/100). Учитывая, что у вас есть 50 экземпляров приложений, вы отправляете 500 (=10x50) общих запросов при перезапуске приложения или перезагрузке конфигурации.

Наконец, давайте сложим его вместе. Если вы дважды обновили ключ sentinel в течение часа, ваше хранилище Конфигурация приложений таким образом получит 7000 (=6000+500x2) общих запросов в течение этого часа. Обратите внимание, что из этих запросов только около 1000 (=500x2) запросов будут использовать доступную почасовую квоту. Обновите числа в этом примере, чтобы соответствовать определенной настройке и проектированию соответствующим образом, чтобы у вас был достаточный буфер для почасового ограничения регулирования. Дополнительные сведения см. в статье о сокращении запросов, сделанных в Конфигурация приложений.

†Уровневые магазины не имеют частых повторяющихся запросов, исключенных из их ежедневного ограничения.

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

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

Да. В то время как вы можете управлять флагами компонентов и ссылками на Key Vault в Конфигурации приложений с помощью портала Azure или CLI, вы также можете создавать и обновлять их программными средствами с помощью пакетов SDK Конфигурации приложений. Следовательно, вы можете написать настроенный портал управления или управлять ими в Ci/CD программным способом. API-интерфейсы флага компонентов и ссылок на Key Vault доступны в пакетах SDK для всех поддерживаемых языков. Примеры для каждого поддерживаемого языка см. по этим ссылкам на примеры.

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

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

Рекомендуется задать метку значений ключей в соответствии с профилями Spring. По умолчанию библиотека поставщика Конфигурация приложений Spring загружает значения ключей с метками, соответствующими текущим активным профилям Spring (${spring.profiles.active}), если фильтр меток не задан явным образом. Если нет активного набора профилей Spring, ключ-значения без метки будут загружены.

Например, с профилями dev и prodзначениями ключей создаются соответствующим образом с помощью следующих меток.

Если для профиля Spring задано devзначение, значение config.message будет.Hello from dev Если для профиля Spring задано prodзначение, значение config.message будет.Hello from prod

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

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Чтобы выбрать другие метки и профили Spring, можно использовать фильтр меток, например ',${spring.profiles.active}', который будет выбирать все ключи без метки и те, которые соответствуют профилям Spring. Наиболее правые метки имеют приоритет при обнаружении повторяющихся ключей.

Начиная с версии 3.1.0 Microsoft.FeatureManagement библиотека позволяет запускать службы управления функциями, включая фильтры компонентов, как область служб в приложениях .NET на основе зависимостей. Чтобы воспользоваться этой функцией, можно просто заменить AddFeatureManagement вызов в коде AddScopedFeatureManagementследующим фрагментом кода:

services.AddScopedFeatureManagement();

Фильтры функций могут оценивать флаг компонента на основе свойств HTTP-запроса. Обычно это выполняется путем проверки HttpContext с помощью одноэлементного IHttpContextAccessorшаблона. Однако этот шаблон не работает для серверных приложений Blazor, где вместо этого следует использовать область службы. В этом случае AddScopedFeatureManagement следует использовать метод.

Подпишитесь на наш репозиторий объявлений на GitHub.

Вы можете связаться с нами прямо на сайте GitHub.

• Сведения о Конфигурация приложений Azure