نقل تطبيق الوظائف إلى منطقة Azure أخرى

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

هناك أسباب مختلفة وراء رغبتك في نقل موارد Azure الحالية من منطقة إلى أخرى. قد ترغب في:

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

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

يمكنك نقل هذه الموارد نفسها إلى مجموعة موارد أخرى أو اشتراك آخر، طالما أنها تظل في نفس المنطقة. لمزيد من المعلومات، راجع نقل موارد App Service إلى مجموعة موارد جديدة أو اشتراك جديد.

المتطلبات الأساسية

• تأكد من أن المنطقة المستهدفة تدعم Azure Functions وأي خدمة ذات صلة تريد نقل مواردها.
• تأكد من أن لديك امتيازات لإنشاء الموارد المطلوبة في المنطقة الجديدة.

تجهيز

تحديد جميع موارد تطبيق الوظائف المستخدمة في منطقة المصدر، والتي من المحتمل أن تتضمن:

• تطبيق الوظيفة
• خطة الاستضافة
• فتحات التوزيع
• المجالات المخصصة المشتراة في Azure
• إعدادات وشهادات TLS/SSL
• خيارات الشبكات المهيأة
• الهويات المُدارة
• إعدادات التطبيق المكونة
• تكوينات القياس

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

اسم تطبيق الوظائف

يجب أن تكون أسماء تطبيقات الوظائف فريدة عالميا عبر جميع تطبيقات Azure. وهذا يعني أن تطبيق الوظائف الجديد لا يمكن أن يكون له نفس الاسم وعنوان URL مثل الاسم الأصلي. هذا صحيح حتى عند استخدام DNS مخصص، لأن الأساسي <APP_NAME>.azurewebsites.net يجب أن يظل فريدا. قد تحتاج إلى تحديث أي عملاء يتصلون بنقاط نهاية HTTP على تطبيق الوظائف. يحتاج هؤلاء العملاء إلى استخدام عنوان URL الجديد عند تقديم الطلبات.

كود المصدر

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

حساب التخزين الافتراضي

يتطلب مضيف الوظائف حساب تخزين Azure. لمزيد من المعلومات، راجع متطلبات حساب التخزين. للحصول على أفضل أداء، يجب أن يستخدم تطبيق الوظائف حساب تخزين في نفس المنطقة. عند إنشاء تطبيق جديد باستخدام حساب تخزين جديد في منطقتك الجديدة، يحصل تطبيقك على مجموعة جديدة من مفاتيح الوصول إلى الوظائف ويتم إعادة تعيين حالة أي مشغلات (مثل مشغلات المؤقت).

التخزين المحلي المستمر

تهدف عمليات تنفيذ الوظائف إلى أن تكون عديمة الحالة. ومع ذلك، لا نمنعك من كتابة البيانات إلى نظام الملفات المحلي. من الممكن تخزين البيانات التي تم إنشاؤها واستخدامها بواسطة التطبيق الخاص بك على محرك الأقراص %HOME%\site الظاهري، ولكن لا ينبغي أن تكون هذه البيانات متعلقة بالحالة. إذا كان السيناريو الخاص بك يتطلب منك الحفاظ على الحالة بين عمليات تنفيذ الوظائف، ففكر بدلا من ذلك في استخدام Durable Functions.

إذا استمر تطبيقك في البيانات إلى مسار التخزين المشترك للتطبيق، فتأكد من تخطيط كيفية إدارة هذه الحالة أثناء نقل المورد. ضع في اعتبارك أنه بالنسبة لتطبيقات خطة مخصصة (خدمة التطبيقات)، فإن المشاركة جزء من الموقع. بالنسبة لخطط الاستهلاك وPremium، تكون المشاركة، بشكل افتراضي، مشاركة Azure Files في حساب التخزين الافتراضي. قد تستخدم التطبيقات التي تعمل على Linux مشاركة مثبتة بشكل صريح للتخزين المستمر.

الخدمات المتصلة

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

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

التكوين

• يمكنك التقاط لقطة لإعدادات التطبيق الموجودة سلسلة الاتصال من مدخل Microsoft Azure. قم بتوسيع Settings>Environment variables، وحدد Advanced edit ضمن App settings أو Connections strings واحفظ إخراج JSON الذي يحتوي على الإعدادات أو الاتصالات الموجودة. تحتاج إلى إعادة إنشاء هذه الإعدادات في المنطقة الجديدة، ولكن من المحتمل أن تتغير القيم نفسها نتيجة لتغييرات المنطقة اللاحقة في الخدمات المتصلة.

• لا يمكن تصدير مراجع Key Vault الموجودة عبر حدود Azure الجغرافية. يجب إعادة إنشاء أي مراجع مطلوبة في المنطقة الجديدة.

• قد تتم إدارة تكوين التطبيق الخاص بك بواسطة Azure App Configuration أو من تبعية قاعدة بيانات مركزية أخرى (انتقال البيانات من الخادم). راجع أي متجر App Configuration أو متاجر مشابهة للبيئة والإعدادات الخاصة بالمنطقة التي قد تتطلب تعديلات.

إضافة مجالات مخصصة

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

الشبكات الظاهرية

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

الهويات

• تحتاج إلى إعادة إنشاء أي هويات مدارة معينة من قبل النظام إلى جانب تطبيقك في المنطقة المستهدفة الجديدة. عادة ما يتم تعيين تطبيق معرف Microsoft Entra الذي تم إنشاؤه تلقائيا، ويستخدمه EasyAuth، افتراضيا إلى اسم مورد التطبيق.

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

• امنح الهويات المدارة نفس الأذونات في الخدمات التي تم نقلها مثل الهويات الأصلية التي تحل محلها، بما في ذلك عضوية المجموعة.

الشهادات

يمكن نقل موارد شهادة App Service إلى مجموعة موارد جديدة أو اشتراك جديد ولكن ليس عبر المناطق. يمكن أيضا استيراد الشهادات التي يمكن تصديرها إلى التطبيق أو إلى Key Vault في المنطقة الجديدة. عملية التصدير والاستيراد هذه تعادل الانتقال بين المناطق.

هناك أنواع مختلفة من الشهادات التي يجب أخذها في الاعتبار أثناء التخطيط لنقل الخدمة:

مفاتيح الاختصار

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

وقت التعطل

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

Durable Functions

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

نقل

تتطلب إعادة إنشاء تطبيق الوظائف في منطقة جديدة إعادة إنشاء البنية الأساسية ل Azure أولا لخطة App Service ومثيل تطبيق الوظائف والموارد ذات الصلة، مثل الشبكات الظاهرية والهويات والفتحات. يجب عليك أيضا إعادة الاتصال أو إعادة إنشاء موارد Azure المطلوبة من قبل التطبيق في المنطقة الجديدة. قد تتضمن هذه الموارد حساب Azure Storage الافتراضي ومثيل Application Insights.

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

إعادة إنشاء البنية الأساسية ل Azure

هناك عدة طرق لإنشاء تطبيق دالة والموارد ذات الصلة في Azure في المنطقة المستهدفة:

• قوالب التوزيع: إذا قمت في الأصل بنشر تطبيق الوظائف باستخدام ملفات البنية الأساسية كتعليمية (IaC) (Bicep أو قوالب ARM أو Terraform)، يمكنك تحديث عمليات النشر السابقة هذه لاستهداف المنطقة الجديدة واستخدامها لإعادة إنشاء الموارد في المنطقة الجديدة. إذا لم تعد لديك ملفات التوزيع هذه، يمكنك دائما تنزيل قالب ARM لمجموعة الموارد الموجودة لديك من مدخل Microsoft Azure.
• البرامج النصية ل Azure CLI/PowerShell: إذا قمت في الأصل بنشر تطبيق الوظائف باستخدام البرامج النصية Azure CLI أو Azure PowerShell، يمكنك تحديث هذه البرامج النصية لاستهداف المنطقة الجديدة وتشغيلها مرة أخرى بدلا من ذلك. إذا لم تعد لديك هذه البرامج النصية، فيمكنك أيضا تنزيل قالب ARM لمجموعة الموارد الموجودة لديك من مدخل Microsoft Azure.
• مدخل Microsoft Azure: إذا قمت بإنشاء تطبيق الوظائف في المدخل في الأصل أو لم تشعر بالراحة باستخدام البرامج النصية أو ملفات IaC، يمكنك فقط إعادة إنشاء كل شيء في المدخل. تأكد من استخدام نفس خطة الاستضافة ووقت تشغيل اللغة وإصدار اللغة مثل تطبيقك الأصلي.

مراجعة الموارد المكونة

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

إعادة نشر التعليمات البرمجية المصدر

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

يمكنك أيضا استخدام أي أسلوب نشر آخر تدعمه Functions. تتطلب معظم عمليات النشر المستندة إلى الأدوات تمكين المصادقة الأساسية على scm نقطة النهاية، وهو ما لا ينصح به لتطبيقات الإنتاج.

اعتبارات النقل

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

تنظيف

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

الموارد ذات الصلة

راجع Azure Architecture Center للحصول على أمثلة لتطبيقات الوظائف التي تعمل في مناطق متعددة كجزء من بنيات حلول أكثر تقدما وتكرارا جغرافيا.