أفضل ممارسات التوزيع

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

مكونات النشر

يصف هذا القسم المكونات الرئيسية الثلاثة للنشر في App Service.

مصدر التوزيع

مصدر التوزيع هو موقع التعليمات البرمجية للتطبيق الخاص بك. بالنسبة لتطبيقات الإنتاج، يكون مصدر النشر عادة مستودعا تستضيفه برامج التحكم في الإصدار مثل GitHub أو Bitbucket أو Azure Repos. بالنسبة لسيناريوهات التطوير والاختبار، قد يكون مصدر التوزيع مشروعا على جهازك المحلي.

مسار البنية

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

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

آلية التوزيع

آلية النشر هي الإجراء المستخدم لوضع التطبيق المضمن في الدليل /home/site/wwwroot لتطبيق الويب الخاص بك. الدليل /wwwroot هو موقع تخزين مثبت مشترك من قِبَل جميع مثيلات تطبيق الويب الخاص بك. عندما تضع آلية النشر التطبيق الخاص بك في هذا الدليل، تتلقى مثيلاتك إعلاماً لمزامنة الملفات الجديدة.

تدعم App Service آليات النشر التالية:

• نقاط نهاية Kudu: Kudu هي أداة إنتاجية المطور مفتوحة المصدر التي تعمل كعملية منفصلة في خدمة تطبيقات Windows. يتم تشغيله كحاوية ثانية في خدمة تطبيقات Linux. يعالج Kudu عمليات التوزيع المستمر ويوفر نقاط نهاية HTTP للتوزيع، مثل zipdeploy/.
• FTP وWebDeploy: باستخدام بيانات اعتماد الموقع أو المستخدم، يمكنك تحميل الملفات عبر FTP أو WebDeploy. هذه الآليات لا تمر عبر Kudu.

تستخدم أدوات النشر مثل Azure Pipelines وJenkins والمكونات الإضافية للمحرر إحدى آليات النشر هذه.

استخدام فتحات التوزيع

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

نشر التعليمات البرمجية باستمرار

إذا كان مشروعك يحتوي على فروع مخصصة للاختبار و QA والتقسيم المرحلي، فيجب نشر كل فرع من هذه الفروع بشكل مستمر في فتحة التقسيم المرحلي. يعرف هذا النهج بتصميم Gitflow. يسمح هذا التصميم للمساهمين بتقييم الفرع المنشور واختباره بسهولة.

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

نشر الحاويات باستمرار

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

لكل فرع تريد نشره في فتحة، قم بإعداد التشغيل التلقائي للقيام بهذه المهام على كل تثبيت إلى الفرع.

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

تحتوي هذه المقالة على أمثلة لأطر عمل التنفيذ التلقائي الشائعة.

استخدام Azure DevOps

تحتوي App Service على تسليم مستمر مضمن للحاويات من خلال مركز النشر. انتقل إلى تطبيقك في مدخل Microsoft Azure. ضمن Deployment، حدد Deployment Center. اتبع الإرشادات لتحديد المستودع والفرع. يقوم هذا الأسلوب بتكوين مسار إنشاء وإصدار DevOps لإنشاء الحاوية ووضع علامة عليها ونشرها تلقائيا عند دفع عمليات التثبيت الجديدة إلى الفرع المحدد.

استخدم إجراءات GitHub

يمكنك أيضاً أتمتة نشر الحاوية باستخدام إجراءات GitHub. يقوم ملف سير العمل بإنشاء الحاوية ووسمها بمعرف التثبيت، ودفعها إلى سجل حاوية، وتحديث تطبيق الويب المحدد بعلامة الصورة الجديدة.

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

استخدم موفري أتمتة آخرين

تنطبق الخطوات المذكورة سابقاً على الأدوات المساعدة الأخرى للأتمتة مثل CircleCI أو Travis CI. ومع ذلك، يتعين عليك استخدام Azure CLI لتحديث فتحات النشر بعلامات صور جديدة في الخطوة الأخيرة. لاستخدام Azure CLI في البرنامج النصي للأتمتة، قم بإنشاء كيان الخدمة باستخدام الأمر التالي.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

في البرنامج النصي الخاص بك، سجل الدخول باستخدام az login --service-principal، مع توفير المعلومات الأساسية. يمكنك بعد ذلك استخدام az webapp config container set لتعيين اسم الحاوية والعلامة وعنوان URL للتسجيل وكلمة مرور السجل. لمزيد من المعلومات، راجع كيفية تسجيل الدخول إلى Azure CLI على Circle CI.

اعتبارات خاصة باللغة

ضع في اعتبارك الاعتبارات التالية لتطبيقات Java والعقدة و.NET.

Java

استخدم Kudu zipdeploy API لنشر تطبيقات JAR. استخدم wardeploy لتطبيقات WAR. إذا كنت تستخدم Jenkins، يمكنك استخدام واجهات برمجة التطبيقات هذه مباشرة في مرحلة التوزيع الخاصة بك. لمزيد من المعلومات، راجع النشر إلى Azure App Service باستخدام Jenkins.

العقدة

بشكل افتراضي، يقوم Kudu بتشغيل خطوات الإنشاء لتطبيق العقدة (npm install). إذا كنت تستخدم خدمة بناء مثل Azure DevOps، فإن بنية Kudu غير ضرورية. لتعطيل إصدار Kudu، أنشئ إعداد تطبيق، SCM_DO_BUILD_DURING_DEPLOYMENT، بقيمة false.

.NET

بشكل افتراضي، يقوم Kudu بتشغيل خطوات الإنشاء لتطبيق .NET الخاص بك (dotnet build). إذا كنت تستخدم خدمة بناء مثل Azure DevOps، فإن بنية Kudu غير ضرورية. لتعطيل إصدار Kudu، أنشئ إعداد تطبيق، SCM_DO_BUILD_DURING_DEPLOYMENT، بقيمة false.

اعتبارات التوزيع الأخرى

وتشمل الاعتبارات الأخرى ذاكرة التخزين المؤقت المحلية وارتفاع وحدة المعالجة المركزية أو الذاكرة.

ذاكرة التخزين المؤقت المحلية

يتم تخزين محتوى Azure App Service على Azure Storage ويتم ظهوره بطريقة دائمة كمشاركة محتوى. ومع ذلك، تحتاج بعض التطبيقات فقط إلى مخزن محتوى عالي الأداء للقراءة فقط يمكنه تشغيله بتوافر عالٍ. يمكن أن تستفيد هذه التطبيقات من استخدام ذاكرة التخزين المؤقت المحلية. لمزيد من المعلومات، راجع نظرة عامة على Azure App Service Local Cache.

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

وحدة المعالجة المركزية أو الذاكرة العالية

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

لمزيد من المعلومات، تفضل بزيارة App Service Diagnostics لمعرفة أفضل الممارسات القابلة للتنفيذ الخاصة بالموارد الخاصة بك.

1. انتقل إلى تطبيق الوظائف الجديد لديك في مدخل Azure.

2. حدد تشخيص المشكلات وحلها في التنقل الأيسر، الذي يفتح تشخيصات خدمة التطبيقات.

3. اختر التوفر والأداء أو استكشف خيارات أخرى، مثل تحليل وحدة المعالجة المركزية العالي.

   اعرض الحالة الحالية لتطبيقك فيما يتعلق بأفضل الممارسات هذه.

يمكنك أيضاً استخدام هذا الارتباط لفتح App Service Diagnostics مباشرةً لموردك: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

المحتوى ذو الصلة

• متغيرات البيئة ومرجع إعدادات التطبيق