أعلنت AWS في 17 سبتمبر 2026 عن إتاحة Cluster Mode بشكل عام في خدمة AWS Elastic Beanstalk. يتيح النمط الجديد للفرق تقديم الشيفرة المصدرية أو ملف Docker أو صورة حاوية، بينما تتولى Elastic Beanstalk إنشاء بيئة التشغيل وإدارتها، بما في ذلك النشر والتوسعة والتصحيح والمراقبة والترقية طوال فترة تشغيل التطبيق.
يستهدف Cluster Mode الفرق التي تدير مجموعة من التطبيقات، بدلاً من تشغيل كل تطبيق في بيئة منفصلة بالكامل. وتستند البنية الجديدة إلى Amazon Elastic Kubernetes Service (Amazon EKS)، مع خط أساس تشغيلي واحد تديره Elastic Beanstalk. ووفق AWS، يمكن للتطبيقات مشاركة الموارد، ما قد يخفض التكلفة لكل تطبيق مع نمو المحفظة من دون إضافة عبء تشغيلي مماثل.
ما الذي يقدمه النمط الجديد؟
يمكن نشر تطبيقات Java و.NET وPython وNode.js وPHP وRuby وGo مباشرة من الشيفرة المصدرية، إذ تستخدم Elastic Beanstalk تقنية Cloud Native Buildpacks لإنشاء الحاويات عند الحاجة، من دون إلزام الفريق بكتابة Dockerfile أو إعادة هندسة التطبيق. كما يدعم النمط صور الحاويات الجاهزة، ويمكن إدارة النشر من خلال وحدة التحكم أو AWS CLI أو EB CLI أو AWS SDKs.
- استراتيجيات نشر تشمل النشر دفعة واحدة، والنشر المرحلي، والنشر غير القابل للتغيير، وتقسيم حركة المرور مع التراجع التلقائي عند الفشل.
- توسعة تلقائية قائمة على الأحداث، وتكامل مع AWS Secrets Manager لإدارة الأسرار.
- رصد مبني على OpenTelemetry، مع إمكانية التكامل مع أدوات المراقبة، ومنها Amazon CloudWatch.
- تحليل مدعوم بالذكاء الاصطناعي لمشكلات صحة البيئة، مع جمع سجلات من جانب الخدمة وتقديم توصيات لمعالجة الأعطال.
- دعم HTTPS افتراضياً عبر AWS Certificate Manager، مع وضع امتثال يتضمن أهلية HIPAA والتوافق مع PCI DSS والمواءمة مع SOC 1/2/3 وفق ما أعلنته AWS.
ما الذي يتغير عملياً للفرق؟
يختصر Cluster Mode المسافة بين نشر تطبيق تقليدي وإدارته ضمن بيئة حاويات مشتركة. فعند إنشاء أول بيئة لمجموعة شبكات فرعية معينة، تنشئ الخدمة عنقود EKS، وقد تستغرق العملية نحو عشر دقائق. أما عمليات النشر اللاحقة فتستفيد من العنقود الموجود، بحسب AWS. ويمكن تشغيل عدة خدمات مصغرة ضمن التطبيق نفسه، مع ضبط موارد مثل عدد النسخ، ووحدات المعالجة، والذاكرة، والمنفذ، ومسار فحص الصحة لكل خدمة.
الأهم أن الفرق لا تنتقل قسراً من النمط الحالي. تواصل بيئات Elastic Beanstalk Standard، المدعومة بـ Amazon EC2، عملها، ويمكن تشغيل البيئات القياسية وبيئات Cluster Mode جنباً إلى جنب داخل تطبيق Elastic Beanstalk نفسه. كما تنفذ الخدمة فحوص توافق قبل التغييرات، ما يتيح الترحيل التدريجي.
متى لا يكون Cluster Mode الخيار الأفضل؟
تقول AWS إن Standard Mode يظل مناسباً للتطبيقات المنفردة أو البيئات المنفردة، وأحمال Windows/.NET Framework التي تعمل على IIS، والتطبيقات التي لا يمكن تحويلها إلى حاويات. كما قد يكون أكثر ملاءمة للأحمال التي تنفق أقل من 500 دولار شهرياً، لأن رسوم مستوى التحكم في EKS والعلاوة المرتبطة بـ EKS Auto Mode قد تضيف تكلفة لا تعوضها مشاركة الموارد في تطبيق واحد.
التوفر والتكلفة
أصبح Cluster Mode متاحاً عموماً في جميع مناطق AWS التي تتوفر فيها Elastic Beanstalk. لا تفرض AWS رسماً إضافياً على نمط Cluster Mode نفسه، لكن العميل يدفع مقابل الموارد الأساسية التي تستهلكها التطبيقات، ومنها رسوم مستوى التحكم في EKS، وحوسبة EKS Auto Mode، وAmazon ECR، وAmazon CloudWatch. الخدمة غير مؤهلة لبرنامج AWS Free Tier.
قراءة certi.news: التغيير الفعلي ليس مجرد خيار نشر جديد، بل نقل مسؤولية تشغيل مجموعة تطبيقات حاوية إلى طبقة Elastic Beanstalk مع الاستفادة من EKS خلف الكواليس. هذا قد يكون مفيداً للفرق التي تريد توحيد التشغيل وتقليل العمل اليدوي، لكن القرار لا يُحسم بغياب رسم إضافي للخدمة؛ فتكلفة EKS والموارد المساندة، إضافة إلى توافق التطبيق مع الحاويات، تظل عوامل حاسمة. كما أن المصدر لا يقدم أرقام أداء أو مقارنة تكلفة فعلية بين النمطين، لذلك ينبغي اختبار العبء والتكلفة قبل ترحيل محفظة إنتاجية كبيرة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.