مشاركة عبر

تعرف على طريقة إنشاء بيئة خدمة تطبيقات خارجية أو بيئة ILB باستخدام قالب Azure Resource Manager

  • مقالة

نظرة عامة

هام

تتناول هذه المقالة الإصدار الثاني من App Service Environment، والذي يتم استخدامه مع خطط خدمة التطبيقات المعزولة. تم إيقاف App Service Environment v1 وv2 اعتبارا من 31 أغسطس 2024. يوجد إصدار جديد من App Service Environment يسهل استخدامه ويعمل ببنية أساسية أكثر قوة. لمعرفة المزيد عن الإصدار الجديد، ابدأ بمقدمة لبيئة App Service. إذا كنت تستخدم إصدار 1 من App Service Environment حاليًا، فالرجاء اتباع الخطوات الواردة في هذه المقالة للترحيل إلى الإصدار الجديد.

اعتبارا من 31 أغسطس 2024، لم تعد اتفاقية مستوى الخدمة (SLA) وأرصدة الخدمة تنطبق على أحمال عمل App Service Environment v1 وv2 التي لا تزال قيد الإنتاج نظرا لأنها منتجات متوقفة. بدأ إيقاف تشغيل أجهزة App Service Environment v1 وv2، وقد يؤثر ذلك على توفر التطبيقات والبيانات وأدائها.

يجب إكمال الترحيل إلى App Service Environment v3 على الفور أو قد يتم حذف التطبيقات والموارد. سنحاول الترحيل التلقائي لأي بيئة خدمة تطبيقات متبقية v1 وv2 على أساس أفضل جهد باستخدام ميزة الترحيل الموضعي، ولكن Microsoft لا تقدم أي مطالبة أو ضمانات حول توفر التطبيق بعد الترحيل التلقائي. قد تحتاج إلى إجراء تكوين يدوي لإكمال الترحيل وتحسين خيار SKU لخطة App Service لتلبية احتياجاتك. إذا لم يكن الترحيل التلقائي ممكنا، حذف الموارد وبيانات التطبيق المقترنة. ونحثك بشدة على التصرف الآن لتجنب أي من هذه السيناريوهات المتطرفة.

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

للحصول على أحدث المعلومات حول إيقاف App Service Environment v1/v2، راجع تحديث إيقاف App Service Environment v1 وv2.

يمكن إنشاء بيئات خدمة تطبيقات Azure (ASEs) بنقطة نهاية يمكن الوصول إليها عبر الإنترنت أو نقطة نهاية على عنوان داخلي في شبكة Azure الظاهرية. عند الإنشاء بنقطة نهاية داخلية، يتم توفير نقطة النهاية هذه بواسطة مكون Azure يسمى موازن التحميل الداخلي (ILB). ASE على عنوان IP داخلي تسمى ILB ASE. ASE مع نقطة نهاية عامة تسمى ASE خارجية.

يمكن إنشاء ASE باستخدام مدخل Microsoft Azure أو قالب Azure Resource Manager. تتناول هذه المقالة الخطوات وبناء الجملة التي تحتاجها لإنشاء ASE خارجي أو ILB ASE باستخدام قوالب Resource Manager. لمعرفة كيفية إنشاء ASEv2 في مدخل Microsoft Azure، راجع [Make an External ASE][MakeExternalASE] أو Make an ILB ASE.

عند إنشاء ASE في مدخل Microsoft Azure، يمكنك إنشاء شبكتك الظاهرية في نفس الوقت أو اختيار شبكة ظاهرية موجودة مسبقا للنشر فيها.

عند إنشاء ASE من قالب، يجب أن تبدأ بما يلي:

  • شبكة Azure الظاهرية.
  • شبكة فرعية في الشبكة الظاهرية. نوصي بحجم شبكة فرعية ASE مع /24 256 عنوانًا لاستيعاب احتياجات النمو والتحجيم المستقبلية. بعد إنشاء ASE، لا يمكنك تغيير الحجم.
  • الاشتراك الذي تريد النشر فيه.
  • الموقع الذي تريد النشر فيه.

لأتمتة إنشاء ASE الخاص بك، اتبع إرشاداتها في الأقسام التالية. إذا كنت تقوم بإنشاء ILB ASEv2 مع dnsSuffix مخصص (على سبيل المثال، internal.contoso.com)، فهناك بعض الأشياء الأخرى التي يجب القيام بها.

  1. بعد إنشاء ILB ASE مع dnsSuffix المخصص، يجب تحميل شهادة TLS/SSL التي تطابق مجال ILB ASE الخاص بك.

  2. يتم تعيين شهادة TLS/SSL التي تم تحميلها إلى ILB ASE كشهادة TLS/SSL "افتراضية". تُستخدم هذه الشهادة لنسبة استخدام الشبكة TLS / SSL إلى التطبيقات الموجودة على ILB ASE عندما تستخدم مجال الجذر المشترك الذي تم تعيينه لـ ASE (على سبيل المثال،https://someapp.internal.contoso.com).

إنشاء ASE

يتوفر قالب Resource Manager الذي ينشئ ASE وملف المعلمات المقترن به على GitHub ل ASEv2.

إذا كنت تريد إنشاء ASE، فاستخدم مثال ASEv2 لقالب Resource Manager هذا. معظم المعلمات في ملف azuredeploy.parameters.json شائعة في إنشاء ILB ASEs وASEs الخارجية. تستدعي القائمة التالية معلمات الملاحظة الخاصة، أو التي تكون فريدة، عند إنشاء ILB ASE مع شبكة فرعية موجودة.

المعلمات

  • aseName: تعرف هذه المعلمة اسم ASE فريدا.
  • الموقع: تحدد هذه المعلمة موقع App Service Environment.
  • existingVirtualNetworkName: تحدد هذه المعلمة اسم الشبكة الظاهرية للشبكة الظاهرية والشبكة الفرعية الموجودة حيث توجد ASE.
  • existingVirtualNetworkResourceGroup: تحدد معلمته اسم مجموعة الموارد للشبكة الظاهرية الحالية والشبكة الفرعية حيث يوجد ASE.
  • subnetName: تحدد هذه المعلمة اسم الشبكة الفرعية للشبكة الظاهرية الحالية والشبكة الفرعية حيث يوجد ASE.
  • internalLoadBalancingMode: في معظم الحالات، قم بتعيين هذا إلى 3، ما يعني أن كلاً من نسبة استخدام الشبكة HTTP/HTTPS على المنافذ 80/443، ومنافذ قناة التحكم/البيانات التي استمعت إليها خدمة FTP على ASE، ستكون مرتبطة بعنوان داخلي للشبكة الظاهرية المخصصة من ILB. إذا تم تعيين هذه الخاصية إلى 2، فإن المنافذ المتعلقة بخدمة FTP فحسب (كل من قنوات التحكم والبيانات) مرتبطة بعنوان ILB. إذا تم تعيين هذه الخاصية إلى 0، تظل نسبة استخدام الشبكة HTTP/HTTPS على VIP العام.
  • dnsSuffix: تحدد هذه المعلمة المجال الجذر الافتراضي الذي تم تعيينه إلى ASE. في التباين العام لـ Azure App Service يكون المجال الجذر الافتراضي لجميع تطبيقات الويب azurewebsites.net. نظرًا إلى أن ILB ASE داخلي للشبكة الظاهرية للعميل، فمن غير المنطقي استخدام المجال الجذر الافتراضي للخدمة العامة. وبدلاً من ذلك، يجب أن يكون لـ ILB ASE مجال جذر افتراضي منطقي للاستخدام داخل الشبكة الظاهرية الداخلية لشركة. على سبيل المثال، قد تستخدم شركة Contoso مجال جذر افتراضي internal.contoso.com للتطبيقات التي تهدف إلى أن تكون قابلة للحل ويمكن الوصول إليها فقط داخل الشبكة الظاهرية لشركة Contoso. لتحديد مجال جذر مخصص، تحتاج إلى استخدام إصدار 2018-11-01 واجهة برمجة التطبيقات أو الإصدارات السابقة.
  • ipSslAddressCount: هذه المعلمة تعين تلقائيًا افتراضيًا إلى قيمة 0 في ملف azuredeploy.json لأن ILB ASEs لها عنوان ILB واحد فقط. لا توجد عناوين IP-SSL صريحة لـ ILB ASE. بعد ذلك، يجب تعيين تجمع عناوين IP-SSL لـ ILB ASE إلى صفر. وإلا، يحدث خطأ في التوفير.

بعد تعبئة ملف azuredeploy.parameters.json، قم بإنشاء ASE باستخدام القصاصة البرمجية PowerShell. قم بتغيير مسارات الملفات لمطابقة مواقع ملفات القوالب Resource Manager على جهازك. تذكر توفير القيم الخاصة بك لاسم نشر Resource Manager واسم مجموعة الموارد:

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

يستغرق إنشاء ASE حوالي ساعتين. ثم تظهر ASE في البوابة الإلكترونية في قائمة ASEs للاشتراك الذي أدى إلى النشر.

تحميل وتكوين شهادة TLS/SSL "الافتراضية"

يجب أن تكون شهادة TLS/SSL مقترنة بـ ASE كشهادة TLS/SSL "الافتراضية" المستخدمة لإنشاء اتصالات TLS بالتطبيقات. إذا كانت لاحقة DNS الافتراضية ل ASE internal.contoso.com، يتطلب الاتصال https://some-random-app.internal.contoso.com شهادة TLS/SSL صالحة ل *.internal.contoso.com.

احصل على شهادة TLS/SSL صالحة باستخدام المراجع المصدقة الداخلية أو شراء شهادة من مصدر خارجي أو استخدام شهادة موقعة ذاتيًا. بصرف النظر عن مصدر شهادة TLS/SSL، يجب تكوين سمات الشهادة التالية بشكل صحيح كما يلي:

  • الموضوع: يجب تعيين هذه السمة إلى *.your-root-domain-here.com.
  • اسم الموضوع البديل: يجب أن تتضمن هذه السمة كلا من .your-root-domain-here.com و*.scm.your-root-domain-here.com*. تستخدم اتصالات TLS بموقع SCM/Kudu المقترن بكل تطبيق عنوانًا للنموذج your-app-name.scm.your-root-domain-here.com.

مع شهادة TLS/SSL صالحة في متناول اليد، هناك حاجة إلى خطوتين تحضيريتين إضافيتين. تحويل/حفظ شهادة TLS/SSL كملف .pfx. تذكر أن ملف .pfx يجب أن يتضمن جميع الشهادات المتوسطة والجذرية. قم بتأمينه باستخدام كلمة مرور.

يجب تحويل ملف .pfx إلى سلسلة base64 لأنه يتم تحميل شهادة TLS/SSL باستخدام قالب Resource Manager. نظرًا إلى أن قوالب Resource Manager عبارة عن ملفات نصية، فيجب تحويل ملف .pfx إلى سلسلة base64. بهذه الطريقة يمكن تضمينه كمعلمة للقالب.

استخدم التعليمات البرمجية التالية PowerShell المتكررة إلى:

  • إنشاء شهادة موقعة ذاتيًا.
  • تصدير الشهادة كملف .pfx.
  • تحويل ملف .pfx إلى سلسلة مرمزة بـ base64.
  • احفظ السلسلة المرمزة base64 إلى ملف منفصل.

تم تكييف رمز PowerShell هذا لترميز base64 من مدونة البرامج النصية PowerShell:

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password     

$fileContentBytes = get-content -encoding byte $fileName
$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$fileContentEncoded | set-content ($fileName + ".b64")

بعد إنشاء شهادة TLS/SSL بنجاح وتحويلها إلى سلسلة مرمزة بـ base64، استخدم المثال Resource Manager قالب تكوين شهادة SSL الافتراضية على GitHub.

يتم سرد المعلمات في ملف azuredeploy.parameters.json هنا:

  • appServiceEnvironmentName: اسم ILB ASE الذي يتم تكوينه.
  • existingAseLocation: سلسلة نصية تحتوي على منطقة Azure بموقع نشر ILB ASE. على سبيل المثال، "جنوب وسط الولايات المتحدة".
  • pfxBlobString: تمثيل السلسلة المشفرة المستندة إلى 64 لملف .pfx. استخدم القصاصة البرمجية الموضحة سابقًا وانسخ السلسلة الموجودة في "exportedcert.pfx.b64". ألصقها كقيمة للسمة pfxBlobString.
  • كلمة المرور: كلمة المرور المستخدمة لتأمين ملف .pfx.
  • certificateThumbprint: بصمة الإبهام للشهادة. إذا قمت باسترداد هذه القيمة من PowerShell (على سبيل المثال، $certificate.Thumbprint من القصاصة البرمجية السابقة)، يمكنك استخدام القيمة كما هي. إذا قمت بنسخ القيمة من مربع الحوار شهادة Windows، فتذكر أن تقوم بتجريد المسافات الغريبة. يجب أن تبدو بصمة الشهادة مثل AF3143EB61D43F6727842115BB7F17BBCECAECAE.
  • certificateName: معرف سلسلة مألوف من اختيارك الخاص المستخدم لهوية الشهادة. يتم استخدام الاسم كجزء من معرف Resource Manager الفريد لكيان Microsoft.Web/certificates الذي يمثل شهادة TLS/SSL. يجب أن ينتهي الاسم باللاحقة التالية: _yourASENameHere_InternalLoadBalancingASE. يستخدم مدخل Microsoft Azure هذه اللاحقة كمؤشر على استخدام الشهادة لتأمين ASE ممكن بواسطة ILB.

يتم هنا عرض مثال مختصر على azuredeploy.parameters.json بما يلي:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "appServiceEnvironmentName": {
      "value": "yourASENameHere"
    },
    "existingAseLocation": {
      "value": "East US 2"
    },
    "pfxBlobString": {
      "value": "MIIKcAIBAz...snip...snip...pkCAgfQ"
    },
    "password": {
      "value": "PASSWORDGOESHERE"
    },
    "certificateThumbprint": {
      "value": "AF3143EB61D43F6727842115BB7F17BBCECAECAE"
    },
    "certificateName": {
      "value": "DefaultCertificateFor_yourASENameHere_InternalLoadBalancingASE"
    }
  }
}

بعد تعبئة ملف azuredeploy.parameters.json، قم بتكوين شهادة TLS/SSL الافتراضية باستخدام القصاصة البرمجية PowerShell. تغيير مسارات الملفات لمطابقة موقع ملفات قالب Resource Manager على الجهاز. تذكر توفير القيم الخاصة بك لاسم نشر Resource Manager واسم مجموعة الموارد:

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

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

بعد انتهاء القالب، يمكن الوصول إلى التطبيقات على ILB ASE عبر HTTPS. يتم تأمين الاتصالات باستخدام شهادة TLS/SSL الافتراضية. يتم استخدام شهادة TLS/SSL الافتراضية عند معالجة التطبيقات على ILB ASE باستخدام مجموعة من اسم التطبيق بالإضافة إلى اسم المضيف الافتراضي. على سبيل المثال، https://mycustomapp.internal.contoso.com يستخدم شهادة TLS/SSL الافتراضية ل *.internal.contoso.com.

مع ذلك، تمامًا مثل التطبيقات التي تعمل على الخدمة العامة متعددة المستأجرين، يمكن للمطورين تكوين أسماء مضيفين مخصصة للتطبيقات الفردية. كما يمكنها تكوين روابط شهادات SNI TLS/SSL فريدة للتطبيقات الفردية.