Поделиться через

руководство разработчика PowerShell Azure Functions

В этой статье содержатся сведения о том, как писать Azure Functions с помощью PowerShell.

Функция PowerShell Azure (функция) представлена как скрипт PowerShell, который выполняется при активации. Каждый сценарий функции имеет связанный файл function.json, который определяет ее работу, например порядок запуска функции, ее входные и выходные параметры. Дополнительные сведения см. тут: Концепции триггеров и привязок Azure Functions.

Функции скриптов PowerShell, как и другие типы функций, принимают параметры, соответствующие именам всех входных привязок, определенных в файле function.json. Также передается параметр TriggerMetadata, содержащий дополнительные сведения о триггере, который запустил функцию.

В этой статье предполагается, что вы уже ознакомились с руководством разработчика Azure Functions. Кроме того, предполагается, что вы выполнили краткое руководство по функциям для PowerShell, чтобы создать свою первую функцию PowerShell.

Структура папок

Необходимая структура папок для проекта PowerShell выглядит следующим образом. Это значение по умолчанию можно изменить. Дополнительные сведения см. в разделе scriptFile .

PSFunctionApp
 | - MyFirstFunction
 | | - run.ps1
 | | - function.json
 | - MySecondFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - myFirstHelperModule
 | | | - myFirstHelperModule.psd1
 | | | - myFirstHelperModule.psm1
 | | - mySecondHelperModule
 | | | - mySecondHelperModule.psd1
 | | | - mySecondHelperModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1
 | - profile.ps1
 | - extensions.csproj
 | - bin

В корневой папке проекта существует общий файл host.json, который может использоваться для настройки приложения-функции. У каждой функции есть папка с собственным файлом кода (ps1) и файлом конфигурации привязки (function.json). Имя родительского каталога файла function.json всегда является именем этой функции.

Для определенных привязок требуется наличие файла extensions.csproj. Расширения привязки, необходимые в версии 2.x и более поздних среды выполнения функций, определены в файле extensions.csproj с фактическими файлами библиотеки в папке bin. При локальной разработке необходимо зарегистрировать расширения привязки. При разработке функций на портале Azure эта регистрация выполняется для вас.

В приложениях-функциях PowerShell при желании может быть добавлено profile.ps1, которое запускается при старте приложения-функции (в противном случае — холодный запуск). Дополнительные сведения см. в статье Профиль PowerShell.

Определение скрипта PowerShell как функции

По умолчанию среда выполнения Функций ищет функцию в файле run.ps1, где run.ps1 использует тот же родительский каталог, что и соответствующий файл function.json.

Скрипту передаются несколько аргументов при выполнении. Для обработки этих параметров добавьте блок param в начало скрипта, как в следующем примере.

# $TriggerMetadata is optional here. If you don't need it, you can safely remove it from the param block
param($MyFirstInputBinding, $MySecondInputBinding, $TriggerMetadata)

Параметр TriggerMetadata

Параметр TriggerMetadata используется для предоставления дополнительных сведений о триггере. Эти метаданные зависят от привязки к привязке, но все они содержат sys свойство, содержащее следующие данные:

$TriggerMetadata.sys
Свойство Описание Тип
UtcNow Время активации функции (в формате UTC) Дата/время
ИмяМетода Имя активированной функции строка
РандГуид Уникальный GUID для этого выполнения функции строка

Каждый тип триггера имеет свой набор метаданных. Например, $TriggerMetadata для QueueTrigger, помимо прочего, содержит InsertionTime, Id и DequeueCount. Дополнительные сведения о метаданных триггера очереди см. в официальной документации по триггерам очереди. Чтобы узнать, что входит в метаданные триггера, ознакомьтесь с документацией по триггерам, с которыми вы работаете.

Привязки

В PowerShell привязки настраиваются и определяются в файле function.json функции. Функции взаимодействуют с привязками различными способами.

Чтение триггера и входных данных

Триггеры и входные привязки считываются как параметры, передаваемые в вашу функцию. Для входных привязок в файле function.json значению direction присваивается значение in. Свойство name, определенное в файле function.json, является именем параметра в блоке param. Поскольку в PowerShell для привязки используются именованные параметры, порядок параметров не имеет значения. При этом рекомендуется следовать порядку привязок, определенному в файле function.json.

param($MyFirstInputBinding, $MySecondInputBinding)

запись выходных данных;

В Функциях в файле function.json параметру direction присваивается значение out. Для записи данных в выходную привязку можно использовать командлет Push-OutputBinding, доступный в среде выполнения Функций. Во любом случае свойство name привязки, определенное в файле function.json, соответствует параметру Name командлета Push-OutputBinding.

В следующем примере показано, как вызвать Push-OutputBinding в скрипте функции:

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

Значение для конкретной привязки можно также передать через конвейер.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Командлет Push-OutputBinding ведет себя по-разному в зависимости от того, какое значение указано для параметра -Name.

  • Если указанное имя не может быть разрешено для допустимой выходной привязки, возникает ошибка.

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

  • Если выходная привязка принимает только отдельное значение, вызов Push-OutputBinding во второй раз приведет к ошибке.

Синтаксис Push-OutputBinding

Для вызова Push-OutputBinding допустимы следующие параметры.

Имя. Тип Позиция Описание
-Name Строка 1 Имя выходной привязки, которую вам нужно задать.
-Value Объект 2 Значение выходной привязки, которую вам нужно задать, принимается из конвейера ByValue.
-Clobber ПараметрПереключателя Назван (Необязательно.) Если указано, это приводит к установке значения для заданной выходной привязки.

Также поддерживаются следующие общие параметры.

  • Verbose
  • Debug
  • ErrorAction
  • ErrorVariable
  • WarningAction
  • WarningVariable
  • OutBuffer
  • PipelineVariable
  • OutVariable

Дополнительные сведения см. в статье Об общих параметрах.

Пример команды Push-OutputBinding: HTTP-ответы

Триггер HTTP возвращает ответ, используя выходную привязку с именем response. В следующем примере выходная привязка response имеет значение output #1.

Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
StatusCode = [System.Net.HttpStatusCode]::OK
Body = "output #1"
})

Поскольку выходные данные передаются в HTTP, который принимает только одно значение, при втором вызове Push-OutputBinding возникает ошибка.

Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
StatusCode = [System.Net.HttpStatusCode]::OK
Body = "output #2"
})

Для выходных данных, которые принимают только отдельные значения, можно использовать переопределение старого значения с помощью параметра -Clobber, а не пытаться добавить его в коллекцию. В следующем примере предполагается, что вы уже добавили значение. При использовании параметра -Clobber ответ из следующего примера переопределяет существующее значение и возвращает значение output #3.

Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
StatusCode = [System.Net.HttpStatusCode]::OK
Body = "output #3"
}) -Clobber

Пример использования Push-OutputBinding: привязка выходных данных к очереди

Push-OutputBinding используется для отправки данных в привязки для вывода, такие как привязка к выходной очереди хранилища Azure. В следующем примере сообщение, которое записывается в очередь, имеет значение output #1.

Push-OutputBinding -Name outQueue -Value "output #1"

Выходная привязка для очереди хранилища принимает несколько выходных значений. В этом случае, если вызывать следующий пример после того, как в очередь внесена первая запись, в ней появятся два элемента: "output #1" и "output #2".

Push-OutputBinding -Name outQueue -Value "output #2"

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

Push-OutputBinding -Name outQueue -Value @("output #3", "output #4")

При записи в очередь сообщение содержит следующие четыре значения: output #1, output #2, output #3 и output #4.

Командлет Get-OutputBinding

Командлет Get-OutputBinding можно использовать для получения значений, установленных для ваших выходных привязок. Этот командлет извлекает хэш-таблицу, содержащую имена выходных привязок с соответствующими значениями.

В следующем примере используется Get-OutputBinding для возврата текущих значений привязки:

Get-OutputBinding

Name                           Value
----                           -----
MyQueue                        myData
MyOtherQueue                   myData

Командлет Get-OutputBinding также содержит параметр с именем -Name, который можно использовать для фильтрования возвращаемой привязки, как показано в следующем примере.

Get-OutputBinding -Name MyQ*

Name                           Value
----                           -----
MyQueue                        myData

В Get-OutputBinding поддерживается использование подстановочных знаков (*).

Ведение журнала

Ведение журналов в функциях PowerShell работает так же, как и обычное ведение журналов в PowerShell. Командлеты ведения журнала можно использовать для записи данных в каждый выходной поток. Каждый командлет сопоставляется с уровнем ведения журнала, который используется Функциями.

Уровень ведения журнала функций Командлет логирования
Ошибка Write-Error
Предупреждение Write-Warning
Информация Write-Information
Write-Host
Write-Output
Записывает на уровень ведения журнала Information.
Отладка Write-Debug
Трассировка Write-Progress
Write-Verbose

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

Внимание

Использование командлетов Write-Verbose или Write-Debug недостаточно для включения подробного и отладочного логирования. Кроме того, необходимо настроить пороговое значение для уровня ведения журнала, которое объявляет, какой уровень журналов вас интересует. Дополнительные сведения см. в разделе Настройка уровня ведения журнала для приложения-функции.

Настройка уровня ведения журнала для приложения-функции

Azure Functions позволяет определить пороговый уровень, чтобы упростить управление способом записи функций в журналы. Чтобы задать пороговое значение для всех трассировок, которые записываются в консоль, используйте свойство logging.logLevel.default в файле host.json. Этот параметр применяется ко всем функциям в функциональном приложении.

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

{
    "logging": {
        "logLevel": {
            "Function.MyFunction": "Debug",
            "default": "Trace"
        }
    }
}

Дополнительные сведения см. в справочной статье о host.json.

Просмотр журналов

Если приложение-функция работает в Azure, вы можете использовать Application Insights для его мониторинга. Ознакомьтесь с monitoring Azure Functions чтобы узнать больше о просмотре и запросе журналов функций.

Если вы запускаете Function App локально для разработки, журналы по умолчанию ведутся в файловой системе. Для просмотра журналов в консоли задайте для переменной среды AZURE_FUNCTIONS_ENVIRONMENT значение Development, прежде чем запускать приложение-функцию.

Типы триггеров и привязок

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

Все триггеры и привязки представлены в коде как несколько реальных типов данных.

  • Хэш-таблица
  • строка
  • байт[]
  • INT
  • двойной
  • Контекст HTTP-запроса
  • HttpResponseContext

Первые пять типов в этом списке являются стандартными .NET типами. Последние два использует только триггер HttpTrigger.

Каждый параметр привязки в ваших функциях должен относиться к одному из этих типов.

Триггеры и привязки HTTP

Триггеры HTTP и вебхуков, а также привязки вывода HTTP используют объекты запроса и ответа для представления обмена сообщениями HTTP.

Объект запроса

Объект запроса, передаваемый в скрипт, имеет тип HttpRequestContext, имеющий следующие свойства:

Свойство Описание Тип
Body Объект, содержащий текст запроса. Свойство Body сериализуется в тип, оптимальный для данных. Например, если данные имеют формат JSON, они передаются в виде хэш-таблицы. Если данные являются строкой, они передаются как строка. объект
Headers Словарь, содержащий заголовки запросов. Словарь<строка, строка>*
Method Метод HTTP, используемый для запроса. строка
Params Объект, содержащий параметры маршрутизации запроса. Словарь<строка, строка>*
Query Объект, содержащий параметры запроса. Словарь<строка, строка>*
Url URL-адрес запроса. строка

* Все Dictionary<string,string> ключи регистр не учитывает.

Объект ответа

Объект ответа, который необходимо отправить обратно, имеет тип HttpResponseContext со следующими свойствами.

Свойство Описание Тип
Body Объект, содержащий текст ответа. объект
ContentType Быстрый способ установки типа содержимого для ответа. строка
Headers Объект, содержащий заголовок ответа. Словарь или хэш-таблица
StatusCode Код состояния HTTP для ответа. строка или целое число

Доступ к запросу и ответу

При работе с триггерами HTTP доступ к HTTP-запросу можно получить точно так же, как и с любой другой входной привязкой. Он находится в блоке param.

HttpResponseContext Используйте объект для возврата ответа, как показано в следующем примере:

function.json

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "anonymous"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

run.ps1

param($req, $TriggerMetadata)

$name = $req.Query.Name

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "Hello $name!"
})

Результат вызова этой функции будет выглядеть следующим образом.

irm http://localhost:5001?Name=Functions
Hello Functions!

Приведение типов триггеров и привязок

Для некоторых привязок, например связывания BLOB, можно указывать тип параметра.

Например, чтобы данные из Blob-хранилища передавались в качестве строки, добавьте следующее приведение типов в блок param.

param([string] $myBlob)

Профиль PowerShell

В PowerShell есть понятие профиля PowerShell. Если вы не знакомы с профилями PowerShell, см. статью О профилях.

В Функциях PowerShell скрипт профиля выполняется для каждого экземпляра рабочего процесса PowerShell в приложении по одному разу при первом развертывании и после пребывания в бездействии (холодный запуск). Если с помощью значения PSWorkerInProcConcurrencyUpperBound включен параллелизм, скрипт профиля выполняется для каждого созданного пространства выполнения.

При создании функции с использованием таких инструментов, как Visual Studio Code и Azure Functions Core Tools, для вас создается profile.ps1 по умолчанию. Профиль по умолчанию поддерживается в репозитории GitHub Core Tools и содержит:

  • Автоматическая проверка подлинности MSI для Azure.
  • Возможность включить псевдонимы PowerShell Azure PowerShell AzureRM, если вы хотите.

Версии PowerShell

В следующей таблице показаны версии PowerShell, доступные для каждой основной версии среды выполнения Функций, и требуемая версия .NET:

Версия функций Версия PowerShell версия .NET
4.x PowerShell 7.4 .NET 8
4.x PowerShell 7.2 (окончание поддержки) .NET 6

Чтобы выяснить текущую версию, распечатайте $PSVersionTable из любой функции.

Дополнительные сведения о политике поддержки среды выполнения Azure Functions см. в этой статье article

Примечание.

Поддержка PowerShell 7.2 в Azure Functions заканчивается 8 ноября 2024 г. При обновлении функций PowerShell 7.2 для запуска в PowerShell 7.4 может потребоваться устранить некоторые критические изменения. Следуйте инструкциям по миграции для обновления до PowerShell 7.4.

Локальное выполнение на определенной версии

При локальном запуске функций PowerShell необходимо добавить параметр "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"Values в массив в файл local.setting.json в корневом каталоге проекта. При локальном запуске в PowerShell 7.4 файл local.settings.json выглядит следующим образом:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "FUNCTIONS_WORKER_RUNTIME": "powershell",
    "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"
  }
}

Примечание.

В Функциях PowerShell значение "~7" для FUNCTIONS_WORKER_RUNTIME_VERSION относится к "7.0.x". Мы не обновляем автоматически приложения-функции PowerShell, имеющие "~7" до "7.4". Для приложений-функций PowerShell требуется, чтобы приложения указали основную и дополнительную версию, которую они хотят использовать. Необходимо упомянуть "7.4", если вы хотите нацелиться на "7.4.x"

Изменение версии PowerShell

Перед переносом приложения-функции PowerShell в PowerShell 7.4 следует учитывать следующие рекомендации.

  • Так как миграция может привести к критическим изменениям в приложении, ознакомьтесь с этим руководством по migration перед обновлением приложения до PowerShell 7.4.

  • Убедитесь, что приложение-функция работает в последней версии среды выполнения Функций в Azure, которая является версией 4.x. Дополнительные сведения см. в разделе "Просмотр текущей версии среды выполнения".

Чтобы изменить версию PowerShell, используемую приложением-функцией, выполните указанные ниже действия. Эту операцию можно выполнить на портале Azure или с помощью PowerShell.

  1. На портале Azure перейдите к функциональному приложению.

  2. В разделе Параметры выберите пункт Конфигурация. На вкладке Общие параметры найдите версию PowerShell.

    Снимок экрана: выбор версии PowerShell.

  3. Выберите нужную версию PowerShell Core и нажмите Сохранить. Когда появится предупреждение об ожидающем перезапуске, нажмите Продолжить. Приложение-функция перезапустится в выбранной версии PowerShell.

Примечание.

Поддержка PowerShell 7.4 для Azure Functions теперь общедоступна. Вы можете увидеть, что PowerShell 7.4 по-прежнему указан как предварительная версия на портале Azure, но это значение будет обновлено в ближайшее время, чтобы отразить статус общедоступной версии.

После внесения изменений в конфигурацию приложение-функция перезапустится.

Управление зависимостями

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

Выбор правильного подхода к управлению модулями

Почему используйте функцию управляемых зависимостей?

  • Упрощенная начальная установка: автоматически управляет установкой модуля на основе вашего файла requirements.psd1.
  • Автоматическое обновление: модули обновляются автоматически, включая исправления безопасности, не требуя вмешательства вручную.

Зачем включать модули в содержимое приложения?

  • Отсутствие зависимости от PowerShell Gallery: модули интегрированы в приложение, устраняя необходимость во внешних зависимостях.
  • Дополнительные средства управления: избегает риска регрессии, вызванной автоматическим обновлением, что дает полный контроль над используемыми версиями модулей.
  • Совместимость: работает с Flex Consumption и рекомендуется для других SKU Linux.

Функция управляемых зависимостей

Функция управляемых зависимостей позволяет Azure Functions автоматически загружать модули PowerShell и управлять ими, указанными в файле requirements.psd1. Эта функция включена по умолчанию в новых приложениях-функциях PowerShell.

Настройка requirements.psd1

Чтобы использовать управляемые зависимости в Azure Functions с PowerShell, необходимо настроить файл requirements.psd1. Этот файл указывает необходимые модули для вашей функции, и Azure Functions автоматически скачивает и обновляет эти модули, чтобы гарантировать, что среда остается актуальной.

Вот как установить и настроить файл requirements.psd1:

  1. Создайте файл requirements.psd1 в корневом каталоге функции Azure, если он еще не существует.
  2. Определите модули и их версии в структуре данных PowerShell.

Пример файла requirements.psd1:

@{
    'Az' = '9.*'  # Specifies the Az module and will use the latest version with major version 9
}

Включение модулей в содержимое приложения

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

Чтобы включить пользовательские модули, выполните следующие действия.

  1. Создайте папку Modules в корне приложения-функции.

    mkdir ./Modules

  2. Скопируйте модули в папку Modules с помощью одного из следующих методов:

    • Если модули уже доступны локально:

      Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse

    • Использование Save-Module для получения из PowerShell Gallery:

      Save-Module -Name MyCustomModule -Path ./Modules

    • Использование Save-PSResource из PSResourceGet модуля:

      Save-PSResource -Name MyCustomModule -Path ./Modules

Приложение-функция должно иметь следующую структуру:

PSFunctionApp
 | - MyFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - MyCustomModule
 | | - MyOtherCustomModule
 | | - MySpecialModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1

При запуске приложения-функции обработчик языка в PowerShell добавляет эту папку Modules в $env:PSModulePath, чтобы вы могли использовать автозагрузку модуля, как в обычном сценарии PowerShell.

Примечание.

Если ваше приложение функций находится под управлением системой контроля версий, убедитесь, что все содержимое в папке Modules, которую вы добавили, не исключается файлом .gitignore. Например, если один из ваших модулей содержит папку bin, которая исключается, необходимо изменить .gitignore, заменив bin на

**/bin/**
!Modules/**

Устранение неполадок управляемых зависимостей

Включение управляемых зависимостей

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

{
  "managedDependency": {
          "enabled": true
       }
}

Конкретные целевые версии

При выборе определенных версий модулей важно выполнить оба следующих шага, чтобы убедиться, что задана правильная версия модуля:

  1. Укажите версию модуля в requirements.psd1:

    @{
  'Az.Accounts' = '1.9.5'
}

  2. Добавление инструкции импорта в profile.ps1:

    Import-Module Az.Accounts -RequiredVersion '1.9.5'

После выполнения этих действий гарантируется, что указанная версия загружается при запуске функции.

Настройка определенных параметров интервала управляемой зависимости

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

Настройка Значение по умолчанию Описание
Максимальный период фонового обновления MD 7.00:00:00 (семь дней) Управляет периодом фонового обновления для приложений-функций PowerShell.
Период проверки нового снимка MD 01:00:00 (один час) Указывает, как часто рабочий процесс PowerShell проверяет наличие обновлений.
Минимальный период обновления фона MD 1.00:00:00 (один день) Минимальное время между проверками обновления.

Рекомендации по управлению зависимостями

  • Доступ в интернет: управляемым зависимостям требуется доступ к https://www.powershellgallery.com, чтобы скачивать модули. Убедитесь, что ваша среда разрешает этот доступ, включая изменение правил брандмауэра или виртуальной сети по мере необходимости. Необходимые конечные точки описаны в разделе "Устранение неполадок с командлетами". Эти конечные точки можно добавить в список разрешений по мере необходимости.
  • Принятие лицензий. Управляемые зависимости не поддерживают модули, требующие принятия лицензий.
  • План потребления Flex: функция управляемых зависимостей не поддерживается в плане потребления Flex. Вместо этого используйте пользовательские модули.
  • Расположения модулей: на локальном компьютере модули обычно устанавливаются в одну из глобальных доступных папок в вашей системе $env:PSModulePath. При запуске в Azure $env:PSModulePath для приложения-функции PowerShell отличается от $env:PSModulePath в обычном скрипте PowerShell и содержит папку Modules, загруженную вместе с содержимым вашего приложения, а также отдельное расположение, управляемое управляемыми зависимостями.

Переменные среды

В Функциях параметры приложения, такие как строки подключения службы, доступны в виде переменных среды во время выполнения. Вы можете получить доступ к этим параметрам с помощью $env:NAME_OF_ENV_VAR, как показано в следующем примере.:

param($myTimer)

Write-Host "PowerShell timer trigger function ran! $(Get-Date)"
Write-Host $env:AzureWebJobsStorage
Write-Host $env:WEBSITE_SITE_NAME

Существует несколько способов для добавления, обновления и удаления параметров приложения-функции.

Изменения в настройках функционального приложения требуют его перезапуска.

При локальном запуске приложения параметры считываются из файла проекта local.settings.json.

Конкурентность

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

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

В зависимости от типа рабочей нагрузки можно попробовать несколько моделей параллелизма.

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

  • Увеличьте значение параметра приложения PSWorkerInProcConcurrencyUpperBound. Увеличение этого параметра позволяет создавать несколько пространств выполнения в одном процессе, что значительно снижает нагрузку на ЦП и память.

Эти переменные среды задаются в параметрах приложения для приложения функции.

В зависимости от варианта использования Durable Functions может значительно повысить масштабируемость. Дополнительные сведения можно найти в шаблонах приложений Durable Functions.

Примечание.

Возможно, вы получите предупреждение "запросы помещаются в очередь из-за отсутствия доступных пространств выполнения". Это сообщение не является ошибкой. В сообщении говорится, что запросы помещаются в очередь. Они обрабатываются после завершения предыдущих запросов.

Рекомендации по использованию параллелизма

PowerShell является отдельным потоковым языком сценариев по умолчанию. При этом параллелизм можно добавить, используя несколько пространств выполнения PowerShell в одном и том же процессе. Количество созданных пространств выполнения и, следовательно, количество параллельных потоков на одну рабочую роль ограничивается параметром приложения PSWorkerInProcConcurrencyUpperBound. По умолчанию для количества пространств выполнения функций задано значение 1000 в версии 4.x среды выполнения Функций. В версиях 3.x и более ранних максимальное число пространств выполнения равно 1. Пропускная способность приложения-функции зависит от объема ЦП и памяти, доступной в выбранном плане.

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

Существует огромное значение параллелизма с Azure PowerShell, так как некоторые операции могут занять значительное время. При этом следует соблюдать осторожность. Если вы считаете, что у вас возникло конкурентное состояние, установите для параметра приложения PSWorkerInProcConcurrencyUpperBound значение 1 и используйте вместо этого изоляцию на уровне процесса обработчика языка для параллелизма.

Настройка scriptFile функции

По умолчанию функция PowerShell выполняется из файла run.ps1, расположенного в том же родительском каталоге, что и соответствующий файл function.json.

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

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.ps1

В этом случае function.json для myFunction включает свойство scriptFile, которое ссылается на файл с экспортируемой функцией для выполнения.

{
  "scriptFile": "../lib/PSFunction.ps1",
  "bindings": [
    // ...
  ]
}

Использование модулей PowerShell путем настройки entryPoint

Функции PowerShell в этой статье показаны с файлом скрипта по умолчанию run.ps1 , созданным шаблонами. Однако функции можно включить и в модулях PowerShell. Вы можете привести в модуле ссылку на код определенной функции, используя поля scriptFile и entryPoint в файле конфигурации function.json.

В этом случае entryPoint — это имя функции или командлета в модуле PowerShell, на которые ссылается scriptFile.

Рассмотрите следующую структуру папок.

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.psm1

PSFunction.psm1 содержит следующий код.

function Invoke-PSTestFunc {
    param($InputBinding, $TriggerMetadata)

    Push-OutputBinding -Name OutputBinding -Value "output"
}

Export-ModuleMember -Function "Invoke-PSTestFunc"

В этом примере конфигурация myFunction включает свойство scriptFile, которое ссылается на модуль PowerShell PSFunction.psm1 в другой папке. Свойство entryPoint ссылается на функцию Invoke-PSTestFunc, которая в этом модуле является точкой входа.

{
  "scriptFile": "../lib/PSFunction.psm1",
  "entryPoint": "Invoke-PSTestFunc",
  "bindings": [
    // ...
  ]
}

В этой конфигурации функция Invoke-PSTestFunc выполняется точно так же, как выполнялся бы скрипт run.ps1.

Рекомендации для функций PowerShell

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

Холодный запуск

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

Избегайте использования install-Module

Выполнение Install-Module в скрипте функции при каждом вызове может привести к проблемам с производительностью. Вместо этого используйте Save-Module или Save-PSResource перед публикацией приложения-функции для упаковки необходимых модулей.

Дополнительные сведения см. в разделе "Управление зависимостями".

Следующие шаги

Дополнительные сведения см. на следующих ресурсах:

  • Last updated on