النشر المستمر إلى Azure App Service

إشعار

بدءا من 1 يونيو 2024، سيكون لجميع تطبيقات App Service التي تم إنشاؤها حديثا خيار إنشاء اسم مضيف افتراضي فريد باستخدام اصطلاح <app-name>-<random-hash>.<region>.azurewebsites.netالتسمية . ستظل أسماء التطبيقات الحالية دون تغيير.

مثال: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

لمزيد من التفاصيل، راجع اسم المضيف الافتراضي الفريد لمورد App Service.

تتيح Azure App Service التوزيع المستمر من مستودعات GitHub وBitbucket وAzure Repos عن طريق سحب آخر التحديثات.

قم بإعداد المستودع الخاص بك

للحصول على تصميمات مؤتمتة من خادم إنشاء Azure App Service، تأكد من أن جذر المستودع الخاص بك يحتوي على الملفات الصحيحة في مشروعك.

وقت التشغيل	ملفات الدليل الجذر
ASP.NET (Windows فحسب)	*.slnو *.csproj, أو default.aspx
ASP.NET Core	*.sln أو *.csproj
PHP	index.php
Ruby (Linux فحسب)	Gemfile
Node.js	server.jsأو app.jsأو package.json باستخدام برنامج نصي للبدء
Python	*.pyو requirements.txt, أو runtime.txt
HTML	default.htmأو أو default.htmlأو index.htmindex.htmldefault.aspiisstart.htm
WebJobs	<job_name>/run.<extension> ضمن App_Data/jobs/continuous ل WebJobs المستمر، أو App_Data/jobs/triggered ل WebJobs المشغلة. لمزيدٍ من المعلومات، راجع وثائق Kudu WebJobs.
الوظائف	راجع التوزيع المستمر لوظائف Azure.

لتخصيص التوزيع، قم بتضمين ملف .deployment في جذر المستودع. لمزيدٍ من المعلومات، راجع تخصيص عمليات التوزيع والبرنامج النصي للتوزيع المخصص.

إشعار

إذا كنت تستخدم Visual Studio، فدع Visual Studio ينشئ مستودعًا لك. سيكون مشروعك جاهزًا على الفور للتوزيع عبر Git.

تكوين مصدر التوزيع

1. في مدخل Azure، انتقل إلى صفحة الإدارة لتطبيق App Service.

2. في الجزء الأيسر، حدد مركز التوزيع. ثم حدد Settings.

3. في مربع المصدر، حدد أحد خيارات CI/CD:

   

حدد علامة التبويب التي تتوافق مع موفر الإصدار الخاص بك للمتابعة.

GitHub

4. GitHub Actions هو المزود الافتراضي للإنشاء. لتغيير الموفر، حدد Change provider>App Service Build Service>OK.

5. إذا كنت تقوم بالتوزيع من GitHub للمرة الأولى، فحدد تخويل واتبع مطالبات التفويض. إذا كنت تريد التوزيع من مستودع مستخدم مختلف، فحدد تغيير الحساب.

6. بعد تخويل حساب Azure الخاص بك باستخدام GitHub، حدد المؤسسة والمستودع والفرع الذي تريده.

   إذا لم تتمكن من العثور على مؤسسة أو مستودع، فقد تحتاج إلى تمكين المزيد من الأذونات على GitHub. لمزيدٍ من المعلومات، راجع إدارة الوصول إلى مستودعات مؤسستك.

7. ضمن نوع المصادقة، حدد الهوية المعينة من قبل المستخدم للحصول على أمان أفضل. لمزيد من المعلومات، راجع الأسئلة المتداولة.

   إشعار

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

8. (اختياري) لمشاهدة الملف قبل حفظ التغييرات، حدد معاينة الملف. تحدد App Service قالب سير عمل استنادا إلى إعداد مكدس اللغة لتطبيقك وتلتزم به في مستودع GitHub المحدد.

9. حدد حفظ.

   يتم الآن توزيع الالتزامات الجديدة في المستودع والفرع المحددين بشكل مستمر في تطبيق App Service الخاص بك. يمكنك تتبع الالتزامات وعمليات التوزيع في علامة تبويب السجلات.

Bitbucket

يستخدم تكامل Bitbucket App Service Build Services لأتمتة البناء.

4. إذا كنت تقوم بالتوزيع من Bitbucket لأول مرة، فحدد تخويل واتبع مطالبات التفويض. إذا كنت تريد التوزيع من مستودع مستخدم مختلف، فحدد تغيير الحساب.

5. بالنسبة إلى Bitbucket، حدد فريق Bitbucket والمستودع والفرع الذي تريد توزيعه باستمرار.

6. حدد حفظ.

   يتم الآن توزيع الالتزامات الجديدة في المستودع والفرع المحددين بشكل مستمر في تطبيق App Service الخاص بك. يمكنك تتبع الالتزامات وعمليات التوزيع في علامة تبويب السجلات.

Git المحلي

راجع توزيع Git المحلي في Azure App Service.

Azure Repos

4. App Service Build Service هي موفر البناء الافتراضي.

   إشعار

   لاستخدام Azure Pipelines كموفر بناء لتطبيق App Service، قم بتكوينه مباشرة من Azure Pipelines. تجنب تكوينه في App Service. يوجهك خيار Azure Pipelines في الاتجاه الصحيح فحسب.

5. حدد مؤسسة Azure DevOps والمشروع والمستودع والفرع الذي تريد توزيعه باستمرار.

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

مستودعات أخرى

بالنسبة لتطبيقات Windows، يمكنك تكوين التوزيع المستمر يدويًا من مستودع سحابة Git أو Mercurial لا يدعمه المدخل بشكل مباشر، مثل GitLab. يمكنك إجراء ذلك عن طريق تحديد External Git في القائمة المنسدلة للمصدر. لمزيدٍ من المعلومات، راجع إعداد التوزيع المستمر باستخدام الخطوات اليدوية.

تعطيل التوزيع المستمر

1. في مدخل Azure، انتقل إلى صفحة الإدارة لتطبيق App Service.

2. في الجزء الأيسر، حدد مركز التوزيع. ثم حدد الإعدادات> قطع الاتصال:

   

3. بشكل افتراضي، يتم الاحتفاظ بملف سير عمل GitHub Actions في المستودع الخاص بك، ولكنه يستمر في تشغيل النشر إلى تطبيقك. لحذف الملف من المستودع الخاص بك، حدد حذف ملف سير العمل.

4. حدد موافق.

ما المقصود بموفري البنية؟

استنادا إلى مصدر النشر في مركز النشر، قد ترى بعض الخيارات لتحديدها لموفري البنية. يساعدك موفرو الإنشاء على إنشاء حل CI/CD باستخدام Azure App Service من خلال أتمتة الإنشاء والاختبار والنشر.

لا تقتصر على خيارات موفر البناء الموجودة في مركز النشر، ولكن تتيح لك App Service إعدادها بسرعة وتوفر بعض تجربة تسجيل النشر المتكاملة.

GitHub Actions

يتوفر موفر إنشاء GitHub Actions فقط لنشر GitHub. عند تكوينه من مركز النشر للتطبيق، فإنه يكمل هذه الإجراءات لإعداد CI/CD:

• يودع ملف سير عمل GitHub Actions في مستودع GitHub للتعامل مع إنشاء المهام وتوزيعها بـ App Service.
• للمصادقة الأساسية، يضيف ملف تعريف النشر لتطبيقك كسر GitHub. يستخدم ملف سير العمل هذا السر للمصادقة مع App Service.
• للحصول على الهوية المعينة من قبل المستخدم، راجع ماذا يفعل خيار الهوية المعينة من قبل المستخدم لإجراءات GitHub؟
• يلتقط المعلومات من سجلات تشغيل سير العمل ويعرضها في علامة التبويب Logs في Deployment Center.

يمكنك تخصيص موفر إنشاء GitHub Actions بهذه الطرق:

• تخصيص ملف سيرِ العمل بعد إنشائه في مستودع GitHub الخاص بك. لمزيدٍ من المعلومات عن بناء جملة سير العمل، راجع بناء جملة سير العمل لـ GitHub Actions. تأكد من توزيع سير العمل في App Service فحسب باستخدام الإجراء azure/webapps-deploy.
• إذا كان الفرع المحدد محميًا، فلا يزال بإمكانك معاينة ملف سير العمل دون حفظ التكوين ثم إضافته يدويًا إلى المستودع الخاص بك. لا تمنحك هذه الطريقة تكامل السجل مع مدخل Azure.
• بدلا من استخدام المصادقة الأساسية أو الهوية المعينة من قبل المستخدم، يمكنك أيضا النشر باستخدام كيان خدمة في معرف Microsoft Entra. لا يمكن تكوين هذا في المدخل.

خدمة إنشاء خدمة التطبيقات

إشعار

تتطلب خدمة App Service Build مصادقة SCM الأساسية لتمكين خطاف الويب للعمل. لمزيد من المعلومات، راجع النشر بدون مصادقة أساسية.

App Service Build Service هي محرك التوزيع والبناء الأصلي لخدمة التطبيقات، والمعروفة باسم Kudu. عند تحديد هذا الخيار، تضيف App Service خطاف ويب إلى المستودع الذي أذنت به. يؤدي أي دفع للتعليمات البرمجية إلى المستودع إلى تشغيل خطاف الويب، وتسحب App Service التغييرات إلى مستودعها وتنفذ أي مهام توزيع. لمزيد من المعلومات، راجع النشر من GitHub (Kudu).

الموارد:

• التحقيق في المشكلات الشائعة مع التوزيع المستمر
• ⁩مشروع Kudu

مسارات Azure

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

لاستخدام Azure Pipelines كموفر بناء، لا تقم بتكوينه في App Service، ولكن انتقل إلى Azure DevOps مباشرة. في مركز النشر، يشير لك خيار Azure Pipelines فقط في الاتجاه الصحيح.

لمزيد من المعلومات، راجع النشر إلى App Service باستخدام Azure Pipelines.

ماذا يحدث لتطبيقي أثناء التوزيع؟

جميع أساليب التوزيع المعتمدة رسميًا تجري تغييرات على الملفات في المجلد /home/site/wwwroot من التطبيق الخاص بك. يتم استخدام هذه الملفات لتشغيل التطبيق الخاص بك. لذلك يمكن أن تفشل عملية التوزيع بسبب الملفات المؤمنة. قد يتصرف التطبيق أيضًا بشكل غير متوقع في أثناء التوزيع لأن الملفات لا تُحدث كلها في الوقت نفسه. هذا السلوك غير مرغوب فيه لتطبيق مواجه للعميل. هناك عدة طرق لتجنب المشكلات:

• شغّل التطبيق الخاص بك مباشرةً من حزمة ZIP، بدون فك ضغطه.
• أوقف التطبيق الخاص بك أو مكّن الوضع غير المتصل في أثناء التوزيع. لمزيدٍ من المعلومات، اطلع على التعامل مع الملفات المؤمنة في أثناء التوزيع.
• التوزيع إلى فتحة التقسيم المرحلي مع تشغيل التبديل التلقائي.

الأسئلة الشائعة

• هل يعمل موفر إنشاء GitHub Actions مع المصادقة الأساسية إذا تم تعطيل المصادقة الأساسية؟
• ماذا يفعل خيار الهوية المعين من قبل المستخدم لإجراءات GitHub؟
• لماذا أرى الخطأ، "هذه الهوية ليس لديها أذونات كتابة على هذا التطبيق. الرجاء تحديد هوية مختلفة، أو العمل مع المسؤول لمنح دور المساهم في موقع الويب لهويتك على هذا التطبيق"؟
• لماذا أرى الخطأ، "هذه الهوية ليس لديها أذونات كتابة على هذا التطبيق. الرجاء تحديد هوية مختلفة، أو العمل مع المسؤول لمنح دور المساهم في موقع الويب لهويتك على هذا التطبيق"؟

هل يعمل موفر إنشاء GitHub Actions مع المصادقة الأساسية إذا تم تعطيل المصادقة الأساسية؟

‏‏لا. حاول استخدام إجراءات GitHub مع خيار الهوية المعين من قبل المستخدم.

لمزيد من المعلومات، راجع النشر بدون مصادقة أساسية.

ماذا يفعل خيار الهوية المعين من قبل المستخدم لإجراءات GitHub؟

عند تحديد الهوية المعينة من قبل المستخدم ضمن مصدر إجراءات GitHub ، تقوم App Service بتكوين جميع الموارد الضرورية في Azure وفي GitHub لتمكين مصادقة OpenID Connect الموصى بها باستخدام إجراءات GitHub.

على وجه التحديد، تقوم App Service بالعملية التالية:

• إنشاء بيانات اعتماد موحدة بين هوية مدارة يعينها المستخدم في Azure والمستودع والفرع المحددين في GitHub.
• إنشاء الأسرار AZURE_CLIENT_IDو AZURE_TENANT_IDو AZURE_SUBSCRIPTION_ID من بيانات الاعتماد الموحدة في مستودع GitHub المحدد.
• تعيين الهوية لتطبيقك.

في سير عمل GitHub Actions في مستودع GitHub الخاص بك، يمكنك بعد ذلك استخدام إجراء Azure/login للمصادقة مع تطبيقك باستخدام OpenID Connect. للحصول على أمثلة، راجع إضافة ملف سير العمل إلى مستودع GitHub الخاص بك.

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

لماذا أرى الخطأ، "ليس لديك أذونات كافية على هذا التطبيق لتعيين الوصول المستند إلى الدور إلى هوية مدارة وتكوين بيانات الاعتماد الموحدة"؟

تشير الرسالة إلى أن حساب Azure الخاص بك ليس لديه الأذونات المطلوبة لإنشاء هوية مدارة معينة من قبل المستخدم لإجراءات GitHub. الأذونات المطلوبة (التي تم تحديد نطاقها لتطبيقك) هي:

• Microsoft.Authorization/roleAssignments/write
• Microsoft.ManagedIdentity/userAssignedIdentities/write

بشكل افتراضي، يمتلك دور مسؤول وصول المستخدم ودور المالك هذه الأذونات بالفعل، ولكن دور المساهم لا يملكها. إذا لم يكن لديك الأذونات المطلوبة، فاعمل مع مسؤول Azure لإنشاء هوية مدارة معينة من قبل المستخدم مع دور المساهم في موقع الويب. في Deployment Center، يمكنك بعد ذلك تحديد الهوية في القائمة المنسدلة GitHub>Identity.

لمزيد من المعلومات حول الخطوات البديلة، راجع النشر إلى App Service باستخدام GitHub Actions.

لماذا أرى الخطأ، "هذه الهوية ليس لديها أذونات كتابة على هذا التطبيق. الرجاء تحديد هوية مختلفة، أو العمل مع المسؤول لمنح دور المساهم في موقع الويب لهويتك على هذا التطبيق"؟

تشير الرسالة إلى أن الهوية المدارة المحددة المعينة من قبل المستخدم ليس لها الدور المطلوب لتمكين OpenID Connect بين مستودع GitHub والتطبيق App Service. يجب أن يكون للهوية أحد الأدوار التالية على التطبيق: المالك والمساهم والمساهم في مواقع الويب. الدور الأقل امتيازا الذي تحتاجه الهوية هو مساهم مواقع الويب.

المزيد من الموارد

• استخدام Azure PowerShell