Рекомендации по хранению для Функций Azure
При создании экземпляра приложения-функции для Функций Azure требуется учетная запись хранения Azure. Следующие службы хранилища можно использовать приложением-функцией:
| Служба хранилища | Назначение функций |
|---|---|
| Хранилище BLOB-объектов Azure | Сохраняйте состояние привязок и ключифункции 1. Используется по умолчанию для центров задач в Устойчивые функции. Можно использовать для хранения кода приложения-функции для удаленной сборки потребления Linux или в рамках развертывания URL-адреса внешнего пакета. |
| Файлы Azure 2 | Общая папка, используемая для хранения и запуска кода приложения-функции в плане потребления и плане Премиум. |
| хранилище очередей Azure; | Используется по умолчанию для центров задач в Устойчивые функции. Используется для обработки сбоев и повторных попыток в определенных триггерах Функции Azure. Используется для отслеживания объектов триггером хранилища BLOB-объектов. |
| Хранилище таблиц Azure | Используется по умолчанию для центров задач в Устойчивые функции. |
1 Хранилище BLOB-объектов — это хранилище по умолчанию для ключей функций, но можно настроить альтернативное хранилище.
2 Файлы Azure настроены по умолчанию, но вы можете создать приложение без Файлы Azure в определенных условиях.
Важные замечания
Необходимо настоятельно учитывать следующие факты, касающиеся учетных записей хранения, используемых приложениями-функциями:
Если приложение-функция размещается в плане потребления или плане Premium, код функции и файлы конфигурации хранятся в Файлы Azure в связанной учетной записи хранения. При удалении этой учетной записи хранения содержимое удаляется и не может быть восстановлено. Дополнительные сведения см. в статье об удалении учетной записи служба хранилища
Важные данные, такие как код функции, ключи доступа и другие важные данные, связанные с службой, могут быть сохранены в учетной записи хранения. Необходимо тщательно управлять доступом к учетным записям хранения, используемым приложениями-функциями следующим образом:
Аудит и ограничение доступа приложений и пользователей к учетной записи хранения на основе модели с минимальными привилегиями. Разрешения для учетной записи хранения могут поступать из действий с данными в назначенной роли или с помощью разрешения на выполнение операции listKeys.
Отслеживайте действия плоскости управления (например, извлечение ключей) и операций плоскости данных (например, запись в большой двоичный объект) в учетной записи хранения. Рекомендуется поддерживать журналы хранения в расположении, отличном от служба хранилища Azure. Дополнительные сведения см. в служба хранилища журналах.
Требования к учетной записи хранения
служба хранилища учетные записи, созданные в рамках потока создания приложения-функции в портал Azure, гарантированно работают с новым приложением-функцией. При выборе использования существующей учетной записи хранения указанный список не включает некоторые неподдерживаемые учетные записи хранения. Следующие ограничения применяются к учетным записям хранения, используемым приложением-функцией, поэтому необходимо убедиться, что существующая учетная запись хранения соответствует следующим требованиям:
Тип учетной записи должен поддерживать хранилище BLOB-объектов, очередей и таблиц. Некоторые учетные записи хранения не поддерживают очереди и таблицы. Эти учетные записи включают учетные записи хранения только BLOB-объектов и хранилища класса Premium Azure. Дополнительные сведения об учетных записях хранения см. в разделе Общие сведения об учетной записи хранения.
Вы не можете использовать учетную запись хранения, уже защищенную с помощью брандмауэра или виртуальной частной сети при создании приложения-функции в портал Azure. Однако портал в настоящее время не фильтрует эти защищенные учетные записи хранения. Сведения об использовании защищенной учетной записи хранения с приложением-функцией см. в статье "Использование защищенной учетной записи хранения с Функции Azure".
Вы не можете использовать защищенные учетные записи хранения с приложениями-функциями, размещенными в плане потребления.
При создании приложения-функции на портале можно выбрать только существующую учетную запись хранения в том же регионе, что и создаваемое приложение-функцию. Это оптимизация производительности, а не строгое ограничение. Дополнительную информацию см. в статье Расположение учетных записей хранения.
При создании приложения-функции в плане с поддержкой зоны доступности поддерживаются только учетные записи хранения, избыточные между зонами .
Вы можете создавать приложения-функции в плане Elastic Premium или выделенного (Служба приложений) с помощью автоматизации развертывания. Однако необходимо включить определенные конфигурации сети в шаблон ARM или Bicep-файл. Если эти параметры и ресурсы не включены, автоматическое развертывание может завершиться ошибкой. Дополнительные сведения см. в разделе "Защищенные развертывания".
Руководство по учетной записи хранения
Для работы каждого приложения-функции нужна учетная запись хранения. Если эта учетная запись удалена, приложение-функция не будет работать. Сведения об устранении неполадок, связанных с хранилищем, см. в статье Устранение неполадок, связанных с хранилищем. Следующие дополнительные рекомендации относятся к учетной записи хранения, используемой приложениями-функциями.
Расположение учетной записи хранения
Для наилучшей производительности в приложении-функции должна использоваться учетная запись хранения в том же регионе, что сокращает задержку. Эта рекомендация применяется на портале Azure. Если потребуется использовать учетную запись хранения в регионе, отличном от региона вашего приложения-функции, необходимо создать приложение-функцию вне портала.
Учетная запись хранения должна быть доступна приложению-функции. Если необходимо использовать безопасную учетную запись хранения, попробуйте ограничить учетную запись хранения виртуальной сетью.
Строка подключения учетной записи хранения
По умолчанию приложения-функции настраивают AzureWebJobsStorage подключение как строка подключения, хранящиеся в параметре приложения AzureWebJobs служба хранилища но также можно настроить AzureWebJobs служба хранилища для использования подключения на основе удостоверений без секрета.
Приложения-функции, работающие в плане потребления (только для 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. Однако необходимо также настроить журналы ресурсов для учетной записи хранения для отслеживания последующего использования ключей или других операций плоскости данных на основе удостоверений. Вы должны иметь по крайней мере категорию журнала служба хранилища Write, чтобы иметь возможность определять изменения данных за пределами обычных операций Функций.
Чтобы ограничить потенциальное влияние всех область область разрешений на хранилище, рассмотрите возможность использования назначения, отличного от журнала, например Log Analytics. Дополнительные сведения см. в статье Мониторинг Хранилища BLOB-объектов.
Оптимизация производительности хранилища
Чтобы увеличить производительность, используйте для каждого приложения-функции отдельную учетную запись хранения. Это особенно важно, если у вас есть устойчивые функции или функции, активируемые концентратором событий, так как и те и другие создают большой объем транзакций с хранилищем. Если логика приложения взаимодействует со службой хранилища Azure напрямую (с помощью пакета SDK службы хранилища) или с помощью одной из привязок к хранилищу, следует использовать выделенную учетную запись хранения. Например, если у вас есть функция, активируемая концентратором событий, которая записывает данные в хранилище BLOB-объектов, используйте две учетные записи хранения: одну для приложения-функции, а другую — для больших двоичных объектов, сохраняемых функцией.
Работа с большими двоичными объектами
Ключевым сценарием функций является обработка файлов в контейнере BLOB-объектов, например для обработки изображений или анализа тональности. Дополнительные сведения см. в разделе "Обработка отправки файлов".
Триггер контейнера BLOB-объектов
Есть несколько способов выполнять код функции при изменениях в больших двоичных объектах, сохраненных в контейнере хранилища. Следующая таблица поможет вам определить, какой триггер функции лучше всего соответствует вашим потребностям.
| Фактор | Хранилище BLOB-объектов (опрос) | Хранилище BLOB-объектов (на основе событий) | Хранилище очередей | Сетка событий |
|---|---|---|---|---|
| Задержка | Высокая (до 10 минут) | Низкая | Средний | Низкий |
| Ограничения по использованию учетных записей хранения | Не поддерживаются¹ учетные записи только для больших двоичных объектов | Не поддерживаются учетные записи общего назначения версии 1 | ничего | Не поддерживаются учетные записи общего назначения версии 1 |
| версия расширения; | Любое | Хранилище версии 5.x и выше | Любой | Любой |
| Обрабатывает существующие большие двоичные объекты | Да | No | No | No |
| Фильтры | Шаблон имени BLOB-объекта | Фильтры событий | Н/Д | Фильтры событий |
| Требуется подписка на события | No | Да | No | Да |
| Поддерживает большой масштаб операций² | No | Да | Да | Да |
| Description | Стандартное поведение триггера, которое основано на опросе обновлений в контейнере. Дополнительные сведения см. в примерах в справочнике по триггеру хранилища BLOB-объектов. | Использует события хранилища BLOB-объектов из подписки на события. Параметр Source должен иметь значение EventGrid. Дополнительные сведения см. в учебнике Триггер большого двоичного объекта сетки событий функции Azure. |
Строка имени BLOB-объекта вручную добавляется в очередь хранилища, когда в контейнер добавляется большой двоичный объект. Это значение передается непосредственно триггером хранилища очередей в входную привязку хранилища BLOB-объектов в той же функции. | Повышает гибкость благодаря активации триггеров по событиям, происходящим вне контейнера хранилища. Используйте, если необходимо также активировать события, не относящиеся к журналу, используйте функцию. Подробнее см. статью Руководство. Работа с триггерами и привязками в Функциях Azure. |
1 Входные и выходные привязки хранилища BLOB-объектов поддерживают учетные записи только для BLOB-объектов.
2 Большое масштабирование может быть свободно определено как контейнеры с более чем 100 000 большими двоичными объектами в них или учетными записями хранения, которые имеют более 100 обновлений BLOB-объектов в секунду.
Шифрование хранимых данных
Служба хранилища 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 по умолчанию настраивается для планов потребления Elastic Premium и не Linux в качестве общей файловой системы в крупномасштабных сценариях. Эта файловая система используется платформой для поддержки некоторых функций, таких как потоковая передача журналов, однако в первую очередь она обеспечивает согласованность развернутых полезных данных функции. При развертывании приложения с использованием URL-адреса внешнего пакета содержимое приложения обслуживается из отдельной файловой системы, доступной только для чтения. Это означает, что приложение-функцию можно создать без Файлов Azure. Если вы создаете приложение-функцию с помощью Файлов Azure, файловая система, доступная для записи, по-прежнему предоставляется. Однако эта файловая система может быть недоступна для всех экземпляров приложения-функции.
Если служба "Файлы Azure" не используется, необходимо выполнить следующие требования:
- Необходимо выполнять развертывание из URL-адреса внешнего пакета.
- Приложение не может использовать общую файловую систему, доступную для записи.
- Приложение не может использовать версию 1.x среды выполнения Функций.
- В клиентах, таких как портал Azure, в качестве интерфейсов потоковой передачи журналов по умолчанию используются журналы файловой системы. Вместо этого следует использовать журналы Application Insights.
Если указанные выше данные правильно учитываются, можно создать приложение без Файлы Azure. Создайте приложение функции без указания параметров приложения WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE. Чтобы не указывать эти параметр, можно создать шаблон ARM для стандартного развертывания, удалить эти два параметра, а затем развернуть шаблон.
Поскольку функции используют Файлы Azure во время динамического горизонтального масштабирования, масштабирование может быть ограничено при выполнении без Файлы Azure планов потребления и эластичных премиумов.
Подключение общих файловых ресурсов
Эта функция доступна только при работе в 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-typeAzureFiles. Вы можете подключить только пять общих папок к конкретному приложению-функции. Подключение общей папки может увеличить время холодного запуска по крайней мере на 200–300 мс или даже больше, если учетная запись хранения находится в другом регионе.
Подключенная общая папка доступна для кода функции в указанном mount-path. Например, если mount-path является /path/to/mount, доступ к целевому каталогу можно получить с помощью API-интерфейсов файловой системы, как показано в следующем примере Python:
import os
...
files_in_share = os.listdir("/path/to/mount")
Следующие шаги
Ознакомьтесь с дополнительными сведениями о вариантах размещения в Функциях Azure.