Azure Functions PowerShell fejlesztői útmutatója

Ez a cikk részletesen ismerteti, hogyan ír Azure Functions a PowerShell használatával.

Egy Azure PowerShell-függvény (függvény) PowerShell-szkriptként van ábrázolva, amely végrehajtódik, amikor aktiválódik. Minden függvényszkript rendelkezik egy kapcsolódó fájllal function.json , amely meghatározza a függvény viselkedését, például az aktiválás módját, valamint a bemeneti és kimeneti paramétereket. További információ: Azure Functions triggerek és hozzárendelések fogalmai.

Más típusú függvényekhez hasonlóan a PowerShell-szkriptfüggvények is olyan paramétereket használnak, amelyek megfelelnek a fájlban function.json definiált bemeneti kötések nevének. A TriggerMetadata rendszer egy paramétert is átad, amely további információkat tartalmaz a függvényt elindító eseményindítóról.

Ez a cikk feltételezi, hogy már elolvasta a Azure Functions fejlesztői útmutatót. Azt is feltételezi, hogy elvégezte a PowerShellhez készült Functions gyorsindítót, hogy elkészítse az első PowerShell-függvényt.

Mappastruktúra

A PowerShell-projektekhez szükséges mappastruktúra az alábbihoz hasonlóan néz ki. Ez az alapértelmezett beállítás módosítható. További információkért lásd a scriptFile szakaszt.

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

A projekt gyökerében található egy megosztott host.json fájl, amely a függvényalkalmazás konfigurálásához használható. Minden függvény rendelkezik egy saját kódfájllal (.ps1) és kötéskonfigurációs fájllal (function.json). A function.json fájl szülőkönyvtárának neve mindig a függvény neve.

Bizonyos kötésekhez szükség van egy fájl jelenlétére extensions.csproj . A Functions-futtatókörnyezet 2.x és újabb verzióiban szükséges kötéskiterjesztések a extensions.csproj fájlban vannak definiálva, a mappában lévő bin tényleges kódtárfájlokkal együtt. Helyi fejlesztéskor kötésbővítményeket kell regisztrálnia. Amikor függvényeket fejleszt az Azure portálon, ezt a regisztrációt automatikusan elvégzik ön helyett.

A PowerShell-függvényalkalmazásokban szükség lehet egy profile.ps1 futtatására, ami akkor fut, amikor a függvényalkalmazás elindul (más néven hidegindítás). További információ: PowerShell-profil.

PowerShell-szkript definiálása függvényként

Alapértelmezés szerint a Functionök futtatókörnyezete megkeresi a függvényt run.ps1, ahol run.ps1 ugyanabban a szülőkönyvtárban található, mint a hozzá tartozó function.json.

A szkript több argumentumot is átad a végrehajtás során. A paraméterek kezeléséhez adjon hozzá egy blokkot param a szkript tetejére, ahogyan az alábbi példában látható:

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

TriggerMetadata paraméter

A TriggerMetadata paraméter az eseményindítóval kapcsolatos további információk megadására szolgál. Ezek a metaadatok kötéstől kötésig változnak, de mindegyik tartalmaz egy tulajdonságot sys , amely a következő adatokat tartalmazza:

$TriggerMetadata.sys
Tulajdonság Leírás Típus
UtcNow Amikor UTC-ben a függvény aktiválva lett Dátum/idő
MódszerNév Az aktivált függvény neve karakterlánc
RandGuid a függvény végrehajtásának egyedi GUID-ja karakterlánc

Minden eseményindítótípus más metaadatkészlettel rendelkezik. Például a $TriggerMetadata for QueueTrigger tartalmazza a InsertionTime, Id, DequeueCount, többek között. Az üzenetsor-eseményindító metaadataival kapcsolatos további információkért tekintse meg az üzenetsor-eseményindítók hivatalos dokumentációját. Az eseményindító metaadatainak megtekintéséhez tekintse meg az eseményindítók dokumentációját.

Kötések

A PowerShellben a kötések egy függvény function.json fájlban vannak konfigurálva és definiálva. A függvények sokféleképpen lépnek kapcsolatba a kötésekkel.

Eseményindító és bemeneti adatok olvasása

Az eseményindítók és a bemeneti kötések a függvénynek átadott paraméterekként lesznek beolvasva. A bemeneti kötések direction beállítása in a function.json fájlban. A name-ben meghatározott function.json tulajdonság a paraméter neve a param blokkban. Mivel a PowerShell elnevezett paramétereket használ a kötéshez, a paraméterek sorrendje nem számít. Ajánlott azonban követni a function.json által meghatározott rendelkezések sorrendjét.

param($MyFirstInputBinding, $MySecondInputBinding)

Kimeneti adatok írása

A Functionsben a kimeneti kötésnél a direction értékét out-ra állítják a function.json fájlban. A Push-OutputBinding parancsmaggal, amely elérhető a függvények futtatókörnyezetében, írhat kimeneti kötésre. A name kötés tulajdonsága minden esetben megfelel a function.json paraméternek, amelyet a Name parancsmag határoz meg.

Az alábbi példa bemutatja, hogyan hívja meg a Push-OutputBinding elemet a függvényskriptjében:

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

Egy adott kötés értékét is átadhatja a pipeline-on keresztül.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding a következőhöz megadott érték alapján eltérően viselkedik -Name:

  • Ha a megadott név nem oldható fel érvényes kimeneti kötésre, hibaüzenet jelenik meg.

  • Ha a kimeneti kötés értékgyűjteményt fogad el, többször is meghívhat Push-OutputBinding több érték leküldésére.

  • Ha a kimeneti kötés csak egyetlen értéket fogad el, akkor a Push-OutputBinding újbóli meghívása hibát eredményez.

Push-OutputBinding szintaxis

A híváshoz Push-OutputBindingaz alábbi paraméterek érvényesek:

Név Típus Pozíció Leírás
-Name Sztring 1 A beállítani kívánt kimeneti kötés neve.
-Value Objektum 2 A beállítani kívánt kimeneti kötés értéke, amely a ByValue folyamatból lesz elfogadva.
-Clobber kapcsolóParaméter Nevű (Nem kötelező) Ha meg van adva, kényszeríti az értéket egy adott kimeneti kötésre.

A következő gyakori paraméterek is támogatottak:

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

További információért lásd: A CommonParameters című részt.

Push-OutputBinding példa: HTTP-válaszok

Az HTTP-eseményindító egy response nevű kimeneti kötést használva ad vissza választ. Az alábbi példában a kimeneti kötés response értéke "1. kimenet":

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

Mivel a kimenet HTTP formátumú, amely csak egyetlen értéket fogad el, hibát jelez, ha Push-OutputBinding második alkalommal van meghívva.

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

Az olyan kimenetek esetében, amelyek csak egyszeri értékeket fogadnak el, a -Clobber paraméterrel felülbírálhatja a régi értéket a gyűjteményhez való hozzáadás helyett. Az alábbi példa feltételezi, hogy már hozzáadott egy értéket. A -Clobber használatával a következő példa válasza felülírja a meglévő értéket, és "3. kimenet" értéket ad vissza.

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

Push-OutputBinding példa: Sorkimeneti kötés

Push-OutputBinding az adatok kimeneti kötésekbe való küldésére szolgál, például egy Azure Queue Storage kimeneti kötésre. Az alábbi példában az üzenetsorba írt üzenet értéke "1. kimenet":

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

A Storage-üzenetsor kimeneti kötése több kimeneti értéket fogad el. Ebben az esetben az első írás után hívja meg az alábbi példát, ami felsorol két elemet az üzenetsorba: "output #1" és "output #2".

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

Az alábbi példa, amikor az előző kettő után van meghívva, két további értéket ad hozzá a kimeneti gyűjteményhez:

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

Amikor az üzenetsorba íródott, az üzenet a következő négy értéket tartalmazza: "output #1", "output #2", "output #3" és "output #4".

Get-OutputBinding parancsmag

A Get-OutputBinding parancsmaggal lekérheti a kimeneti kötésekhez jelenleg beállított értékeket. Ez a parancsmag lekér egy hashtáblát, amely tartalmazza a kimeneti kötések neveit és az azokhoz tartozó értékeket.

Az alábbi példa az aktuális kötési értékek visszaadására használ Get-OutputBinding :

Get-OutputBinding

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

Get-OutputBinding egy , a -Namevisszaadott kötés szűrésére használható paramétert is tartalmaz, ahogyan az alábbi példában is látható:

Get-OutputBinding -Name MyQ*

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

A helyettesítő karakterek (*) támogatottak a Get-OutputBinding-ben.

Naplózás

A PowerShell-függvények naplózása a szokásos PowerShell-naplózáshoz hasonlóan működik. A naplózási parancsmagokkal minden kimeneti streambe írhat. Minden parancsmag a Functions által használt naplószintre van leképezetten.

Függvények naplózási szintje Naplózási parancsmag
Hiba Write-Error
Figyelmeztetés Write-Warning
Tájékoztatás Write-Information
Write-Host
Write-Output
Az Information naplószintre ír üzeneteket.
Hibakeresés Write-Debug
Nyom Write-Progress
Write-Verbose

A parancsmagok mellett a folyamatba írt összes írás a naplószintre Information lesz átirányítva, és az alapértelmezett PowerShell-formázással jelenik meg.

Fontos

Write-Verbose vagy Write-Debug parancsmagok használata nem elegendő a részletes és hibakeresési szintű naplózás megtekintéséhez. A naplószint küszöbértékét is konfigurálnia kell, amely deklarálja, hogy milyen szintű naplók érdeklik. További információ: A függvényalkalmazás naplószintjének konfigurálása.

A függvényalkalmazás naplószintjének konfigurálása

Azure Functions lehetővé teszi a küszöbérték szintjének meghatározását, hogy könnyen irányíthassa a Functions naplózási módját. A konzolra írt nyomkövetések összességének küszöbértékét a logging.logLevel.default tulajdonsággal a host.json fájlban állíthatja be. Ez a beállítás a függvényalkalmazás összes függvényére vonatkozik.

Az alábbi példa a küszöbértéket úgy állítja be, hogy az összes függvény esetében engedélyezze a részletes naplózást, de a küszöbértéket úgy állítja be, hogy engedélyezze a hibakeresési naplózást egy nevesített MyFunctionfüggvény esetében:

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

További információ: host.json referencia.

A naplók megtekintése

Ha a függvényalkalmazása az Azure-ban fut, az Application Insights segítségével figyelheti. A függvénynaplók megtekintéséről és lekérdezéséről a monitoring Azure Functions című témakörben olvashat.

Ha helyileg futtatja a Function App-ot fejlesztési célokra, a naplók alapértelmezetten a fájlrendszerbe kerülnek. A naplók a konzolon való megtekintéséhez állítsa be a AZURE_FUNCTIONS_ENVIRONMENT környezeti változót Development a függvényalkalmazás indítása előtt.

Eseményindítók és kötések típusai

A függvényalkalmazáshoz számos eseményindító és kötés érhető el. Az eseményindítók és kötések teljes listájáért tekintse meg a támogatott kötéseket.

Az összes eseményindító és kötés a kódban néhány valós adattípusként jelenik meg:

  • Hasítótábla
  • karakterlánc
  • bájt[]
  • int
  • dupla
  • HTTP kérelem környezet
  • HttpResponseContext

A lista első öt típusa standard .NET típus. Az utolsó kettőt csak a HttpTrigger-eseményindító használja.

A függvények minden kötési paraméterének ilyen típusúnak kell lennie.

HTTP-eseményindítók és kötések

A HTTP- és webhook-eseményindítók és HTTP-kimeneti kötések kérés- és válaszobjektumokat használnak a HTTP-üzenetküldés megjelenítéséhez.

Objektum kérése

A szkriptbe átadott kérelemobjektum a HttpRequestContextkövetkező tulajdonságokkal rendelkezik:

Tulajdonság Leírás Típus
Body A kérelem törzsét tartalmazó objektum. Body az adatok alapján a legjobb típusba van szerializálva. Például, ha az adatok JSON formátumúak, kivonattáblázatként lesznek átadva. Ha az adat karakterlánc, akkor karakterláncként adjuk át. objektum
Headers A kérelemfejléceket tartalmazó szótár. Szótár
Method A kérés HTTP-metódusa. karakterlánc
Params A kérés útválasztási paramétereit tartalmazó objektum. Szótár
Query A lekérdezési paramétereket tartalmazó objektum. Szótár
Url A kérés URL-címe. karakterlánc

* Minden Dictionary<string,string> kulcs érzéketlen a kis- és nagybetűkhez.

Válaszobjektum

A válaszobjektum, amelyet vissza kell küldenie, az alábbi HttpResponseContexttulajdonságokkal rendelkezik:

Tulajdonság Leírás Típus
Body A válasz törzsét tartalmazó objektum. objektum
ContentType Rövid kéz a válasz tartalomtípusának beállításához. karakterlánc
Headers A válaszfejléceket tartalmazó objektum. Szótár vagy hash-tábla
StatusCode A válasz HTTP-állapotkódja. string vagy int

A kérés és a válasz elérése

HA HTTP-eseményindítókkal dolgozik, ugyanúgy érheti el a HTTP-kérést, mint bármely más bemeneti kötés esetén. A blokkban param van.

Az alábbi példában látható módon egy HttpResponseContext objektum használatával adjon vissza egy választ.

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

A függvény meghívásának eredménye a következő:

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

Típuskonverzió triggerekhez és kötésekhez

Bizonyos kötések, például a blobkötés esetében megadhatja a paraméter típusát.

Ha például sztringként szeretné megadni a Blob Storage-ból származó adatokat, adja hozzá a következő típust a blokkhoz param :

param([string] $myBlob)

PowerShell-profil

A PowerShell-ben létezik egy PowerShell-profil fogalma. Ha nem ismeri a PowerShell-profilokat, olvassa el a Profilok ismertetése című témakört.

A PowerShell Functionsben a profilszkript végrehajtása powerShell-feldolgozópéldányonként egyszer történik az alkalmazásban az első üzembe helyezéskor és az inaktív állapot (hideg kezdés) után. Ha az egyidejűség a PSWorkerInProcConcurrencyUpperBound érték beállításával engedélyezve van, a rendszer minden létrehozott runspace esetében futtatja a profilszkriptet.

Ha olyan eszközökkel hoz létre függvényalkalmazásokat, mint például Visual Studio Code és Azure Functions Core Tools, a rendszer létrehoz egy alapértelmezett profile.ps1. Az alapértelmezett profil a Core Tools GitHub adattárban van fenntartva, és a következőket tartalmazza:

  • Automatikus MSI-hitelesítés Azure.
  • Ha szeretné, bekapcsolhatja a Azure PowerShell AzureRM PowerShell-aliasokat.

PowerShell-verziók

Az alábbi táblázat a Functions-futtatókörnyezet egyes főverziói számára elérhető PowerShell-verziókat és a szükséges .NET verziót mutatja be:

Függvények verziója PowerShell-verzió .NET verzió
4.x PowerShell 7.6 .NET 10
4.x PowerShell 7.4 .NET 8

A PowerShell 7.6 általánosságban elérhető minden Azure Functions hosting csomagon, kivéve a Linux Consumption-et. A támogatott csomagok közé tartozik a Windows Consumption, Premium és Dedicated Windows és Linuxon, valamint a Flex Consumption.

Az aktuális verziót bármelyik függvényből kinyomtathatja $PSVersionTable .

Az Azure Functions futtatókörnyezet támogatási szabályzatáról további információt ebben a cikkben.

Helyi futtatás adott verzióban

Amikor helyben futtat PowerShell-függvényeket, hozzá kell adnia a beállítást "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.6" a projekt gyökérkönyvtárában található local.setting.json fájl Values tömbjéhez. Ha helyileg fut a PowerShell 7.6-on, a local.settings.json fájl a következő példához hasonlóan néz ki:

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

Megjegyzés

A PowerShell 7.6 .NET 10-et igényel.

Adja meg a fő- és alverziószámot is a(z) FUNCTIONS_WORKER_RUNTIME_VERSION mezőben, például: "7.6". Az érték "~7" arra "7.0.x" utal, hogy nem frissíti automatikusan az alkalmazásodat egy későbbi kisebb verzióra.

A PowerShell-verzió módosítása

A PowerShell verzió módosítása előtt teszteld az alkalmazás kompatibilitást, és győződj meg róla, hogy az a Functions futási ideje 4.x verzióján fut. További információt az aktuális futtatókörnyezeti verzió megtekintése című témakörben talál.

Migrációs útmutatásért nézd meg az Azure Functions PowerShell worker wiki oldalát.

Az alábbi lépésekkel módosíthatja a függvényalkalmazás által használt PowerShell-verziót. Ezt a műveletet a Azure portálon vagy a PowerShell használatával hajthatja végre.

  1. A Azure portálon keresse meg a függvényalkalmazást.

  2. A Beállítások területen válassza a Konfiguráció lehetőséget. Az Általános beállítások lapon keresse meg a PowerShell-verziót.

    Képernyőkép a PowerShell-verzió kiválasztásáról.

  3. Válassza ki a kívánt PowerShell Core-verziót , és válassza a Mentés lehetőséget. Amikor figyelmeztetést ad a függőben lévő újraindításról, válassza a Folytatás lehetőséget. A függvényalkalmazás újraindul a kiválasztott PowerShell-verzióban.

A függvényalkalmazás a konfiguráció módosítása után újraindul.

Függőségkezelés

A PowerShellben írt Azure Functions moduljainak kezelése kétféleképpen közelíthető meg: a modulokat közvetlenül az alkalmazás tartalmában helyezheted el, vagy használhatod a "Managed Dependencies" funkciót. Minden módszernek megvannak a maga előnyei, és a megfelelő kiválasztása az Ön igényeitől függ.

A megfelelő modulkezelési megközelítés kiválasztása

Miért érdemes használni a Felügyelt függőségek funkciót?

  • Egyszerűsített kezdeti telepítés: Automatikusan kezeli a modul telepítését a requirements.psd1 fájl alapján.
  • Automatikus frissítések: A modulok automatikusan frissülnek, beleértve a biztonsági javításokat is, manuális beavatkozás nélkül.

Miért érdemes modulokat belefoglalni az alkalmazás tartalmába?

  • Nem függ a PowerShell-galéria: A modulok az alkalmazáshoz vannak csomagolva, így megszűnnek a külső függőségek.
  • További szabályozás: Elkerüli az automatikus frissítések által okozott regressziók kockázatát, így teljes mértékben szabályozhatja a modulverziók használatát.
  • Kompatibilitás: Flex Consumption rendszeren működik, és a többi Linux SKU-hoz is ajánlott.

Felügyelt függőségek funkció

A Felügyelt függőségek funkció lehetővé teszi, hogy Azure Functions automatikusan letöltse és kezelje a requirements.psd1 fájlban megadott PowerShell-modulokat. Ez a funkció alapértelmezés szerint engedélyezve van az új PowerShell-függvényalkalmazásokban.

A requirements.psd1 konfigurálása

Ha felügyelt függőségeket szeretne használni Azure Functions a PowerShell-lel, konfigurálnia kell egy requirements.psd1 fájlt. Ez a fájl megadja a függvény által igényelt modulokat, és Azure Functions automatikusan letölti és frissíti ezeket a modulokat, így biztosítva, hogy a környezet up-to-date maradjon.

Így állítsd be és konfiguráld a requirements.psd1 fájlt:

  1. Hozzon létre egy requirements.psd1 fájlt a Azure függvény gyökérkönyvtárában, ha még nem létezik.
  2. Határozza meg a modulokat és azok verzióit egy PowerShell-adatstruktúrában.

requirements.psd1 példafájl:

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

Modulok beépítése az alkalmazás tartalmába

A modulverziók hatékonyabb szabályozása és a külső erőforrásoktól való függőségek elkerülése érdekében a modulokat közvetlenül a függvényalkalmazás tartalmába is belefoglalhatja.

Egyéni modulok belefoglalása:

  1. Hozzon létre egy Modules mappát a függvényalkalmazás gyökerénél.

    mkdir ./Modules

  2. Másolja a modulokat a Modules mappába az alábbi módszerek egyikével:

    • Ha a modulok már elérhetők helyileg:

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

    • A Save-Module letöltése a PowerShell Galériából

      Save-Module -Name MyCustomModule -Path ./Modules

    • A Save-PSResource modul PSResourceGet használata:

      Save-PSResource -Name MyCustomModule -Path ./Modules

A függvényalkalmazásnak a következő struktúrával kell rendelkeznie:

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

A függvényalkalmazás indításakor a PowerShell nyelvi feldolgozója hozzáadja ezt Modules a mappát a mappához, így ugyanúgy támaszkodhat a $env:PSModulePath modul automatikus betöltésére, mint egy normál PowerShell-szkriptben.

Megjegyzés

Ha a függvényalkalmazás forrásvezérlés alatt áll, győződjön meg arról, hogy a hozzáadott Modulok mappában lévő összes tartalmat nem zárja ki a .gitignore. Ha például az egyik modul tartalmaz egy bin könyvtárat, amely ki van hagyva, a .gitignore-t úgy szeretné módosítani, hogy kicseréli bin a következőre:

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

Felügyelt függőségek hibaelhárítása

Felügyelt függőségek engedélyezése

Ahhoz, hogy a felügyelt függőségek működjenek, engedélyezni kell a funkciót host.json:

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

Célspecifikus verziók

Adott modulverziók megcélzásakor fontos mindkét lépést követni a modul megfelelő verziójának betöltése érdekében:

  1. Adja meg a modul verzióját a következő helyen requirements.psd1:

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

  2. Importálási utasítás hozzáadása a következőhöz profile.ps1:

    Import-Module Az.Accounts -RequiredVersion '1.9.5'

Az alábbi lépések végrehajtásával biztosítható, hogy a függvény indításakor a megadott verzió be legyen töltve.

Adott felügyelt függőség időközi beállításainak konfigurálása

A felügyelt függőségek letöltésének és telepítésének módját az alábbi alkalmazásbeállítások használatával konfigurálhatja:

Beállítás Alapértelmezett érték Leírás
MDMaxHátterfrissítésiIdőszak 7.00:00:00 (hét nap) Szabályozza a PowerShell-függvényalkalmazások háttérfrissítési időszakát.
MDNewSnapshotCheckPeriod 01:00:00 (egy óra) Megadja, hogy a PowerShell-feldolgozó milyen gyakran keres frissítéseket.
MDMinBackgroundUpgradePeriod 1.00:00:00 (egy nap) A frissítési ellenőrzések közötti minimális idő.

Függőségkezelési szempontok

  • Internet-hozzáférés: A felügyelt függőségek hozzáférést igényelnek a letöltési modulokhoz https://www.powershellgallery.com . Győződjön meg arról, hogy a környezet engedélyezi ezt a hozzáférést, beleértve a tűzfal-/VNet-szabályok szükség szerinti módosítását is. A szükséges végpontokat a hibaelhárítási parancsmagok ismertetik. Ezek a végpontok igény szerint hozzáadhatók az engedélyezési listához.
  • Licenc elfogadása: A felügyelt függőségek nem támogatják a licenc elfogadását igénylő modulokat.
  • Flex fogyasztási terv: A Flex fogyasztási terv nem támogatja a felügyelt függőségek funkciót. Használjon inkább egyéni modulokat.
  • Modulhelyek: A helyi számítógépen a modulok általában a globálisan elérhető mappák egyikében vannak telepítve.$env:PSModulePath Ha az Azure-ben fut, a PowerShell-függvényalkalmazás $env:PSModulePath különbözik egy normál PowerShell szkript $env:PSModulePath-tól, és tartalmazza az alkalmazás tartalmával feltöltött Modules mappát, valamint egy különálló helyet, amelyet a felügyelt függőségek kezelnek.

Környezeti változók

A Functionsben az alkalmazásbeállítások, például a szolgáltatás kapcsolati sztring környezeti változókként jelennek meg a végrehajtás során. Ezeket a beállításokat $env:NAME_OF_ENV_VARaz alábbi példában látható módon érheti el:

param($myTimer)

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

A függvényalkalmazás beállításai többféleképpen is hozzáadhatók, frissíthetők és törölhetők:

A függvényalkalmazás beállításainak módosításához újra kell indítani a függvényalkalmazást.

Helyi futtatáskor az alkalmazásbeállítások a local.settings.json projektfájlból lesznek beolvasva.

Egyidejűség

Alapértelmezés szerint a Functions PowerShell-futtatókörnyezet egyszerre csak egy függvény meghívását tudja feldolgozni. Ez az egyidejűségi szint azonban nem feltétlenül elegendő a következő helyzetekben:

  • Amikor egyszerre sok meghívást próbál kezelni.
  • Ha olyan függvényei vannak, amelyek más függvényeket is meghívnak ugyanabban a függvényalkalmazásban.

A számítási feladatok típusától függően néhány egyidejűségi modellt is megvizsgálhat:

  • Növelje a(z) FUNCTIONS_WORKER_PROCESS_COUNT értékét. A beállítás növelése lehetővé teszi a függvényhívások kezelését több folyamaton belül, amelyek bizonyos processzor- és memóriaterhelést okoznak. Az I/O-kötött függvények általában nem szenvednek ettől a többletterheléstől. A processzorhoz kötött függvények esetében a hatás jelentős lehet.

  • Növelje az PSWorkerInProcConcurrencyUpperBound alkalmazásbeállítás értékét. A beállítás növelése lehetővé teszi több futtató tér létrehozását ugyanazon a folyamaton belül, ami jelentősen csökkenti a processzor- és memóriaterhelést.

Ezeket a környezeti változókat a függvényalkalmazás alkalmazásbeállításaiban állíthatja be.

A használati esettől függően a Durable Functions jelentősen javíthatja a méretezhetőséget. További információ: Durable Functions alkalmazásminták.

Megjegyzés

Előfordulhat, hogy "a kérések várólistára kerülnek, mert nincsenek elérhető futtatóterek" figyelmeztetések. Ez az üzenet nem hiba. Az üzenet azt jelzi, hogy a kérések várólistára kerülnek. A rendszer az előző kérések teljesítésekor kezeli őket.

Az egyidejűség használatának szempontjai

A PowerShell alapértelmezés szerint egy single_threaded szkriptnyelv. Egyidejűség azonban több PowerShell-futtatótér használatával is hozzáadható ugyanabban a folyamatban. A létrehozott futtatóterek számát, így az egyidejű szálak számát feldolgozónként az alkalmazásbeállítás korlátozza PSWorkerInProcConcurrencyUpperBound . A futtatókörnyezetek száma alapértelmezés szerint 1000-ra van állítva a Functions-futtatókörnyezet 4.x verziójában. A 3.x és újabb verziókban a futtatóterek maximális száma 1. A függvényalkalmazás átviteli sebességére hatással van a kiválasztott csomagban elérhető processzor és memória mennyisége.

Azure PowerShell process-level környezeteket és állapotokat használ a felesleges gépelés elkerülése érdekében. Ha azonban engedélyezi az egyidejűséget a függvényalkalmazásban, és olyan műveleteket hív meg, amelyek módosítják az állapotot, versenyfeltételekhez vezethet. Ezeket a versenyfeltételeket nehéz hibakeresésre használni, mert az egyik hívás egy adott állapotra támaszkodik, a másik meghívás pedig módosította az állapotot.

A Azure PowerShell egyidejűségében óriási érték van, mivel egyes műveletek jelentős időt is igénybe vehetnek. Azonban körültekintően kell eljárnia. Ha azt gyanítja, hogy versenyhelyzetet tapasztal, állítsa a PSWorkerInProcConcurrencyUpperBound alkalmazásbeállítást 1, és használja helyette a nyelvi munkás folyamatszintű elkülönítését az egyidejű feldolgozás érdekében.

Függvény scriptFile konfigurálása

Alapértelmezés szerint egy PowerShell-függvény egy olyan fájlból run.ps1lesz végrehajtva, amely ugyanazt a szülőkönyvtárat használja, mint a megfelelő function.json.

A scriptFile tulajdonság a function.json következő példához hasonló mappastruktúra lekérésére használható:

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

Ebben az esetben a function.json for myFunction tartalmaz egy scriptFile tulajdonságot, amely hivatkozik a fájlra az exportált függvény futtatásához.

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

PowerShell-modulok használata entryPoint konfigurálásával

A cikkben szereplő PowerShell-függvények a sablonok által létrehozott alapértelmezett run.ps1 szkriptfájllal jelennek meg. A függvényeket azonban a PowerShell-modulokba is belefoglalhatja. A function.json konfigurációs fájlban található scriptFile és entryPoint mezők használatával hivatkozhat a modulban található adott függvénykódra.

Ebben az esetben entryPoint egy függvény vagy parancsmag neve a PowerShell-modulban scriptFile.

Vegye figyelembe a következő mappastruktúrát:

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

Amikor PSFunction.psm1 tartalmazza:

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

Ebben a példában a konfiguráció egy olyan tulajdonságot myFunction tartalmaz, amely egy másik mappában lévő PowerShell-modulra hivatkozikscriptFile.PSFunction.psm1 A entryPoint tulajdonság a Invoke-PSTestFunc függvényre hivatkozik, amely a modul belépési pontja.

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

Ezzel a konfigurációval a rendszer pontosan úgy hajtja végre a Invoke-PSTestFunc végrehajtást, ahogy tenné run.ps1 .

A PowerShell-függvények szempontjai

A PowerShell-függvények használatakor vegye figyelembe a következő szakaszokban ismertetett szempontokat.

Hideg kezdés

Az Azure Functions kiszolgáló nélküli üzemeltetési modellben való fejlesztésekor a hidegindítás valós jelenség. A hidegindítás azt az időtartamot jelenti, amely alatt a függvényalkalmazás elkezd futni egy kérés feldolgozásához. A használatalapú csomagban gyakrabban fordul elő hidegindítás, mert a függvényalkalmazás inaktivitási időszakokban leáll.

Az Install-Module használatának mellőzése

Az Install-Module függvényszkriptben minden egyes meghívás során való futtatása teljesítményproblémákat okozhat. Ehelyett használja a Save-Module vagy Save-PSResource jelöléseket, majd tegye közzé a függvényalkalmazást a szükséges modulok kötegeléséhez.

További információ: Függőségkezelés.

Következő lépések

További információt a következő források tartalmaznak:

  • Last updated on