ملاحظة
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
توضح هذه المقالة وظيفة نظام التشغيل الأساسية المتوفرة لجميع تطبيقات Windows التي تعمل في Azure App Service. تتضمن هذه الوظيفة الوصول إلى الملفات والشبكة والتسجيل، بالإضافة إلى سجلات التشخيص والأحداث.
إشعار
تعمل تطبيقات Linux في App Service في حاوياتها الخاصة. لديك حق الوصول الجذر إلى الحاوية ولكن لا يوجد وصول إلى نظام التشغيل المضيف. وبالمثل، بالنسبة للتطبيقات التي تعمل في حاويات Windows، لديك حق الوصول الإداري إلى الحاوية ولكن لا يمكنك الوصول إلى نظام التشغيل المضيف.
مستويات خطة App Service
تشغل App Service تطبيقات العملاء في بيئة استضافة متعددة المستأجرين.
- تعمل التطبيقات المنشورة في المستويات المجانية والمشتركة في عمليات العامل على الأجهزة الظاهرية المشتركة (VMs).
- تعمل التطبيقات المنشورة في المستويات القياسية والمتميزة على الأجهزة الظاهرية المخصصة خصيصا للتطبيقات المرتبطة لعميل واحد.
إشعار
إن خطط خدمة المستويات المجانية والمشتركة (إصدار أولي) لـ App Service هي مستويات أساسية تعمل على نفس الأجهزة الظاهرية لـ Azure مثل تطبيقات App Service الأخرى. قد تنتمي بعض التطبيقات إلى عملاء آخرين. هذه المستويات مخصصة فقط لأغراض التطوير والاختبار.
نظرا لأن App Service تدعم تجربة تحجيم سلسة بين المستويات، يظل تكوين الأمان المفروض لتطبيقات App Service كما هو. يضمن هذا التكوين أن التطبيقات لا تتصرف فجأة بشكل مختلف وتفشل بطرق غير متوقعة عند تبديل خطة App Service من مستوى إلى آخر.
أطر التطوير
تتحكم مستويات تسعير App Service في مقدار موارد الحوسبة (وحدة المعالجة المركزية وتخزين القرص والذاكرة والخروج من الشبكة) المتوفرة للتطبيقات. ومع ذلك، يظل اتساع وظائف إطار العمل المتاحة للتطبيقات كما هو بغض النظر عن مستويات التحجيم.
تدعم App Service أطر التطوير المختلفة، بما في ذلك ASP.NET وASP الكلاسيكية Node.jsوPHP وPython. لتبسيط تكوين الأمان وتطبيعه، تقوم تطبيقات App Service عادة بتشغيل أطر التطوير بإعداداتها الافتراضية. يتم تحديث أطر العمل ومكونات وقت التشغيل التي يوفرها النظام الأساسي بانتظام لتلبية متطلبات الأمان والتوافق. لهذا السبب، لا نضمن إصدارات ثانوية أو تصحيحية محددة. نوصي العملاء باستهداف الإصدارات الرئيسية حسب الحاجة.
تلخص الأقسام التالية الأنواع العامة لوظائف نظام التشغيل المتوفرة لتطبيقات App Service.
الوصول إلى الملفات
توجد محركات أقراص مختلفة داخل App Service، بما في ذلك محركات الأقراص المحلية ومحركات أقراص الشبكة.
محركات الأقراص المحلية
في جوهرها، خدمة التطبيقات هي خدمة تعمل على رأس البنية الأساسية لمنصة Azure كخدمة (PaaS). ونتيجة لذلك، فإن محركات الأقراص المحلية المقترنة بجهاز ظاهري هي نفس أنواع محركات الأقراص المتوفرة لأي دور عامل يعمل في Azure. يشمل ذلك ما يلي:
- محرك أقراص نظام التشغيل (
%SystemDrive%) الذي يعتمد حجمه على حجم الجهاز الظاهري. - محرك أقراص الموارد (
%ResourceDrive%) الذي تستخدمه App Service داخليا.
أفضل ممارسة هي استخدام متغيرات %SystemDrive%%ResourceDrive% البيئة دائما وبدلا من مسارات الملفات ذات التعليمات البرمجية المضمنة. تحول المسار الجذر الذي تم إرجاعه من متغيري البيئة هذين بمرور الوقت من d:\ إلى c:\. ومع ذلك، فإن التطبيقات القديمة ذات تعليمات برمجية مضمنة مع مراجع مسار الملف لمتابعة d:\ العمل لأن App Service تعيد d:\ التعيين تلقائيا للإشارة c:\إلى . كما ذكرنا سابقا، نوصي بشدة باستخدام متغيرات البيئة دائما عند إنشاء مسارات الملفات وتجنب الارتباك حول تغييرات النظام الأساسي لمسار ملف الجذر الافتراضي.
من المهم مراقبة استخدام القرص مع نمو تطبيقك. يمكن أن يكون للوصول إلى الحصة النسبية للقرص تأثيرات سلبية على التطبيق الخاص بك. على سبيل المثال:
- قد يطرح التطبيق خطأ يشير إلى عدم وجود مساحة كافية على القرص.
- قد ترى أخطاء في القرص عند الاستعراض إلى وحدة تحكم Kudu.
- قد يفشل النشر من Azure DevOps أو Visual Studio مع
ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk). - قد يكون أداء التطبيق بطيئا.
محركات أقراص الشبكة (مشاركات UNC)
أحد الجوانب الفريدة لخدمة التطبيقات التي تجعل نشر التطبيقات وصيانتها مباشرة هو تخزين جميع مشاركات المحتوى على مجموعة من مشاركات اتفاقية التسمية العالمية (UNC). يعين هذا النموذج بشكل جيد إلى النمط الشائع لتخزين المحتوى الذي تستخدمه بيئات استضافة الويب المحلية التي تحتوي على خوادم متعددة متوازنة التحميل.
داخل App Service، يتم إنشاء مشاركات UNC في كل مركز بيانات. يتم تخصيص نسبة مئوية من محتوى المستخدم لجميع العملاء في كل مركز بيانات لكل مشاركة UNC. يحتوي اشتراك كل عميل على بنية دليل محجوزة على حصة UNC معينة في مركز بيانات. قد يكون لدى العميل تطبيقات متعددة تم إنشاؤها في مركز بيانات معين، لذلك يتم إنشاء جميع الدلائل التي تنتمي إلى اشتراك عميل واحد على نفس مشاركة UNC.
نظرا للطريقة التي تعمل بها خدمات Azure، يتغير الجهاز الظاهري المحدد المسؤول عن استضافة مشاركة UNC بمرور الوقت. يتم تحميل مشاركات UNC بواسطة أجهزة ظاهرية مختلفة حيث يتم إحضارها وهبوطها أثناء المسار العادي لعمليات Azure. لهذا السبب، يجب ألا تجعل التطبيقات أبدا افتراضات ذات تعليمات برمجية مضمنة بأن معلومات الجهاز في مسار ملف UNC تظل مستقرة بمرور الوقت. بدلا من ذلك، يجب عليهم استخدام المسار%HOME%\site المطلق المناسب الذي توفره App Service.
المسار المطلق المساعد هو طريقة محمولة للإشارة إلى تطبيقك الخاص. إنها ليست خاصة بأي تطبيق أو مستخدم. باستخدام %HOME%\site، يمكنك نقل الملفات المشتركة من تطبيق إلى تطبيق دون الحاجة إلى تكوين مسار مطلق جديد لكل عملية نقل.
أنواع الوصول إلى الملفات الممنوحة لتطبيق
يعين %HOME% الدليل في تطبيق إلى مشاركة محتوى في Azure Storage المخصص لهذا التطبيق. يحدد مستوى التسعير الخاص بك حجمه. قد يتضمن أدلة مثل تلك الخاصة بالمحتوى وسجلات الأخطاء والتشخيص والإصدارات السابقة من التطبيق الذي أنشأه التحكم بالمصادر. تتوفر هذه الدلائل للتعليمات البرمجية للتطبيق في وقت التشغيل للوصول للقراءة والكتابة. نظرا لعدم تخزين الملفات محليا، فهي مستمرة عبر عمليات إعادة تشغيل التطبيق.
على محرك أقراص النظام، تحتفظ %SystemDrive%\local App Service بالتخزين المحلي المؤقت الخاص بالتطبيق. التغييرات على الملفات في هذا الدليل غير مستمرة عبر عمليات إعادة تشغيل التطبيق. على الرغم من أن التطبيق لديه حق الوصول الكامل للقراءة والكتابة إلى التخزين المحلي المؤقت الخاص به، فإن هذا التخزين غير مخصص للاستخدام المباشر من قبل التعليمات البرمجية للتطبيق. بدلا من ذلك، فإن الهدف هو توفير تخزين مؤقت للملفات ل IIS وأطر عمل تطبيقات الويب.
تحد App Service من مقدار التخزين في %SystemDrive%\local كل تطبيق لمنع التطبيقات الفردية من استهلاك كميات زائدة من تخزين الملفات المحلية. بالنسبة للمستويات المجانية والمشتركة والاستهلاكية (Azure Functions)، يكون الحد هو 500 ميغابايت. يسرد الجدول التالي المستويات الأخرى:
| المستوي | حد التخزين المحلي |
|---|---|
| B1/S1/P1 | 11 غيغابايت |
| B2/S2/P2 | 15 غيغابايت |
| B3/S3/P3 | 58 غيغابايت |
| P0v3/P0v4 | 11 غيغابايت |
| P1v2/P1v3/P1mv3/P1mv4/Isolated1/Isolated1v2 | 21 غيغابايت |
| P2v2/P2v3/P2mv3/P2mv4/Isolated2/Isolated2v2 | 61 غيغابايت |
| P3v2/P3v3/P3mv3/P3mv4/Isolated3/Isolated3v2 | 140 غيغابايت |
| Isolated4v2 | 276 غيغابايت |
| P4mv3/P4mv4 | 280 غيغابايت |
| Isolated5v2 | 552 غيغابايت |
| P5mv3/P5mv4 | 560 غيغابايت |
| Isolated6v2 | 1,104 غيغابايت |
دليل ملفات ASP.NET المؤقتة ودليل ملفات IIS المضغوطة مثالان على كيفية استخدام App Service للتخزين المحلي المؤقت. يستخدم %SystemDrive%\local\Temporary ASP.NET Files نظام التحويل البرمجي ASP.NET الدليل كموقع مؤقت لذاكرة التخزين المؤقتة للوصول إلى التحويل البرمجي. يستخدم %SystemDrive%\local\IIS Temporary Compressed Files IIS الدليل لتخزين إخراج الاستجابة المضغوطة. يتم إعادة تعيين كلا النوعين من استخدام الملفات (جنبا إلى جنب مع الآخرين) في App Service إلى التخزين المحلي المؤقت لكل تطبيق. تساعد إعادة التعيين هذه على ضمان استمرار الوظيفة كما هو متوقع.
يعمل كل تطبيق في App Service كهوية عملية عامل عشوائية وفريدة ومنخفضة الامتيازات تسمى هوية تجمع التطبيقات. تستخدم التعليمات البرمجية للتطبيق هذه الهوية للوصول الأساسي للقراءة فقط إلى محرك أقراص نظام التشغيل. يعني هذا الوصول أن التعليمات البرمجية للتطبيق يمكنها سرد بنيات الدليل الشائعة وقراءة الملفات الشائعة على محرك أقراص نظام التشغيل. على الرغم من أن هذا المستوى من الوصول قد يبدو واسعا، إلا أنه يمكن الوصول إلى نفس الدلائل والملفات عند توفير دور عامل في خدمة مستضافة على Azure وقراءة محتويات محرك الأقراص.
الوصول إلى الملفات عبر مثيلات متعددة
يحتوي دليل مشاركة المحتوى (%HOME%) على محتوى التطبيق، ويمكن للتعليمات البرمجية للتطبيق الكتابة إليه. إذا تم تشغيل تطبيق على مثيلات متعددة، %HOME% تتم مشاركة الدليل بين جميع المثيلات بحيث ترى جميع المثيلات نفس الدليل. على سبيل المثال، إذا قام أحد التطبيقات بحفظ الملفات التي تم تحميلها إلى %HOME% الدليل، تكون هذه الملفات متاحة على الفور لجميع المثيلات.
لا تتم مشاركة دليل التخزين المحلي المؤقت (%SystemDrive%\local) بين المثيلات. كما أنه لا تتم مشاركته بين التطبيق والتطبيق Kudu الخاص به.
الوصول إلى الشبكة
يمكن أن تستخدم التعليمات البرمجية للتطبيق بروتوكولات مستندة إلى TCP/IP وUDP لإجراء اتصالات الشبكة الصادرة بنقاط النهاية التي يمكن الوصول إليها عبر الإنترنت والتي تعرض الخدمات الخارجية. يمكن للتطبيقات استخدام نفس البروتوكولات للاتصال بالخدمات داخل Azure-- على سبيل المثال، عن طريق إنشاء اتصالات HTTPS بقاعدة بيانات Azure SQL.
هناك أيضا قدرة محدودة للتطبيقات على إنشاء اتصال رد حلقي محلي واحد والاستماع إلى تطبيق على مأخذ التوصيل الحلقي المحلي هذا. تتيح هذه الميزة للتطبيقات التي تستمع إلى مآخذ الاستعادة المحلية كجزء من وظائفها. يحتوي كل تطبيق على اتصال خاص بالرد. لا يمكن لأحد التطبيقات الاستماع إلى مأخذ توصيل حلقي محلي أنشأه تطبيق آخر.
يتم دعم الأنابيب المسماة أيضا كآلية للاتصال البيني بين العمليات التي تشغل التطبيق بشكل جماعي. على سبيل المثال، تعتمد الوحدة النمطية IIS FastCGI على أنابيب مسماة لتنسيق العمليات الفردية التي تقوم بتشغيل صفحات PHP.
تنفيذ التعليمات البرمجية والعمليات والذاكرة
كما ذكرنا سابقا، تعمل التطبيقات داخل عمليات العامل ذات الامتيازات المنخفضة باستخدام هوية تجمع تطبيقات عشوائية. تتمتع التعليمات البرمجية للتطبيق بإمكانية الوصول إلى مساحة الذاكرة المقترنة بعملية العامل، بالإضافة إلى أي عمليات تابعة قد تفرخها عمليات CGI أو تطبيقات أخرى. ومع ذلك، لا يمكن لأحد التطبيقات الوصول إلى ذاكرة أو بيانات تطبيق آخر، حتى لو كان على نفس الجهاز الظاهري.
يمكن للتطبيقات تشغيل البرامج النصية أو الصفحات المكتوبة باستخدام أطر عمل تطوير الويب المدعومة. لا تقوم App Service بتكوين أي إعدادات إطار عمل ويب لأوضاع أكثر تقييدا. على سبيل المثال، تعمل ASP.NET التطبيقات التي تعمل في App Service بثقة كاملة، بدلا من وضع ثقة أكثر تقييدا. يمكن لإطارات عمل الويب، بما في ذلك كل من ASP الكلاسيكية ASP.NET، استدعاء مكونات COM قيد المعالجة (مثل كائنات بيانات ActiveX) المسجلة بشكل افتراضي على نظام التشغيل Windows. لا يمكن لإطارات عمل الويب استدعاء مكونات COM خارج العملية.
يمكن للتطبيق إنتاج التعليمات البرمجية العشوائية وتشغيلها، أو فتح أمر shell، أو تشغيل برنامج نصي PowerShell. ومع ذلك، لا تزال البرامج والبرامج النصية القابلة للتنفيذ مقيدة بالامتيازات الممنوحة لتجمع التطبيقات الأصل. على سبيل المثال، يمكن للتطبيق إنتاج برنامج قابل للتنفيذ يقوم بإجراء مكالمة HTTP صادرة، ولكن هذا البرنامج القابل للتنفيذ لا يمكنه محاولة إلغاء ربط عنوان IP لجهاز ظاهري من محول الشبكة الخاص به. يسمح بإجراء مكالمة شبكة صادرة للتعليمات البرمجية ذات الامتيازات المنخفضة، ولكن محاولة إعادة تكوين إعدادات الشبكة على جهاز ظاهري يتطلب امتيازات إدارية.
سجلات التشخيص والأحداث
معلومات السجل هي مجموعة أخرى من البيانات التي تحاول بعض التطبيقات الوصول إليها. تتضمن أنواع معلومات السجل المتوفرة للتعليمات البرمجية التي تعمل في App Service معلومات التشخيص والسجل التي ينشئها التطبيق ويمكن الوصول إليها بسهولة.
على سبيل المثال، تتوفر سجلات W3C HTTP التي تم إنشاؤها بواسطة التطبيق إما:
- في دليل سجل في موقع مشاركة الشبكة الذي قمت بإنشائه للتطبيق.
- في blob storage إذا قمت بإعداد تسجيل W3C إلى التخزين.
يتيح الخيار الأخير للتطبيقات جمع كميات كبيرة من السجلات دون تجاوز حدود تخزين الملفات المقترنة بمشاركة الشبكة.
وبالمثل، يمكن تسجيل معلومات التشخيص في الوقت الحقيقي من تطبيقات .NET من خلال البنية الأساسية لتتبع .NET والتشخيص. يمكنك بعد ذلك كتابة معلومات التتبع إما إلى مشاركة شبكة التطبيق أو موقع تخزين كائن ثنائي كبير الحجم.
مجالات التسجيل التشخيصي والتتبع غير المتوفرة للتطبيقات هي أحداث تتبع أحداث Windows (ETW) وسجلات أحداث Windows الشائعة (على سبيل المثال، النظام والتطبيق وسجلات أحداث الأمان). نظرا لأنه من المحتمل أن تكون معلومات تتبع ETW قابلة للعرض عبر جهاز باستخدام قوائم التحكم في الوصول الصحيحة، يتم حظر الوصول للقراءة والكتابة إلى أحداث ETW. قد يبدو أن استدعاءات واجهة برمجة التطبيقات لقراءة وكتابة أحداث ETW وسجلات أحداث Windows الشائعة تعمل، ولكن في الواقع، لا يمكن للتعليمات البرمجية للتطبيق الوصول إلى بيانات الحدث هذه.
الوصول إلى السجل
تتمتع التطبيقات بإمكانية الوصول للقراءة فقط إلى الكثير من سجل الجهاز الظاهري الذي تعمل عليه، وإن لم يكن كلها. يعني هذا الوصول أنه يمكن للتطبيقات الوصول إلى مفاتيح التسجيل التي تسمح بالوصول للقراءة فقط إلى مجموعة المستخدمين المحليين. إحدى مناطق السجل غير المدعومة حاليا للوصول للقراءة أو الكتابة هي الخلية HKEY_CURRENT_USER .
يتم حظر الوصول للكتابة إلى السجل، بما في ذلك الوصول إلى أي مفاتيح تسجيل لكل مستخدم. من منظور التطبيق، لا يمكنه الاعتماد على الوصول للكتابة إلى السجل في بيئة Azure لأنه يمكن ترحيل التطبيقات عبر الأجهزة الظاهرية. التخزين الدائم الوحيد القابل للكتابة الذي يمكن أن يعتمد عليه التطبيق هو بنية دليل المحتوى لكل تطبيق المخزنة على مشاركات App Service UNC.
الوصول إلى سطح المكتب البعيد
لا توفر App Service الوصول إلى سطح المكتب البعيد إلى مثيلات الجهاز الظاهري.
المحتوى ذو الصلة
لمزيد من المعلومات up-to-date حول بيئة تنفيذ App Service، راجع بيئة الاختبار المعزولة لخدمة تطبيقات Azure. يحتفظ فريق تطوير App Service بهذه الصفحة.