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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При использовании автоматизации развертывания для создания приложения-функции с учетной записью хранения, защищенной сетью, необходимо включить определенные конфигурации сети в шаблон ARM или Bicep-файл. Если эти параметры и ресурсы не включены, автоматическое развертывание может завершиться ошибкой. Дополнительные инструкции по ARM и Bicep см. в разделе "Защищенные развертывания". Общие сведения о настройке учетных записей хранения с сетевыми сетями см. в статье "Использование защищенной учетной записи хранения с Функции 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 службы хранилища) или с помощью одной из привязок к хранилищу, следует использовать выделенную учетную запись хранения. Например, если у вас есть функция, активируемая концентратором событий, которая записывает данные в хранилище BLOB-объектов, используйте две учетные записи хранения: одну для приложения-функции, а другую — для больших двоичных объектов, сохраняемых функцией.

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

Несколько приложений-функций, размещенных в одном плане, также могут использовать одну и ту же учетную запись хранения для Файлы 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 в журнал заносится ошибка и узел останавливается, что приводит к жесткому сбою. Дополнительные сведения о конфликтах идентификаторов узла см. в описании этой проблемы.

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

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

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

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

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

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

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

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

Чтобы создать приложение-функцию в кластере 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, что поддерживает управляемые удостоверения.

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

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

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

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

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

Так как Файлы Azure используется для включения динамического масштабирования для функций, масштабирование может быть ограничено при запуске приложения без Файлы Azure в плане эластичного уровня "Премиум" и планах потребления, работающих в 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.