الحوسبة السحابية
8 دقائق قراءةالعودة إلى المدونة
تشغيل تطبيق حديث لا يتوقف عند كتابة الكود.
فبعد الانتهاء من تطوير التطبيق، تظهر مجموعة أخرى من الأسئلة: أين سيعمل التطبيق؟ كيف سيتم نشره؟ ماذا يحدث عندما يزداد عدد المستخدمين؟ وكيف يمكن إدارة الموارد ومراقبة التطبيق دون الدخول في تفاصيل البنية التحتية في كل مرة؟
أصبحت Containers واحدة من الطرق الشائعة لتشغيل التطبيقات بشكل أكثر مرونة وقابلية للنقل. لكن مع زيادة عدد الحاويات، تظهر مشكلة جديدة: من سيتولى نشرها وتنظيمها ومراقبتها وتوسيعها؟
هنا يأتي دور Containers as a Service (CaaS)، وهو نموذج من الخدمات السحابية يوفّر بيئة لإدارة وتشغيل التطبيقات المبنية على الحاويات، مع تقليل جزء كبير من التعقيد المرتبط بإدارة البنية التحتية الأساسية.
لفهم سبب ظهور CaaS، من المفيد أن نعود خطوة إلى الوراء.
في البدايات، كانت التطبيقات تعمل مباشرة على Physical Servers. وكان تشغيل تطبيق جديد يعني توفير خادم فعلي، وإعداد نظام التشغيل، وتخصيص الموارد، ثم تثبيت التطبيق وإعداده.
لاحقًا ظهرت Virtual Machines (VMs)، وأصبح من الممكن تشغيل عدة بيئات افتراضية على الخادم نفسه، مع قدر أكبر من العزل والاستفادة من الموارد.
ثم ظهرت Containers لتقدم طريقة أخف لتغليف التطبيق مع المكونات التي يحتاج إليها للتشغيل.
يمكن تبسيط الرحلة هكذا:
Physical Servers → Virtual Machines → Containers → Container Orchestration → CaaS
كل مرحلة جاءت لمعالجة جزء من التعقيد الموجود في المرحلة السابقة. لكن Containers لم تلغِ المشكلة بالكامل؛ بل نقلتها إلى مستوى آخر.
يمكن النظر إلى الـ Container باعتبارها بيئة معزولة تحتوي على التطبيق والمكونات اللازمة لتشغيله، بحيث يمكن نقلها وتشغيلها في بيئات مختلفة دون الحاجة إلى إعادة إعداد التطبيق من البداية في كل مرة.
توضح وثائق Kubernetes أن الحاويات تُستخدم لتغليف التطبيق مع اعتمادات التشغيل، وأن هذا التوحيد يساعد على تشغيل التطبيق بسلوك متقارب عبر بيئات مختلفة.
· قابلية النقل بين البيئات.
· سرعة تشغيلها مقارنة بالبيئات الافتراضية الكاملة في كثير من السيناريوهات.
· سهولة تكرار التطبيق.
· عزل التطبيقات عن بعضها.
· إمكانية دمجها مع عمليات CI/CD.
لكن ماذا يحدث عندما لا يكون لدينا Container واحد أو اثنان، وإنما عشرات أو مئات الحاويات؟ هنا تبدأ المشكلة الحقيقية.
تخيل أن لديك تطبيقًا يتكون من عدة خدمات، وكل خدمة تعمل داخل Container مستقل. في البداية قد يبدو الأمر بسيطًا، لكن مع نمو التطبيق قد يصبح لديك عدد كبير من الحاويات، وكل واحدة منها تحتاج إلى التشغيل على مورد مناسب، والاتصال بالحاويات الأخرى، والوصول إلى الشبكة، والتعامل مع التخزين، والمراقبة، وإعادة التشغيل عند حدوث مشكلة، والتوسع عند زيادة الطلب.
وهنا لا يعود السؤال: كيف أشغّل Container؟ بل يصبح: كيف أدير مئات الحاويات بكفاءة؟
توضح وثائق Kubernetes أن تشغيل الحاويات في بيئة إنتاج يتطلب إدارة الأحمال الحاوية والتأكد من استمرار الخدمات عند تعطل بعض النسخ.
Containers as a Service — CaaS هو نموذج من Cloud Computing يتيح للشركات والفرق التقنية تشغيل ونشر وإدارة التطبيقات المبنية على Containers، دون الحاجة إلى إدارة جميع طبقات البنية التحتية بنفسها.
بدل أن يتولى الفريق إعداد الخوادم، ونظام التشغيل، وبيئة الـ Cluster، وأجزاء كبيرة من طبقة إدارة الحاويات، توفر منصة CaaS هذه البيئة كخدمة.
في المقابل، يركز العميل بدرجة أكبر على التطبيق، وContainer Images، وإعدادات التطبيق، والبيانات، وسياسات التوسع، والخدمات التي يحتاج إليها التطبيق.
بهذا المعنى، CaaS ليست مجرد مكان لتشغيل Container؛ بل طبقة تجمع بين تشغيل الحاويات وأدوات الإدارة والتوسع والمراقبة والخدمات المساندة.
لفهم CaaS بشكل عملي، يمكن تتبع رحلة التطبيق من لحظة تطويره حتى يصبح متاحًا للمستخدم:
1. تطوير التطبيق: يبدأ المطور بكتابة التطبيق وتجهيزه للتشغيل داخل Container.
2. إنشاء Container Image: يتم تغليف التطبيق وبيئة تشغيله في Image قابلة للاستخدام.
3. تخزين الصورة: يتم حفظ الـ Image في Container Registry.
4. النشر: تقوم منصة CaaS بنشر الـ Containers ضمن البيئة المناسبة.
5. التوزيع: يتم توزيع الأحمال على Worker Nodes وفق الموارد والسياسات.
6. تشغيل التطبيق: تبدأ الحاويات بالعمل وتصبح الخدمات متاحة عبر الشبكة.
7. المراقبة والتوسع: تتم مراقبة الحالة واستخدام الموارد ويمكن زيادة أو تقليل عدد النسخ وفق الحاجة.
الشكل 2: تسلسل مبسط من الكود إلى الحاويات العاملة.
قد تبدو CaaS للمستخدم كواجهة بسيطة لنشر التطبيق، لكن خلفها توجد مجموعة من المكونات التي تعمل معًا.
يمثل مركز التحكم في البيئة، ويتولى إدارة حالة الـ Cluster والتنسيق بين مكوناته. في البيئات المبنية على Kubernetes توجد مكونات تحكم مثل API Server وScheduler وControllers.
هي الموارد التي تُشغّل عليها التطبيقات والحاويات فعليًا.
توفر الاتصال بين الحاويات والخدمات والمستخدمين، وتساعد في توجيه الطلبات إلى التطبيق المناسب.
بعض التطبيقات تحتاج إلى بيانات تستمر حتى بعد إعادة تشغيل الـ Container، وهنا تأتي الحاجة إلى Persistent Storage.
لا يكفي تشغيل التطبيق؛ يجب معرفة حالته واستهلاك الموارد والأخطاء التي تحدث أثناء التشغيل.
لنفترض أن تطبيقًا يعمل حاليًا باستخدام 3 Containers. في الأيام العادية، هذا العدد كافٍ لتلبية الطلب. لكن خلال حملة تسويقية أو حدث معين، ارتفع عدد المستخدمين بشكل كبير.
إذا بقي التطبيق على نفس عدد الـ Containers، فقد تصل الموارد إلى حدودها ويتأثر الأداء. هنا تظهر إحدى قدرات بيئات CaaS: Auto-Scaling.
يمكن للمنصة زيادة عدد الـ Containers عندما يرتفع الطلب، وتقليلها عندما ينخفض.
تختلف آليات التوسع بحسب المنصة. على سبيل المثال، توضح وثائق Google Cloud أن Cloud Run يمكنه التوسع تلقائيًا مع الطلب، بينما تدعم Azure Container Apps التوسع بناءً على HTTP traffic والأحداث وبعض مؤشرات الموارد أو أدوات KEDA.
من أهم الأفكار في نموذج as a Service هو توزيع المسؤوليات. في بيئة CaaS قد يتولى مزود الخدمة طبقات أساسية من البنية التحتية، بينما يركز العميل على التطبيق والحاويات وإعداداتها.
· قد تشمل مسؤوليات مزود الخدمة: Hardware، Virtualization، البنية التحتية للـ Container، وإدارة المنصة أو الـ Cluster بحسب نوع الخدمة.
· يركز العميل عادةً على Application، وContainer Images، وConfiguration، والبيانات، وسياسات التوسع، ومتطلبات التطبيق.
· لا يوجد تقسيم واحد ثابت للمسؤوليات؛ فهو يختلف حسب مزود الخدمة ونوع CaaS المستخدم.
تساعد Containers على نقل التطبيق بين بيئات مختلفة مع الحفاظ على بيئة تشغيل متقاربة.
يمكن زيادة أو تقليل عدد النسخ وفق حجم الطلب، بدل تخصيص أكبر قدر من الموارد طوال الوقت.
يمكن توزيع أحمال العمل بصورة أكثر مرونة مع تحديد حدود الموارد للحاويات.
يمكن دمج Containers مع CI/CD بحيث تمر التغييرات بمراحل Build ثم Test ثم Deploy.
بدل التعامل مع كل Container بصورة منفصلة، توفر منصات الإدارة أدوات للتعامل مع مجموعة كبيرة من الأحمال من بيئة واحدة.
قد تبدو هذه النماذج متشابهة لأنها جميعًا من Cloud Service Models، لكن مستوى المسؤولية والتجريد يختلف بينها.
عندما يتكون التطبيق من عدة خدمات مستقلة يمكن تشغيلها وإدارتها ضمن بيئة موحدة.
يمكن تشغيل تطبيقات الويب وواجهات API داخل Containers مع إمكانية التوسع بحسب الطلب.
يمكن فصل أجزاء النظام مثل الواجهة وواجهات API وخدمات الطلبات والدفع وتشغيلها بصورة مستقلة.
يمكن استخدام Containers لتوفير بيئات أكثر اتساقًا في مراحل Build وTest وDeployment.
يمكن تشغيل بعض مهام Batch Processing أو المعالجة غير المتزامنة عند الحاجة.
يمكن تشغيل بعض تطبيقات الأعمال ضمن بيئات Containerized عندما تكون هناك حاجة إلى توحيد النشر وعزل البيئات.
تشغيل التطبيقات داخل Containers لا يعني أن الأمان أصبح مسؤولية المنصة بالكامل. ما زالت هناك مسؤوليات مهمة تتعلق بالوصول، والأسرار، وصور الحاويات، وتحديث المكونات، والمراقبة.
· التحكم في الصلاحيات والوصول.
· حماية Secrets ومفاتيح الوصول.
· فحص Container Images قبل نشرها.
· تحديد الموارد المسموح بها لكل workload.
· تحديث الصور والمكونات باستمرار.
· مراقبة النشاط والسجلات.
القاعدة الأساسية: الحاويات تقلل جزءًا من التعقيد التشغيلي، لكنها لا تلغي الحاجة إلى تصميم أمني جيد.
قد يعمل التطبيق بصورة طبيعية اليوم، لكن هذا لا يعني أن كل شيء سيبقى كذلك. لذلك تحتاج بيئة CaaS إلى مراقبة الموارد وحالة الحاويات وسجلات التطبيق وحركة المرور والأخطاء.
· CPU
· Memory
· Network
· Container Health
· Application Logs
· Errors
· Traffic
كلما زاد عدد الخدمات والحاويات، أصبحت المراقبة وObservability أكثر أهمية لفهم ما يحدث داخل البيئة.
تُستخدم Docker على نطاق واسع لبناء وتشغيل وتوزيع Containers، بينما يمكن استخدام منصات أخرى لإدارة وتشغيل هذه الحاويات على نطاق أكبر.
Kubernetes منصة مفتوحة المصدر لإدارة containerized workloads والخدمات، وتوفر آليات للإدارة الآلية والتكوين التصريحي وإدارة الحالة المطلوبة للتطبيقات.
توجد نماذج متعددة في السحابة. فمثلًا، يصف Google Cloud Run نفسه كمنصة مُدارة لتشغيل الكود أو الحاويات دون الحاجة إلى إنشاء Cluster وإدارته مباشرة، بينما تتيح Azure Container Apps تشغيل التطبيقات الحاوية دون إدارة البنية التحتية الأساسية.
لذلك من المهم التمييز بين CaaS كمفهوم عام وبين الخدمات المختلفة التي تقدمها مزودات السحابة؛ فدرجة التحكم، وطريقة النشر، وآليات التوسع، ونموذج التشغيل تختلف من خدمة إلى أخرى.
ليس بالضرورة. إذا كان لديك تطبيق صغير جدًا، بعدد محدود من المستخدمين، ولا يحتاج إلى توسع أو عمليات نشر متكررة، فقد لا تكون كل إمكانيات CaaS ضرورية.
لكن مع نمو النظام، وخصوصًا عندما يصبح لديك عدد كبير من Containers، أو Microservices متعددة، أو عمليات Deployment متكررة، أو حاجة إلى Auto-Scaling وHigh Availability وبيئات متعددة، تصبح إدارة البيئة أكثر تعقيدًا، وهنا تظهر قيمة CaaS بشكل أكبر.
قد يبدو CaaS للوهلة الأولى وكأنه مجرد طريقة لتشغيل Docker Containers في السحابة، لكن الصورة أكبر من ذلك.
القيمة تأتي من الجمع بين Containerization وContainer Management وNetworking وStorage وScaling وMonitoring وSecurity ضمن بيئة يمكن إدارتها بشكل أكثر تنظيمًا.
ولهذا يمكن النظر إلى CaaS باعتبارها طبقة تساعد الفرق التقنية على التركيز على التطبيق نفسه، بدل قضاء جزء كبير من وقتها في إدارة كل تفاصيل البنية التحتية اللازمة لتشغيله.
بدأت رحلة تشغيل التطبيقات من الخوادم الفعلية، ثم انتقلت إلى البيئات الافتراضية، ثم إلى Containers التي جعلت تغليف التطبيقات ونقلها أكثر مرونة.
لكن عندما زاد عدد الحاويات، ظهرت مشكلة جديدة: كيف يمكن إدارة كل هذه الحاويات بكفاءة؟
هنا تأتي Containers as a Service (CaaS). فهي تجمع بين مرونة Containers وقدرات إدارة وتشغيل الأحمال الحاوية والخدمات السحابية اللازمة، مع تقليل جزء من العبء المرتبط بإدارة البنية التحتية.
ومن نشر التطبيق إلى التوسع التلقائي، ومن الشبكات والتخزين إلى المراقبة والأمان، لا يتعلق CaaS بمجرد تشغيل Container، بل ببناء بيئة متكاملة تستطيع التطبيقات أن تعمل وتنمو داخلها.
CaaS لا تجعل الحاويات تعمل فقط؛ بل تجعل إدارة بيئة الحاويات على نطاق واسع أكثر تنظيمًا ومرونة.
كن أول من يقيّم هذا المقال
تعرّف على الحاويات كخدمة (CaaS)، وكيف تنشر تطبيقك وتوسّعه في السحابة دون إدارة الخوادم، ومتى تختارها بدلًا من الأجهزة الافتراضية أو الدوال بلا خادم.
تعرّف على الحاويات كخدمة (CaaS)، وكيف تساعد الشركات على تشغيل التطبيقات ونشرها وإدارتها وتوسيعها بسهولة داخل بيئات الحوسبة السحابية.
تعرف كيف تتيح الواجهة الخلفية كخدمة للمطورين الاستفادة من خدمات Backend جاهزة وتسريع الانتقال من الفكرة إلى التطبيق.