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

Статья
01/23/2025

В этой статье рассказывается, как писать Функции 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.4	.NET 8
4.x	PowerShell 7.2 (окончание поддержки)	.NET 6

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

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

Примечание.

Поддержка PowerShell 7.2 в Функции Azure заканчивается 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 следует учитывать следующие рекомендации.

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

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

Портал
PowerShell

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

Примечание.

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

Выполните следующий скрипт, чтобы изменить версию PowerShell.

Set-AzResource -ResourceId "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<FUNCTION_APP>/config/web" -Properties @{  powerShellVersion  = '<VERSION>' } -Force -UsePatchSemantics

Замените значения параметров <SUBSCRIPTION_ID>, <RESOURCE_GROUP> и <FUNCTION_APP> на идентификатор своей подписки Azure, имя группы ресурсов и имя приложения-функции соответственно. Кроме того, замените <VERSION> 7.4на . Вы можете проверить обновленное значение параметра powerShellVersion в разделе Properties возвращаемой хэш-таблицы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создайте папку Modules в корне приложения-функции.
```
mkdir ./Modules
```
Скопируйте модули в папку Modules с помощью одного из следующих методов:
- Если модули уже доступны локально:
```
Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse
```
- Использование Save-Module для получения из коллекция PowerShell:
```
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.

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

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

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

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

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

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

Укажите версию модуля в requirements.psd1:
```
@{
  'Az.Accounts' = '1.9.5'
}
```
Добавление инструкции импорта в profile.ps1:
```
Import-Module Az.Accounts -RequiredVersion '1.9.5'
```

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

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

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

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

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

В Функциях параметры приложения, такие как строки подключения службы, доступны в виде переменных среды во время выполнения. Вы можете получить доступ к этим параметрам с помощью $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. Увеличение этого параметра позволяет создавать несколько пространств выполнения в одном процессе, что значительно снижает нагрузку на ЦП и память.

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

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

Примечание.

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

Настройка свойства 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 для Функций Azure.

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

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

Параметр TriggerMetadata

Привязки

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

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

Синтаксис командлета Push-OutputBinding

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

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

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

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

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

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

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

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

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

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

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

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

Профиль PowerShell

Версии PowerShell

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

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

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

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

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

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

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

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

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

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

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

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

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

Параллелизм

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

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

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

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

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

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

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

Обратная связь

Дополнительные ресурсы