البنية المرجعية للمؤسسات DevTest Labs

توضح هذه المقالة البنية المرجعية لتوزيع Azure DevTest Labs في المؤسسة. تتضمن البنية العناصر الرئيسية التالية:

• الاتصالية المحلية من خلال Azure ExpressRoute
• بوابة سطح المكتب البعيد لتسجيل الدخول عن بعد إلى الأجهزة الظاهرية (VMs)
• الاتصالية إلى مستودع البيانات الاصطناعية الخاصة
• مكونات النظام الأساسي الأخرى كخدمة (PaaS) التي تستخدمها المختبرات

Architecture

يوضح المخطط التالي التوزيع النموذجي لمؤسسة DevTest Labs. تربط هذه البنية العديد من المختبرات في اشتراكات Azure المختلفة بشبكة الشركة الداخلية.

مكوّنات DevTest Labs

تجعل DevTest Labs من السهل والسريع على المؤسسات إتاحة الوصول إلى موارد Azure. يحتوي كل مختبر على البرامج كخدمة (SaaS) والبنية التحتية كخدمة (IaaS) وموارد PaaS. بإمكان مستخدمي المختبر إنشاء وتكوين الأجهزة الظاهرية وبيئات PaaS والبيانات الاصطناعية للجهاز الظاهري.

في المخطط السابق، يعرض Team Lab 1 في Azure Subscription 1 مثالاً على مكونات Azure التي يمكن للمختبرات الوصول إليها واستخدامها. للمزيد من المعلومات، راجع معلومات عن DevTest Labs.

Connectivity components

تحتاج إلى اتصالية محلية في حال كان يجب على مختبراتك الوصول إلى موارد المؤسسة الداخلية. السيناريوهات الشائعة:

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

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

محليًا، تمكن بوابة سطح المكتب البعيد اتصالات بروتوكول سطح المكتب البعيد الصادر (RDP) بـDevTest Labs. عادة ما تحظر المؤسسات الاتصالات الصادرة في جدار حماية الشركة. لتمكين الاتصالية، بإمكانك:

• استخدام بوابة سطح المكتب البعيد، والسماح لعنوان IP الثابت الخاص بموازنة تحميل البوابة.
• استخدام التوجيه القسري لأسفل لإعادة توجيه كل نسبة استخدام الشبكة RDP مرة أخرى عبر اتصال ExpressRoute أو اتصال الشبكة الظاهرية الخاصة من موقع إلى موقع. التوجيه القسري لأسفل هو وظيفة شائعة لتوزيع DevTest Labs على نطاق المؤسسة.

Networking components

في هذه البنية، يوفر معرف Microsoft Entra إدارة الهوية والوصول عبر جميع الشبكات. في العادة، يكون لدى الأجهزة الظاهرية للمختبر حساب إداري محلي للوصول. إذا كان هناك مجال Microsoft Entra ID أو محلي أو Microsoft Entra Domain Services متوفر، يمكنك الانضمام إلى الأجهزة الظاهرية للمختبر إلى المجال. بإمكان المستخدمين بعد ذلك استخدام هوياتهم المستندة إلى المجال للاتصال بالأجهزة الظاهرية.

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

نظرًا إلى أن DevTest Labs تستخدم Azure Virtual Network بشكلٍ مباشر، فلا توجد قيود على كيفية إعداد البنية الأساسية للشبكة. بإمكانك إعداد مجموعة أمان شبكة لتقييد نسبة استخدام الشبكة على السحابة استنادًا إلى عناوين IP المصدر والوجهة. على سبيل المثال، بإمكانك السماح فقط بنسبة استخدام الشبكة الناشئة من شبكة الشركة إلى شبكات المختبر.

Scalability considerations

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

• Resource groups. تنشئ DevTest Labs مجموعة موارد لكل جهاز ظاهري جديد، وينشئ مستخدمو المختبر البيئات في مجموعات الموارد. يمكن أن تحتوي الاشتراكات على ما يصل إلى 980 مجموعة موارد، وهذا هو الحد الأقصى للأجهزة الظاهرية والبيئات في الاشتراك.

  يمكن أن تساعدك استراتيجيتان على البقاء ضمن حدود مجموعة الموارد:

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

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

• Storage accounts. يأتي كل معمل في DevTest Labs بحساب تخزين. حصة Azure النسبية لعدد حسابات التخزين لكل منطقة لكل اشتراك هي 250 بشكل افتراضي. لذا فإن الحد الأقصى لعدد مختبرات DevTest في منطقة واحدة هو 250 أيضًا. مع زيادة الحصة النسبية، يمكنك إنشاء ما يصل إلى 500 حساب تخزين لكل منطقة. لمزيد من المعلومات، راجع زيادة حصص حساب Azure Storage.

• Role assignments. يمنح تعيين الدور المستخدم أو المسؤول الأساسي إمكانية الوصول إلى مورد. يحتوي Azure على حد 4,000 تعيين دور لكل اشتراك.

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

• API reads/writes. بإمكانك أتمتة Azure وDevTest Labs باستخدام واجهات برمجة تطبيقات REST وPowerShell وAzure CLI وAzure SDK. يسمح كل اشتراك Azure بما يصل إلى 12,000 طلب قراءة و1,200 طلب كتابة في الساعة. إذا قمت بأتمتة DevTest Labs، فقد تصل إلى الحد الأقصى لطلبات واجهة برمجة التطبيقات.

Manageability considerations

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

فيما يلي بعض الأمثلة على استخدام البرمجة النصية في عمليات توزيع DevTest Labs:

• تغيير إعدادات مختبر. حدِّث إعداد مختبر معين عبر جميع المختبرات باستخدام برامج PowerShell النصية أو Azure CLI أو واجهات برمجة تطبيقات REST. على سبيل المثال، حدِّث كل المختبرات للسماح بحجم مثيل جهاز ظاهري جديد.

• تحديث الرموز المميزة للوصول الشخصي لمستودع القطع الاصطناعية (PATs). تنتهي صلاحية PATs لمستودعات Git عادة خلال 90 يومًا أو عام واحد أو عامين. من المهم توسيع PAT لضمان الاستمرارية. أو يمكنك إنشاء PAT جديد واستخدام الأتمتة لتطبيقه على جميع المختبرات.

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

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

يمكنك إدارة موارد Azure لمختبرات DevTest بنفس الطريقة التي تفعل بها لأغراض أخرى. على سبيل المثال، ينطبق نهج Azure على الأجهزة الظاهرية التي تقوم بإنشائها في المختبر. باستطاعة Microsoft Defender للسحابة الإبلاغ عن توافق الجهاز الظاهري للمختبر. من الممكن أن يوفر Azure Backup نسخًا احتياطية منتظمة للأجهزة الظاهرية للمختبر.

Security considerations

تستفيد DevTest Labs بشكل تلقائي من ميزات أمان Azure المضمنة. لطلب إنشاء اتصالات سطح المكتب البعيد الواردة من شبكة الشركة فقط، بإمكانك إضافة مجموعة أمان شبكة إلى الشبكة الافتراضية على بوابة سطح المكتب البعيد.

هناك اعتبار الأمان آخر، وهو مستوى الإذن الذي تمنحه لمستخدمي المختبر. يستعمل مالكو المختبر ميزة التحكم في الوصول استناداً إلى الدور في Azure (Azure RBAC) لتعيين الأدوار للمستخدمين وتعيين أذونات مستوى الوصول والموارد. أذونات DevTest Labs الأكثر انتشارًا هي المالك والمساهم والمستخدم. بإمكانك أيضًا إنشاء أدوار مخصصة وتعيينها. للمزيد من المعلومات، راجع إضافة مالكين مستخدمين في Azure DevTest Labs.

Next step

انظر المقالة التالية في هذه السلسلة: تقديم دليل على المفهوم