Azure Functions PowerShell guia para desenvolvedores

Este artigo fornece detalhes sobre como escrever Azure Functions usando PowerShell.

Uma função PowerShell Azure (função) é representada como um script PowerShell que é executado quando é ativado. Cada script de função tem um arquivo relacionado function.json que define como a função se comporta, como ela é acionada e seus parâmetros de entrada e saída. Para saber mais, consulte Azure Functions gatilhos e conceitos de ligações.

Como outros tipos de funções, as function.json funções de script do PowerShell recebem parâmetros que correspondem aos nomes de todas as ligações de entrada definidas no arquivo. Também é passado um TriggerMetadata parâmetro que contém informações adicionais sobre o gatilho que iniciou a função.

Este artigo parte do princípio de que já leu o guia para desenvolvedores Azure Functions. Ele também pressupõe que você concluiu o início rápido do Functions para o PowerShell para criar sua primeira função do PowerShell.

Estrutura de pastas

A estrutura de pastas necessária para um projeto do PowerShell tem a seguinte aparência. Esse padrão pode ser alterado. Para obter mais informações, consulte a seção 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

Na raiz do projeto, há um arquivo compartilhado host.json que pode ser usado para configurar o aplicativo de função. Cada função tem uma pasta com seu próprio arquivo de código (.ps1) e arquivo de configuração de vinculação (function.json). O nome do diretório pai do arquivo function.json é sempre o nome da sua função.

Certas associações requerem a presença de um extensions.csproj arquivo. As extensões de ligação, necessárias na versão 2.x e versões posteriores do tempo de execução do Functions, são definidas no extensions.csproj arquivo, com os arquivos de biblioteca reais na bin pasta. Ao desenvolver localmente, você deve registrar extensões de vinculação. Quando desenvolve funções no portal Azure, este registo é feito por si.

Nos Aplicativos de Função do PowerShell, você pode, opcionalmente, ter um profile.ps1 que é executado quando um aplicativo de função começa a ser executado (caso contrário, conhecido como início a frio). Para obter mais informações, consulte Perfil do PowerShell.

Definindo um script do PowerShell como uma função

Por padrão, o tempo de execução do Functions procura a sua função no diretório run.ps1, onde o run.ps1 partilha o mesmo diretório pai que o seu correspondente function.json.

O seu script recebe vários argumentos na execução. Para manipular esses parâmetros, adicione um param bloco à parte superior do script, como no exemplo a seguir:

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

Parâmetro TriggerMetadata

O TriggerMetadata parâmetro é usado para fornecer informações adicionais sobre o gatilho. Esses metadados variam de binding para binding, mas todos eles contêm a propriedade sys que contém os dados seguintes.

$TriggerMetadata.sys

Cada tipo de gatilho tem um conjunto diferente de metadados. Por exemplo, o $TriggerMetadata for QueueTrigger contém o InsertionTime, Id, , DequeueCountentre outras coisas. Para obter mais informações sobre os metadados do gatilho de fila, vá para a documentação oficial dos gatilhos de fila. Verifica a documentação sobre os triggers com os quais estás a trabalhar para ver o que vem dentro dos metadados do trigger.

Ligações

No PowerShell, as associações são configuradas e definidas no function.json de uma função. As funções interagem com ligações de muitas maneiras.

Leitura de dados de gatilho e de entrada

As ligações de gatilho e entrada são lidas como parâmetros passados para sua função. As ligações de entrada têm um direction definido como in em function.json. A name propriedade definida em function.json é o nome do parâmetro, no bloco param. Como o PowerShell usa parâmetros nomeados para vinculação, a ordem dos parâmetros não importa. No entanto, é uma prática recomendada seguir a ordem das ligações definidas no function.json.

param($MyFirstInputBinding, $MySecondInputBinding)

Gravando dados de saída

Em funções, uma ligação de saída tem um direction definido como out no function.json. Você pode gravar em uma associação de saída usando o cmdlet (comando específico) Push-OutputBinding, que está disponível no ambiente de execução do Functions. Em todos os casos, a name propriedade da associação, conforme definida em function.json , corresponde ao Name parâmetro do Push-OutputBinding cmdlet.

O exemplo a seguir mostra como chamar Push-OutputBinding no seu script de função:

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

Você também pode passar um valor para uma vinculação específica pelo pipeline.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding comporta-se de forma diferente com base no valor especificado para -Name:

• Quando o nome especificado não pode ser resolvido para uma ligação de saída válida, um erro é gerado.

• Quando a associação de saída aceita uma coleção de valores, você pode chamar Push-OutputBinding repetidamente para enviar vários valores.

• Quando a ligação de saída só aceita um valor singleton, chamar Push-OutputBinding uma segunda vez gera um erro.

Sintaxe Push-OutputBinding

Os seguintes parâmetros são válidos para chamar Push-OutputBinding:

Os seguintes parâmetros comuns também são suportados:

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

Para obter mais informações, consulte Sobre CommonParameters.

Exemplo de Push-OutputBinding: Respostas HTTP

Um gatilho HTTP retorna uma resposta usando uma ligação de saída chamada response. No exemplo a seguir, a ligação de saída de response tem o valor de "output #1":

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

Como a saída é para HTTP, que aceita apenas um valor singleton, um erro é lançado quando Push-OutputBinding é chamado uma segunda vez.

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

Para saídas que aceitam apenas valores singleton, você pode usar o -Clobber parâmetro para substituir o valor antigo em vez de tentar adicionar a uma coleção. O exemplo a seguir pressupõe que você já tenha adicionado um valor. Ao usar -Clobber, a resposta do exemplo seguinte substitui o valor anterior por um valor de "saída #3":

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

Exemplo de Push-OutputBinding: Vinculação de saída de fila

Push-OutputBinding é utilizado para enviar dados para ligações de saída, como uma ligação de saída Azure Queue storage. No exemplo a seguir, a mensagem gravada na fila de mensagens tem um valor de "resultado #1":

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

A associação de saída para uma fila de armazenamento aceita vários valores de saída. Nesse caso, executar o exemplo abaixo após o primeiro grava na fila uma lista com dois itens: "output #1" e "output #2".

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

O exemplo a seguir, quando chamado após os dois anteriores, adiciona mais dois valores à coleção de saída:

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

Quando gravada na fila, a mensagem contém estes quatro valores: "output #1", "output #2", "output #3" e "output #4".

Cmdlet Get-OutputBinding

Você pode usar o Get-OutputBinding cmdlet para recuperar os valores atualmente definidos para suas associações de saída. Este cmdlet obtém uma tabela hash que contém os nomes das ligações de saída com os seus respetivos valores.

O exemplo a seguir usa Get-OutputBinding para retornar valores de vinculação atuais:

Get-OutputBinding

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

Get-OutputBinding também contém um parâmetro chamado -Name, que pode ser usado para filtrar a associação retornada, como no exemplo a seguir:

Get-OutputBinding -Name MyQ*

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

Os caracteres universais (*) são compatíveis com Get-OutputBinding.

Registo

O registo em funções do PowerShell funciona como o do log regular do PowerShell. Você pode usar os cmdlets de registo para gravar em cada fluxo de saída. Cada cmdlet mapeia para um nível de log usado pelo Functions.

Além destes cmdlets, tudo o que é enviado para o pipeline é redirecionado para o nível de log Information e exibido com a formatação padrão do PowerShell.

Configurar o nível de log do aplicativo de função

O Azure Functions permite definir o nível do limiar para facilitar o controlo da forma como o Functions escreve nos logs. Para definir o limite para todos os rastreamentos gravados no console, use a propriedade logging.logLevel.default no arquivo host.json. Esta definição aplica-se a todas as funções na sua aplicação de funções.

O exemplo a seguir define o limite para habilitar o log detalhado para todas as funções, mas define o limite para habilitar o log de depuração para uma função chamada MyFunction:

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

Para obter mais informações, consulte host.json referência.

Visualizando os logs

Se a sua Function App estiver a correr no Azure, pode usar o Application Insights para a monitorizar. Leia monitorização do Azure Functions para saber mais sobre visualização e consulta de logs de funções.

Se você estiver executando seu aplicativo de função localmente para desenvolvimento, registra o padrão no sistema de arquivos. Para ver os logs no console, defina a AZURE_FUNCTIONS_ENVIRONMENT variável de ambiente como Development antes de iniciar o aplicativo de função.

Tipos de gatilhos e ligações

Há muitos gatilhos e ligações disponíveis para você usar com seu aplicativo de função. Para obter a lista completa de gatilhos e associações, consulte Ligações suportadas.

Todos os gatilhos e ligações são representados no código como alguns tipos de dados reais:

• Tabela Hash
• cadeia (de caracteres)
• byte[]
• int
• duplo
• Contexto de Pedido HTTP
• HttpResponseContext

Os primeiros cinco tipos desta lista são tipos .NET padrão. Os dois últimos são usados apenas pelo gatilho HttpTrigger.

Cada parâmetro de vinculação em suas funções deve ser um desses tipos.

Gatilhos e associações HTTP

Os gatilhos HTTP e webhook e as ligações de saída HTTP usam objetos de solicitação e resposta para representar as mensagens HTTP.

Objeto de solicitação

O objeto de solicitação que é passado para o script é do tipo HttpRequestContext, que tem as seguintes propriedades:

^* As chaves Dictionary<string,string> não diferenciam entre maiúsculas e minúsculas.

Objeto de resposta

O objeto de resposta que você deve enviar de volta é do tipo HttpResponseContext, que tem as seguintes propriedades:

Acesso ao pedido e à resposta

Quando você trabalha com gatilhos HTTP, você pode acessar a solicitação HTTP da mesma forma que faria com qualquer outra ligação de entrada. Está no bloco param.

Use um HttpResponseContext objeto para retornar uma resposta, conforme mostrado no exemplo a seguir:

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!"
})

O resultado da invocação desta função seria:

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

Conversão de tipos para triggers e bindings

Para determinadas associações, como a ligação blob, você pode especificar o tipo do parâmetro.

Por exemplo, para que os dados do armazenamento de Blob sejam fornecidos como uma cadeia de caracteres, adicione o seguinte tipo de conversão ao meu param bloco:

param([string] $myBlob)

Perfil do PowerShell

No PowerShell, há o conceito de um perfil do PowerShell. Se você não estiver familiarizado com perfis do PowerShell, consulte Sobre perfis.

No PowerShell Functions, o script de perfil é executado uma vez por instância de trabalho do PowerShell no aplicativo na primeira implantação e após estar inativo (arranque a frio). Quando a concorrência é habilitada ao definir o valor PSWorkerInProcConcurrencyUpperBound, o script de perfil é executado para cada espaço de execução criado.

Quando cria uma aplicação de funções usando ferramentas como Visual Studio Code e Azure Functions Core Tools, um profile.ps1 padrão é criado para si. O perfil padrão é mantido no repositório Core Tools GitHub e contém:

• Autenticação automática MSI no Azure.
• A capacidade de ativar os aliases do Azure PowerShell AzureRM se desejar.

Versões do PowerShell

A tabela seguinte mostra as versões PowerShell disponíveis para cada versão principal do runtime das Funções, e a versão .NET necessária:

Você pode ver a versão atual imprimindo $PSVersionTable a partir de qualquer função.

Para saber mais sobre a política de suporte do runtime do Azure Functions, consulte este artigo

Executando localmente numa versão específica

Ao executar funções do PowerShell localmente, deve adicionar a configuração "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4" ao array Values no arquivo local.setting.json na raiz do projeto. Quando executado localmente no PowerShell 7.4, seu arquivo de local.settings.json se parece com o exemplo a seguir:

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

Alterando a versão do PowerShell

Leve estas considerações em consideração antes de migrar seu aplicativo de função do PowerShell para o PowerShell 7.4:

• Como a migração pode introduzir alterações urgentes na sua aplicação, reveja este guia migração antes de atualizar a sua aplicação para o PowerShell 7.4.

• Certifique-se de que a sua aplicação de funções está a correr na versão mais recente do runtime de Funções no Azure, que é a versão 4.x. Para obter mais informações, consulte Ver a versão atual do runtime.

Use as etapas a seguir para alterar a versão do PowerShell usada pelo seu aplicativo de função. Pode realizar esta operação tanto no portal do Azure como usando o PowerShell.

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

O aplicativo de função é reiniciado depois que a alteração é feita na configuração.

Gestão de dependências

Gerir módulos no Azure Functions escritos em PowerShell pode ser abordado de duas formas: usando a funcionalidade de Dependências Geridas ou incluindo os módulos diretamente no conteúdo da sua aplicação. Cada método tem suas próprias vantagens, e escolher o certo depende de suas necessidades específicas.

Escolhendo a abordagem correta de gerenciamento de módulos

Por que usar o recurso Dependências gerenciadas?

• Instalação inicial simplificada: lida automaticamente com a instalação do módulo com base no seu requirements.psd1 arquivo.
• Atualizações automáticas: Os módulos são atualizados automaticamente, incluindo correções de segurança, sem necessidade de intervenção manual.

Por que incluir módulos no conteúdo do aplicativo?

• Sem dependência do PowerShell Gallery: Os módulos são incluídos na sua aplicação, eliminando dependências externas.
• Mais controlo: Evita o risco de regressões causadas por atualizações automáticas, dando-lhe controlo total sobre quais as versões do módulo que são utilizadas.
• Compatibilidade: Funciona no Flex Consumption e é recomendado para outras SKUs Linux.

Funcionalidade de Dependências Geridas

A funcionalidade de Dependências Geridas permite-Azure Functions descarregar e gerir automaticamente módulos PowerShell especificados no ficheiro requirements.psd1. Esse recurso é habilitado por padrão em novos aplicativos de função do PowerShell.

Configuração do requirements.psd1

Para usar Dependências Gerenciadas em Funções Azure com PowerShell, é necessário configurar um ficheiro requirements.psd1. Este ficheiro especifica os módulos que a sua função necessita e Azure Functions descarrega e atualiza automaticamente esses módulos para garantir que o seu ambiente se mantém up-todata.

Veja como instalar e configurar o requirements.psd1 arquivo:

1. Cria um ficheiro requirements.psd1 na diretório raiz da tua Azure Função, caso ainda não exista.
2. Defina os módulos e suas versões em uma estrutura de dados do PowerShell.

Ficheiro requirements.psd1 de exemplo:

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

Incluindo módulos no conteúdo do aplicativo

Para ter mais controle sobre as versões do módulo e evitar dependências de recursos externos, você pode incluir módulos diretamente no conteúdo do aplicativo de função.

Para incluir módulos personalizados:

1. Crie uma Modules pasta na raiz do seu aplicativo de função.

   mkdir ./Modules
   

2. Copie módulos para a Modules pasta usando um dos seguintes métodos:

   • Se os módulos já estiverem disponíveis localmente:

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

   • Usando Save-Module para recuperar a partir do PowerShell Gallery:

     Save-Module -Name MyCustomModule -Path ./Modules
     

   • Usando Save-PSResource a partir do PSResourceGet módulo:

     Save-PSResource -Name MyCustomModule -Path ./Modules
     

Seu aplicativo de função deve ter a seguinte estrutura:

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

Quando inicia a sua app de funções, o trabalhador de linguagem do PowerShell adiciona esta pasta Modules à $env:PSModulePath de modo que possa confiar no carregamento automático de módulos tal como faria num script normal do PowerShell.

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

Solução de problemas de dependências gerenciadas

Habilitando dependências gerenciadas

Para que as Dependências Gerenciadas funcionem, o recurso deve ser habilitado em host.json:

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

Versões específicas de destino

Ao direcionar versões específicas do módulo, é importante seguir as duas etapas a seguir para garantir que a versão correta do módulo seja carregada:

1. Especifique a versão do módulo em requirements.psd1:

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

2. Adicione uma instrução import a profile.ps1:

   Import-Module Az.Accounts -RequiredVersion '1.9.5'
   

Seguir estas etapas garante que a versão especificada seja carregada quando a função for iniciada.

Configurar definições específicas de intervalo de dependência gerenciada

Você pode configurar como as Dependências Gerenciadas são baixadas e instaladas usando as seguintes configurações de aplicativo:

Considerações sobre gerenciamento de dependência

• Acesso à Internet: as dependências geridas exigem acesso ao https://www.powershellgallery.com para baixar módulos. Certifique-se de que seu ambiente permita esse acesso, incluindo a modificação de regras de firewall/VNet conforme necessário. Os endpoints necessários são descritos em Cmdlets de resolução de problemas. Esses endereços podem ser adicionados à lista de autorização, conforme necessário.
• Aceitação de licença: Dependências gerenciadas não suporta módulos que exigem aceitação de licença.
• Flex Consumption Plan: O recurso Dependências Geridas não é compatível no plano Flex Consumption. Em vez disso, use módulos personalizados.
• Locais dos módulos: No computador local, os módulos geralmente são instalados em uma das pastas disponíveis globalmente no .$env:PSModulePath Quando a correr em Azure, o $env:PSModulePath para uma aplicação de funções PowerShell difere do $env:PSModulePath num script PowerShell normal e contém tanto a pasta Modules carregada com o conteúdo da tua aplicação como uma localização separada gerida pelas Dependências Geridas.

Variáveis de ambiente

Em Funções, as configurações do aplicativo, como cadeias de conexão de serviço, são expostas como variáveis de ambiente durante a execução. Você pode aceder a estas configurações usando $env:NAME_OF_ENV_VAR, conforme mostrado no exemplo a seguir.

param($myTimer)

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

Há várias maneiras de adicionar, atualizar e excluir as configurações do aplicativo de função:

• No portal do Azure
• Usando o Azure CLI
• Usando Azure PowerShell

As alterações nas configurações do aplicativo de função exigem que seu aplicativo de função seja reiniciado.

Quando executado localmente, as configurações do aplicativo são lidas a partir do arquivo de projeto local.settings.json .

Concorrência

Por padrão, o tempo de execução do Functions PowerShell só pode processar uma invocação de uma função de cada vez. No entanto, esse nível de simultaneidade pode não ser suficiente nas seguintes situações:

• Quando você está tentando lidar com um grande número de invocações ao mesmo tempo.
• Quando você tem funções que invocam outras funções dentro do mesmo aplicativo de função.

Existem alguns modelos de simultaneidade que você pode explorar dependendo do tipo de carga de trabalho:

• Aumente FUNCTIONS_WORKER_PROCESS_COUNT. Aumentar essa configuração permite manipular invocações de função em vários processos dentro da mesma instância, o que introduz determinada sobrecarga de CPU e memória. Em geral, as funções ligadas a E/S não sofrem com essa sobrecarga. Para funções ligadas à CPU, o impacto pode ser significativo.

• Aumente o valor da configuração do PSWorkerInProcConcurrencyUpperBound aplicativo. Aumentar essa configuração permite criar vários espaços de execução dentro do mesmo processo, o que reduz significativamente a sobrecarga de CPU e memória.

Você define essas variáveis de ambiente nas configurações do aplicativo de função.

Dependendo do seu caso de uso, o Durable Functions pode melhorar significativamente a escalabilidade. Para saber mais, consulte os padrões de aplicação do Durable Functions.

Considerações sobre o uso da simultaneidade

O PowerShell é uma linguagem de script monothreaded por padrão. No entanto, a simultaneidade pode ser adicionada usando vários espaços de execução do PowerShell no mesmo processo. O número de espaços de execução criados e, portanto, o número de threads simultâneos por trabalhador, é limitado pela configuração do PSWorkerInProcConcurrencyUpperBound aplicativo. Por padrão, o número de espaços de execução é definido como 1.000 na versão 4.x do tempo de execução do Functions. Nas versões 3.x e inferiores, o número máximo de espaços de execução é definido como 1. A taxa de transferência do seu aplicativo de função é afetada pela quantidade de CPU e memória disponível no plano selecionado.

Azure PowerShell utiliza alguns contextos e estados nível de processo para ajudar a evitar tipagem excessiva. No entanto, se você ativar a simultaneidade em seu aplicativo de função e invocar ações que mudam de estado, você pode acabar com condições de corrida. Essas condições de corrida são difíceis de depurar porque uma invocação depende de uma determinada condição e a outra invocação altera o estado.

Há um valor imenso na execução paralela com o Azure PowerShell, uma vez que algumas operações podem demorar um tempo considerável. No entanto, deve proceder com precaução. Se você suspeitar que está enfrentando uma condição de corrida, defina a configuração do aplicativo PSWorkerInProcConcurrencyUpperBound como 1 e, em vez disso, use o isolamento de nível de processo do trabalhador de idioma para simultaneidade.

Configurar função scriptFile

Por padrão, uma função do PowerShell é executada a partir de run.ps1, um arquivo que compartilha o mesmo diretório pai que seu diretório correspondente function.json.

A scriptFile propriedade no function.json pode ser usada para obter uma estrutura de pastas que se parece com o exemplo a seguir:

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

Nesse caso, o function.json for myFunction inclui uma scriptFile propriedade que faz referência ao arquivo com a função exportada a ser executada.

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

Usar módulos do PowerShell configurando um entryPoint

As funções do PowerShell neste artigo são mostradas com o arquivo de script padrão run.ps1 gerado pelos modelos. No entanto, você também pode incluir suas funções nos módulos do PowerShell. Você pode fazer referência ao seu código de função específico no módulo usando os campos scriptFile e entryPoint no arquivo de configuração function.json.

Nesse caso, entryPoint é o nome de uma função ou cmdlet no módulo do PowerShell referenciado em scriptFile.

Considere a seguinte estrutura de pastas:

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

Onde PSFunction.psm1 contém:

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

Neste exemplo, a configuração para myFunction inclui uma propriedade scriptFile que faz referência a PSFunction.psm1, que é um módulo do PowerShell em outra pasta. A entryPoint propriedade faz referência à Invoke-PSTestFunc função, que é o ponto de entrada no módulo.

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

Com essa configuração, o Invoke-PSTestFunc é executado exatamente como faria run.ps1 .

Considerações para funções do PowerShell

Ao trabalhar com funções do PowerShell, esteja ciente das considerações nas seções a seguir.

Arranque a frio

Ao desenvolver Azure Functions no modelo de alojamento sem servidor (serverless), os arranques a frio são uma realidade. Início a frio refere-se ao período de tempo que leva para que seu aplicativo de função comece a ser executado para processar uma solicitação. O arranque a frio acontece com mais frequência no plano de Consumo porque a sua aplicação funcional é encerrada durante os períodos de inatividade.

Evite usar o Install-Module

Executar Install-Module no seu script de função em cada invocação pode causar problemas de desempenho. Em vez disso, use Save-Module ou Save-PSResource antes de publicar seu aplicativo de função para agrupar os módulos necessários.

Para obter mais informações, consulte Gerenciamento de dependência.

Próximos passos

Para obter mais informações, consulte os seguintes recursos:

• Melhores práticas para Azure Functions
• Azure Functions Referência do Desenvolvedor
• Azure Functions triggers e ligações