إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
بوابة التطبيق بمثابة نقطة اتصال واحدة للعملاء. وهو يوزع حركة مرور التطبيقات الواردة عبر العديد من تجمعات الخلفية، والتي تشمل Azure VMs ومجموعات مقياس الجهاز الظاهري وخدمة تطبيقات Azure والخوادم الداخلية/الخارجية. لتوزيع حركة المرور، يستخدم بوابة التطبيق عدة مكونات الموضحة في هذه المقالة.
عناوين IP الأمامية
عنوان IP الأمامي هو عنوان IP المقترن ببوابة التطبيق. يمكنك تكوين بوابة تطبيقات بحيث يكون لها عنوان IP عام أو عنوان IP خاص أو كلاهما. بوابة التطبيق تدعم عنوان IP عام أو خاص واحد. يجب أن يكون عنوان IP الخاص بك وشبكة الاتصال الظاهرية في نفس الموقع كبوابة التطبيق. بعد إنشائه، يتم إقران عنوان IP الأمامي بمستمع.
عنوان IP عام ثابت مقابل عنوان IP عام ديناميكي
يمكن تكوين وحدة تعريف Azure Application Gateway V2 لدعم كل من عنوان IP داخلي ثابت وعنوان IP عام ثابت، أو فقط عنوان IP عام ثابت. يمكنك أيضا تكوينها بعنوان IP داخلي ثابت (خاص) فقط عند نشر بوابة تطبيق خاصة مع networkIsolationEnabled تعيين على True. للاطلاع على تركيبات عناوين IP المدعومة في الواجهة الأمامية، انظر تكوين عناوين IP للواجهة الأمامية. لسلوك DNS في عمليات نشر IP الخاصة فقط، راجع حل DNS لبوابة التطبيق.
يمكن تكوين V1 SKU لدعم عنوان IP الداخلي الثابت أو الديناميكي وعنوان IP العام الديناميكي. لا يتغير عنوان IP الديناميكي لبوابة التطبيق على بوابة قيد التشغيل. يمكن تغيير فقط عند إيقاف أو بدء تشغيل البوابة. لا يتغير على فشل النظام والتحديثات وتحديثات مضيف Azure وما إلى ذلك.
ولكن اسم DNS المقترن ببوابة التطبيقات لا يتغير خلال عمر البوابة. لأنه لا يتم تغيير اسم DNS يجب استخدام اسم مستعار CNAME والإشارة إليه في عنوان DNS من بوابة التطبيقات.
وحدة الاستماع
المستمع هو كيان منطقي يقوم بالتحقق من طلبات التوصيل القادمة. يقبل المستمع طلبًا إذا تطابق البروتوكول والمنفذ واسم المضيف وعنوان IP المقترن بالطلب مع نفس العناصر المقترنة بتكوين وحدة الإصغاء.
قبل استخدام بوابة التطبيق، يجب إضافة مستمع واحدة على الأقل. يمكن أن يكون هناك عدة مستمعين متصلين ببوابة التطبيق، ويمكن استخدامها لنفس البروتوكول.
بعد اكتشاف المستمع الطلبات الواردة من العملاء، توجيه بوابة التطبيق هذه الطلبات إلى الأعضاء في تجمع الخلفية تكوين في القاعدة.
يدعم المستمعون المنافذ والبروتوكولات التالية.
منافذ
المنفذ هو المكان الذي يستمع إليه المستمع لطلب العميل. يمكنك تكوين المنافذ ل v1 وv2 SKUs وفقا لما يلي.
| وحدة حفظ المخزون SKU | نطاق المنفذ المدعوم | استثناء (استثناءات) |
|---|---|---|
| الإصدار 2 | من 1 إلى 64999 | استخدام المنفذ 22 غير مدعوم مع البوابات التي تدعم Private Link. الميناء 53 |
| الإصدار 1 | من 1 إلى 65502 | الميناء 3389 |
البروتوكولات
توفر بوابة التطبيق الدعم لبروتوكولات الويب HTTP وHTTPS وHTTP/2 وWebSocket من خلال وكيل الطبقة 7 الخاص بها. بالإضافة إلى ذلك، يدعم بروتوكول TLS وTCP عبر وكيل الطبقة الرابعة الخاص به، والذي يمكن تكوينه على نفس المصدر.
- اختر بين بروتوكولات HTTP أو HTTPS أو TLS أو TCP في تكوين وحدة الاستماع.
- يمكنك استخدام مستمع HTTPS أو TLS لإنهاء TLS. يقوم مستمع HTTPS/TLS بإلغاء تحميل عمل التشفير وفك التشفير إلى بوابة التطبيق الخاصة بك، لذلك لا تتحمل خوادمك عبء حساب TLS.
- يتم توفير الدعم WebSockets وبروتوكولات HTTP/2 أصلاً، ويتم تمكين دعم WebSocket بشكل افتراضي. لا يوجد إعداد قابل للتكوين من قِبل المستخدم لتمكين دعم WebSocket أو تعطيله بشكل انتقائي. استخدام WebSockets مع كل من HTTP و HTTPS listeners.
يلخص الجدول التالي كيف يدعم Application Gateway كل بروتوكول.
| بروتوكول | الوكيل | قابل للاختيار كبروتوكول مستمع | تفاصيل الدعم |
|---|---|---|---|
| HTTP | الطبقة 7 | نعم | مدعوم بشكل أصلي من خلال وكيل الطبقة 7. |
| HTTPS | الطبقة 7 | نعم | استخدم مستمع HTTPS لإنهاء TLS حتى تقوم البوابة بتحميل أعمال التشفير وفك التشفير من خوادمك. |
| HTTP/2 | الطبقة 7 | لا | متاح للعملاء الذين يتصلون بمستمعي بوابة التطبيق فقط. التواصل مع مجموعات خوادم الخلفية دائما يتم عبر HTTP/1.1. معطلة بشكل افتراضي؛ يمكنك اختيار تفعيله. |
| WebSocket | الطبقة 7 | لا | يتم تفعيله افتراضيا بدون إعداد يمكن للمستخدم التكوين تفعيله أو تعطيله بشكل انتقائي. استخدام WebSockets مع كل من HTTP و HTTPS listeners. |
| TLS | الطبقة 4 | نعم | مدعوم من خلال وكيل الطبقة الرابعة، الذي يمكنك تكوينه على نفس المصدر. |
| TCP | الطبقة 4 | نعم | مدعوم من خلال وكيل الطبقة الرابعة، الذي يمكنك تكوينه على نفس المصدر. |
إشعار
يتوفر دعم بروتوكول HTTP/2 للعملاء الذين يتصلون بمستمعي بوابة التطبيق فقط. الاتصال إلى تجمعات الملقم الخلفية دومًا عبر HTTP/1.1. افتراضيًا، يتم تعطيل دعم HTTP/2. يمكنك اختيار تمكينه.
صفحات الأخطاء المخصصة
تسمح لك بوابة التطبيق تكوين صفحات خطأ افتراضي بدلاً من عرض صفحات خطأ افتراضية. يمكنك استخدام العلامة التجارية الخاصة بك والتخطيط باستخدام صفحة الأخطاء المُخصصة. تعرض بوابة التطبيق صفحة خطأ مخصصة عندما يتعذر على الطلب الوصول إلى الواجهة الخلفية.
لمزيدٍ من المعلومات، راجع صفحات الخطأ المخصصة لبوابة التطبيق الخاص بك.
أنواع المستمعين
يوجد نوعان من المستمعين:
رئيسي. يستمع هذا النوع من المستمع إلى موقع مجال واحد، حيث يحتوي على تعيين DNS واحد إلى عنوان IP لبوابة التطبيق. تكوين مستمع هذا مطلوب عند استضافة موقع واحد خلف بوابة التطبيق.
موقع متعدد. تكوين المستمع هذا مطلوب عندما تريد تكوين التوجيه استنادًا إلى اسم المضيف أو اسم المجال لأكثر من تطبيق ويب واحد على نفس بوابة التطبيق. فهو يسمح لك بتكوين طوبولوجيا أكثر كفاءة للتوزيع الخاص بك عن طريق إضافة ما يصل إلى أكثر من 100 موقع ويب إلى بوابة تطبيق واحدة. يمكن توجيه كل موقع إلى مجموعة الواجهة الخلفية الخاصة به. على سبيل المثال، تشير ثلاثة مجالات وهي contoso.com وfabrikam.com وadatum.com إلى عنوان IP لبوابة التطبيق. يمكنك إنشاء ثلاثة مستمعين متعددة المواقع وتكوين كل وحدة بإعداد المنفذ والبروتوكول المعني لها.
يمكنك أيضًا تعريف أسماء مضيف حرف البدل في وحدة الاستماع متعددة المواقع وما قد يصل إلى 5 أسماء مضيف لكل وحدة استماع. لمعرفة المزيد، راجع أسماء مضيفي أحرف البدل في وحدة الاستماع.
لمزيدٍ من المعلومات حول كيفية تكوين مستمع متعددة المواقع، راجع استضافة مواقع متعددة في تطبيق البوابة باستخدام بوابة Azure.
بعد إنشاء مستمع يمكنك إقرانه مع قاعدة تحويل طلب. تحدد هذه القاعدة كيفية توجيه الطلب المستلم على المستمع إلى الخلفية. قاعدة توجيه الطلب تحتوي أيضًا على تجمع الخلفية لتحويلها إلى و HTTP الإعداد حيث يتم ذكر المنفذ الخلفية، البروتوكول، إلخ.
قواعد توجيه الطلبات
قاعدة توجيه الطلب هي مكون أساسي لبوابة التطبيق لأنه يحدد كيفية تحويل حركة المرور على المستمع. تربط القاعدة وحدة الاستماع وتجمع الخادم الخلفي وإعدادات HTTP الخلفية.
عندما يقبل المستمع طلبًا، فإن قاعدة توجيه الطلب تعيد توجيه الطلب إلى الواجهة الخلفية أو تعيد توجيهه إلى مكان آخر. إذا تمت إعادة توجيه الطلب إلى الواجهة الخلفية، فإن قاعدة توجيه الطلب تحدد تجمع خادم الواجهة الخلفية لإعادة توجيهه إليه. تحدد قاعدة تحويل الطلب أيضًا ما إذا كانت الرؤوس في الطلب ستتم إعادة كتابتها. يمكن إرفاق مستمع بقاعدة واحدة.
هناك نوعان من قواعد توجيه الطلب:
رئيسي. يتم إعادة توجيه كافة الطلبات للمستمع المقترنة (على سبيل المثال، blog.contoso.com/*) إلى تجمع الخلفية المقترنة باستخدام إعداد HTTP المقترنة.
مستند إلى المسار. تتيح لك قاعدة التحويل هذه توجيه الطلبات للمستمع المقترنة إلى تجمع نهاية خلفية محدد، استنادًا إلى عنوان URL في الطلب. إذا كان مسار URL في طلب يطابق نمط المسار في قاعدة تستند إلى مسار، فإن القاعدة توجه هذا الطلب. يطبق نمط المسار فقط على مسار URL، وليس على معلمات الاستعلام الخاصة به. إذا لم يتطابق مسار URL على طلب المستمع مع أي من القواعد المستندة إلى المسار، فإنه يقوم بتوجيه الطلب إلى تجمع الواجهة الخلفية الافتراضي وإعدادات HTTP.
الجدول التالي يقارن بين نوعي القواعد.
| نوع القاعدة | حالة الاستخدام | أساس التوجيه | الخلفيات المدعومة |
|---|---|---|---|
| أساسي | أرسل كل طلب يقبله المستمع إلى نفس التطبيق. | جميع الطلبات على المستمع المرتبط، على سبيل المثال blog.contoso.com/*. |
تجمع خلفي واحد مرتبط، يتم الوصول إليه باستخدام إعداد HTTP المرتبط. |
| المسار المعتمد | توجيه الطلبات التي تصل إلى مستمع واحد إلى تطبيقات مختلفة بناء على عنوان URL المطلوب. | مسار الرابط في الطلب. نمط المسار ينطبق فقط على مسار الرابط، وليس على معلمات الاستعلام الخاصة به. | تجمع خلفية محدد لكل نمط مسار متطابق، بالإضافة إلى تجمع خلفيات افتراضي وإعدادات HTTP للطلبات التي لا تتطابق مع أي قاعدة مبنية على المسار. |
لمزيدٍ من المعلومات، راجع نظرة عامة حول التوجيه المستند إلى مسار عنوان موقع ويب.
دعم إعادة التوجيه
قاعدة توجيه الطلب يسمح لك أيضًا بإعادة تحويل حركة المرور على بوابة التطبيق. هذه هي آلية إعادة توجيه عامة، بحيث يمكنك إعادة توجيه من وإلى أي منفذ تقوم بتعريفه باستخدام القواعد.
يمكنك اختيار هدف إعادة التوجيه ليكون مستمعًا آخر (والذي يمكن أن يساعد في تمكين HTTP التلقائي لإعادة توجيه HTTPS) أو موقع خارجي. يمكنك أيضًا اختيار أن تكون إعادة التوجيه مؤقتة أو دائمة، أو إلحاق مسار URI وسلسلة الاستعلام بعنوان URL المعاد توجيهه.
لمزيدٍ من المعلومات، راجع عمليات إعادة التوجيه في بوابة التطبيق.
إعادة كتابة عناوين HTTP وURL
يمكن لبوابة التطبيقات إضافة أو إزالة أو تحديث رؤوس طلبات واستجابة HTTP(S)، إلى جانب معلمات مسار الرابط وسلاسل الاستعلام، مع انتقال حركة المرور بين العملاء وتجمعات الخلفية. للحصول على شرح كامل وخطوات التكوين، راجع إعادة كتابة رؤوس HTTP وURL في بوابة التطبيق الخاصة بك.
إعدادات HTTP
إعداد HTTP، والذي يسمى أيضا إعداد الخلفية، هو التكوين الذي يحدد كيفية وصول حركة المرور إلى خوادم الخلفية. يحدد المنفذ والبروتوكول الذي تستخدمه بوابة التطبيق للاتصال بتلك الخوادم، وكيف تتصرف الاتصالات، وكيف تراقب البوابة صحة الواجهة الخلفية. تحدد قاعدة توجيه الطلبات أي إعداد HTTP يجب تطبيقه عند إعادة توجيه الطلب إلى مجموعة الخلفية الخلفية.
يحدد المنفذ والبروتوكول المستخدم في إعدادات HTTP ما إذا كان يتم تشفير حركة المرور بين بوابة التطبيق وملقمات الخلفية (توفير TLS من طرف إلى طرف) أو غير مشفرة.
يستخدم هذا المكون أيضًا في:
تحديد ما إذا كان سيتم الاحتفاظ جلسة عمل مستخدم على نفس الملقم باستخدام تقارب جلسة العمل المستندة إلى ملف تعريف الارتباط.
قم بإزالة أعضاء تجمع الخلفية بأمان باستخدام اتصال استنزاف.
إقران probe مخصص لمراقبة صحة الخلفية وتعيين الفاصل الزمني مهلة الطلب تجاوز اسم المضيف والمسار في الطلب وتوفير سهولة بنقرة واحدة لتحديد إعدادات الخلفية خدمة التطبيقات.
مجموعة خلفية
تجمع الخلفية التوجيهات طلب إلى ملقمات الخلفية التي تخدم الطلب. يمكن أن تحتوي تجمعات الخلفية على:
- بطاقات الكيانات
- مجموعات توسيع الجهاز الافتراضي
- عناوين IP العامة
- عناوين IP الداخلية
- FQDN (أسماء النطاقات المؤهلة بالكامل) أو الأسماء القصيرة (أسماء النطاقات ذات العلامة الواحدة)، بشرط أن يتمكن خادم DNS الخاص بك من حلها
- الخلفيات متعددة المستأجرين مثل "Azure App Service" وAzure Container Apps. راجع حماية تطبيقات الحاويات مع Application Gateway وWAF للحصول على إرشادات التنفيذ.
لا يتم ربط أعضاء تجمع الواجهة الخلفية لبوابة التطبيق بمجموعة توفر. طالما لديك اتصال IP، يمكن لبوابة التطبيق الاتصال بمثيلات خارج الشبكة الظاهرية التي توجد فيها. ونتيجة لذلك، يمكن أن يكون أعضاء تجمعات الخلفية عبر الكتل، عبر مراكز البيانات، أو خارج أزور، طالما هناك اتصال IP.
إذا كنت تخطط لاستخدام عناوين IP داخلية كأعضاء تجمع واجهات خلفية، فاستخدم الشبكة الظاهرية للتناظر أو Azure VPN Gateway. يتم دعم شبكة الاتصال الظاهرية النظير ومفيدة لحركة المرور موازنة التحميل في الشبكات الظاهرية الأخرى.
يمكن لبوابة التطبيق أيضا الاتصال بالخوادم المحلية عند توصيلها بواسطة أنفاق Azure ExpressRoute أو VPN إذا كان مسموحا بنسبة استخدام الشبكة.
يمكنك إنشاء تجمعات خلفية مختلفة لأنواع مختلفة من الطلبات. على سبيل المثال، إنشاء تجمع خلفية واحدة للطلبات العامة ثم تجمع خلفية أخرى للطلبات إلى microservices للتطبيق الخاص بك.
بعد إضافة مجموعات مقياس الجهاز الظاهري كعضو في تجمع الخلفية، تحتاج إلى ترقية مثيلات مجموعات مقياس الجهاز الظاهري. حتى تقوم بترقية مثيلات مجموعات المقياس، ستكون الخلفية غير سليمة.
تحقيقات الصحة
بشكل افتراضي، بوابة التطبيق تراقب صحة كافة الموارد في تجمع الخلفية الخاص بها وتزيل تلقائيًا غير الصحية. ثم تراقب المثيلات غير الصحية وتضيفهم إلى تجمع الخلفية الصحية عند توافرهم وتستجيب للفحوصات الصحية.
بالإضافة إلى استخدام مراقبة التحقيق الصحي الافتراضي، يمكنك أيضًا تخصيص التحقيق الصحي ليناسب متطلبات التطبيق الخاص بك. يسمح التحقق المخصص بالتحكم في المراقبة الصحية. عند استخدام تحقيقات مخصصة، يمكنك تكوين اسم مضيف مخصص ومسار URL والفاصل الزمني للتحقيق وعدد الاستجابات الفاشلة التي يجب قبولها قبل وضع علامة على مثيل تجمع الواجهة الخلفية كرموز حالة مخصصة وغير سليمة ومطابقة نص الاستجابة وما إلى ذلك. نوصي بتكوين تحقيقات مخصصة لمراقبة صحة كل تجمع خلفية.
إشعار
بالنسبة لمجسات الصحة الخاصة ب HTTPS على Application Gateway v2، عند تفعيل التحقق من صحة اسم موضوع الشهادة، يجب أن يتطابق اسم المضيف SNI المستخدم من قبل المسبار مع اسم بديل للموضوع (SAN) في شهادة TLS الخلفية، أو اسمه الشائع (CN) إذا لم يكن هناك SAN موجود. قبل أن تضبط المسبار، راجع سلوك مؤشر اسم الخادم (SNI) لحركة مرور المجس. إذا أبلغت Backend Health عن عدم تطابق اسم الشهادة، اتبع الإرشادات الخاصة بالتكوين في Common Name (CN) لا يتطابق. تشمل هذه الإرشادات خيار تجاوز اسم المضيف .
لمزيدٍ من المعلومات، راجع عمليات إعادة التوجيه في بوابة التطبيق.
الخطوات التالية
أنشئ بوابة تطبيق.