Рекомендации по хранению для Функций Azure
При создании экземпляра приложения-функции для Функций Azure требуется учетная запись хранения Azure. Следующие службы хранилища можно использовать приложением-функцией:
| Служба хранилища | Назначение функций |
|---|---|
| Хранилище BLOB-объектов Azure | Сохраняйте состояние привязок и ключифункции 1. Источник развертывания для приложений, работающих в плане потребления Flex. Используется по умолчанию для центров задач в Устойчивые функции. Можно использовать для хранения кода приложения-функции для удаленной сборки потребления Linux или в рамках развертывания URL-адреса внешнего пакета. |
| Файлы Azure 2 | Общая папка, используемая для хранения и запуска кода приложения-функции в плане потребления и плане Премиум. |
| хранилище очередей Azure; | Используется по умолчанию для центров задач в Устойчивые функции. Используется для обработки сбоев и повторных попыток в определенных триггерах Функции Azure. Используется для отслеживания объектов триггером хранилища BLOB-объектов. |
| Хранилище таблиц Azure | Используется по умолчанию для центров задач в Устойчивые функции. |
- Хранилище BLOB-объектов — это хранилище по умолчанию для ключей функций, но можно настроить альтернативное хранилище.
- Служба "Файлы 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-webjobs scm.
Журналы хранилища
Так как код функции и ключи могут сохраняться в учетной записи хранения, ведение журнала действий в учетной записи хранения является хорошим способом мониторинга несанкционированного доступа. Журналы ресурсов Azure Monitor можно использовать для отслеживания событий в плоскости данных хранилища. Дополнительные сведения о настройке и проверке этих журналов см. в служба хранилища Azure мониторинга.
В журнале действий Azure Monitor отображаются события плоскости управления, включая операцию listKeys. Однако необходимо также настроить журналы ресурсов для учетной записи хранения для отслеживания последующего использования ключей или других операций плоскости данных на основе удостоверений. Вы должны иметь по крайней мере категорию журнала StorageWrite, чтобы иметь возможность идентифицировать изменения данных вне обычных операций Функций.
Чтобы ограничить потенциальное влияние любых разрешений на хранилище с широкой областью действия, рассмотрите возможность использования назначения, отличного от журнала, например Log Analytics. Дополнительные сведения см. в статье Мониторинг Хранилища BLOB-объектов.
Оптимизация производительности хранилища
Чтобы увеличить производительность, используйте для каждого приложения-функции отдельную учетную запись хранения. Это особенно важно, если у вас есть устойчивые функции или функции, активируемые концентратором событий, так как и те и другие создают большой объем транзакций с хранилищем. Если логика приложения взаимодействует со службой хранилища Azure напрямую (с помощью пакета SDK службы хранилища) или с помощью одной из привязок к хранилищу, следует использовать выделенную учетную запись хранения. Например, если у вас есть функция, активируемая концентратором событий, которая записывает данные в хранилище BLOB-объектов, используйте две учетные записи хранения: одну для приложения-функции, а другую — для больших двоичных объектов, сохраняемых функцией.
Согласованная маршрутизация через виртуальные сети
Несколько приложений-функций, размещенных в одном плане, также могут использовать одну и ту же учетную запись хранения для Файлы Azure общей папки содержимого (определяетсяWEBSITE_CONTENTAZUREFILECONNECTIONSTRING). Если эта учетная запись хранения также защищена виртуальной сетью, все эти приложения также должны использовать то же значение для vnetContentShareEnabled (ранее WEBSITE_CONTENTOVERVNET), чтобы гарантировать, что трафик направляется последовательно через предназначенную виртуальную сеть. Несоответствие в этом параметре между приложениями, использующими ту же Файлы Azure учетную запись хранения, может привести к маршрутизации трафика через общедоступные сети, что приводит к блокировке доступа правилами сети учетной записи хранения.
Работа с большими двоичными объектами
Ключевым сценарием функций является обработка файлов в контейнере BLOB-объектов, например для обработки изображений или анализа тональности. Дополнительные сведения см. в разделе "Обработка отправки файлов".
Триггер контейнера BLOB-объектов
Есть несколько способов выполнять код функции при изменениях в больших двоичных объектах, сохраненных в контейнере хранилища. Следующая таблица поможет вам определить, какой триггер функции лучше всего соответствует вашим потребностям.
| Стратегия | Контейнер (опрос) | Контейнер (события) | Триггер очереди | Сетка событий |
|---|---|---|---|---|
| Задержка | Высокая (до 10 минут) | Низкая | Средняя | Низкий |
| Ограничения по использованию учетных записей хранения | Не поддерживаются¹ учетные записи только для больших двоичных объектов | Не поддерживаются учетные записи общего назначения версии 1 | ничего | Не поддерживаются учетные записи общего назначения версии 1 |
| Тип триггера | Хранилище BLOB-объектов | Хранилище BLOB-объектов | Хранилище очередей | Сетка событий |
| версия расширения; | Любое | Хранилище версии 5.x и выше | Любой | Любой |
| Обрабатывает существующие большие двоичные объекты | Да | No | No | No |
| Фильтры | Шаблон имени BLOB-объекта | Фильтры событий | Н/Д | Фильтры событий |
| Требуется подписка на события | No | Да | No | Да |
| Поддержка плана потребления Flex | No | Да | Да | Да |
| Поддерживает большой масштаб операций² | No | Да | Да | Да |
| Description | Стандартное поведение триггера, которое основано на опросе обновлений в контейнере. Дополнительные сведения см. в примерах в справочнике по триггеру хранилища BLOB-объектов. | Использует события хранилища BLOB-объектов из подписки на события. Параметр Source должен иметь значение EventGrid. Дополнительные сведения см. в учебнике Триггер большого двоичного объекта сетки событий функции Azure. |
Строка имени BLOB-объекта вручную добавляется в очередь хранилища, когда в контейнер добавляется большой двоичный объект. Это значение передается непосредственно триггером хранилища очередей в входную привязку хранилища BLOB-объектов в той же функции. | Повышает гибкость благодаря активации триггеров по событиям, происходящим вне контейнера хранилища. Используйте, если необходимо также активировать события, не относящиеся к журналу, используйте функцию. Подробнее см. статью Руководство. Работа с триггерами и привязками в Функциях Azure. |
- Входные и выходные привязки хранилища BLOB-объектов поддерживают учетные записи только для больших двоичных объектов.
- Большой масштаб можно определить как контейнеры, содержащие более 100 000 больших двоичных объектов, или как учетные записи хранения, в которых выполняется более 100 обновлений больших двоичных объектов в секунду.
Шифрование хранимых данных
Служба хранилища Azure шифрует все данные в неактивных учетных записях хранения. Дополнительные сведения см. в статье Шифрование службы хранилища Azure для неактивных данных.
По умолчанию данные шифруются с помощью ключей, управляемых Майкрософт. Для дополнительного управления ключами шифрования можно предоставить ключи, управляемые клиентом, чтобы зашифровать большие двоичные объекты и данные файлов. Эти ключи должны присутствовать в Azure Key Vault, чтобы Функции Azure могли получить доступ к учетной записи хранения. Дополнительные сведения см. в разделе Шифрование неактивных данных с помощью управляемых клиентом ключей.
Место расположения данных в регионе
Если все данные клиента должны оставаться в пределах одного региона, учетная запись хранения, связанная с приложением-функцией, должна быть единственной с избыточностью в регионе. Кроме того, в Устойчивых функциях Azure необходимо использовать учетную запись хранения с избыточностью в регионе.
Другие данные клиента, управляемые платформой, хранятся в регионе только при размещении в Среде службы приложений с балансировкой нагрузки (ASE). Дополнительные сведения см. в разделе избыточность между зонами ASE.
Рекомендации в отношении идентификаторов узла
Функции используют значение идентификатора узла для уникальной идентификации конкретного приложения-функции в хранимых артефактах. По умолчанию этот идентификатор автоматически создается из имени приложения-функции, усечен до первых 32 символов. Затем он применяется при хранении данных корреляции для каждого приложения и для отслеживания данных в связанной учетной записи хранения. Если у вас есть приложения-функции с именами длиной более 32 символов, у которых первые 32 символа идентичны, такое усечение может привести к дублированию идентификаторов узла. Если два приложения-функции с одинаковыми идентификаторами узлов используют одну учетную запись хранения, возникает конфликт идентификаторов, так как сохраненные данные не удается уникальным образом связать с приложением-функцией.
Примечание.
Такой же конфликт идентификаторов основного приложения может возникнуть между приложением-функцией в рабочем слоте и тем же приложением-функцией в промежуточном слоте, когда оба слота используют одну и ту же учетную запись хранения.
Начиная с версии 3.x среды выполнения Функций такие конфликты идентификаторов узла обнаруживаются, после чего выдаются предупреждения. В версии 4.x в журнал заносится ошибка и узел останавливается, что приводит к жесткому сбою. Дополнительные сведения о конфликтах идентификаторов узла см. в описании этой проблемы.
Предотвращение конфликтов идентификаторов узла
Чтобы избежать конфликтов идентификаторов узла, используйте следующие подходы:
- Используйте отдельную учетную запись хранения для каждого конфликтующего приложения-функции или слота.
- Переименуйте одно из приложений-функций, задав для него название длиной менее 32 символов, чтобы изменить идентификатор рассчитываемого для приложения узла и избежать конфликта.
- Задайте явный идентификатор узла для одного или нескольких конфликтующих приложений. Дополнительные сведения см. в разделе о переопределении идентификатора узла.
Внимание
Изменение учетной записи хранения, связанной с существующим приложением-функцией, и изменение идентификатора узла приложения могут повлиять на работу существующих функций. Например, триггер хранилища BLOB-объектов отслеживает, обрабатывает ли он отдельные большие двоичные объекты, записывая квитанции в соответствии с определенным путем идентификатора узла в хранилище. Когда идентификатор узла изменяется или указываете на новую учетную запись хранения, ранее обработанные большие двоичные объекты можно повторно обработать.
Переопределение идентификатора узла
Вы можете явно задать определенный идентификатор узла для приложения-функции в параметрах приложения с помощью параметра AzureFunctionsWebHost__hostid. Дополнительные сведения см. в разделе AzureFunctionsWebHost__hostid.
При столкновении между слотами необходимо задать определенный идентификатор узла для каждого слота, включая рабочий слот. Эти параметры также необходимо пометить как параметры развертывания, чтобы они не переключились. Сведения о создании параметров приложения см. в разделе Работа с параметрами приложения.
Кластеры с поддержкой Azure Arc
При развертывании приложения-функции в кластере Kubernetes с поддержкой Azure Arc учетная запись хранения может не потребоваться приложению-функции. В этом случае учетная запись хранения будет нужна Функциям Azure, только когда приложение-функция использует триггер, требующий хранилища. В следующей таблице указывается, какие триггеры могут требовать учетную запись хранения и которые не требуются.
| Необязательное | Может потребоваться хранилище |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Служебная шина |
Azure SQL • Хранилище BLOB-объектов • Сетка событий • Центры событий • Центр Интернета вещей • Хранилище очередей • SendGrid • SignalR • Хранилище таблиц • Таймер • Twilio |
Чтобы создать приложение-функцию в кластере Kubernetes с поддержкой Azure Arc без хранилища, необходимо использовать в Azure CLI команду az functionapp create. Версия Azure CLI должна включать расширение appservice-kube как минимум версии 0.1.7. Чтобы проверить установку и версию расширения, используйте команду az --version.
Другие методы создания ресурсов приложения-функции помимо Azure CLI требуют наличия учетной записи хранения. Если вы планируете использовать триггеры, которым необходима учетная запись хранения, нужно создать эту запись перед созданием приложения-функции.
Создание приложения без использования службы "Файлы Azure"
Служба Файлы Azure предоставляет общую файловую систему, которая поддерживает крупномасштабные сценарии. Когда приложение-функция работает в Windows в плане эластичного уровня "Премиум" или "Потребление", Файлы Azure общий ресурс создается по умолчанию в учетной записи хранения. Эта общая папка используется функциями для включения определенных функций, таких как потоковая передача журналов. Он также используется в качестве расположения развертывания общего пакета, что гарантирует согласованность развернутого кода функции во всех экземплярах.
По умолчанию приложения-функции, размещенные в планах "Премиум" и "Потребление", используют zip-развертывание с пакетами развертывания, хранящимися в этой общей папке Azure. Этот раздел относится только к этим планам размещения.
Использование Файлы Azure требует использования строка подключения, который хранится в параметрах приложения как WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Файлы Azure в настоящее время не поддерживает подключения на основе удостоверений. Если в вашем сценарии не требуется хранить секреты в параметрах приложения, необходимо удалить зависимость приложения от Файлы Azure. Это можно сделать, создав приложение без зависимости по умолчанию Файлы Azure.
Примечание.
Также следует рассмотреть возможность запуска в приложении-функции в плане потребления Flex, что обеспечивает более широкий контроль над пакетом развертывания, включая возможность использования подключений к управляемым удостоверениям. Дополнительные сведения см. в разделе "Настройка параметров развертывания" в статье "Использование Flex".
Чтобы запустить приложение без общей папки Azure, необходимо выполнить следующие требования:
- Необходимо развернуть пакет в удаленном контейнере хранилища BLOB-объектов Azure, а затем задать URL-адрес, предоставляющий доступ к пакету
WEBSITE_RUN_FROM_PACKAGEв качестве параметра приложения. Этот параметр позволяет хранить содержимое приложения в хранилище BLOB-объектов вместо Файлы Azure, что поддерживает управляемые удостоверения.
Вы несете ответственность за обновление пакета развертывания вручную и обслуживание URL-адреса пакета развертывания, который, скорее всего, содержит подписанный URL-адрес (SAS).
- Приложение не может использовать общую файловую систему, доступную для записи.
- Приложение не может использовать версию 1.x среды выполнения Функций.
- В клиентах, таких как портал Azure, в качестве интерфейсов потоковой передачи журналов по умолчанию используются журналы файловой системы. Вместо этого следует использовать журналы Application Insights.
Если приведенные выше требования соответствуют вашему сценарию, можно продолжить создание приложения-функции без Файлы Azure. Это можно сделать, создав приложение без WEBSITE_CONTENTAZUREFILECONNECTIONSTRING параметров приложения и WEBSITE_CONTENTSHARE приложения. Чтобы приступить к работе, создайте шаблон ARM для стандартного развертывания, удалите два параметра и разверните измененный шаблон.
Так как Файлы Azure используется для включения динамического масштабирования для функций, масштабирование может быть ограничено при запуске приложения без Файлы Azure в плане эластичного уровня "Премиум" и планах потребления, работающих в Windows.
Подключение общих файловых ресурсов
Эта функция доступна только при работе в Linux.
Вы можете подключить существующие общие папки Файлов Azure к приложениям-функциям Linux. Подключив общую папку к приложению-функции Linux, вы можете использовать существующие модели машинного обучения или другие данные в своих функциях. Вы можете использовать следующую команду, чтобы подключить существующую общую папку к приложению-функции Linux.
az webapp config storage-account add
В этой команде share-name — это имя существующей общей папки Файлов Azure, а custom-id может быть любой строкой, которая уникально определяет общую папку при подключении к приложению-функции. Кроме того, mount-path — это путь, по которому осуществляется доступ к общей папке в приложении-функции. mount-path должен иметь формат /dir-name и не может начинаться с /home.
Полный пример см. в сценариях в статье "Создание приложения-функции Python" и подключение Файлы Azure общего ресурса.
В настоящее время поддерживается только storage-type AzureFiles. Вы можете подключить только пять общих папок к конкретному приложению-функции. Подключение общей папки может увеличить время холодного запуска по крайней мере на 200–300 мс или даже больше, если учетная запись хранения находится в другом регионе.
Подключенная общая папка доступна для кода функции в указанном mount-path. Например, если mount-path является /path/to/mount, доступ к целевому каталогу можно получить с помощью API-интерфейсов файловой системы, как показано в следующем примере Python:
import os
...
files_in_share = os.listdir("/path/to/mount")
Следующие шаги
Ознакомьтесь с дополнительными сведениями о вариантах размещения в Функциях Azure.