Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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:
| 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. Pertahankan bundel ekstensi. Simpan log penyebaran. Mendukung dependensi dikelola di PowerShell. |
| Azure Queue Penyimpanan | 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. Digunakan untuk melacak peristiwa diagnostik. |
- Penyimpanan blob adalah penyimpanan default untuk kunci fungsi, tetapi Anda dapat mengonfigurasi penyimpanan alternatif.
- 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, 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 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 Anda buat selama proses pembuatan aplikasi fungsi di portal Microsoft 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 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 Microsoft 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 templat ARM dan panduan 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 Microsoft 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 Microsoft 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 AzureWebJobsStorage koneksi 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 (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. Nilai ini biasanya merupakan akun yang sama yang digunakan untuk AzureWebJobsStorage. Anda juga dapat membuat aplikasi fungsi yang tidak menggunakan Azure Files, tetapi penskalakan mungkin terbatas.
Catatan
Anda harus memperbarui string koneksi akun penyimpanan saat meregenerasi kunci penyimpanan. Untuk informasi selengkapnya, lihat Membuat 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 tabrakan ID host.
Pertimbangan kebijakan manajemen siklus hidup
Jangan terapkan 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. 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. Pendekatan ini sangat penting ketika Anda memiliki fungsi yang dipicu Durable Functions atau Event Hubs, 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 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 kontainer blob
Ada beberapa cara untuk menjalankan kode fungsi Anda berdasarkan perubahan pada blob dalam kontainer penyimpanan, seperti yang ditunjukkan oleh diagram ini:
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 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 | Penyimpanan v5.x+ | Mana pun | Mana pun |
| Memproses blob yang ada | Ya | Tidak. | Tidak. | Tidak. |
| Filter | Pola nama blob | Filter peristiwa | N/a | Filter peristiwa |
| Memerlukan langganan peristiwa | Tidak. | Ya | Tidak. | Ya |
| Mendukung paket Konsumsi Flex | Tidak. | Ya | Ya | Ya |
| Mendukung skala tinggi² | Tidak. | Ya | Ya | Ya |
| Bekerja dengan pembatasan akses masuk | Ya | Tidak. | Ya | Ya3 |
| 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. 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 ketika perlu juga memiliki peristiwa nonstorage yang memicu fungsi Anda. Untuk informasi selengkapnya, lihat Cara menggunakan pemicu dan pengikatan Event Grid di Azure Functions. |
- Pengikatan input dan output penyimpanan blob mendukung akun khusus blob.
- 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.
- 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.
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 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 for Functions untuk 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 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
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. 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
Tabrakan ID host semacam ini dapat terjadi antara aplikasi fungsi di slot produksi dan aplikasi fungsi yang sama di slot penahapan, 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 Pemotongan HostID dapat menyebabkan tabrakan.
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 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 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, aplikasi fungsi Anda mungkin tidak memerlukan akun penyimpanan. Dalam hal ini, fungsi hanya memerlukan akun penyimpanan 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 dalam paket Elastic Premium atau di 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 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 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 menyebarkan paket Anda ke kontainer penyimpanan Azure Blob jarak jauh lalu mengatur URL yang menyediakan akses ke paket tersebut
WEBSITE_RUN_FROM_PACKAGEsebagai pengaturan aplikasi. Pendekatan ini memungkinkan Anda menyimpan konten aplikasi di penyimpanan Blob alih-alih Azure Files, yang mendukung identitas terkelola.
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.
- Log pengalaman streaming di klien seperti portal Microsoft Azure default 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 Microsoft Azure: batal pilih Tambahkan koneksi Azure Files di tab Penyimpanan saat Anda membuat aplikasi di portal Microsoft Azure.
Azure Files digunakan untuk mengaktifkan peluasan skala dinamis untuk Functions. Penskalaan dapat dibatasi saat Anda menjalankan aplikasi tanpa Azure Files dalam paket Elastic Premium dan rencana Konsumsi yang berjalan di platform 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.
Penting
Setelah 30 September 2028, opsi untuk menghosting aplikasi fungsi Anda di Linux dalam paket Konsumsi dihentikan. Untuk menghindari gangguan, migrasikan aplikasi paket Konsumsi yang ada yang berjalan di Linux ke paket Konsumsi Flex sebelum tanggal tersebut. Aplikasi yang berjalan di Windows dalam paket Konsumsi tidak terpengaruh oleh perubahan ini. Untuk informasi selengkapnya, lihat pemberitahuan penghentian paket Konsumsi Linux.
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.
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 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")
Artikel terkait
Pelajari selengkapnya tentang opsi hosting Azure Functions.