Azure İşlevleri PowerShell geliştirici kılavuzu

2025-05-08

Bu makalede, PowerShell kullanarak Azure İşlevleri 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 İşlevleri tetikleyiciler 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 İşlevleri 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ı, klasöründeki gerçek kitaplık dosyalarıyla birlikte dosyada extensions.csproj tanımlanırbin. 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ğinize yürütmeyle ilgili 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	işlevin bu yürütülmesi için benzersiz bir guid	Dize

Her tetikleyici türünün farklı bir meta veri kümesi vardır. Örneğin , $TriggerMetadata ve diğer öğeleri içerirQueueTriggerInsertionTimeId.DequeueCount 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 olarak ayarlanmıştır directionin . name içinde function.json tanımlanan özellik, bloğundaki parametresinin param adıdır. PowerShell bağlama için adlandırılmış parametreler kullandığından, parametrelerin sırası önemli değildir. Ancak, içinde tanımlanan bağlamaların sırasını izlemek en iyi yöntemdir function.json.

param($MyFirstInputBinding, $MySecondInputBinding)

Çıkış verileri yazma

İşlevler'de çıkış bağlamasının direction function.json olarak ayarlanmıştır out . İşlevler çalışma zamanı için kullanılabilen cmdlet'ini Push-OutputBinding kullanarak bir çıkış bağlamasına yazabilirsiniz. Her durumda, name bağlamanın içinde tanımlandığı function.json gibi özelliği cmdlet'in parametresine Name karşılık gelirPush-OutputBinding.

Aşağıdaki örnekte işlev betiğinizde nasıl çağrılacakları Push-OutputBinding 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, ikinci bir kez çağrılması Push-OutputBinding 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ğeri belirtilen çıkış bağlaması için ayarlanacak şekilde zorlar.

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, ikinci kez çağrıldığında Push-OutputBinding bir hata oluşur.

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 çıkış bağlaması

Push-OutputBindingAzure 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

Çıkış bağlamalarınız için ayarlanmış olan değerleri almak için cmdlet'ini kullanabilirsiniz Get-OutputBinding . Bu cmdlet, ilgili değerleriyle çıkış bağlamalarının adlarını içeren bir karma tablo alır.

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 (*) içinde Get-OutputBindingdesteklenir.

Günlük Kaydı

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

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

Bu cmdlet'lere ek olarak, işlem hattına yazılan her şey günlük düzeyine 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ı günlük düzeyini yapılandırma

Azure İşlevleri, İşlevler'in 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 dosyasındaki logging.logLevel.defaulthost.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 için eşiği ayarlar, ancak adlı MyFunctionişlev için hata ayıklama günlüğünü etkinleştirmek için eşiği ayarlar:

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

Daha fazla bilgi için bkz . host.json başvurusu.

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

İşlev Uygulamanız Azure'da ç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 izleme Azure İşlevleri okuyun.

İşlev Uygulamanızı geliştirme için yerel olarak çalıştırıyorsanız, varsayılan olarak dosya sistemini günlüğe kaydeder. 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
bayt[]
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

Betiğine geçirilen istek nesnesi, aşağıdaki özelliklere sahip olan türündedir HttpRequestContext:

Özellik	Açıklama	Tür
`Body`	İsteğin gövdesini içeren bir nesne. `Body` verileri temel alarak en iyi türe seri hale getirilir. Örneğin, veriler JSON ise karma tablo olarak geçirilir. Veriler bir dizeyse, dize olarak geçirilir.	nesne
`Headers`	İstek üst bilgilerini içeren bir sözlük.	Sözlük<dizesi,dize>^*
`Method`	İsteğin HTTP yöntemi.	Dize
`Params`	İsteğin yönlendirme parametrelerini içeren bir nesne.	Sözlük<dizesi,dize>^*
`Query`	Sorgu parametrelerini içeren bir nesne.	Sözlük<dizesi,dize>^*
`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.	dize 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. Blokta param .

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 bkz . Profiller hakkında.

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 İşlevleri Core Tools gibi araçları kullanarak bir işlev uygulaması oluşturduğunuzda, sizin için varsayılan bir varsayılan profile.ps1 oluşturulur. Varsayılan profil, Core Tools GitHub deposunda tutulur ve şunları içerir:

Azure'da otomatik MSI kimlik doğrulaması.
İstersensiniz Azure PowerShell PowerShell AzureRM diğer adlarını açabilirsiniz.

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 İşlevleri çalışma zamanı destek ilkesi hakkında daha fazla bilgi edinmek için bu makaleye bakın

Not

Azure İşlevleri 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 geçiş 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 olan değişikliklere neden olabileceğinden, uygulamanızı PowerShell 7.4'e yükseltmeden önce bu geçiş kılavuzunu 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 İşlevleri desteği genel kullanıma sunulmuştur (GA). Azure portalında PowerShell 7.4'un 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>ve <RESOURCE_GROUP> yerine Azure aboneliğinizin kimliğini, sırasıyla kaynak grubunuzun ve işlev uygulamanızın adını yazın<FUNCTION_APP>. Ayrıca değerini ile <VERSION>değiştirin7.4. Döndürülen karma tablosundaki ayarın powerShellVersionProperties 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 İşlevleri 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 Galerisi bağımlılığı yok: Modüller uygulamanızla birlikte paketlenir ve dış bağımlılıkları ortadan kaldırı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 İşlevleri dosyada belirtilen PowerShell modüllerini otomatik olarak indirmesine ve yönetmesine requirements.psd1 olanak tanır. Bu özellik, yeni PowerShell işlev uygulamalarında varsayılan olarak etkindir.

Requirements.psd1'i yapılandırma

powershell ile Azure İşlevleri yönetilen bağımlılıkları kullanmak için bir requirements.psd1 dosya yapılandırmanız gerekir. Bu dosya işlevinizin gerektirdiği modülleri belirtir ve Azure İşlevleri ortamınızın gü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 dosya 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
```
- Save-Module almak için kullanma:
```
Save-Module -Name MyCustomModule -Path ./Modules
```
- Save-PSResource kullanarak PSResourceGet:
```
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 çalışanı, normal bir PowerShell betiğinde Modules yaptığınız gibi modül otomatik yüklemesine güvenebilmeniz için bu $env:PSModulePath klasörü öğesine ekler.

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 bölme klasörü varsa şununla değiştirerek bin .gitignore dosyasını değiştirmek 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'
}
```

içine profile.ps1bir içeri aktarma deyimi 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:

Ayar	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, $env:PSModulePath bir PowerShell işlev uygulaması için normal bir PowerShell komut dosyasından $env:PSModulePath farklıdır ve hem uygulama içeriğinizle yüklenmiş klasörü 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 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ğinize bağlı olarak Dayanıklı İşlevler ölçeklenebilirliği önemli ölçüde iyileştirebilir. Daha fazla bilgi edinmek için bkz. Dayanıklı İşlevler 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 yazma işleminden tasarruf etmenizi sağlamak için bazı işlem düzeyinde bağlamlar ve durum kullanır. Ancak işlev uygulamanızda eşzamanlılığı açar ve durumu değiştiren eylemleri çağırırsanız yarış koşullarıyla sonuçlanabilirsiniz. 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.

Azure PowerShell ile eşzamanlılık açısından çok büyük bir değer vardır çünkü bazı işlemler çok uzun sürebilir. 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 betiğini yapılandırmaDosya

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. function.json yapılandırma dosyasındaki ve scriptFile alanlarını kullanarak entryPoint modüldeki belirli işlev koduna başvurabilirsiniz.

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, için myFunction yapılandırması, başka bir klasördeki bir scriptFile PowerShell modülü olan öğesine başvuran PSFunction.psm1bir özellik 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, tam Invoke-PSTestFunc olarak bir run.ps1 şekilde 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 İşlevleri 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 etkinlik dışı dönemlerde kapatılmalarından dolayı, 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 veya Save-Module kullanınSave-PSResource.

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:

Aracılığıyla paylaş