استخدام Azure Front Door في حل متعدد المستأجرين

  • مقالة

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

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

  • كم عدد المستأجرين لديك، وكم عدد المستأجرين الذين تتوقع أن يكون لديهم في المستقبل؟
  • هل تشارك مستوى التطبيق الخاص بك بين مستأجرين متعددين، أو تنشر العديد من مثيلات تطبيق المستأجر الفردي، أو تنشر طوابع توزيع منفصلة تتم مشاركتها من قبل مستأجرين متعددين؟
  • هل يريد المستأجرون إحضار أسماء المجالات الخاصة بهم؟
  • هل ستستخدم مجالات أحرف البدل؟
  • هل تحتاج إلى استخدام شهادات TLS الخاصة بك، أم ستدير Microsoft شهادات TLS الخاصة بك؟
  • هل فكرت في الحصص النسبية والحدود التي تنطبق على Azure Front Door؟ هل تعرف ما هي الحدود التي ستقترب منها أثناء نموك؟ إذا كنت تشك في أنك ستقترب من هذه الحدود، ففكر في استخدام ملفات تعريف Azure Front Door متعددة. أو ضع في اعتبارك ما إذا كان يمكنك تغيير الطريقة التي تستخدم بها Azure Front Door لتجنب الحدود. لاحظ أن Premium SKU له حدود أعلى من SKU القياسية.
  • هل لديك أنت أو المستأجرون لديك متطلبات لتصفية عنوان IP أو الحظر الجغرافي أو تخصيص قواعد WAF؟
  • هل جميع خوادم تطبيقات المستأجرين تواجه الإنترنت؟

ميزات Azure Front Door التي تدعم تعدد المستأجرين

يصف هذا القسم العديد من الميزات الرئيسية ل Azure Front Door المفيدة للحلول متعددة المستأجرين. يصف كيف يمكن أن يساعدك Azure Front Door في تكوين المجالات المخصصة، بما في ذلك معلومات حول مجالات أحرف البدل وشهادات TLS. كما يلخص كيفية استخدام قدرات توجيه Azure Front Door لدعم تعدد المستأجرين.

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

يوفر Azure Front Door اسم مضيف افتراضي لكل نقطة نهاية تقوم بإنشائها، على سبيل المثال، contoso.z01.azurefd.net. بالنسبة لمعظم الحلول، يمكنك بدلا من ذلك إقران اسم المجال الخاص بك بنقطة نهاية Azure Front Door. تمكنك أسماء المجالات المخصصة من استخدام العلامة التجارية الخاصة بك وتكوين التوجيه استنادا إلى اسم المضيف المقدم في طلب العميل.

في حل متعدد المستأجرين، يمكنك استخدام أسماء المجالات الخاصة بالمستأجر أو المجالات الفرعية، وتكوين Azure Front Door لتوجيه حركة مرور المستأجر إلى مجموعة الأصل الصحيحة لحمل عمل هذا المستأجر. على سبيل المثال، قد تقوم بتكوين اسم مجال مخصص مثل tenant1.app.contoso.com. باستخدام Azure Front Door، يمكنك تكوين مجالات مخصصة متعددة على ملف تعريف Azure Front Door واحد.

لمزيد من المعلومات، راجع إضافة مجال مخصص إلى Front Door.

مجالات أحرف البدل

تعمل مجالات أحرف البدل على تبسيط تكوين سجلات DNS وتكوين توجيه حركة مرور Azure Front Door عند استخدام مجال جذع مشترك والمجالات الفرعية الخاصة بالمستأجر. على سبيل المثال، افترض أن المستأجرين يصلون إلى تطبيقاتهم باستخدام مجالات فرعية مثل tenant1.app.contoso.com و tenant2.app.contoso.com. يمكنك تكوين مجال حرف بدل، ، *.app.contoso.comبدلا من تكوين كل مجال خاص بالمستأجر بشكل فردي.

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

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

لا يصدر Azure Front Door شهادات TLS المدارة لمجالات أحرف البدل، لذلك تحتاج إلى شراء الشهادة الخاصة بك وتوفيرها.

لمزيد من المعلومات، راجع مجالات أحرف البدل.

شهادات TLS المدارة

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

قد تتم استضافة تطبيق الأصل الخاص بك على خدمة Azure أخرى توفر أيضا شهادات TLS مدارة، مثل Azure App Service. يعمل Azure Front Door بشفافية مع الخدمة الأخرى لمزامنة شهادات TLS الخاصة بك.

إذا سمحت للمستأجرين بتوفير المجالات المخصصة الخاصة بهم وتريد أن يصدر Azure Front Door شهادات لأسماء المجالات هذه، فلا يجب على المستأجرين تكوين سجلات CAA على خوادم DNS الخاصة بهم والتي قد تمنع Azure Front Door من إصدار الشهادات نيابة عنهم. لمزيد من المعلومات، راجع شهادات TLS/SSL.

لمزيد من المعلومات حول شهادات TLS، راجع TLS من طرف إلى طرف باستخدام Azure Front Door.

التوجيه

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

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

لمزيد من المعلومات، راجع نظرة عامة على هندسة التوجيه.

محرك القواعد

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

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

لمزيد من المعلومات، راجع ما هو محرك قواعد Azure Front Door؟.

سيناريوهات مقدمة كمثال

توضح سيناريوهات المثال التالي كيف يمكنك تكوين العديد من البنيات متعددة المستأجرين في Azure Front Door، وكيف يمكن أن تؤثر القرارات التي تتخذها على تكوين DNS وTLS.

تنفذ العديد من الحلول متعددة المستأجرين نمط طوابع النشر. عند استخدام نهج النشر هذا، عادة ما تقوم بنشر ملف تعريف Azure Front Door مشترك واحد واستخدام Azure Front Door لتوجيه نسبة استخدام الشبكة الواردة إلى الطابع المناسب. نموذج التوزيع هذا هو النموذج الأكثر شيوعا، وتظهر السيناريوهات من 1 إلى 4 في هذه المقالة كيف يمكنك استخدامه لتلبية مجموعة من المتطلبات.

ومع ذلك، في بعض الحالات، قد تقوم بنشر ملف تعريف Azure Front Door في كل طابع من حلولك. يصف السيناريو 5 نموذج التوزيع هذا.

السيناريو 1: مجال حرف البدل المدار من قبل الموفر، طابع واحد

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

تنشر Contoso Azure Front Door باستخدام هذا التكوين:

Diagram that shows an Azure Front Door configuration that has a single custom domain, route, and origin group and a wildcard TLS certificate in Azure Key Vault.

تكوين DNS

التكوين لمرة واحدة: تقوم Contoso بتكوين إدخالين من إدخالات DNS:

  • سجل TXT لحرف البدل ل *.contoso.com. يتم تعيينه إلى القيمة المحددة بواسطة Azure Front Door أثناء عملية إعداد المجال المخصص.
  • سجل CNAME لحرف البدل، *.contoso.com، وهو اسم مستعار لنقطة نهاية Azure Front Door الخاصة ب Contoso: contoso.z01.azurefd.net.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

تكوين TLS

التكوين لمرة واحدة: تشتري شركة Contoso شهادة TLS لحرف بدل، وتضيفها إلى مخزن مفاتيح، وتمنح Azure Front Door حق الوصول إلى المخزن.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

تكوين Azure Front Door

التكوين لمرة واحدة: تنشئ Contoso ملف تعريف Azure Front Door ونقطة نهاية واحدة. يضيفون مجالا مخصصا واحدا بالاسم *.contoso.com ويربطون شهادة TLS لحرف البدل بمورد المجال المخصص. ثم يقومون بتكوين مجموعة أصل واحدة تحتوي على أصل واحد لخادم التطبيق الخاص بهم. وأخيرا، يقومون بتكوين مسار لتوصيل المجال المخصص بمجموعة الأصل.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

المزايا

  • هذا التكوين سهل التكوين نسبيا ويوفر للعملاء عناوين URL ذات العلامة التجارية Contoso.
  • يدعم النهج عددا كبيرا من المستأجرين.
  • عند إعداد مستأجر جديد، لا تحتاج Contoso إلى إجراء تغييرات على شهادات Azure Front Door أو DNS أو TLS.

العيوب

  • لا يتجاوز هذا النهج بسهولة طابع تطبيق واحد أو منطقة واحدة.
  • تحتاج شركة Contoso إلى شراء شهادة TLS لحرف بدل وتجديد الشهادة وتثبيتها عند انتهاء صلاحيتها.

السيناريو 2: مجال حرف البدل المدار من قبل موفر الخدمة، طوابع متعددة

تقوم Proseware ببناء حل متعدد المستأجرين عبر طوابع متعددة يتم نشرها في كل من أستراليا وأوروبا. يتم تقديم جميع الطلبات داخل منطقة واحدة بواسطة الطابع في تلك المنطقة. مثل Contoso، قررت Proseware استخدام مجالات أحرف البدل لجميع المستأجرين، مثل tenant1.proseware.com و tenant2.proseware.com.

ينشر Proseware Azure Front Door باستخدام هذا التكوين:

Diagram that shows an Azure Front Door configuration that has multiple custom domains, routes, and origin groups and a wildcard TLS certificate in Key Vault.

تكوين DNS

التكوين لمرة واحدة: يقوم Proseware بتكوين إدخالين من إدخالات DNS:

  • سجل TXT لحرف البدل ل *.proseware.com. يتم تعيينه إلى القيمة المحددة بواسطة Azure Front Door أثناء عملية إعداد المجال المخصص.
  • سجل CNAME لحرف البدل، *.proseware.com، وهو اسم مستعار لنقطة نهاية Azure Front Door ل Proseware: proseware.z01.azurefd.net.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

تكوين TLS

التكوين لمرة واحدة: يشتري Proseware شهادة TLS لحرف البدل، ويضيفها إلى مخزن مفاتيح، ويمنح Azure Front Door حق الوصول إلى المخزن.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

تكوين Azure Front Door

التكوين لمرة واحدة: ينشئ Proseware ملف تعريف Azure Front Door ونقطة نهاية واحدة. تقوم الشركة بتكوين مجموعات منشأ متعددة، واحدة لكل خادم/طابع تطبيق في كل منطقة.

عند إعداد مستأجر جديد: يضيف Proseware مورد مجال مخصص إلى Azure Front Door. يستخدمون الاسم *.proseware.com ويربطون شهادة TLS لحرف البدل بمورد المجال المخصص. ثم يقومون بإنشاء مسار لتحديد مجموعة الأصل (الطابع) التي يجب توجيه طلبات المستأجر إليها. في الرسم التخطيطي السابق، tenant1.proseware.com التوجيهات إلى مجموعة الأصل في منطقة أستراليا، والمسارات tenant2.proseware.com إلى مجموعة الأصل في منطقة أوروبا.

المزايا

  • عند إلحاق المستأجرين الجدد، لا يلزم إجراء تغييرات على تكوين DNS أو TLS.
  • يحتفظ Proseware بمثيل واحد من Azure Front Door لتوجيه نسبة استخدام الشبكة إلى طوابع متعددة عبر مناطق متعددة.

العيوب

  • يحتاج Proseware إلى إعادة تكوين Azure Front Door في كل مرة يتم فيها إلحاق مستأجر جديد.
  • يحتاج Proseware إلى الانتباه إلى حصص وحدود Azure Front Door، خاصة على عدد المسارات والمجالات المخصصة، وحدود التوجيه المركب.
  • يحتاج Proseware إلى شراء شهادة TLS لحرف البدل.
  • Proseware مسؤول عن تجديد الشهادة وتثبيتها عند انتهاء صلاحيتها.

السيناريو 3: المجالات الفرعية لأحرف البدل المستندة إلى الطوابع التي يديرها الموفر

تقوم Fabrikam ببناء حل متعدد المستأجرين. تنشر الشركة الطوابع في أستراليا والولايات المتحدة. سيتم تقديم جميع الطلبات داخل منطقة واحدة بواسطة الطابع في تلك المنطقة. ستستخدم Fabrikam المجالات الجذعية المستندة إلى الطوابع، مثل tenant1.australia.fabrikam.comو tenant2.australia.fabrikam.comو.tenant3.us.fabrikam.com

تنشر الشركة Azure Front Door باستخدام هذا التكوين:

Diagram that shows an Azure Front Door configuration that has multiple custom stamp-based stem domains, routes, origin groups, and wildcard TLS certificate in Key Vault.

تكوين DNS

التكوين لمرة واحدة: تقوم Fabrikam بتكوين إدخالي DNS لحرف البدل التاليين لكل طابع.

  • سجل TXT لحرف البدل لكل طابع: *.australia.fabrikam.com و *.us.fabrikam.com. يتم تعيينها إلى القيم المحددة بواسطة Azure Front Door أثناء عملية إعداد المجال المخصص.
  • سجل CNAME لحرف البدل لكل طابع، و*.us.fabrikam.com، *.australia.fabrikam.com وهما اسمان مستعاران لنقطة نهاية Azure Front Door: fabrikam.z01.azurefd.net.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

تكوين TLS

التكوين لمرة واحدة: تشتري Fabrikam شهادة TLS لحرف البدل لكل طابع، وتضيفها إلى مخزن مفاتيح، وتمنح Azure Front Door حق الوصول إلى المخزن.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

تكوين Azure Front Door

التكوين لمرة واحدة: تنشئ Fabrikam ملف تعريف Azure Front Door ونقطة نهاية واحدة. يقومون بتكوين مجموعة أصل لكل طابع. يقومون بإنشاء مجالات مخصصة، باستخدام حرف بدل، لكل مجال فرعي قائم على الطوابع: *.australia.fabrikam.com و *.us.fabrikam.com. يقومون بإنشاء مسار للمجال المخصص لكل طابع لإرسال نسبة استخدام الشبكة إلى مجموعة الأصل المناسبة.

عند إلحاق مستأجر جديد: لا يلزم تكوين إضافي.

المزايا

  • يمكن هذا الأسلوب Fabrikam من التوسع إلى أعداد كبيرة من المستأجرين عبر طوابع متعددة.
  • عند إلحاق المستأجرين الجدد، لا يلزم إجراء تغييرات على تكوين DNS أو TLS.
  • تحتفظ Fabrikam بمثيل واحد من Azure Front Door لتوجيه نسبة استخدام الشبكة إلى طوابع متعددة عبر مناطق متعددة.

العيوب

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

السيناريو 4: مجالات الغرور

تقوم Adventure Works Cycles ببناء حل متعدد المستأجرين. تنشر الشركة الطوابع في مناطق متعددة، مثل أستراليا والولايات المتحدة. سيتم تقديم جميع الطلبات داخل منطقة واحدة بواسطة الطابع في تلك المنطقة. ستسمح Adventure Works لمستأجريها بإحضار أسماء المجالات الخاصة بهم. على سبيل المثال، قد يقوم المستأجر 1 بتكوين اسم مجال مخصص مثل tenant1app.tenant1.com.

تنشر الشركة Azure Front Door باستخدام هذا التكوين:

Diagram that shows an Azure Front Door configuration that has multiple custom vanity domains, routes, and origin groups and a combination of TLS certificates in Key Vault and TLS certificates that are managed by Azure Front Door.

تكوين DNS

التكوين لمرة واحدة: لا شيء.

عند إعداد مستأجر جديد: يحتاج المستأجر إلى إنشاء سجلين على خادم DNS الخاص به:

  • سجل TXT للتحقق من صحة المجال. على سبيل المثال، يحتاج المستأجر 1 إلى تكوين سجل TXT المسمى tenant1app.tenant1.com وتعيينه إلى القيمة المحددة بواسطة Azure Front Door أثناء عملية إلحاق المجال المخصص.
  • سجل CNAME باسم مستعار لنقطة نهاية Adventure Works Azure Front Door. على سبيل المثال، يحتاج المستأجر 1 إلى تكوين سجل CNAME المسمى tenant1app.tenant1.com وتعيينه إلى adventureworks.z01.azurefd.net.

تكوين TLS

تحتاج Adventure Works ومستأجريها إلى تحديد من يصدر شهادات TLS:

  • الخيار الأسهل هو استخدام Azure Front Door لإصدار الشهادات وإدارتها، ولكن يجب ألا يقوم المستأجرون بتكوين سجلات CCA على خوادم DNS الخاصة بهم. إذا فعلوا ذلك، فقد تمنع السجلات مرجع مصدق Azure Front Door من إصدار الشهادات.
  • بدلا من ذلك، يمكن للمستأجرين توفير شهاداتهم الخاصة. يحتاجون إلى العمل مع Adventure Works لتحميل الشهادة إلى مخزن مفاتيح وتوفير الوصول إلى Azure Front Door.

تكوين Azure Front Door

التكوين لمرة واحدة: تقوم Adventure Works بإنشاء ملف تعريف Azure Front Door ونقطة نهاية واحدة. يقومون بتكوين مجموعة أصل لكل طابع. لا يقومون بإنشاء موارد مجال مخصصة أو مسارات.

عند إلحاق مستأجر جديد: تضيف Adventure Works مورد مجال مخصص إلى Azure Front Door. يستخدمون اسم المجال الذي يوفره المستأجر ويربطون شهادة TLS المناسبة بمورد المجال المخصص. ثم يقومون بإنشاء مسار لتحديد مجموعة الأصل (الطابع) التي يجب توجيه طلبات المستأجر إليها. في الرسم التخطيطي السابق، tenant1app.tenant1.com يتم توجيهه إلى مجموعة الأصل في منطقة أستراليا، ويتم tenant2app.tenant3.com توجيهه إلى مجموعة الأصل في منطقة الولايات المتحدة.

المزايا

  • يمكن للعملاء توفير أسماء المجالات الخاصة بهم. يوجه Azure Front Door الطلبات بشفافية إلى الحل متعدد المستأجرين.
  • تحتفظ Adventure Works بمثيل واحد من Azure Front Door لتوجيه نسبة استخدام الشبكة إلى طوابع متعددة عبر مناطق متعددة.

العيوب

  • تحتاج Adventure Works إلى إعادة تكوين Azure Front Door في كل مرة يتم فيها إلحاق مستأجر جديد.
  • يجب أن يشارك المستأجرون في عملية الإعداد. يحتاجون إلى إجراء تغييرات DNS وربما إصدار شهادات TLS.
  • يتحكم المستأجرون في سجلات DNS الخاصة بهم. قد تؤثر التغييرات في سجلات DNS على قدرتها على الوصول إلى حل Adventure Works.
  • تحتاج Adventure Works إلى الانتباه إلى حصص وحدود Azure Front Door، خاصة على عدد المسارات والمجالات المخصصة، وحدود التوجيه المركب.

السيناريو 5: ملف تعريف Azure Front Door لكل طابع

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

تلميح

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

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

المزايا

  • إذا قمت بتوسيع التكوين الخاص بك عبر ملفات تعريف متعددة، فأنت أقل احتمالا للوصول إلى حدود موارد Azure Front Door. على سبيل المثال، إذا كنت بحاجة إلى دعم أعداد كبيرة من المجالات المخصصة، يمكنك تقسيم المجالات بين ملفات تعريف Azure Front Door المتعددة والبقاء ضمن حدود كل ملف تعريف.
  • يمكنك هذا الأسلوب من تحديد نطاق أذونات إدارة موارد Azure Front Door. يمكنك استخدام التحكم في الوصول المستند إلى دور Azure (RBAC) لمنح المسؤولين حق الوصول إلى ملف تعريف طابع واحد.

العيوب

  • عادة ما يتحمل هذا الأسلوب تكلفة عالية لأنك تنشر المزيد من ملفات التعريف. لمزيد من المعلومات، راجع فهم فوترة Front Door.
  • هناك حد لعدد ملفات تعريف Azure Front Door التي يمكنك نشرها في اشتراك Azure واحد. لمزيد من المعلومات، راجع الحصص النسبية والحدود ل Front Door.
  • تحتاج إلى تكوين ملف تعريف Azure Front Door لكل طابع بشكل منفصل، وتحتاج إلى إدارة تكوين DNS وشهادات TLS وتكوين TLS لكل طابع.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

مساهمون آخرون:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية