Azure Functions panduan pengembang PowerShell

Artikel ini menyediakan detail tentang cara Anda menulis Azure Functions menggunakan PowerShell.

Fungsi Azure PowerShell (fungsi) direpresentasikan sebagai skrip PowerShell yang dijalankan saat dipicu. Setiap skrip fungsi memiliki file function.json terkait yang menentukan bagaimana fungsi berperilaku, seperti bagaimana hal itu dipicu dan parameter input dan outputnya. Untuk mempelajari selengkapnya, lihat konsep pemicu dan pengikatan Azure Functions.

Seperti jenis fungsi lainnya, fungsi skrip PowerShell mengambil parameter yang cocok dengan nama semua pengikatan input yang ditentukan dalam file function.json. Parameter TriggerMetadata juga diteruskan yang berisi informasi tambahan tentang pemicu yang memulai fungsi.

Artikel ini mengasumsikan bahwa Anda telah membaca panduan pengembang Azure Functions. Ini juga mengasumsikan bahwa Anda telah menyelesaikan panduan memulai cepat Functions untuk PowerShell untuk membuat fungsi PowerShell pertama Anda.

Struktur folder

Struktur folder yang diperlukan untuk proyek PowerShell terlihat seperti berikut ini. Default ini bisa diubah. Untuk informasi selengkapnya, lihat bagian scriptFile .

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

Di akar proyek, terdapat file host.json bersama yang dapat digunakan untuk mengonfigurasi aplikasi fungsi. Setiap fungsi memiliki folder dengan file kode sendiri (.ps1) dan file konfigurasi pengikatan (function.json). Nama direktori induk file function.json selalu merupakan nama fungsi Anda.

Pengikatan tertentu memerlukan keberadaan file extensions.csproj. Ekstensi pengikatan, yang diperlukan dalam versi 2.x dan versi yang lebih baru dari runtime Functions, didefinisikan dalam file extensions.csproj, dengan file pustaka aktual di folder bin. Saat mengembangkan secara lokal, Anda harus mendaftarkan ekstensi pengikatan. Saat Anda mengembangkan fungsi di portal Azure, pendaftaran ini dilakukan untuk Anda.

Di PowerShell Function Apps, Anda mungkin secara opsional memiliki profile.ps1 yang berjalan saat aplikasi fungsi mulai berjalan (yang dikenal sebagai cold start). Untuk informasi selengkapnya, lihat Profil PowerShell.

Menentukan skrip PowerShell sebagai fungsi

Secara default, fungsi runtime mencari fungsi Anda di run.ps1, di mana run.ps1 berbagi direktori induk yang sama dengan function.json yang sesuai.

Skrip Anda diberikan beberapa argumen saat dieksekusi. Untuk menangani parameter ini, tambahkan blok param ke bagian atas skrip Anda seperti dalam contoh berikut:

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

Parameter TriggerMetadata

Parameter TriggerMetadata ini digunakan untuk memberikan informasi tambahan tentang pemicunya. Metadata ini bervariasi dari pengikatan ke pengikatan tetapi semuanya berisi sys properti yang berisi data berikut:

$TriggerMetadata.sys

Properti	Deskripsi	Jenis
UtcNow	Ketika fungsi dipicu di UTC	Tanggal dan Waktu
MethodName	Nama Fungsi yang dipicu	string
RandGuid	pengidentifikasi unik untuk pelaksanaan fungsi ini	string

Setiap jenis pemicu memiliki sekumpulan metadata yang berbeda. Misalnya, $TriggerMetadata untuk QueueTrigger berisi InsertionTime, Id, DequeueCount, antara lain. Untuk informasi lebih lanjut tentang metadata pemicu antrean, buka dokumentasi resmi untuk pemicu antrean. Periksa dokumentasi tentang pemicu yang sedang Anda kerjakan untuk melihat apa yang ada di dalam metadata pemicu.

Pengikatan

Di PowerShell, pengikatan dikonfigurasi dan ditentukan dalam function.json dari fungsi. Fungsi berinteraksi dengan pengikatan dalam banyak cara.

Membaca pemicu dan memasukkan data

Pemicu dan pengikatan input dibaca sebagai parameter yang diteruskan ke fungsi Anda. Pengikatan input memiliki direction yang diatur ke in di function.json. Properti name yang ditentukan di function.json adalah nama parameter di blok param. Karena PowerShell menggunakan parameter bernama untuk pengikatan, urutan parameter tidak menjadi masalah. Namun, ini adalah praktik terbaik untuk mengikuti urutan pengikatan yang ditentukan di function.json.

param($MyFirstInputBinding, $MySecondInputBinding)

Menulis data keluaran

Pada Functions, pengikatan output memiliki direction yang diatur ke out di function.json. Anda dapat menulis ke pengikatan output dengan menggunakan cmdlet Push-OutputBinding, yang tersedia untuk runtime Functions tersebut. Dalam semua kasus, properti name dari pengikatan seperti yang ditentukan di function.json sesuai dengan parameter Name dari cmdlet Push-OutputBinding.

Contoh berikut menunjukkan cara memanggil Push-OutputBinding dalam skrip fungsi Anda:

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

Anda juga dapat meneruskan nilai untuk pengikatan tertentu melalui alur.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding berperilaku berbeda berdasarkan nilai yang ditentukan untuk -Name:

• Ketika nama yang ditentukan tidak dapat diatasi ke pengikatan output yang valid, maka kesalahan akan muncul.

• Saat pengikatan output menerima kumpulan nilai, Anda dapat memanggil Push-OutputBinding berulang kali untuk memasukkan beberapa nilai.

• Ketika pengikatan output hanya menerima nilai tunggal, memanggil Push-OutputBinding untuk kedua kalinya menghasilkan kesalahan.

Sintaks dari Push-OutputBinding

Berikut ini adalah parameter yang valid untuk memanggil Push-OutputBinding:

Nama	Jenis	Posisi	Deskripsi
-Name	string	1	Nama pengikatan output yang ingin Anda atur.
-Value	Objek	2	Nilai pengikatan output yang ingin Anda atur, yang diterima dari alur ByValue.
-Clobber	SwitchParameter	Dinamai	(Opsional) Jika ditentukan, memaksa penetapan nilai untuk ikatan keluaran yang ditentukan.

Parameter umum berikut juga didukung:

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

Untuk informasi selengkapnya, lihat Tentang CommonParameters.

Contoh Push-OutputBinding: Respons HTTP

Pemicu HTTP mengembalikan respons menggunakan pengikatan output bernama response. Dalam contoh berikut, pengikatan output response memiliki nilai "output #1":

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

Karena output adalah ke HTTP, yang hanya menerima nilai database tunggal, kesalahan muncul ketika Push-OutputBinding dipanggil untuk kedua kalinya.

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

Untuk output yang hanya menerima nilai tunggal, Anda dapat menggunakan parameter -Clobber untuk menggantikan nilai lama daripada menambah ke koleksi. Contoh berikut mengasumsikan bahwa Anda telah menambahkan nilai. Dengan menggunakan -Clobber, respons dari contoh berikut mengambil alih nilai yang ada untuk mengembalikan nilai "output #3":

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

Contoh Push-OutputBinding: Pengikatan output antrean

Push-OutputBinding digunakan untuk mengirim data ke pengikatan output, seperti pengikatan output penyimpanan antrean Azure. Dalam contoh berikut, pesan yang ditulis ke dalam antrian memiliki nilai "output #1":

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

Pengikatan output untuk antrean Storage menerima berbagai nilai keluaran. Dalam hal ini, memanggil contoh berikut setelah penulisan pertama ke daftar antrean dengan dua item: "output #1" dan "output #2".

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

Contoh berikut, ketika dipanggil setelah dua panggilan sebelumnya, menambahkan dua nilai lagi ke koleksi output:

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

Ketika ditulis ke antrean, pesan berisi keempat nilai ini: "output #1", "output #2", "output #3", dan "output #4".

cmdlet Get-OutputBinding

Anda dapat menggunakan cmdlet Get-OutputBinding untuk mengambil nilai yang saat ini ditetapkan untuk pengikatan output Anda. Cmdlet ini mengambil hashtable yang berisi nama-nama pengikatan output dengan nilai masing-masing.

Contoh berikut menggunakan Get-OutputBinding untuk mengembalikan nilai pengikatan saat ini:

Get-OutputBinding

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

Get-OutputBinding juga berisi parameter yang disebut -Name, yang dapat digunakan untuk memfilter pengikatan yang dikembalikan, seperti dalam contoh berikut:

Get-OutputBinding -Name MyQ*

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

Dukungan wildcard (*) tersedia di Get-OutputBinding.

Logging

Pengelogan di fungsi PowerShell berfungsi seperti pencatatan PowerShell biasa. Anda dapat menggunakan cmdlet pengelogan untuk menulis ke setiap aliran output. Setiap cmdlet dipetakan ke tingkat log yang digunakan oleh Functions.

Tingkat pengelogan Functions	Cmdlet pengelogan
Kesalahan	Write-Error
Peringatan	Write-Warning
Informasi	Write-Information Write-Host Write-Output Menulis ke tingkat log Information.
Pemecahan Kesalahan	Write-Debug
Jejak	Write-Progress Write-Verbose

Selain cmdlet ini, segala sesuatu yang ditulis ke pipeline diarahkan ke level log Information dan ditampilkan dengan pemformatan PowerShell default.

Penting

Menggunakan cmdlet Write-Verbose atau Write-Debug tidak cukup untuk melihat pencatatan tingkat verbose dan debug. Anda juga harus mengonfigurasi ambang tingkat log, yang menyatakan tingkat log yang benar-benar Anda pedulikan. Untuk mempelajari lebih lanjut, lihat Mengonfigurasi tingkat log aplikasi fungsi.

Mengonfigurasi tingkat log aplikasi fungsional

Azure Functions memungkinkan Anda menentukan tingkat ambang batas untuk memudahkan kontrol cara Functions menulis ke log. Untuk mengatur ambang untuk semua jejak yang ditulis ke konsol, gunakan properti logging.logLevel.default di host.json file. Pengaturan ini berlaku untuk semua fungsi di aplikasi fungsi Anda.

Contoh berikut menetapkan ambang untuk mengaktifkan pengelogan verbose untuk semua fungsi, tetapi menetapkan ambang guna mengaktifkan pengelogan debug untuk fungsi bernama MyFunction:

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

Untuk informasi selengkapnya, lihat referensi host.json.

Menampilkan log

Jika Aplikasi Fungsi Anda berjalan di Azure, Anda dapat menggunakan Application Insights untuk memantaunya. Baca monitoring Azure Functions untuk mempelajari selengkapnya tentang menampilkan dan mengkueri log fungsi.

Jika Anda menjalankan Aplikasi Fungsi secara lokal untuk pengembangan, log akan secara default menuju ke sistem file. Untuk melihat log di konsol, atur variabel lingkungan AZURE_FUNCTIONS_ENVIRONMENT ke Development sebelum memulai Aplikasi Fungsi.

Jenis pemicu dan pengikatan

Ada banyak pemicu dan pengikatan yang tersedia untuk Anda gunakan dengan aplikasi fungsi Anda. Untuk daftar lengkap pemicu dan pengikatan, lihat Pengikatan yang didukung.

Semua pemicu dan pengikatan ditunjukkan dalam kode sebagai beberapa jenis data nyata:

• Hashtable
• string
• byte[]
• int (integer)
• ganda
• HttpRequestContext
• HttpResponseContext

Lima jenis pertama dalam daftar ini adalah jenis .NET standar. Dua terakhir hanya digunakan oleh pemicu HttpTrigger.

Setiap parameter pengikatan dalam fungsi Anda harus salah satu dari jenis ini.

Pemicu dan pengikatan HTTP

Pemicu HTTP dan webhook dan pengikatan output HTTP menggunakan objek permintaan dan respons untuk mewakili olah pesan HTTP.

Objek permintaan

Objek permintaan yang diteruskan ke dalam skrip adalah jenis HttpRequestContext, yang memiliki properti berikut:

Properti	Deskripsi	Jenis
Body	Objek yang memuat isi permintaan. Body diserialisasikan menjadi jenis terbaik berdasarkan data. Misalnya, jika data adalah JSON, data tersebut diteruskan sebagai hashtable. Jika data adalah string, maka diteruskan sebagai string.	objek
Headers	Sebuah diksi yang berisi header dari permintaan.	Kamus<string,string>*
Method	Metode HTTP permintaan.	string
Params	Objek yang berisi parameter perutean permintaan.	Kamus<string,string>*
Query	Objek yang berisi parameter kueri.	Kamus<string,string>*
Url	URL permintaan.	string

^*Semua kunci Dictionary<string,string> tidak peka terhadap huruf besar/kecil.

Objek respons

Objek respons yang harus Anda kirim kembali adalah jenis HttpResponseContext, yang memiliki properti berikut:

Properti	Deskripsi	Jenis
Body	Objek yang berisi isi respons.	objek
ContentType	Cara ringkas untuk mengatur jenis konten untuk respons.	string
Headers	Objek yang berisi header respons.	Kamus atau Hashtable
StatusCode	Kode status HTTP dari respons.	string atau int

Mengakses permintaan dan respons

Ketika Anda bekerja dengan pemicu HTTP, Anda dapat mengakses permintaan HTTP dengan cara yang sama seperti yang Anda lakukan dengan pengikatan input lainnya. Ada di blok param.

HttpResponseContext Gunakan objek untuk mengembalikan respons, seperti yang ditunjukkan dalam contoh berikut:

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

Hasil dari pemanggilan fungsi ini adalah:

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

Type-casting untuk pemicu dan pengikatan

Untuk pengikatan tertentu seperti pengikatan blob, Anda dapat menentukan jenis parameter.

Misalnya, agar data dari penyimpanan Blob disediakan sebagai untai (karakter), tambahkan jenis cast berikut ke blok param saya:

param([string] $myBlob)

Profil PowerShell

Di PowerShell, ada konsep profil PowerShell. Jika Anda tidak terbiasa dengan profil PowerShell, lihat Tentang profil.

Dalam PowerShell Functions, skrip profil dijalankan sekali per instans pekerja PowerShell di aplikasi ketika pertama kali disebarkan dan setelah terjadi masa tidak digunakan (cold start). Ketika pemrosesan bersamaan diaktifkan dengan mengatur nilai PSWorkerInProcConcurrencyUpperBound, skrip profil dijalankan untuk setiap ruang jalankan yang dibuat.

Saat Anda membuat aplikasi fungsi menggunakan alat, seperti Visual Studio Code dan Azure Functions Core Tools, profile.ps1 default dibuat untuk Anda. Profil default dipertahankan di repositori Core Tools GitHub dan berisi:

• Autentikasi MSI otomatis ke Azure.
• Kemampuan untuk mengaktifkan alias PowerShell di Azure PowerShell AzureRM jika Anda mau.

Versi PowerShell

Tabel berikut ini memperlihatkan versi PowerShell yang tersedia untuk setiap versi utama runtime Functions, dan versi .NET diperlukan:

Versi Azure Functions	Versi PowerShell	versi .NET
4.x	PowerShell 7.4	.NET 8
4.x	PowerShell 7.2 (akhir dukungan)	.NET 6

Anda dapat melihat versi saat ini dengan mencetak $PSVersionTable dari fungsi apa pun.

Untuk mempelajari selengkapnya tentang kebijakan dukungan runtime Azure Functions, lihat article ini

Catatan

Dukungan untuk PowerShell 7.2 di Azure Functions berakhir pada 8 November 2024. Anda mungkin harus mengatasi beberapa perubahan mendasar saat memutakhirkan fungsi PowerShell 7.2 Anda untuk dijalankan di PowerShell 7.4. Ikuti panduan migrasi ini untuk meningkatkan ke PowerShell 7.4.

Menjalankan secara lokal pada versi tertentu

Saat Menjalankan fungsi PowerShell secara lokal, Anda perlu menambahkan pengaturan "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4" ke Values array dalam file local.setting.json di akar proyek. Saat berjalan secara lokal di PowerShell 7.4, file local.settings.json Anda terlihat seperti contoh berikut:

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

Catatan

Di PowerShell Functions, nilai "~7" untuk FUNCTIONS_WORKER_RUNTIME_VERSION mengacu pada "7.0.x". Kami tidak secara otomatis meningkatkan aplikasi Fungsi PowerShell yang memiliki "~7" ke "7.4". Ke depannya, untuk PowerShell Function Apps, kami mengharuskan aplikasi menentukan versi utama dan minor yang ingin mereka targetkan. Perlu disebutkan "7.4" jika Anda ingin menargetkan "7.4.x"

Mengubah versi PowerShell

Pertimbangkan pertimbangan ini sebelum Anda memigrasikan aplikasi fungsi PowerShell ke PowerShell 7.4:

• Karena migrasi mungkin memperkenalkan perubahan yang dapat merusak aplikasi Anda, tinjau panduan migrasi ini sebelum memperbarui aplikasi Anda ke PowerShell 7.4.

• Pastikan aplikasi fungsi Anda berjalan pada versi terbaru runtime Functions di Azure, yaitu versi 4.x. Untuk informasi selengkapnya, lihat Menampilkan versi runtime saat ini.

Gunakan langkah-langkah berikut untuk mengubah versi PowerShell yang digunakan oleh aplikasi fungsi Anda. Anda dapat melakukan operasi ini baik di portal Azure atau dengan menggunakan PowerShell.

Portal

1. Di portal Azure, telusuri ke aplikasi fungsi Anda.

2. Di bawah Setelan, pilih Konfigurasi. Di tab Pengaturan umum, temukan versi PowerShell.

   

3. Pilih versi PowerShell Core yang Anda inginkan dan pilih Simpan. Ketika diperingatkan tentang penyalaan ulang yang tertunda, pilih Lanjutkan. Aplikasi fungsi dimulai ulang pada versi PowerShell yang dipilih.

Catatan

Azure Functions dukungan terhadap PowerShell 7.4 sekarang tersedia secara umum (GA). Anda mungkin melihat PowerShell 7.4 masih ditunjukkan sebagai pratinjau di portal Azure, tetapi nilai ini akan segera diperbarui untuk mencerminkan status GA.

PowerShell

Jalankan skrip berikut ini untuk mengubah versi PowerShell:

Set-AzResource -ResourceId "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<FUNCTION_APP>/config/web" -Properties @{  powerShellVersion  = '<VERSION>' } -Force -UsePatchSemantics

Ganti <SUBSCRIPTION_ID>, <RESOURCE_GROUP>, dan <FUNCTION_APP> dengan ID langganan Azure Anda, nama grup sumber daya dan aplikasi fungsi Anda. Selain itu, ganti <VERSION> dengan 7.4. Anda dapat memverifikasi nilai pengaturan powerShellVersion yang diperbarui di Properties dari tabel hash yang dikembalikan.

Aplikasi fungsi dihidupkan ulang setelah perubahan dilakukan pada konfigurasi.

Manajemen dependensi

Mengelola modul dalam Azure Functions yang ditulis di PowerShell dapat didekati dengan dua cara: menggunakan fitur Dependensi Terkelola atau menyertakan modul langsung di konten aplikasi Anda. Setiap metode memiliki kelebihannya sendiri, dan memilih yang tepat tergantung pada kebutuhan spesifik Anda.

Memilih pendekatan manajemen modul yang tepat

Mengapa menggunakan fitur Dependensi Terkelola?

• Penginstalan awal yang disederhanakan: Secara otomatis menangani penginstalan modul berdasarkan file Anda requirements.psd1 .
• Peningkatan otomatis: Modul diperbarui secara otomatis, termasuk perbaikan keamanan, tanpa memerlukan intervensi manual.

Mengapa menyertakan modul dalam konten aplikasi?

• Tidak ada dependensi pada PowerShell Gallery: Modul dibundel dengan aplikasi Anda, menghilangkan dependensi eksternal.
• Kontrol lebih lanjut: Menghindari risiko regresi yang disebabkan oleh peningkatan otomatis, memberi Anda kontrol penuh atas versi modul mana yang digunakan.
• Kompatibilitas: Mendukung Flex Consumption dan direkomendasikan untuk SKU Linux lainnya.

Fitur Ketergantungan Terkelola

Fitur Dependensi Terkelola memungkinkan Azure Functions mengunduh dan mengelola modul PowerShell secara otomatis yang ditentukan dalam file requirements.psd1. Fitur ini diaktifkan secara default di aplikasi fungsi PowerShell baru.

Mengonfigurasi requirements.psd1

Untuk menggunakan Dependensi Terkelola di Azure Functions dengan PowerShell, Anda perlu mengonfigurasi file requirements.psd1. File ini menentukan modul yang diperlukan fungsi Anda, dan Azure Functions secara otomatis mengunduh dan memperbarui modul ini untuk memastikan bahwa lingkungan Anda tetap up-to-date.

Berikut cara menyiapkan dan mengonfigurasi requirements.psd1 file:

1. Buat file requirements.psd1 di direktori akar Fungsi Azure Anda jika belum ada.
2. Tentukan modul dan versinya dalam struktur data PowerShell.

Contoh requirements.psd1 file:

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

Menyertakan modul dalam konten aplikasi

Untuk kontrol lebih besar atas versi modul Anda dan untuk menghindari dependensi pada sumber daya eksternal, Anda dapat menyertakan modul langsung dalam konten aplikasi fungsi Anda.

Untuk menyertakan modul kustom:

1. Buat Modules folder di akar aplikasi fungsi Anda.

   mkdir ./Modules
   

2. Salin modul ke Modules folder menggunakan salah satu metode berikut:

   • Jika modul sudah tersedia secara lokal:

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

   • Gunakan Save-Module untuk mengambil dari PowerShell Gallery:

     Save-Module -Name MyCustomModule -Path ./Modules
     

   • Menggunakan Save-PSResource dari PSResourceGet modul:

     Save-PSResource -Name MyCustomModule -Path ./Modules
     

Aplikasi fungsi Anda harus memiliki struktur berikut:

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

Saat memulai aplikasi fungsi Anda, pekerja bahasa PowerShell menambahkan folder Modules ini ke $env:PSModulePath sehingga Anda dapat mengandalkan autoloading modul seperti yang Anda lakukan dalam skrip PowerShell biasa.

Catatan

Jika aplikasi fungsi Anda berada di bawah kontrol sumber, Anda harus mengonfirmasi bahwa semua konten di folder Modul yang Anda tambahkan tidak dikecualikan oleh .gitignore. Misalnya, jika salah satu modul Anda memiliki folder bin yang dikecualikan, Anda ingin memodifikasi .gitignore dengan mengganti bin dengan

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

Pemecahan Masalah Dependensi Terkelola

Mengaktifkan Ketergantungan Terkelola

Agar Dependensi Terkelola berfungsi, fitur harus diaktifkan dalam host.json:

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

Menargetkan versi tertentu

Saat menargetkan versi modul tertentu, penting untuk mengikuti kedua langkah berikut untuk memastikan versi modul yang benar dimuat:

1. Tentukan versi modul di requirements.psd1:

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

2. Tambahkan pernyataan impor ke profile.ps1:

   Import-Module Az.Accounts -RequiredVersion '1.9.5'
   

Mengikuti langkah-langkah ini memastikan versi yang ditentukan dimuat saat fungsi Anda dimulai.

Mengonfigurasi pengaturan interval khusus untuk Dependensi Terkelola

Anda dapat mengonfigurasi bagaimana Dependensi Terkelola diunduh dan diinstal menggunakan pengaturan aplikasi berikut:

Pengaturan	Nilai Default	Deskripsi
MDMaxBackgroundUpgradePeriod	7.00:00:00 (tujuh hari)	Mengontrol periode pembaruan latar belakang untuk aplikasi fungsi PowerShell.
MDNewSnapshotCheckPeriod	01:00:00 (satu jam)	Menentukan seberapa sering pekerja PowerShell memeriksa pembaruan.
MDMinBackgroundUpgradePeriod (Periode Pembaruan Latar Belakang Minimum MD)	1.00:00:00 (satu hari)	Waktu minimum sementara antara pemeriksaan pembaruan.

Pertimbangan manajemen dependensi

• Akses Internet: Dependensi Terkelola memerlukan akses ke https://www.powershellgallery.com untuk mengunduh modul. Pastikan lingkungan Anda mengizinkan akses ini, termasuk memodifikasi aturan firewall/VNet sesuai kebutuhan. Titik akhir yang dibutuhkan dijelaskan di dalam Cmdlet Pemecahan Masalah. Titik akhir ini dapat ditambahkan ke daftar izinkan, sesuai kebutuhan.
• Penerimaan Lisensi: Modul pengelolaan dependensi tidak mendukung modul yang memerlukan penerimaan lisensi.
• Paket Konsumsi Flex: Fitur Dependensi Terkelola tidak didukung dalam Paket Konsumsi Flex. Gunakan modul kustom sebagai gantinya.
• Lokasi Modul: Di komputer lokal Anda, modul biasanya diinstal di salah satu folder yang tersedia secara global di $env:PSModulePath. Saat berjalan di Azure, $env:PSModulePath untuk aplikasi fungsi PowerShell berbeda dari $env:PSModulePath dalam skrip PowerShell biasa dan berisi folder Modules yang diunggah dengan konten aplikasi Anda dan lokasi terpisah yang dikelola oleh Dependensi Terkelola.

Variabel lingkungan

Di Azure Functions, pengaturan aplikasi, seperti string koneksi layanan, diekspos sebagai variabel lingkungan selama eksekusi. Anda dapat mengakses pengaturan ini menggunakan $env:NAME_OF_ENV_VAR, seperti yang ditunjukkan dalam contoh berikut:

param($myTimer)

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

Ada beberapa cara yang dapat Anda tambahkan, perbarui, dan hapus pengaturan aplikasi fungsi:

• Di portal Azure
• Dengan menggunakan Azure CLI
• Dengan menggunakan Azure PowerShell

Perubahan pada pengaturan aplikasi fungsi mengharuskan aplikasi fungsi Anda dimulai ulang.

Saat berjalan secara lokal, pengaturan aplikasi dibaca dari file proyek local.settings.json.

Konkurensi

Secara default, runtime Functions PowerShell hanya dapat memproses satu pemanggilan fungsi pada satu waktu. Namun, tingkat konkurensi ini mungkin tidak cukup dalam situasi berikut:

• Ketika Anda mencoba untuk menangani sejumlah besar panggilan secara bersamaan.
• Ketika Anda memiliki fungsi yang memanggil fungsi lain di dalam aplikasi fungsi yang sama.

Ada beberapa model konkurensi yang dapat Anda jelajahi tergantung pada jenis beban kerja:

• Tingkatkan FUNCTIONS_WORKER_PROCESS_COUNT. Meningkatkan pengaturan ini memungkinkan penanganan pemanggilan fungsi dalam beberapa proses dalam instans yang sama, yang memperkenalkan overhead CPU dan memori tertentu. Secara umum, fungsi I/O tidak mengalami overhead ini. Untuk fungsi terikat CPU, dampaknya mungkin signifikan.

• Menambah nilai pengaturan aplikasi PSWorkerInProcConcurrencyUpperBound. Meningkatkan pengaturan ini memungkinkan pembuatan beberapa runspace dalam proses yang sama, yang secara signifikan mengurangi overhead CPU dan memori.

Anda mengatur variabel lingkungan ini di pengaturan aplikasi dari aplikasi fungsi Anda.

Tergantung pada kasus penggunaan Anda, Durable Functions mungkin secara signifikan meningkatkan skalabilitas. Untuk mempelajari selengkapnya, lihat pola aplikasi Durable Functions.

Catatan

Anda mungkin mendapatkan peringatan "permintaan sedang diantrekan karena tidak ada runspace yang tersedia". Pesan ini bukan kesalahan. Pesan memberi tahu Anda bahwa permintaan sedang diantrekan. Mereka diproses setelah permintaan sebelumnya telah selesai.

Pertimbangan untuk menggunakan konkurensi

PowerShell adalah bahasa pembuatan skrip single_threaded secara default. Namun, konkurensi dapat ditambahkan dengan menggunakan beberapa runspace PowerShell dalam proses yang sama. Jumlah runspace yang dibuat, dan oleh karena itu jumlah utas serentak tiap pekerja, dapat dibatasi oleh pengaturan aplikasi PSWorkerInProcConcurrencyUpperBound. Secara default, jumlah runspace diatur ke 1.000 di versi 4.x dari runtime Functions. Di versi 3.x dan di bawahnya, jumlah maksimum runspace diatur ke 1. Throughput aplikasi fungsi Anda dipengaruhi oleh jumlah CPU dan memori yang tersedia dalam paket yang dipilih.

Azure PowerShell menggunakan beberapa konteks dan keadaan tingkat proses untuk membantu menyelamatkan Anda dari pengetikan berlebih. Namun, jika Anda mengaktifkan konkurensi di aplikasi fungsi Anda dan memanggil tindakan yang mengubah status, Anda bisa berakhir dengan kondisi bersaing. Kondisi bersaing ini sulit di-debug karena satu pemanggilan bergantung pada status tertentu dan pemanggilan lainnya mengubah status.

Ada nilai besar dalam konkurensi dengan Azure PowerShell, karena beberapa operasi dapat memakan waktu yang cukup lama. Namun, Anda harus melanjutkan dengan hati-hati. Jika Anda curiga bahwa Anda mengalami kondisi bersaing, atur pengaturan aplikasi PSWorkerInProcConcurrencyUpperBound ke 1 dan sebagai gantinya gunakan isolasi tingkat proses pekerja bahasa untuk konkurensi.

Mengonfigurasi fungsi scriptFile

Secara default, fungsi PowerShell dijalankan dari run.ps1, file yang berbagi direktori induk yang sama dengan function.json yang sesuai.

Properti scriptFile di function.json dapat digunakan untuk mendapatkan struktur folder yang terlihat seperti contoh berikut:

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

Dalam hal ini, function.json untuk myFunction menyertakan properti scriptFile yang mereferensikan file dengan fungsi yang diekspor untuk dijalankan.

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

Menggunakan modul PowerShell dengan mengonfigurasi entryPoint

Fungsi PowerShell dalam artikel ini diperlihatkan dengan file skrip default run.ps1 yang dihasilkan oleh templat. Namun, Anda juga dapat menyertakan fungsi Anda dalam modul PowerShell. Anda dapat mereferensikan kode fungsi spesifik Anda dalam modul dengan menggunakan scriptFile dan bidang entryPoint di file konfigurasi function.json.

Dalam hal ini, entryPoint adalah nama fungsi atau cmdlet dalam modul PowerShell yang direferensikan dalam scriptFile.

Pertimbangkan struktur folder berikut ini:

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

Dengan PSFunction.psm1 berisi:

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

Dalam contoh ini, konfigurasi untuk myFunction menyertakan properti scriptFile yang mereferensikan PSFunction.psm1, yang merupakan modul PowerShell di folder lain. Properti entryPoint mereferensikan fungsi Invoke-PSTestFunc, yang merupakan titik masuk dalam modul.

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

Dengan konfigurasi ini, Invoke-PSTestFunc dieksekusi persis seperti yang akan dilakukan run.ps1.

Pertimbangan untuk fungsi PowerShell

Saat Anda bekerja dengan fungsi PowerShell, perhatikan pertimbangan di bagian berikut.

Mulai dari Nol

Saat mengembangkan Azure Functions di model hosting serverless, cold start adalah kenyataan. Cold start mengacu pada periode waktu yang diperlukan agar aplikasi fungsi Anda mulai berjalan untuk memproses permintaan. Cold start lebih sering terjadi pada paket Konsumsi karena aplikasi fungsi Anda dimatikan saat tidak aktif.

Hindari menggunakan Install-Module

Menjalankan Install-Module dalam skrip fungsi Anda pada setiap pemanggilan dapat menyebabkan masalah kinerja. Sebagai gantinya, gunakan Save-Module atau Save-PSResource sebelum menerbitkan aplikasi fungsi Anda untuk menggabungkan modul yang diperlukan.

Untuk informasi selengkapnya, lihat Manajemen dependensi.

Langkah berikutnya

Untuk informasi selengkapnya, lihat sumber daya berikut:

• Praktik terbaik untuk Azure Functions
• Azure Functions Referensi untuk Pengembang
• Azure Functions pemicu dan pengikatan