Рекомендации по хранению для Функций Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа с большими двоичными объектами

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

Триггер контейнера BLOB-объектов

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

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

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

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

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

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

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

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

Рекомендации в отношении идентификаторов узла

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

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

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

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

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

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

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

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

Кластеры с поддержкой Azure Arc

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

Чтобы создать приложение-функцию в кластере Kubernetes с поддержкой Azure Arc без хранилища, необходимо использовать в Azure CLI команду az functionapp create. Версия Azure CLI должна включать расширение appservice-kube как минимум версии 0.1.7. Чтобы проверить установку и версию расширения, используйте команду az --version.

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

Создание приложения без использования службы "Файлы Azure"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подключенная общая папка доступна для кода функции в указанном mount-path. Например, если mount-path является /path/to/mount, доступ к целевому каталогу можно получить с помощью API-интерфейсов файловой системы, как показано в следующем примере Python:

import os
...

files_in_share = os.listdir("/path/to/mount")

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

Ознакомьтесь с дополнительными сведениями о вариантах размещения в Функциях Azure.