Azure İşlevleri PowerShell geliştirici kılavuzu

Bu makalede, PowerShell kullanarak Azure Işlevleri yazma hakkında ayrıntılı bilgi sağlanır.

Bir 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 function.json davranacağını, örneğin nasıl tetikleneceğini ve giriş ve çıkış parametrelerini tanımlayan ilgili bir dosya içerir. Daha fazla bilgi edinmek için Tetikleyiciler ve bağlama makalesinebakın.

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

Bu makalede, Azure işlevleri geliştirici başvurusunuzaten okuduğunuzu varsaymış olursunuz. İlk PowerShell işlevinizi oluşturmak için PowerShell için hızlı başlangıç işlevleri de tamamlanmış olmalıdır.

Klasör yapısı

PowerShell projesi için gereken 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, host.json işlev uygulamasını yapılandırmak için kullanılabilecek paylaşılan bir dosya vardır. Her işlevde kendi kod dosyası (.ps1) ve bağlama yapılandırma dosyası () içeren bir klasör vardır function.json . Dosyanın üst dizinindeki function.jsadı her zaman işlevinizin adıdır.

Belirli bağlamalar bir dosya varlığını gerektirir extensions.csproj . Sürüm 2. x ve sonraki sürümlerde işlevler çalışma zamanının gerekli olan bağlama uzantıları, extensions.csproj dosyasında, klasördeki gerçek kitaplık dosyaları ile tanımlanmıştır bin . Yerel olarak geliştirme yaparken, bağlama uzantılarını kaydetmenizgerekir. Azure portal işlevler geliştirirken, bu kayıt sizin için yapılır.

PowerShell Işlev uygulamalarında, bir işlev uygulaması çalışmaya başladığında isteğe bağlı olarak bir profile.ps1 çalışır (Aksi takdirde, soğuk bir başlangıç olarak bilinir. Daha fazla bilgi için bkz. PowerShell profili.

Bir PowerShell betiğini işlev olarak tanımlama

Varsayılan olarak, Işlevler çalışma zamanı ' de işlevinize bakar run.ps1 ve run.ps1 buna karşılık olarak aynı üst dizini paylaşır function.json .

Betiğinizin yürütme sırasında bir dizi bağımsız değişkeni geçti. Bu parametreleri işlemek için, param betiğinizin en üstüne aşağıdaki örnekte olduğu gibi bir 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

TriggerMetadataParametresi, 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 hepsi sys aşağıdaki verileri içeren bir özellik içerir:

$TriggerMetadata.sys
Özellik Açıklama Tür
UtcNow UTC olarak işlev tetiklendiğinde DateTime
MethodName Tetiklenen Işlevin adı string
RandGuid işlevin bu yürütmeye yönelik benzersiz bir GUID string

Her tetikleyici türünün farklı bir meta veri kümesi vardır. Örneğin, için, $TriggerMetadata QueueTrigger InsertionTime Id DequeueCount diğer şeyleri kapsayan,,,. Sıra tetikleyicisinin meta verileri hakkında daha fazla bilgi için, sıra tetikleyicilerinin resmi belgelerinegidin. Tetikleyici meta verilerinin içinde neler olduğunu görmek için, üzerinde çalıştığınız tetikleyicilerle ilgili belgelere bakın.

Bağlamalar

PowerShell 'de bağlamalar , üzerinde bir işlevin function.jsyapılandırılır ve tanımlanır. İşlevler, bağlamalarla çeşitli yollarla etkileşime geçin.

Tetikleyici ve giriş verilerini okuma

Tetikleyici ve giriş bağlamaları, işleviniz için parametre olarak okunabilir. Giriş bağlamalarında direction function.jsüzerinde bir kümesi vardır in . nameİçinde tanımlanan özelliği, function.json bloğundaki parametrenin adıdır param . PowerShell, bağlama için adlandırılmış parametreler kullandığından, parametrelerin sırası bu şekilde değildir. Ancak, içinde tanımlanan bağlamaların sırasını izlemek en iyi uygulamadır function.json .

param($MyFirstInputBinding, $MySecondInputBinding)

Çıkış verileri yazma

Işlevlerde, bir çıkış bağlamasının direction üzerinde function.jsiçin bir kümesi vardır out . Push-OutputBindingİşlevler çalışma zamanı için kullanılabilen cmdlet 'ini kullanarak bir çıktı bağlamaya yazabilirsiniz. Her durumda, name içinde tanımlandığı şekilde bağlamanın özelliği function.json Name cmdlet 'in parametresine karşılık gelir Push-OutputBinding .

Aşağıda, Push-OutputBinding işlev betiğinizde nasıl çağrılacağını 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 belirtilen değere göre farklı davranır -Name :

  • Belirtilen ad geçerli bir çıkış bağlamasıyla çözülemezse bir hata oluşur.

  • Çıkış bağlaması bir değer koleksiyonunu kabul ettiğinde, Push-OutputBinding birden fazla değeri göndermek için tekrar tekrar çağırabilirsiniz.

  • Çıkış bağlaması yalnızca bir tek değeri kabul ettiğinde, Push-OutputBinding ikinci kez çağırma bir hata oluşturur.

Push-OutputBinding sözdizimi

Çağırmak için geçerli parametreler aşağıda verilmiştir Push-OutputBinding :

Ad Tür Konum Description
-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 Adlandırılır Seçim Belirtildiğinde, belirtilen bir çıkış bağlaması için değeri ayarlamaya 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 örnek: HTTP yanıtları

HTTP tetikleyicisi adlı çıkış bağlamasını kullanarak bir yanıt döndürür response . 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"
})

Çıktı yalnızca tek bir değer kabul eden HTTP 'e ait olduğundan, Push-OutputBinding ikinci kez çağrıldığında bir hata oluşur.

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

Yalnızca Singleton değerlerini kabul eden çıkışlar için, -Clobber bir koleksiyona eklemeye çalışmak yerine eski değeri geçersiz kılmak için parametresini kullanabilirsiniz. Aşağıdaki örnek, daha önce bir değer eklediğinizi varsayar. Kullanarak -Clobber , aşağıdaki örnekteki yanıt, "çıkış #3" değeri döndürecek varolan değeri geçersiz kılar:

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

Push-OutputBinding örnek: kuyruk çıktı bağlaması

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, sıraya yazılan ileti "output #1" değerine sahiptir:

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

Depolama kuyruğu için çıkış bağlaması birden çok çıkış değeri kabul eder. Bu durumda, iki öğe içeren bir listeyi kuyruğa yazmaya sonra aşağıdaki örneği çağırmak: "output #1" ve "output #2".

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

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

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

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

Get-OutputBinding cmdlet 'i

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

Aşağıda Get-OutputBinding geçerli bağlama değerlerini döndürmek için kullanılan bir örneği verilmiştir:

Get-OutputBinding
Name                           Value
----                           -----
MyQueue                        myData
MyOtherQueue                   myData

Get-OutputBinding Ayrıca -Name , aşağıdaki örnekte olduğu gibi döndürülen bağlamayı filtrelemek için kullanılabilen adlı bir parametresini de içerir:

Get-OutputBinding -Name MyQ*
Name                           Value
----                           -----
MyQueue                        myData

Joker karakterler (*) ' de desteklenir Get-OutputBinding .

Günlüğe Kaydetme

PowerShell işlevlerinde günlüğe kaydetme, normal PowerShell günlüğü gibi çalışır. Günlük cmdlet 'lerini her bir çıkış akışına yazmak için kullanabilirsiniz. Her cmdlet, Işlevleri tarafından kullanılan bir günlük düzeyiyle eşlenir.

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

Bu cmdlet 'lere ek olarak, işlem hattına yazılan her şey Information günlük düzeyine yönlendirilir ve varsayılan PowerShell biçimlendirmesi ile görüntülenir.

Önemli

Write-VerboseVeya Write-Debug cmdlet 'lerinin kullanılması, ayrıntılı ve hata ayıklama düzeyinde günlüğe kaydetmeyi görmek için yeterli değildir. Ayrıca, gerçekten önem verdiğiniz günlükleri bildiren günlük düzeyi eşiğini da yapılandırmanız gerekir. Daha fazla bilgi için bkz. işlev uygulaması günlük düzeyini yapılandırma.

İşlev uygulaması günlük düzeyini yapılandırma

Azure Işlevleri, Işlevlerin günlüklere yazma yöntemini denetlemenizi 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.defaulthost.js[ host.json dosyadaki] özelliği[ başvuru üzerinde]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, ancak şu adlı bir işlev için hata ayıklama günlüğünü etkinleştirmek üzere eşiği ayarlar MyFunction :

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

Daha fazla bilgi için bkz. [host.jsbaşvurusu].

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

İşlev Uygulaması Azure 'da çalışıyorsa, bunu izlemek için Application Insights kullanabilirsiniz. İşlev günlüklerini görüntüleme ve sorgulama hakkında daha fazla bilgi edinmek için Azure işlevlerini izleme makalesini okuyun.

Geliştirme için İşlev Uygulaması yerel olarak çalıştırıyorsanız, varsayılan olarak dosya sistemine kaydedilir. Konsolunda günlükleri görmek için, AZURE_FUNCTIONS_ENVIRONMENT işlev uygulaması başlatmadan önce ortam değişkenini olarak ayarlayın Development .

Tetikleyiciler ve bağlamalar türleri

İşlev uygulamanız ile kullanabileceğiniz birkaç tetikleyici ve bağlama vardır. Tetikleyiciler ve bağlamaların tam listesi burada bulunabilir.

Tüm tetikleyiciler ve bağlamalar kodda birkaç gerçek veri türü olarak temsil edilir:

  • Hashtable
  • string
  • Byte []
  • int
  • double
  • HttpRequestContext
  • HttpResponseContext

Bu listedeki ilk beş tür standart .NET türlerdir. Son ikisi yalnızca httptrigger tetikleyicisitarafından kullanılır.

İşlevinizdeki 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 iletilerini temsil etmek için istek ve yanıt nesnelerini kullanır.

İstek nesnesi

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

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

* Tüm Dictionary<string,string> anahtarlar büyük/küçük harfe duyarlıdır.

Yanıt nesnesi

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

Özellik Açıklama Tür
Body Yanıtın gövdesini içeren bir nesne. object
ContentType Yanıt için içerik türünü ayarlamanın kısa bir tarafı. string
Headers Yanıt üst bilgilerini içeren bir nesne. Sözlük veya Hashtable
StatusCode Yanıtın HTTP durum kodu. dize veya tamsayı

İstek ve yanıta erişme

HTTP tetikleyicilerle çalışırken, HTTP isteğine diğer giriş bağlamalarla aynı şekilde erişebilirsiniz. Bu, param bloğunda.

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

function.json

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "anonymous"
    },
    {
      "type": "http",
      "direction": "out"
    }
  ]
}

run.ps1

param($req, $TriggerMetadata)

$name = $req.Query.Name

Push-OutputBinding -Name res -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "Hello $name!"
})

Bu işlevi çağırma sonucu şöyle olur:

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, parametrenin türünü belirtebilirsiniz.

Örneğin, BLOB depolama alanından bir dize olarak sağlanan verilerin olmasını engellemek için aşağıdaki tür cast 'u param bloba ekleyin:

param([string] $myBlob)

PowerShell profili

PowerShell 'de bir PowerShell profili kavramı vardır. PowerShell profilleri hakkında bilgi sahibi değilseniz, bkz. profiller hakkında.

PowerShell Işlevlerinde, profil betiği, ilk dağıtıldığında ve etkinleştirildikten sonra, uygulamada PowerShell çalışan örneği başına bir kez yürütülür (soğuk başlar. Eşzamanlılık etkinleştirildiğinde, PSWorkerInProcConcurrencyUpperBound değeri ayarlanarak profil betiği oluşturulan her çalışma alanı için ç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 değer profile.ps1 oluşturulur. varsayılan profil, temel araçlar GitHub deposunda tutulur ve şunları içerir:

  • Azure 'da otomatik MSI kimlik doğrulaması.
  • isterseniz Azure PowerShell AzureRM PowerShell diğer adlarını açma özelliği.

PowerShell sürümleri

Aşağıdaki tabloda, Işlevlerin ç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ü
3. x (önerilir) PowerShell 7 (önerilir)
PowerShell Core 6
.NET Core 3.1
.NET Core 2.1
2.x PowerShell Core 6 .NET Core 2.2

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

Azure Iş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

Yerel olarak çalıştırılırken Azure Işlevleri çalışma zamanı varsayılan olarak PowerShell Core 6 ' yı kullanmaktır. Bunun yerine, yerel olarak çalışırken PowerShell 7 ' yi kullanmak için, "FUNCTIONS_WORKER_RUNTIME_VERSION" : "~7" Values Proje kökündeki dosyadaki local.setting.js, bu ayarı diziye eklemeniz gerekir. PowerShell 7 ' de yerel olarak çalışırken, local.settings.jsdosya aşağıdaki örnekteki gibi görünür:

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

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

İşlev uygulamanızın PowerShell Core 6 ' dan PowerShell 7 ' ye yükseltebilmesi için sürüm 3. x üzerinde çalışıyor olması gerekir. 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 ya da PowerShell kullanarak yapabilirsiniz.

  1. Azure Portal, işlev uygulamanıza gidin.

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

    İşlev uygulaması tarafından kullanılan PowerShell sürümünü seçin

  3. İstediğiniz PowerShell Çekirdek sürümünüzü seçin ve Kaydet' i seçin. Bekleyen yeniden başlatma hakkında uyarı olduğunda devam' ı seçin. İşlev uygulaması, seçilen PowerShell sürümünde yeniden başlatılır.

İşlev uygulaması, yapılandırma sırasında değişiklik yapıldıktan sonra 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 etkinken, gerekli modülleri otomatik olarak indirmek için requirements.psd1 dosyası kullanılır. Bu davranışı managedDependency , özelliği, true Aşağıdaki örnekte olduğu gibi, dosyadakihost.jskökünde ayarlayarak etkinleştirin:

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

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

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

requirements.psd1 dosyasını güncelleştirdiğinizde, bir yeniden başlatmanın ardından güncelleştirilmiş modüller yüklenir.

Hedef belirli sürümler

requirements.psd1 dosyanızdaki bir modülün belirli bir sürümünü hedeflemek isteyebilirsiniz. Örneğin, daha eski bir sürümü dahil edilen az Module sürümünden daha eski bir sürümünü kullanmak isterseniz, aşağıdaki örnekte gösterildiği gibi belirli bir sürümü hedefleyebilirsiniz:

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

Bu durumda, aşağıdaki örnekte olduğu gibi profile.ps1 dosyanızın üst kısmına bir içeri aktarma açıklaması da eklemeniz gerekir:

Import-Module Az.Accounts -RequiredVersion '1.9.5'

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

Bağımlılık yönetimi konuları

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

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

  • Yönetilen bağımlılıklar Şu anda, lisansı etkileşimli olarak kabul ederek ya da çağrılırken anahtar sağlayarak kullanıcının bir lisansı kabul etmesini gerektiren modülleri desteklemez -AcceptLicense Install-Module .

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

Aşağıdaki uygulama ayarları, yönetilen bağımlılıkların nasıl indirileceğini ve yükleneceğini değiştirmek için kullanılabilir.

İşlev Uygulaması ayarı Varsayılan değer Description
MDMaxBackgroundUpgradePeriod 7.00:00:00 (yedi gün) PowerShell işlev uygulamaları için arka plan güncelleştirme dönemini denetler. Daha fazla bilgi için bkz. Mdmaxbackgroundupgradeperiod.
MDNewSnapshotCheckPeriod 01:00:00 (bir saat) Her bir PowerShell çalışanının, yönetilen bağımlılık yükseltmelerinden yüklenip yüklenmediğini ne sıklıkta denetleyeceğini belirtir. Daha fazla bilgi için bkz. Mdnewsnapshotcheckperiod.
MDMinBackgroundUpgradePeriod 1.00:00:00 (bir gün) Önceki bir yükseltme denetiminden sonra, başka bir yükseltme denetimi başlatılmadan önce geçen süre. Daha fazla bilgi için bkz. Mdminbackgroundupgradeperiod.

Esas olarak, uygulama yükseltmeniz içinde başlar MDMaxBackgroundUpgradePeriod ve yükseltme işlemi yaklaşık olarak içinde tamamlanır MDNewSnapshotCheckPeriod .

Özel modüller

Azure Işlevlerinde kendi özel modüllerinizi kullanmak, PowerShell için normal şekilde nasıl yapacağınızdan farklıdır.

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

Işlevlerde PSModulePath iki yol içerir:

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

İşlev uygulama düzeyi modüller klasörü

Özel modülleri kullanmak için işlevlerinizin bir klasöre bağlı olduğu modülleri yerleştirebilirsiniz Modules . 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 bu dosyaları modüller klasörüne dahil etmeniz gerekmez. Bunlar, $env:LOCALAPPDATA/AzureFunctions bulutta çalıştırıldığında klasöründe ve klasöründe yerel olarak depolanır /data/ManagedDependencies .

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

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

Bir Modules klasör ile, işlev uygulamanız aşağıdaki klasör yapısına 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ı bu Modules klasörü öğesine ekler $env:PSModulePath . böylece, normal bir PowerShell betiğiyle yaptığınız gibi, modül oto yüklemeye güvenebilirsiniz.

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

Birçok modül genellikle PowerShell dil çalışanı tarafından kullanılır. Bu modüller, öğesinin son konumunda tanımlanmıştır PSModulePath .

Geçerli modüller listesi aşağıdaki gibidir:

  • Microsoft. PowerShell. Archive:, ve gibi Arşivlerle çalışmak için kullanılan .zip modül .nupkg .
  • Threadjob: PowerShell iş API 'lerinin iş parçacığı tabanlı bir uygulamasıdır.

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

Ortam değişkenleri

Işlevlerde, hizmet bağlantı dizeleri gibi uygulama ayarları, yürütme sırasında ortam değişkenleri olarak sunulur. $env:NAME_OF_ENV_VARAşağıdaki örnekte gösterildiği gibi, kullanarak bu 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ı ekleyebileceğiniz, güncelleştiren ve silebilmeniz için çeşitli yollar 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ırsanız, uygulama ayarları proje local.settings.jsdosyasından okunur.

Eşzamanlılık

Varsayılan olarak, İşlevler PowerShell çalışma zamanı aynı anda yalnızca bir işlev çağrılarını işleyene kadar devam eder. 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ışırken.
  • Aynı işlev uygulamasının içinde diğer işlevleri çağıran işlevleriniz olduğunda.

İş yükü türüne bağlı olarak araştırabilirsiniz birkaç eşzamanlılık modeli vardır:

  • 'i FUNCTIONS_WORKER_PROCESS_COUNT artırmak. Bu, aynı örnek içindeki birden çok işlemde işlev çağrılarını işlemeye olanak sağlar ve bu da belirli CPU ve bellek ek yüküne neden olur. Genel olarak, I/O'ya bağlı işlevler bu ek yükten zarar çekmez. CPU'ya bağlı işlevlerde bu etki önemli olabilir.

  • Uygulama PSWorkerInProcConcurrencyUpperBound ayarı değerini artırma. Bu, aynı işlem içinde birden çok çalışma alanı oluşturulmasına olanak sağlar ve bu da CPU ve bellek ek yükünü önemli ölçüde azaltır.

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

Kullanım durumuna bağlı olarak, Dayanıklı İşlevler ölçeklenebilirliği önemli ölçüde geliştirebilir. Daha fazla bilgi için bkz. Dayanıklı İşlevler desenleri.

Not

"Kullanılabilir çalışma alanı yok nedeniyle istekler kuyruğa alınan istekler" uyarılarını alabilirsiniz, bunun bir hata olmadığını unutmayın. İleti, isteklerin kuyruğa alınan ve önceki istekler tamamlandığında işleneceklerini belirtir.

Eşzamanlılık kullanımında dikkat edilmesi gerekenler

PowerShell varsayılan olarak tek bir iş parçacıklı betik dilidir. Ancak eşzamanlılık, aynı işlemde birden çok PowerShell çalışma alanı kullanılarak eklenebilir. Oluşturulan çalışma alanı miktarı uygulama ayarıyla PSWorkerInProcConcurrencyUpperBound eştir. Aktarım hızı, seçilen plandaki kullanılabilir CPU ve bellek miktarına göre etkilenecez.

Azure PowerShell fazla yazmadan tasarruf etmeye yardımcı olmak için bazı işlem düzeyi bağlamlar ve durum kullanır. Ancak, işlev uygulamanıza eşzamanlılığı açmanız ve durumu değiştirecek eylemleri çağırmanız, yarış koşullarıyla sonuçlanabilirsiniz. Bir çağrı belirli bir durumu bağlı olduğu ve diğer çağrının durumu değiştirdiğini için bu yarış durumlarında hata ayıklaması zordur.

Bazı işlemler önemli ölçüde zaman ala Azure PowerShell eşzamanlılık için çok fazla değer vardır. Ancak dikkatli olmalısınız. Yarış durumuyla karşılaşıyorsanız PSWorkerInProcConcurrencyUpperBound uygulama ayarını olarak ayarlayın ve bunun yerine eşzamanlılık için dil çalışanı işlem düzeyi yalıtımı 1 kullanın.

İşlev betiği yapılandırmaDosya

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

scriptFileiçinde function.json özelliği, aşağıdaki örnekte olduğu gibi görünen bir klasör yapısı almak için kullanılabilir:

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

Bu durumda, function.json myFunction için, çalıştıracak scriptFile dışarı aktarıldı işleviyle dosyaya başvuran bir özelliği içerir.

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

EntryPoint'i yapılandırarak PowerShell modüllerini kullanma

Bu makalede şablonlar tarafından oluşturulan varsayılan betik dosyasında PowerShell run.ps1 işlevleri gösterilmiştir. Ancak işlevlerinizi PowerShell modüllerine de dahil edersiniz. Modülün yapılandırma dosyasındaki ve alanlarını kullanarak scriptFile entryPoint modüldeki belirli işlev function.jsbaşvurabilirsiniz.

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

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

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

Burada PSFunction.psm1 şunları içerir:

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

Bu örnekte yapılandırması, başka myFunction bir scriptFile klasördeki Bir PowerShell modülü PSFunction.psm1 olan 'a başvuran bir özelliği içerir. entryPointözelliği, Invoke-PSTestFunc modüldeki giriş noktası olan işlevine başvurur.

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

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

PowerShell işlevleriyle ilgili dikkat edilmesi gerekenler

PowerShell işlevleriyle birlikte çalışıyorken, aşağıdaki bölümlerde dikkat edilmesi gerekenler hakkında bilgi alın.

Soğuk Başlangıç

Sunucusuz Azure İşlevleri modeliyle yeni bir geliştirme modeli geliştirensoğuk başlangıçlar gerçek bir gerçektir. Soğuk başlatma, işlev uygulamanın bir isteği işlemeye başlaması için gereken süreyi ifade eder. İşlev uygulamanız, eylemsizlik dönemleri sırasında kapatılana kadar Tüketim planında daha sık olarak soğuk başlatma gerçekleşir.

Modüller yerine paket Install-Module

Betiğiniz her çağrıda çalıştır. Install-ModuleBetiğinizi kullanmaktan kaçının. Bunun Save-Module yerine, işlevinizin modülü indirirken zaman harcaması gerekmeden yayımlamadan önce kullanın. Soğuk başlangıçlar işlevlerinizi etkiliyorsa, işlev uygulamanızı her zaman açık olarak ayarlanmış bir App Service planına dağıtmayı göz önünde Premium göz önünde bulundurabilirsiniz.

Sonraki adımlar

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