Pertimbangan penyimpanan untuk Azure Functions

Saat membuat instans aplikasi fungsi di Azure, Anda harus menyediakan akses ke akun Azure Storage default. Diagram dan tabel berikut merinci bagaimana Azure Functions menggunakan layanan di akun penyimpanan default:

Diagram memperlihatkan bagaimana Azure Functions menggunakan layanan penyimpanan yang berbeda dalam akun Azure Storage, termasuk penyimpanan Blob, Berbagi file, penyimpanan Antrean, dan Penyimpanan tabel.

Layanan penyimpanan Penggunaan fungsi
Penyimpanan Blob Azure Pertahankan status pengikatan dan kuncifungsi 1.
Sumber penyebaran untuk aplikasi yang berjalan dalam rencana Konsumsi Flex.
Digunakan sebagai default untuk hub tugas di Durable Functions.
Dapat digunakan untuk menyimpan kode fungsi aplikasi untuk build Konsumsi Linux jarak jauh 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.
Pertahankan bundel ekstensi.
Simpan log penyebaran.
Mendukung dependensi dikelola di PowerShell.
penyimpanan Antrean Azure Digunakan sebagai default untuk hub tugas di Durable Functions. Digunakan untuk penanganan kegagalan dan coba lagi dalam pemicu Azure Functions spesifik. Digunakan untuk pelacakan objek oleh trigger penyimpanan Blob.
Penyimpanan Tabel Azure Digunakan sebagai default untuk hub tugas di Durable Functions.
Digunakan untuk melacak peristiwa diagnostik.
  1. Penyimpanan blob adalah penyimpanan default untuk kunci fungsi, tetapi Anda dapat mengonfigurasi penyimpanan alternatif.
  2. Azure Files disiapkan secara default, tetapi Anda dapat buat 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, bertahan 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 yang ditetapkan dalam peran 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 Anda buat selama proses pembuatan aplikasi fungsi di portal Azure 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. Pastikan 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 mencakup 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 Consumption.

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

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

Saat Anda menggunakan otomatisasi penyebaran untuk membuat aplikasi fungsi dengan akun penyimpanan yang diamankan jaringan, Anda harus menyertakan konfigurasi jaringan tertentu dalam templat ARM atau file Bicep Anda. Jika Anda tidak menyertakan pengaturan dan sumber daya ini, penyebaran otomatis Anda mungkin gagal dalam validasi. Untuk panduan templat ARM dan Bicep, lihat penyebaran yang 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 Anda menghapus akun tersebut, aplikasi fungsi Anda berhenti berjalan. Untuk memecahkan masalah terkait penyimpanan, lihat Cara memecahkan masalah terkait penyimpanan. Pertimbangan berikut berlaku untuk akun penyimpanan 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 Azure memberlakukan praktik terbaik ini. Jika perlu menggunakan akun penyimpanan di wilayah yang berbeda dari aplikasi fungsi, Anda harus membuat aplikasi fungsi di luar portal Azure.

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 koneksi AzureWebJobsStorage sebagai string koneksi yang disimpan di pengaturan aplikasi AzureWebJobsStorage. Anda juga dapat mengonfigurasi AzureWebJobsStorage untuk menggunakan koneksi berbasis identitas tanpa rahasia.

Aplikasi fungsi yang berjalan dalam paket Konsumsi (hanya Windows) atau paket Elastic Premium (Windows atau Linux) dapat menggunakan Azure Files untuk menyimpan gambar yang diperlukan untuk mengaktifkan penskalaan dinamis. Untuk rencana-rencana ini, atur string koneksi untuk akun penyimpanan pada pengaturan WEBSITE_CONTENTAZUREFILECONNECTIONSTRING dan nama file share pada pengaturan WEBSITE_CONTENTSHARE. Nilai ini biasanya merupakan akun yang sama yang digunakan untuk AzureWebJobsStorage. Anda juga dapat buat aplikasi fungsi yang tidak menggunakan Azure Files, tetapi penskalaan mungkin terbatas.

Catatan

Anda harus memperbarui string koneksi akun penyimpanan saat meregenerasi kunci penyimpanan. Untuk informasi selengkapnya, lihat Buat akun penyimpanan Azure.

Akun penyimpanan bersama

Beberapa aplikasi fungsi dapat berbagi akun penyimpanan yang sama tanpa masalah. Misalnya, di Visual Studio, Anda dapat mengembangkan beberapa aplikasi dengan menggunakan emulator penyimpanan Azurite. Dalam hal ini, emulator bertindak seperti satu akun penyimpanan. Akun penyimpanan yang sama dengan yang digunakan aplikasi fungsi Anda juga dapat 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 konflik ID host.

Pertimbangan kebijakan manajemen siklus hidup

Jangan terapkan kebijakan manajemen lifecycle ke akun Blob Storage yang digunakan oleh aplikasi fungsi Anda. Functions menggunakan penyimpanan Blob untuk mempertahankan informasi penting, seperti kunci akses fungsi. 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 dari lapisan data penyimpanan. Lihat Monitoring Azure Storage untuk detail tentang cara mengonfigurasi dan memeriksa log ini.

Log aktivitas Azure Monitor menunjukkan 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 Log Analytics. Untuk informasi selengkapnya, lihat Monitoring Azure Blob Storage.

Mengoptimalkan kinerja penyimpanan

Untuk memaksimalkan kinerja, gunakan akun penyimpanan terpisah untuk setiap aplikasi fungsi. Pendekatan ini sangat penting ketika Anda memiliki fungsi yang dipicu Durable Functions atau Azure Event Hubs, yang keduanya menghasilkan volume transaksi penyimpanan yang tinggi. Saat logika aplikasi Anda berinteraksi dengan Azure Storage, baik secara langsung (menggunakan Storage SDK) atau melalui salah satu pengikatan penyimpanan, Anda harus menggunakan akun penyimpanan khusus. Misalnya, jika Anda memiliki fungsi yang dipicu oleh hub acara yang menuliskan data ke dalam 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, yang ditentukan oleh WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Saat Anda mengamankan akun penyimpanan ini dengan menggunakan jaringan virtual, semua aplikasi ini (termasuk slot) harus menggunakan nilai yang sama untuk vnetContentShareEnabled (sebelumnya WEBSITE_CONTENTOVERVNET) dan konfigurasi integrasi jaringan virtual yang sama untuk memastikan bahwa lalu lintas merutekan secara konsisten melalui jaringan virtual yang dimaksudkan. Ketidakcocokan dalam pengaturan ini antara aplikasi yang menggunakan akun penyimpanan Azure Files yang sama dapat mengakibatkan perutean lalu lintas melalui jaringan publik. Dalam konfigurasi ini, aturan jaringan akun penyimpanan memblokir akses.

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 wadah blob

Ada beberapa cara untuk menjalankan kode fungsi Anda berdasarkan perubahan pada blob dalam kontainer penyimpanan, seperti yang ditunjukkan oleh diagram ini:

Diagram yang memperlihatkan berbagai opsi untuk memicu fungsi saat item ditambahkan atau diperbarui dalam kontainer Blob Storage di Azure.

Gunakan tabel berikut untuk menentukan pemicu fungsi mana yang paling sesuai dengan kebutuhan Anda untuk memproses blob yang ditambahkan atau diperbarui dalam kontainer:

Strategi Pemicu blob (polling) Pemicu berbasis peristiwa Blob Pemicu antrean Pemicu Event Grid
Latensi Tinggi (hingga 10 menit) Kurang Penting Menengah Kurang Penting
Batas Akun penyimpanan Akun hanya untuk Blob tidak didukung¹ tujuan umum v1 tidak didukung tidak ada tujuan umum v1 tidak didukung
Jenis pemicu Penyimpanan Blob Penyimpanan Blob Queue Storage Event Grid
Versi ekstensi Apa saja Penyimpanan v5.x+ Apa saja Apa saja
Memproses blob yang ada Ya Tidak. Tidak. Tidak.
Filter Pola nama blob Filter peristiwa N/a Filter peristiwa
Memerlukan subskripsi acara Tidak. Ya Tidak. Ya
Mendukung Paket Konsumsi Fleksibel Tidak. Ya Ya Ya
Mendukung skala tinggi² Tidak. Ya Ya Ya
Bekerja dengan pembatasan akses masuk Ya Tidak. Ya Ya3
Deskripsi Perilaku standar pemicu, yang mengandalkan pengecekan berkala pada kontainer untuk mengupdate. 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: Menjalankan Azure Functions pada wadah blob menggunakan langganan peristiwa. String nama blob ditambahkan secara manual ke antrean penyimpanan saat blob ditambahkan ke kontainer. Pemicu penyimpanan Antrian meneruskan nilai ini langsung ke ikatan input penyimpanan Blob pada fungsi yang sama. Memberikan fleksibilitas pemicu pada peristiwa selain peristiwa yang berasal dari kontainer penyimpanan. Gunakan jika Anda juga perlu agar fungsi Anda dipicu oleh peristiwa nonstorage. Untuk informasi selengkapnya, lihat Cara bekerja dengan 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.
  3. Anda dapat mengatasi pembatasan akses masuk dengan meminta langganan peristiwa mengirimkan peristiwa melalui saluran terenkripsi di ruang IP publik menggunakan identitas pengguna yang diketahui. Untuk informasi selengkapnya, lihat Mengirimkan peristiwa dengan aman menggunakan identitas terkelola.

Data penyimpanan terenkripsi

Azure Storage mengenkripsi semua data di akun penyimpanan saat tidak aktif. Untuk informasi selengkapnya, lihat enkripsi Azure Storage untuk data tidak aktif.

Secara default, data dienkripsi dengan kunci yang dikelola Microsoft. Untuk kontrol lebih besar atas kunci enkripsi, Anda dapat menyediakan kunci yang dikelola pelanggan untuk digunakan untuk enkripsi blob dan data file. Kunci ini harus ada di Azure Key Vault agar Functions dapat mengakses akun penyimpanan. Untuk mempelajari selengkapnya, lihat Mengenkripsi data aplikasi Anda saat 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 redundan dalam kawasan juga harus digunakan dengan Azure Durable Functions.

Data pelanggan lain yang dikelola oleh platform hanya disimpan di dalam wilayah ketika hosting di App Service Environment (ASE) dengan penyeimbangan beban internal. Untuk mempelajari lebih lanjut, lihat Redundansi zona ASE.

Pertimbangan ID Host

Catatan

Pertimbangan ID Host di bagian ini tidak berlaku saat aplikasi Anda berjalan dalam paket Konsumsi Flex. Dalam paket hosting ini, nilai ID Host dibuat dengan cara yang menghindari potensi masalah ini.

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. Ketika dua fungsi aplikasi dengan ID host yang identik menggunakan akun penyimpanan yang sama, terjadi tabrakan ID host karena data yang disimpan tidak dapat ditautkan secara unik ke fungsi aplikasi yang benar.

Catatan

Konflik ID host semacam ini dapat terjadi antara aplikasi fungsi di slot produksi dan aplikasi fungsi yang sama di slot pengujian, ketika kedua slot menggunakan akun penyimpanan yang sama.

Dalam versi 4.x dari runtime Functions, ketika terjadi kesalahan, kesalahan tersebut dicatat dan host akan dihentikan, yang mengakibatkan kegagalan fatal. Untuk informasi selengkapnya, lihat HostID Truncation dapat menyebabkan tabrakan.

Menghindari konflik 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 lebih lanjut, lihat Mengambil alih 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 pengecekan blob melacak apakah blob individual telah diproses dengan mencatat tanda terima di jalur ID host tertentu dalam 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.

Membuat aplikasi tanpa Azure Files

Layanan Azure Files menyediakan sistem file bersama yang mendukung skenario skala tinggi. Saat aplikasi fungsi Anda berjalan dalam paket Elastic Premium atau pada Windows dalam paket Konsumsi, berbagi Azure Files dibuat secara default di akun penyimpanan Anda. Berbagi ini 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 zip deployment, dengan paket penyebaran yang disimpan dalam file share 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 menghindari dependensi ini dengan membuat aplikasi tanpa dependensi Azure Files default.

Catatan

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

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

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

Anda juga harus mencatat pertimbangan berikut:

  • Aplikasi tidak dapat menggunakan runtime Functions versi 1.x.
  • Aplikasi Anda tidak dapat mengandalkan sistem file bersama yang dapat ditulis.
  • Pengeditan portal tidak didukung.
  • Pengalaman streaming log di klien, seperti portal Azure, secara default mengarah ke log sistem file. Anda sebaiknya mengandalkan log Application Insights.

Jika persyaratan sebelumnya sesuai dengan skenario Anda, Anda dapat melanjutkan untuk membuat aplikasi fungsi tanpa Azure Files. Buat aplikasi tanpa pengaturan aplikasi WEBSITE_CONTENTAZUREFILECONNECTIONSTRING dan WEBSITE_CONTENTSHARE dengan salah satu cara berikut:

  • templat Bicep/ARM: hapus dua pengaturan aplikasi dari templat ARM atau file Bicep lalu sebarkan aplikasi menggunakan templat yang dimodifikasi.
  • Portal Azure: batalkan pilihan Tambahkan koneksi Azure Files di tab Storage saat Anda membuat aplikasi di portal Azure.

Azure Files digunakan untuk mengaktifkan peluasan skala dinamis untuk Functions. Penskalaan mungkin terbatas saat Anda menjalankan aplikasi tanpa menggunakan Azure Files dalam paket Elastic Premium dan paket Konsumsi pada Windows.

Pasang pembagian file

Fungsionalitas ini saat ini hanya tersedia saat berjalan di Linux.

Anda dapat memasang share Azure Files pada aplikasi fungsi Linux Anda, yang memungkinkan Anda mengakses file yang ada, model pembelajaran mesin, atau biner besar dalam fungsi Anda. Pemasangan penyimpanan tidak didukung pada paket Konsumsi . Untuk panduan konseptual tentang memilih antara pemasangan penyimpanan, pengikatan, dan database eksternal, lihat Memilih strategi akses file untuk Azure Functions.

Penting

Aplikasi fungsi yang masih menggunakan runtime v3 yang sudah mencapai akhir masa pakai di Linux dalam rencana Konsumsi akan berhenti beroperasi setelah 30 September 2026. Untuk menghindari gangguan layanan, migrasikan aplikasi Anda ke runtime v4.

Opsi untuk menghosting aplikasi fungsi di Linux dalam paket Konsumsi akan dihentikan pada 30 September 2028. Paket Konsumsi Linux tidak mendapatkan fitur atau versi bahasa baru. Aplikasi yang berjalan di Windows dalam paket Konsumsi saat ini tidak terpengaruh. Migrasikan aplikasi Anda ke paket Konsumsi Flex sebelum tanggal penghentian.

Anda dapat menggunakan perintah berikut untuk memasang pembagian yang ada ke aplikasi fungsi Linux Anda.

Perintah untuk menambahkan akun penyimpanan ke konfigurasi aplikasi web Azure adalah az webapp config storage-account add

Dalam perintah ini, share-name adalah nama berbagi Azure Files yang ada. custom-id dapat berupa string apa saja yang secara unik mendefinisikan share 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 Buat aplikasi fungsi Python dan pasang berbagi Azure Files.

Artikel terkait

Pelajari selengkapnya tentang opsi hosting Azure Functions.

Penskalakan dan hosting Azure Functions

  • Last updated on