Руководство разработчика PowerShell для Функций Azure.

  • Статья

В этой статье рассказывается, как писать Функции Azure с помощью PowerShell.

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

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

В этой статье предполагается, что вы уже прочли руководство для разработчиков по Функциям Azure. Кроме того, вы должны были пройти краткое руководство по функциям для 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) Дата/время
MethodName Имя активированной функции строка
RandGuid Уникальный 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 допустимы следующие параметры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS >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 позволяют определить пороговый уровень и, таким образом, упростить управление порядком записи данных в журналы Функций. Чтобы задать пороговое значение для всех трассировок, которые записываются в консоль, используйте свойство logging.logLevel.default в файле host.json. Этот параметр применяется ко всем функциям в приложении-функции.

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

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

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

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

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

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

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

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

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

  • Хэш-таблица
  • строка
  • byte[]
  • INT
  • двойной точности
  • HttpRequestContext
  • HttpResponseContext

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

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

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

Триггеры HTTP и webhook, а также привязки вывода 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!"
})

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

PS > 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 и содержит следующее:

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

Версии PowerShell

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

Версия службы "Функции" Версия PowerShell Версия .NET
4.x PowerShell 7.2 .NET 6

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

Дополнительные сведения о политике поддержки среды выполнения в Функциях Azure см. в этой статье.

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

Поддержка PowerShell 7.0 в Функции Azure закончилась 3 декабря 2022 г. Чтобы использовать PowerShell 7.2 при локальном запуске, необходимо добавить параметр "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.2"Values в массив в файл local.setting.json в корневом каталоге проекта. При локальном запуске в PowerShell 7.2 файл local.settings.json выглядит следующим образом:

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

Примечание.

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

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

Поддержка PowerShell 7.0 в Функции Azure закончилась 3 декабря 2022 г. Чтобы обновить приложение-функцию до PowerShell 7.2, убедитесь, что значение FUNCTIONS_EXTENSION_VERSION равно ~4. Инструкции см. в статье Просмотр и обновление текущей версии среды выполнения.

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

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

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

    image

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

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

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

Функции позволяют использовать коллекцию PowerShell для управления зависимостями. При включенном управлении зависимостями файл requirements.psd1 используется для автоматической загрузки необходимых модулей. Это поведение можно включить, задав для свойства managedDependency значение true в корневом каталоге файла host.json, как показано в следующем примере.

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

При создании нового проекта функций PowerShell управление зависимостями включается по умолчанию с включенным модулем Azure Az. Пока поддерживается максимум 10 модулей. Поддерживаемый синтаксис — MajorNumber.* или точная версия модуля, как показано в следующем примере файла requirements.psd1.

@{
	Az = '1.*'
	SqlServer = '21.1.18147'
}

При обновлении файла requirements.psd1 обновленные модули устанавливаются после перезагрузки.

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

Вы можете выбрать конкретную версию модуля в файле requirements.psd1. Например, если вы хотите использовать более раннюю версию Az.Accounts, чем указанная в модуле Az, выберите конкретную версию, как показано в следующем примере.

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

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

Import-Module Az.Accounts -RequiredVersion '1.9.5'

В этом случае при запуске функции сначала загружается более ранняя версия модуля Az.Account.

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

При использовании управления зависимостями учитывайте следующие моменты.

  • Управляемым зависимостям для скачивания модулей требуется доступ к веб-сайту https://www.powershellgallery.com. При локальном выполнении убедитесь в том, что среда выполнения может получить доступ к этому URL-адресу, добавив необходимые правила брандмауэра.

  • Управляемые зависимости пока не поддерживают модули, требующие, чтобы пользователь принял лицензию (либо приняв ее в интерактивном режиме, либо предоставив коммутатор -AcceptLicense при вызове командлета Install-Module).

Параметры приложения управления зависимостями

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

Параметр приложения-функции Значение по умолчанию Description
MDMaxBackgroundUpgradePeriod 7.00:00:00 (семь дней) Управляет периодом фонового обновления для приложений-функций PowerShell. Дополнительные сведения см. в разделе MDMaxBackgroundUpgradePeriod.
MDNewSnapshotCheckPeriod 01:00:00 (один час) Указывает, как часто каждый рабочий процесс PowerShell проверяет, установлены ли обновления для управляемых зависимостей. Дополнительные сведения см. в разделе MDNewSnapshotCheckPeriod.
MDMinBackgroundUpgradePeriod 1.00:00:00 (один день) Период времени с момента завершения одной до запуска другой проверки обновления. Дополнительные сведения см. в разделе MDMinBackgroundUpgradePeriod.

По сути, обновление приложения начинается в период MDMaxBackgroundUpgradePeriod, а процесс обновления завершается примерно в период MDNewSnapshotCheckPeriod.

Пользовательские модули

Использование собственных пользовательских модулей в Функциях Azure отличается от обычной работы в PowerShell.

На локальном компьютере модуль устанавливается в одну из глобально доступных папок в $env:PSModulePath. При выполнении в Azure у вас нет доступа к модулям, установленным на вашем компьютере. Это означает, что объект $env:PSModulePath для приложения-функции PowerShell отличается от объекта $env:PSModulePath в обычном скрипте PowerShell.

В Функциях PSModulePath содержит два пути:

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

Папка модулей на уровне приложения-функции

Чтобы использовать пользовательские модули, можно поместить модули, необходимые для выполнения функций, в папку Modules. Из этой папки модули автоматически становятся доступными для среды выполнения функций. Эти модули могут использоваться всеми функциями в приложении-функции.

Примечание.

Модули, указанные в файле requirements.psd1, загружаются и включаются в путь автоматически, поэтому включать их в папку модулей не нужно. Они хранятся локально в папке $env:LOCALAPPDATA/AzureFunctions и в папке /data/ManagedDependencies при выполнении в облаке.

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

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

В папке Modules у приложения-функции должна быть следующая структура папок.

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

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

Папка модулей на уровне обработчика языка

Обработчик языка в PowerShell обычно использует несколько модулей. Эти модули определяются в последней позиции PSModulePath.

Сейчас список модулей выглядит так.

  • Microsoft.PowerShell.Archive: модуль, используемый для работы с архивами, например .zip, .nupkg и другие.
  • ThreadJob: реализация API заданий 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. Это позволяет создавать несколько пространств выполнения в рамках одного процесса, что значительно сокращает нагрузку на ЦП и память.

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

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

Примечание.

Если появится сообщение "запросы помещаются в очередь из-за отсутствия доступных пространств выполнения", это не ошибка. Такое сообщение говорит о том, что запросы помещаются в очередь и будут обработаны после выполнения предыдущих запросов.

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

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

Объединение модулей вместо использования Install-Module

Ваш сценарий выполняется при каждом вызове. Старайтесь не использовать Install-Module в скрипте. Вместо этого используйте перед публикацией Save-Module, чтобы функция не тратила время на загрузку модуля. Если холодный запуск влияет на ваши функции, разверните приложение-функцию в плане службы приложений со значением Always on или в плане Premium.

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

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