Вопросы хранения для Azure Functions

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

1. Хранилище BLOB-объектов — это хранилище по умолчанию для ключей функций, но можно настроить альтернативное хранилище.
2. Azure Files настраивается по умолчанию, но вы можете создать приложение без Azure Files в определенных условиях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Привязки для входных и выходных данных блоб-хранилищ поддерживают аккаунты только для блоб-хранилищ.
2. Большой масштаб можно определить как контейнеры, содержащие более 100 000 больших двоичных объектов, или как учетные записи хранения, в которых выполняется более 100 обновлений больших двоичных объектов в секунду.
3. Вы можете обойти ограничения на входящий доступ, назначив подписку на событие, которая будет передавать события через зашифрованный канал в общедоступном IP-пространстве с использованием известного удостоверения пользователя. Дополнительные сведения см. в разделе "Безопасное предоставление событий с помощью управляемых удостоверений".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание приложения без Azure Files

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

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

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

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

• Необходимо развернуть пакет в удаленный контейнер хранилища BLOB-объектов Azure и задать URL-адрес, предоставляющий доступ к пакету, в качестве настройки приложения WEBSITE_RUN_FROM_PACKAGE. Этот подход позволяет хранить содержимое приложения в хранилище BLOB-объектов вместо Azure Files, которая поддерживает управляемые удостоверения.

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

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

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

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

• Bicep/шаблоны ARM: удалите два параметра приложения из файла шаблона ARM или Bicep, затем разверните приложение с помощью измененного шаблона.
• Портал Azure: отмените выбор Добавить соединение Azure Files во вкладке Storage при создании приложения в портале Azure.

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

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

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

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

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

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

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