Bagikan melalui

Pertimbangan penyimpanan untuk Azure Functions

  • Artikel

Azure Functions memerlukan akun Azure Storage saat Anda membuat instans aplikasi fungsi. Layanan penyimpanan berikut dapat digunakan oleh aplikasi fungsi Anda:

Layanan penyimpanan Penggunaan fungsi
Azure Blob Storage Pertahankan status pengikatan dan kuncifungsi 1.
Sumber penyebaran untuk aplikasi yang berjalan dalam paket Konsumsi Flex.
Digunakan secara default untuk hub tugas di Durable Functions.
Dapat digunakan untuk menyimpan kode aplikasi fungsi untuk build jarak jauh Konsumsi Linux atau sebagai bagian dari penyebaran URL paket eksternal.
Azure Files2 Berbagi file yang digunakan untuk menyimpan dan menjalankan kode aplikasi fungsi Anda dalam Rencana Konsumsi dan Rencana Premium.
Azure Queue storage Digunakan secara default untuk hub tugas di Durable Functions. Digunakan untuk kegagalan dan penanganan coba lagi dalam pemicu Azure Functions tertentu. Digunakan untuk pelacakan objek oleh pemicu penyimpanan Blob.
Azure Table Storage Digunakan secara default untuk hub tugas di Durable Functions.
  1. Penyimpanan blob adalah penyimpanan default untuk kunci fungsi, tetapi Anda dapat mengonfigurasi penyimpanan alternatif.
  2. Azure Files disiapkan secara default, tetapi Anda dapat membuat aplikasi tanpa Azure Files dalam kondisi tertentu.

Pertimbangan penting

Anda harus sangat mempertimbangkan fakta-fakta berikut mengenai akun penyimpanan yang digunakan oleh aplikasi fungsi Anda:

  • Saat aplikasi fungsi Anda dihosting pada paket Konsumsi atau paket Premium, kode fungsi dan file konfigurasi Anda disimpan di Azure Files di akun penyimpanan yang ditautkan. Saat Anda menghapus akun penyimpanan ini, konten akan dihapus dan tidak dapat dipulihkan. Untuk informasi selengkapnya, lihat Akun penyimpanan telah dihapus

  • Data penting, seperti kode fungsi, kunci akses, dan data terkait layanan penting lainnya, dapat disimpan di akun penyimpanan. Anda harus mengelola akses dengan hati-hati ke akun penyimpanan yang digunakan oleh aplikasi fungsi dengan cara berikut:

    • Audit dan batasi akses aplikasi dan pengguna ke akun penyimpanan berdasarkan model hak istimewa paling sedikit. Izin ke akun penyimpanan dapat berasal dari tindakan data dalam peran yang ditetapkan atau melalui izin untuk melakukan operasi listKeys.

    • Pantau aktivitas sarana kontrol (seperti mengambil kunci) dan operasi sarana data (seperti menulis ke blob) di akun penyimpanan Anda. Pertimbangkan untuk mempertahankan log penyimpanan di lokasi selain Azure Storage. Untuk informasi selengkapnya, lihat Log penyimpanan.

Persyaratan akun penyimpanan

Akun penyimpanan yang dibuat sebagai bagian dari alur pembuatan aplikasi fungsi di portal Azure dijamin berfungsi dengan aplikasi fungsi baru. Saat Anda memilih untuk menggunakan akun penyimpanan yang ada, daftar yang disediakan tidak menyertakan akun penyimpanan tertentu yang tidak didukung. Pembatasan berikut berlaku untuk akun penyimpanan yang digunakan oleh aplikasi fungsi Anda, jadi Anda harus memastikan akun penyimpanan yang ada memenuhi persyaratan berikut:

  • Jenis akun harus mendukung penyimpanan Blob, Antrean, dan Tabel. Beberapa akun penyimpanan tidak mendukung antrean dan tabel. Akun-akun ini termasuk akun penyimpanan khusus blob dan Azure Premium Storage. Untuk mempelajari jenis akun penyimpanan selengkapnya, lihat ringkasan akun penyimpanan.

  • Anda tidak dapat menggunakan akun penyimpanan yang diamankan jaringan saat aplikasi fungsi Anda dihosting dalam paket Konsumsi.

  • Saat membuat aplikasi fungsi di portal, Anda hanya diizinkan untuk memilih akun penyimpanan yang ada di wilayah yang sama dengan aplikasi fungsi yang Anda buat. Ini adalah pengoptimalan performa dan bukan batasan yang ketat. Untuk mempelajari selengkapnya, lihat Lokasi akun penyimpanan.

  • Saat membuat aplikasi fungsi Anda pada paket dengan dukungan zona ketersediaan diaktifkan, hanya akun penyimpanan zona redundan yang didukung.

Saat menggunakan otomatisasi penyebaran untuk membuat aplikasi fungsi Anda dengan akun penyimpanan yang diamankan jaringan, Anda harus menyertakan konfigurasi jaringan tertentu dalam templat ARM atau file Bicep Anda. Saat Anda tidak menyertakan pengaturan dan sumber daya ini, penyebaran otomatis Anda mungkin gagal dalam validasi. Untuk panduan ARM dan Bicep yang lebih spesifik, lihat Penyebaran aman. Untuk gambaran umum tentang mengonfigurasi akun penyimpanan dengan jaringan, lihat Cara menggunakan akun penyimpanan aman dengan Azure Functions.

Panduan akun penyimpanan

Setiap aplikasi fungsi memerlukan akun penyimpanan untuk beroperasi. Saat akun tersebut dihapus, aplikasi fungsi Anda tidak akan berjalan. Untuk memecahkan masalah terkait penyimpanan, lihat Cara memecahkan masalah terkait penyimpanan. Pertimbangan lain berikut berlaku untuk akun Storage yang digunakan oleh aplikasi fungsi.

Lokasi akun penyimpanan

Agar performanya maksimal, aplikasi fungsi Anda harus menggunakan akun penyimpanan di wilayah yang sama, untuk mengurangi latensi. Portal Microsoft Azure memberlakukan praktik terbaik ini. Jika karena alasan tertentu Anda perlu menggunakan akun penyimpanan di wilayah yang berbeda dari aplikasi fungsi, Anda harus membuat aplikasi fungsi di luar portal.

Akun penyimpanan harus dapat diakses oleh aplikasi fungsi. Jika Anda perlu menggunakan akun penyimpanan aman, pertimbangkan untuk membatasi akun penyimpanan Anda ke jaringan virtual.

Pengaturan koneksi akun penyimpanan

Secara default, aplikasi fungsi mengonfigurasi AzureWebJobsStorage koneksi sebagai string koneksi yang disimpan di pengaturan aplikasi AzureWebJobsStorage, tetapi Anda juga dapat mengonfigurasi AzureWebJobsStorage untuk menggunakan koneksi berbasis identitas tanpa rahasia.

Aplikasi fungsi yang berjalan dalam paket Konsumsi (khusus Windows) atau paket Elastic Premium (Windows atau Linux) dapat menggunakan Azure Files untuk menyimpan gambar yang diperlukan untuk mengaktifkan penskalaan dinamis. Untuk paket ini, atur string koneksi untuk akun penyimpanan di pengaturan WEBSITE_CONTENTAZUREFILECONNECTIONSTRING dan nama berbagi file di pengaturan WEBSITE_CONTENTSHARE. Ini biasanya akun yang sama yang digunakan untuk AzureWebJobsStorage. Anda juga dapat membuat aplikasi fungsi yang tidak menggunakan Azure Files, tetapi penskalakan mungkin terbatas.

Catatan

Akun penyimpanan string koneksi harus diperbarui saat Anda meregenerasi kunci penyimpanan. Baca selengkapnya tentang manajemen kunci penyimpanan di sini.

Akun penyimpanan bersama

Beberapa aplikasi fungsi dapat berbagi akun penyimpanan yang sama tanpa ditemui masalah. Misalnya, di Visual Studio Anda dapat mengembangkan beberapa aplikasi menggunakan emulator penyimpanan Azurite. Dalam hal ini, emulator bertindak seperti satu akun penyimpanan. Akun penyimpanan yang sama dengan yang digunakan oleh aplikasi fungsi Anda juga dapat digunakan untuk menyimpan data aplikasi Anda. Namun, pendekatan ini tidak selalu merupakan ide yang baik dalam lingkungan produksi.

Anda mungkin perlu menggunakan akun penyimpanan terpisah untuk menghindari tabrakan ID host.

Pertimbangan kebijakan manajemen siklus hidup

Anda tidak boleh menerapkan kebijakan manajemen siklus hidup ke akun Blob Storage yang digunakan oleh aplikasi fungsi Anda. Functions menggunakan penyimpanan Blob untuk mempertahankan informasi penting, seperti kunci akses fungsi, dan kebijakan dapat menghapus blob (seperti kunci) yang diperlukan oleh host Functions. Jika Anda harus menggunakan kebijakan, kecualikan kontainer yang digunakan oleh Functions, yang diawali dengan azure-webjobs atau scm.

Log penyimpanan

Karena kode fungsi dan kunci mungkin bertahan di akun penyimpanan, pengelogan aktivitas terhadap akun penyimpanan adalah cara yang baik untuk memantau akses yang tidak sah. Log sumber daya Azure Monitor dapat digunakan untuk melacak peristiwa terhadap bidang data penyimpanan. Lihat Memantau Azure Storage untuk detail tentang cara mengonfigurasi dan memeriksa log ini.

Log aktivitas Azure Monitor memperlihatkan peristiwa sarana kontrol, termasuk operasi listKeys. Namun, Anda juga harus mengonfigurasi log sumber daya untuk akun penyimpanan guna melacak penggunaan kunci berikutnya atau operasi data plane berbasis identitas lainnya. Anda harus memiliki setidaknya kategori log StorageWrite yang diaktifkan untuk dapat mengidentifikasi modifikasi pada data di luar operasi Fungsi normal.

Untuk membatasi dampak potensial dari izin penyimpanan yang dilingkup secara luas, pertimbangkan untuk menggunakan tujuan nonstorage untuk log ini, seperti Analitik Log. Untuk informasi selengkapnya, lihat Memantau Azure Blob Storage.

Mengoptimalkan kinerja penyimpanan

Untuk memaksimalkan kinerja, gunakan akun penyimpanan terpisah untuk setiap aplikasi fungsi. Ini sangat penting ketika Anda memiliki fungsi Durable Functions atau Event Hub yang dipicu, yang keduanya menghasilkan volume transaksi penyimpanan yang tinggi. Saat logika aplikasi Anda berinteraksi dengan Azure Storage, baik secara langsung (menggunakan SDK Penyimpanan) atau melalui salah satu pengikatan penyimpanan, Anda harus menggunakan akun penyimpanan khusus. Misalnya, jika Anda memiliki fungsi yang dipicu Event Hub yang menulis beberapa data ke penyimpanan blob, gunakan dua akun penyimpanan—satu untuk aplikasi fungsi dan satu lagi untuk blob yang disimpan oleh fungsi.

Perutean yang konsisten melalui jaringan virtual

Beberapa aplikasi fungsi yang dihosting dalam paket yang sama juga dapat menggunakan akun penyimpanan yang sama untuk berbagi konten Azure Files (ditentukan oleh WEBSITE_CONTENTAZUREFILECONNECTIONSTRING). Ketika akun penyimpanan ini juga diamankan oleh jaringan virtual, semua aplikasi ini juga harus menggunakan nilai yang sama untuk vnetContentShareEnabled (sebelumnya WEBSITE_CONTENTOVERVNET) untuk menjamin bahwa lalu lintas dirutekan secara konsisten melalui jaringan virtual yang dimaksudkan. Ketidakcocokan dalam pengaturan ini antara aplikasi yang menggunakan akun penyimpanan Azure Files yang sama dapat mengakibatkan lalu lintas dirutekan melalui jaringan publik, yang menyebabkan akses diblokir oleh aturan jaringan akun penyimpanan.

Bekerja dengan blob

Skenario utama untuk Functions adalah pemrosesan file file dalam kontainer blob, seperti untuk pemrosesan gambar atau analisis sentimen. Untuk mempelajari selengkapnya, lihat Memproses unggahan file.

Pemicu pada kontainer blob

Ada beberapa cara untuk menjalankan kode fungsi Anda berdasarkan perubahan pada blob dalam kontainer penyimpanan. Gunakan tabel berikut untuk menentukan pemicu fungsi mana yang paling sesuai dengan kebutuhan Anda:

Strategi Kontainer (polling) Kontainer (peristiwa) Pemicu antrean Event Grid
Latensi Tinggi (hingga 10 menit) Kurang Penting Medium Kurang Penting
Batas Akun penyimpanan Akun khusus blob tidak didukung¹ tujuan umum v1 tidak didukung tidak ada tujuan umum v1 tidak didukung
Jenis pemicu Penyimpanan Blob Penyimpanan Blob Antrean Penyimpanan Event Grid
Versi ekstensi Mana pun Storage v5.x+ Apa pun Apa pun
Memproses blob yang ada Ya No No Tidak
Filter Pola nama blob Filter peristiwa n/a Filter peristiwa
Memerlukan langganan peristiwa Tidak Ya No Ya
Mendukung paket Konsumsi Flex Tidak Ya Ya Ya
Mendukung skala tinggi² Tidak Ya Ya Ya
Deskripsi Perilaku pemicu default, yang bergantung pada polling kontainer untuk pembaruan. Untuk informasi selengkapnya, lihat contoh dalam referensi pemicu penyimpanan Blob. Mengonsumsi peristiwa penyimpanan blob dari langganan peristiwa. Memerlukan nilai parameter Source dari EventGrid. Untuk informasi selengkapnya, lihat Tutorial: Memicu Azure Functions pada kontainer blob menggunakan langganan peristiwa. String nama blob ditambahkan secara manual ke antrean penyimpanan saat blob ditambahkan ke kontainer. Nilai ini diteruskan langsung oleh pemicu penyimpanan Antrean ke pengikatan input penyimpanan Blob pada fungsi yang sama. Memberikan fleksibilitas pemicu pada beberapa peristiwa selain yang berasal dari kontainer penyimpanan. Gunakan ketika perlu juga memiliki peristiwa nonstorage yang memicu fungsi Anda. Untuk informasi selengkapnya, lihat Cara menggunakan pemicu dan pengikatan Event Grid di Azure Functions.
  1. Pengikatan input dan output penyimpanan blob mendukung akun khusus blob.
  2. Skala tinggi dapat didefinisikan secara longgar sebagai kontainer yang memiliki lebih dari 100.000 blob di dalamnya atau akun penyimpanan yang memiliki lebih dari 100 pembaruan blob per detik.

Enkripsi data penyimpanan

Azure Storage mengenkripsi semua data di akun penyimpanan ketika tidak aktif. Untuk informasi lebih lanjut, lihat Enkripsi Azure Storage untuk data tidak aktif.

Secara default, data dienkripsi dengan kunci yang dikelola Microsoft. Untuk kontrol tambahan atas kunci enkripsi, Anda dapat menyediakan kunci yang dikelola pelanggan untuk digunakan pada enkripsi blob dan data file. Kunci ini harus ada di Azure Key Vault for Functions untuk dapat mengakses akun penyimpanan. Untuk mempelajari lebih lanjut, lihat Enkripsi ketika tidak aktif menggunakan kunci yang dikelola pelanggan.

Residensi data dalam wilayah

Jika semua data pelanggan harus tetap berada dalam satu wilayah, akun penyimpanan yang terkait dengan aplikasi fungsi harus satu dengan redundansi wilayah. Akun penyimpanan yang berlebihan di wilayah juga harus digunakan dengan Azure Durable Functions.

Data pelanggan lainnya yang dikelola platform hanya disimpan di wilayah ini saat hosting di Lingkungan Layanan Aplikasi (ASE) yang seimbang secara internal. Untuk mempelajari lebih lanjut, lihat Redundansi zona ASE.

Pertimbangan ID Host

Functions menggunakan nilai ID host sebagai cara untuk mengidentifikasi aplikasi fungsi tertentu secara unik dalam artefak yang disimpan. Secara default, ID ini dibuat secara otomatis dari nama aplikasi fungsi, dipotong menjadi 32 karakter pertama. ID ini kemudian digunakan saat menyimpan korelasi per aplikasi dan melacak informasi di akun penyimpanan yang ditautkan. Ketika Anda memiliki aplikasi fungsi dengan nama yang lebih panjang dari 32 karakter dan ketika 32 karakter pertama identik, pemotongan ini dapat menghasilkan nilai ID host duplikat. Saat dua aplikasi fungsi dengan ID host yang identik menggunakan akun penyimpanan yang sama, Anda mendapatkan tabrakan ID host karena data yang disimpan tidak dapat ditautkan secara unik ke aplikasi fungsi yang benar.

Catatan

Jenis tabrakan ID host yang sama ini dapat terjadi antara aplikasi fungsi di slot produksi dan aplikasi fungsi yang sama di slot penahapan, saat kedua slot menggunakan akun penyimpanan yang sama.

Dimulai dengan runtime Functions versi 3.x, tabrakan ID host terdeteksi dan peringatan dicatat. Dalam versi 4.x, kesalahan dicatat dan host dihentikan, mengakibatkan kegagalan keras. Detail selengkapnya tentang tabrakan ID host dapat ditemukan dalam masalah ini.

Menghindari tabrakan ID host

Anda dapat menggunakan strategi berikut untuk menghindari tabrakan ID host:

  • Gunakan akun penyimpanan terpisah untuk setiap aplikasi fungsi atau slot yang terlibat dalam tabrakan.
  • Ganti nama salah satu aplikasi fungsi Anda menjadi nilai yang panjangnya kurang dari 32 karakter, yang mengubah ID host komputasi untuk aplikasi dan menghapus tabrakan.
  • Atur ID host eksplisit untuk satu atau beberapa aplikasi yang bertabrakan. Untuk mempelajari selengkapnya, lihat Penimpaan ID Host.

Penting

Mengubah akun penyimpanan yang terkait dengan aplikasi fungsi yang ada atau mengubah ID host aplikasi dapat memengaruhi perilaku fungsi yang ada. Misalnya, pemicu penyimpanan Blob melacak apakah blob individual diproses dengan menulis tanda terima di bawah jalur ID host tertentu di penyimpanan. Ketika ID host berubah atau Anda menunjuk ke akun penyimpanan baru, blob yang diproses sebelumnya dapat diproses ulang.

Mengambil alih ID host

Anda dapat secara eksplisit mengatur ID host tertentu untuk aplikasi fungsi Anda di pengaturan aplikasi dengan menggunakan pengaturan AzureFunctionsWebHost__hostid. Untuk informasi selengkapnya, lihat AzureFunctionsWebHost__hostid.

Ketika tabrakan terjadi di antara slot, Anda harus mengatur ID host tertentu untuk setiap slot, termasuk slot produksi. Anda juga harus menandai pengaturan ini sebagai pengaturan penyebaran sehingga tidak ditukar. Untuk mempelajari cara membuat pengaturan aplikasi, lihat Bekerja dengan pengaturan aplikasi.

Kluster yang mendukung Azure Arc

Saat aplikasi fungsi Anda disebarkan ke kluster Kubernetes dengan dukungan Azure Arc, akun penyimpanan mungkin tidak diperlukan oleh aplikasi fungsi Anda. Dalam hal ini, akun penyimpanan hanya diperlukan oleh Functions saat aplikasi fungsi Anda menggunakan pemicu yang memerlukan penyimpanan. Tabel berikut menunjukkan pemicu mana yang mungkin memerlukan akun penyimpanan dan mana yang tidak.

Tidak diperlukan mungkin memerlukan penyimpanan
• Azure Cosmos DB
• HTTP
• Kafka
• RabbitMQ
• Bus Layanan		 • Azure SQL
• Penyimpanan blob
• Event Grid
• Pusat Aktivitas
• IoT Hub
• Penyimpanan antrean
• SendGrid
• SignalR
• Penyimpanan tabel
• Timer
• Twilio

Untuk membuat aplikasi fungsi pada kluster Kubernetes dengan dukungan Azure Arc tanpa penyimpanan, Anda harus menggunakan perintah Azure CLI buat az functionapp. Versi Azure CLI harus menyertakan versi 0.1.7 atau versi yang lebih baru dari ekstensi appservice-kube. Gunakan perintah az --version untuk memverifikasi bahwa ekstensi telah diinstal dan merupakan versi yang benar.

Membuat sumber daya aplikasi fungsi Anda menggunakan metode selain Azure CLI memerlukan akun penyimpanan yang sudah ada. Jika Anda berencana menggunakan pemicu apa pun yang memerlukan akun penyimpanan, Anda harus membuat akun sebelum membuat aplikasi fungsi.

Membuat aplikasi tanpa Azure Files

Layanan Azure Files menyediakan sistem file bersama yang mendukung skenario skala tinggi. Saat aplikasi fungsi Anda berjalan di Windows dalam paket Elastic Premium atau Consumption, berbagi Azure Files dibuat secara default di akun penyimpanan Anda. Berbagi tersebut digunakan oleh Functions untuk mengaktifkan fitur tertentu, seperti streaming log. Ini juga digunakan sebagai lokasi penyebaran paket bersama, yang menjamin konsistensi kode fungsi yang Anda sebarkan di semua instans.

Secara default, aplikasi fungsi yang dihosting dalam paket Premium dan Konsumsi menggunakan penyebaran zip, dengan paket penyebaran yang disimpan dalam berbagi file Azure ini. Bagian ini hanya relevan dengan paket hosting ini.

Menggunakan Azure Files memerlukan penggunaan string koneksi, yang disimpan di pengaturan aplikasi Anda sebagai WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files saat ini tidak mendukung koneksi berbasis identitas. Jika skenario mengharuskan Anda untuk tidak menyimpan rahasia apa pun di pengaturan aplikasi, Anda harus menghapus dependensi aplikasi pada Azure Files. Anda dapat melakukan ini dengan membuat aplikasi tanpa dependensi Azure Files default.

Catatan

Anda juga harus mempertimbangkan untuk berjalan di aplikasi fungsi Anda dalam paket Konsumsi Flex, yang saat ini dalam pratinjau. Paket Konsumsi Flex memberikan kontrol yang lebih besar atas paket penyebaran, termasuk kemampuan menggunakan koneksi identitas terkelola. Untuk informasi selengkapnya, lihat Mengonfigurasi pengaturan penyebaran di artikel Konsumsi Flex.

Untuk menjalankan aplikasi tanpa berbagi file Azure, Anda harus memenuhi persyaratan berikut:

Anda bertanggung jawab untuk memperbarui paket penyebaran secara manual dan mempertahankan URL paket penyebaran, yang kemungkinan berisi tanda tangan akses bersama (SAS).

  • Aplikasi Anda tidak dapat mengandalkan sistem file bersama yang dapat ditulis.
  • Aplikasi tidak dapat menggunakan runtime Functions versi 1.x.
  • Log pengalaman streaming di klien seperti portal Microsoft Azure default ke log sistem file. Anda sebaiknya mengandalkan log Application Insights.

Jika persyaratan di atas sesuai dengan skenario Anda, Anda dapat melanjutkan untuk membuat aplikasi fungsi tanpa Azure Files. Anda dapat melakukan ini dengan membuat aplikasi tanpa WEBSITE_CONTENTAZUREFILECONNECTIONSTRING pengaturan aplikasi dan WEBSITE_CONTENTSHARE . Untuk memulai, buat templat ARM untuk penyebaran standar, hapus dua pengaturan, lalu sebarkan templat yang dimodifikasi.

Karena Azure Files digunakan untuk mengaktifkan peluasan skala dinamis untuk Functions, penskalaan dapat dibatasi saat menjalankan aplikasi Anda tanpa Azure Files dalam paket Elastic Premium dan paket Konsumsi yang berjalan di Windows.

Kaitkan pembagian file

Fungsi ini saat ini hanya tersedia untuk operasi Linux.

Anda dapat memasang berbagi Azure Files yang ada ke aplikasi fungsi Linux Anda. Dengan memasang berbagi ke aplikasi fungsi Linux, Anda dapat memanfaatkan model pembelajaran mesin atau data lain yang ada dalam fungsi Anda. Anda dapat menggunakan perintah berikut untuk memasang pembagian yang ada ke aplikasi fungsi Linux Anda.

az webapp config storage-account add

Dalam perintah ini, share-name adalah nama berbagi Azure Files yang ada, dan custom-id dapat menjadi string apa pun yang khusus menentukan pembagian file saat dipasang ke aplikasi fungsi. mount-path juga merupakan jalur tempat pembagian diakses di aplikasi fungsi Anda. mount-path harus dalam format /dir-name, dan tidak dapat dimulai dengan /home.

Untuk contoh lengkapnya, lihat skrip di Membuat aplikasi fungsi Python dan memasang berbagi Azure Files.

Saat ini, hanya storage-type dari AzureFiles yang didukung. Anda hanya dapat memasang lima pembagian ke aplikasi fungsi tertentu. Memasang berbagi file dapat meningkatkan waktu mulai dingin setidaknya 200-300 ms, atau bahkan lebih ketika akun penyimpanan berada di wilayah yang berbeda.

Pembagian file tersedia untuk kode fungsi Anda pada mount-path yang ditentukan. Misalnya, ketika mount-path adalah /path/to/mount, Anda dapat mengakses direktori target berdasarkan API sistem file, seperti dalam contoh Python berikut:

import os
...

files_in_share = os.listdir("/path/to/mount")

Langkah berikutnya

Pelajari selengkapnya tentang opsi hosting Azure Functions.

Skala dan hosting Azure Functions