Руководство разработчиков Функций Azure
В Функции Azure все функции используют некоторые основные технические понятия и компоненты независимо от предпочитаемого языка или среды разработки. Эта статья зависит от языка. Выберите предпочитаемый язык в верхней части статьи.
В этой статье предполагается, что вы уже прочли статью Общие сведения о Функциях Azure.
Если вы предпочитаете перейти вправо, вы можете выполнить краткое руководство по работе с помощью Visual Studio, Visual Studio Code или из командной строки.
Если вы предпочитаете перейти вправо, вы можете выполнить краткое руководство по началу работы с помощью Maven (командной строки), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud или Visual Studio Code.
Если вы предпочитаете перейти прямо в систему, вы можете выполнить краткое руководство по работе с Visual Studio Code или из командной строки.
Если вы предпочитаете перейти прямо в систему, вы можете выполнить краткое руководство по работе с Visual Studio Code или из командной строки.
Если вы предпочитаете перейти прямо в систему, вы можете выполнить краткое руководство по работе с Visual Studio Code или из командной строки.
Если вы предпочитаете перейти прямо в систему, вы можете выполнить краткое руководство по работе с Visual Studio Code или из командной строки.
Проект кода
В основе Функции Azure лежит проект кода для конкретного языка, который реализует одну или несколько единиц выполнения кода, называемых функциями. Функции — это просто методы, которые выполняются в облаке Azure на основе событий, в ответ на HTTP-запросы или по расписанию. Думайте о проекте кода Функции Azure в качестве механизма для организации, развертывания и коллективного управления отдельными функциями в проекте при их запуске в Azure. Дополнительные сведения см. в разделе "Упорядочение функций".
Способ размещения проекта кода и способ указания методов в проекте зависит от языка разработки проекта. Подробные рекомендации по языку см. в руководстве разработчиков C#.
Способ размещения проекта кода и способ указания методов в проекте зависит от языка разработки проекта. Инструкции для конкретного языка см. в руководстве разработчиков Java.
Способ размещения проекта кода и способ указания методов в проекте зависит от языка разработки проекта. Инструкции по языку см. в руководстве разработчиков Node.js.
Способ размещения проекта кода и способ указания методов в проекте зависит от языка разработки проекта. Инструкции по языку см. в руководстве разработчиков PowerShell.
Способ размещения проекта кода и способ указания методов в проекте зависит от языка разработки проекта. Инструкции для конкретных языков см. в руководстве разработчиков Python.
Все функции должны иметь триггер, который определяет, как запускается функция и может предоставлять входные данные функции. Функции могут при необходимости определять входные и выходные привязки. Эти привязки упрощают подключения к другим службам без необходимости работать с клиентскими пакетами SDK. См. дополнительные сведения о триггерах и привязках в Функциях Azure.
Функции Azure предоставляет набор шаблонов проектов и функций для конкретного языка, которые упрощают создание проектов кода и добавление функций в проект. Вы можете использовать любой из инструментов, поддерживающих разработку Функции Azure, для создания новых приложений и функций с помощью этих шаблонов.
Средства разработки
Следующие средства предоставляют интегрированный интерфейс разработки и публикации для Функции Azure на предпочитаемом языке:
Функции Azure Core Tools (командная строка)
Эти средства интегрируются с Функции Azure Core Tools, чтобы можно было запускать и отладку на локальном компьютере с помощью среды выполнения функций. Дополнительные сведения см. в статье Как программировать и тестировать Функции Azure в локальной среде.
В портал Azure также есть редактор, который позволяет обновлять код и файл определения function.json непосредственно на портале. Этот редактор следует использовать только для небольших изменений или создания функций проверки концепции. Вы всегда должны разрабатывать свои функции локально, когда это возможно. Дополнительные сведения см. в статье Создание первой функции на портале Azure.
Редактирование портала поддерживается только для Node.js версии 3, которая использует файл function.json.
Развертывание
При публикации проекта кода в Azure вы фактически развертываете проект в существующем ресурсе приложения-функции. Приложение-функция предоставляет контекст выполнения в Azure, в котором выполняются функции. Таким образом, это единица развертывания и управления для ваших функций. С точки зрения ресурсов Azure приложение-функция эквивалентно ресурсу сайта (Microsoft.Web/sites
) в службе приложение Azure, что эквивалентно веб-приложению.
Приложение-функция состоит из одной или нескольких отдельных функций, которые управляются, развертываются и масштабируются вместе. Все функции в приложении-функции используют один и тот же план ценообразования, метод развертывания и версию среды выполнения. Дополнительные сведения см. в статье "Управление приложением-функцией".
Если приложение-функция и другие необходимые ресурсы еще не существуют в Azure, сначала необходимо создать эти ресурсы, прежде чем развернуть файлы проекта. Эти ресурсы можно создать одним из следующих способов:
- Во время публикации Visual Studio
Использование Visual Studio Code
Программное использование Azure CLI, Azure PowerShell, шаблонов ARM или шаблонов Bicep
На портале Azure:
Помимо публикации на основе инструментов Функции поддерживают другие технологии для развертывания исходного кода в существующем приложении-функции. Дополнительные сведения см. в статье Технологии развертывания в Функциях Azure.
Подключение к службам
Основное требование любой облачной вычислительной службы заключается в чтении и записи данных в другие облачные службы. Функции предоставляют широкий набор привязок, что упрощает подключение к службам без необходимости работать с клиентскими пакетами SDK.
Независимо от того, используете ли вы расширения привязки, предоставляемые Функциями, или работаете с клиентскими пакетами SDK напрямую, вы безопасно храните данные подключения и не включаете его в код. Дополнительные сведения см. в разделе Соединения.
Привязки
Функции предоставляют привязки для многих служб Azure и нескольких сторонних служб, которые реализуются как расширения. Дополнительные сведения см. в полном списке поддерживаемых привязок.
Расширения привязки могут поддерживать входные и выходные данные, а многие триггеры также действуют в качестве входных привязок. Привязки позволяют настроить подключение к службам, чтобы узел функций может обрабатывать доступ к данным. См. дополнительные сведения о триггерах и привязках в Функциях Azure.
Если у вас возникли проблемы с ошибками, поступающими из привязок, ознакомьтесь с документацией по Функции Azure кодов ошибок привязки.
Клиентские пакеты SDK
Хотя Функции предоставляют привязки для упрощения доступа к данным в коде функции, вы по-прежнему можете использовать клиентский пакет SDK в проекте для прямого доступа к данной службе, если вы предпочитаете. Возможно, вам потребуется использовать клиентские пакеты SDK напрямую, если для функций требуется функциональность базового пакета SDK, который не поддерживается расширением привязки.
При использовании клиентских пакетов SDK следует использовать тот же процесс для хранения и доступа к строка подключения, используемых расширениями привязки.
При создании экземпляра клиентского пакета SDK в функциях необходимо получить сведения о подключении, необходимые клиенту из переменных среды.
При создании экземпляра клиентского пакета SDK в функциях необходимо получить сведения о подключении, необходимые клиенту из переменных среды.
При создании экземпляра клиентского пакета SDK в функциях необходимо получить сведения о подключении, необходимые клиенту из переменных среды.
При создании экземпляра клиентского пакета SDK в функциях необходимо получить сведения о подключении, необходимые клиенту из переменных среды.
При создании экземпляра клиентского пакета SDK в функциях необходимо получить сведения о подключении, необходимые клиенту из переменных среды.
Связи
В качестве рекомендации по обеспечению безопасности Функции Azure использует функциональные возможности параметров приложения службы приложение Azure, чтобы обеспечить более безопасное хранение строк, ключей и других маркеров, необходимых для подключения к другим службам. Параметры приложения в Azure хранятся в зашифрованном виде и могут быть доступны во время выполнения приложением в виде пар переменных name
value
среды. Для триггеров и привязок, требующих свойства подключения, необходимо задать имя параметра приложения вместо фактического строка подключения. Невозможно настроить привязку непосредственно с помощью строка подключения или ключа.
Например, рассмотрим определение триггера connection
, которое имеет свойство. Вместо строка подключения задается connection
имя переменной среды, содержащей строка подключения. Использование этой стратегии доступа к секретам делает приложения более безопасными и упрощает изменение подключений между средами. Для еще большей безопасности можно использовать подключения на основе удостоверений.
Поставщик конфигурации по умолчанию использует переменные среды. Эти переменные определяются в параметрах приложения при запуске в Azure и локальном файле параметров при локальной разработке.
Значения подключений
Если имя подключения указывает на одно точное значение, среда выполнения определяет значение как строку подключения, которая обычно содержит секрет. Сведения о строка подключения зависят от службы, к которой вы подключаетесь.
Однако имя подключения также может ссылаться на коллекцию нескольких элементов конфигурации. Это удобно при настройке подключений на основе удостоверений. Переменные среды можно представить как коллекцию с помощью общего префикса, заканчивающегося двойными символами подчеркивания __
. На эту группу можно ссылаться, задав имя подключения для этого префикса.
Например, connection
свойство для определения триггера BLOB-объектов Azure может быть Storage1
. Если ни одно строковое значение, настроенное переменной среды с именемStorage1
, то для информирования blobServiceUri
свойства подключения можно использовать переменную Storage1__blobServiceUri
среды. Свойства подключения у всех служб различны. Сведения о компоненте, использующем подключение, см. в документации.
Примечание.
При использовании Конфигурации приложений Azure или Key Vault для предоставления параметров подключений Управляемого удостоверения имена параметров должны использовать допустимый разделитель ключей, например :
или /
, вместо __
, чтобы обеспечить правильное разрешение имен.
Например, Storage1:blobServiceUri
.
Настройка подключения на основе удостоверений
Для некоторых подключений в Функциях Azure можно настроить использование удостоверения, а не секрета. Поддержка зависит от расширения, использующего подключение. В некоторых случаях строка подключения по-прежнему требуется в Функциях, даже если служба, к которой вы подключаетесь, поддерживает подключения на основе удостоверений. Руководство по настройке приложений-функций с помощью управляемых удостоверений см. в руководстве по созданию приложения-функции с подключениями на основе удостоверений.
Примечание.
При запуске в плане "Потребление" или "Эластичная премиум" приложение использует WEBSITE_AZUREFILESCONNECTIONSTRING
параметры и WEBSITE_CONTENTSHARE
параметры при подключении к Файлы Azure учетной записи хранения, используемой приложением-функцией. Файлы Azure не поддерживает использование управляемого удостоверения при доступе к общей папке. Дополнительные сведения см. в Файлы Azure поддерживаемых сценариях проверки подлинности
Следующие компоненты поддерживают подключения на основе удостоверений:
При размещении в службе "Функции Azure" для подключений на основе удостоверений используется управляемое удостоверение. По умолчанию используется назначаемое системой удостоверение, однако вы можете указать назначаемое пользователем удостоверение с помощью свойств credential
и clientID
. Обратите внимание, что настройка назначаемого пользователем удостоверения с идентификатором ресурса не поддерживается. При выполнении в других контекстах, например при локальной разработке, вместо этого используется удостоверение разработчика, хотя это можно настроить. См. раздел Локальная разработка с использованием подключений на основе удостоверений.
Предоставление разрешения удостоверению
Любое используемое удостоверение должно иметь разрешения на выполнение предполагаемых действий. Для большинства служб Azure это означает, что необходимо назначить роль в Azure RBAC, используя встроенные или настраиваемые роли, которые предоставляют эти разрешения.
Внимание
Иногда целевая служба может предоставлять разрешения, которые не являются обязательными для всех контекстов. Там, где это возможно, придерживайтесь принципа минимальных привилегий, предоставляя удостоверению лишь самые необходимые привилегии. Например, если приложению требуется только возможность чтения из источника данных, используйте роль, которая имеет разрешение только на чтение. Было бы неуместным назначить роль, которая также разрешает запись в эту службу, так как это разрешение не требуется для операции чтения. Соответственно необходимо еще проверить, что область действия назначенной роли ограничена только теми ресурсами, которые необходимо прочитать.
Выберите одну из этих вкладок, чтобы узнать о разрешениях для каждого компонента:
- Расширение BLOB-объектов Azure
- Расширение очередей Azure
- Расширение таблиц Azure
- Расширение центров событий
- Расширение служебной шины
- Расширение сетки событий
- Расширение Azure Cosmos DB
- Расширение Azure SignalR
- поставщик хранилища Устойчивые функции
- Хранилище узлов функций
Необходимо создать назначение ролей, которое предоставляет доступ к контейнеру BLOB-объектов во время выполнения. Ролей управления, таких как Владелец, недостаточно. В следующей таблице показаны встроенные роли, которые рекомендуется использовать вместе с расширением BLOB-объекта службы хранилища при обычной работе. Приложению могут потребоваться дополнительные разрешения на основе написанного кода.
Тип привязки | Примеры встроенных ролей |
---|---|
Триггер | Владелец данных BLOB-объектов хранилища и участникданных очереди хранилища 1 Дополнительные разрешения также должны быть предоставлены подключению AzureWebJobsStorage.2 |
Входные привязки | читатель данных больших двоичных объектов хранилища. |
Выходные привязки | владелец данных BLOB-объектов хранилища; |
1 Триггер BLOB-объекта обрабатывает сбой при нескольких попытках и записывает подозрительные BLOB-объекты в очередь в учетной записи хранения, указанной в подключении.
2 Подключение AzureWebJobsStorage используется во внутренней логике для BLOB-объектов и очередей, которые обеспечивают работу триггера. Если он настроен на использование подключения на основе удостоверений, он нуждается в дополнительных разрешениях за пределами требования по умолчанию. Необходимые разрешения охватываются ролями владельца данных BLOB-объектов хранилища, участника очередей хранилища и участника учетной записи хранения. Для получения дополнительных сведений см. раздел Подключение к хранилищу узла с помощью удостоверения.
Общие свойства подключений на основе удостоверений
Подключение на основе удостоверений для службы Azure принимает следующие общие свойства, где <CONNECTION_NAME_PREFIX>
— это значение свойства connection
в определении триггера или привязки:
Свойство | Шаблон переменной среды | Description |
---|---|---|
Учетные данные маркера | <CONNECTION_NAME_PREFIX>__credential |
Определяет, как должен быть получен маркер для соединения. Этот параметр следует задать, managedidentity если развернутая функция Azure намерена использовать проверку подлинности управляемого удостоверения. Это значение допустимо только в том случае, если управляемое удостоверение доступно в среде размещения. |
Client ID | <CONNECTION_NAME_PREFIX>__clientId |
Если credential задано значение managedidentity , это свойство можно задать, чтобы указать назначаемое пользователем удостоверение, которое будет использоваться при получении маркера. Свойство принимает идентификатор клиента, соответствующий назначаемому пользователем удостоверению, которое назначено приложению. Недопустимо указать идентификатор ресурса и идентификатор клиента. Если это не указано, используется удостоверение, назначаемое системой. Это свойство используется по-разному в локальных сценариях разработки, если credential не следует задавать. |
ИД ресурса | <CONNECTION_NAME_PREFIX>__managedIdentityResourceId |
Если credential задано managedidentity значение, это свойство можно задать, чтобы указать идентификатор ресурса, который будет использоваться при получении маркера. Свойство принимает идентификатор ресурса, соответствующий идентификатору ресурса определяемого пользователем управляемого удостоверения. Недопустимо указать идентификатор ресурса и идентификатор клиента. Если ни указано, используется удостоверение, назначаемое системой. Это свойство используется по-разному в локальных сценариях разработки, если credential не следует задавать. |
Другие параметры могут поддерживаться для заданного типа подключения. Ознакомьтесь с документацией по компоненту, который делает подключение.
Локальная разработка с использованием подключений на основе удостоверений
Примечание.
Для локальной разработки с подключениями на основе удостоверений требуется версия 4.0.3904
Функции Azure Core Tools или более поздней версии.
При локальном запуске проекта функции в приведенной выше конфигурации среда выполнения будет использовать локальное удостоверение разработчика. Подключение пытается получить маркер из следующих расположений, упорядочение:
- локальный кэш, совместно используемый приложениями Майкрософт;
- контекст текущего пользователя в Visual Studio;
- контекст текущего пользователя в Visual Studio Code;
- контекст текущего пользователя в Azure CLI.
Если ни один из этих параметров не выполнен успешно, возникает ошибка.
Удостоверение может уже включать некоторые назначения ролей для ресурсов Azure, используемых для разработки, но эти роли могут не предоставлять необходимый доступ к данным. Ролей управления, таких как Владелец, недостаточно. Еще раз проверьте, какие разрешения необходимы для подключений для каждого компонента, и убедитесь, что они назначены вам.
В некоторых случаях может потребоваться указать другое удостоверение. Вы можете добавить свойства конфигурации для подключения, которое указывает на альтернативное удостоверение на основе идентификатора клиента и секрета клиента для субъекта-службы Microsoft Entra. Следующий параметр конфигурации не поддерживается при размещении в службе "Функции Azure". Чтобы использовать идентификатор и секрет на локальном компьютере, определите подключение со следующими дополнительными свойствами:
Свойство | Шаблон переменной среды | Description |
---|---|---|
Идентификатор клиента | <CONNECTION_NAME_PREFIX>__tenantId |
Идентификатор клиента Microsoft Entra (каталог). |
Client ID | <CONNECTION_NAME_PREFIX>__clientId |
Идентификатор клиента (приложения) для регистрации приложения в клиенте. |
Секрет клиента | <CONNECTION_NAME_PREFIX>__clientSecret |
Секрет клиента, созданный для регистрации приложения. |
Ниже приведен пример свойств, необходимых local.settings.json
для подключения на основе удостоверений к BLOB-объектам Azure:
{
"IsEncrypted": false,
"Values": {
"<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
"<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
"<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
"<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
"<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
}
}
Подключение к хранилищу узла с помощью удостоверения
Узел Функции Azure использует набор AzureWebJobsStorage
подключений к хранилищу для включения основных действий, таких как координация одноэлементного выполнения триггеров таймера и хранилища ключей приложения по умолчанию. Это подключение также можно настроить для использования удостоверения.
Внимание
Другие компоненты в Функциях зависят от AzureWebJobsStorage
поведения по умолчанию. Их не следует переводить на использование подключений на основе удостоверений, если вы используете более старые версии расширений, которые не поддерживают данный тип подключения, включая триггеры и привязки для BLOB-объектов Azure, центры событий и устойчивые функции. Аналогичным образом для артефактов развертывания используется AzureWebJobsStorage
, когда используется серверная сборка в потреблении Linux и, если вы включите этот параметр, вам потребуется выполнить развертывание с помощью внешнего пакета развертывания.
Кроме того, приложение-функция может повторно использовать AzureWebJobsStorage
для других подключений к хранилищу в их триггерах, привязках и /или коде функции. Прежде чем переходить на удостоверение со строки подключения, убедитесь, что все сценарии использования AzureWebJobsStorage
поддерживают формат подключения на основе удостоверений.
Чтобы использовать подключение AzureWebJobsStorage
на основе удостоверений, настройте следующие параметры приложения:
Параметр | Description | Пример значения |
---|---|---|
AzureWebJobsStorage__blobServiceUri |
Универсальный код ресурса (URI) плоскости данных службы BLOB-объектов учетной записи хранения, использующей схему HTTPS. | https://<storage_account_name>.blob.core.windows.net |
AzureWebJobsStorage__queueServiceUri |
Универсальный код ресурса (URI) плоскости данных службы очередей учетной записи хранения, использующей схему HTTPS. | https://<storage_account_name>.queue.core.windows.net |
AzureWebJobsStorage__tableServiceUri |
Универсальный код ресурса (URI) плоскости данных службы таблиц учетной записи хранения, использующей схему HTTPS. | https://<storage_account_name>.table.core.windows.net |
Также можно задать общие свойства для подключений на основе удостоверений.
Если вы настраиваете AzureWebJobsStorage
учетную запись хранения, которая использует dns-суффикс по умолчанию и имя службы для глобальной среды Azure, https://<accountName>.[blob|queue|file|table].core.windows.net
вы можете вместо этого задать AzureWebJobsStorage__accountName
имя учетной записи хранения. Конечные точки для каждой службы хранения выводятся для этой учетной записи. Это не работает, если учетная запись хранения находится в суверенном облаке или имеет пользовательский DNS.
Параметр | Description | Пример значения |
---|---|---|
AzureWebJobsStorage__accountName |
Имя учетной записи хранения, допустимое только в том случае, если учетная запись не в суверенном облаке и не имеет настраиваемого DNS. Этот синтаксис уникален AzureWebJobsStorage и не может использоваться для других подключений на основе удостоверений. |
<storage_account_name> |
Вам потребуется создать назначение ролей, предоставляющее доступ к учетной записи хранения для "AzureWebJobsStorage" во время выполнения. Ролей управления, таких как Владелец, недостаточно. Роль владельца данных BLOB-объектов хранилища охватывает основные потребности хранилища узлов Функций. Среда выполнения должна иметь доступ для чтения и записи к BLOB-объектам и возможность создавать контейнеры. Несколько расширений используют это подключение в качестве расположения по умолчанию для BLOB-объектов, очередей и таблиц, и в этом случае могут возникать дополнительные требования, как указано в таблице ниже. При использовании AzureWebJobsStorage в других целях могут потребоваться дополнительные разрешения.
Расширение | Необходимые роли | Описание |
---|---|---|
Без расширения (только узел) | владелец данных BLOB-объектов хранилища; | Используется для общей координации, хранилище ключей по умолчанию |
BLOB-объекты Azure (только триггер) | Все из: Участник учетной записи хранения, Владелец данных BLOB-объектов хранилища, Участник для данных очереди хранилища |
Триггер BLOB-объектов использует очереди Azure во внутренней структуре и записывает команды для BLOB-объектов. Для них используется атрибут AzureWebJobsStorage независимо от подключения, настроенного для триггера. |
Центры событий Azure (только триггер) | (без изменения требований по умолчанию) владелец данных BLOB-объектов хранилища; |
Контрольные точки сохраняются в BLOB-объектах с помощью подключения AzureWebJobsStorage. |
Триггер по таймеру | (без изменения требований по умолчанию) владелец данных BLOB-объектов хранилища; |
Чтобы обеспечить одно выполнение для каждого события, блокировки берутся их BLOB-объектов с помощью подключения AzureWebJobsStorage. |
Устойчивые функции | Все из: Участник для данных BLOB-объектов хранилища, Участник для данных очереди хранилища, Участник данных таблицы хранилища |
Устойчивые функции использует BLOB-объекты, очереди и таблицы для координации функций действий и поддержания состояния оркестрации. По умолчанию для всех этих подключений используется подключение AzureWebJobsStorage, но в конфигурации расширения Устойчивые функции можно указать другое подключение. |
Создание отчетов о проблемах
Позиция | Description | Ссылка |
---|---|---|
Параметры выполнения | Сервер сценариев, триггеры и привязки, языковая поддержка | Сообщить о проблеме |
Шаблоны | Проблемы с кодом при использовании шаблона создания | Сообщить о проблеме |
Портал | Проблемы с пользовательским интерфейсом или при работе с ним | Сообщить о проблеме |
Репозитории с открытым кодом
Код для Функции Azure открытый код, и вы можете найти ключевые компоненты в этих репозиториях GitHub:
Следующие шаги
Дополнительные сведения см. на следующих ресурсах:
- сценарии Функции Azure
- Как программировать и тестировать функции Azure в локальной среде
- Best Practices for Azure Functions (Рекомендации по Функциям Azure)