توزيع المؤسسة باستخدام Azure App Service Environment

توضح هذه البنية المرجعية حمل عمل المؤسسة الشائع الذي يستخدم الإصدار 3 من App Service Environment. كما يصف أفضل الممارسات لتعزيز أمن عبء العمل.

يتوفر تنفيذ مرجعي لهذه البنية على GitHub.

بناء الأنظمة

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

يوفر الإصدار 3 من App Service Environment ميزات مختلفة عن الإصدارات السابقة، ومزايا مقارنة بتلك الإصدارات. لمزيد من المعلومات، راجع اختلافات الميزات. يمكنك نشر App Service Environment بطريقتين:

• كبيئة خدمة تطبيقات خارجية مع عنوان IP عام
• كبيئة App Service داخلية مع عنوان IP داخلي ينتمي إلى موازن التحميل الداخلي (ILB)

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

• استضافة تطبيقات الإنترانت مع أمان محسن في السحابة، والوصول إليها عبر VPN من موقع إلى موقع أو Azure ExpressRoute.
• توفير طبقة من الحماية للتطبيقات باستخدام جدار حماية تطبيق ويب (WAF).
• استضف التطبيقات في السحابة غير المدرجة في خوادم DNS العامة.
• إنشاء تطبيقات خلفية معزولة عبر الإنترنت، والتي يمكن أن تتكامل معها تطبيقات الواجهة الأمامية بطريقة آمنة للغاية.

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

يسمح تطبيق التصويت البسيط في هذا التنفيذ للمستخدمين بعرض الإدخالات الموجودة وإنشاء إدخالات جديدة والتصويت على الإدخالات الموجودة. تُستخدم واجهة برمجة تطبيقات الويب لإنشاء واسترداد الإدخالات والتصويت. تُخزن البيانات نفسها في قاعدة بيانات SQL Server. لعرض تحديثات البيانات غير المتزامنة، يقوم تطبيق الويب بقوائم انتظار التصويت المضافة حديثًا في مثيل ناقل خدمة Microsoft Azure. تلتقط الدالة التصويتات المدرجة في قائمة الانتظار وتحدث قاعدة بيانات SQL. يتم استخدام Azure Cosmos DB لتخزين الإعلان الوهمي، الذي يسترده تطبيق الويب لعرضه على المتصفح. يستخدم التطبيق ذاكرة التخزين المؤقت Azure لـ Redis لإدارة ذاكرة التخزين المؤقت. يتم استخدام Azure Cache for Redis من المستوى المتميز، والذي يسمح بالتكوين لنفس الشبكة الظاهرية مثل App Service Environment، في شبكتها الفرعية الخاصة. يوفر ذلك أمانًا وعزلاً محسَّنين لذاكرة التخزين المؤقت.

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

المكونات

الخدمات التالية هي المفتاح لتأمين بيئة خدمة التطبيقات في هذه البنية:

• شبكة Azure الظاهرية هي شبكة سحابة Azure خاصة مملوكة لمؤسسة. ويوفر أمانا وعزلا محسنين قائمين على الشبكة. App Service Environment هو توزيع App Service في شبكة فرعية للشبكة الظاهرية المملوكة للمؤسسة. يسمح للمؤسسة بالتحكم بإحكام في مساحة الشبكة والموارد التي تصل إليها باستخدام مجموعات أمان الشبكة ونقاط النهاية الخاصة.

• بوابة التطبيق هي موازن تحميل حركة مرور الويب على مستوى التطبيق مع تفريغ TLS/SSL وWAF. يستمع إلى عنوان IP عام ويوجه حركة المرور إلى نقطة نهاية التطبيق في بيئة خدمة تطبيق ILB. نظرا لأن هذا هو التوجيه على مستوى التطبيق، فإنه يمكن توجيه حركة المرور إلى تطبيقات متعددة داخل نفس بيئة خدمة تطبيق ILB. لمزيد من المعلومات، راجع استضافة مواقع متعددة باستخدام بوابة التطبيق.

• Azure Firewall يُستخدم لتقييد نسبة استخدام الشبكة الصادرة من تطبيق الويب. يتم توجيه نسبة استخدام الشبكة الصادرة التي لا تمر عبر قنوات نقطة النهاية الخاصة وجدول التوجيه المطلوب من قبل App Service Environment إلى الشبكة الفرعية لجدار الحماية. من أجل البساطة، تقوم هذه البنية بتكوين جميع نقاط النهاية الخاصة على الشبكة الفرعية للخدمات.

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

• يخزن Azure Key Vault أي أسرار وبيانات اعتماد مطلوبة من قبل التطبيقات. استخدم هذا الخيار عبر تخزين الأسرار مباشرة في التطبيق.

• توفر GitHub Actions التكامل المستمر وقدرات النشر المستمر في هذه البنية. نظرا لوجود App Service Environment في الشبكة الظاهرية، يتم استخدام جهاز ظاهري كصندوق انتقال داخل الشبكة الظاهرية لنشر التطبيقات في خطط App Service. ينشئ الإجراء التطبيقات خارج الشبكة الظاهرية. لتحسين الأمان واتصال RDP/SSH السلس، ضع في اعتبارك استخدام Azure Bastion ل jumpbox.

تكوين متعدد المواقع

قم بتنزيل ملف Visio لهذه البنية.

يمكن لبيئة خدمة التطبيقات الداخلية استضافة العديد من تطبيقات الويب وواجهات برمجة التطبيقات مع نقاط نهاية HTTP. يتم تأمين هذه التطبيقات من الإنترنت العام، حيث لا يمكن الوصول إلى IP ILB إلا من داخل الشبكة الظاهرية. يتم استخدام بوابة التطبيق لعرض هذه التطبيقات بشكل انتقائي على الإنترنت. تعين App Service Environment عنوان URL افتراضيا لكل تطبيق App Service ك <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. يتم إنشاء منطقة DNS خاصة تقوم بتعيين اسم مجال App Service Environment إلى عنوان IP لبيئة خدمة التطبيقات ILB. هذا يتجنب استخدام DNS مخصص للوصول إلى التطبيقات داخل الشبكة الظاهرية.

يتم تكوين بوابة التطبيق بحيث يستمع المستمع على منفذ HTTPS للطلبات إلى عنوان IP الخاص بالبوابة. من أجل البساطة، لا يستخدم هذا التنفيذ تسجيل اسم DNS عاما. يتطلب تعديل ملف localhost على الكمبيوتر الخاص بك لتوجيه عنوان URL تم اختياره بشكل عشوائي إلى عنوان IP لبوابة التطبيق. للتبسيط، يستخدم المستمع شهادة موقعة ذاتيًا لمعالجة هذه الطلبات. تحتوي بوابة التطبيق على تجمعات خلفية لكل عنوان URL الافتراضي لتطبيق App Service. يتم تكوين قاعدة التحويل لتوصيل وحدة الاستماع بتجمع الواجهة الخلفية. يتم إنشاء إعدادات HTTP التي تحدد ما إذا كان سيتم تشفير الاتصال بين البوابة وبيئة خدمة التطبيقات. كما تُستخدم هذه الإعدادات لتجاوز عنوان مضيف HTTP الوارد مع اسم مضيف تم اختياره من تجمع الواجهة الخلفية. يستخدم هذا التنفيذ الشهادات الافتراضية التي تم إنشاؤها لعناوين URL الافتراضية لتطبيق App Service Environment، والتي تثق بها البوابة. تتم إعادة توجيه الطلب إلى عنوان محدد مواقع الويب الافتراضي للتطبيق المقابل. يقوم DNS الخاص المرتبط بالشبكة الظاهرية بإعادة توجيه هذا الطلب إلى IP ILB. ثم تقوم App Service Environment بإعادة توجيه هذا إلى خدمة التطبيق المطلوبة. أي اتصال HTTP داخل تطبيقات App Service Environment يمر عبر DNS الخاص. لاحظ أنه يجب تكوين وحدة الاستماع وتجمع الواجهة الخلفية وقاعدة التحويل وإعدادات HTTP على بوابة التطبيق لكل تطبيق App Service Environment.

راجع appgw.bicep وdns.bicep لمعرفة كيفية إجراء هذه التكوينات للسماح بمواقع متعددة. تطبيق الويب المسمى testapp هو تطبيق فارغ أنشئ لتوضيح هذا التكوين. يتم الوصول إلى ملفات JSON هذه من البرنامج النصي للتوزيع commands_std.azcli. يتم الوصول إليها أيضا بواسطة commands_ha.azcli، والذي يستخدم لنشر بيئة خدمة التطبيقات متعددة المواقع عالية التوفر.

تفاصيل السيناريو

Azure App Service هي خدمة PaaS تُستخدم لاستضافة مجموعة متنوعة من التطبيقات على Azure: تطبيقات الويب، وتطبيقات واجهة برمجة التطبيقات، والدوال، وتطبيقات الأجهزة المحمولة. تسمح App Service Environment للمؤسسات بنشر تطبيقات App Service الخاصة بها في شبكة فرعية في شبكة Azure الظاهرية الخاصة بها، ما يوفر بيئة معزولة وقابلة للتطوير بدرجة كبيرة ومخصصة لأحمال العمل السحابية الخاصة بها.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الأمان

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

بيئة خدمة التطبيق

يتم نشر بيئة App Service داخلية في الشبكة الظاهرية للمؤسسة، مخفية من الإنترنت العام. يسمح للمؤسسة بتأمين خدمات الواجهة الخلفية الخاصة بها، مثل واجهات برمجة تطبيقات الويب والوظائف، على مستوى الشبكة. يمكن الوصول إلى أي تطبيق App Service Environment مع نقطة نهاية HTTP، من خلال ILB، من داخل الشبكة الظاهرية. تم تكوين بوابة التطبيق لإعادة توجيه الطلبات إلى تطبيق الويب من خلال ILB. يمر تطبيق الويب نفسه من خلال ILB للوصول إلى واجهة برمجة التطبيقات. لا يمكن الوصول إلى مكونات الواجهة الخلفية الهامة، أي واجهة برمجة التطبيقات والدالة، بشكل فعال من الإنترنت العام.

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

Application Gateway

يقوم التنفيذ المرجعي بتكوين Application Gateway برمجيا في appgw.bicep. يستخدم الملف commands_std.azcli هذا التكوين عند نشر البوابة:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

التشفير

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

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

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

يستخدم هذا التنفيذ المرجعي شهادات موقعة ذاتيا لبوابة التطبيق. بالنسبة إلى التعليمة البرمجية للإنتاج، يجب استخدام شهادة صادرة عن هيئة الشهادات. للحصول على قائمة أنواع الشهادات المدعومة، راجع الشهادات المدعومة لإنهاء TLS. اقرأ تكوين بوابة تطبيق مع إنهاء TLS باستخدام مدخل Microsoft Azure لمعرفة كيفية إنشاء تشفير منتهية البوابة. تكون الأسطر التالية من التعليمات البرمجية في appgw.bicep هذا برمجيا:

          httpListeners: [for item in appgwApplications: {
          name: '${appgwListenerName}${item.name}'
          properties: {
            frontendIPConfiguration: {
              id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
            }
            frontendPort: {
              id: '${appgwId}/frontendPorts/port_443'
            }
            protocol: 'Https'
            sslCertificate: {
              id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
            }
            hostName: item.hostName
            requireServerNameIndication: true
          }
        }]

يوضح التنفيذ المرجعي التشفير الشامل لنسبة استخدام الشبكة بين Application Gateway وتطبيقات الويب على App Service Environment. يتم استخدام شهادات SSL الافتراضية. يتم تكوين تجمعات الواجهة الخلفية في هذا التنفيذ لإعادة توجيه حركة مرور HTTPS مع تجاوز اسم المضيف بواسطة أسماء المجالات الافتراضية المقترنة بتطبيقات الويب. تثق بوابة التطبيق في شهادات SSL الافتراضية لأنها صادرة عن Microsoft. راجع تكوين خدمة التطبيقات باستخدام بوابة التطبيق للحصول على معلومات حول كيفية إجراء هذه التكوينات. توضح التعليمات البرمجية التالية من appgw.bicep كيفية تكوين هذا في التنفيذ المرجعي:

        backendHttpSettingsCollection: [for item in appgwApplications: {
        name: '${appgwHttpSettingsName}${item.name}'
        properties: {
          port: 443
          protocol: 'Https'
          cookieBasedAffinity: 'Disabled'
          pickHostNameFromBackendAddress: true
          requestTimeout: 20
          probe: {
            id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
          }
        }
      }]

جدار حماية تطبيق الويب

يحمي جدار حماية تطبيق الويب (WAF) على بوابة التطبيق تطبيقات الويب من الهجمات الضارة، مثل حقن SQL. كما أنه متكامل مع Azure Monitor، لمراقبة الهجمات باستخدام سجل في الوقت الحقيقي. يجب تمكين WAF على البوابة، كما هو موضح في إنشاء بوابة تطبيق باستخدام Web Application Firewall باستخدام مدخل Microsoft Azure. يتيح التنفيذ المرجعي WAF برمجيا في ملف appgw.bicep مع القصاصة البرمجية التالية:

        webApplicationFirewallConfiguration: {
        enabled: true
        firewallMode: 'Detection'
        ruleSetType: 'OWASP'
        ruleSetVersion: '3.0'
      }

شبكة ظاهرية

يمكن إقران مجموعات أمان الشبكة بشبكة فرعية واحدة أو أكثر في الشبكة الظاهرية. هذه هي قواعد الأمان التي تسمح أو ترفض تدفق نسبة استخدام الشبكة بين موارد Azure المختلفة. تربط هذه البنية مجموعة أمان شبكة منفصلة لكل شبكة فرعية. يسمح هذا بضبط هذه القواعد لكل شبكة فرعية، وفقا للخدمات المضمنة في تلك الشبكة الفرعية. على سبيل المثال، راجع التكوين في "type": "Microsoft.Network/networkSecurityGroups" الملف ase.bicep لمجموعة أمان الشبكة للشبكة الفرعية App Service Environment، وفي الملف appgw.bicep لمجموعة أمان الشبكة للشبكة الفرعية ل Application Gateway.

تتيح نقاط النهاية الخاصة اتصالا خاصا محسنا للأمان بين العملاء وخدمات Azure عبر شبكة خاصة. وهي توفر عنوان IP يمكن الوصول إليه بشكل خاص لخدمة Azure، ما يتيح نسبة استخدام الشبكة المحسنة للأمان إلى مورد Azure Private Link. يتحقق النظام الأساسي من صحة اتصالات الشبكة، ما يسمح فقط بتلك التي تتصل بمورد Private Link المحدد. تدعم نقاط النهاية الخاصة نهج الشبكة مثل مجموعات أمان الشبكة والمسارات المعرفة من قبل المستخدم ومجموعات أمان التطبيقات. لتحسين الأمان، يجب تمكين نقاط النهاية الخاصة لأي خدمة Azure تدعمها. يمكنك بعد ذلك تحسين الأمان للخدمة في الشبكة الظاهرية عن طريق تعطيل الوصول العام، وحظر أي وصول من الإنترنت العام بشكل فعال. تقوم هذه البنية بتكوين نقاط النهاية الخاصة للخدمات التي تدعمها: ناقل خدمة Azure وSQL Server وKey Vault وAzure Cosmos DB. يمكنك مشاهدة التكوين في privatendpoints.bicep.

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

Firewall

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

لمعرفة كيفية تكامل Azure Firewall مع App Service Environment، راجع تكوين Azure Firewall مع App Service Environment. تتم مراقبة أي حركة مرور لا تعبر نقاط النهاية الخاصة وجدول توجيه الشبكة الظاهرية وبواباتها بواسطة جدار الحماية.

Microsoft Entra ID

يوفر معرف Microsoft Entra ميزات أمان لمصادقة التطبيقات وتخويل الوصول إلى الموارد. تستخدم هذه البنية المرجعية ميزتين رئيسيتين لمعرف Microsoft Entra: الهويات المدارة، والتحكم في الوصول المستند إلى الدور في Azure.

في التطبيقات السحابية، يجب تأمين بيانات الاعتماد المطلوبة للمصادقة على الخدمات السحابية. وبشكل مثالي، لا يجب أن تظهر بيانات الاعتماد أبدًا على محطات عمل المطور أو يتم إيداعها في عنصر تحكم المصدر. يوفر Azure Key Vault طريقة لتخزين بيانات الاعتماد والبيانات السرية، ولكن يظل يجب على التطبيق أن يصادق Key Vault لاستردادها. توفر الهويات المدارة لموارد Azure خدمات Azure بهوية مدارة تلقائيا في معرف Microsoft Entra. يمكن استخدام هذه الهوية للمصادقة على أي خدمة تدعم مصادقة Microsoft Entra، بما في ذلك Key Vault، دون أي بيانات اعتماد في التطبيق.

التحكم في الوصول استنادًا إلى الدور (Azure RBAC) يدير الوصول إلى موارد Azure. يتضمن هذا:

• أي كيان لديه حق الوصول: المستخدم، الهوية المدارة، أساس الأمان.
• نوع الوصول الذي يحتوي عليه: المالك والمساهم والقارئ والمسؤول.
• نطاق الوصول: المورد أو مجموعة الموارد أو الاشتراك أو مجموعة الإدارة.

يمكنك تأمين الوصول إلى تطبيقات App Service Environment عن طريق التحكم بإحكام في الدور المطلوب ونوع الوصول لكل تطبيق. بهذه الطريقة، يمكن نشر تطبيقات متعددة على نفس بيئة خدمة التطبيقات من فرق تطوير مختلفة. على سبيل المثال، قد تتم معالجة الواجهة الأمامية من قبل فريق واحد، والواجهة الخلفية بواسطة فريق آخر. يمكن استخدام Azure RBAC للحد من وصول كل فريق إلى التطبيق (التطبيقات) الذي يعمل عليه. استكشف أدوار Azure المخصصة لإنشاء أدوار مناسبة لمؤسستك.

Key Vault

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

• بالنسبة لناقل خدمة Microsoft Azure، إنه توقيعات وصول مشتركة.
• بالنسبة إلى Azure Cosmos DB، إنها مفاتيح.

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

تظهر التعليمات البرمجية التالية في services.bicep تكوين Key Vault لهذه الخدمات:

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

يتم الوصول إلى قيم سلسلة الاتصال هذه بواسطة التطبيقات، والتي تشير إلى زوج مفتاح/قيمة Key Vault. يتم ذلك في ملف sites.bicep ، كما يظهر التعليمات البرمجية التالية لتطبيق Voting:

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

كما تصل الدالة إلى سلسلة اتصال مستمع ناقل خدمة Microsoft Azure بطريقة مماثلة.

قابلية التوسع

تصميم تطبيقات قابلة للتطوير

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

بوابة تطبيق التحجيم التلقائي

يمكن تمكين التحجيم التلقائي على Azure Application Gateway V2. يسمح هذا لبوابة التطبيق بالتحجيم لأعلى أو لأسفل استنادا إلى أنماط تحميل نسبة استخدام الشبكة. يتم تكوين autoscaleConfiguration هذه البنية المرجعية في الملف appgw.bicep لتوسيع نطاقه بين صفر و10 مثيلات إضافية. لمزيد من التفاصيل، راجع تغيير حجم بوابة التطبيق وWAF v2.

التوزيع

يتم استخدام البرامج النصية للتوزيع في هذه البنية المرجعية لنشر App Service Environment والخدمات الأخرى والتطبيقات داخل App Service Environment. بمجرد توزيع هذه التطبيقات، قد ترغب المؤسسات في الحصول على خطة للتكامل والنشر المستمر لصيانة التطبيقات والترقيات. يوضح هذا القسم بعض الطرق الشائعة التي يستخدمها المطورون ل CI/CD لتطبيقات App Service Environment.

يمكن نشر التطبيقات في بيئة App Service داخلية فقط من داخل الشبكة الظاهرية. تستخدم الطرق الثلاث التالية على نطاق واسع لنشر تطبيقات App Service Environment:

• يدويا داخل الشبكة الظاهرية: أنشئ جهازا ظاهريا داخل الشبكة الظاهرية ل App Service Environment باستخدام الأدوات المطلوبة للنشر. افتح اتصال RDP بالجهاز الظاهري باستخدام تكوين NSG. انسخ البيانات الاصطناعية للتعليمات البرمجية إلى الجهاز الظاهري، وأنشئها وانشرها في الشبكة الفرعية لبيئة خدمة التطبيقات. هذه طريقة بسيطة لإعداد بيئة تطوير أولية للبناء والاختبار. ومع ذلك، لا يوصى به لبيئة الإنتاج لأنه لا يمكنه تغيير حجم معدل نقل التوزيع المطلوب.

• نقطة إلى اتصال الموقع من محطة العمل المحلية: يسمح لك هذا بتوسيع الشبكة الظاهرية لبيئة خدمة التطبيقات إلى جهاز التطوير الخاص بك، والنشر من هناك. هذه طريقة أخرى لإعداد بيئة تطوير أولية، ولا يوصى بها للإنتاج.

• من خلال Azure Pipelines: ينفذ هذا مسار CI/CD كاملا، ينتهي بعامل موجود داخل الشبكة الظاهرية. يعد هذا مثاليًا لبيئات الإنتاج التي تتطلب معدل نقل عالي للتوزيع. تظل البنية الأساسية لبرنامج ربط العمليات التجارية للبناء خارج الشبكة الظاهرية بالكامل. ينسخ مسار التوزيع الكائنات المضمنة إلى عامل البناء داخل الشبكة الظاهرية، ثم ينشر إلى الشبكة الفرعية لبيئة خدمة التطبيقات. لمزيد من المعلومات، اقرأ هذه المناقشة حول عامل البناء المستضاف ذاتيا بين البنية الأساسية لبرنامج ربط العمليات التجارية والشبكة الظاهرية لبيئة خدمة التطبيقات.

يوصى باستخدام Azure Pipelines لبيئات الإنتاج. يساعد البرمجة النصية CI/CD بمساعدة مخطط AZURE Pipelines YAML على أتمتة عمليات الإنشاء والتوزيع. ينفذ azure-pipelines.yml مثل مسار CI/CD لتطبيق الويب في هذا التنفيذ المرجعي. هناك برامج نصية CI/CD مشابهة لواجهة برمجة تطبيقات الويب بالإضافة إلى الدالة. اقرأ استخدام Azure Pipelines لمعرفة كيفية استخدامها لأتمتة CI/CD لكل تطبيق.

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

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

لمعرفة المزيد من الطرق التي يمكن من خلالها نشر التطبيقات في خطط App Service، اقرأ مقالات App Service التي تركز على استراتيجيات التوزيع.

تحسين التكلفة

استخدم حاسبة تسعير Azure لتقدير التكاليف. تم توضيح الاعتبارات الأخرى في قسم التكلفة في Microsoft Azure Well-Architected Framework. تساعدك Azure Reservations على توفير المال من خلال الالتزام بخطط لمدة عام أو ثلاث سنوات للعديد من موارد Azure. اقرأ المزيد في المقالة شراء حجز.

فيما يلي بعض النقاط التي يجب مراعاتها لبعض الخدمات المستخدمة في هذه البنية.

بيئة خدمة التطبيق الإصدار 3

هناك خيارات تسعير مختلفة متوفرة لـ App Service. يتم نشر App Service Environment باستخدام خطة خدمة الإصدار 2 المعزولة. ضمن هذه الخطة، هناك خيارات متعددة لأحجام وحدة المعالجة المركزية، من I1v2 إلى I6v2. يستخدم هذا التنفيذ المرجعي ثلاثة I1v2s لكل مثيل.

Application Gateway

يوفر تسعير Application Gateway خيارات تسعير مختلفة. يستخدم هذا التنفيذ Application Gateway Standard v2 وWAF v2 SKU، والذي يدعم التحجيم التلقائي والتكرار في المنطقة. راجع تغيير حجم Application Gateway v2 وWAF v2 لمزيد من المعلومات حول نموذج التسعير المستخدم ل SKU هذا.

ذاكرة التخزين المؤقت في Azure لـ Redis

تسعير Azure Cache for Redis يوفر خيارات التسعير المختلفة لهذه الخدمة. هذه البنية Premium SKU تستخدم لدعم الشبكة الظاهرية.

فيما يلي صفحات التسعير للخدمات الأخرى المستخدمة لتأمين App Service Environment:

• تسعير Azure Firewall

• أسعار Key Vault

• أسعار Microsoft Entra

نشر هذا السيناريو

لتوزيع التنفيذ المرجعي لهذه البنية، راجع GitHub readme، واتبع البرنامج النصي للتوزيع القياسي.

المساهمون

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

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

• Dhanashri Kshirsagar | كبير مديري المحتوى

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

• ديب بهاتاخاريا | مهندس حلول السحابة
• سهاس راو | مهندس حلول السحابة

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

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

• تشغيل تطبيقك في Azure App Service مباشرة من حزمة ZIP
• مخطط YAML لـ Azure Pipelines
• الحصول على عناوين الإدارة من واجهة برمجة التطبيقات
• Azure Key Vault
• مسارات Azure

الموارد ذات الصلة

لمعرفة كيفية توسيع هذه البنية لدعم قابلية الوصول العالية، اقرأ توزيع تطبيق قابلية وصول عالية باستخدام App Services Environment.