Guía para desarrolladores de Azure Functions PowerShell

En este artículo se proporcionan detalles sobre cómo escribir Azure Functions mediante PowerShell.

Una función (función) Azure de PowerShell se representa como un script de PowerShell que se ejecuta cuando se desencadena. Cada script de función tiene un archivo relacionado donde se define el comportamiento de la función, como su desencadenamiento y sus parámetros de entrada y salida. Para obtener más información, consulte conceptos de desencadenadores y enlaces de Azure Functions.

Al igual que otros tipos de funciones, las funciones de script de PowerShell toman parámetros que coinciden con los nombres de todos los enlaces de entrada definidos en el archivo . También se pasa un parámetro que contiene información adicional sobre el desencadenador que inició la función.

En este artículo se supone que ya ha leído la guía para desarrolladores Azure Functions. También supone que ha completado el inicio rápido de Functions para PowerShell para crear la primera función de PowerShell.

Estructura de carpetas

La estructura de carpetas necesaria para un proyecto de PowerShell tiene el siguiente aspecto. Este valor predeterminado se puede cambiar. Para más información, consulte la sección 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

En la raíz del proyecto, hay un archivo compartido que se puede usar para configurar la aplicación de función. Cada función tiene una carpeta con su propio archivo de código (.ps1) y archivo de configuración de enlace (). El nombre del directorio primario del archivo function.json es siempre es el nombre de la función.

Determinados enlaces requieren la presencia de un archivo . Las extensiones de enlace necesarias en la versión 2.x y posteriores del entorno en tiempo de ejecución de Functions se definen en el archivo , con los archivos de biblioteca reales de la carpeta . Al desarrollar de forma local, debe registrar las extensiones de enlace. Al desarrollar funciones en el portal de Azure, este registro se realiza por usted.

En PowerShell Function Apps, es posible que tenga opcionalmente un que se ejecute cuando una aplicación de funciones empiece a ejecutarse (de lo contrario, se conoce como un inicio en frío). Para más información, consulte el Perfil de PowerShell.

Definición de un script de PowerShell como función

De forma predeterminada, el tiempo de ejecución de Functions busca la función en , donde comparte el mismo directorio primario que su correspondiente.

Varios argumentos se pasan al script durante la ejecución. Para controlar estos parámetros, agregue un bloque a la parte superior del script como en el siguiente ejemplo:

# $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

El parámetro se usa para proporcionar información adicional acerca del desencadenador. Estos metadatos varían de un enlace a otro, pero todos ellos contienen una propiedad con los siguientes datos:

$TriggerMetadata.sys

Cada tipo de desencadenador tiene un conjunto diferente de metadatos. Por ejemplo, para contiene , y , entre otras cosas. Para más información sobre los metadatos del desencadenador de cola, vaya a la documentación oficial de los desencadenadores de cola. Consulte la documentación sobre los desencadenadores con los que está trabajando para ver lo que está incluido en los metadatos de desencadenador.

Enlaces

En PowerShell, los enlaces se configuran y definen en el archivo function.json de una función. Las funciones interactúan con enlaces de muchas maneras.

Lectura de datos del desencadenador y de entrada

Los desencadenadores y los enlaces de entrada se leen como parámetros que se pasan a la función. Los enlaces de entrada tienen un establecido en en function.json. La propiedad definida en es el nombre del parámetro, en el bloque . Dado que PowerShell utiliza parámetros con nombre para el enlace, no importa el orden de estos. Sin embargo, es un procedimiento recomendado seguir el orden de los enlaces definidos en el archivo .

param($MyFirstInputBinding, $MySecondInputBinding)

Escritura de datos de salida

En Functions, un enlace de salida tiene un establecido en en el archivo function.json. Puede escribir en un enlace de salida mediante el cmdlet , disponible para Functions Runtime. En cualquier caso, la propiedad del enlace tal como se define en corresponde al parámetro del cmdlet .

En el ejemplo siguiente se muestra cómo llamar a en el script de la función:

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

También puede pasar un valor para un enlace específico mediante la canalización.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

se comporta de forma distinta según el valor especificado para :

• Cuando no se pueda resolver el nombre especificado en un enlace de salida válido, se producirá un error.

• Cuando el enlace de salida acepta una colección de valores, puede llamar a varias veces para insertar varios valores.

• Cuando el enlace de salida solo acepta un valor singleton, volver a llamar a produce un error.

Sintaxis de Push-OutputBinding

Los siguientes son parámetros válidos para llamar a :

También se admiten los siguientes parámetros habituales:

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

Para más información, consulte About Common Parameters (Acerca de los parámetros habituales).

Ejemplo de Push-OutputBinding: respuestas HTTP

Un desencadenador HTTP devuelve una respuesta con un enlace de salida denominado . En el siguiente ejemplo, el enlace de salida de tiene el valor de "output #1":

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

Dado que la salida es HTTP, que acepta solo un valor singleton, al volver a llamar a se produce un error.

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

Para las salidas que solo aceptan valores singleton, puede usar el parámetro para invalidar el antiguo valor en lugar de intentar agregarlo a una colección. En el siguiente ejemplo se da por supuesto que ya ha agregado un valor. Mediante el uso de , la respuesta de ejemplo siguiente invalida el valor existente para devolver un valor de "output #3":

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

Ejemplo de Push-OutputBinding: enlace de salida de cola

Push-OutputBinding se usa para enviar datos a enlaces de salida, como un enlace de salida de Azure Queue Storage. En el siguiente ejemplo, el mensaje que se escribe en la cola tiene un valor de "output #1":

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

El enlace de salida para una cola de Storage acepta varios valores de salida. En este caso, llamar al siguiente ejemplo después del primero hace que se escriba en la cola una lista con dos elementos: "output #1" y "output #2".

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

Cuando se llama al siguiente ejemplo después de los dos anteriores, se agregan dos valores más a la colección de salida:

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

Cuando se escribe en la cola, el mensaje contiene estos cuatro valores: "output #1", "output #2", "output #3" y "output #4".

Cmdlet Get-OutputBinding

Puede usar el cmdlet para recuperar los valores establecidos actualmente para los enlaces de salida. Este cmdlet recupera una tabla hash que contiene los nombres de los enlaces de salida con sus respectivos valores.

En el ejemplo siguiente se usa para devolver valores de enlace actuales:

Get-OutputBinding

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

también contiene un parámetro denominado que se puede usar para filtrar el enlace devuelto, como en el siguiente ejemplo:

Get-OutputBinding -Name MyQ*

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

En se admiten caracteres comodín (*).

Registro

El inicio de sesión en las funciones de PowerShell funciona como el inicio de sesión normal de PowerShell. Puede usar los cmdlets de registro para escribir en cada flujo de salida. Cada cmdlet se asigna a un nivel de registro utilizado por Functions.

Además de estos cmdlets, todo lo escrito en la canalización se redirige al nivel de registro y se muestra con el formato predeterminado de PowerShell.

Configuración del nivel de registro de la aplicación de funciones

Azure Functions permite definir el nivel de umbral para facilitar el control de la forma en que Functions escribe en los registros. Para establecer el umbral para todos los seguimientos que se escriben en la consola, use la propiedad en el archivo . Esta configuración se aplica a todas las funciones de Function App.

En el siguiente ejemplo se establece el umbral para habilitar el registro detallado para todas las funciones, pero establece el umbral para habilitar el registro de depuración para una función denominada :

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

Para más información, consulte la referencia sobre host.json.

Visualización de los registros

Si la aplicación de funciones se ejecuta en Azure, puede usar Application Insights para supervisarla. Lea monitoring Azure Functions para obtener más información sobre cómo ver y consultar registros de funciones.

Si la aplicación de funciones se ejecuta localmente para el desarrollo, los registros están de manera predeterminada en el sistema de archivos. Para ver los registros en la consola, establezca la variable de entorno en antes de iniciar la aplicación de funciones.

Tipos de desencadenadores y enlaces

Hay muchos desencadenadores y enlaces disponibles para usar con la aplicación de funciones. Para obtener la lista completa de desencadenadores y enlaces, consulte Enlaces admitidos.

Todos los desencadenadores y enlaces se representan en código como tipos de datos reales:

• Hashtable
• cuerda / cadena
• byte[]
• int
• double
• Contexto de Solicitud HTTP
• HttpResponseContext

Los cinco primeros tipos de esta lista son tipos .NET estándar. Los dos últimos los usa únicamente el desencadenador HttpTrigger.

Todos los parámetros de enlace de las funciones deben ser de uno de estos tipos.

Desencadenadores y enlaces HTTP

Los desencadenadores HTTP y de webhook trigger y los enlaces de salida HTTP usan objetos de solicitud y respuesta para representar la mensajería HTTP.

Objeto de solicitud

El objeto de solicitud que se pasa al script es del tipo , con las siguientes propiedades:

Todas las claves distinguen mayúsculas de minúsculas.

Objeto de respuesta

El objeto de respuesta que debe enviar de vuelta es de tipo , que tiene las siguientes propiedades:

Acceso a solicitudes y respuestas

Al trabajar con desencadenadores HTTP, puede acceder a la solicitud HTTP del mismo modo que lo haría con cualquier otro enlace de entrada. Se encuentra en el bloque .

Use un objeto para devolver una respuesta, tal y como se muestra en el ejemplo siguiente:

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

El resultado de invocar esta función sería:

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

Conversión de tipos de desencadenadores y enlaces

Para determinados enlaces como el enlace de blobs, podrá especificar el tipo del parámetro.

Por ejemplo, para que los datos de Blob Storage se proporcionen como cadena, agregue la siguiente conversión de tipo de mi bloque :

param([string] $myBlob)

Perfil de PowerShell

En PowerShell, existe el concepto de "perfil de PowerShell". Si no está familiarizado con los perfiles de PowerShell, consulte About profiles (Acerca de los perfiles).

En las funciones de PowerShell, el script de perfil se ejecuta una vez por instancia de trabajo de PowerShell en la aplicación cuando se implementa por primera vez y después de estar inactivo (arranque en frío. Cuando se habilita la simultaneidad estableciendo el valor PSWorkerInProcConcurrencyUpperBound, el script de perfil se ejecuta para cada espacio de ejecución creado.

Al crear una aplicación de funciones con herramientas como Visual Studio Code y Azure Functions Core Tools, se crea automáticamente una profile.ps1 predeterminada. El perfil predeterminado se mantiene on el repositorio de Core Tools GitHub y contiene:

• Autenticación automática de MSI en Azure.
• La capacidad de activar los alias de Azure PowerShell AzureRM si así lo desea.

Versiones de PowerShell

En la tabla siguiente se muestran las versiones de PowerShell disponibles para cada versión principal del entorno de ejecución de Functions y la versión de .NET necesaria:

Puede ver la versión actual mediante la impresión de desde cualquier función.

Para obtener más información sobre la política de soporte del tiempo de ejecución de Azure Functions, consulte este artículo.

Ejecución local en una versión específica

Cuando ejecute funciones de PowerShell localmente, debe agregar la configuración al array en el archivo local.setting.json en la raíz del proyecto. Cuando se ejecuta localmente en PowerShell 7.4, el archivo de local.settings.json es similar al ejemplo siguiente:

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

Cambio de la versión de PowerShell

Tenga en cuenta estas consideraciones antes de migrar la aplicación de funciones de PowerShell a PowerShell 7.4:

• Dado que la migración podría introducir cambios importantes en la aplicación, revise esta guía de migración antes de actualizar la aplicación a PowerShell 7.4.

• Asegúrese de que la aplicación de funciones se ejecuta en la versión más reciente del entorno de ejecución de Functions en Azure, que es la versión 4.x. Para obtener más información, consulte Visualización de la versión actual del entorno de ejecución.

Siga estos pasos para cambiar la versión de PowerShell que usa la aplicación de funciones. Puede realizar esta operación en el portal de Azure o mediante PowerShell.

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

La aplicación de funciones se reinicia después de realizar el cambio en la configuración.

Administración de dependencias

La administración de módulos en Azure Functions escritos en PowerShell se puede abordar de dos maneras: usar la característica Dependencias administradas o incluir los módulos directamente en el contenido de la aplicación. Cada método tiene sus propias ventajas y elegir la adecuada depende de sus necesidades específicas.

Elección del enfoque adecuado de administración de módulos

¿Por qué usar la característica de dependencias administradas?

• Instalación inicial simplificada: controla automáticamente la instalación del módulo en función del archivo .
• Actualizaciones automáticas: los módulos se actualizan automáticamente sin necesidad de intervención manual, incluyendo las correcciones de seguridad.

¿Por qué incluir módulos en el contenido de la aplicación?

• No dependencia del Galería de PowerShell: los módulos se agrupan con la aplicación, lo que elimina las dependencias externas.
• Más control: se evita el riesgo de regresiones causadas por actualizaciones automáticas, lo que proporciona control total sobre qué versiones de módulo se usan.
• Compatibilidad: funciona en Consumo flexible y se recomienda para otras SKU de Linux.

Característica de dependencias administradas

La característica Dependencias administradas permite que Azure Functions descargue y administre automáticamente los módulos de PowerShell especificados en el archivo />

Configuración de requirements.psd1

Para usar dependencias administradas en Azure Functions con PowerShell, debe configurar un archivo requirements.psd1. Este archivo especifica los módulos que requiere la función y Azure Functions descarga y actualiza automáticamente estos módulos para asegurarse de que el entorno permanece up-to-date.

Aquí se muestra cómo configurar el archivo :

1. Cree un archivo />
2. Defina los módulos y sus versiones en una estructura de datos de PowerShell.

Archivo de ejemplo:

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

Inclusión de módulos en el contenido de la aplicación

Para disfrutar de más control sobre las versiones de los módulos y evitar dependencias en recursos externos, incluya los módulos directamente en el contenido de la aplicación de funciones.

Para incluir módulos personalizados:

1. Cree una carpeta en la raíz de la aplicación de funciones.

   mkdir ./Modules
   

2. Copie los módulos en la carpeta con uno de los métodos siguientes:

   • Si los módulos ya estuvieran disponibles localmente:

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

   • Usando Save-Module para recuperar del Galería de PowerShell:

     Save-Module -Name MyCustomModule -Path ./Modules
     

   • Uso de del módulo :

     Save-PSResource -Name MyCustomModule -Path ./Modules
     

La aplicación de funciones debería tener la estructura siguiente:

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

Al inicia la aplicación de funciones, el trabajo de lenguaje de PowerShell agrega esta carpeta a , de manera que pueda confiar en la carga automática del módulo del mismo modo que lo haría en un script de PowerShell normal.

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

Solución de problemas de las dependencias administradas

Habilitación de las dependencias administradas

Para que las dependencias administradas funcionen, la característica debe estar habilitada en host.json:

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

Versiones de destino específicas

Al enfocarse en versiones de módulo específicas, es importante que siga los dos pasos siguientes para asegurarse de que se cargue la versión correcta del módulo:

1. Especificar la versión del módulo en :

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

2. Adición de instrucciones de importación en :

   Import-Module Az.Accounts -RequiredVersion '1.9.5'
   

Al seguir estos pasos se garantiza que se cargue la versión especificada al iniciar la función.

Establecer la configuración específica del intervalo de dependencia administrada

Es posible configurar cómo se descargan e instalan las dependencias administradas con las siguientes opciones de configuración de la aplicación:

Consideraciones de administración de dependencias

• Acceso a Internet: las dependencias administradas requieren acceso a para descargar módulos. Asegúrese de que el entorno permita este acceso, incluyendo la modificación de reglas de firewall o red virtual, según sea necesario. Los puntos de conexión necesarios se describen en Solución de problemas de cmdlets. Estos puntos de conexión se pueden agregar a la lista de permitidos, según sea necesario.
• Aceptación de licencias: las dependencias administradas no admiten módulos que requieran la aceptación de licencias.
• Plan de consumo flexible: la característica de dependencias administradas no se admite en el plan de consumo flexible. Uso de módulos personalizados en su lugar.
• Ubicaciones de módulos: en el equipo local, los módulos se instalan normalmente en una de las carpetas disponibles a nivel global en . Cuando se ejecuta en Azure, el $env:PSModulePath para una aplicación de funciones de PowerShell difiere de $env:PSModulePath en un script de PowerShell normal y contiene la carpeta Modules cargada con el contenido de la aplicación y una ubicación independiente administrada por dependencias administradas.

Variables de entorno

En Functions, la configuración de la aplicación, como las cadenas de conexión del servicio, se exponen como variables de entorno durante la ejecución. Puede acceder a esta configuración mediante , como se muestra en el siguiente ejemplo:

param($myTimer)

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

Hay varias maneras de agregar, actualizar y eliminar opciones de configuración de la aplicación de función:

• En el portal de Azure
• Usando el CLI de Azure
• Usando Azure PowerShell

Para aplicar los cambios realizados en la configuración de la aplicación de funciones, es necesario reiniciar la aplicación de funciones.

Cuando se ejecuta localmente, la configuración de la aplicación se lee desde el archivo del proyecto local.settings.json.

Simultaneidad

De forma predeterminada, Function Runtime de PowerShell solo puede procesar una invocación de función a la vez. Sin embargo, este nivel de simultaneidad podría no ser suficiente en las siguientes situaciones:

• Al intentar controlar un gran número de invocaciones a la vez.
• Al disponer de funciones que invocan a otras dentro de la misma aplicación de funciones.

Hay algunos modelos de simultaneidad que se pueden explorar según el tipo de carga de trabajo:

• Aumente . El aumento de esta configuración permitirá controlar las invocaciones de funciones en varios procesos dentro de la misma instancia, lo que presenta cierta sobrecarga de CPU y memoria. En general, esta sobrecarga no afecta a las funciones enlazadas a E/S. En el caso de las funciones enlazadas a la CPU, el impacto podría ser significativo.

• Aumente el valor de la configuración de aplicación . El aumento de esta configuración permite crear varios espacios de ejecución en el mismo proceso, lo que reduce significativamente la sobrecarga de CPU y memoria.

Establezca estas variables de entorno en la configuración de la aplicación de la aplicación de funciones.

En función del caso de uso, Durable Functions puede mejorar significativamente la escalabilidad. Para obtener más información, consulte patrones de aplicación de Durable Functions.

Consideraciones para usar la simultaneidad

De forma predeterminada, PowerShell es un lenguaje de scripting uniproceso. Sin embargo, la simultaneidad puede agregarse mediante el uso de varios espacios de ejecución de PowerShell en el mismo proceso. El número de espacios de ejecución creados y, por tanto, el número de subprocesos simultáneos por trabajo está limitado por la configuración de la aplicación . De forma predeterminada, el número de espacios de ejecución se establece en 1000 en la versión 4.x del entorno de ejecución de Functions. En las versiones 3.x y posteriores, el número máximo de espacios de ejecución se establece en 1. El rendimiento de la aplicación de funciones se ve afectado por la cantidad de CPU y memoria disponible en el plan seleccionado.

Azure PowerShell usa algunos contextos a nivel de proceso para ayudarle a evitar escribir en exceso. Sin embargo, si activa la simultaneidad en la aplicación de funciones e invoca acciones que cambien el estado, puede acabar con las condiciones de carrera. Estas condiciones de carrera son difíciles de depurar, ya que una invocación se basa en un estado determinado y la otra ha cambiado el estado.

Hay un gran valor en simultaneidad con Azure PowerShell, ya que algunas operaciones pueden tardar mucho tiempo. Sin embargo, debe proceder con precaución. Si sospecha que está experimentando una condición de carrera, establezca la configuración de la aplicación PSWorkerInProcConcurrencyUpperBound en y, en su lugar, use el aislamiento de nivel de proceso de trabajo de lenguaje para la simultaneidad.

Configuración de la función scriptdFile

De forma predeterminada, se ejecuta una función de PowerShell desde , un archivo que comparte el mismo directorio primario que su archivo correspondiente.

La propiedad de se puede usar para obtener una estructura de carpetas que tenga el aspecto del siguiente ejemplo:

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

En este caso, el archivo para incluye una propiedad que hace referencia al archivo con la función exportada que se va a ejecutar.

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

Uso de módulos de PowerShell mediante la configuración de entryPoint

Las funciones de PowerShell de este artículo se muestran en el archivo de script predeterminado generado por las plantillas. Sin embargo, también puede incluir las funciones en módulos de PowerShell. Puede hacer referencia a su código de función específico del módulo mediante los campos y del archivo de configuración function.json.

En este caso, es el nombre de una función o un cmdlet del módulo de PowerShell a los que se hace referencia en .

Considere la siguiente estructura de carpetas:

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

Donde contiene:

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

En este ejemplo, la configuración de incluye una propiedad que hace referencia a , que es un módulo de PowerShell de otra carpeta. La propiedad hace referencia a la función , que es el punto de entrada del módulo.

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

Con esta configuración, se ejecuta exactamente como lo haría .

Consideraciones para las funciones de PowerShell

Al trabajar con las funciones de PowerShell, tenga en cuenta las consideraciones de las siguientes secciones.

Arranque en frío

Al desarrollar Azure Functions en el modelo de hospedaje sin servidor, los arranques en frío son una realidad. El arranque en frío se refiere al período de tiempo tarda la aplicación de funciones en empezar a ejecutarse para procesar una solicitud. El arranque en frío se produce con mayor frecuencia en el plan Consumo, puesto que la aplicación de funciones se cierra durante los períodos de inactividad.

Evitar el uso de Install-Module

La ejecución de en el script de funciones en cada invocación puede provocar problemas de rendimiento. En su lugar, use o antes de publicar la aplicación de funciones para agrupar los módulos necesarios.

Para obtener más información, consulte Administración de dependencias.

Pasos siguientes

Para obtener más información, consulte los siguientes recursos:

• Mejores prácticas para Azure Functions
• Azure Functions referencia para desarrolladores
• Azure Functions desencadenadores y asociaciones