Azure Functions PowerShell geliştirici kılavuzu

Bu makalede, PowerShell kullanarak Azure Functions yazma hakkında ayrıntılar sağlanır.

PowerShell Azure işlevi (işlev), tetiklendiğinde yürütülen bir PowerShell betiği olarak temsil edilir. Her işlev betiği, işlevin nasıl davrandığını tanımlayan, nasıl tetiklendiğini ve giriş ve çıkış parametreleri gibi ilgili function.json bir dosyaya sahiptir. Daha fazla bilgi edinmek için bkz. Azure Functions tetikleyicileri ve bağlamaları kavramları.

Diğer işlev türleri gibi PowerShell betik işlevleri de dosyada tanımlanan function.json tüm giriş bağlamalarının adlarıyla eşleşen parametreler alır. TriggerMetadata ayrıca, işlevi başlatan tetikleyici hakkında ek bilgiler içeren bir parametre geçirilir.

Bu makalede, Azure Functions geliştirici kılavuzunu okuduğunuz varsayılır. Ayrıca, ilk PowerShell işlevinizi oluşturmak için PowerShell Functions quickstart'ını tamamladığınız varsayılır.

Klasör yapısı

PowerShell projesi için gerekli klasör yapısı aşağıdaki gibi görünür. Bu varsayılan değer değiştirilebilir. Daha fazla bilgi için scriptFile bölümüne bakın.

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

Projenin kökünde, işlev uygulamasını yapılandırmak için kullanılabilecek paylaşılan host.json bir dosya vardır. Her işlevin kendi kod dosyası (.ps1) ve bağlama yapılandırma dosyası () içeren bir klasörü vardırfunction.json. function.json dosyasının üst dizininin adı her zaman işlevinizin adıdır.

Bazı bağlamalar bir extensions.csproj dosyanın bulunmasını gerektirir. İşlevler çalışma zamanının 2.x ve sonraki sürümlerinde gerekli olan bağlama uzantıları, extensions.csproj klasöründeki gerçek kütüphane dosyalarıyla birlikte bin dosyasında tanımlanır. Yerel olarak geliştirirken bağlama uzantılarını kaydetmeniz gerekir. Azure portalında işlevler geliştirirken bu kayıt sizin için yapılır.

PowerShell İşlev Uygulamaları'nda, bir işlev uygulaması çalışmaya başladığında (aksi takdirde profile.ps1 olarak bilinir) çalışan isteğe bağlı bir bulunabilir. Daha fazla bilgi için bkz . PowerShell profili.

PowerShell betiğini işlev olarak tanımlama

varsayılan olarak, İşlevler çalışma zamanı işlevinizi run.ps1içinde arar ve burada run.ps1 ilgili function.jsonile aynı üst dizini paylaşır.

Betiğiniz çalıştırıldığında ona birkaç bağımsız değişken geçirilir. Bu parametreleri işlemek için aşağıdaki örnekte olduğu gibi betiğinizin en üstüne bir param blok ekleyin:

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

TriggerMetadata parametresi

TriggerMetadata parametresi tetikleyici hakkında ek bilgi sağlamak için kullanılır. Bu meta veriler bağlamadan bağlamaya farklılık gösterir, ancak bunların tümü aşağıdaki verileri içeren bir sys özellik içerir:

$TriggerMetadata.sys

Özellik	Açıklama	Tür
UtcNow	UTC'de işlev tetiklendiğinde	Tarih ve Saat
YöntemAdı	Tetiklenen İşlevin adı	Dize
RandGuid	İşlevin bu çalıştırılması için benzersiz bir GUID	Dize

Her tetikleyici türünün farklı bir meta veri kümesi vardır. Örneğin, $TriggerMetadata, QueueTrigger için InsertionTime, Id, DequeueCount ve diğer şeyleri içerir. Kuyruk tetikleyicisinin meta verileri hakkında daha fazla bilgi için kuyruk tetikleyicileri için resmi belgelere gidin. Tetikleyici meta verilerinin içinde neler olduğunu görmek için birlikte çalıştığınız tetikleyicilerle ilgili belgelere bakın.

Bağlamalar

PowerShell'de bağlamalar bir işlevin function.json yapılandırılır ve tanımlanır. İşlevler bağlamalarla birçok şekilde etkileşim kurar.

Tetikleyici ve giriş verilerini okuma

Tetikleyici ve giriş bağlamaları işlevinize geçirilen parametreler olarak okunur. Giriş bağlamaları function.json içinde direction değerine in olarak ayarlanmıştır. name içinde tanımlanan function.json özelliği, param bloğundaki parametrenin adıdır. PowerShell bağlama için adlandırılmış parametreler kullandığından, parametrelerin sırası önemli değildir. Ancak, function.json içinde tanımlanan bağlamaların sırasını takip etmek en iyi uygulamadır.

param($MyFirstInputBinding, $MySecondInputBinding)

Çıkış verileri yazma

İşlevler'de, çıkış bağlaması function.json dosyasına directionout olarak ayarlanmıştır. Çalışma zamanında kullanılabilen Push-OutputBinding cmdlet'ini kullanarak bir çıkış bağlamasına yazabilirsiniz. Tüm durumlarda, bağlamanın name içinde tanımlandığı function.json özelliği, cmdlet'in Name parametresine karşılık gelirPush-OutputBinding.

İşlev betiğinizde Push-OutputBinding nasıl çağrılacağı aşağıdaki örnekte gösterilmektedir.

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

Ayrıca, işlem hattı aracılığıyla belirli bir bağlama için bir değer geçirebilirsiniz.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding için -Namebelirtilen değere göre farklı davranır:

Belirtilen ad geçerli bir çıkış bağlamasına çözümlenemediyse bir hata oluşur.
Çıkış bağlaması bir değer koleksiyonu kabul ettiğinde, birden çok değer göndermek için tekrar tekrar çağırabilirsiniz Push-OutputBinding .
Çıkış bağlaması yalnızca tek bir değeri kabul ettiğinde, Push-OutputBinding ikinci kez çağrılması bir hataya neden olur.

Push-OutputBinding söz dizimi

Çağrısı için Push-OutputBindinggeçerli parametreler şunlardır:

Adı	Tür	Pozisyon	Açıklama
`-Name`	Dize	1	Ayarlamak istediğiniz çıkış bağlamasının adı.
`-Value`	Nesne	2	Ayarlamak istediğiniz çıkış bağlamasının değeri, işlem hattı ByValue'dan kabul edilir.
`-Clobber`	SwitchParameter	Adlı	(İsteğe bağlı) Belirtildiğinde, değerin belirtilen çıkış bağlaması için ayarlanmasını sağlar.

Aşağıdaki ortak parametreler de desteklenir:

Verbose
Debug
ErrorAction
ErrorVariable
WarningAction
WarningVariable
OutBuffer
PipelineVariable
OutVariable

Daha fazla bilgi için bkz . CommonParameters Hakkında.

Push-OutputBinding örneği: HTTP yanıtları

HTTP tetikleyicisi adlı responsebir çıkış bağlaması kullanarak bir yanıt döndürür. Aşağıdaki örnekte, çıkış bağlaması response "output #1" değerine sahiptir:

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

Çıkış, yalnızca tek bir değeri kabul eden HTTP'ye geldiğinden, Push-OutputBinding ikinci kez çağrıldığında bir hata fırlatılır.

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

Yalnızca tekil değerleri kabul eden çıkışlar için, bir koleksiyona eklemeye çalışmak yerine eski değeri geçersiz kılmak için parametresini kullanabilirsiniz -Clobber . Aşağıdaki örnekte zaten bir değer eklediğiniz varsayılır. kullanılarak -Clobber, aşağıdaki örnekte verilen yanıt mevcut değeri geçersiz kılarak "çıktı #3" değerini döndürür:

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

Push-OutputBinding örneği: Kuyruk çıktısı bağlayıcısı

Push-OutputBinding, Azure Kuyruk depolama çıkış bağlaması gibi çıkış bağlamalarına veri göndermek için kullanılır. Aşağıdaki örnekte kuyruğa yazılan iletinin değeri "output #1" şeklindedir:

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

Depolama kuyruğunun çıkış bağlaması birden çok çıkış değeri kabul eder. Bu durumda, kuyruğa ilk yazmadan sonra aşağıdaki örneği çağırarak iki öğe içeren bir liste oluşturun: "output #1" ve "output #2".

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

Aşağıdaki örnek, önceki iki örnekten sonra çağrıldığında çıkış koleksiyonuna iki değer daha ekler:

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

Kuyruğa yazıldığında, ileti şu dört değeri içerir: "output #1", "output #2", "output #3" ve "output #4".

Get-OutputBinding cmdlet'i (PowerShell komutu)

Çıkış bağlamalarınız için ayarlanmış olan değerleri almak için cmdlet'ini kullanabilirsiniz Get-OutputBinding . Bu cmdlet, çıkış bağlamalarının adlarını ve ilgili değerlerini içeren bir karma tabloyu elde eder.

Aşağıdaki örnek geçerli bağlama değerlerini döndürmek için kullanır Get-OutputBinding :

Get-OutputBinding

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

Get-OutputBinding ayrıca, aşağıdaki örnekte olduğu gibi döndürülen bağlamayı filtrelemek için kullanılabilen adlı -Namebir parametre içerir:

Get-OutputBinding -Name MyQ*

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

Joker karakterler (*) Get-OutputBinding içinde desteklenir.

Loglama

PowerShell işlevlerinde günlüğe kaydetme, normal PowerShell günlüğü gibi çalışır. Her çıktı akışına yazmak için günlük kaydı cmdlet'lerini kullanabilirsiniz. Her cmdlet İşlevler tarafından kullanılan bir günlük düzeyine eşler.

İşlevin günlükleme düzeyi	Günlük Kaydı cmdlet'i
Hata	`Write-Error`
Uyarı	`Write-Warning`
Bilgiler	`Write-Information` `Write-Host` `Write-Output` `Information` log düzeyine yazar.
Hata Ayıklama	`Write-Debug`
İzleme	`Write-Progress` `Write-Verbose`

Bu cmdlet'lerin yanı sıra, işlem hattına yazılan her şey günlük seviyesine Information yönlendirilir ve varsayılan PowerShell biçimlendirmesiyle görüntülenir.

Önemli

Write-Verbose veya Write-Debug cmdlet'lerini kullanmak ayrıntılı ve hata ayıklama düzeyinde günlüğe kaydetmeyi görmek için yeterli değildir. Ayrıca günlük düzeyi eşiğini de yapılandırmanız gerekir. Bu eşik, hangi günlük düzeyini gerçekten önemsediğinizi bildirir. Daha fazla bilgi edinmek için bkz İşlev uygulaması günlük düzeyini yapılandırma.

İşlev uygulamasının günlük düzeyini yapılandır.

Azure Functions, İşlevlerin günlüklere yazma biçimini denetlemeyi kolaylaştırmak için eşik düzeyini tanımlamanızı sağlar. Konsola yazılan tüm izlemelerin eşiğini ayarlamak için logging.logLevel.default dosyasındaki host.json özelliğini kullanın. Bu ayar, işlev uygulamanızdaki tüm işlevler için geçerlidir.

Aşağıdaki örnek, tüm işlevler için ayrıntılı günlük kaydını etkinleştirmek üzere eşiği ayarlar, bununla birlikte isimli MyFunction işlev için ise hata ayıklama günlüğünü etkinleştirmek üzere eşiği ayarlar.

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

Daha fazla bilgi için host.json başvurusu'na bakın.

Günlükleri görüntüleme

İşlev Uygulamanız Azure çalışıyorsa, izlemek için Application Insights'ı kullanabilirsiniz. İşlev günlüklerini görüntüleme ve sorgulama hakkında daha fazla bilgi edinmek için monitoring Azure Functions okuyun.

İşlev Uygulamanızı geliştirme amaçlı yerel olarak çalıştırıyorsanız, günlükler varsayılan olarak dosya sistemine kaydedilir. Konsoldaki günlükleri görmek için, İşlev Uygulamasını başlatmadan önce ortam değişkenini olarak AZURE_FUNCTIONS_ENVIRONMENT ayarlayınDevelopment.

Tetikleyiciler ve bağlama türleri

İşlev uygulamanızla kullanabileceğiniz birçok tetikleyici ve bağlama vardır. Tetikleyicilerin ve bağlamaların tam listesi için bkz . Desteklenen bağlamalar.

Tüm tetikleyiciler ve bağlamalar kodda birkaç gerçek veri türü olarak gösterilir:

Hash Tablosu
Dize
byte[]
Int
çift
HTTP İstek Bağlamı
HttpResponseContext

Bu listedeki ilk beş tür standart .NET türleridir. Son ikisi yalnızca HttpTrigger tetikleyicisi tarafından kullanılır.

İşlevlerinizdeki her bağlama parametresi bu türlerden biri olmalıdır.

HTTP tetikleyicileri ve bağlamaları

HTTP ve web kancası tetikleyicileri ve HTTP çıkış bağlamaları, HTTP mesajlaşmasını temsil etmek için istek ve yanıt nesnelerini kullanır.

İstek nesnesi

Senaryoya geçirilen istek nesnesi, HttpRequestContext türünde olup, aşağıdaki özelliklere sahiptir:

Özellik	Açıklama	Tür
`Body`	İsteğin gövdesini içeren bir nesne. `Body` veriler esas alınarak en iyi türe serileştirilir. Örneğin, veriler JSON ise hash tablosu olarak geçirilir. Veriler bir dizeyse, dize olarak geçirilir.	nesne
`Headers`	İstek üst bilgilerini içeren bir sözlük.	Sözlük<string,string>^*
`Method`	İsteğin HTTP yöntemi.	Dize
`Params`	İsteğin yönlendirme parametrelerini içeren bir nesne.	Sözlük<string,string>^*
`Query`	Sorgu parametrelerini içeren bir nesne.	Sözlük<string,string>^*
`Url`	İsteğin URL'si.	Dize

^* Tüm Dictionary<string,string> anahtarlar büyük/küçük harfe duyarlı değildir.

Yanıt nesnesi

Geri göndermeniz gereken yanıt nesnesi, aşağıdaki özelliklere sahip olan türündedir HttpResponseContext:

Özellik	Açıklama	Tür
`Body`	Yanıtın gövdesini içeren bir nesne.	nesne
`ContentType`	Yanıt için içerik türünü ayarlamak için kısa bir el.	Dize
`Headers`	Yanıt üst bilgilerini içeren bir nesne.	Sözlük veya Karma Tablo
`StatusCode`	Yanıtın HTTP durum kodu.	string veya int

İstek ve yanıta erişme

HTTP tetikleyicileriyle çalışırken, HTTP isteğine diğer giriş bağlamalarıyla yaptığınız gibi erişebilirsiniz. O param bloğunda.

HttpResponseContext Aşağıdaki örnekte gösterildiği gibi yanıt döndürmek için bir nesne kullanın:

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

Bu işlevi çağırmanın sonucu şu olacaktır:

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

Tetikleyiciler ve bağlamalar için tür atama

Blob bağlaması gibi bazı bağlamalar için parametresinin türünü belirtebilirsiniz.

Örneğin, Blob depolamadan alınan verilerin dize olarak sağlanması için bloğuma param aşağıdaki tür atamasını ekleyin:

param([string] $myBlob)

PowerShell profili

PowerShell'de PowerShell profili kavramı vardır. PowerShell profilleri hakkında bilginiz yoksa Profiller Hakkında kısmına bakın.

PowerShell İşlevleri'nde, profil betiği ilk dağıtıldığında ve boşta kaldığında (soğuk başlangıç) uygulamadaki PowerShell çalışan örneği başına bir kez yürütülür. PSWorkerInProcConcurrencyUpperBound değeri ayarlanarak eşzamanlılık etkinleştirildiğinde, oluşturulan her çalışma alanı için profil betiği çalıştırılır.

Visual Studio Code ve Azure Functions Core Tools gibi araçları kullanarak bir işlev uygulaması oluşturduğunuzda, sizin için varsayılan bir profile.ps1 oluşturulur. Varsayılan profil, Core Tools GitHub deposunda korunur ve şunları içerir:

Azure için otomatik MSI kimlik doğrulaması.
Azure PowerShell AzureRM PowerShell diğer adlarını açma özelliğini istersen kullanabilirsin.

PowerShell sürümleri

Aşağıdaki tabloda İşlevler çalışma zamanının her ana sürümü için kullanılabilen PowerShell sürümleri ve gerekli .NET sürümü gösterilmektedir:

İşlevler sürümü	PowerShell sürümü	.NET sürümü
4.x	PowerShell 7.4	.NET 8
4.x	PowerShell 7.2 (destek sona eriyor)	.NET 6

Herhangi bir işlevden yazdırarak $PSVersionTable geçerli sürümü görebilirsiniz.

Azure Functions çalışma zamanı destek ilkesi hakkında daha fazla bilgi edinmek için bu makaleye başvurun.

Not

Azure Functions PowerShell 7.2 desteği 8 Kasım 2024'te sona erer. PowerShell 7.2 işlevlerinizi PowerShell 7.4'te çalışacak şekilde yükseltirken bazı hataya neden olan değişiklikleri çözmeniz gerekebilir. PowerShell 7.4'e yükseltmek için bu migration kılavuzunu izleyin.

Belirli bir sürümde yerel çalıştırma

PowerShell işlevlerini yerel olarak çalıştırdığınızda, ayarı "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"Values proje kökündeki local.setting.json dosyasındaki diziye eklemeniz gerekir. PowerShell 7.4'te yerel olarak çalışırken, local.settings.json dosyanız aşağıdaki örneğe benzer:

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

Not

PowerShell İşlevleri'nde, FUNCTIONS_WORKER_RUNTIME_VERSION için "~7" değeri "7.0.x" anlamına gelir. "~7" içeren PowerShell İşlevi uygulamalarını otomatik olarak "7.4" sürümüne yükseltmeyiz. Bundan sonra PowerShell İşlev Uygulamaları için uygulamaların hedeflemek istedikleri ana ve ikincil sürümü belirtmesini zorunlu kılarız. "7.4.x"i hedeflemek istiyorsanız "7.4" denmesi gerekir

PowerShell sürümünü değiştirme

PowerShell işlev uygulamanızı PowerShell 7.4'e geçirmeden önce şu noktaları dikkate alın:

Geçiş, uygulamanızda hataya neden olabilecek değişikliklere neden olabileceğinden, uygulamanızı PowerShell 7.4'e yükseltmeden önce bu migration guide gözden geçirin.
İşlev uygulamanızın Azure'daki İşlevler çalışma zamanının en son sürümünde çalıştığından emin olun. Bu sürüm 4.x'tir. Daha fazla bilgi için bkz. Geçerli çalışma zamanı sürümünü görüntüleme.

İşlev uygulamanız tarafından kullanılan PowerShell sürümünü değiştirmek için aşağıdaki adımları kullanın. Bu işlemi Azure portalında veya PowerShell kullanarak gerçekleştirebilirsiniz.

Portal
PowerShell

Azure portalında işlev uygulamanıza göz atın.
Ayarlar'ın altında Yapılandırma'yı seçin. Genel ayarlar sekmesinde PowerShell sürümünü bulun.
İstediğiniz PowerShell Core sürümünü seçin ve Kaydet'i seçin. Bekleyen yeniden başlatma hakkında uyarıldığında Devam'ı seçin. İşlev uygulaması seçilen PowerShell sürümünde yeniden başlatılır.

Not

PowerShell 7.4 için Azure Functions desteği genel kullanıma sunulmuştur (GA). PowerShell 7.4'in Azure portalında hala önizleme olarak gösterildiğini görebilirsiniz, ancak bu değer yakında GA durumunu yansıtacak şekilde güncelleştirilecektir.

PowerShell sürümünü değiştirmek için aşağıdaki betiği çalıştırın:

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> ve <FUNCTION_APP> yerine sırasıyla Azure aboneliğinizin kimliğini, kaynak grubunuzun ve işlev uygulamanızın adını yazın. Ayrıca, <VERSION>'yi 7.4 ile değiştirin. Döndürülen karma tablosunda powerShellVersion ayarının Properties içindeki güncelleştirilmiş değerini doğrulayabilirsiniz.

yapılandırmada değişiklik yapıldıktan sonra işlev uygulaması yeniden başlatılır.

Bağımlılık yönetimi

PowerShell'de yazılmış Azure Functions modülleri yönetmeye iki şekilde yaklaşılabilir: Yönetilen Bağımlılıklar özelliğini kullanma veya modülleri doğrudan uygulama içeriğinize ekleme. Her yöntemin kendi avantajları vardır ve doğru yöntemi seçmek kendi ihtiyaçlarınıza bağlıdır.

Doğru modül yönetimi yaklaşımını seçme

Yönetilen Bağımlılıklar özelliğini neden kullanmalısınız?

Basitleştirilmiş ilk yükleme: Dosyanıza requirements.psd1 göre modül yüklemesini otomatik olarak işler.
Otomatik yükseltmeler: Modüller, el ile müdahaleye gerek kalmadan güvenlik düzeltmeleri de dahil olmak üzere otomatik olarak güncelleştirilir.

Modüller neden uygulama içeriğine dahil?

PowerShell Gallery'e bağımlılık yok: Modüller uygulamanızla birlikte paketlenir, böylece dış bağımlılıklar ortadan kaldırılır.
Daha fazla denetim: Otomatik yükseltmelerin neden olduğu regresyon riskini önler ve hangi modül sürümlerinin kullanıldığı üzerinde tam denetim sağlar.
Uyumluluk: Esnek Tüketim üzerinde çalışır ve diğer Linux SKU'ları için önerilir.

Yönetilen Bağımlılıklar özelliği

Yönetilen Bağımlılıklar özelliği, Azure Functions requirements.psd1 dosyasında belirtilen PowerShell modüllerini otomatik olarak indirmesine ve yönetmesine olanak tanır. Bu özellik, yeni PowerShell işlev uygulamalarında varsayılan olarak etkindir.

Requirements.psd1'i yapılandırma

Azure Functions ile PowerShell'de Yönetilen Bağımlılıkları kullanmak için bir requirements.psd1 dosyası yapılandırmanız gerekir. Bu dosya işlevinizin gerektirdiği modülleri belirtir ve Azure Functions ortamınızın up-togüncel kalmasını sağlamak için bu modülleri otomatik olarak indirir ve güncelleştirir.

Dosyayı şu şekilde ayarlayabilir ve yapılandırabilirsiniz requirements.psd1 :

henüz yoksa, Azure İşlevinizin kök dizininde bir requirements.psd1 dosyası oluşturun.
Modülleri ve sürümlerini bir PowerShell veri yapısında tanımlayın.

Örnek requirements.psd1 dosyası:

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

Uygulama içeriğine modüller dahil

Modül sürümleriniz üzerinde daha fazla denetim sahibi olmak ve dış kaynaklara bağımlılıklardan kaçınmak için modülleri doğrudan işlev uygulamanızın içeriğine ekleyebilirsiniz.

Özel modüller eklemek için:

İşlev uygulamanızın kökünde bir Modules klasör oluşturun.
```
mkdir ./Modules
```
Aşağıdaki yöntemlerden birini kullanarak modülleri Modules klasöre kopyalayın:
- Modüller yerel olarak zaten kullanılabilir durumdaysa:
```
Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse
```
- PowerShell Galerisi'nden Save-Module kullanarak alma:
```
Save-Module -Name MyCustomModule -Path ./Modules
```
- Save-PSResource modülünden PSResourceGet kullanarak:
```
Save-PSResource -Name MyCustomModule -Path ./Modules
```

İşlev uygulamanız aşağıdaki yapıya sahip olmalıdır:

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

İşlev uygulamanızı başlattığınızda, PowerShell dil işçisi bu Modules klasörünü $env:PSModulePath öğesine ekler, böylece normal bir PowerShell betiğinde olduğu gibi modül otomatik yüklemesine güvenebilirsiniz.

Not

İşlev uygulamanız kaynak denetimi altındaysa, eklediğiniz Modules klasöründeki tüm içeriğin .gitignore tarafından dışlanmadığını onaylamanız gerekir. Örneğin, modüllerinizden birinin dışlanan bir bin klasörü varsa, bin ile değiştirip .gitignore dosyanızı değiştirmeyi isteyebilirsiniz:

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

Yönetilen Bağımlılıklarla İlgili Sorunları Giderme

Yönetilen Bağımlılıkları Etkinleştirme

Yönetilen Bağımlılıklar'ın çalışması için özelliğin host.json etkinleştirilmesi gerekir:

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

Belirli sürümleri hedefleme

Belirli modül sürümlerini hedeflerken, doğru modül sürümünün yüklendiğinden emin olmak için aşağıdaki adımların her ikisini de izlemek önemlidir:

modül sürümünü içinde requirements.psd1belirtin:
```
@{
  'Az.Accounts' = '1.9.5'
}
```

profile.ps1 kısmına bir import ifadesi ekleyin:

Import-Module Az.Accounts -RequiredVersion '1.9.5'

Bu adımların izlenmesi, işleviniz başlatıldığında belirtilen sürümün yüklendiğinden emin olur.

Belirli Yönetilen Bağımlılık aralığı ayarlarını yapılandırma

Aşağıdaki uygulama ayarlarını kullanarak Yönetilen Bağımlılıkların nasıl indirildiğini ve yükleneceğini yapılandırabilirsiniz:

Ayarlar	Varsayılan Değer	Açıklama
Maksimum Arka Plan Yükseltme Süresi	`7.00:00:00` (yedi gün)	PowerShell işlev uygulamaları için arka plan güncelleştirme süresini denetler.
MDNewSnapshotCheckPeriod	`01:00:00` (bir saat)	PowerShell çalışanının güncelleştirmeleri ne sıklıkta denetleyişini belirtir.
MDMinBackgroundUpgradePeriod	`1.00:00:00` (bir gün)	Yükseltme denetimleri arasındaki en düşük süre.

Bağımlılık yönetimiyle ilgili dikkat edilmesi gerekenler

İnternet Erişimi: Yönetilen Bağımlılıklar, modülleri indirmek için https://www.powershellgallery.com erişim gerektirir. Güvenlik duvarı/sanal ağ kurallarını gerektiği gibi değiştirmek de dahil olmak üzere ortamınızın bu erişime izin verdiğinden emin olun. Gerekli uç noktalar , Sorun Giderme Cmdlet'leri bölümünde açıklanmıştır. Bu uç noktalar gerektiği gibi izin verme listesine eklenebilir.
Lisans Kabulü: Yönetilen Bağımlılıklar, lisans kabulü gerektiren modülleri desteklemez.
Esnek Tüketim Planı: Yönetilen Bağımlılıklar özelliği Esnek Tüketim planında desteklenmez. Bunun yerine özel modüller kullanın.
Modül Konumları: Yerel bilgisayarınızda modüller genellikle içindeki $env:PSModulePathgenel olarak kullanılabilir klasörlerden birine yüklenir. Azure'da çalışırken, bir PowerShell işlev uygulamasının $env:PSModulePath normal bir PowerShell betiğindeki $env:PSModulePath farklıdır ve hem uygulama içeriğiniz ile karşıya yüklenen Modules klasörünü hem de Yönetilen Bağımlılıklar tarafından yönetilen ayrı bir konumu içerir.

Ortam değişkenleri

İşlevler'de, hizmet bağlantı dizesi gibi uygulama ayarları yürütme sırasında ortam değişkenleri olarak sunulur. Aşağıdaki örnekte gösterildiği gibi kullanarak $env:NAME_OF_ENV_VARbu ayarlara erişebilirsiniz:

param($myTimer)

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

İşlev uygulaması ayarlarını eklemenin, güncelleştirmenin ve silmenin birkaç yolu vardır:

İşlev uygulaması ayarlarında yapılan değişiklikler, işlev uygulamanızın yeniden başlatılmasını gerektirir.

Yerel olarak çalıştırıldığında, uygulama ayarları local.settings.json proje dosyasından okunur.

Eşzamanlılık

Varsayılan olarak, İşlevler PowerShell çalışma zamanı bir kerede bir işlevin yalnızca bir çağrısını işleyebilir. Ancak, bu eşzamanlılık düzeyi aşağıdaki durumlarda yeterli olmayabilir:

Aynı anda çok sayıda çağrıyı işlemeye çalıştığınızda.
Aynı işlev uygulamasının içinde diğer işlevleri çağıran işlevleriniz olduğunda.

İş yükünün türüne bağlı olarak keşfedebileceğiniz birkaç eşzamanlılık modeli vardır:

Artırın FUNCTIONS_WORKER_PROCESS_COUNT. Bu ayarın artırılması, aynı örnekteki birden çok işlemdeki işlev çağrılarının işlenmesine olanak tanır ve bu da belirli CPU ve bellek ek yükü getirir. Genel olarak G/Ç'ye bağlı işlevler bu ek yükten zarar görmez. CPU'ya bağlı işlevler için etki önemli olabilir.
PSWorkerInProcConcurrencyUpperBound Uygulama ayarı değerini artırın. Bu ayarın artırılması, aynı işlem içinde birden çok çalışma alanı oluşturulmasına olanak tanır ve bu da CPU ve bellek ek yükünü önemli ölçüde azaltır.

Bu ortam değişkenlerini işlev uygulamanızın uygulama ayarlarında ayarlarsınız.

Kullanım örneğine bağlı olarak Durable Functions ölçeklenebilirliği önemli ölçüde iyileştirebilir. Daha fazla bilgi edinmek için bkz. Durable Functions uygulama desenleri.

Not

"Kullanılabilir çalışma alanları olmadığından istekler kuyruğa alınıyor" uyarılarını alabilirsiniz. Bu ileti bir hata değil. İleti, isteklerin kuyruğa alındığını söylüyor. Bunlar, önceki istekler tamamlandığında işlenir.

Eşzamanlılık kullanımıyla ilgili dikkat edilmesi gerekenler

PowerShell varsayılan olarak single_threaded bir betik dilidir. Ancak eşzamanlılık, aynı işlemde birden çok PowerShell çalışma alanı kullanılarak eklenebilir. Oluşturulan çalışma alanı sayısı ve dolayısıyla çalışan başına eş zamanlı iş parçacığı sayısı, uygulama ayarıyla PSWorkerInProcConcurrencyUpperBound sınırlıdır. Varsayılan olarak, çalışma alanı sayısı İşlevler çalışma zamanının 4.x sürümünde 1.000 olarak ayarlanır. 3.x ve altındaki sürümlerde en fazla çalışma alanı sayısı 1 olarak ayarlanır. İşlev uygulamanızın aktarım hızı, seçilen planda kullanılabilir CPU ve bellek miktarından etkilenir.

Azure PowerShell fazla yazmadan tasarruf etmenizi sağlamak için bazı process-level bağlamları ve durumlarını kullanır. Ancak, işlev uygulamanızda eşzamanlılığı açarsanız ve durumu değiştiren eylemleri çağırırsanız yarış koşulları meydana gelebilir. Bir çağrı belirli bir duruma bağlı olduğundan ve diğer çağrı durumu değiştirdiğinden bu yarış koşullarının hata ayıklaması zordur.

Bazı işlemler önemli ölçüde zaman alabileceğinden, Azure PowerShell ile eşzamanlılıkta çok büyük bir değer vardır. Ancak dikkatli olmanız gerekir. Bir yarış durumuyla karşılaştığınızı düşünüyorsanız PSWorkerInProcConcurrencyUpperBound uygulama ayarını 1 olarak ayarlayın ve bunun yerine eşzamanlılık için dil çalışanı işlem düzeyi yalıtımını kullanın.

İşlev scriptFile'ı yapılandırma

Varsayılan olarak, bir PowerShell işlevi, karşılık gelen run.ps1ile aynı üst dizini paylaşan bir dosyasından yürütülürfunction.json.

içindeki scriptFilefunction.json özelliği, aşağıdaki örneğe benzer bir klasör yapısı almak için kullanılabilir:

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

Bu durumda, function.json for myFunction işlevi, çalıştırılacak dışarı aktarılan işleve sahip dosyaya başvuran bir scriptFile özellik içerir.

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

EntryPoint yapılandırarak PowerShell modüllerini kullanma

Bu makaledeki PowerShell işlevleri, şablonlar tarafından oluşturulan varsayılan run.ps1 betik dosyasıyla gösterilir. Ancak, işlevlerinizi PowerShell modüllerine de ekleyebilirsiniz. Belirli işlev kodunu scriptFile ve entryPoint alanlarını kullanarak function.json yapılandırma dosyasında modülde referans alabilirsiniz.

Bu durumda, entryPoint içinde başvuruda bulunan PowerShell modülündeki bir işlevin veya cmdlet'in adıdır scriptFile.

Aşağıdaki klasör yapısını göz önünde bulundurun:

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

İçerir:PSFunction.psm1

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

Bu örnekte, myFunction için yapılandırma, başka bir klasördeki bir PowerShell modülü olan scriptFile öğesine atıfta bulunan bir PSFunction.psm1 özelliği içerir. entryPoint özelliği modüldeki Invoke-PSTestFunc giriş noktası olan işleve başvurur.

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

Bu yapılandırmayla, Invoke-PSTestFunc tam olarak bir run.ps1 gibi yürütülür.

PowerShell işlevleri için dikkat edilmesi gerekenler

PowerShell işlevleriyle çalışırken, aşağıdaki bölümlerde dikkat edilmesi gereken noktalara dikkat edin.

Soğuk Başlangıç

sunucusuz barındırma modelinde Azure Functions geliştirirken soğuk başlangıçlar gerçektir. Soğuk başlangıç , işlev uygulamanızın bir isteği işlemek için çalışmaya başlaması için geçen süreyi ifade eder. İşlev uygulamanızın etkinlik dışı dönemlerde kapatılması nedeniyle, Tüketim planında soğuk başlatma daha sık gerçekleşir.

Install-Module kullanmaktan kaçının

her çağrıda işlev betiğinizde çalıştırmak Install-Module performans sorunlarına neden olabilir. Bunun yerine, gerekli modülleri paketlemek için işlev uygulamanızı yayımlamadan önce Save-Module veya Save-PSResource kullanın.

Daha fazla bilgi için bkz . Bağımlılık yönetimi.

Sonraki adımlar

Daha fazla bilgi edinmek için aşağıdaki kaynaklara bakın:

Azure Functions için en iyi uygulamalar
Azure Functions geliştirici başvurusu
Azure Functions tetikleyicileri ve bağlamaları

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-03-11