قم بتوسيع البنية الأساسية الخاصة بك في Azure DevTest Labs

يتطلب تنسيق التنفيذ الناجح لمختبرات DevTest على نطاق المؤسسة النظر في نقاط القرار الرئيسية، والتخطيط لنهج للتوزيع السريع وتنفيذ مختبرات Azure DevTest.

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

نقاط القرار الرئيسية

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

المجالات الثلاثة الأولى لتخطيط النطاق الأولي هي:

• الشبكات والأمان
• طوبولوجيا الاشتراك
• الأدوار والمسؤوليات

الشبكات والأمان

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

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

طوبولوجيا الاشتراك

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

• اشتراك واحد للمؤسسة بأكملها
• الاشتراك لكل مستخدم

بعد ذلك، نسلط الضوء على مزايا كل نهج.

اشتراك واحد

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

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

الاشتراك لكل مستخدم

يوفر الاشتراك المنفصل لكل مستخدم فرصًا متساوية للطيف البديل. تشمل مزايا وجود العديد من الاشتراكات ما يلي:

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

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

الأدوار والمسؤوليات

يشتمل إثبات المبدأ لـ DevTest Labs على ثلاثة أدوار أساسية مع مسؤوليات محددة – مالك الاشتراك ومالك DevTest Labs ومستخدم DevTest Labs ومساهم اختياريًا.

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

تنسيق تنفيذ DevTest Labs

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

الافتراضات

تفترض هذه المقالة أن لديك العناصر التالية في مكانها قبل تنفيذ برنامج DevTest Labs التجريبي:

• اشتراك Azure: يتمتع الفريق التجريبي بإمكانية الوصول إلى توزيع الموارد في اشتراك Azure. إذا كانت أحمال العمل عبارة عن تطوير واختبار فقط، فمن المستحسن تحديد عرض Enterprise DevTest للحصول على صور إضافية متاحة ومعدلات أقل على أجهزة Windows الظاهرية.
• الوصول المحلي: إذا لزم الأمر، فقد تم بالفعل تكوين الوصول المحلي. يمكن تحقيق الوصول المحلي عبر اتصال VPN من موقع إلى موقع أو عبر Express Route. قد يستغرق إنشاء الاتصال عبر الطريق السريع عادةً عدة أسابيع، ويوصى بتثبيت الطريق السريع قبل بدء المشروع.
• الفرق التجريبية: تم تحديد فريق (فرق) مشروع التطوير الأولي الذي يستخدم DevTest Labs جنباً إلى جنب مع أنشطة التطوير أو الاختبار المعمول بها ووضع المتطلبات/الأهداف/الأهداف لتلك الفرق.

المرحلة الأولى: إنشاء هيكل وتصميم الشبكة الأولي

يتمثل مجال التركيز الأول عند توزيع حل Azure DevTest Labs في إنشاء الاتصال المخطط للأجهزة الظاهرية. توضح الخطوات التالية الإجراءات اللازمة:

1. حدد initial IP address ranges التي تم تعيينها لاشتراك DevTest Labs في Azure. تتطلب هذه الخطوة التنبؤ بالاستخدام المتوقع في عدد الأجهزة الظاهرية بحيث يمكنك توفير كتلة كبيرة بما يكفي للتوسع في المستقبل.
2. حدد methods of desired access إلى DevTest Labs (على سبيل المثال، الوصول الخارجي / الداخلي). تتمثل النقطة الأساسية في هذه الخطوة في تحديد ما إذا كانت الأجهزة الظاهرية لها عناوين IP عامة (أي يمكن الوصول إليها من الإنترنت مباشرة).
3. تحديد وإنشاء methods of connectivity مع بقية بيئة السحابة Azure والمحلية. إذا تم تمكين التوجيه الإجباري باستخدام Express Route، فمن المحتمل أن تحتاج الأجهزة الظاهرية إلى تكوينات وكيل مناسبة لاجتياز جدار حماية الشركة.
4. إذا كان سيتم ربط الأجهزة الظاهرية بالمجال، فحدد ما إذا كانت تنضم إلى مجال مستند إلى السحابة (Microsoft Entra Directory Services على سبيل المثال) أو مجال محلي. بالنسبة إلى المحلي، حدد الوحدة التنظيمية (OU) داخل الدليل النشط التي تنضم إليها الأجهزة الظاهرية. بالإضافة إلى ذلك، تأكد من أن المستخدمين لديهم حق الوصول للانضمام (أو إنشاء حساب خدمة لديه القدرة على إنشاء سجلات الجهاز في المجال)

المرحلة 2: توزيع المعمل التجريبي

بمجرد وضع هيكل الشبكة في مكانه الصحيح، يمكن إنشاء المعمل الأول / التجريبي باتباع الخطوات التالية:

1. إنشاء بيئة DevTest Labs أولية.
2. تحديد صور VM وأحجامها المسموح بها للاستخدام مع المعمل. حدد ما إذا كان يمكن تحميل الصور المخصصة إلى Azure لاستخدامها مع DevTest Labs.
3. تأمين الوصول إلى المختبر من خلال إنشاء عنصر تحكم في الوصول الأولي المستند إلى الدور في Azure (Azure RBAC) للمختبر (مالكو المعمل ومستخدمي المعمل). نوصي باستخدام حسابات الدليل النشط المتزامنة مع معرف Microsoft Entra للهوية مع مختبرات DevTest.
4. قم بتكوين DevTest Labs لاستخدام نُهج مثل الجداول الزمنية أو إدارة التكلفة أو الأجهزة الظاهرية القابلة للمطالبة أو الصور المخصصة أو الصيغ.
5. أنشئ مستودعاً عبر الإنترنت مثل Azure Repos / Git.
6. اتخذ قراراً بشأن استخدام المستودعات العامة أو الخاصة أو كليهما. تنظيم قوالب JSON لعمليات التوزيع والاستدامة طويلة الأجل.
7. إذا لزم الأمر، فقم بإنشاء البيانات الاصطناعية المخصصة. هذه الخطوة اختيارية.

المعلم 3: التوثيق والدعم والتعلم والتحسين

قد تتطلب الفرق التجريبية الأولية دعماً متعمقاً للبدء. استخدم خبراتهم لضمان توفير التوثيق الصحيح والدعم للاستمرار في طرح Azure DevTest Labs.

1. تقديم الفرق التجريبية إلى موارد DevTest Labs الجديدة (العروض التوضيحية والوثائق)
2. بناءً على تجارب الفرق التجريبية، قم بتخطيط وتقديم الوثائق حسب الحاجة
3. إضفاء الطابع الرسمي على عملية إلحاق فرق جديدة (إنشاء وتكوين المختبرات، وتوفير الوصول، وما إلى ذلك)
4. بناءً على الاستيعاب الأولي، تحقق من أن التوقعات الأصلية لمساحة عنوان IP لا تزال معقولة ودقيقة
5. تأكد من اكتمال مراجعات الامتثال والأمان المناسبة

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

راجع المقالة التالية في هذه السلسلة: إدارة البنية الأساسية لـ Azure DevTest Labs