مشاركة عبر

إدارة البنية الأساسية لـ Azure DevTest Labs

  • مقالة

تتناول هذه المقالة مواءمة الموارد وإدارتها لـ DevTest Labs داخل مؤسستك.

الموارد

محاذاة موارد DevTest Labs ضمن اشتراك Azure

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

  • كيف يمكن قياس التكلفة المرتبطة بدورة حياة تطوير التطبيق؟
  • كيف تقوم المؤسسة بمواءمة عرض الخدمة المقترحة مع نهج أمان الشركة؟
  • هل التجزئة مطلوبة لفصل بيئات التطوير والتشغيل؟
  • ما هي عناصر التحكم التي يتم إدخالها لتسهيل الإدارة والاستقرار والنمو على المدى الطويل؟

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

تتمثل الممارسة الثانية الموصى بها في تمكين اشتراك DevTest داخل مدخل Azure Enterprise. يسمح للمؤسسة بتشغيل أنظمة تشغيل العميل غير المتوفرة عادة في اشتراك مؤسسة Azure. بعد ذلك، استخدم برنامج المؤسسة، إذ تدفع فقط مقابل الحساب ولا تقلق بشأن الترخيص. إنه يضمن أن فوترة الخدمات المخصصة، بما في ذلك صور المعرض في IaaS مثل Microsoft SQL Server، تعتمد على الاستهلاك فقط. يمكن العثور على تفاصيل حول اشتراك Azure DevTest هنا لعملاء اتفاقية Enterprise (EA) وهنا لعملاء الدفع حسب وقت الاستخدام.

رسم تخطيطي يوضح كيفية محاذاة الموارد مع الاشتراكات.

يوفر هذا النموذج للمؤسسة المرونة اللازمة لتوزيع Azure DevTest Labs على نطاق واسع. يمكن للمؤسسة دعم مئات المعامل لمختلف وحدات الأعمال مع 100 إلى 1000 جهاز ظاهري يعمل بالتوازي. يرقّي لمفهوم حل مختبر مؤسسي مركزي يمكنه مشاركة نفس مبادئ إدارة التكوين و عنصر تحكم الأمان.

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

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

عدد المستخدمين لكل مختبر والمعامل لكل مؤسسة

يجب أن ترتبط وحدات الأعمال ومجموعات التطوير المرتبطة بنفس مشروع التطوير بنفس المختبر. يسمح بتطبيق نفس أنواع السياسات والصور وسياسات إيقاف التشغيل على المجموعتين.

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

يمكنك أيضاً استخدام مختبر لمشروع معين ضمن مشاريعDevOps Azure. بعد ذلك، يمكنك تطبيق الأمان من خلال مجموعة Microsoft Entra محددة، والتي تسمح بالوصول إلى كل مجموعة من الموارد. يمكن أن تكون الشبكة الافتراضية المعينة للمختبر حد آخر لدمج المستخدمين.

منع حذف الموارد

تعيين الأذونات على مستوى المختبر بحيث يمكن للمستخدمين المعتمدين فقط حذف الموارد أو تغيير نهج المختبر. يجب وضع المطورين ضمن مجموعة DevTest Labs Users. يجب أن يكون المطور الرئيسي أو مسئول البنية التحتية هو مالك مختبرات DevTest. نوصي أن يكون لديك اثنين فقط من أصحاب المعامل. يمتد هذا النهج نحو مستودع التعليمات البرمجية لتجنب التلف. استخدامات المختبر لها حقوق استخدام الموارد ولكن لا يمكنها تحديث نهج المختبر. راجع المقالة التالية التي تسرد الأدوار والحقوق التي تمتلكها كل مجموعة مضمنة داخل المختبر: إضافة الملاك والمستخدمين في مختبرات Azure DevTest.

إدارة التكلفة والملكية

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

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

تساعدك العديد من الميزات المضمنة في DevTest Labs على تحسين التكلفة. راجع مقالات إدارة التكلفة والحدود والسياسات للحد من أنشطة المستخدمين.

إذا كنت تستخدم DevTest Labs للتطوير واختبار أحمال العمل، ففكر في استخدام ميزات اشتراك Enterprise Dev/Test التي تشكل جزءًا من اتفاقية Enterprise. أو إذا كنت عميل Pay as you Go، ففكر في عرض Pay-as-you go DevTest.

يوفر هذا النهج العديد من المزايا:

  • أسعار Special lower Dev/Test على أجهزة Windows الظاهرية والخدمات السحابية وHDInsight وخدمة التطبيقات وتطبيقات المنطق
  • أسعار اتفاقية Enterprise الرائعة (EA) على خدمات Azure الأخرى
  • صور Access to exclusive Dev/Test في المعرض، بما في ذلك Windows 8.1 وWindows 10

يمكن فقط لمشتركي Visual Studio النشطين (الاشتراكات العادية والاشتراكات السحابية السنوية والاشتراكات السحابية الشهرية) استخدام موارد Azure التي تعمل ضمن اشتراك enterprise Dev/Test. مع ذلك، يمكن للمستخدمين النهائيين الوصول إلى التطبيق لتقديم الملاحظات أو إجراء اختبار القبول. يمكنك استخدام الموارد ضمن هذا الاشتراك فقط لتطوير التطبيقات واختبارها. لا يوجد ضمان لوقت التشغيل.

إذا قررت استخدام عرض DevTest، فاستخدم هذه الميزة حصرياً لتطوير تطبيقاتك واختبارها. لا يحمل الاستخدام داخل الاشتراك SLA المدعومة ماليًا، باستثناء استخدام Azure DevOps وHockeyApp.

تحديد الوصول المستند إلى الدور عبر مؤسستك

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

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

يجب أن يكون مالكو موارد DevTest Labs قريبين من فريق المشروع أو التطبيق. يفهم هؤلاء المالكون متطلبات الجهاز والبرامج. في معظم المؤسسات، يكون مالك مورد DevTest Labs قائد التطوير أو المشروع. يمكن لهذا المالك إدارة المستخدمين والنهج داخل بيئة المختبر ويمكنه إدارة جميع الأجهزة الظاهرية في بيئة DevTest Labs.

إضافة أعضاء فريق المشروع والتطبيق إلى دور مستخدمي DevTest Labs. يمكن لهؤلاء المستخدمين إنشاء الأجهزة الظاهرية (بما يتماشى مع نهج المختبر ومستوى الاشتراك). يمكن للمستخدمين أيضاً إدارة أجهزتهم الظاهرية الخاصة، ولكن لا يمكنهم إدارة الأجهزة الظاهرية التابعة لمستخدمين آخرين.

لمزيد من المعلومات، راجع Azure Enterprise scaffold - حوكمة الاشتراك الإلزامية.

نهج الشركة وتوافقها

يوفر هذا القسم إرشادات حول إدارة نهج الشركة والامتثال للبنية الأساسية ل Azure DevTest Labs.

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

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

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

مستودع واحد أو عِدة مستودعات

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

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

نُهج أمان الشركة

يجوز للمؤسسة تطبيق نهج أمان الشركة من خلال:

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

تكامل البيانات

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

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

الطبقة الأولى من عناصر التحكم للوصول البعيد هي تطبيق نهج الوصول البعيد من خلال اتصال VPN غير متصل مباشرة بالمختبر.

الطبقة الثانية من عناصر التحكم هي تطبيق مجموعة من كائنات نهج المجموعة التي تمنع النسخ واللصق من خلال سطح المكتب البعيد. يمكن تطبيق نهج شبكة اتصال لعدم السماح للخدمات الصادرة من البيئة مثل FTP وخدمات RDP خارج البيئة. قد يفرض التوجيه المعرف من قبل المستخدم حركة مرور شبكة Azure مرة أخرى إلى أماكن العمل، ولكن التوجيه لا يمكن أن يفسر جميع عناوين URL التي قد تسمح بتحميل البيانات ما لم يتم التحكم فيها من خلال وكيل لمسح المحتوى والجلسات. يمكن تقييد بروتوكولات الانترنت العامة داخل الشبكة الافتراضية التي تدعم مختبر DevTest لعدم السماح بالاستعانة بمورد شبكة خارجي.

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

ترحيل التطبيقات والتكامل

بمجرد إنشاء بيئة مختبر التطوير/الاختبار، تحتاج إلى التفكير في الأسئلة التالية:

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

صور Azure Marketplace مقابل الصور المخصصة

يلزم استخدام Azure Marketplace بشكل افتراضي إلا إذا كانت لديك مخاوف أو متطلبات تنظيمية محددة. بعض الأمثلة الشائعة تتضمن:

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

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

صيغة مقابل صورة مخصصة

عادةً ما يكون العامل الحاسم في هذا السيناريو هو التكلفة وإعادة الاستخدام.

يمكنك تقليل التكلفة عن طريق إنشاء صورة مخصصة إذا:

  • طلب العديد من المستخدمين أو المختبرات الصورة.
  • احتوت الصورة المطلوبة على الكثير من البرامج أعلى الصورة الأساسية.

يعني هذا الحل أنك تُنشئ الصورة مرة واحدة. تقلل الصورة المخصصة من وقت إعداد الجهاز الظاهري. لا تتحمل تكاليف نتيجة تشغيل الجهاز الظاهري أثناء الإعداد.

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

أنماط إعداد تكوين الشبكة

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

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

نقل البيانات الصادرة - إذا أردت منع الأجهزة الظاهرية من الوصول إلى الإنترنت العام مباشرةً وفرض نقل البيانات عبر جدار حماية الشركة، فيمكنك توجيه نقل البيانات محليًا عبر Azure ExpressRoute أو VPN باستخدام التوجيه الإجباري.

إشعار

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

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

شبكة ظاهرية جديدة أو موجودة

إذا كانت الأجهزة الظاهرية بحاجة إلى التفاعل مع البنية الأساسية الموجودة، فيجب التفكير في استخدام شبكة ظاهرية موجودة داخل بيئة "مختبرات DevTest". إذا كنت تستخدم ExpressRoute، فصغّر عدد الشبكات الظاهرية والشبكات الفرعية حتى لا تُجزئ مساحة عنوان IP المُعينة لاشتراكاتك. ضع في اعتبارك أيضًا استخدام نمط شبكة ظاهرية متماثل هنا (Hub-Spoke model). يتيح هذا الأسلوب اتصال الشبكة الظاهرية والشبكة الفرعية عبر الاشتراكات داخل منطقة معينة.

يمكن أن يكون لكل بيئة "مختبرات DevTest" شبكتها الظاهرية الخاصة، ولكن هناك حدود لعدد الشبكات الظاهرية لكل اشتراك. المبلغ الافتراضي هو 50، على الرغم من أن هذا الحد يمكن رفعه إلى 100.

IP مشترك أو عام أو خاص

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

إشعار

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

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

حدود المختبر

هناك العديد من الحدود المعملية التي يجب أن تكون على علم بها. يتم وصف هذه الحدود في الأقسام التالية.

حدود المختبرات لكل اشتراك

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

حدود الأجهزة الظاهرية لكل مختبر

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

حدود عدد الأجهزة الظاهرية لكل مستخدم أو معمل

عند مراعاة عدد الأجهزة الظاهرية لكل مستخدم أو لكل مختبر، هناك ثلاثة مخاوف رئيسية:

  • التكلفة الإجمالية التي يمكن للفريق إنفاقها على الموارد في المختبر. من السهل تدوير العديد من الأجهزة. تتمثل إحدى طرق التحكم في التكاليف في الحد من عدد الأجهزة الظاهرية لكل مستخدم أو لكل مختبر
  • يتأثر العدد الإجمالي للأجهزة الظاهرية في المختبر بالحصص مستوى الاشتراك المتاحة. أحد الحدود القصوى هو 800 مجموعة موارد لكل اشتراك. تنشئ "مختبرات DevTest" حاليًا مجموعة موارد جديدة لكل جهاز ظاهري (ما لم تُستخدم عناوين IP العامة المشتركة). إذا كان هناك 10 مختبرات في اشتراك ما، يمكن أن تناسب المختبرات ما يقرب من 79 جهازًا ظاهريًا في كل مختبر (800 حد أقصى - 10 مجموعات موارد للمختبرات العشرة نفسها) = 79 جهازًا ظاهريًا لكل مختبر.
  • إذا كان المختبر متصلًا محليًا عبر Express Route (على سبيل المثال)، فهناك مساحات عناوين IP محددة متاحة للشبكة الظاهرية/الشبكة الفرعية. للتأكد من عدم فشل إنشاء الأجهزة الظاهرية في المختبر (خطأ: لا يمكن الحصول على عنوان IP)، يمكن لمالكي المختبر تحديد الحد الأقصى للأجهزة الظاهرية لكل مختبر بما يتماشى مع مساحة عنوان IP المتوفرة.

استخدام قوالب Azure Resource Manager

وزّع قوالب Azure Resource Manager باتباع الخطوات الواردة في استخدام "مختبرات Azure DevTest" لبيئات الاختبار. بشكلٍ أساسي، يمكنك التحقق من قوالب "إدارة الموارد" في مستودع GitHub Git أو Azure Repos، وإضافة مستودع خاص للقوالب إلى المختبر.

قد لا يكون هذا السيناريو مفيدًا إذا كنت تستخدم "مختبرات DevTest" لاستضافة أجهزة التطوير. استخدم هذا السيناريو لإنشاء بيئة تشغيل مرحلي تُمثل الإنتاج.

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