Azure İşlevleri PowerShell geliştirici kılavuzu

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 Tetikleyiciler ve bağlama makalesine bakın.

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 başvuruyu zaten okuduğunuz varsayılır. İlk PowerShell işlevinizi oluşturmak için PowerShell için İşlevler hızlı başlangıcını da tamamlamış olmanız gerekir.

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 aşağıdaki 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 bin tanımlanırextensions.csproj. 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, isteğe bağlı olarak bir profile.ps1 işlev uygulaması çalışmaya başladığında (aksi takdirde soğuk başlangıç olarak bilindiğinde) çalışan bir uygulamanız olabilir. 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ütmede bir dizi 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. Ek 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	DateTime
MethodName	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çerirDequeueCountInsertionTimeId.QueueTrigger 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 çeşitli yollarla bağlamalarla 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 Push-OutputBinding karşılık gelirName.

Aşağıda, 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ümlenemediğinde 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ı	Tip	Position	Açıklama
-Name	String	1	Ayarlamak istediğiniz çıkış bağlamasının adı.
-Value	Object	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:

PS >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.

PS >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:

PS >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:

PS >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".

PS >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:

PS >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.

Geçerli bağlama değerlerini döndürmek için kullanma Get-OutputBinding örneği aşağıda verilmiştir:

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 Analizler 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 Development ayarlayınAZURE_FUNCTIONS_ENVIRONMENT.

Tetikleyiciler ve bağlama türleri

İşlev uygulamanızla kullanabileceğiniz bir dizi tetikleyici ve bağlama vardır. Tetikleyicilerin ve bağlamaların tam listesine buradan ulaşabilirsiniz.

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

• Hashtable
• Dize
• bayt[]
• int
• çift
• HttpRequestContext
• 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 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:

PS > 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.2	.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 lütfen bu makaleye bakın

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

Azure İşlevleri PowerShell 7.0 desteği 3 Aralık 2022'de sona erdi. Yerel olarak çalışırken PowerShell 7.2'yi kullanmak içinValues, bu ayarı "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.2" proje kökündeki local.setting.json dosyasındaki diziye eklemeniz gerekir. PowerShell 7.2'de 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.2"
  }
}

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.2" 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ılacak. Bu nedenle, "7.2.x"i hedeflemek istiyorsanız "7.2" den bahsetmek gerekir

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

Azure İşlevleri PowerShell 7.0 desteği 3 Aralık 2022'de sona erdi. İşlev Uygulamanızı PowerShell 7.2'ye yükseltmek için FUNCTIONS_EXTENSION_VERSION değerinin ~4 olarak ayarlandığından emin olun. Bunun nasıl yapılacağını öğrenmek için bkz . Geçerli çalışma zamanı sürümünü görüntüleme ve güncelleştirme.

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

Portal

1. Azure portalında işlev uygulamanıza göz atın.

2. Ayarlar altında Yapılandırma'yı seçin. Genel ayarlar sekmesinde PowerShell sürümünü bulun.

   

3. İ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.

PowerShell

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

, <RESOURCE_GROUP>ve <FUNCTION_APP> yerine Azure aboneliğinizin kimliğini, sırasıyla kaynak grubunuzun ve işlev uygulamanızın adını yazın<SUBSCRIPTION_ID>. Ayrıca değerini ile 7.2değiştirin<VERSION>. 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

İşlevler, bağımlılıkları yönetmek için PowerShell galerisinden yararlanmanızı sağlar. Bağımlılık yönetimi etkinleştirildiğinde requirements.psd1 dosyası gerekli modülleri otomatik olarak indirmek için kullanılır. Aşağıdaki örnekte olduğu managedDependency gibi, özelliğini true host.json dosyasının kökünde olarak ayarlayarak bu davranışı etkinleştirirsiniz:

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

Yeni bir PowerShell işlevleri projesi oluşturduğunuzda bağımlılık yönetimi, Azure Az modülü de dahil olmak üzere varsayılan olarak etkinleştirilir. Şu anda desteklenen en fazla modül sayısı 10'dur. Desteklenen söz dizimi, aşağıdaki requirements.psd1 örneğinde gösterildiği gibi tam modül sürümüdür MajorNumber.* :

@{
	Az = '1.*'
	SqlServer = '21.1.18147'
}

requirements.psd1 dosyasını güncelleştirdiğinizde, güncelleştirilmiş modüller yeniden başlatıldıktan sonra yüklenir.

Belirli sürümleri hedefleme

Requirements.psd1 dosyanızda modülün belirli bir sürümünü hedeflemek isteyebilirsiniz. Örneğin, Az.Accounts'ın dahil edilen Az modülündekinden daha eski bir sürümünü kullanmak istiyorsanız, aşağıdaki örnekte gösterildiği gibi belirli bir sürümü hedeflemeniz gerekir:

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

Bu durumda, profile.ps1 dosyanızın en üstüne aşağıdaki örneğe benzer bir içeri aktarma deyimi de eklemeniz gerekir:

Import-Module Az.Accounts -RequiredVersion '1.9.5'

Bu şekilde işlev başlatıldığında önce Az.Account modülünün eski sürümü yüklenir.

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

Bağımlılık yönetimi kullanılırken aşağıdaki noktalar geçerlidir:

• Yönetilen bağımlılıklar, modülleri indirmek için https://www.powershellgallery.com erişim gerektirir. Yerel olarak çalışırken, çalışma zamanının gerekli güvenlik duvarı kurallarını ekleyerek bu URL'ye erişebildiğinden emin olun.

• Yönetilen bağımlılıklar şu anda kullanıcının lisansı etkileşimli olarak kabul ederek veya çağrılırken anahtar sağlayarak -AcceptLicense lisans kabul etmelerini gerektiren modülleri desteklememektedir Install-Module.

Bağımlılık yönetimi uygulama ayarları

Yönetilen bağımlılıkların indirilip yüklenme şeklini değiştirmek için aşağıdaki uygulama ayarları kullanılabilir.

İşlev Uygulaması ayarı	Varsayılan değer	Açıklama
MDMaxBackgroundUpgradePeriod	7.00:00:00 (yedi gün)	PowerShell işlev uygulamaları için arka plan güncelleştirme süresini denetler. Daha fazla bilgi edinmek için bkz . MDMaxBackgroundUpgradePeriod.
MDNewSnapshotCheckPeriod	01:00:00 (bir saat)	Her PowerShell çalışanının yönetilen bağımlılık yükseltmelerinin yüklenip yüklenmediğini ne sıklıkta denetlediğini belirtir. Daha fazla bilgi edinmek için bkz . MDNewSnapshotCheckPeriod.
MDMinBackgroundUpgradePeriod	1.00:00:00 (bir gün)	Başka bir yükseltme denetimi başlatılmadan önceki yükseltme denetiminden sonraki süre. Daha fazla bilgi edinmek için bkz . MDMinBackgroundUpgradePeriod.

Temelde, uygulama yükseltmeniz içinde MDMaxBackgroundUpgradePeriodbaşlar ve yükseltme işlemi yaklaşık MDNewSnapshotCheckPeriodiçinde tamamlar.

Özel modüller

Azure İşlevleri'da kendi özel modüllerinizden yararlanmanız, PowerShell için normal şekilde nasıl yapabileceğinizden farklıdır.

Yerel bilgisayarınızda modül, içindeki $env:PSModulePathgenel olarak kullanılabilir klasörlerden birine yüklenir. Azure'da çalışırken makinenizde yüklü modüllere erişiminiz yoktur. Bu, bir PowerShell işlev uygulaması için uygulamasının $env:PSModulePath normal bir PowerShell betiğinden $env:PSModulePath farklı olduğu anlamına gelir.

İşlevler'de iki PSModulePath yol içerir:

• Modules İşlev uygulamanızın kökünde bulunan bir klasör.
• PowerShell dil çalışanı tarafından denetlenen bir Modules klasörün yolu.

İşlev uygulaması düzeyinde modüller klasörü

Özel modülleri kullanmak için işlevlerinizin bağlı olduğu modülleri bir Modules klasöre yerleştirebilirsiniz. Bu klasörden modüller işlevler çalışma zamanı tarafından otomatik olarak kullanılabilir. İşlev uygulamasındaki herhangi bir işlev bu modülleri kullanabilir.

Not

requirements.psd1 dosyasında belirtilen modüller otomatik olarak indirilir ve yola eklenir, bu nedenle bunları modüller klasörüne eklemeniz gerekmez. Bunlar bulutta çalıştırıldığında klasörde ve /data/ManagedDependencies klasörde yerel olarak $env:LOCALAPPDATA/AzureFunctions depolanır.

Özel modül özelliğinden yararlanmak için işlev uygulamanızın kökünde bir Modules klasör oluşturun. İşlevlerinizde kullanmak istediğiniz modülleri bu konuma kopyalayın.

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

Bir Modules klasörle, işlev uygulamanızın aşağıdaki klasör yapısına sahip olması gerekir:

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 $env:PSModulePath yaptığınız gibi modül otomatik yüklemesine güvenebilmeniz için bu Modules klasörü öğesine ekler.

Dil çalışanı düzeyi modüller klasörü

PowerShell dil çalışanı tarafından yaygın olarak çeşitli modüller kullanılır. Bu modüller öğesinin son konumunda PSModulePathtanımlanır.

Modüllerin geçerli listesi aşağıdaki gibidir:

• Microsoft.PowerShell.Archive: , .nupkgve diğerleri gibi .ziparşivlerle çalışmak için kullanılan modül.
• ThreadJob: PowerShell iş API'lerinin iş parçacığı tabanlı uygulaması.

İşlevler varsayılan olarak bu modüllerin en son sürümünü kullanır. Belirli bir modül sürümünü kullanmak için bu belirli sürümü işlev uygulamanızın Modules klasörüne yerleştirin.

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:

• Azure portalda.
• Azure CLI kullanarak.
• Azure PowerShell kullanarak.

İş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:

• öğesini artırın FUNCTIONS_WORKER_PROCESS_COUNT. Bu, aynı örnek içindeki 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 muzdarip olmaz. CPU'ya bağlı işlevler için etki önemli olabilir.

• PSWorkerInProcConcurrencyUpperBound Uygulama ayarı değerini artırın. Bu, 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, 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, bunun bir hata olmadığını lütfen unutmayın. İleti, isteklerin kuyruğa alındığını ve önceki istekler tamamlandığında işleneceğini söylüyor.

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. 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 function.jsonile aynı üst dizini paylaşan bir dosyasından yürütülürrun.ps1.

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 makalede, şablonlar tarafından oluşturulan varsayılan run.ps1 betik dosyasında PowerShell işlevleri gösterilmiştir. Ancak, işlevlerinizi PowerShell modüllerine de ekleyebilirsiniz. function.json yapılandırma dosyasındaki ve entryPoint alanlarını kullanarak scriptFile 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 yerine modülleri paketleme

Betiğiniz her çağrıda çalıştırılır. Betiğinizde kullanmaktan Install-Module kaçının. Bunun yerine, işlevinizin modülü indirmek için zaman kaybetmemesi için yayımlamadan önce kullanın Save-Module . Soğuk başlangıçlar işlevlerinizi etkiliyorsa işlev uygulamanızı her zaman açık veya Premium plana ayarlanmış bir App Service planına dağıtmayı göz önünde bulundurun.

Sonraki adımlar

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

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