مشاركة عبر

مناطق هبوط Azure لمنصات التطبيقات الحديثة

  • مقالة

توجه منهجية Ready لإطار عمل اعتماد السحابة إنشاء جميع بيئات Azure باستخدام مناطق هبوط Azure. توفر مناطق هبوط Azure العديد من خيارات التنفيذ المبنية حول مجموعة من مناطق التصميم الشائعة.

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

البنية المفاهيمية لمنطقة Azure المنتقل إليها

عند إعداد أي بيئة لاعتماد السحابة المستدامة، نستخدم البنية المفاهيمية لمناطق هبوط Azure لتمثيل ما يجب أن تبدو عليه حالة النهاية المستهدفة في Azure، كما هو موضح أدناه.

رسم تخطيطي يوضح بنية مفاهيمية لمنطقة Azure المنتقل إليها

لمزيد من المعلومات حول مناطق التصميم المسماة A-I في المرئيات، راجع مناطق تصميم البيئة.

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

الاعتبارات الاستراتيجية والتخطيطية للمناطق المنتقل إليها لمنصات التطبيقات

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

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

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

إظهار نطاق قابل للتنفيذ

لتحقيق أقصى قدر من الإخراج أثناء عمليات التنفيذ الأولية، يركز الجزء المتبقي من هذا الدليل على تنفيذ خدمة Azure Kubernetes (AKS) مع القدرة على إضافة تراكب لخدمة تطبيقات Azure على Kubernetes باستخدام Azure Arc. يضيق هذا النهج نطاق الخيارات من خلال توفير بنية مرجعية وتنفيذ.

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

اعتبارات خيار التنفيذ

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

  • استراتيجية منطقة Azure المنتقل إليها الحالية: إذا كانت مؤسستك قد نفذت بالفعل استراتيجية منطقة هبوط Azure، فإن سيناريو الأنظمة الأساسية للتطبيقات الحديثة يجب أن يلتزم على الأرجح بالاستراتيجية الحالية. وإلا، اختر أحد الإجراءات التالية كخطوة أولى نحو بيئات المنطقة المنتقل إليها القابلة للتكرار.
  • ابدأ صغيرا وقم بتوسيعه باستخدام أساس AKS: توفر البنية الأساسية لمجموعة Azure Kubernetes Service (AKS) نهجا مثبتا لتوزيع بيئة AKS الأولى.
    • يتم استخدام هذا الخيار بشكل شائع عندما تكون فرق المطور أو DevOps مسؤولة مباشرة عن عمليات المجموعات والبيئات السحابية والتطبيقات.
    • يمكن إضافة العمليات وأفضل الممارسات في منهجيات Ready, Govern and Manage في Cloud Adoption Framework لاحقا لإعداد هذا النشر للعمليات المركزية والمضيفين المشتركين.
  • مناطق الهبوط على نطاق المؤسسة: يتضمن مسرع منطقة هبوط AKS تنفيذا مرجعيا لنشر مثيل لخط أساس AKS في منطقة هبوط على نطاق المؤسسة لدعم النظام الأساسي AKS الخاص بك ضمن التكوين البيئي المحدد الذي تتطلبه حلول المنطقة المنتقل إليها على نطاق المؤسسة الأوسع.
    • هذا هو الخيار الأكثر شيوعا عندما يجب تطبيق متطلبات التوافق أو الحوكمة أو الأمان مركزيا على أي بيئة حاوية.
    • كما أنه الخيار الأكثر شيوعا للفرق المركزية التي تقدم عمليات استضافة الحاويات، ما يسمح للمطورين بالتركيز بشكل أكبر على التطبيق وأقل على التطوير ل Kubernetes.

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

تراكبات النظام الأساسي للتطبيق

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

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

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

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

مناطق تصميم منطقة هبوط Azure

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

الخطوة التالية: ترحيل أحمال العمل إلى الأنظمة الأساسية للتطبيقات الحديثة

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