ميزات شبكة خدمة التطبيقات
يمكنك توزيع التطبيقات في خدمة تطبيقات Azure بطرق متعددة. بشكل افتراضي، يمكن الوصول إلى التطبيقات المستضافة في App Service مباشرة من خلال الإنترنت ويمكن أن تصل إلى نقاط النهاية المستضافة عبر الإنترنت فقط. بالنسبة للعديد من التطبيقات، تحتاج إلى التحكم في نسبة استخدام الشبكة الواردة والصادرة. يوجد العديد من الميزات في App Service لمساعدتك على تلبية هذه الاحتياجات. التحدي هو معرفة أي ميزة لاستخدامها لحل مشكلة معينة. استخدم هذه المقالة لمساعدتك في تحديد الميزة التي يجب استخدامها، استنادا إلى حالات الاستخدام على سبيل المثال.
يوجد نوعان رئيسيان من النشر لخدمة تطبيقات Azure:
- تستضيف الخدمة العامة متعددة المستأجرين خطط App Service في وحدات حفظ المخزون المجانية والمشتركة والأساسية والقياسية والمتميزة والمتميزة من الفئة 2 والمتميزة من الفئة 3.
- يوجد أيضًا بيئة App Service (ASE) المستأجرة الفردية التي تستضيف خطط App Service لوحدة حفظ المخزون المعزولة مباشرة في شبكة Azure الظاهرية.
تعتمد الميزات التي تستخدمها على ما إذا كنت في الخدمة متعددة المستأجرين أو في ASE.
إشعار
ميزات شبكات App Service متعددة المستأجرين
خدمة Azure App Service هي نظام موزع. تسمى الأدوار التي تعالج طلبات HTTP أو HTTPS الواردة الواجهات الأمامية. تسمى الأدوار التي تستضيف حمل عمل العميل العمال. توجد كافة الأدوار في توزيع App Service في شبكة متعددة المستأجرين. نظراً لوجود العديد من العملاء المختلفين في الخوادم المخصصة لخدمة App Service نفسها، لا يمكنك توصيل شبكة خدمة App Service مباشرة بالشبكة الخاصة بك.
بدلاً من الاتصال بالشبكات، تحتاج إلى ميزات للتعامل مع مختلف جوانب الاتصال بالتطبيق. لا يمكن استخدام الميزات التي تتعامل مع الطلبات إلى تطبيقك لحل المشكلات عند إجراء مكالمات من تطبيقك. وبالمثل، لا يمكن استخدام الميزات التي تحل مشكلات المكالمات من التطبيق لحل المشكلات في تطبيقك.
الميزات الواردة | الميزات الصادرة |
---|---|
عنوان معين بواسطة التطبيق | اتصالات مختلطة |
قيود الوصول | تكامل الشبكة الظاهرية المطلوب من البوابة |
نقاط نهاية الخدمة | تكامل الشبكة الظاهرية |
نقاط النهاية الخاصة |
بخلاف الاستثناءات المذكورة، يمكنك استخدام كافة الميزات معًا. يمكنك المزج بين الميزات لحل مشاكلك.
استخدام الحالات والميزات
بالنسبة إلى أي حالة استخدام معينة، تكون هناك بعض الطرق لحل المشكلة. يتجاوز اختيار أفضل ميزة في بعض الأحيان حالة الاستخدام نفسها. تقترح الحالات الخاصة بالاستخدام الوارد التالية كيفية استخدام ميزات شبكة خدمة التطبيقات لحل المشاكل المتعلقة بالتحكم في نسبة استخدام الشبكة التي تذهب إلى تطبيقك:
حالة الاستخدام الواردة | ميزة |
---|---|
دعم احتياجات SSL المستندة إلى بروتوكول الإنترنت لتطبيقك | عنوان معين بواسطة التطبيق |
دعم عنوان وارد مخصص غير مشترك لتطبيقك | عنوان معين بواسطة التطبيق |
تقييد الوصول إلى تطبيقك من مجموعة من العناوين المحددة جيداً | قيود الوصول |
تقييد الوصول إلى التطبيق الخاص بك من الموارد الموجودة في شبكة ظاهرية | نقاط تقديم الخدمة نقاط النهاية الخاصة لموازن التحميل الداخلي (ILB) ASE |
الكشف عن التطبيق الخاص بك على IP خاص في شبكتك الظاهرية | ILB ASE نقطة النهاية الخاصة IP لنسبة استخدام الشبكة الواردة على مثيل بوابة التطبيق مع نقاط نهاية الخدمة |
حماية التطبيق باستخدام جدار حماية تطبيق ويب (WAF) | Application Gateway وILB ASE Application Gateway مع نقاط النهاية الخاصة Application Gateway مع نقاط نهاية الموفر Azure Front Door مع قيود الوصول |
تحميل نسبة استخدام الشبكة إلى التطبيقات الخاصة بك في مناطق مختلفة | Azure Front Door مزودة بقيود الوصول |
نسبة استخدام الشبكة لموازنة التحميل في نفس المنطقة | Application Gateway مع نقاط نهاية الخدمة |
تشير حالات الاستخدام الصادرة التالية إلى كيفية استخدام ميزات شبكة App Service لحل احتياجات الوصول الصادر للتطبيق الخاص بك:
حالة الاستخدام الصادر | ميزة |
---|---|
الوصول إلى الموارد في شبكة اتصال ظاهرية Azure في نفس المنطقة | تكامل الشبكة الظاهرية ASE |
الوصول إلى الموارد في شبكة اتصال ظاهرية Azure في منطقة مختلفة | تكامل الشبكة الظاهرية والشبكة الظاهرية النظيرة تكامل الشبكة الافتراضية المطلوبة من البوابة الشبكة الظاهرية المطلوبة ASE ونظير الشبكة الظاهرية |
الوصول إلى الموارد المؤمنة باستخدام نقاط نهاية الموفر | تكامل الشبكة الظاهرية ASE |
الوصول إلى الموارد في الشبكة الخاصة غير متصلة بـ Azure | اتصالات مختلطة |
الوصول إلى الموارد عبر دوائر تطبيق Azure ExpressRoute | تكامل الشبكة الظاهرية ASE |
تأمين نسبة استخدام الشبكة الصادرة من تطبيق الويب الخاص بك | تكامل الشبكة الظاهرية ومجموعات الأمان الخاص بشبكة ASE |
توجيه نسبة استخدام الشبكة الصادرة من تطبيق الويب الخاص بك | تكامل الشبكة الظاهرية وجداول التوجيه ASE |
سلوك الشبكات الافتراضي
تدعم الخوادم المخصصة لخدمة Azure App Service العديد من العملاء في كل عملية توزيع. تستضيف خطط SKU المجانية والمشتركة أحمال عمل العملاء على العمال متعددي المستأجرين. تستضيف الخطط الأساسية والأعلى أحمال عمل العملاء المخصصة لخطة App Service واحدة فقط. إذا كانت لديك خطة Standard App Service، فإن جميع التطبيقات في تلك الخطة تعمل على نفس العامل. إذا قمت بتوسيع نطاق العامل، يتم نسخ جميع التطبيقات الموجودة في خطة App Service هذه على عامل جديد لكل مثيل في خطة App Service.
العناوين الصادرة
يتم تقسيم الأجهزة الظاهرية العاملة في جزء كبير من خطط App Service. تستخدم الخطط المجانية والمشتركة والأساسية والقياسية والمميزة نفس نوع الجهاز الظاهري للعامل. تستخدم خطة PremiumV2 نوع جهاز ظاهري آخر. يستخدم PremiumV3 نوع جهاز ظاهري آخر.
عند تغيير عائلة الجهاز الظاهري، تحصل على مجموعة مختلفة من العناوين الصادرة. إذا قمت بالتحجيم من Standard إلى PremiumV2، فستتغير عناوينك الصادرة. إذا قمت بالتحجيم من PremiumV2 إلى PremiumV3، فستتغير عناوينك الصادرة. في بعض وحدات المقياس القديمة، تتغير كل من العناوين الواردة والصادرة عند التحجيم من Standard إلى PremiumV2.
هناك العناوين متعددة يتم استخدامها للمكالمات الصادرة. يتم سرد العناوين الصادرة المستخدمة من قبل تطبيقك لإجراء المكالمات الصادرة في خصائص التطبيق الخاص بك. تشترك جميع التطبيقات التي تعمل على نفس عائلة الجهاز الظاهري العامل في نشر App Service في هذه العناوين. إذا كنت تريد رؤية جميع العناوين التي قد يستخدمها تطبيقك في وحدة مقياس، فهناك خاصية تسمى possibleOutboundAddresses
تسردها.
تحتوي App Service على نقاط نهاية خدمة مستخدمة متعددة لإدارة الخدمة. نشر العناوين في مستند منفصل وهي أيضًا في AppServiceManagement
علامة خدمة IP. استخدام العلامة AppServiceManagement
فقط في App Service Environments حيث تحتاج إلى السماح بنسبة استخدام الشبكة هذه. تتبع عناوين App Service الواردة AppService
في علامة خدمة IP. لا توجد علامة خدمة IP تحتوي على العناوين الصادرة المستخدمة من قبل خدمة التطبيقات.
عنوان معين بواسطة التطبيق
ميزة العنوان المعين من قبل التطبيق هي فرع من إمكانية SSL المستندة إلى IP. للوصول إليه، قم بإعداد SSL باستخدام تطبيقك. يمكنك استخدام الميزة لمكالمات SSL المستندة إلى IP. يمكنك أيضًا استخدامه لإعطاء التطبيق عنوانًا يحتوي عليه فقط.
عند استخدام عنوان معين من قِبل التطبيق، لا تزال نسبة استخدام الشبكة الخاصة بك تمر بنفس الأدوار الأمامية التي تتعامل مع جميع الزيارات الواردة إلى وحدة مقياس خدمة التطبيقات. لا يستخدم التطبيق العنوان الذي تم تعيينه لتطبيقك إلا. الحالات المستخدمة لهذه الميزة:
- دعم احتياجات SSL المعتمدة على بروتوكول الإنترنت للتطبيق الخاص بك.
- عين عنوان مخصص لتطبيقك غير مشترك.
لمعرفة كيفية تعيين عنوان على التطبيق، راجع إضافة شهادة TLS/SSL في خدمة تطبيقات Azure.
قيود الوصول
تسمح لك قيود الوصول بتصفية الطلبات الواردة. يتم إجراء التصفية على أدوار الواجهة الأمامية المصدر من أدوار العامل حيث يتم تشغيل تطبيقاتك. نظرًا إلى أن أدوار الواجهة الأمامية هي في المنبع من العمال، يمكنك التفكير في قيود الوصول كحماية على مستوى الشبكة لتطبيقاتك. لمزيد من المعلومات، راجع قيود الوصول إلى Azure App Service.
تسمح لك الميزة بإنشاء قائمة السماح ورفض القواعد التي يتم تقييمها بترتيب الأولوية. وهي مشابهة لميزة مجموعة أمان الشبكة (NSG) في شبكة Azure. يمكنك استخدام هذه الميزة في ASE أو في الخدمة متعددة المستأجرين. عند استخدامه مع ASE ILB يمكنك تقييد الوصول من كتل العناوين الخاصة. لمزيد من المعلومات، راجع إعداد قيود الوصول إلى Azure App Service.
إشعار
يمكنك تكوين ما يصل إلى 512 قاعدة تقييد وصول لكل تطبيق.
نقطة النهاية الخاصة
نقطة النهاية الخاصة هي واجهة شبكة اتصال تربطك بشكل خاص وآمن بتطبيق الويب الخاص بك بواسطة ارتباط Azure الخاص. تستخدم نقطة النهاية الخاصة بعنوان IP خاص من شبكتك الافتراضية، ما يؤدي إلى إدخال تطبيق الويب بشكل فعال إلى شبكتك الافتراضية. هذه الميزة هي فقط للتدفقات الواردة إلى تطبيق الويب الخاص بك. لمزيد من المعلومات، راجع استخدام نقاط النهاية الخاصة لتطبيقات App Service.
بعض الحالات المستخدمة لهذه الميزة:
- تقييد الوصول إلى التطبيق من الموارد الموجودة في شبكة افتراضية.
- كشف التطبيق الخاص بك على IP خاص في الشبكة الافتراضية الخاصة بك.
- حماية التطبيق الخاص بك مع WAF.
تمنع نقاط النهاية الخاصة النقل غير المصرح للبيانات. الشيء الوحيد الذي يمكنك الوصول إليه عبر نقطة النهاية الخاصة هو التطبيق الذي تم تكوينه به.
محيط أمان الشبكة
Azure Network Security Perimeter (NSP) هي خدمة توفر محيطا آمنا للاتصال بخدمات النظام الأساسي كخدمة (PaaS). يمكن لخدمات PaaS هذه التواصل مع بعضها البعض داخل المحيط. يمكنهم أيضا الاتصال بالموارد خارج المحيط باستخدام قواعد الوصول العامة الواردة والصادرة.
يستخدم فرض قاعدة NSP بشكل أساسي الأمان المستند إلى الهوية. لا يمكن فرض هذا الأسلوب بالكامل في خدمات النظام الأساسي مثل App Services و Functions التي تسمح لك بنشر التعليمات البرمجية الخاصة بك واستخدام الهوية لتمثيل النظام الأساسي. إذا كنت بحاجة إلى الاتصال بخدمات PaaS التي تعد جزءا من NSP، أضف تكامل الشبكة الظاهرية إلى مثيلات App Service أو Functions. التواصل مع موارد PaaS باستخدام نقاط النهاية الخاصة.
اتصالات مختلطة
تمكن اتصالات المختلط لخدمة التطبيقات تطبيقاتك من إجراء مكالمات صادرة إلى نقاط نهاية TCP محددة. يمكن أن تكون نقطة النهاية محلية أو في شبكة ظاهرية أو في أي مكان يسمح نسبة استخدام الشبكة الصادرة إلى Azure على المنفذ 443. لاستخدام الميزة، تحتاج إلى تثبيت عامل ترحيل يسمى إدارة الاتصال المختلط على مضيف Windows Server 2012 أو أحدث. إدارة الاتصال المختلط يحتاج إلى أن تكون قادرة على الوصول إلى Azure ترحيل في المنفذ 443. يمكنك تنزيل إدارة الاتصال المختلط من واجهة مستخدم الاتصالات المختلطة لخدمة التطبيقات في المدخل.
إنشاء App Service Hybrid Connections على إمكانية Azure Relay Hybrid Connections. تستخدم خدمة التطبيقات شكلاً متخصصًا من الميزة يدعم فقط إجراء مكالمات صادرة من تطبيقك إلى مضيف ومنفذ TCP. يحتاج المضيف والمنفذ فقط إلى حل على المضيف حيث يتم تثبيت إدارة الاتصال المختلط.
عندما يقوم التطبيق، في خدمة التطبيقات، بالبحث عن DNS على المضيف والمنفذ المحدد في الاتصال المختلط، فإن نسبة استخدام الشبكة تعيد توجيهها تلقائيا للانتقال عبر الاتصال المختلط والخروج من إدارة الاتصال المختلط. لمزيد من المعلومات، راجع App Service Hybrid Connections.
تستخدم الميزة بشكل شائع لـ:
- الوصول إلى الموارد في الشبكات الخاصة غير المتصلة بـ Azure باستخدام VPN أو ExpressRoute.
- دعم ترحيل التطبيقات المحلية إلى App Service دون الحاجة إلى نقل قواعد البيانات المدعمة.
- توفير الوصول مع الأمان المحسن إلى مضيف واحد ومنفذ لكل اتصال مختلط. معظم ميزات شبكة الاتصال فتح الوصول إلى شبكة اتصال. باستخدام الاتصالات المختلطة، يمكنك الوصول إلى المضيف والمنفذ الفرديين فقط.
- تغطية سيناريوهات غير مشمولة بطرق الاتصال الصادرة الأخرى.
- إجراء التطوير في خدمة التطبيقات بطريقة تسمح للتطبيقات باستخدام الموارد المحلية بسهولة.
نظرًا إلى أن الميزة تمكن الوصول إلى الموارد المحلية دون وجود ثقب جدار حماية وارد، فهي شائعة لدى المطورين. ترتبط ميزات شبكة خدمة التطبيقات الصادرة الأخرى بالشبكة الظاهرية Azure. لا تعتمد الاتصالات المختلطة على الانتقال عبر شبكة افتراضية. يمكن استخدامه لمجموعة متنوعة من احتياجات الشبكات.
اتصالات خدمة التطبيقات المختلطة غير مدركة لما تقوم به على رأسها. يمكنك استخدامه للوصول إلى قاعدة بيانات أو خدمة ويب أو مأخذ توصيل TCP عشوائي على الكمبيوتر المركزي. الميزة بشكل أساسي أنفاق حزم TCP.
الاتصالات المختلطة شائعة للتطوير. يمكنك أيضا استخدامه في تطبيقات الإنتاج. إنه أمر رائع للوصول إلى خدمة ويب أو قاعدة بيانات، ولكنه ليس مناسبًا للحالات التي تنطوي على إنشاء العديد من الاتصالات.
تكامل الشبكة الظاهرية
يتيح تكامل الشبكة الظاهرية ل App Service لتطبيقك إجراء طلبات صادرة إلى شبكة Azure الظاهرية.
تمكنك ميزة تكامل الشبكة الظاهرية من وضع النهاية الخلفية لتطبيقك في شبكة فرعية في شبكة ظاهرية ل Resource Manager. يجب أن تكون الشبكة الظاهرية في نفس منطقة تطبيقك. لا تتوفر الميزة من بيئة خدمة التطبيقات الموجودة بالفعل في شبكة افتراضية. الحالات المستخدمة لهذه الميزة:
- الوصول إلى الموارد في الشبكات الظاهرية إدارة الموارد في نفس المنطقة.
- الوصول إلى الموارد في شبكات الاتصال الظاهرية النظيرة، بما في ذلك اتصالات المنطقة المشتركة.
- الوصول إلى الموارد التي تم تأمينها باستخدام نقاط نهاية الخدمة.
- الوصول إلى الموارد التي يمكن الوصول إليها من خلال اتصالات ExpressRoute أو VPN.
- الوصول إلى الموارد في الشبكات الخاصة دون الحاجة إلى بوابة شبكة ظاهرية وتكلفتها.
- مساعدة لتأمين جميع نسبة استخدام الشبكة الصادرة.
- فرض نفق جميع نسب استخدام الشبكة الصادرة.
لمعرفة المزيد، راجع pp Service virtual network integration.
تكامل الشبكة الظاهرية المطلوب من البوابة
كان تكامل الشبكة الظاهرية المطلوبة من البوابة هو الإصدار الأول من تكامل الشبكة الظاهرية في App Service. تستخدم الميزة VPN من نقطة إلى موقع لتوصيل المضيف الذي يعمل عليه تطبيقك ببوابة شبكة ظاهرية على شبكتك الظاهرية. عند تكوين الميزة، يحصل تطبيقك على أحد العناوين المعينة من نقطة إلى موقع المعينة لكل مثيل.
يسمح لك التكامل المطلوب للبوابة بالاتصال مباشرة بشبكة ظاهرية في منطقة أخرى دون نظير والاتصال بشبكة ظاهرية كلاسيكية. تقتصر الميزة على خطط App Service Windows ولا تعمل مع الشبكات الظاهرية المتصلة ب ExpressRoute. نوصي باستخدام تكامل الشبكة الظاهرية الإقليمية. لمزيد من المعلومات، راجع تكوين تكامل الشبكة الظاهرية المطلوبة من البوابة.
بيئة خدمة التطبيق
بيئة خدمة التطبيقات (ASE) هي توزيع مستأجر واحد لخدمة تطبيقات Azure التي يتم تشغيلها في الشبكة الظاهرية. بعض الحالات مثل لهذه الميزة:
- الوصول إلى الموارد في الشبكة الظاهرية.
- الوصول إلى الموارد من خلال ExpressRoute.
- كشف التطبيقات الخاصة بك باستخدام عنوان خاص في الشبكة الظاهرية.
- الوصول إلى الموارد من خلال نقاط نهاية الخدمة.
- الوصول إلى الموارد من خلال نقاط النهاية الخاصة.
باستخدام ASE، لا تحتاج إلى استخدام تكامل الشبكة الظاهرية لأن ASE موجود بالفعل في الشبكة الظاهرية الخاصة بك. إذا كنت ترغب في الوصول إلى موارد مثل SQL أو تخزين Azure من خلال نقاط نهاية الخدمة، فقم بتمكين نقاط نهاية الخدمة على الشبكة الفرعية ASE. إذا كنت تريد في الوصول إلى الموارد في الشبكة الظاهرية أو نقاط النهاية الخاصة في الشبكة الظاهرية، فلن تحتاج إلى إجراء أي تكوين إضافي. إذا كنت ترغب في الوصول إلى الموارد عبر ExpressRoute، فأنت موجود بالفعل في الشبكة الافتراضية ولا تحتاج إلى تكوين أي شيء على ASE أو التطبيقات الموجودة فيه.
نظرا لأنه يمكن عرض التطبيقات في ILB ASE على عنوان IP خاص، يمكنك إضافة أجهزة WAF لعرض بعض التطبيقات فقط على الإنترنت. عدم الكشف عن الآخرين يساعد على الحفاظ على أمان الباقي. يمكن أن تساعد الميزة في تسهيل تطوير التطبيقات متعددة المستويات.
بعض الأشياء غير ممكنة حاليا من الخدمة متعددة المستأجرين ولكنها ممكنة من ASE. إليك بعض الأمثلة:
- استضافة تطبيقاتك في خدمة مستأجر واحد.
- قم بتوسيع نطاق إلى العديد من المثيلات أكثر مما هو ممكن في الخدمة متعددة المستأجرين.
- تحميل شهادات العميل المرجع المصدق الخاص للاستخدام من قبل التطبيقات الخاصة بك مع نقاط النهاية الخاصة CA المضمون.
- فرض TLS 1.2 عبر جميع التطبيقات المستضافة في النظام دون أي قدرة على تعطيله على مستوى التطبيق.
يوفر ASE أفضل قصة حول استضافة التطبيقات المعزولة والمخصصة. ويشمل هذا النهج بعض التحديات الإدارية. بعض الأشياء التي يتعين مراعاتها قبل استخدام ASE تشغيلي:
- يتم تشغيل ASE داخل شبكتك الظاهرية، ولكن لها تبعيات خارج الشبكة الظاهرية. يتعين السماح بتلك التبعيات. لمزيد من المعلومات، راجع اعتبارات شبكة الاتصال لبيئة خدمة التطبيقات.
- لا يتم قياس ASE على الفور مثل الخدمة متعددة المستأجرين. تحتاج إلى توقع احتياجات التحجيم بدلا من التحجيم التفاعلي.
- لدى ASE تكلفة أعلى مقدما. للحصول على أقصى استفادة من ASE الخاصة بك، يجب أن تخطط لوضع العديد من أعباء العمل في ASE واحدة بدلاً من استخدامها في جهود صغيرة.
- لا يمكن للتطبيقات في ASE تقييد الوصول إلى بعض التطبيقات في ASE بشكل انتقائي وليس غيرها.
- ASE في شبكة فرعية. تنطبق أي قواعد شبكة على جميع نسبة استخدام الشبكة من وإلى ASE. إذا كنت ترغب في تعيين قواعد نسبة استخدام الشبكة الواردة لتطبيق واحد فقط، فاستخدم قيود الوصول.
التجميع بين الميزات
يمكن استخدام الميزات المذكورة للخدمة متعددة المستأجرين معا لحل حالات الاستخدام الأكثر تفصيلا. يتم وصف اثنتين من حالات الاستخدام الأكثر شيوعا هنا كأمثلة. فهم ما تفعله من خلال الميزات المختلفة، يمكنك تلبية جميع احتياجات بنية النظام تقريبًا.
وضع التطبيق في الشبكة الافتراضية
تتساءل عن كيفية وضع تطبيق في شبكة افتراضية. إذا وضعت التطبيق الخاص بك في شبكة افتراضية، فإن نقاط النهاية الواردة والصادرة للتطبيق موجودة داخل الشبكة الظاهرية. ASE هو أفضل وسيلة لحل المشكلة. ولكن يمكنك تلبية معظم احتياجاتك داخل الخدمة متعددة المستأجرين من خلال الجمع بين الميزات. على سبيل المثال، يمكنك استضافة تطبيقات إنترنت فقط مع عناوين واردة وصادرة خاصة بواسطة:
- إنشاء مدخل تطبيق مع عناوين واردة وصادرة خاصة.
- تأمين نسبة استخدام الشبكة الواردة إلى التطبيق الخاص بك باستخدام نقاط نهاية الخدمة.
- استخدام ميزة تكامل الشبكة الظاهرية بحيث تكون النهاية الخلفية للتطبيق الخاص بك في شبكتك الظاهرية.
لا يمنحك نمط النشر هذا عنوانا مخصصا لنسبة استخدام الشبكة الصادرة إلى الإنترنت أو القدرة على تأمين كل نسبة استخدام الشبكة الصادرة من تطبيقك. فهو يمنحك الكثير مما كنت ستحصل عليه فقط بخلاف ذلك باستخدام ASE.
إنشاء تطبيقات متعددة المستويات
التطبيق ذو المستويات المتعددة هو تطبيق يمكن فيه الوصول إلى تطبيقات واجهة برمجة التطبيقات الخلفية فقط من مستوى الواجهة الأمامية. يوجد طريقتان لإنشاء تطبيق متعدد المستويات. يبدأ كلاهما باستخدام تكامل الشبكة الظاهرية لتوصيل التطبيق الخاص بالويب الأمامي بشبكة فرعية في شبكة ظاهرية. يؤدي القيام بذلك إلى تمكين تطبيق الويب الخاص بك من إجراء مكالمات إلى شبكتك الظاهرية. بعد توصيل تطبيق الواجهة الأمامية بالشبكة الظاهرية، حدد كيفية تأمين الوصول إلى تطبيق API الخاص بك. يمكنك:
- استضافة كل من الواجهة الأمامية والتطبيق API في نفس ASE ILB، وفضح التطبيق الأمامي إلى الإنترنت باستخدام بوابة التطبيق.
- استضافة الواجهة الأمامية في الخدمة متعددة المستأجرين والنهاية الخلفية في ILB ASE.
- استضافة كل من الواجهة الأمامية وواجهة برمجة التطبيقات في الخدمة متعددة المستأجرين.
إذا كنت تستضيف كلاً من الواجهة الأمامية وتطبيق واجهة برمجة التطبيقات لتطبيق متعدد المستويات، بإمكانك:
كشف تطبيق API الخاص بك باستخدام نقاط نهاية الخدمة الخاصة في شبكتك الظاهرية:
استخدم نقاط نهاية الخدمة لضمان أن نسبة استخدام الشبكة الواردة إلى تطبيق واجهة برمجة التطبيقات تأتي فقط من الشبكة الفرعية المستخدمة من قبل تطبيق الويب الأمامي:
فيما يلي بعض الاعتبارات لمساعدتك في تحديد الطريقة التي يتعين استخدامها:
- عند استخدام نقاط نهاية الخدمة، تحتاج فقط إلى تأمين نسبة استخدام الشبكة إلى تطبيق API إلى الشبكة الفرعية للتكامل. تساعد نقاط نهاية الخدمة على تأمين تطبيق واجهة برمجة التطبيقات، ولكن لا يزال بإمكانك الحصول على بيانات غير مصرح بها من تطبيق الواجهة الأمامية إلى تطبيقات أخرى في خدمة التطبيق.
- عند استخدام نقاط النهاية الخاصة، يكون لديك اثنتان من الشبكات الفرعية في اللعب، الأمر الذي يضيف التعقيد. نقطة النهاية الخاصة مورد المستوى الأعلى ثم يضيف مقدار الحمل الإدارة أيضا. الفائدة من استخدام نقاط النهاية الخاصة هي أنه ليس لديك إمكانية تسرب البيانات.
يعمل أي من الأسلوبين مع عدة نهايات أمامية. على نطاق صغير، نقاط نهاية الخدمة أسهل في الاستخدام لأنك ببساطة تمكن نقاط نهاية الخدمة لتطبيق API على الشبكة الفرعية للتكامل الأمامي. عند إضافة المزيد من التطبيقات الأمامية، تحتاج إلى ضبط كل تطبيق API لتضمين نقاط نهاية الخدمة مع الشبكة الفرعية للتكامل. عند استخدام نقاط النهاية الخاصة، يوجد تعقيد أكبر، ولكن ليس عليك تغيير أي شيء على تطبيقات API بعد تعيين نقطة نهاية خاصة.
تطبيقات خط الأعمال
تطبيقات خط العمل (LOB) تعتبر تطبيقات داخلية لا يتم عرضها عادة للوصول من الإنترنت. استدعاء التطبيقات من داخل شبكات الشركات حيث يمكن التحكم في الوصول بدقة. إذا كنت تستخدم ILB ASE، فمن السهل استضافة تطبيقات خط الأعمال الخاصة بك. إذا كنت تستخدم الخدمة متعددة المستأجرين، يمكنك إما استخدام نقاط نهاية خاصة أو استخدام نقاط نهاية الخدمة جنبا إلى جنب مع بوابة تطبيق. يوجد سببان لاستخدام عبارة تطبيق مع نقاط نهاية الخدمة بدلاً من استخدام نقاط النهاية الخاصة:
- ستحتاج إلى حماية WAF على تطبيقات LOB الخاصة بك.
- تريد تحميل الرصيد إلى مثيلات متعددة لتطبيقات LOB.
إذا لم يتم تطبيق أي من الاحتياجات، فمن الأفضل لك استخدام نقاط النهاية الخاصة. باستخدام نقاط النهاية الخاصة المتوفرة في خدمة التطبيقات، يمكنك عرض تطبيقاتك على عناوين خاصة في الشبكة الظاهرية. يمكن الوصول إلى نقطة النهاية الخاصة التي تضعها في الشبكة الظاهرية عبر اتصالات ExpressRoute وVPN.
يؤدي تكوين نقاط النهاية الخاصة إلى عرض تطبيقاتك على عنوان خاص. تحتاج إلى تكوين DNS للوصول إلى هذا العنوان من أماكن العمل. لجعل هذا التكوين يعمل، أعد توجيه المنطقة الخاصة ل Azure DNS التي تحتوي على نقاط النهاية الخاصة بك إلى خوادم DNS المحلية. لا تدعم المناطق الخاصة ل Azure DNS إعادة توجيه المنطقة، ولكن يمكنك دعم إعادة توجيه المنطقة باستخدام محلل Azure DNS الخاص.
منافذ خدمة التطبيقات
إذا قمت بمسح App Service ضوئيا، فستجد العديد من المنافذ التي يتم عرضها للاتصالات الواردة. لا توجد طريقة لحظر أو التحكم في الوصول إلى هذه المنافذ في الخدمة متعددة المستأجرين. فيما يلي قائمة المنافذ المكشوفة:
استخدام | المنفذ أو المنافذ |
---|---|
HTTP/HTTPS | 80, 443 |
الإدارة | 454، 455 |
FTP/FTPS | 21، 990، 10001-10300 |
Visual Studio المتعلق بتصحيح الأخطاء عن بعد | 4020، 4022، 4024 |
خدمة توزيع ويب | 8172 |
استخدام البنية الأساسية | 7654, 1221 |