وظيفة نظام التشغيل في Azure App Service

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

إشعار

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

مستويات خطة خدمة التطبيق

تشغل App Service تطبيقات العملاء في بيئة استضافة متعددة المستأجرين. تعمل التطبيقات المنشورة في المستويات المجانية والمشتركة في عمليات العامل على الأجهزة الظاهرية المشتركة (VMs). تعمل التطبيقات المنشورة في المستويات القياسية والمتميزة على الأجهزة الظاهرية المخصصة خصيصا للتطبيقات المرتبطة لعميل واحد.

إشعار

إن خطط خدمة المستويات المجانية والمشتركة (إصدار أولي) لـ App Service هي مستويات أساسية تعمل على نفس الأجهزة الظاهرية لـ Azure مثل تطبيقات App Service الأخرى. قد تنتمي بعض التطبيقات إلى عملاء آخرين. هذه المستويات مخصصة فقط لأغراض التطوير والاختبار.

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

أطر عمل التطوير

تتحكم مستويات تسعير خدمة التطبيقات في مقدار موارد الحوسبة (وحدة المعالجة المركزية، وتخزين القرص، والذاكرة، وخروج الشبكة) المتاحة للتطبيقات. ومع ذلك، فإن نطاق وظائف إطار العمل المتاحة للتطبيقات يظل كما هو بغض النظر عن مستويات القياس.

تدعم App Service أطر التطوير المختلفة، بما في ذلك ASP.NET وASP الكلاسيكية وNode.js وPHP وPython. لتبسيط تكوين الأمان وتطبيعه، تقوم تطبيقات 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 الذي توفره خدمة التطبيقات.

المسار المطلق المساعد هو طريقة محمولة للإشارة إلى تطبيقك الخاص. إنها ليست خاصة بأي تطبيق أو مستخدم. باستخدام %HOME%\site، يمكنك نقل الملفات المشتركة من تطبيق إلى تطبيق دون الحاجة إلى تكوين مسار مطلق جديد لكل عملية نقل.

أنواع الوصول إلى الملفات الممنوحة للتطبيق

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

على محرك أقراص النظام، تحتفظ خدمة التطبيق بـ %SystemDrive%\local للتخزين المحلي المؤقت الخاص بالتطبيق. التغييرات التي يتم إجراؤها على الملفات في هذا الدليل ليست مستمرة عبر عمليات إعادة تشغيل التطبيق. على الرغم من أن التطبيق لديه حق الوصول الكامل للقراءة والكتابة إلى التخزين المحلي المؤقت الخاص به، فإن هذا التخزين غير مخصص للاستخدام المباشر من قبل التعليمات البرمجية للتطبيق. بدلاً من ذلك، فإن الهدف هو توفير تخزين مؤقت للملفات لـ IIS وأطر تطبيقات الويب.

تحد App Service من مقدار التخزين في %SystemDrive%\local كل تطبيق لمنع التطبيقات الفردية من استهلاك كميات زائدة من تخزين الملفات المحلية. بالنسبة إلى المستويات المجانية والمشتركة والاستهلاك (وظائف Azure)، فإن الحد الأقصى هو 500 ميغابايت. يسرد الجدول التالي المستويات الأخرى:

المستوى	تخزين الملفات المحلية
B1/S1/P1	11 غيغابايت
B2/S2/P2	15 غيغابايت
B3/S3/P3	58 غيغابايت
P0v3	11 غيغابايت
P1v2/P1v3/P1mv3/Isolated1/Isolated1v2	21 غيغابايت
P2v2/P2v3/P2mv3/Isolated2/Isolated2v2	61 غيغابايت
P3v2/P3v3/P3mv3/Isolated3/Isolated3v2	140 غيغابايت
Isolated4v2	276 غيغابايت
P4mv3	280 غيغابايت
Isolated5v2	552 غيغابايت
P5mv3	560 غيغابايت
Isolated6v2	1,104 غيغابايت

مثالان على كيفية استخدام خدمة التطبيقات للتخزين المحلي المؤقت هما دليل ملفات ASP.NET المؤقتة ودليل ملفات IIS المضغوطة. يستخدم نظام التحويل البرمجي ASP.NET الدليل %SystemDrive%\local\Temporary ASP.NET Files كموقع مؤقت لذاكرة التخزين المؤقت للترجمة. يستخدم IIS الدليل %SystemDrive%\local\IIS Temporary Compressed Files لتخزين إخراج الاستجابة المضغوطة. يتم إعادة تعيين كلا النوعين من استخدام الملفات (جنبا إلى جنب مع الآخرين) في App Service إلى التخزين المحلي المؤقت لكل تطبيق. تساعد إعادة التعيين هذه على ضمان استمرار الوظيفة كما هو متوقع.

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

الوصول إلى الملفات عبر مثيلات متعددة

يحتوي دليل مشاركة المحتوى (%HOME%) على محتوى التطبيق، ويمكن أن يكتب عليه رمز التطبيق. إذا تم تشغيل أحد التطبيقات على مثيلات متعددة، فسيتم مشاركة دليل %HOME% بين جميع المثيلات بحيث ترى جميع المثيلات نفس الدليل. على سبيل المثال، إذا قام أحد التطبيقات بحفظ الملفات التي تم تحميلها إلى %HOME% الدليل، تكون هذه الملفات متاحة على الفور لجميع المثيلات.

لا تتم مشاركة دليل التخزين المحلي المؤقت (%SystemDrive%\local) بين المثيلات. كما أنه لا تتم مشاركته بين التطبيق والتطبيق Kudu الخاص به.

الوصول إلى الشبكة

يمكن أن تستخدم التعليمات البرمجية للتطبيق بروتوكولات مستندة إلى TCP/IP وUDP لإجراء اتصالات الشبكة الصادرة بنقاط النهاية التي يمكن الوصول إليها عبر الإنترنت والتي تعرض الخدمات الخارجية. يمكن للتطبيقات استخدام نفس البروتوكولات للاتصال بالخدمات داخل Azure-- على سبيل المثال، عن طريق إنشاء اتصالات HTTPS بقاعدة بيانات Azure SQL.

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

يتم دعم الأنابيب المسماة أيضا كآلية للاتصال البيني بين العمليات التي تشغل التطبيق بشكل جماعي. على سبيل المثال، تعتمد الوحدة النمطية IIS FastCGI على الأنابيب المسماة لتنسيق العمليات الفردية التي تقوم بتشغيل صفحات PHP.

تنفيذ التعليمات البرمجية والعمليات والذاكرة

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

يمكن للتطبيقات تشغيل البرامج النصية أو الصفحات المكتوبة باستخدام أطر تطوير الويب المدعومة. لا تقوم خدمة التطبيقات بتهيئة أي إعدادات لإطار عمل الويب إلى أوضاع أكثر تقييدًا. على سبيل المثال، تعمل ASP.NET التطبيقات التي تعمل في App Service بثقة كاملة، بدلا من وضع ثقة أكثر تقييدا. يمكن لإطارات عمل الويب، بما في ذلك كل من ASP الكلاسيكية ASP.NET، استدعاء مكونات COM قيد المعالجة (مثل كائنات بيانات ActiveX) المسجلة بشكل افتراضي على نظام التشغيل Windows. لا يمكن لإطارات عمل الويب استدعاء مكونات COM خارج العملية.

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

سجلات التشخيص والأحداث

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

على سبيل المثال، تتوفر سجلات W3C HTTP التي تم إنشاؤها بواسطة التطبيق إما:

• في دليل سجل في موقع مشاركة الشبكة الذي قمت بإنشائه للتطبيق
• في تخزين الكائن الثنائي كبير الحجم إذا قمت بإعداد تسجيل W3C إلى التخزين

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

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

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

الوصول إلى السجل

تتمتع التطبيقات بإمكانية الوصول للقراءة فقط إلى الكثير (وليس كل) سجل الجهاز الظاهري الذي تعمل عليه. يعني هذا الوصول أنه يمكن للتطبيقات الوصول إلى مفاتيح التسجيل التي تسمح بالوصول للقراءة فقط إلى مجموعة المستخدمين المحليين. إحدى مناطق السجل غير المدعومة حاليا للوصول للقراءة أو الكتابة هي الخلية HKEY\_CURRENT\_USER .

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

الوصول إلى سطح المكتب البعيد

لا توفر خدمة التطبيقات وصولاً لسطح المكتب البعيد إلى مثيلات VM.

مزيد من المعلومات

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