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

В этой статье изложены ответы на часто задаваемые вопросы о Конфигурации приложений Azure.

Чем отличается служба "Конфигурация приложений" от решения Azure Key Vault?

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

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

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

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

Следует ли хранить секреты в Конфигурации приложений?

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

Вы можете создать в App Configuration пары «ключ-значение», ссылающиеся на секреты, хранящиеся в Key Vault. Дополнительные сведения см. в руководстве по использованию ссылок Key Vault в приложении ASP.NET Core.

Шифрует ли Конфигурация приложений мои данные?

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

Чем отличается Конфигурация приложений от параметров в Службе приложений Azure?

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

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

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

Существуют ли ограничения на размер ключей и значений, хранящихся в Конфигурации приложений?

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

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

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

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

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

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

Как рекомендуется использовать Конфигурацию приложений?

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

Сколько стоит использование Конфигурации приложений?

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

Какой уровень Конфигурации приложений следует использовать?

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

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

  • Назначение. Уровень "Бесплатный" идеально подходит для оценки службы в непроизводственных средах, что позволяет изучить ее функции без каких-либо затрат.

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

    Уровень "Стандартный" предназначен для средних рабочих и непроизводственных вариантов использования, обеспечивая баланс производительности и экономичности.

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

  • Ресурсы на подписку: Ресурс представляет собой одно хранилище конфигурации. Для каждой подписки на уровне Free доступно не более трёх хранилищ конфигураций в каждом регионе. Подписки могут содержать неограниченное число хранилищ конфигурации в категориях Developer, Standard и Premium.

  • Хранилище на ресурс: на уровне Free каждое хранилище конфигурации ограничено 10 МБ основного хранилища и 10 МБ хранилища моментальных снимков. На уровне Developer каждое хранилище конфигурации может использовать до 500 МБ обычного хранилища и дополнительно 500 МБ хранилища снимков. В ценовой категории "Стандартный" каждое хранилище конфигурации может использовать до 1 ГБ обычного хранилища и дополнительно 1 ГБ хранилища моментальных снимков. В уровне "Премиум" каждое хранилище конфигурации может использовать до 4 ГБ основного хранилища и дополнительно 4 ГБ хранилища моментальных снимков.

  • Журнал изменений: App Configuration хранит журнал всех изменений, внесённых в ключи. На уровнях "Бесплатный" и "Разработчик" эта история хранится в течение семи дней. На уровнях "Стандартный" и "Премиум" эта история хранится в течение 30 дней.

  • Квота запросов: В хранилищах бесплатного уровня допускается не более 1 000 запросов в день. Когда для хранилища достигается ограничение в 1000 запросов, в ответ на любые запросы вплоть до наступления полуночи в формате UTC оно возвращает код состояния HTTP 429.

    Магазины уровня Developer ограничены 6 000 запросами в час. После исчерпания почасовой квоты дополнительные запросы возвращают код состояния HTTP 429, указывающий на слишком много запросов до конца часа.

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

    Хранилища уровня "Премиум" не имеют ограничения квоты на запросы, гарантируя, что доступ к хранилищу никогда не блокируется.

  • Пропускная способность: Хранилища App Configuration во всех ценовых категориях имеют лимит пропускной способности. Запросы, превышающие этот лимит, получают ответ с кодом состояния HTTP 429.

    Магазины на уровне "Бесплатный" и "Разработчик" не имеют гарантированной пропускной способности.

    Хранилища на уровне "Стандартный" позволяют частоту выполнения† до 300 запросов в секунду (RPS) для запросов на чтение и до 60 запросов на запись.

    Хранилища ценового уровня «Премиум» поддерживают† до 450 RPS для запросов на чтение и до 100 RPS для запросов на запись.

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

  • Соглашение об уровне обслуживания: уровень "Бесплатный" и уровень "Разработчик" не имеют соглашения об уровне обслуживания. Уровень "Стандарт" предусматривает SLA с доступностью 99,9 % и 99,95 % при включённой георепликации. Для уровня «Премиум» SLA предусматривает доступность на уровне 99,9 %, а при включённой георепликации — 99,99 %.

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

    Тарифный план Developer также включает поддержку Приватный канал.

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

  • Стоимость: нет затрат на использование хранилища уровня "Бесплатный".

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

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

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

Можно ли повысить или понизить уровень хранилища App Configuration?

Вы можете в любое время повысить уровень хранилища App Configuration, например с уровня «Бесплатный» до уровня «Разработчик», «Стандартный» или «Премиум», либо с уровня «Разработчик» или «Стандартный» до уровня «Премиум».

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

Перед понижением уровня хранилища App Configuration с уровня "Премиум" на уровень "Стандартный" убедитесь, что объём используемого основного хранилища и хранилища моментальных снимков не превышает ограничения уровня "Стандартный". Вы можете проверить текущее потребление по метрикам Azure Monitor «Ежедневное использование хранилища» и «Размер хранилища моментальных снимков» для вашего хранилища App Configuration на портале Azure.

Где физически находятся данные, сохраненные в Конфигурации приложений?

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

За счет чего Конфигурация приложений обеспечивает высокий уровень доступности данных?

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

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

Северная и Южная Америки Европа Ближний Восток Африка Азиатско-Тихоокеанский регион
Бразилия (Юг) Центральная Франция Израиль, центральный регион Восточная Австралия
Центральная Канада Центрально-Западная Германия Центральный Катар Центральная Индия
Центральная часть США Северная Италия Северная часть ОАЭ; Северный Китай 3
Восточная часть США Северная Европа Восточная Азия
Восточная часть США 2 Восточная Норвегия; Восточная Япония
Центральная Мексика Центральная Польша Республика Корея, центральный регион
Центрально-южная часть США Центральная Испания Юго-Восточная Азия
Правительство США (Вирджиния) Центральная Швеция
западная часть США 2 Северная Швейцария
Запад США 3 южная часть Соединенного Королевства
Западная Европа

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

Хранилища App Configuration имеют разные квоты запросов в зависимости от их уровня. Хранилища бесплатного уровня ограничены 1 000 запросами в день, хранилища уровня Developer — 6 000 запросами в час, хранилища уровня Standard — 30 000 запросами в час, а хранилища уровня Premium не имеют ограничений на количество запросов, что обеспечивает непрерывный доступ.

Хранилища App Configuration имеют лимиты пропускной способности в зависимости от своего уровня. Бесплатный уровень и магазины уровня разработчика не имеют гарантированной пропускной способности. Хранилища уровня "Стандартный" поддерживают скорость выполнения до 300 запросов в секунду (RPS) для операций чтения и до 60 RPS для операций записи. Хранилища уровня «Премиум» поддерживают до 450 запросов в секунду при операциях чтения и до 100 запросов в секунду при операциях записи.

Как мне оценить количество запросов, которые может отправить мое приложение в App Configuration?

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

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

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

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

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

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

Мое приложение получает ответы с кодом состояния HTTP 429. Почему?

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

  • Превышение дневной квоты запросов для магазина на бесплатном тарифе.
  • Превышение часовой квоты запросов для магазина на тарифе Developer.
  • Превышение почасовой квоты запросов для магазина уровня Standard.
  • Превышение квоты пропускной способности для хранилища на любом уровне.
  • Превышение квоты пропускной способности для хранилища на любом уровне.
  • Попытка создать или изменить значение ключа при превышении квоты хранилища.

Проверьте тело ответа с кодом 429, чтобы узнать конкретную причину сбоя запроса. Вы также можете собирать журналы для своего хранилища App Configuration в Azure Monitor и настраивать оповещения для метрики «Использование квоты запросов».

Кратковременные ответы HTTP со статус-кодом 429 обычно не приводят к проблемам, так как клиенты App Configuration корректно их обрабатывают. Однако если приложение регулярно испытывает ответы на код состояния HTTP 429, рассмотрите следующие варианты:

  • Обновите хранилище до уровня "Премиум": этот уровень не имеет ограничения квоты на запросы и увеличил квоту хранилища и более высокую пропускную способность.
  • Используйте поставщики конфигурации приложений: у поставщиков есть встроенные возможности повторных попыток и кэширования, а также множество других функций устойчивости. Обязательно обновите последнюю версию поставщика для всех последних улучшений.
  • Используйте пакеты SDK для App Configuration, если вашему приложению требуется отправлять запросы на запись. Хотя SDK могут быть не столь функциональны, как провайдеры, они автоматически выполняют повторные попытки при ответах с кодом состояния HTTP 429 и других временных ошибках.
  • Включите логику повторных попыток в пользовательские клиенты, если вы не можете использовать поставщики App Configuration или пакеты SDK. Заголовок retry-after-ms в ответе предоставляет предлагаемое время ожидания (в миллисекундах) перед повтором запроса.
  • Распределяйте запросы между несколькими экземплярами клиента: это поможет добиться максимальной пропускной способности хранилища App Configuration.
  • Уменьшите количество запросов, сделанных в Конфигурация приложений. Следуйте инструкциям, чтобы свести к минимуму количество запросов.
  • Уменьшите время удержания версий для данных "ключ-значение", если вы часто обновляете ключи и значения и вам не нужно сохранять версии для максимального периода, разрешенного вашим хранилищем конфигурации приложений. Количество изменений учитывается в общем объеме использования хранилища вашего магазина. Если превышена квота хранилища, вы больше не сможете создавать или изменять значения ключей или флаги компонентов.
  • Повысьте отказоустойчивость приложения: рассмотрите возможность интеграции георепликации, чтобы обеспечить аварийное переключение и балансировку нагрузки. Ознакомьтесь с рекомендациями по созданию высоконадежных приложений.

Как использовать конфигурацию приложений в клиентских приложениях с конфигурацией гипермасштабирования?

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

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

Как восстановить хранилище Конфигурации приложений, удаленное по ошибке?

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

Как определить, кто получил доступ к хранилищу конфигурации приложений?

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

Можно ли создавать и обновлять флаги компонентов или ссылки на Key Vault программным способом?

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

Для оценки и использования флагов функций в вашем приложении требуется библиотека провайдера конфигурации приложений и управления функциями, которые доступны для .NET, Java Spring, Python, JavaScript и Go. Дополнительные сведения см. в разделе Обзор управления функциями.

Как использовать профили Spring для Java в Конфигурации приложений Azure?

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

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

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

Ключ Название Значение
/application/config.message разработчик Привет от разработчика
/application/config.message прод Привет от 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. Наиболее правые метки имеют приоритет при обнаружении повторяющихся ключей.

Как включить управление функциями в приложениях Blazor или в качестве служб с областью действия в приложениях .NET?

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

services.AddScopedFeatureManagement();

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

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

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

Как сообщить о проблеме или внести предложение?

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

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