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

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

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

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

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

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

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

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

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

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

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

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

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

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

Install the دالات Azure Core Tools

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

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

قم بتنزيل وتشغيل مثبت Core Tools بناء على نسختك من Windows:

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

تلميح

لتثبيت Core Tools على نظام Windows الفرعي لـ Linux‬ (WSL)، اتبع التعليمات في تبويب لينكس.

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

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

Important

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

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

func init MyProjFolder --worker-runtime dotnet-isolated 

افتراضيا، ينشئ هذا الأمر مشروعا يعمل أثناء العملية مع مضيف الوظائف على النسخة الحالية Long-Term Support (LTS) من .NET Core. يمكنك استخدام خيار --target-framework لاستهداف نسخة مدعومة محددة من .NET، بما في ذلك إطار عمل .NET. لمزيد من المعلومات، راجع 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 يستخدم النسخة المطلوبة programming model.

عند التشغيل 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 المرجع.

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

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

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

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

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

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

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

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

يستخدم هذا المثال ASP.NET Core التكامل. إذا لم تكن تستخدم ASP.NET Core التكامل، عليك تغيير HttpRequest إلى HttpRequestData وIActionResult إلى HttpResponseData.

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

@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) {

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

const { app, output } = require('@azure/functions');

const sendToQueue = output.storageQueue({
  queueName: 'outqueue',
  connection: 'AzureWebJobsStorage',
});

app.http('HttpExample', {
  methods: ['GET', 'POST'],
  authLevel: 'anonymous',
  extraOutputs: [sendToQueue],
  handler: async (request, context) => {
    try {
      context.log(`Http function processed request for url "${request.url}"`);

      const name = request.query.get('name') || (await request.text());
      context.log(`Name: ${name}`);

      if (name) {
        const msg = `Name passed to the function ${name}`;
        context.extraOutputs.set(sendToQueue, [msg]);
        return { body: msg };
      } else {
        context.log('Missing required data');
        return { status: 404, body: 'Missing required data' };
      }
    } catch (error) {
      context.log(`Error: ${error}`);
      return { status: 500, body: 'Internal Server Error' };
    }
  },
});

تعتمد الطريقة التي تحدد بها ربط الإخراج على إصدار نموذج 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 الخاص بك. لمزيد من المعلومات، بما في ذلك الارتباطات إلى مثال التعليمات البرمجية للربط التي يمكنك الرجوع إليها، راجع إضافة روابط إلى دالة.

import {
  app,
  output,
  HttpRequest,
  HttpResponseInit,
  InvocationContext,
  StorageQueueOutput,
} from '@azure/functions';

const sendToQueue: StorageQueueOutput = output.storageQueue({
  queueName: 'outqueue',
  connection: 'AzureWebJobsStorage',
});

export async function HttpExample(
  request: HttpRequest,
  context: InvocationContext,
): Promise<HttpResponseInit> {
  try {
    context.log(`Http function processed request for url "${request.url}"`);

    const name = request.query.get('name') || (await request.text());
    context.log(`Name: ${name}`);

    if (name) {
      const msg = `Name passed to the function ${name}`;
      context.extraOutputs.set(sendToQueue, [msg]);
      return { body: msg };
    } else {
      context.log('Missing required data');
      return { status: 404, body: 'Missing required data' };
    }
  } catch (error) {
    context.log(`Error: ${error}`);
    return { status: 500, body: 'Internal Server Error' };
  }
}

app.http('HttpExample', {
  methods: ['GET', 'POST'],
  authLevel: 'anonymous',
  handler: HttpExample,
});

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

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

  • بالنسبة للغات التي تعرف الدوال باستخدام ملف التكوين function.json، تعليمة Visual Studio برمجية يبسط عملية إضافة الروابط إلى تعريف الدوال الموجود. لمزيد من المعلومات، راجع Connect الدوال إلى خدمات Azure باستخدام bindings.
  • عند إضافة روابط تتصل بخدمة، يجب عليك أيضا إضافة إعداد تطبيق يشير إلى سلسلة الاتصال أو هوية مدارة إلى ملف 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 محليا (Queue 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)، يمكنك الآن تشغيل وظائف فردية لتشغيل التعليمات البرمجية للدالة وتصحيحها. تعتمد الطريقة التي تنفذ بها دالة فردية على نوع المشغل الخاص بها.

Note

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

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

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

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

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

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

هذا المثال هو نفس الوظيفة التي تم استدعاؤها من طلب POST يمرر name في جسم الطلب، كما هو موضح لكل من 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 معتمد من جانب المشغل.

Publish to Azure

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

نوع التوزيع Command Description
ملفات Project func azure functionapp publish ينشر ملفات مشروع الدالة مباشرة إلى تطبيق الوظائف الخاص بك باستخدام النشر المضغوط.
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، راجع Azure CLI Samples. يمكنك أيضا إنشاء هذه الموارد في بوابة Azure. تحصل على خطأ عند محاولة النشر إلى <FunctionAppName> غير موجود في اشتراكك.

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

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

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

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

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

نشر الحاويات

تتيح لك Core Tools نشر تطبيق الوظائف conwareized app في بيئات 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.

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

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

العناصر في مجموعة Values في ملف local.settings.json الخاص بمشروعك تهدف إلى عكس العناصر في إعدادات application settings في تطبيق الوظيفة الخاص بك في 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 الخاصة بك.

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

من جذر المشروع، استخدم الأمر التالي لتحميل جميع إعدادات التطبيق من تطبيق 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) حزم الملحقات.

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

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

إصدارات Core Tools

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

بدءا من الإصدار 4.0.6517 من أدوات النواة، يجب على مشاريع النموذج أثناء العملية الرجوع إلى الإصدار 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.

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