اختر خدمة حاوية Azure
يقدم Azure مجموعة من خدمات استضافة الحاويات المصممة لاستيعاب أحمال العمل المختلفة والبنى ومتطلبات العمل. يمكن أن يساعدك دليل تحديد خدمة الحاوية هذا على فهم خدمة حاوية Azure الأنسب لسيناريوهات ومتطلبات حمل العمل.
إشعار
في هذا الدليل، يشير مصطلح حمل العمل إلى مجموعة من موارد التطبيق التي تدعم هدف العمل أو تنفيذ عملية تجارية. يستخدم حمل العمل خدمات متعددة، مثل واجهات برمجة التطبيقات ومخازن البيانات، التي تعمل معا لتقديم وظائف محددة من طرف إلى طرف.
كيفية استخدام هذا الدليل
يتضمن هذا الدليل مقالتين: مقالة المقدمة هذه ومقالة أخرى حول الاعتبارات التي تتم مشاركتها عبر جميع أنواع حمل العمل.
إشعار
إذا لم تكن ملتزما بعد بالتعبئة في حاويات، فشاهد اختيار خدمة حساب Azure للحصول على معلومات حول خيارات الحوسبة الأخرى التي يمكنك استخدامها لاستضافة حمل العمل الخاص بك.
توضح مقالة المقدمة هذه خدمات حاويات Azure الموجودة في نطاق هذا الدليل وكيفية مقارنة نماذج الخدمة من حيث المفاضلات بين قابلية التكوين والحلول ذات الرأي، مثل النهج المدارة من قبل العميل مقابل النهج التي تديرها Microsoft. بعد تحديد الخدمات المرشحة استنادا إلى تفضيلات نموذج الخدمة، فإن الخطوة التالية هي تقييم الخيارات مقابل متطلبات حمل العمل من خلال مراجعة المقالة حول الاعتبارات المشتركة للشبكات والأمان والعمليات والموثوقية.
يأخذ هذا الدليل في الاعتبار المقايضات التي قد تحتاج إلى القيام بها، استنادا إلى المتطلبات التقنية وحجم وتعقيد حمل العمل الخاص بك وخبرة فريق حمل العمل الخاص بك.
خدمات حاوية Azure في نطاق هذا الدليل
يركز هذا الدليل على مجموعة فرعية من خدمات الحاوية التي تقدمها Azure حاليا. توفر هذه المجموعة الفرعية مجموعة ميزات ناضجة لتطبيقات الويب وواجهات برمجة التطبيقات والشبكات وإمكانية المراقبة وأدوات المطور والعمليات. تتم مقارنة خدمات الحاويات هذه:
Azure Container Apps هو نظام أساسي للتطبيقات يستند إلى Kubernetes مدار بالكامل يساعدك على نشر تطبيقات HTTP وغير HTTP من التعليمات البرمجية أو الحاويات دون تنسيق البنية الأساسية. لمزيد من المعلومات، راجع وثائق Azure Container Apps.
Azure Kubernetes Service (AKS) هي خدمة Kubernetes مدارة لتشغيل التطبيقات الحاوية. باستخدام AKS، يمكنك الاستفادة من الوظائف الإضافية والملحقات المدارة للحصول على قدرات إضافية مع الحفاظ على أوسع مستوى من قابلية التكوين. لمزيد من المعلومات، راجع وثائق AKS.
تطبيق الويب للحاويات هو ميزة من ميزات Azure App Service، وهي خدمة مدارة بالكامل لاستضافة تطبيقات الويب المستندة إلى HTTP مع صيانة البنية الأساسية المضمنة وتصحيح الأمان والتحجيم والأدوات التشخيصية. لمزيد من المعلومات، راجع وثائق خدمة التطبيقات .
للحصول على قائمة كاملة بجميع خدمات حاوية Azure، راجع صفحة فئة منتج خدمات الحاوية.
اعتبارات نموذج الخدمة
يوفر نموذج الخدمة أوسع نظرة ثاقبة على مستوى المرونة والتحكم الذي توفره أي خدمة حاوية Azure، مقابل بساطتها العامة وسهولة استخدامها.
للحصول على مقدمة عامة حول المصطلحات والمفاهيم حول نماذج الخدمة، بما في ذلك البنية الأساسية كخدمة (IaaS) والنظام الأساسي كخدمة (PaaS)، راجع المسؤولية المشتركة في السحابة.
مقارنة نماذج الخدمة لحلول حاوية Azure
AKS
كمختلط من IaaS وPaaS، تعطي AKS الأولوية للتحكم في البساطة. على الرغم من أن AKS يبسط إدارة البنية الأساسية الأساسية، إلا أن هذا النظام الأساسي المستند إلى الجهاز الظاهري لا يزال معرضا لتطبيقاتك ويتطلب حواجز وعمليات مناسبة، مثل التصحيح، لضمان الأمان واستمرارية الأعمال. يتم دعم البنية الأساسية للحساب بواسطة موارد Azure الإضافية التي تتم استضافتها مباشرة في اشتراكك، مثل موازنات تحميل Azure.
يوفر AKS أيضا الوصول إلى خادم Kubernetes API، والذي يمكنك من تخصيص تنسيق الحاوية وبالتالي نشر المشاريع من Cloud Native Computing Foundation (CNCF). وبالتالي، هناك منحنى تعليمي كبير لفرق حمل العمل الجديدة في Kubernetes. إذا كنت جديدا على الحلول المعبأة في حاويات، فقد يكون منحنى التعلم هذا رادعا. توفر حلول PaaS التالية حاجزا أقل أمام الدخول. يمكنك الانتقال إلى Kubernetes عندما تملي متطلباتك هذا النقل.
Azure Container Apps
توازن تطبيقات الحاوية، وهو عرض PaaS، بين التحكم والبساطة. يوفر كلا من خيارات الحوسبة بلا خادم والمخصصة، والتي تجرد الحاجة إلى تصحيح نظام التشغيل أو بناء حواجز حماية حول التطبيقات، بالنسبة إلى نظام التشغيل. تجرد Container Apps أيضا تماما واجهة برمجة تطبيقات تزامن الحاوية وتوفر مجموعة فرعية من وظائفها الرئيسية من خلال واجهات برمجة تطبيقات Azure التي قد يكون فريقك على دراية بها بالفعل. بالإضافة إلى ذلك، فإن دخول الطبقة 7 وتقسيم نسبة استخدام الشبكة واختبار A/B وإدارة دورة حياة التطبيق متاحة بالكامل خارج الصندوق.
تطبيق الويب للحاويات
تطبيق الويب للحاويات هو أيضا عرض PaaS، ولكنه يوفر المزيد من البساطة والتحكم أقل من تطبيقات الحاوية. فهو يلخص تنسيق الحاويات ولكنه لا يزال يوفر التحجيم المناسب وإدارة دورة حياة التطبيق وتقسيم نسبة استخدام الشبكة وتكامل الشبكة وإمكانية المراقبة.
اعتبارات نموذج الاستضافة
يمكنك استخدام موارد Azure، مثل مجموعات AKS، لاستضافة أحمال عمل متعددة. يمكن أن يساعدك القيام بذلك على تبسيط العمليات وبالتالي تقليل التكلفة الإجمالية. إذا اخترت هذا المسار، فإليك بعض الاعتبارات المهمة:
تستخدم AKS عادة لاستضافة أحمال عمل متعددة أو مكونات حمل عمل متباينة. يمكنك عزل أحمال العمل والمكونات هذه باستخدام وظائف Kubernetes الأصلية، مثل مساحات الأسماء وعناصر التحكم في الوصول وعناصر التحكم في الشبكة، لتلبية متطلبات الأمان.
يمكنك أيضا استخدام AKS في سيناريوهات حمل العمل الفردي إذا كنت بحاجة إلى الوظائف الإضافية التي توفرها واجهة برمجة تطبيقات Kubernetes وكان فريق حمل العمل لديك لديه خبرة كافية لتشغيل مجموعة Kubernetes. لا يزال بإمكان الفرق التي تتمتع بخبرة أقل في Kubernetes تشغيل مجموعاتها الخاصة بنجاح من خلال الاستفادة من الوظائف الإضافية والميزات المدارة من Azure، مثل الترقية التلقائية للمجموعة، لتقليل النفقات التشغيلية.
يجب استخدام تطبيقات الحاوية لاستضافة حمل عمل واحد بحد أمان مشترك. تحتوي تطبيقات الحاوية على حد منطقي واحد من المستوى الأعلى يسمى بيئة Container Apps، والتي تعمل أيضا كحد أمان محسن. لا توجد آليات للتحكم الإضافي في الوصول متعدد المستويات. على سبيل المثال، الاتصال داخل البيئة غير مقيد، وتشارك جميع التطبيقات مساحة عمل Log Analytics واحدة.
إذا كان حمل العمل يحتوي على مكونات متعددة وردود أمان متعددة، فوزع بيئات تطبيقات حاوية متعددة، أو ضع في اعتبارك AKS بدلا من ذلك.
تطبيق الويب للحاويات هو ميزة من ميزات App Service. تجمع App Service التطبيقات في حد فوترة يسمى خطة App Service. نظرا لأنه يمكنك تحديد نطاق التحكم في الوصول استنادا إلى الدور (RBAC) على مستوى التطبيق، فقد يكون من المغري استضافة أحمال عمل متعددة في خطة واحدة. ومع ذلك، نوصي باستضافة حمل عمل واحد لكل خطة لتجنب مشكلة الجيران المزعجين. تشترك جميع التطبيقات في خطة App Service واحدة في نفس الحساب المخصص والذاكرة والتخزين.
عند التفكير في عزل الأجهزة، يجب أن تكون على دراية بأن خطط App Service تعمل بشكل عام على البنية الأساسية التي تتم مشاركتها مع عملاء Azure الآخرين. يمكنك اختيار مستويات مخصصة للأجهزة الظاهرية المخصصة أو المستويات المعزولة للأجهزة الظاهرية المخصصة في شبكة ظاهرية مخصصة.
بشكل عام، يمكن لجميع خدمات حاويات Azure استضافة تطبيقات متعددة تحتوي على مكونات متعددة. ومع ذلك، فإن تطبيقات الحاوية وتطبيق الويب للحاويات أكثر ملاءمة لمكون حمل عمل واحد أو مكونات حمل عمل متعددة ذات صلة عالية تشترك في دورة حياة مماثلة، حيث يمتلك فريق واحد التطبيقات ويديرها.
إذا كنت بحاجة إلى استضافة مكونات تطبيق أو أحمال عمل متباينة أو غير مرتبطة على مضيف واحد، ففكر في AKS.
المفاضلة بين التحكم وسهولة الاستخدام
توفر AKS أكثر قابلية للتكوين، ولكن تأتي هذه القابلية للتكوين على حساب زيادة النفقات التشغيلية، مقارنة بالخدمات الأخرى. على الرغم من أن تطبيقات الحاويات وتطبيق الويب للحاويات هما خدمات PaaS التي لها مستويات مماثلة من الميزات التي تديرها Microsoft، إلا أن تطبيق الويب للحاويات يؤكد على البساطة لتلبية احتياجات جمهوره المستهدف: عملاء Azure PaaS الحاليين، الذين يجدون الواجهة مألوفة.
القاعدة الذهبية
بشكل عام، تميل الخدمات التي توفر المزيد من البساطة إلى ملاءمة العملاء الذين يفضلون التركيز بشكل أكبر على تطوير الميزات وأقل على البنية التحتية. تميل الخدمات التي توفر المزيد من التحكم إلى ملاءمة العملاء الذين يحتاجون إلى مزيد من قابلية التكوين ولديهم المهارات والموارد وتبرير الأعمال اللازمة لإدارة بنيتهم الأساسية الخاصة.
الاعتبارات المشتركة عبر جميع أحمال العمل
على الرغم من أن فريق حمل العمل قد يفضل نموذج خدمة معين، فقد لا يفي هذا النموذج بمتطلبات المؤسسة ككل. على سبيل المثال، قد يفضل المطورون نفقات تشغيلية أقل، ولكن قد تنظر فرق الأمان في هذا النوع من النفقات العامة الضرورية لتلبية متطلبات التوافق. تحتاج الفرق إلى التعاون لإجراء المفاضلات المناسبة.
يجب أن تدرك أن الاعتبارات المشتركة واسعة النطاق. قد تكون مجموعة فرعية فقط ذات صلة بك، اعتمادا ليس فقط على نوع حمل العمل ولكن أيضا على دورك داخل المؤسسة.
يوفر الجدول التالي نظرة عامة عالية المستوى على الاعتبارات، بما في ذلك مقارنات ميزات الخدمة. راجع الاعتبارات في كل فئة وقارنها بمتطلبات حمل العمل الخاص بك.
الفئة | نظرة عامة |
---|---|
اعتبارات الشبكات | تختلف الشبكات في خدمات حاويات Azure اعتمادا على تفضيلك للتبسيط مقابل قابلية التكوين. AKS قابل للتكوين بدرجة كبيرة، ما يوفر تحكما واسعا في تدفق الشبكة، ولكنه يتطلب المزيد من الجهد التشغيلي. توفر تطبيقات الحاوية ميزات الشبكات المدارة من Azure. إنها نقطة وسط بين AKS وWeb App للحاويات، والتي تم تصميمها للعملاء الذين هم على دراية بخدمة التطبيقات. والأهم من ذلك، يمكن أن يكون لقرارات تصميم الشبكة عواقب طويلة الأجل بسبب تحديات تغييرها دون إعادة توزيع أحمال العمل. تختلف عدة عوامل، مثل تخطيط عنوان IP ومسؤوليات موازنة التحميل وطرق اكتشاف الخدمة وقدرات الشبكات الخاصة، عبر هذه الخدمات. يجب عليك مراجعة كيفية تلبية الخدمات لمتطلبات شبكة محددة بعناية. |
اعتبارات الأمان | توفر جميع تطبيقات الحاويات وAKS وتطبيق الويب للحاويات التكامل مع عروض أمان Azure الرئيسية مثل Azure Key Vault والهويات المدارة. تقدم AKS ميزات إضافية مثل الحماية من تهديدات وقت التشغيل ونهج الشبكة. على الرغم من أنه قد يبدو أن خدمات النظام الأساسي كخدمة مثل تطبيقات الحاوية تقدم ميزات أمان أقل، ويرجع ذلك جزئيا إلى أن المزيد من مكونات البنية الأساسية تتم إدارتها بواسطة Azure ولا تتعرض للعملاء، ما يقلل من المخاطر. |
الاعتبارات التشغيلية | على الرغم من أن AKS تقدم أكبر قدر من التخصيص، إلا أنها تتطلب مدخلات تشغيلية أكبر. في المقابل، تتيح حلول النظام الأساسي كخدمة مثل تطبيقات الحاوية وتطبيق الويب للحاويات ل Azure معالجة مهام مثل تحديثات نظام التشغيل. تعد قابلية التوسع ومرونة SKU للأجهزة أمرا بالغ الأهمية. توفر AKS خيارات أجهزة مرنة، بينما توفر تطبيقات الحاويات وتطبيق الويب للحاويات تكوينات مجموعة. قابلية توسع التطبيق في AKS هي مسؤولية العميل وحدها. توفر تطبيقات الحاويات وتطبيق الويب للحاويات أساليب أكثر انسيابية. |
اعتبارات الموثوقية | إن تكوينات فحص صحة تطبيق الويب للحاويات وتطبيقات الحاويات أكثر انسيابية من تكوينات AKS، نظرا لأنها تستخدم واجهة برمجة تطبيقات Azure Resource Manager المألوفة. يتطلب AKS استخدام واجهة برمجة تطبيقات Kubernetes. كما يتطلب منك تحمل مسؤولية إضافية لإدارة قابلية توسع تجمع عقدة Kubernetes وتوافرها من أجل جدولة مثيلات التطبيق بشكل صحيح. تؤدي هذه المتطلبات إلى حمل إضافي ل AKS. وعلاوة على ذلك، فإن اتفاقيات مستوى الخدمة لتطبيقات الحاويات وتطبيق الويب للحاويات أكثر وضوحا من تلك الخاصة ب AKS، والتي لكل من وحدة التحكم وتجمعات العقد اتفاقيات مستوى الخدمة الخاصة بها وتحتاج إلى أن تتفاقم وفقا لذلك. توفر جميع الخدمات تكرار المنطقة في مراكز البيانات التي تقدمها. |
بعد مراجعة الاعتبارات السابقة، ربما لا تزال لم تجد الملائم المثالي. هذا طبيعي تماما
تقييم المفاضلات
اختيار خدمة سحابية ليس تمرين مباشر. نظرا لتعقيد حوسبة السحابة والتعاون بين العديد من الفرق وقيود الموارد التي تتضمن الأشخاص والميزانيات والوقت، فإن كل حل له مفاضلات.
يجب أن تدرك أنه بالنسبة لأي حمل عمل معين، قد تكون بعض المتطلبات أكثر أهمية من غيرها. على سبيل المثال، قد يفضل فريق التطبيق حل PaaS مثل Container Apps ولكنه يختار AKS لأن فريق الأمان الخاص بهم يتطلب عناصر تحكم شبكة رفض بشكل افتراضي بين مكونات حمل العمل المجمعة، وهي ميزة AKS فقط تستخدم نهج شبكة Kubernetes.
وأخيرا، لاحظ أن الاعتبارات المشتركة السابقة تتضمن المتطلبات الأكثر شيوعا ولكنها ليست شاملة. تقع على عاتق فريق حمل العمل مسؤولية التحقيق في كل متطلبات مجموعة ميزات الخدمة المفضلة قبل تأكيد القرار.
الخاتمة
يصف هذا الدليل الاعتبارات الأكثر شيوعا التي تواجهها عند اختيار خدمة حاوية Azure. تم تصميمه لتوجيه فرق حمل العمل في اتخاذ قرارات مستنيرة. تبدأ العملية باختيار نموذج خدمة سحابية، والذي يتضمن تحديد المستوى المطلوب من التحكم. السيطرة تأتي على حساب البساطة. بمعنى آخر، إنها عملية لإيجاد التوازن الصحيح بين البنية الأساسية المدارة ذاتيا والبنية الأساسية التي تديرها Microsoft.
يمكن للعديد من فرق حمل العمل اختيار خدمة حاوية Azure فقط استنادا إلى نموذج الخدمة المفضل: PaaS مقابل IaaS. تحتاج الفرق الأخرى إلى مزيد من التحقيق لتحديد كيفية معالجة الميزات الخاصة بالخدمة لحمل العمل أو المتطلبات التنظيمية.
يجب على جميع فرق حمل العمل استخدام هذا الدليل بالإضافة إلى دمج العناية الواجبة لتجنب اتخاذ قرارات صعبة التراجع. ومع ذلك، يجب أن تدرك أن القرار لا يتم تأكيده حتى يجرب المطورون الخدمة ويقررون بناء على التجربة بدلا من النظرية.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكتاب الرئيسيون:
- أندريه ديوز | مهندس عملاء أول
- ماركوس مارتينيز | مهندس خدمة أول
- جولي نغ | مهندس أول
مساهمون آخرون:
- مايكل ألبرتس | كاتب تقني
- مارتن غوشيفسكي | مهندس عملاء أول
- Don High | مهندس العملاء الرئيسي
- نيللي كيبوي | مهندس خدمة
- شوهونغ ليو | مهندس خدمة أول
- فيصل مصطفى | مهندس عملاء أول
- والتر مايرز | مدير هندسة العملاء الرئيسي
- سوناليكا روي | مهندس عملاء أول
- باولو سالفاتوري | مهندس العملاء الرئيسي
- فيكتور سانتانا | مهندس العملاء الرئيسي
الخطوة التالية
تعرف على المزيد حول الاعتبارات المعمارية المشتركة للخدمات المذكورة في هذه المقالة.