Соображения по хранению для Функции Azure

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

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

Служба хранилища Использование функций
Azure хранилище BLOB-объектов Сохраняйте состояние привязок и функциональные клавиши1.
Источник развертывания для приложений, работающих в плане Flex Consumption.
Используется по умолчанию для центров заданий в Устойчивые функции.
Можно использовать для хранения кода функционального приложения для удаленной сборки потребления Linux или в рамках развертывания по URL-адресу внешнего пакета.
Файлы Azure2 Общая папка, используемая для хранения и запуска кода приложения-функции в плане потребления и плане Премиум.
Обслуживание пакетов расширений.
Храните журналы развертывания.
Поддерживает управляемые зависимости в PowerShell.
хранилище очередей Azure Используется по умолчанию для центров заданий в Устойчивые функции. Используется для обработки сбоев и повторных попыток в определенных триггерах Функции Azure. Используется для отслеживания объектов триггером хранилища Blob.
Azure хранилище таблиц Используется по умолчанию для центров заданий в Устойчивые функции.
Используется для отслеживания диагностических событий.
  1. Хранилище BLOB-объектов — это хранилище по умолчанию для ключей функций, но можно настроить альтернативное хранилище.
  2. Файлы Azure настраивается по умолчанию, но вы можете создать приложение без Файлы Azure в определенных условиях.

Важные замечания

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

  • Если ваше приложение-функция размещается на тарифном плане Consumption или тарифном плане Premium, ваш код функции и файлы конфигурации хранятся в Файлы Azure в связанной учетной записи хранения. При удалении этой учетной записи хранения содержимое удаляется и не может быть восстановлено. Дополнительные сведения см. в статье об удалении учетной записи хранения.

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

    • Аудит и ограничение доступа приложений и пользователей к учетной записи хранения на основе модели с минимальными привилегиями. Разрешения для учетной записи хранения могут поступать из действий с данными в назначенной роли или за счет разрешения на выполнение операции listKeys.

    • Отслеживайте действия плоскости управления (например, извлечение ключей) и операций плоскости данных (например, запись в большой двоичный объект) в учетной записи хранения. Рекомендуется поддерживать журналы хранения в расположении, отличном от служба хранилища Azure. Дополнительные сведения см. в журналах хранилища.

Требования к учетной записи хранения

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

  • Тип учетной записи должен поддерживать хранилище BLOB-объектов, очередей и таблиц. Некоторые учетные записи хранения не поддерживают очереди и таблицы. Эти учетные записи включают учетные записи хранения только для больших двоичных объектов и Azure хранилище класса Premium. Дополнительные сведения об учетных записях хранения см. в разделе Общие сведения об учетной записи хранения.

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

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

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

При использовании автоматизации развертывания для создания приложения-функции с сетево защищенной учетной записью хранения необходимо включить определенные конфигурации сети в шаблон ARM или файл Bicep. Если эти параметры и ресурсы не включены, автоматическое развертывание может не пройти проверку на этапе валидации. Инструкции по шаблону ARM и Bicep см. в разделе Secured deployments. Чтобы получить сведения о настройке учетных записей хранения с сетями, см. статью Как использовать защищенную учетную запись хранения с Функции Azure.

Руководство по учетной записи хранения

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

Расположение учетной записи хранения

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

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

Настройки подключения учетной записи хранения

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

Приложения-функции, работающие в плане потребления (только Windows), или план Elastic Premium (Windows или Linux) могут использовать Файлы Azure для хранения образов, необходимых для включения динамического масштабирования. Для этих планов задайте строку подключения для учетной записи хранения в параметре WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и имя общей папки в параметре WEBSITE_CONTENTSHARE. Обычно это значение совпадает с учетной записью, используемой для AzureWebJobsStorage. Вы также можете создать приложение-функцию, которое не использует Файлы Azure, но масштабирование может быть ограничено.

Примечание.

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

Общие учетные записи хранения

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

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

Особенности использования политик управления жизненным циклом

Не применяйте политики управления жизненным циклом к учетной записи Хранилище BLOB-объектов, используемой приложением-функцией. Функции используют хранилище BLOB-объектов для сохранения важных сведений, таких как ключи доступа к функциям. Политики могут удалять большие двоичные объекты, такие как ключи, необходимые хосту функций. Если необходимо использовать политики, исключите контейнеры, используемые функциями, которые префиксируются с azure-webjobs или scm.

Журналы хранилища

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

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

Чтобы ограничить потенциальное влияние любых широко охватывающих разрешений хранилища, рассмотрите возможность использования нестандартного назначения для этих журналов, например, Log Analytics. Дополнительные сведения см. в разделе Monitoring Хранилище BLOB-объектов Azure.

Оптимизация производительности хранилища

Чтобы увеличить производительность, используйте для каждого приложения-функции отдельную учетную запись хранения. Этот подход особенно важен, если у вас есть Устойчивые функции или триггерные функции Центров событий, которые создают большой объем транзакций хранения. Если логика приложения взаимодействует с служба хранилища Azure напрямую (с помощью пакета SDK службы хранилища) или через одну из привязок хранилища, следует использовать выделенную учетную запись хранения. Например, если у вас есть функция, запускаемая концентратором событий, записывающая некоторые данные в хранилище блоб-объектов, используйте две учетные записи хранения: одну для функции приложения и другую для блоб-объектов, которые хранит функция.

Согласованная маршрутизация через виртуальные сети

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

Работа с объектами BLOB

Ключевой сценарий для функций — это обработка файлов в контейнере объектов BLOB, например, для обработки изображений или анализа тональности. Дополнительные сведения см. в разделе "Обработка отправки файлов".

Триггер на хранилище BLOB-объектов

Существует несколько способов запуска кода функции на основе изменений объектов blob в контейнере хранилища, как показано на этой диаграмме:

Diagram с различными параметрами активации функции при добавлении или обновлении элементов в контейнере Хранилище BLOB-объектов в Azure.

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

Стратегия Триггер BLOB (опрос) Триггер BLOB (на основе событий) Триггер очереди Триггер Сетки событий
Задержка Высокая (до 10 минут) Низкая Средняя Низкая
Ограничения по использованию учетных записей хранения Не поддерживаются учетные записи только для Blob. Не поддерживаются учетные записи общего назначения версии 1 ничего Не поддерживаются учетные записи общего назначения версии 1
Тип триггера Хранилище BLOB-объектов Хранилище BLOB-объектов Хранилище очередей Сетка событий
версия расширения; Любое Хранилище версии 5.x и выше Любое Любое
Обрабатывает существующие большие двоичные объекты Да нет нет нет
Фильтры Шаблон имени BLOB-объекта Фильтры событий Н/Д Фильтры событий
Требуется подписка на события нет Да нет Да
Поддержка плана потребления Flex нет Да Да Да
Поддерживает большой масштаб операций² нет Да Да Да
Работает с ограничениями для входящего доступа Да нет Да Да3
Описание Стандартное поведение триггера, которое основано на опросе контейнера для получения обновлений. Дополнительную информацию см. в примерах в справочнике о триггере для хранилища BLOB-объектов. Использует события хранилища BLOB-объектов из подписки на события. Параметр Source должен иметь значение EventGrid. Дополнительные сведения см. в руководстве: триггер Функции Azure на контейнерах BLOB-объектов с помощью подписки на события. Строка имени BLOB вручную добавляется в очередь хранения, когда BLOB добавляется в контейнер. Триггер хранилища очередей передает это значение непосредственно входной привязке блочного хранилища в той же функции. Обеспечивает гибкость активации событий помимо этих событий, поступающих из контейнера хранилища. Используйте, когда необходимо, чтобы ваша функция активировалась также событиями, не связанными с хранением данных. Дополнительные сведения см. в разделе Как работать с триггерами и привязками сетки событий в Функции Azure.
  1. Привязки для входных и выходных данных блоб-хранилищ поддерживают аккаунты только для блоб-хранилищ.
  2. Большой масштаб можно определить как контейнеры, содержащие более 100 000 больших двоичных объектов, или как учетные записи хранения, в которых выполняется более 100 обновлений больших двоичных объектов в секунду.
  3. Вы можете обойти ограничения на входящий доступ, назначив подписку на событие, которая будет передавать события через зашифрованный канал в общедоступном IP-пространстве с использованием известного удостоверения пользователя. Дополнительные сведения см. в разделе "Безопасное предоставление событий с помощью управляемых удостоверений".

Шифрование хранимых данных

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

По умолчанию данные шифруются с помощью ключей, управляемых Майкрософт. Для получения большего контроля над ключами шифрования можно предоставить управляемые клиентом ключи для шифрования данных BLOB-объектов и файлов. Эти ключи должны присутствовать в Azure Key Vault, чтобы функции могли получить доступ к учетной записи хранения. Дополнительные сведения см. в статье "Шифрование неактивных данных приложения" с помощью ключей, управляемых клиентом.

Место расположения данных в регионе

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

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

Аспекты идентификаторов хоста

Примечание.

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

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

Примечание.

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

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

Предотвращение конфликтов идентификаторов узла

Чтобы избежать конфликтов идентификаторов узла, следуйте следующим подходам:

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

Внимание

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

Переопределение идентификатора хоста

Вы можете явно задать определенный идентификатор узла для приложения-функции в параметрах приложения с помощью параметра AzureFunctionsWebHost__hostid. Дополнительные сведения см. в разделе AzureFunctionsWebHost__hostid.

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

Создание приложения без Файлы Azure

Служба Файлы Azure предоставляет общую файловую систему, которая поддерживает крупномасштабные сценарии. Если ваше приложение-функция работает в плане Elastic Premium или на Windows в плане потребления, в вашей учетной записи хранения по умолчанию создается файл-репозиторий Файлы Azure. Эта общая папка используется функциями для включения определённых возможностей, таких как потоковая передача данных журналов. Он также используется в качестве расположения развертывания совместного пакета, что гарантирует согласованность развернутого кода функции во всех инстанциях.

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

Использование Файлы Azure требует использования строка подключения, который хранится в параметрах приложения как WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Файлы Azure в настоящее время не поддерживает подключения на основе удостоверений. Если вашему сценарию требуется не хранить секреты в параметрах приложения, необходимо удалить зависимость приложения от Файлы Azure. Эту зависимость можно избежать, создав приложение без Файлы Azure зависимости по умолчанию.

Примечание.

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

Чтобы запустить приложение без общей папки Azure, необходимо выполнить следующие требования:

Необходимо вручную обновить пакет развертывания и сохранить URL-адрес пакета развертывания, который, скорее всего, содержит общий ключ доступа (SAS).

Кроме того, следует отметить следующие рекомендации.

  • Приложение не может использовать версию 1.x среды выполнения Функций.
  • Приложение не может использовать общую файловую систему, доступную для записи.
  • Редактирование портала не поддерживается.
  • Потоковая передача журналов в клиентах, таких как портал Azure, по умолчанию нацелена на журналы файловой системы. Вместо этого следует использовать журналы Application Insights.

Если предыдущие требования соответствуют вашему сценарию, можно продолжить создание приложения-функции без Файлы Azure. Создайте приложение одним из этих способов без настроек приложения WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE.

  • Шаблоны Bicep/ARM: удалите две настройки приложения из шаблона ARM или файла Bicep, а затем разверните приложение, используя измененный шаблон.
  • Портал Azure: снимите выделение добавьте подключение Файлы Azure на вкладке "Хранилище" при создании приложения на портале Azure.

Файлы Azure используется для включения динамического масштабирования для функций. Масштабирование может быть ограничено при запуске приложения без Файлы Azure в плане Elastic Premium и планах Consumption на платформе Windows.

Подключение общих файловых ресурсов

Эта функция в настоящее время доступна только при запуске в Linux.

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

Внимание

Приложения-функции, которые до сих пор работают на устаревшей среде выполнения версии 3 на Linux в потребительском плане, перестанут функционировать после 30 сентября 2026 года. Чтобы избежать нарушения работы службы, перенесите приложение в среду выполнения версии 4.

Возможность размещения приложений-функций на Linux в плане Consumption прекращает своё действие 30 сентября 2028 года. План потребления Linux не получает новых функций или языковых версий. Приложения, работающие на Windows в плане потребления, в настоящее время не затрагиваются. Перенесите ваши приложения на план потребления Flex до даты прекращения поддержки.

Вы можете использовать следующую команду, чтобы подключить существующую общую папку к приложению-функции Linux.

az webapp config storage-account add (добавить учетную запись хранилища в конфигурацию веб-приложения)

В этой команде share-name — это имя существующей общей папки Файлы Azure. custom-id может быть любой строкой, которая однозначно определяет общую папку при подключении к приложению-функции. Кроме того, mount-path — это путь, по которому осуществляется доступ к общему ресурсу в вашем приложении функций. mount-path должен иметь формат /dir-name и не может начинаться с /home.

Полный пример см. в разделе Create a Python function app and mount an Файлы Azure share.

Связанная статья

Узнайте больше о вариантах размещения Функции Azure.

Функции Azure масштабирование и хостинг

  • Last updated on