إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
عند إنشاء مثيل تطبيق وظائف في Azure، يجب عليك توفير الوصول إلى حساب Azure Storage افتراضي. يوضح المخطط والجدول التاليان كيف يستخدم Azure Functions الخدمات في حساب التخزين الافتراضي:
| خدمة التخزين | استخدام الوظائف |
|---|---|
| تخزين Azure Blob | الحفاظ على مفاتيح حالة الروابط والوظائف1. مصدر التوزيع للتطبيقات التي تعمل في خطة استهلاك Flex. يستخدم افتراضيا لمراكز المهام في Durable Functions. يمكن استخدامها لتخزين التعليمات البرمجية لتطبيق الوظائف للإنشاء عن بعد لاستهلاك Linux أو كجزء من عمليات نشر عنوان URL للحزمة الخارجية. |
| ملفات Azure2 | مشاركة الملفات المستخدمة لتخزين وتشغيل رمز تطبيق الوظائف الخاص بك في خطة الاستهلاكوالخطة المميزة. الحفاظ على حزم التمديد. تخزين سجلات النشر. يدعم التبعيات المدارة في PowerShell. |
| مخزن Azure Queue | يستخدم افتراضيا لمراكز المهام في Durable Functions. يستخدم لمعالجة الفشل وإعادة المحاولة في مشغلات Azure Functions معينة. يستخدم لتعقب الكائنات بواسطة مشغل تخزين Blob. |
| تخزين Azure Table | يستخدم افتراضيا لمراكز المهام في Durable Functions. تستخدم لتتبع الأحداث التشخيصية. |
- تخزين Blob هو المخزن الافتراضي للمفاتيح الوظيفية، ولكن يمكنك تكوين مخزن بديل.
- يتم إعداد Azure Files بشكل افتراضي، ولكن يمكنك إنشاء تطبيق بدون Azure Files في ظل ظروف معينة.
اعتبارات هامة
يجب مراعاة الحقائق التالية بقوة فيما يتعلق بحسابات التخزين المستخدمة من قبل تطبيقات الوظائف الخاصة بك:
عند استضافة تطبيق الوظائف الخاص بك على خطة الاستهلاك أو خطة Premium، يتم تخزين التعليمات البرمجية للوظيفة وملفات التكوين في ملفات Azure في حساب التخزين المرتبط. عند حذف حساب التخزين هذا، يتم حذف المحتوى ولا يمكن استرداده. لمزيد من المعلومات، راجع حذف حساب التخزين.
البيانات المهمة، مثل كود الوظيفة، ومفاتيح الدخول، وغيرها من البيانات المهمة المتعلقة بالخدمة، تبقى في حساب التخزين. يجب عليك إدارة الوصول بعناية إلى حسابات التخزين المستخدمة من قبل تطبيقات الوظائف بالطرق التالية:
تدقيق وتقييد وصول التطبيقات والمستخدمين إلى حساب التخزين استنادا إلى نموذج أقل امتيازا. يمكن أن تأتي الأذونات لحساب التخزين من إجراءات البيانات في الدور المعين أو من خلال الإذن لتنفيذ عملية listKeys.
مراقبة كل من نشاط وحدة التحكم (مثل استرداد المفاتيح) وعمليات مستوى البيانات (مثل الكتابة إلى كائن ثنائي كبير الحجم) في حساب التخزين الخاص بك. ضع في اعتبارك الاحتفاظ بسجلات التخزين في موقع آخر غير Azure Storage. لمزيد من المعلومات، راجع سجلات التخزين.
متطلبات حساب التخزين
حسابات التخزين التي تنشئها أثناء عملية إنشاء تطبيق الوظائف في بوابة Azure تعمل مع تطبيق الوظائف الجديد. عند اختيار استخدام حساب تخزين موجود، لا تتضمن القائمة المقدمة بعض حسابات التخزين غير المدعومة. تنطبق القيود التالية على حسابات التخزين التي يستخدمها تطبيق الوظائف. تأكد من أن حساب تخزين موجود يفي بهذه المتطلبات:
يجب أن يدعم نوع الحساب تخزين Blob وQueue وTable. لا تدعم بعض حسابات التخزين قوائم الانتظار والجداول. تتضمن هذه الحسابات حسابات تخزين كائنات ثنائية كبيرة الحجم فقط وAzure Premium Storage. لمعرفة المزيد حول أنواع حسابات التخزين، راجع نظرة عامة على حساب التخزين .
لا يمكنك استخدام حساب تخزين آمن بالشبكة عند استضافة تطبيق الوظائف الخاص بك في خطة الاستهلاك.
عند إنشاء تطبيق الوظائف في بوابة Azure، يمكنك اختيار حساب تخزين موجود فقط في نفس المنطقة التي تنشئ فيها تطبيق الدالة. هذا المطلب هو تحسين الأداء وليس تقييدا صارما. لمعرفة المزيد، راجع موقع حساب التخزين.
عند إنشاء تطبيق الوظائف على خطة مع تمكين دعم منطقة التوفر ، يتم دعم حسابات التخزين المتكررة في المنطقة فقط.
عند استخدام أتمتة النشر لإنشاء تطبيق الوظائف باستخدام حساب تخزين مؤمن بالشبكة، يجب تضمين تكوينات شبكة معينة في قالب ARM أو ملف Bicep. إذا لم تدرج هذه الإعدادات والموارد، فقد يفشل النشر الآلي في التحقق. للحصول على قالب ARM وإرشادات Bicep، راجع عمليات النشر الآمنة. للحصول على نظرة عامة حول تكوين حسابات التخزين مع الشبكات، راجع كيفية استخدام حساب تخزين آمن مع Azure Functions.
إرشادات حساب التخزين
يتطلب كل تطبيق وظائف حساب تخزين للعمل. عندما تحذف ذلك الحساب، يتوقف تطبيق الوظائف عن العمل. لاستكشاف المشكلات المتعلقة بالتخزين وإصلاحها، راجع كيفية استكشاف المشكلات المتعلقة بالتخزين وإصلاحها. تنطبق الاعتبارات التالية على حساب التخزين المستخدم من قبل تطبيقات الوظائف.
موقع حساب التخزين
للحصول على أفضل أداء، يجب أن يستخدم تطبيق الوظائف حساب تخزين في نفس المنطقة، مما يقلل من زمن الانتقال. يفرض مدخل Azure هذه الممارسة (أفضل ممارسة). إذا كنت بحاجة لاستخدام حساب تخزين في منطقة مختلفة عن تطبيق الوظيفة الخاص بك، يجب عليك إنشاء تطبيق الوظائف خارج بوابة Azure.
يجب أن يكون حساب التخزين متاحا لتطبيق الوظائف. إذا كنت بحاجة إلى استخدام حساب تخزين آمن، ففكر في تقييد حساب التخزين الخاص بك إلى شبكة ظاهرية.
تعيين اتصال حساب التخزين
بشكل افتراضي، تقوم تطبيقات الوظائف بتكوين AzureWebJobsStorage الاتصال كسلسلة اتصال مخزنة في إعداد تطبيق AzureWebJobsStorage. يمكنك أيضا تكوين AzureWebJobsStorage لاستخدام اتصال قائم على الهوية دون وجود سر.
يمكن لتطبيقات الوظائف التي تعمل في خطة استهلاك (Windows فقط) أو خطة Elastic Premium (Windows أو Linux) استخدام ملفات Azure لتخزين الصور المطلوبة لتمكين التحجيم الديناميكي. بالنسبة لهذه الخطط، قم بتعيين سلسلة الاتصال لحساب التخزين في إعداد WEBSITE_CONTENTAZUREFILECONNECTIONSTRING واسم مشاركة الملف في إعداد WEBSITE_CONTENTSHARE . عادة ما تكون هذه القيمة هي نفس الحساب المستخدم ل AzureWebJobsStorage. يمكنك أيضا إنشاء تطبيق وظائف لا يستخدم Azure Files، ولكن قد يكون التحجيم محدودا.
Note
يجب عليك تحديث سلسلة اتصال حساب التخزين عند إعادة توليد مفاتيح التخزين. لمزيد من المعلومات، راجع إنشاء حساب تخزين Azure.
حسابات التخزين المشتركة
يمكن لتطبيقات متعددة الوظائف مشاركة نفس حساب التخزين بدون مشاكل. على سبيل المثال، في Visual Studio، يمكنك تطوير عدة تطبيقات باستخدام محاكي تخزين Azurite. في هذه الحالة، يعمل المحاكي مثل حساب تخزين واحد. نفس حساب التخزين الذي يستخدمه تطبيق الوظيفة يمكنه أيضا تخزين بيانات تطبيقك. ومع ذلك، فإن هذا النهج ليس دائما فكرة جيدة في بيئة التشغيل.
قد تحتاج إلى استخدام حسابات تخزين منفصلة لتجنب تضارب معرف المضيف.
اعتبارات نهج إدارة دورة الحياة
لا تطبق سياسات إدارة دورة الحياة على حساب Blob Storage الخاص بك الذي يستخدمه تطبيق الوظائف الخاص بك. تستخدم الدالات تخزين Blob لاستمرار المعلومات المهمة، مثل مفاتيح الوصول إلى الدالة. يمكن للنهج إزالة الكائنات الثنائية كبيرة الحجم، مثل المفاتيح، التي يحتاجها مضيف الوظائف. إذا كان يجب عليك استخدام النهج، فاستبعد الحاويات المستخدمة بواسطة Functions، والتي تكون مسبوقة ب azure-webjobs أو scm.
سجلات التخزين
نظرا لأن التعليمات البرمجية للوظيفة والمفاتيح قد تستمر في حساب التخزين، فإن تسجيل النشاط مقابل حساب التخزين هو طريقة جيدة لمراقبة الوصول غير المصرح به. يمكن استخدام سجلات موارد Azure Monitor لتعقب الأحداث مقابل مستوى بيانات التخزين. راجع مراقبة تخزين Azure للحصول على تفاصيل حول كيفية تكوين هذه السجلات وفحصها.
يعرض سجل نشاط Azure Monitor أحداث مستوى التحكم، بما في ذلك عملية listKeys. ومع ذلك، يجب عليك أيضا تكوين سجلات الموارد لحساب التخزين لتتبع الاستخدام اللاحق للمفاتيح أو عمليات مستوى البيانات الأخرى المستندة إلى الهوية. يجب أن يكون لديك على الأقل فئة سجل StorageWrite ممكنة لتكون قادرا على تحديد التعديلات على البيانات خارج عمليات الوظائف العادية.
للحد من التأثير المحتمل لأي أذونات تخزين ذات نطاق واسع، ضع في اعتبارك استخدام وجهة غير تخزين لهذه السجلات، مثل Log Analytics. لمزيد من المعلومات، راجع Monitoring Azure Blob Storage.
تحسين أداء التخزين
لتحقيق أقصى قدر من الأداء، استخدم حساب تخزين منفصل لكل تطبيق وظائف. هذا الأسلوب مهم بشكل خاص عندما يكون لديك Durable Functions أو Event Hubs تشغيل الوظائف، والتي تنشئ كل منهما حجم كبير من معاملات التخزين. عندما يتفاعل منطق التطبيق الخاص بك مع Azure Storage، إما مباشرةً (باستخدام SDK للتخزين) أو من خلال أحد روابط التخزين، يجب عليك استخدام حساب تخزين مخصص. على سبيل المثال، إذا كان لديك دالة مشغلة بواسطة مركز الأحداث تكتب بعض البيانات إلى تخزين كائن ثنائي كبير الحجم، فاستخدم حسابي تخزين: أحدهما لتطبيق الدالة والآخر للكائنات الثنائية كبيرة الحجم التي تخزنها الدالة.
التوجيه المتسق عبر الشبكات الظاهرية
يمكن لتطبيقات الوظائف المتعددة المستضافة في نفس الخطة أيضا استخدام نفس حساب التخزين لمشاركة محتوى ملفات Azure، المعرفة بواسطة WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. عند تأمين حساب التخزين هذا باستخدام شبكة افتراضية، يجب أن تستخدم جميع هذه التطبيقات (بما في ذلك الفتحات) نفس القيمة ل vnetContentShareEnabled (سابقا WEBSITE_CONTENTOVERVNET) ونفس تكوين تكامل الشبكة الافتراضية لضمان أن حركة المرور تسير باستمرار عبر الشبكة الافتراضية المقصودة. قد يؤدي عدم التوافق في هذا الإعداد بين التطبيقات التي تستخدم نفس حساب تخزين Azure Files إلى توجيه حركة المرور عبر الشبكات العامة. في هذا التكوين، تمنع قواعد شبكة حساب التخزين الوصول.
العمل مع الكائنات الثنائية كبيرة الحجم
السيناريو الرئيسي للدالات هو معالجة ملفات الملفات في حاوية كائن ثنائي كبير الحجم، مثل معالجة الصور أو تحليل المشاعر. لمعرفة المزيد، راجع معالجة تحميلات الملفات.
تشغيل على حاوية كائن ثنائي كبير الحجم
هناك عدة طرق لتشغيل التعليمات البرمجية للدالة استنادا إلى التغييرات التي تم إجراؤها على الكائنات الثنائية كبيرة الحجم في حاوية تخزين، كما هو موضح في هذا الرسم التخطيطي:
استخدم الجدول التالي لتحديد مشغل الدالة الذي يناسب احتياجاتك بشكل أفضل لمعالجة الكائنات الثنائية كبيرة الحجم المضافة أو المحدثة في حاوية:
| Strategy | مشغل الكائن الثنائي كبير الحجم (الاستقصاء) | مشغل الكائن الثنائي كبير الحجم (مدفوع بالحدث) | مشغِّل قائمة الانتظار | مشغل Event Grid |
|---|---|---|---|---|
| Latency | مرتفع (حتى 10 دقائق) | Low | Medium | Low |
| قيود حساب التخزين | حسابات Blob فقط غير مدعومة¹ | الإصدار 1 للغرض العام غير مدعوم | none | الإصدار 1 للغرض العام غير مدعوم |
| نوع المشغل | تخزين الكائن الثنائي كبير الحجم | تخزين الكائن الثنائي كبير الحجم | تخزين قائمة الانتظار | شبكة الأحداث |
| إصدار الامتداد | Any | التخزين v5.x+ | Any | Any |
| معالجة الكائنات الثنائية كبيرة الحجم الموجودة | Yes | No | No | No |
| Filters | نمط اسم الكائن الثنائي كبير الحجم | فلاتر الأحداث | n/a | فلاتر الأحداث |
| يتطلب اشتراك الحدث | No | Yes | No | Yes |
| يدعم خطة استهلاك Flex | No | Yes | Yes | Yes |
| يدعم التوسع الرفيع² | No | Yes | Yes | Yes |
| يعمل مع قيود الوصول الوارد | Yes | No | Yes | نعم3 |
| Description | سلوك المشغل الافتراضي والذي يعتمد على استقصاء الحاوية للتحديثات. لمزيد من المعلومات، راجع الأمثلة في مرجع مشغل تخزين Blob. | يستهلك أحداث تخزين كائن ثنائي كبير الحجم من اشتراك حدث. يتطلب قيمة معلمة Source من EventGrid. لمزيد من المعلومات، راجع البرنامج التعليمي: تشغيل Azure Functions على حاويات الكائن الثنائي كبير الحجم باستخدام اشتراك حدث. |
تُضاف سلسلة اسم كائن ثنائي كبير الحجم يدويًا إلى قائمة انتظار التخزين عند إضافة كائن ثنائي كبير الحجم إلى الحاوية. يقوم مشغل تخزين قائمة الانتظار بتمرير هذه القيمة مباشرة إلى ربط إدخال تخزين Blob على نفس الدالة. | يوفر مرونة التشغيل على الأحداث إلى جانب تلك الأحداث التي تأتي من حاوية تخزين. استخدم عندما تحتاج أيضا إلى تشغيل الأحداث غير التخزينية لدالتك. لمزيد من المعلومات، راجع كيف يمكن العمل مع مشغلات "شبكة الأحداث" والروابط في Azure Functions. |
- تدعم روابط إدخال وإخراج تخزين Blob حسابات الكائن الثنائي كبير الحجم فقط.
- يمكن تعريف النطاق العالي بشكل فضفاض على أنه حاويات تحتوي على أكثر من 100,000 كائن ثنائي كبير الحجم فيها أو حسابات تخزين تحتوي على أكثر من 100 تحديث للكائنات الثنائية كبيرة الحجم في الثانية.
- يمكنك التغلب على قيود الوصول الوارد من خلال جعل اشتراك الحدث يسلم الأحداث عبر قناة مشفرة في مساحة IP العامة باستخدام هوية مستخدم معروفة. لمزيد من المعلومات، راجع تسليم الأحداث بأمان باستخدام الهويات المدارة.
تشفير بيانات التخزين
يقوم Azure Storage بتشفير كافة البيانات الثابتة في حساب تخزين. لمزيد من المعلومات، راجع تشفير خدمة تخزين Azure للبيانات الثابتة.
بشكل افتراضي، يتم تشفير البيانات باستخدام المفاتيح المُدارة من قِبل Microsoft. لمزيد من التحكم في مفاتيح التشفير، يمكنك توفير مفاتيح يديرها العميل لاستخدامها لتشفير بيانات الملفات والكائنات الثنائية كبيرة الحجم. يجب أن تكون هذه المفاتيح موجودة في Azure Key Vault للوظائف لتتمكن من الوصول إلى حساب التخزين. لمعرفة المزيد، راجع تشفير بيانات التطبيق الثابتة باستخدام مفاتيح يديرها العميل.
موقع بيانات الإقامة المُتاحة في المنطقة
عندما يجب أن تظل جميع بيانات العميل داخل منطقة واحدة، يجب أن يكون حساب التخزين المقترن بتطبيق الوظائف حسابا به تكرار داخل المنطقة. يجب أيضًا استخدام حساب تخزين مكرر في المنطقة مع Azure Durable Functions.
يتم تخزين بيانات العملاء الأخرى المدارة من خلال النظام الأساسي فقط داخل المنطقة عند الاستضافة في App Service Environment المتوازنة داخليًا (ASE). لمعرفة المزيد، راجع التكرار في منطقة ASE.
اعتبارات معرف المضيف
Note
اعتبارات معرف المضيف في هذا القسم لا تنطبق عندما يعمل تطبيقك في خطة استهلاك مرنة. في خطة الاستضافة هذه، يتم إنشاء قيمة معرف المضيف بطريقة تتجنب هذه المشاكل المحتملة.
تستخدم الوظائف قيمة معرف المضيف كطريقة للتعرُّف بشكل فريد على تطبيق وظيفة معين في البيانات الاصطناعية المخزنة. بشكل افتراضي، يتم إنشاء هذا المعرف تلقائيا من اسم تطبيق الوظائف، ويتم اقتطاعه إلى أول 32 حرفا. ثم يتم استخدام هذا المعرف عند تخزين الارتباط لكل تطبيق وتتبع المعلومات في حساب التخزين المرتبط. عندما يكون لديك تطبيقات وظيفية بأسماء أطول من 32 حرفاً وعندما تكون الأحرف 32 الأولى متطابقة، يمكن أن ينتج عن هذا الاقتطاع قيم معرف مضيف مكررة. عندما يستخدم تطبيقان وظيفيان لهما معرّفات مضيف متطابقة نفس حساب التخزين، فإنك تحصل على تضارب معرّف المضيف لأن البيانات المخزنة لا يمكن ربطها بشكل فريد بFunction App الصحيح.
Note
يمكن أن يحدث هذا النوع نفسه من تصادم معرف المضيف بين تطبيق دالة في فتحة إنتاج ونفس تطبيق الوظائف في فتحة التقسيم المرحلي، عندما تستخدم كلتا الفتحتين نفس حساب التخزين.
في الإصدار 4.x من وقت تشغيل الوظائف، يتم تسجيل خطأ ويتم إيقاف المضيف، مما يؤدي إلى فشل صارم. لمزيد من المعلومات، راجع يمكن أن يتسبب اقتطاع HostID في حدوث تضاربات.
تجنب تضارب معرف المضيف
يمكنك استخدام الاستراتيجيات التالية لتجنب تضارب معرف المضيف:
- استخدم حساب تخزين منفصل لكل تطبيق وظيفة أو فتحة متضمنة في التصادم.
- أعد تسمية أحد تطبيقات الوظائف بقيمة أقل من 32 حرفاً في الطول، ما يغير معرف المضيف المحسوب للتطبيق ويزيل التعارض.
- قم بتعيين معرف مضيف صريح لواحد أو أكثر من التطبيقات المتضاربة. لمعرفة المزيد، راجع تجاوز معرف المضيف.
Important
يمكن أن يؤثر تغيير حساب التخزين المقترن بتطبيق دالة موجود أو تغيير معرف مضيف التطبيق على سلوك الوظائف الموجودة. على سبيل المثال، يتعقب مشغل تخزين Blob ما إذا كان قد تمت معالجتها للكائنات الثنائية كبيرة الحجم الفردية عن طريق كتابة الإيصالات ضمن مسار معرف مضيف معين في التخزين. عندما يتغير معرف المضيف أو تشير إلى حساب تخزين جديد، يمكن إعادة معالجة الكائنات الثنائية كبيرة الحجم التي تمت معالجتها مسبقا.
تجاوز معرف المضيف
يمكنك تعيين معرف مضيف محدد بشكل صريح لتطبيق وظيفتك في إعدادات التطبيق باستخدام الإعداد AzureFunctionsWebHost__hostid. لمزيد من المعلومات، راجع AzureFunctionsWebHost__hostid.
عند حدوث التصادم بين الفتحات، يجب تعيين معرف مضيف محدد لكل فتحة، بما في ذلك فتحة الإنتاج. يجب عليك أيضا وضع علامة على هذه الإعدادات كإعدادات نشر حتى لا يتم تبديلها. لمعرفة كيفية إنشاء إعدادات التطبيق، راجع التعامل مع إعدادات التطبيق .
نظام مجموعة Azure Arc المُمكّن
عند نشر تطبيق الوظائف الخاص بك إلى مجموعة Kubernetes الممكنة في Azure Arc، قد لا يتطلب تطبيق الوظائف حساب تخزين. في هذه الحالة، تتطلب الوظائف حساب تخزين فقط عندما يستخدم تطبيق الوظائف مشغلا يتطلب التخزين. يشير الجدول التالي إلى المشغلات التي قد تتطلب حساب تخزين وأيها لا يتطلب ذلك.
| غير مطلوب | قد يتطلب التخزين |
|---|---|
| • Azure Cosmos DB • HTTP • كافكا • RabbitMQ • ناقل الخدمة |
• Azure SQL • تخزين Blob • شبكة الأحداث • مراكز الفعاليات • مركز إنترنت الأشياء • تخزين قائمة الانتظار • SendGrid • سيجنال آر • تخزين الطاولة • مؤقت • تويليو |
لإنشاء تطبيق دالة على مجموعة Kubernetes الممكنة في Azure Arc بدون تخزين، يجب استخدام أمر Azure CLI az functionapp create. يجب أن يتضمن إصدار Azure CLI الإصدار 0.1.7 أو إصدارا أحدث من ملحق appservice-kube. استخدم أمر az --version للتحقق من تثبيت الملحق وهو الإصدار الصحيح.
يتطلب إنشاء موارد تطبيق الوظائف باستخدام أساليب أخرى غير Azure CLI حساب تخزين موجود. إذا كنت تخطط لاستخدام أي مشغلات تتطلب حساب تخزين، فيجب عليك إنشاء الحساب قبل إنشاء تطبيق الوظائف.
إنشاء تطبيق بدون Azure Files
توفر خدمة Azure Files نظام ملفات مشترك يدعم سيناريوهات واسعة النطاق. عند تشغيل تطبيق الوظائف في خطة Elastic Premium أو على Windows في خطة استهلاك، يتم إنشاء مشاركة ملفات Azure بشكل افتراضي في حساب التخزين الخاص بك. تستخدم هذه المشاركة من قبل Functions لتمكين ميزات معينة، مثل بث السجل. كما يتم استخدامه كموقع نشر حزمة مشتركة، ما يضمن تناسق التعليمات البرمجية للدالة المنشورة عبر جميع المثيلات.
بشكل افتراضي، تستخدم تطبيقات الوظائف المستضافة في خطط Premium وConsumption التوزيع المضغوط، مع حزم التوزيع المخزنة في مشاركة ملف Azure هذه. هذا القسم ذو صلة فقط بخطط الاستضافة هذه.
يتطلب استخدام Azure Files استخدام سلسلة الاتصال، والذي يتم تخزينه في إعدادات التطبيق ك WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. لا تدعم ملفات Azure حاليا الاتصالات المستندة إلى الهوية. إذا كان السيناريو الخاص بك يتطلب منك عدم تخزين أي أسرار في إعدادات التطبيق، يجب إزالة تبعية تطبيقك على ملفات Azure. يمكنك تجنب هذا الاعتماد عن طريق إنشاء تطبيقك بدون اعتماد Azure Files الافتراضي.
Note
يجب عليك أيضا التفكير في تشغيل تطبيق الوظائف في خطة Flex Consumption، والتي توفر تحكما أكبر في حزمة التوزيع، بما في ذلك القدرة على استخدام اتصالات الهوية المدارة. لمزيد من المعلومات، راجع تكوين إعدادات النشر.
لتشغيل تطبيقك دون مشاركة ملف Azure، يجب أن تفي بالمتطلبات التالية:
- يجب نشر الحزمة الخاصة بك إلى حاوية تخزين Azure Blob بعيدة ثم تعيين عنوان URL الذي يوفر الوصول إلى تلك الحزمة
WEBSITE_RUN_FROM_PACKAGEكإعداد التطبيق. يتيح لك هذا الأسلوب تخزين محتوى التطبيق في تخزين Blob بدلا من Azure Files، والذي يدعم الهويات المدارة.
يجب تحديث حزمة النشر يدويا والحفاظ على عنوان URL لحزمة النشر، والذي من المحتمل أن يحتوي على توقيع وصول مشترك (SAS).
يجب عليك أيضا ملاحظة الاعتبارات التالية:
- لا يمكن للتطبيق استخدام الإصدار 1.x من وقت تشغيل خدمة Functions.
- لا يمكن للتطبيق الاعتماد على نظام ملفات مشترك قابل للكتابة.
- تحرير المدخل غير مدعوم.
- سجل تجارب الدفق في العملاء مثل مدخل Azure الافتراضي لسجلات نظام الملفات. يجب عليك بدلًا من ذلك الاعتماد على سجلات Application Insights.
إذا كانت المتطلبات السابقة تناسب السيناريو الخاص بك، يمكنك المتابعة لإنشاء تطبيق دالة دون Azure Files. أنشئ تطبيقا بدون WEBSITE_CONTENTAZUREFILECONNECTIONSTRING إعدادات التطبيق و WEBSITE_CONTENTSHARE بإحدى الطرق التالية:
- قوالب Bicep/ARM: قم بإزالة إعدادي التطبيق من قالب ARM أو ملف Bicep ثم انشر التطبيق باستخدام القالب المعدل.
- مدخل Microsoft Azure: قم بإلغاء تحديد إضافة اتصال Azure Files في علامة التبويب Storage عند إنشاء التطبيق في مدخل Microsoft Azure.
يتم استخدام Azure Files لتمكين التوسع الديناميكي للوظائف. قد يكون التحجيم محدودا عند تشغيل تطبيقك دون ملفات Azure في خطة Elastic Premium وخطط الاستهلاك التي تعمل على Windows.
إدخال مشاركات الملفات
هذه الوظيفة الحالية متاحة فقط عند التشغيل على Linux.
يمكنك إدخال مشاركات Azure Files الموجودة إلى تطبيقات وظائف Linux. من خلال إدخال مشاركة إلى تطبيق وظائف Linux، يمكنك الاستفادة من نماذج التعلم الآلي الحالية أو البيانات الأخرى في وظائفك.
Important
بعد 30 سبتمبر 2028، يتم إيقاف خيار استضافة تطبيق الوظائف الخاص بك على Linux في خطة الاستهلاك. لتجنب الاضطرابات، قم بترحيل تطبيقات خطة الاستهلاك الحالية التي تعمل على Linux إلى خطة Flex Consumption قبل ذلك التاريخ. لا تتأثر التطبيقات التي تعمل على Windows في خطة الاستهلاك بهذا التغيير. لمزيد من المعلومات، راجع إشعار إيقاف خطة استهلاك Linux.
يمكنك استخدام الأمر التالي لإدخال مشاركة موجودة إلى تطبيق دوال Linux.
az webapp config تخزين إضافة حساب
في هذا الأمر، share-name هو اسم مشاركة ملفات Azure الموجودة.
custom-id يمكن أن تكون أي سلسلة تحدد المشاركة بشكل فريد عند تحميلها على تطبيق الوظائف. أيضًا، mount-path هو المسار الذي يتم من خلاله الوصول إلى المشاركة في تطبيق الوظائف الخاص بك.
mount-path يجب أن يكون بالتنسيق /dir-name، ولا يمكن أن يبدأ بـ /home.
للحصول على مثال كامل، راجع إنشاء تطبيق دالة Python وإدخال مشاركة ملفات Azure.
حاليًا، يتم دعم storage-type لـ AzureFiles فقط. يمكنك إدخال خمس مشاركات فقط إلى تطبيق وظائف معين. يمكن أن يؤدي تحميل مشاركة ملف إلى زيادة وقت البدء البارد بمقدار 200-300 مللي ثانية على الأقل، أو أكثر عندما يكون حساب التخزين في منطقة مختلفة.
تتوفر المشاركة المُدخلة في التعليمة البرمجية للوظيفة الخاص بك في mount-path المحدد. على سبيل المثال، عندما mount-path يكون/path/to/mount، يمكنك الوصول إلى الدليل الهدف بواسطة واجهات برمجة التطبيقات لنظام الملفات، كما في مثال Python التالي:
import os
...
files_in_share = os.listdir("/path/to/mount")
مقالات لها صلة
تعرف على المزيد حول خيارات استضافة Azure Functions.