مشاركة عبر

ما Azure Resource Manager؟

  • مقالة

Azure Resource Manager هي خدمة التوزيع والإدارة التي توفرها Azure. فهي توفر طبقة إدارة تتيح لك إنشاء الموارد وتحديثها وحذفها في حساب Azure الخاص بك. تستخدم ميزات الإدارة مثل التحكم في الوصول، والأقفال، والعلامات لتأمين مواردك وتنظيمها بعد النشر.

للتعرف على نماذج Azure Resource Manager (نماذج ARM)، راجع نظرة عامة حول نماذج ARM. للتعرف على Bicep، راجع نظرة عامة على Bicep.

يغطي الفيديو التالي المفاهيم الأساسية ل Azure Resource Manager.

طبقة إدارة متناسقة

عند إرسال طلب عبر أي من واجهات برمجة التطبيقات، أو الأدوات أو عدد تطوير البرامج في Azure، فإن Azure Resource Manager يتلقى الطلب. يقوم بمصادقة الطلب وتخويله قبل إعادة توجيهه إلى خدمة Azure المناسبة. نظراً لأنه يتم التعامل مع جميع الطلبات من خلال واجهة برمجة التطبيقات نفسها، فإنك ترى نتائج وقدرات متسقة في جميع الأدوات المختلفة.

تُظهر الصورة التالية الدور الذي يلعبه Azure Resource Manager في معالجة طلبات Azure.

رسم تخطيطي يوضح دور Azure Resource Manager في معالجة طلبات Azure.

جميع الإمكانات المتوفرة في مدخل Azure متاحة أيضاً من خلال PowerShell وAzure CLI وواجهات برمجة تطبيقات REST ومجموعة أدوات تطوير البرامج الخاصة بالعميل. يتم تمثيل الوظائف التي تم إصدارها في البداية من خلال واجهات برمجة التطبيقات في المدخل في غضون 180 يوما من الإصدار الأولي.

هام

سيدعم Azure Resource Manager فقط بروتوكول أمان طبقة النقل (TLS) 1.2 أو أحدث بحلول خريف 2023. لمزيد من المعلومات، راجع الترحيل إلى TLS 1.2 ل Azure Resource Manager.

المصطلحات

إذا كنت مستخدماً جديداً لخدمة Azure Resource Manager، فهناك بعض المصطلحات التي قد لا تكون على دراية بها.

  • المورد - عنصر يمكن التحكم فيه ويتوافر من خلال Azure. تعد الأجهزة الافتراضية، وحسابات التخزين، وتطبيقات الويب، وقواعد البيانات، والشبكات الافتراضية أمثلة على الموارد. كما تُعد مجموعات الموارد والاشتراكات ومجموعات الإدارة والعلامات أيضاً أمثلة على الموارد.
  • مجموعة الموارد - حاوية تضم موارد ذات صلة بحل Azure. تتضمن مجموعة الموارد تلك الموارد التي تريد إدارتها كمجموعة. تقرر نوع الموارد التي تنتمي إلى مجموعة الموارد بناءً على ما هو أكثر منطقية لمؤسستك. راجع ما هي مجموعة الموارد؟.
  • موفر الموارد - خدمة توفِّر موارد Azure. فعلى سبيل المثال، موفر الموارد الشائع هو Microsoft.Compute، الذي يوفر مورد الجهاز الافتراضي. Microsoft.Storage موفر موارد آخر شائع. راجع موفرو الموارد وأنواعها.
  • الصيغة التعريفية - تتيح لك الصيغة قول "هذا ما أنوي إنشاءه" دون الحاجة إلى كتابة سلسلة من الأوامر البرمجية لإنشائه. إن نماذج ARM وملفات Bicep هي أمثلة للصيغة التعريفية. في هذه الملفات، يمكنك تعريف خصائص البنية الأساسية لنشرها في Azure.
  • نموذج ARM - ملف JavaScript Object Notation (JSON) الذي يُعرّف موردًا واحدًا أو أكثر لنشره في مجموعة موارد، أو اشتراك، أو مجموعة إدارة، أو لدى مستأجر. يمكن استخدام القالب لتوزيع الموارد بشكل متناسق ومتكرر. راجع نظرة عامة على نشر القالب.
  • ملف Bicep - ملف لنشر موارد Azure بشكل تعريفي. Bicep هي لغة تم تصميمها لتوفير أفضل تجربة تأليف للبنية الأساسية كحلول تعليمات برمجية في Azure. راجع نظرة عامة على Bicep.
  • مورد الملحق - مورد يضيف إلى قدرات مورد آخر. على سبيل المثال، تعيين الدور هو مورد ملحق. يمكنك تطبيق تعيين دور على أي مورد آخر لتحديد الوصول. راجع موارد الملحق.

لمزيد من تعريفات مصطلحات Azure، راجع مفاهيم Azure الأساسية.

مزايا استخدام Resource Manager

باستخدام Resource Manager، يمكنك فعل ما يلي:

  • إدارة بنيتك الأساسية من خلال القوالب التعريفية بدلاً من البرامج النصية.

  • نشر جميع موارد الحل الخاص بك كمجموعة وإدارتها ومراقبتها، بدلاً من التعامل مع هذه الموارد بشكل فردي.

  • أعِد نشر الحل الخاص بك طوال فترة سريان التطوير وكن واثقاً من نشر مواردك في حالة متسقة.

  • تحديد التبعيات بين الموارد حتى تُوزّع بالترتيب الصحيح.

  • تطبيق التحكم في الوصول على جميع الخدمات لأن التحكم في الوصول المستند إلى دور Azure‏ (Azure RBAC) مدمج أصلاً في النظام الأساسي للإدارة.

  • وضع العلامات على الموارد لتنظيم جميع الموارد بشكل منطقي في اشتراكك.

  • توضيح فوترة مؤسستك من خلال عرض التكاليف لمجموعة من الموارد التي تشترك في العلامة نفسها.

فهم النطاق

يوفر Azure أربعة مستويات من نطاق الإدارة: مجموعات الإدارة والاشتراكات ومجموعات الموارد والموارد. تعرض الصورة التالية مثالاً على هذه الطبقات.

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

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

للحصول على معلومات حول إدارة الهويات والوصول، راجع معرف Microsoft Entra.

يمكنك نشر القوالب على المستأجرين، أو مجموعات الإدارة، أو الاشتراكات، أو مجموعات الموارد.

ما هي مجموعة الموارد؟

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

هناك بعض العوامل الهامة التي يجب مراعاتها عند تعريف مجموعة الموارد الخاصة بك:

  • يجب أن تشترك جميع الموارد في مجموعة الموارد الخاصة بك في دورة الحياة نفسها. يمكنك توزيع هذه الموارد وتحديثها وحذفها معاً. إذا لزم وجود أحد الموارد -مثل الخادم- في دورة نشر مختلفة، فيجب أن يكون في مجموعة موارد أخرى.

  • لا يمكن أن يوجد المورد إلا في مجموعة موارد واحدة فقط.

  • يمكنك إضافة مورد أو إزالته إلى مجموعة موارد في أي وقت.

  • يمكنك نقل مورد من مجموعة موارد واحدة إلى مجموعة أخرى. لمزيد من المعلومات، راجع نقل الموارد إلى مجموعة موارد جديدة أو اشتراك جديد.

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

  • يمكن استخدام مجموعة موارد للتحكم بالوصول إلى النطاق للإجراءات الإدارية. لإدارة مجموعة موارد، يمكنك تعيين نُهج Azure، أو أدوار Azure، أو تأمين الموارد.

  • يمكنك وضع علامات على مجموعة موارد. ولا تستورد الموارد الموجودة في مجموعة الموارد هذه العلامات.

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

  • وعند حذف مجموعة موارد، تُحذف أيضاً جميع الموارد في مجموعة الموارد. للحصول على معلومات حول كيفية تنظيم Azure Resource Manager عمليات الحذف هذه، راجع مجموعة موارد Azure Resource Manager وحذف الموارد .

  • يمكنك نشر ما يصل إلى 800 مثيل لنوع مورد في كل مجموعة موارد. يُستثنى بعض أنواع الموارد من حد الـ 800 مثيل. لمزيد من المعلومات، راجع حدود مجموعة الموارد.

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

  • لإنشاء مجموعة موارد، يمكنك استخدام المدخل، أو PowerShell، أو Azure CLI، أو قالب ARM.

ما الموقع الذي يجب استخدامه لمجموعة الموارد الخاصة بي؟

عند إنشاء مجموعة موارد، تحتاج إلى توفير موقع لهذه المجموعة.

قد تتساءل، "لماذا تحتاج مجموعة الموارد إلى موقع؟ وإذا كان من الممكن أن تحتوي الموارد على مواقع مختلفة عن مجموعة الموارد، فلماذا يكون موقع مجموعة الموارد مهماً على الإطلاق؟"

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

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

إذا كانت منطقة مجموعة الموارد غير متوفرة مؤقتا، فقد لا تتمكن من تحديث الموارد في مجموعة الموارد لأن بيانات التعريف غير متوفرة. لا تزال الموارد في مناطق أخرى تعمل كما هو متوقع، ولكن قد لا تتمكن من تحديثها. قد ينطبق هذا الشرط أيضا على الموارد العمومية مثل Azure DNS ومناطق Azure DNS الخاصة وAzure Traffic Manager وAzure Front Door. يمكنك عرض الأنواع التي تتم إدارة بيانات التعريف الخاصة بها بواسطة Azure Resource Manager عبر قائمة أنواع جدول موارد Azure Resource Graph.

لتقليل تأثير الانقطاعات الإقليمية، نوصي بتحديد موقع الموارد في نفس المنطقة مثل مجموعة الموارد. عندما تكون منطقة مجموعة الموارد غير متوفرة، يتعذر على Azure Resource Manager تحديث بيانات تعريف المورد الخاص بك وحظر مكالمات الكتابة. من خلال تجميع الموارد ومنطقة مجموعة الموارد، فإنك تقلل من مخاطر عدم توفر المنطقة لأن الموارد وبيانات التعريف موجودة في منطقة واحدة بدلا من مناطق متعددة.

لمزيد من المعلومات حول إنشاء تطبيقات موثوقة، راجع تصميم تطبيقات Azure الموثوقة.

مرونة Azure Resource Manager

تم تصميم خدمة Azure Resource Manager من أجل المرونة والتوافر المستمر. Resource Manager وعمليات مستوى التحكم (الطلبات المرسلة إلى management.azure.com) في واجهة برمجة تطبيقات REST:

  • موزعة عبر المناطق. يحتوي Azure Resource Manager على مثيل منفصل في كل منطقة من مناطق Azure، ما يعني أن فشل مثيل Azure Resource Manager في منطقة واحدة لا يؤثر على توفر Azure Resource Manager أو خدمات Azure الأخرى في منطقة أخرى. على الرغم من توزيع Azure Resource Manager عبر المناطق، فإن بعض الخدمات إقليمية. يعني هذا التمييز أنه في حين أن المعالجة الأولية لعملية وحدة التحكم مرنة، فقد يكون الطلب عرضة للانقطاعات الإقليمية عند إعادة توجيهها إلى الخدمة.

  • مُوزّعة في مناطق التوفر (وكذلك القطاعات) في المواقع التي لديها مناطق توافر متعددة. يضمن هذا التوزيع أنه عندما تفقد منطقة منطقة واحدة أو أكثر، يمكن أن يفشل Azure Resource Manager إما في منطقة أخرى أو إلى منطقة أخرى للاستمرار في توفير إمكانية وحدة التحكم للموارد.

  • لا تعتمد على مركز بيانات منطقي واحد.

  • لا يتم إنزالها إطلاقاً إلى أنشطة الصيانة.

تنطبق هذه المرونة على الخدمات التي تتلقى الطلبات من خلال Resource Manager. على سبيل المثال، يستفيد مفتاح المخزن من هذه المرونة.

حل العمليات المتزامنة

عندما تحاول عمليتان أو أكثر تحديث نفس المورد في نفس الوقت، يكتشف Azure Resource Manager التعارض ويسمح بإكمال عملية واحدة فقط بنجاح. يقوم Azure Resource Manager بحظر العمليات الأخرى وإرجاع خطأ.

يمكن أن تتسبب تحديثات الموارد المتزامنة في نتائج غير متوقعة. يضمن هذا القرار أن تكون تحديثاتك محددة وموثوقة. أنت تعرف حالة مواردك وتجنب أي عدم تناسق أو فقدان للبيانات.

لنفترض أن لديك طلبين (A وB) يحاولان تحديث نفس المورد في نفس الوقت. إذا انتهى الطلب أ قبل الطلب ب، ينجح الطلب أ ويفشل الطلب ب. يقوم الطلب ب بإرجاع الخطأ 409. بعد الحصول على رمز الخطأ هذا، يمكنك الحصول على الحالة المحدثة للمورد وتحديد ما إذا كنت تريد إعادة إرسال الطلب B.

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