مشاركة عبر

تطوير Azure Functions محليا باستخدام Core Tools

  • مقالة

تتيح لك Azure Functions Core Tools تطوير وظائفك واختبارها على الكمبيوتر المحلي. عندما تكون مستعدا، يمكنك أيضا استخدام Core Tools لنشر مشروع التعليمات البرمجية إلى Azure والعمل مع إعدادات التطبيق.

أنت تعرض إصدار C# من هذه المقالة. تأكد من تحديد لغة برمجة الوظائف المفضلة لديك في أعلى المقالة.

إذا كنت تريد البدء على الفور، فأكمل مقالة التشغيل السريع ل Core Tools.

أنت تعرض إصدار Java من هذه المقالة. تأكد من تحديد لغة برمجة الوظائف المفضلة لديك في أعلى المقالة.

إذا كنت تريد البدء على الفور، فأكمل مقالة التشغيل السريع ل Core Tools.

أنت تعرض إصدار JavaScript من هذه المقالة. تأكد من تحديد لغة برمجة الوظائف المفضلة لديك في أعلى المقالة.

إذا كنت تريد البدء على الفور، فأكمل مقالة التشغيل السريع ل Core Tools.

أنت تعرض إصدار PowerShell من هذه المقالة. تأكد من تحديد لغة برمجة الوظائف المفضلة لديك في أعلى المقالة.

إذا كنت تريد البدء على الفور، فأكمل مقالة التشغيل السريع ل Core Tools.

أنت تعرض إصدار Python من هذه المقالة. تأكد من تحديد لغة برمجة الوظائف المفضلة لديك في أعلى المقالة.

إذا كنت تريد البدء على الفور، فأكمل مقالة التشغيل السريع ل Core Tools.

أنت تعرض إصدار TypeScript من هذه المقالة. تأكد من تحديد لغة برمجة الوظائف المفضلة لديك في أعلى المقالة.

إذا كنت تريد البدء على الفور، فأكمل مقالة التشغيل السريع ل Core Tools.

تثبيت الأدوات الأساسية لوظائف Azure

تعتمد الطريقة الموصى بها لتثبيت Core Tools على نظام تشغيل كمبيوتر التطوير المحلي.

الخطوات التالية استخدام مثبت Windows (MSI) لتثبيت أدوات الأساسية v4.x. لمزيدٍ من المعلومات حول المثبتات الأخرى المستندة إلى الحزمة، راجع الملف الأساسي أدوات القراءة.

قم بتنزيل وتشغيل مثبت الأدوات الأساسية، استنادًا إلى إصدار Windows:

إذا كنت قد استخدمت مثبت Windows (MSI) مسبقا لتثبيت Core Tools على Windows، فيجب إلغاء تثبيت الإصدار القديم من إضافة إزالة البرامج قبل تثبيت أحدث إصدار.

للحصول على تعليمات حول المشكلات المتعلقة بالإصدار، راجع إصدارات Core Tools.

إنشاء مشروعك المحلي

هام

بالنسبة إلى Python، يجب تشغيل أوامر Core Tools في بيئة ظاهرية. لمزيد من المعلومات، راجع التشغيل السريع: إنشاء دالة Python في Azure من سطر الأوامر.

في نافذة المحطة الطرفية أو من موجه الأوامر، قم بتشغيل الأمر التالي لإنشاء مشروع في MyProjFolder المجلد:

func init MyProjFolder --worker-runtime dotnet-isolated

بشكل افتراضي، ينشئ هذا الأمر مشروعا يتم تشغيله قيد التنفيذ مع مضيف الوظائف على إصدار الدعم طويل الأجل (LTS) الحالي من .NET Core. يمكنك استخدام --target-framework الخيار لاستهداف إصدار معين مدعوم من .NET، بما في ذلك .NET Framework. لمزيد من المعلومات، راجع func init المرجع.

للمقارنة بين نموذجي عملية .NET، راجع مقالة مقارنة وضع العملية.

تستخدم Java نموذج Maven الأصلي لإنشاء المشروع المحلي، جنبا إلى جنب مع أول وظيفة تم تشغيلها بواسطة HTTP. بدلا من استخدام func init و func new، يجب عليك بدلا من ذلك اتباع الخطوات في التشغيل السريع سطر الأوامر.

func init MyProjFolder --worker-runtime javascript --model V4

ينشئ هذا الأمر مشروع JavaScript يستخدم إصدار نموذج البرمجة المطلوب.

func init MyProjFolder --worker-runtime typescript --model V4

ينشئ هذا الأمر مشروع TypeScript يستخدم إصدار نموذج البرمجة المطلوب.

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

ينشئ هذا الأمر مشروع Python يستخدم إصدار نموذج البرمجة المطلوب.

عند التشغيل func init بدون --worker-runtime الخيار، تتم مطالبتك باختيار لغة المشروع. لمعرفة المزيد حول الخيارات المتوفرة func init للأمر، راجع func init المرجع.

إنشاء وظيفة

لإضافة دالة إلى مشروعك، قم بتشغيل func new الأمر باستخدام --template خيار تحديد قالب المشغل. ينشئ المثال التالي مشغل HTTP باسم MyHttpTrigger:

func new --template "Http Trigger" --name MyHttpTrigger

ينشئ هذا المثال مشغل تخزين قائمة انتظار المسمى MyQueueTrigger:

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

تنطبق الاعتبارات التالية عند إضافة الدالات:

  • عند التشغيل func new بدون --template الخيار، تتم مطالبتك باختيار قالب.

  • func templates list استخدم الأمر لمشاهدة القائمة الكاملة للقوالب المتوفرة للغتك.

  • عند إضافة مشغل يتصل بخدمة، ستحتاج أيضا إلى إضافة إعداد تطبيق يشير إلى سلسلة الاتصال أو هوية مدارة إلى ملف local.settings.json. يؤدي استخدام إعدادات التطبيق بهذه الطريقة إلى منعك من تضمين بيانات الاعتماد في التعليمات البرمجية الخاصة بك. لمزيد من المعلومات، راجع العمل مع إعدادات التطبيق محليا.

  • تضيف Core Tools أيضا مرجعا إلى ملحق الربط المحدد لمشروع C# الخاص بك.

لمعرفة المزيد حول الخيارات المتوفرة func new للأمر، راجع func new المرجع.

إضافة ربط إلى الدالة

توفر الوظائف مجموعة من روابط الإدخال والإخراج الخاصة بالخدمة، ما يسهل اتصال وظيفتك بخدمات Azure الأخرى دون الحاجة إلى استخدام حزم SDK الخاصة بالعميل الخاصة بالخدمة. وللحصول على مزيد من المعلومات، انظر مفاهيم مشغلات وروابط خدمة وظائف Azure Functions.

لإضافة ربط إدخال أو إخراج إلى دالة موجودة، يجب تحديث تعريف الدالة يدويا.

يوضح المثال التالي تعريف الدالة بعد إضافة ربط إخراج Queue Storage إلى دالة HTTP المشغلة:

نظرا لأن الدالة التي تم تشغيلها من قبل HTTP تقوم أيضا بإرجاع استجابة HTTP، ترجع الدالة كائنا MultiResponse ، والذي يمثل كلا من إخراج HTTP وقوائم الانتظار.

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

هذا المثال هو تعريف MultiResponse العنصر الذي يتضمن ربط الإخراج:

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

عند تطبيق هذا المثال على مشروعك الخاص، قد تحتاج إلى التغيير HttpRequest إلى HttpRequestData وإلى IActionResult HttpResponseData، اعتمادا على ما إذا كنت تستخدم ASP.NET التكامل الأساسي أم لا.

يتم إرسال الرسائل إلى قائمة الانتظار عند اكتمال الدالة. تعتمد الطريقة التي تحدد بها ربط الإخراج على نموذج العملية. لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

مثال ربط لنموذج Node.js v4 غير متوفر بعد.

تعتمد الطريقة التي تحدد بها ربط الإخراج على إصدار نموذج Node.js الخاص بك. لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

تعتمد الطريقة التي تحدد بها ربط الإخراج على إصدار نموذج Python الخاص بك. لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

مثال ربط لنموذج Node.js v4 غير متوفر بعد.

تعتمد الطريقة التي تحدد بها ربط الإخراج على إصدار نموذج Node.js الخاص بك. لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

تنطبق الاعتبارات التالية عند إضافة روابط إلى دالة:

  • عند إضافة روابط تتصل بخدمة، يجب أيضا إضافة إعداد تطبيق يشير إلى هوية سلسلة الاتصال أو مدارة إلى ملف local.settings.json. لمزيد من المعلومات، راجع العمل مع إعدادات التطبيق محليا.
  • عند إضافة ربط معتمد، يجب تثبيت الملحق بالفعل عندما يستخدم تطبيقك مجموعة الملحقات. لمزيد من المعلومات، راجع حزم الملحقات.
  • عند إضافة ربط يتطلب ملحق ربط جديد، يجب أيضا إضافة مرجع إلى ملحق الربط المحدد هذا في مشروع C# الخاص بك.

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

بدء وقت تشغيل الوظائف

قبل أن تتمكن من تشغيل الدالات أو تصحيحها في مشروعك، تحتاج إلى بدء تشغيل مضيف الوظائف من الدليل الجذر لمشروعك. يعمل المضيف على تمكين مشغلات لكل الوظائف في المشروع. استخدم هذا الأمر لبدء وقت التشغيل المحلي:

mvn clean package 
mvn azure-functions:run

func start

func start

npm install
npm start

يجب تشغيل هذا الأمر في بيئة ظاهرية.

عند بدء تشغيل مضيف الوظائف، فإنه يقوم إخراج قائمة من الدالات في المشروع، بما في ذلك عناوين URL لأي دالات يتم تشغيلها من قبل HTTP، كما هو الحال في هذا المثال:

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

ضع في اعتبارك الاعتبارات التالية عند تشغيل وظائفك محليا:

  • بشكل افتراضي، لا يتم فرض التخويل محليا لنقاط نهاية HTTP. وهذا يعني أن تتم معالجة كل طلبات HTTP المحلية كـauthLevel = "anonymous". لمزيد من المعلومات، راجع مستوى التخويل. يمكنك استخدام --enableAuth الخيار لطلب التخويل عند التشغيل محليا. لمزيد من المعلومات، راجع func start

  • يمكنك استخدام محاكي Azurite المحلي عند تشغيل الوظائف التي تتطلب الوصول إلى خدمات Azure Storage (Queue Storage وBlob Storage وTable Storage) دون الحاجة إلى الاتصال بهذه الخدمات في Azure. عند استخدام المحاكاة المحلية، تأكد من بدء تشغيل Azurite قبل بدء تشغيل المضيف المحلي (func.exe). لمزيد من المعلومات، راجع محاكي التخزين المحلي.

  • يمكنك استخدام محاكي Azurite المحلي لتلبية متطلبات التخزين لعامل Python v2.

  • يمكنك تشغيل وظائف غير HTTP محليا دون الاتصال بخدمة مباشرة. لمزيد من المعلومات، راجع تشغيل دالة محلية.

  • عند تضمين معلومات اتصال Application Insights في ملف local.settings.json، تتم كتابة بيانات السجل المحلي إلى مثيل Application Insights المحدد. للحفاظ على بيانات تتبع الاستخدام المحلية منفصلة عن بيانات الإنتاج، ضع في اعتبارك استخدام مثيل Application Insights منفصل للتطوير والاختبار.

  • عند استخدام الإصدار 1.x من Core Tools، استخدم func host start بدلا من ذلك الأمر لبدء وقت التشغيل المحلي.

تشغيل دالة محلية

مع تشغيل مضيف الوظائف المحلي (func.exe)، يمكنك الآن تشغيل وظائف فردية لتشغيل التعليمات البرمجية للدالة وتصحيحها. تعتمد الطريقة التي تنفذ بها دالة فردية على نوع المشغل الخاص بها.

إشعار

تستخدم الأمثلة في هذا الموضوع أداة cURL لإرسال طلبات HTTP من المحطة الطرفية أو موجه الأوامر. يمكنك استخدام أداة من اختيارك لإرسال طلبات HTTP إلى الخادم المحلي. تتوافر أداة cURL بشكل افتراضي على الأنظمة المستندة إلى لينكس Windows 10 إنشاء 17063 وما بعده. في Windows القديمة، يجب عليك أولاً تنزيل وتثبيتأداة cURL.

يتم بدء تشغيل مشغلات HTTP عن طريق إرسال طلب HTTP إلى نقطة النهاية المحلية والمنفذ كما هو معروض في إخراج func.exe، والذي يحتوي على هذا التنسيق العام:

http://localhost:<PORT>/api/<FUNCTION_NAME>

في قالب URL هذا، <FUNCTION_NAME> هو اسم الدالة أو المسار وهو <PORT> المنفذ المحلي الذي يستمع إليه func.exe.

على سبيل المثال، يقوم أمر cURL هذا بتشغيل دالة MyHttpTrigger التشغيل السريع من طلب GET مع معلمة الاسم التي تم تمريرها في سلسلة الاستعلام:

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

هذا المثال هو نفس الدالة التي تم استدعاؤها من اسم تمرير طلب POST في نص الطلب، الموضح لكل من Bash shell وخط أوامر Windows:

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

curl --request POST http://localhost:7071/api/MyHttpTrigger --data "{'name':'Azure Rocks'}"

تنطبق الاعتبارات التالية عند استدعاء نقاط نهاية HTTP محليا:

  • يمكنك إجراء طلبات GET من مستعرض تمرير البيانات في سلسلة الاستعلام. بالنسبة لجميع أساليب HTTP الأخرى، يجب استخدام أداة اختبار HTTP التي تحافظ أيضا على أمان بياناتك. لمزيد من المعلومات، راجع أدوات اختبار HTTP.

  • تأكد من استخدام نفس اسم الخادم والمنفذ الذي يستمع إليه مضيف الوظائف. ترى نقطة نهاية مثل هذه في الإخراج الذي تم إنشاؤه عند بدء تشغيل مضيف الدالة. يمكنك استدعاء URL هذا باستخدام أي أسلوب HTTP معتمد من جانب المشغل.

نشر إلى Azure

تدعم أدوات Azure الأساسية للوظائف ثلاثة أنواع من النشر:

نوع التوزيع الأمر ‏‏الوصف
ملفات المشروع func azure functionapp publish نشر ملفات مشروع دالة مباشرة إلى تطبيق الوظائف باستخدام نشر zip.
Azure Container Apps func azurecontainerapps deploy نشر تطبيق دالة في حاوية إلى بيئة Container Apps موجودة.
مجموعة Kubernetes func kubernetes deploy توزيع تطبيق الوظائف Linux الخاص بك كحاوية Docker للعميل إلى نظام مجموعة Kubernetes.

يجب أن يكون لديك إما Azure CLI أو Azure PowerShell مثبتا محليا لتتمكن من النشر إلى Azure من Core Tools. بشكل افتراضي، تستخدم Core Tools هذه الأدوات للمصادقة باستخدام حساب Azure الخاص بك.

إذا لم يكن لديك هذه الأدوات مثبتة، فستحتاج بدلا من ذلك إلى الحصول على رمز وصول صالح لاستخدامه أثناء النشر. يمكنك تقديم رمز مميز للوصول باستخدام --access-token الخيار في أوامر النشر.

نشر ملفات المشروع

لنشر التعليمات البرمجية المحلية إلى تطبيق دالة في Azure، استخدم func azure functionapp publish الأمر ، كما في المثال التالي:

func azure functionapp publish <FunctionAppName>

ينشر هذا الأمر ملفات المشروع من الدليل الحالي إلى <FunctionAppName> كحزمة نشر .zip. إذا كان المشروع يتطلب التحويل البرمجي، يتم ذلك عن بعد أثناء النشر.

تستخدم Java Maven لنشر مشروعك المحلي إلى Azure بدلا من Core Tools. استخدم أمر Maven التالي لنشر مشروعك إلى Azure:

mvn azure-functions:deploy

عند تشغيل هذا الأمر، يتم إنشاء موارد Azure أثناء النشر الأولي استنادا إلى الإعدادات في ملف pom.xml. لمزيد من المعلومات، راجع نشر مشروع الدالة إلى Azure.

تنطبق الاعتبارات التالية على هذا النوع من النشر:

  • النشر يحل محل الملفات الموجودة في نشر تطبيق الوظائف عن بعد.

  • يجب أن تكون قد أنشأت بالفعل تطبيق وظائف في اشتراك Azure الخاص بك. تنشر Core Tools التعليمات البرمجية لمشروعك إلى مورد تطبيق الوظائف هذا. لمعرفة كيفية إنشاء تطبيق دالة من موجه الأوامر أو نافذة المحطة الطرفية باستخدام Azure CLI أو Azure PowerShell، راجع إنشاء تطبيق دالة للتنفيذ بلا خادم. يمكنك أيضا إنشاء هذه الموارد في مدخل Microsoft Azure. تحصل على خطأ عند محاولة النشر إلى <FunctionAppName> غير موجود في اشتراكك.

  • قد يحتوي مجلد مشروع على ملفات ودلائل خاصة باللغة لا ينبغي نشرها. يتم سرد العناصر المستبعدة في ملف .funcignore في المجلد المشروع الجذر.

  • بشكل افتراضي، يتم نشر مشروعك بحيث يتم تشغيله من حزمة التوزيع. لتعطيل وضع النشر الموصى به هذا، استخدم --nozip الخيار.

  • يتم تنفيذ بناء بعيد على المشروعات المُحولة برمجيًا. يمكن التحكم في ذلك باستخدام --no-build الخيار.

  • --publish-local-settings استخدم الخيار لإنشاء إعدادات التطبيق تلقائيا في تطبيق الوظائف استنادا إلى القيم الموجودة في ملف local.settings.json.

  • للنشر إلى فتحة مسماة معينة في تطبيق الوظائف، استخدم --slot الخيار .

نشر الحاويات

تتيح لك Core Tools نشر تطبيق الوظائف المعبأة في حاويات لكل من بيئات Azure Container Apps المدارة ومجموعات Kubernetes التي تديرها.

استخدم الأمر التالي func azurecontainerapps deploy لنشر صورة حاوية موجودة إلى بيئة Container Apps:

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

عند النشر إلى بيئة Azure Container Apps، تنطبق الاعتبارات التالية:

  • يجب أن يكون حساب البيئة والتخزين موجودين بالفعل. يتم استخدام حساب التخزين سلسلة الاتصال الذي توفره من قبل تطبيق الوظائف المنشور.

  • لا تحتاج إلى إنشاء مورد تطبيق وظائف منفصل عند النشر إلى Container Apps.

  • تعد سلسلة الاتصال التخزين وبيانات اعتماد الخدمة الأخرى أسرارا مهمة. تأكد من تخزين أي ملفات برامج نصية بأمان باستخدام func azurecontainerapps deploy ولا تخزنها في أي أنظمة تحكم بالمصادر يمكن الوصول إليها بشكل عام. يمكنك تشفير ملف local.settings.json لمزيد من الأمان.

لمزيد من المعلومات، راجع استضافة Azure Container Apps ل Azure Functions.

العمل مع إعدادات التطبيق محليا

عند التشغيل في تطبيق وظيفي في Azure، فإن الإعدادات التي تتطلبها وظائفك يتم تخزينها بأمان في إعدادات التطبيق. أثناء التطوير المحلي، تتم إضافة هذه الإعدادات بدلا من ذلك إلى Values المجموعة في ملف local.settings.json. يخزن ملف local.settings.json أيضاً الإعدادات المستخدمة بواسطة أدوات التطوير المحلية.

تهدف العناصر الموجودة Values في المجموعة في ملف local.settings.json الخاص بمشروعك إلى عكس العناصر في إعدادات تطبيق الدالة في Azure.

تنطبق الاعتبارات التالية عند العمل مع ملف الإعدادات المحلية:

  • نظرًا إلى احتمالية احتواء الملف local.settings.json على أسرار، مثل سلاسل الاتصال، يجب عدم تخزينها في مستودع بعيد. تساعدك Core Tools على تشفير ملف الإعدادات المحلي هذا لتحسين الأمان. لمزيد من المعلومات، راجع ملف الإعدادات المحلية. يمكنك أيضا تشفير ملف local.settings.json لمزيد من الأمان.

  • بشكل افتراضي، لا يتم ترحيل الإعدادات المحلية تلقائيا عند نشر المشروع إلى Azure. --publish-local-settings استخدم الخيار عند نشر ملفات المشروع للتأكد من إضافة هذه الإعدادات إلى تطبيق الوظائف في Azure. لا يتم نشر القيم الموجودة في مجموعة ConnectionStrings. يمكنك أيضا تحميل الإعدادات من ملف local.settings.json في أي وقت.

  • يمكنك تنزيل الإعدادات والكتابة فوقها في ملف local.settings.json مع إعدادات من تطبيق الوظائف في Azure. لمزيد من المعلومات، راجع تنزيل إعدادات التطبيق.

  • يمكن أيضًا قراءة قيم إعدادات تطبيق الدالة في التعليمات البرمجية كمتغيرات البيئة. لمزيد من المعلومات، راجع متغيرات البيئة.
  • يمكن أيضًا قراءة قيم إعدادات تطبيق الدالة في التعليمات البرمجية كمتغيرات البيئة. لمزيد من المعلومات، راجع متغيرات البيئة.
  • يمكن أيضًا قراءة قيم إعدادات تطبيق الدالة في التعليمات البرمجية كمتغيرات البيئة. لمزيد من المعلومات، راجع متغيرات البيئة.
  • يمكن أيضًا قراءة قيم إعدادات تطبيق الدالة في التعليمات البرمجية كمتغيرات البيئة. لمزيد من المعلومات، راجع متغيرات البيئة.
  • يمكن أيضًا قراءة قيم إعدادات تطبيق الدالة في التعليمات البرمجية كمتغيرات البيئة. لمزيد من المعلومات، راجع متغيرات البيئة.
  • عند عدم تعيين سلسلة الاتصال تخزين صالحة وعدم AzureWebJobsStorage استخدام محاكي تخزين محلي، يتم عرض خطأ. يمكنك استخدام Core Tools لتنزيل سلسلة الاتصال معين من أي من حسابات Azure Storage.

تنزيل إعدادات التطبيق

من جذر المشروع، استخدم الأمر التالي لتنزيل جميع إعدادات التطبيق من myfunctionapp12345 التطبيق في Azure:

func azure functionapp fetch-app-settings myfunctionapp12345

يقوم هذا الأمر بالكتابة فوق أي إعدادات موجودة في ملف local.settings.json مع قيم من Azure. عندما لا تكون موجودة بالفعل، تتم إضافة عناصر جديدة إلى المجموعة. لمزيد من المعلومات، راجع func azure functionapp fetch-app-settings الأمر .

تنزيل سلسلة الاتصال تخزين

تسهل Core Tools أيضا الحصول على سلسلة الاتصال أي حساب تخزين يمكنك الوصول إليه. من جذر المشروع، استخدم الأمر التالي لتنزيل سلسلة الاتصال من حساب تخزين يسمى mystorage12345.

func azure storage fetch-connection-string mystorage12345

يضيف هذا الأمر إعدادا يسمى mystorage12345_STORAGE إلى ملف local.settings.json، والذي يحتوي على سلسلة الاتصال mystorage12345 للحساب. لمزيد من المعلومات، راجع func azure storage fetch-connection-string الأمر .

لتحسين الأمان أثناء التطوير، ضع في اعتبارك تشفير ملف local.settings.json.

تحميل الإعدادات المحلية إلى Azure

عند نشر ملفات المشروع إلى Azure دون استخدام --publish-local-settings الخيار ، لا يتم تعيين الإعدادات في ملف local.settings.json في تطبيق الوظائف. يمكنك دائما إعادة تشغيل func azure functionapp publish مع --publish-settings-only خيار تحميل الإعدادات فقط دون إعادة نشر ملفات المشروع.

يقوم المثال التالي بتحميل الإعدادات فقط من Values المجموعة في ملف local.settings.json إلى تطبيق الوظائف في Azure المسمى myfunctionapp12345:

func azure functionapp publish myfunctionapp12345 --publish-settings-only

تشفير ملف الإعدادات المحلية

لتحسين أمان سلسلة الاتصال والبيانات القيمة الأخرى في إعداداتك المحلية، تتيح لك Core Tools تشفير ملف local.settings.json. عند تشفير هذا الملف، يقوم وقت التشغيل تلقائيا بفك تشفير الإعدادات عند الحاجة بنفس الطريقة التي يقوم بها مع إعداد التطبيق في Azure. يمكنك أيضا فك تشفير ملف مشفر محليا للعمل مع الإعدادات.

استخدم الأمر التالي لتشفير ملف الإعدادات المحلية للمشروع:

func settings encrypt

استخدم الأمر التالي لفك تشفير إعداد محلي مشفر، بحيث يمكنك العمل معه:

func settings decrypt

عند تشفير ملف الإعدادات وفك تشفيره، يتم تحديث إعداد الملف IsEncrypted أيضا.

تكوين ملحقات الربط

يتم تنفيذ مشغلات الوظائف والروابط كحزم ملحق .NET (NuGet). لكي تتمكن من استخدام ملحق ربط معين، يجب تثبيت هذا الملحق في المشروع.

لا ينطبق هذا القسم على الإصدار 1.x من وقت تشغيل الوظائف. في الإصدار 1.x، تم تضمين الروابط المدعومة في ملحق المنتج الأساسي.

بالنسبة لمشاريع مكتبة فئة C#، أضف مراجع إلى حزم NuGet المحددة لملحقات الربط التي تتطلبها وظائفك. يجب أن يستخدم مشروع البرنامج النصي C# (.csx) حزم الملحقات.

توفر الوظائف حزم ملحقات لتسهيل العمل مع ملحقات الربط في مشروعك. تقوم حزم الملحقات، التي تم إصدارها وتحديدها في ملف host.json، بتثبيت مجموعة كاملة من حزم ملحقات الربط المتوافقة لتطبيقك. يجب أن يكون لدى host.json بالفعل حزم ملحق ممكنة. إذا كنت بحاجة لسبب ما إلى إضافة مجموعة الملحقات أو تحديثها في ملف host.json، فشاهد حزم الملحقات.

إذا كان يجب عليك استخدام ملحق ربط أو إصدار ملحق غير موجود في مجموعة مدعومة، فستحتاج إلى تثبيت الملحقات يدويا. للحصول على مثل هذه السيناريوهات النادرة func extensions install ، راجع الأمر .

إصدارات Core Tools

ترتبط الإصدارات الرئيسية من Azure Functions Core Tools بإصدارات رئيسية محددة من وقت تشغيل Azure Functions. على سبيل المثال، الإصدار 4.x من Core Tools يدعم الإصدار 4.x من وقت تشغيل الوظائف. هذا الإصدار هو الإصدار الرئيسي الموصى به من كل من وقت تشغيل الوظائف والأدوات الأساسية. يمكنك تحديد أحدث إصدار من Core Tools في مستودع Azure Functions Core Tools.

بدءا من الإصدار 4.0.6517 من Core Tools، يجب أن تشير مشاريع النموذج قيد المعالجة إلى الإصدار 4.5.0 أو أحدث من Microsoft.NET.Sdk.Functions. إذا تم استخدام إصدار سابق، func start فسيخطأ الأمر.

قم بتشغيل الأمر التالي لتحديد إصدار تثبيت Core Tools الحالي:

func --version

ما لم تتم الإشارة إلى خلاف ذلك، فإن الأمثلة الواردة في هذه المقالة هي للإصدار 4.x.

تنطبق الاعتبارات التالية على عمليات تثبيت Core Tools:

  • يمكنك تثبيت إصدار واحد فقط من الأدوات الأساسية على كمبيوتر معين.

  • عند الترقية إلى أحدث إصدار من Core Tools، يجب استخدام نفس الأسلوب الذي استخدمته للتثبيت الأصلي لإجراء الترقية. على سبيل المثال، إذا استخدمت MSI على Windows، فقم بإلغاء تثبيت MSI الحالي وتثبيت أحدث واحد. أو إذا كنت تستخدم npm، أعد تشغيل npm install command.

  • تم استخدام الإصدار 2.x و3.x من Core Tools مع الإصدارين 2.x و3.x من وقت تشغيل الوظائف، والتي وصلت إلى نهاية الدعم. لمزيد من المعلومات، راجع نظرة عامة على إصدارات وقت تشغيل Azure Functions.

  • الإصدار 1.x من Core Tools مطلوب عند استخدام الإصدار 1.x من وقت تشغيل الوظائف، والذي لا يزال مدعوما. يمكن تشغيل هذا الإصدار من Core Tools محليا فقط على أجهزة كمبيوتر Windows. إذا كنت تعمل حاليا على الإصدار 1.x، فيجب أن تفكر في ترحيل تطبيقك إلى الإصدار 4.x اليوم.

الخطوات التالية

تعرف على كيفية تطوير وظائف Azure واختبارها ونشرها باستخدام أدوات Azure Functions الأساسية. تعد Azure Functions Core Tools مفتوحة المصدر ومستضافة على GitHub. لتقديم طلب خطأ أو ميزة، افتح مشكلة GitHub.