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

• البرمجيات كخدمات سحابية Software as a services واختصارًا SaaS
• منصات العمل كخدمات سحابية Platform as a Service واختصارًا PaaS
• البُنى التحتية كخدمات سحابية Infrastructure as Service واختصارًا IaaS

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

ما هي الحوسبة السحابية

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

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

أنواع الخدمات السحابية

فيما يلي مقارنة سريعة بين البرمجيات والمنصات والبنى التحتية كخدمات:

البُنى التحتية كخدمات سحابية IaaS

تؤمن خدمة البنية التحتية السحابية وحدات البناء الأساسية للبنية التحتية لأي سحابة وتقدم موارد حاسوبية مثل المعالجة والآلات الافتراضية والشبكات وأكثر. وتسهل IaaS دعم الأعمال الصغيرة والمنظمات التي تستهدف حلولًا سحابية غير مكلفة وتعمل وفق نموذج الدفع وفقًا للاستخدام pay as you go وبالتالي سيدفع المستخدم تكلفة الخدمات التي يحتاجها فقط دون أية تكاليف إضافية، وهي متاحة لتوزيع الخدمات والموارد بشكل عام أو خاص أو هجين.

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

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

من الأمثلة عليها نجد: خدمة أمازون ويب AWS، ومحرك حوسبة جوجل GCE، ومايكروسوفت آزور، وديجتال أوشن DigitalOcean.

متى نستخدم نموذج IaaS

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

الإيجابيات

• غير مكلفة
• مرنة
• إمكانية استعادة البيانات عند حدوث كوارث
• سهل الوصول
• موثوقة ويمكن الاعتماد عليها

السلبيات

• صعوبة التحكم
• مشاكل في أمان البيانات

منصات العمل كخدمات سحابية PaaS

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

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

من الأمثلة عليها نجد: AWS Elastic Beanstalk و Apache Stratos و Force.com و OpenShift و Heroku

متى نستخدم نموذج PaaS

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

الإيجابيات

• تكلفة مناسبة
• إنتاجية متزايدة
• رشيقة ومتجاوبة
• سهلة التوسع
• سهلة الوصول

السلبيات

• مشاكل في التوافقية
• تغيّر مقدمي الخدمات

البرمجيات كخدمات سحابية SaaS

توفر لنا البرمجيات كخدمة SaaS إمكانية الوصول إلى تطبيقات الويب عبر الإنترنت، ولا حاجة معها إلى تنزيل أية أدوات أو برمجيات، وقد تكون مجانية أو تعمل وفق مبدأ الدفع وفقًا للاستخدام. ويمكن للمستخدمين الوصول إلى التطبيقات عبر أي جهاز بصرف النظر عن البنية التحتية لمقدم الخدمة أو صيانة التطبيقات أو أي شيء آخر، فهي أمور يديرها ويحميها مزوّد الخدمة السحابية.

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

من الأمثلة عنها نجد: Google Workspace و Salesforce و Cisco WebEx و Dropbox.

متى نستخدم نموذج SaaS

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

يمكن للأعمال الصغيرة الاستفادة من SaaS في حال لم نمتلك الميزانية الكافية أو كادر العمل لبناء تطبيقات خاصة بها. ويستخدم العديد من متخصصي تقانة المعلومات والمنظمات تطبيقات SaaS، وبإمكان مستخدمي B2B و B2C الاستفادة من تطبيقات SaaS على خلاف الخدمات السحابية الأخرى

الإيجابيات

• قابلة للتوسع وسهلة الوصول
• غير مكلفة
• سهلة التحديث
• سهلة التوزيع

السلبيات

• لا تقدم حماية كافية للبيانات
• تحكم أقل

الاختلافات بين الخدمات السحابية SaaS و PaaS و Iaas

عندما نقارن بين هذه الخدمات السحابية من ناحية المرونة تبرز خدمة IaaS. إذ تعتمد المرونة تمامًا على موزع الخدمة الذي نختاره، وكذلك الأمر من ناحية الأمان. وتُدفع تكاليف هذه الخدمة عادة بالساعة وفقًا للاستخدام وبالتالي قد ترتفع تكاليفها نظرًا لأسلوب الدفع الدقيق المرتبط بها.

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

أخيرًا، لخدمة SaaS سقف سعر فهي أرخص من كلتا الخدمتين السابقتين، وهي نعمة حقيقية للأشخاص والأعمال الصغيرة. لكن في المقابل سيكون تحكمنا في الخدمة محدودًا أو غير متاح، فمزود الخدمة هو من يدير معظم تفاصيلها.

يمثل المخطط التالي الحجم السوقي للخدمات السحابية بين عامي 2018 و2024، وشعبية كل خدمة من الخدمات السابقة:

المصدر

بالنسبة لحرية التحكم بالخدمة سنجد أن نموذج IaaS في المقدمة، فهو يسمح لنا بإدارة التطبيقات والبيانات والبرمجيات الوسيطة ونظام التشغيل. بينما يسمح لنا نموذج PaaS بإدارة البيانات والتطبيقات فقط، ويدير مقدم الخدمة معظم أو كل النواحي في SaaS.

اختيار الخدمة السحابية المناسبة

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

خدمات حوسبة سحابية أخرى

إلى جانب الخدمات الثلاث التي تحدثنا عنها في الفقرات السابقة نجد خدمات أخرى مثل:

الخدمة السحابية DBaas

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

الإيجابيات

• سهولة العمل والتكيف مع التغييرات.
• غير مكلفة
• موثوقة
• لن نحتاج لبناء منظومة قواعد بيانات أو توظيف مطوري قواعد بيانات
• أوقات توفرها ممتازة

السلبيات

• تحكم محدود
• مشاكل في خصوصية البيانات

الخدمة السحابية Daas

تُعد البيانات كخدمة Daas نهجًا مشابهًا لخدمة SaaS، إذ تؤمن خدمات تخزين ومعالجة وتكامل البيانات سحابيًا إلى مستخدميها عبر الإنترنت، ولا تتطلب تثبيت أو إدارة أية برمجيات. وتساعد Daas المستخدمين في الحد من تضخم البيانات data sprawl والحاجة إلى مجمعات تخزين data silos وتحسّن التعاون بين فرق العمل عبر مشاركة البيانات بينهم.

الإيجابيات

• بيئة مقادة بالبيانات
• صيانة مؤتمتة
• تحسين نوعية البيانات

السلبيات

• مشكلات في الخصوصية
• تعقيد البيانات

الخدمة السحابية Faas

تُعد الدوال كخدمة Functions as a Service واختصارًا FaaS خدمة سحابية ذات معمارية مبنية على الأحداث وخفية الخوادم serverless. تعمل هذه الخدمة على مبدأ كتابة دوال وتنفيذها كاستجابة لحدث ما، وتعتمد نموذج الدفع وفقًا للاستخدام ولن تكون هناك تكاليف إضافية.

الإيجابيات

• ندفع فقط مقابل ما نستخدم
• زيادة في إنتاجية المطور
• توسع تلقائي

السلبيات

• دعم محدود للعديد من التقنيات
• تحكم أقل بالمنظومة

الخلاصة

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

ترجمة -وبتصرف- لمقال: IaaS vs. PaaS vs. Saas how are the differents لصاحبه Sarim Javaid

اقرأ أيضًا

• مفهوم السحابة Cloud
• مقدمة إلى الخوادم السحابية
• نظرة عامة على الحوسبة السحابية
• مقدمة إلى الاستضافة السحابية Cloud Hosting

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

يتطلب العمل مع كوبرنيتس Kubernetes استخدامًا مكثفًا للموارد الحاسوبية، لأنه يعمل في نظام عنقودي يتكون من عدة خوادم، ويُشكل ذلك عبئًا إضافيًا على المطورين وخصوصًا في مرحلة ما قبل الإنتاج، فسيحتاجون الكثير من الموارد لتطوير مكدس Kubernetes تجريبي واختباره قبل النشر في البيئة الفعلية، لذا أنشأ مطورو Kubernetes مشروعًا مساعدًا مخصص لهذا الغرض يدعى minikube، الذي يعمل مع بيئات تشغيل الحاويات مثل دوكر  Docker وغيره، ويستطيع محاكاة عنقود Kubernetes كامل على آلة واحدة فقط هي حاسوبك الشخصي مثلًا.

فما هو minikube المحاكي الشهير لنظام Kubernetes؟ وكيف يستخدم لاختبار إعدادات Kubernetes قبل نشرها في بيئة الإنتاج؟ وما هي لوحة معلومات Kubernetes المضمنة فيه؟ سيجيبك المقال عن هذه الأسئلة، ويعطيك طريقة تثبيته على حاسوبك المحلي أو خادمك البعيد، ثم سنعمل معًا على نشر تطبيق تجريبي بسيط، ونحاول الوصول إليه عبر minikube، وفي الختام سنتعرف على طريقة استخدام Minikube مع عناقيد Kubernetes البعيدة بواسطة ملفات تعريف الإعدادات configuration profiles.

متطلبات العمل

ستحتاج المتطلبات الأولية التالية لتطبيق خطوات العمل المذكورة في المقال:

• فهم أساسيات Kubernetes، تفيدك مطالعة مقال تعرّف على كوبرنيتس Kubernetes لتكوين فكرة جيدة عن أبرز مفاهيم Kubernetes ومكوناته.
• تثبيت بيئة تشغيل الحاويات Docker على حاسوبك الذي ستعمل منه، إذ سنُشغل منها minikube. إذا كنت تستخدم نظام تشغيل لينكس، فستساعدك الخطوات الواردة في مقال كيفية تثبيت دوكر واستخدامه على دبيان، ولسهولة العمل احرص على تنفيذ الخطوة المتعلقة بضبط الإعدادات اللازمة لتشغيل Docker بدون الحاجة لكتابة sudo في بداية كل أمر. أما إذا كنت تعتمد نظام تشغيل ويندوز أو ماك فيمكنك الاستعانة بتوثيقات Docker الرسمية لإتمام عملية التثبيت.
• مدير الحزم Homebrew، يمكنك الاسترشاد بالخطوات الواردة في هذا المقال على DigitalOcean لتثبيته على نظام تشغيل ماك، أو بمقال لتثبيته على لينكس، وفي حال كنت تستخدم نظام ويندوز فتستطيع تثبيته باستخدام WSL نظام ويندوز الفرعي لنظام لينكس .
• توفير الموارد الحاسوبية اللازمة للبيئة التي ستُثَبِّت فيها Minikube، وهي بالحد الأدنى: وحدتي معالجة مركزية 2CPUs، وذاكرة مخبئية 2GB RAM، ومساحة تخزينية على القرص الصلب بسعة 20GB.

الخطوة 1: تثبيت Minikube وتشغيله

ثبّت minikube بواسطة مدير الحزم Homebrew كما يلي:

$ brew install minikube

وستحصل على خرج يشبه التالي، يبين لك نجاح التثبيت:

…
==> Installing minikube
==> Pouring minikube--1.25.2.x86_64_linux.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
  /home/sammy/.linuxbrew/etc/bash_completion.d
==> Summary
🍺  /home/sammy/.linuxbrew/Cellar/minikube/1.25.2: 9 files, 70.0MB
…

ملاحظة: يتطلب تثبيت minikube على نظام ويندوز الانتباه لبعض التفاصيل المهمة: يعمل minikube مع WSL2 (وهي النسخة المتوفرة من WSL لتاريخ نشر المقال)، وينبغي تهيئته ليستخدم Docker واجهةً خلفية backend بدلًا من واجهته الخلفية الافتراضية. لذا بعد تثبيت Docker احرص على تفعيل ميزة دعم WSL2 باتباع إرشادات توثيقات Docker الخاصة بالموضوع ثم ثبت minikube ونفذ الأمر minikube config set driver docker.

اكتب الآن الأمر start وفق التالي لبدء تشغيل minikube، وسينشأ بداخله آليًّا عنقود Kubernetes محلي بأحدث إصدار مستقر متوفر، ويتضمن عدة حاويات Docker:

$ minikube start

سيتطلب التشغيل بعض الوقت، وستحصل في نهايته على الخرج التالي، مع تجهيز الأداة kubectl لتستخدمها للاتصال مع العنقود cluster، كما يوضح السطر الأخير من الخرج:

👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
💾  Downloading Kubernetes v1.23.1 preload ...
    > preloaded-images-k8s-v16-v1...: 504.42 MiB / 504.42 MiB  100.00% 81.31 Mi
    > gcr.io/k8s-minikube/kicbase: 378.98 MiB / 378.98 MiB  100.00% 31.21 MiB p
🔥  Creating docker container (CPUs=2, Memory=1987MB) ...
🐳  Preparing Kubernetes v1.23.1 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: default-storageclass, storage-provisioner
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

ملاحظة: يمكنك اختيار إصدار Kubernetes الذي يناسبك لأسباب تتعلق بالتوافقية أو غيرها، بدلًا من الاعتماد على الإصدار الافتراضي الذي يوفره minikube، وذلك بكتابة رقم الإصدار المطلوب بعد الأمر minikube start بهذا الشكل kubernetes-version v.1.2.3--.

يسمح لك تثبيت minikube بواسطة مدير الحزم Homebrew بالعمل مباشرةً مع kubectl الأداة الأساسية لإدارة عناقيد Kubernetes باستخدام سطر الأوامر، وبالتالي يمكنك كتابة الأمر kubectl get كما يلي لاستعراض جميع pods العاملة في العنقود بالطريقة نفسها المتبعة مع عناقيد Kubernetes العادية:

$ kubectl get pods -A

يعرض الوسيط A- كافة pods العاملة في جميع مساحات الأسماء namespaces الموجودة ضمن العنقود، ألقِ نظرة على شكل الخرج للأمر السابق:

NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-64897985d-ttwl9            1/1     Running   0             46s
kube-system   etcd-minikube                      1/1     Running   0             57s
kube-system   kube-apiserver-minikube            1/1     Running   0             61s
kube-system   kube-controller-manager-minikube   1/1     Running   0             57s
kube-system   kube-proxy-ddtgd                   1/1     Running   0             46s
kube-system   kube-scheduler-minikube            1/1     Running   0             57s
kube-system   storage-provisioner                1/1     Running   1 (14s ago)   54s

لديك الآن عنقود Kubernetes محلي، تستطيع إدارته باستخدام أدوات Kubernetes المألوفة مثل kubectl، وسنعرض في الفقرات القادمة وظائف إضافية يوفرها لك minikube لمراقبة عناقيد Kubernetes وإدارتها والتعديل عليها.

الخطوة 2: الوصول إلى لوحة معلومات Kubernetes

يوفر minikube لمستخدميه وصولًا سهلًا للوحة معلومات النظام Kubernetes Dashboard، التي يمكنك استخدامها لمراقبة سلامة العنقود ولنشر التطبيقات يدويًا ولغيرها من أعمال الإدارة. وفور تثبيت minikube محليًا على حاسوبك تستطيع الوصول إلى لوحة معلومات Kubernetes بكتابة الأمر minikube dashboard:

$ minikube dashboard

سيُشغّل هذا الأمر لوحة المعلومات آليًّا، ويفتح منفذًا port خاصًا داخل Kubernets يوجه حركة البيانات إلى العنقود، ثم يعرض رابط اللوحة الذي يشير إلى رقم المنفذ مباشرةً أمامك في متصفح الويب، كما في الصورة التالية.

يؤدي تشغيل لوحة المعلومات إلى تعطيل النافذة الطرفية terminal التي كَتَبّتَ أمر التشغيل فيها، فلا يمكنك كتابة أوامر أخرى ضمنها، لذا يلجأ المستخدمون إلى تشغيل لوحة المعلومات في نافذة طرفية أخرى غير التي يعملون عليها. يمكنك إيقاف هذه العملية المُعطِّلة وغيرها من العمليات المشابهة بالضغط على Ctrl+C.

أما إذا كنت تستخدم minikube على خادم بعيد، فأضِف الوسيط url-- إلى الأمر minikube dashboard السابق، وسيعطيك في الخرج رابط URL الخاص بلوحة المعلومات، بدلًا من فتحه مباشرة في المتصفح. ألقِ نظرة على الأمر التالي الخاص بتشغيل اللوحة للخادم البعيد:

$ minikube dashboard --url

وسيكون الخرج كما يلي:

🤔  Verifying dashboard health ...
🚀  Launching proxy ...
🤔  Verifying proxy health ...
http://127.0.0.1:34197/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

يختلف رقم المنفذ الذي يفتحه minikube للوحة المعلومات من نظامٍ إلى آخر، ستلاحظ أن رقمه على حاسوبك مختلفٌ عن رقمه هنا في هذا المثال.

تمنع إعدادات الأمان الافتراضية لنظام Kubernetes الوصول إلى عنوان URL هذا من الأجهزة البعيدة لحمايته، لذا ينبغي عليك بدايةً إعداد قناة SSH آمنة مع الخادم قبل فتحه. اكتب إذاً الأمر التالي مع الراية L- لفتح قناة ssh بين الحاسوب المحلي والخادم البعيد، واكتب ضمنه رقم منفذ لوحة المعلومات الظاهر في الخرج السابق، وعنوان IP لخادمك البعيد ليصبح بهذه الصيغة:

$ ssh -L 34197:127.0.0.1:34197 sammy@your_server_ip

يمكنك بعد ذلك الدخول إلى لوحة المعلومات باستخدام الرابط: http://127.0.0.1:34197/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/.

يمكنك معرفة المزيد عن تقنية الاتصال الآمن SSH بمطالعة الفيديو التالي:

الآن بعد أن اختبرنا التعامل مع minikube مثل أي عنقود Kubernetes كامل عن طريق لوحة المعلومات، سننتقل للخطوة التالية، ونحاول نشر تطبيق تجريبي بسيط في هذا العنقود لنتأكد من عمله كما هو بالطريقة المرجوة منه.

الخطوة 3: نشر تطبيق تجريبي واختباره

يمكنك استخدام الأمر kubectl لنشر تطبيق تجريبي في عنقود Minikube. اكتب مثلًا الأمر التالي الذي سيؤدي إلى نشر تطبيق Kubernetes تجريبي متاح للاختبارات من شركة جوجل يدعى hello-app.

$ kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0

يُنشئ هذا الأمر عملية نشر deployment داخل العنقود تدعى web، وتُبنى انطلاقًا من صورة بعيدة تسمى hello-app موجودة في سجل حاويات جوجل المسمى gcr.io.

سنُعَرِّف الآن عملية النشر web بصفتها خدمة من خدمات Kubernetes، ونحدد منفذًا ثابتًا للاتصال معه بكتابة المحددين port=8080-- و type=NodePort--، وفق التالي:

$ kubectl expose deployment web --type=NodePort --port=8080

يمكنك معرفة المزيد عن خدمات Kubernetes وكيفية الاتصال معها بمطالعة مقال تعرّف على كوبرنيتس Kubernetes.

لنتحقق فيما إذا كانت الخدمة تعمل أم لا؟ بواسطة الأمر kubectl get service مع كتابة اسم الخدمة بعده، كما يلي:

$ kubectl get service web

ستحصل على خرج يشبه الخرج التالي، مع اختلاف في أرقام المنافذ لأن NodePort توزع أرقام المنافذ عشوائيًا على خدمات Kubernetes:

NAME   TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
web    NodePort   10.109.254.242   <none>        8080:31534/TCP   10s

يمكننا الآن استخدام minikube للحصول على عنوان URL المتاح من خارج الحاوية، يسمح لك هذا العنوان بالاتصال مع خدمة التطبيق hello-app العاملة على المنفذ 8080 داخل العنقود. إذا كنت تستخدم Minikube على حاسوبك المحلي، فلست بحاجة لإعادة توجيه حركة البيانات من منفذ لآخر كما سنذكر لاحقًا، فقط نفذ الأمر minikube service web --url التالي، وستحصل على عنوان URL لتطبيقك التجريبي:

$ minikube service web --url

وسيكون الخرج عنوان URL مثل التالي:

http://192.168.49.2:31534

اختبر عنوان URL بواسطة crul، وهو أحد أشهر برامج سطر الأوامر command line المستخدمة لإرسال أنواع مختلفة من طلبات الويب، يستخدم للتحقق من إمكانية عمل عناوين URL ضمن المتصفح في ظروف مناسبة، لذا ننصحك بفحص الروابط باستخدام crul دائمًا قبل تجربتها في المتصفح، وذلك وفق التالي:

$ curl http://192.168.49.2:31534

يبين لك الخرج التالي نجاح العملية:

Hello, world!
Version: 1.0.0
Hostname: web-746c8679d4-j92tb

يمكنك الآن استعراض عنوان URL هذا في المتصفح مباشرةً إذا كانت تستخدم minikube محليًا، وستحصل على النص السابق غير المنسق نفسه الذي حصلت عليه بتعليمة crul. أما إذا كنت تعمل على جهاز بعيد، استخدم اتصال SSH كما في الخطوة 2، ثم استعرض العنوان في المتصفح.

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

سنتعلم في خطوتنا التالية طريقة استخدام بعض أدوات Minikube المدمجة لتغيير بعض الإعدادات الافتراضية للعنقود.

الخطوة 4: إدارة نظام ملفات Minikube وموارده

يوفر لك minikube عددًا من الأوامر الخاصة بتعديل إعدادات العنقود، فمثلًا يمكنك استخدام الأمر minikube config لتعديل الذاكرة المتوفرة للعنقود وفق التالي، علمًا أن الذاكرة هنا تقدر بالميجابايت MB وبالتالي يقابل الأمر minikube config 4096 توفير ذاكر بسعة 4GB لعنقودك:

$ minikube config set memory 4096

ستحصل على الخرج التالي:

❗  These changes will take effect upon a minikube delete and then a minikube start

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

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

تتضمن إعادة النشر مرحلتين هما minikube delete و minikube start، اكتب أولًا الأمر:

$ minikube delete

وستحصل على الخرج التالي:

🔥  Deleting "minikube" in docker ...
🔥  Deleting container "minikube" ...
🔥  Removing /home/sammy/.minikube/machines/minikube ...
💀  Removed all traces of the "minikube" cluster.

ثم اكتب الأمر:

$ minikube start

يتيح لك minikube وصل أي مجلد من نظام ملفاتك المحلي الموجود على حاسوبك إلى داخل العنقود وصلًا مؤقتًا باستخدام الأمر minikube mount.

أما كيفية كتابة الأمر mount قواعديًا فهي على الشكل التالي: local_path:minikube_host_path. يرمز local_path إلى مسار المجلد المحلي الذي تريد إيصاله إلى داخل العنقود، ويشير الجزء الآخر أي minikube_host_path إلى الموقع أو المجلد داخل VM أو داخل حاوية Minikube الذي تود أن تصل منه إلى ملفاتك.

ألقِ نظرة على الأمر التالي الذي يوصل المجلد الأساسي الخاص بك home directory إلى المجلد host/ داخل عنقود minikube:

$ minikube mount $HOME:/host

وستحصل على الخرج التالي الذي يؤكد لك نجاح العملية:

📁  Mounting host path /home/sammy into VM as /host ...
    ▪ Mount type:
    ▪ User ID:      docker
    ▪ Group ID:     docker
    ▪ Version:      9p2000.L
    ▪ Message Size: 262144
    ▪ Options:      map[]
    ▪ Bind Address: 192.168.49.1:43605
🚀  Userspace file server: ufs starting
✅  Successfully mounted /home/sammy to /host

📌  NOTE: This process must stay alive for the mount to be accessible ...

تفيدك هذه الطريقة في الحالات التي تحتاج فيها للحفاظ على مدخلات أو مخرجات ثابتة لعملك مع العنقود، مثل عمليات تسجيل الأحداث logging لعنقود minikube.

تعطل هذه العملية نافذة الطرفية فلا يعود بإمكانك كتابة الأوامر فيها، يمكنك الخروج منها بالضغط على Ctrl+C، تمامًا كما فعلنا في حالة فتح المنفذ الخاصة بلوحة المعلومات التي ذكرناها في الخطوة 2. سنتعلم في الخطوة التالية كيف تتنقل بكفاءة بين minikube وعنقود Kubernetes كامل موجود على خادم بعيد.

التعامل مع أكثر من عنقود Kubernetes

يستطيع minikube التعامل مع عناقيد Kubernetes محلية متعددة في الوقت نفسه، فيُهيئ لكل عنقود ملف تعريف profile خاص به. فقد تحتاج في بعض الحالات للتعامل مع إصدارات مختلفة من عناقيد Kubernetes لإجراء اختبار معين مثلًا، فيمكنك عندها التبديل بين هذه الإصدارات باستخدام الراية p- أو profile--.

وإذا كنت ستعمل مع عنقود معين لفترة طويلة أو أكثر من بقية العناقيد، فيمكنك تعيينه ليكون ملف التعريف الافتراضي في minikube بواسطة الأمر minikube profile، بدلًا من تحديده بعد الراية profile-- في كل أمر تنفذه.

لنُشغّل الآن Minikube مع ملف تعريفي جديد بتنفيذ الأمر minikube start مع الراية p-، وفق التالي:

$ minikube start -p new-profile

اضبط الآن هذا الملف التعريفي الجديد ليكون هو الملف الفعال أو الافتراضي في Minikube بكتابة الأمر minikube profile كما يلي:

$ minikube profile new-profile

سيظهر لك هذا الخرج:

✅  minikube profile was successfully set to new-profile

يمكنك معرفة الملف التعريفي الحالي الذي تستخدمه بواسطة الأمر get profile كما يلي:

$ minikube config get profile

وسيعيد لك الخرج اسم الملف التعريفي الحالي وهو في مثالنا:

new-profile

يُنشئ minikube ملفات الإعدادات لمنظومتك، ويخزنها هذه الملفات في مكانها الافتراضي المعروف للأداة kubectl ولغيرها من أدوات Kubernetes لتتمكن من الوصول إليها، ذلك سواء كنت تستخدم ملف تعريفي واحد أو عدة ملفات تعريفية، فمثلًا في كل مرة تنفذ فيها الأمر kubectl get nodes لاستعراض بيانات العقد nodes لعنقود minikube ستُحلل kubectl ملفات الإعدادات وتعطيك النتيجة، ألقِ نظرة على الأمر أدناه:

$ kubectl get nodes

وسيبين الخرج العقد الموجودة وهي عقدة واحدة فقط في حالتنا كما يلي:

NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   3h18m   v1.23.1

يمكنك اختيار أي ملف إعدادات تريده وإسناده للمُحَدِد kubeconfig لتقرأه kubectl عند بدء تشغيلها بدلًا من الملف الافتراضي الموجود في المجلد kube/confg. /~، وعندها ستستخدم بيانات اعتماد العنقود المذكورة في هذا الملف عوضًا عن تلك الموجودة في الملف الافتراضي. لنفترض أن لديك ملف إعدادات اسمه remote-kubeconfig.yaml مثلًا لعنقود Kubernetes آخر غير عنقودك في Minikube، وتريد استخراج العقد الموجودة فيه، فستكتب حينئذ الأمر التالي:

$ kubectl --kubeconfig=remote-kubeconfig.yaml get nodes

وستحصل في الخرج على العقد الموجودة في ذلك العنقود، والتي تعمل عن بعد خارج Minikube الخاص بك، وسيبدو الخرج كما يلي:

NAME                   STATUS   ROLES    AGE    VERSION
pool-xr6rvqbox-uha8f   Ready    <none>   2d2h   v1.21.9
pool-xr6rvqbox-uha8m   Ready    <none>   2d2h   v1.21.9
pool-xr6rvqbox-uha8q   Ready    <none>   2d2h   v1.21.9

صُمم Kubernetes في الأساس للعمل مع ملف إعدادات واحد لكل عنقود، يُمَرَر للأوامر مثل kubectl وغيره عند التشغيل، ومع ذلك يمكنك دمج عدة ملفات إعدادات مع بعضها، إلّا أنها ليست الطريقة المفضلة ولا تُعدّ ضرورية إذ سيضعب عليك بعدها تتبع أفضل الممارسات الموصى بها للعمل مع Kubernetes. ننصحك أيضًا بالتَعَرُّف على Krew مدير الحزم الخاص بإضافات Kubectl plugins.

الخلاصة

وضح هذا المقال كيفية تثبيت Minikube محليًا على الحاسوب الشخصي، واستخدام لوحة معلومات Kubernetes المُضمنة لمراقبة التطبيقات ونشرها، مع الإضاءة على الفكرة الأهم، وهي إمكانية العمل على نشر مثيل instance تجريبي للتطبيق واختباره محليًا ضمن minikube بالتزامن مع وجود مثيل Kubernetes بعيد نصل إليه بواسطة ملفات تعريف Minikube والراية kubectl --kubeconfig. خلاصة القول: يساعدك minikube على اختبار إعدادات Kubernetes وتقييمها محليًا قبل نشرها الفعلي، لتحدد كيف ومتى تصبح جاهزًا لنشر Kubernetes في بيئة الإنتاج.

ترجمة -وبتصرف- للمقال How To Use minikube for Local Kubernetes Development and Testing لصاحبه Alex Garnett.

اقرأ أيضًا

• تعلم أساسيات Kubernetes
• نشر التطبيقات وتوزيعها وفق نهج التسليم المستمر
• نظام كوبيرنتس Kubernetes وكيفية عمله
• أبرز المفاهيم التي يجب عليك الإلمام بها عن الحاويات

تملك أداة بودمان أداة تسمى بودمان كومبوز Podman Compose وهي بديلة عن أداة دوكر كومبوز Docker Compose وتُتيح لك العمل مع ملفاتها. وكما ذكرنا في مقالاتنا السابقة فإن بودمان يُعدّ بديلًا ممتازًا عن دوكر، لكن إحدى مساوئه هي أنه لا يُتيح ميزة سحب الصور وتشغيل الحاويات بدءًا من ملفات كومبوز. سنتعرف في مقالنا على هذه الأداة والفوائد التي تقدمها عند العمل مع الحاويات وكيفية حل هذه المشكلة من خلالها.

ما هي أداة بودمان كومبوز Podman Compose

تُتيح أداة دوكر خاصيّة تحديد جميع التفاصيل المهمة كاسم الحاوية، والصورة المُستَخدمة، وسياسة إعادة التشغيل restart policy، ووحدات التخزين، والمنافذ، والتسميات، وما شابه، في ملف واحد يدعى عادةً ملف docker-compose.yml.

لكن هذه الخاصيّة ليست موجودةً في بودمان. لذلك يجب أن نستخدم أداة بودمان كومبوز لنحصل عليها. تتبع أداة بودمان كومبوز المواصفات نفسها التي تتبعها أداة دوكر Docker، مما يجعلها تتوافق مع ملفات docker-compose.yml (لكن قد توجد بعض الاختلافات البسيطة كوضع القيم بين علامتي الاقتباس المزدوجة (")، ولكن هذه الاختلافات يمكن حلها بمجرد النظر إلى الأخطاء الناتجة عن استعمال الأداة podman-compose.)

تثبيت أداة بودمان كومبوز podman-compose

تُعد أداة بودمان كومبوز أداةً جديدةً نسبيًا لذلك قد لا تجدها في مستودعات توزيعات لينكس المستقرة وذات الدعم طويل الأمد LTS distributions. لكن إليك الخيارات المتاحة من أجل تثبيتها:

• يمكنك تثبيت أداة بودمان كومبوز في توزيعة أوبنتو ذات الإصدار 22.10 نسخة كينيتك كودو Kinetic Kudu والنسخ الأحدث، وفي توزيعة ديبيان النسخة الثانية عشر بوكوورم Bookworm والنسخ الأحدث منها، باستخدام مدير الحزم apt على النحو التالي:

sudo apt install podman-compose

• أما بالنسبة لمستخدمي الإصدار السادس والثلاثين من توزيعة فيدورا Fedora والإصدارات الأحدث (إصدار حزمة النسخة الخامسة والثلاثون من فيدورا هو 0.1.7-6.git) فيمكنهم استخدام مدير الحزم dnf لتثبيت أداة بودمان كومبوز كما يلي:

sudo dnf install podman-compose

• أما لتثبيتها على نسخة OpenSUSE Tumbleweed أو Leap الإصدار الخامس عشر أو الإصدارات الأحدث فاستخدم الأمر التالي:

sudo zypper install podman-compose

• أما مستخدمو Arch Linux فعليهم استخدام الأمر التالي:

sudo pacman -Syu podman-compose

التأكد من نجاح التثبيت

للتأكد من نجاح عملية تثبيت أداة بودمان كومبوز وأن مسارها الصحيح موجود ضمن متغير البيئة path استخدم الأمر التالي والذي سيعرض لك نسخة بودمان المُستخدمة:

podman-compose --version

إليك خرج الأمر السابق على توزيعة فيدورا النسخة السادسة والثلاثون:

$ podman-compose --version
['podman', '--version', '']
using podman version: 4.3.1
podman-composer version  1.0.3
podman --version
podman version 4.3.1
exit code: 0

أساسيات أداة بودمان كومبوز

إليك المقال التالي عن كيفية استخدام دوكر كومبوز. إليك ملف كومبوز الذي سنستخدمه في مقالنا:

version: 3.7

services:


    reverse-proxy:
        image: docker.io/library/caddy:alpine
        container_name: caddy-vishwambhar
        command: caddy run --config /etc/caddy/Caddyfile
        restart: always
        ports:
            - "8080:80"
            - "8443:443"
        volumes:
            - /docker-volumes/caddy/Caddyfile:/etc/caddy/Caddyfile:Z
            - /docker-volumes/caddy/site:/srv:Z
            - /docker-volumes/caddy/caddy_data:/data:Z
            - /docker-volumes/caddy/caddy_config:/config:Z
            - /docker-volumes/caddy/ssl:/etc/ssl:Z
        labels:
            - io.containers.autoupdate=registry
            - pratham.container.category=proxy
        environment:
            - TZ=Asia/Kolkata
        depends_on:
            - gitea-web


    gitea-web:
        image: docker.io/gitea/gitea:latest
        container_name: gitea-govinda
        restart: always
        ports:
            - "8010:3000"
            - "8011:22"
        volumes:
            - /docker-volumes/gitea/web:/data:Z
            - /docker-volumes/gitea/ssh:/data/git/.ssh:Z
            - /etc/localtime:/etc/localtime:ro
        labels:
            - io.containers.autoupdate=registry
            - pratham.container.category=gitea
        environment:
            - RUN_MODE=prod
            - DISABLE_SSH=false
            - START_SSH_SERVER=true
            - SSH_PORT=22
            - SSH_LISTEN_PORT=22
            - ROOT_URL=https://git.mydomain.com
            - DOMAIN=git.mydomain.com
            - SSH_DOMAIN=git.mydomain.com
            - GITEA__database__DB_TYPE=postgres
            - GITEA__database__HOST=gitea-db:5432
            - GITEA__database__NAME=gitea
            - GITEA__database__USER=gitea
            - GITEA__database__PASSWD=/run/secrets/gitea_database_user_password
            - GITEA__service__DISABLE_REGISTRATION=true
            - TZ=Asia/Kolkata
        depends_on:
            - gitea-db
        secrets:
            - gitea_database_user_password


    gitea-db:
        image: docker.io/library/postgres:14-alpine
        container_name: gitea-chitragupta
        restart: always
        volumes:
            - /docker-volumes/gitea/database:/var/lib/postgresql/data:Z
        labels:
            - io.containers.autoupdate=registry
            - pratham.container.category=gitea
        environment:
            - POSTGRES_USER=gitea
            - POSTGRES_PASSWORD=/run/secrets/gitea_database_user_password
            - POSTGRES_DB=gitea
            - TZ=Asia/Kolkata
        secrets:
            - gitea_database_user_password


secrets:
    gitea_database_user_password:
        external: true

تشغيل كل الحاويات من ملف كومبوز

يمكننا باستخدام الأمر up إنشاء الخدمات المذكورة في ملف كومبوز (docker-compose.yml) وتشغيلها:

podman-compose up -d

يؤدي تشغيل الأمر up إلى تنفيذ كل الإجراءات اللازمة لتشغيل الخدمات والحاويات المذكورة في ملف كومبوز، بما فيه الخطوات التالية:

• سحب الصور غير المتوفرة محليًا.
• إنشاء الحاويات مع الخيارات المحددة (المنافذ، ووحدات التخزين، والشبكات، والمعلومات الحساسة secrets).
• تشغيل الحاويات وفق ترتيب معين (باستخدام القيود constrains مثل depends_on). إذا تمعّنت في المثال السابق ستلاحظ وجود الخيار d- الذي يُشغّل الحاويات في الخلفية ويفصلها عن الصدفة الحالية.

يمكنك التأكد من عمل الحاويات بتشغيل الأمر podman ps:

$ podman ps
CONTAINER ID  IMAGE                                COMMAND               CREATED      STATUS          PORTS                                         NAMES
d7b7f91c03aa  docker.io/library/caddy:alpine       caddy run --confi...  4 hours ago  Up 4 hours ago  0.0.0.0:8080->80/tcp, 0.0.0.0:8443->443/tcp   caddy-vishwambhar
1cfcc6efc0d0  docker.io/library/postgres:14-alpine postgres              4 hours ago  Up 4 hours ago                                                gitea-chitragupta
531be3df06d0  docker.io/gitea/gitea:latest         /bin/s6-svscan /e...  4 hours ago  Up 4 hours ago  0.0.0.0:8010->3000/tcp, 0.0.0.0:8011->22/tcp  gitea-govinda

إيقاف جميع الحاويات باستخدام ملف كومبوز

لإيقاف جميع الحاويات المحددة في ملف كومبوز عليك استخدام الأمر down:

podman-compose down

يمكنك تحديد وقت إيقاف timeout لتتوقف فيه الحاويات عن العمل من تلقاء نفسها، باستخدام أحد الخيارين التاليين:

podman-compose down -t TIMEOUT_IN_SECONDS
podman-compose down --timeout TIMEOUT_IN_SECONDS

يرجى الانتباه إلى أن الأمر down يوقف عمل الحاويات فقط، أما إن أردت حذف الحاويات فعليك حذفها يدويًا.

تشغيل أو إيقاف خدمات معينة

إن كررت استخدام المنافذ ووحدات التخزين ومتغيرات البيئة، فمن المحتمل أنك ستستخدم الأمر podman-compose up والأمر podman-compose down بشكل متكرر. لكن هذا سيؤدي إلى تشغيل كل الخدمات وإيقافها، على التوالي. أي إن أردت تشغيل خدمة معينة أو إيقافها، فعليك انتظار تشغيل جميع الخدمات المدرجة في ملف كومبوز وإيقافها، وهذا ليس أمرًا محبّذًا. ولحل هذه المشكلة، يمكنك استخدام الأمر start والأمر stop لتشغيل وإيقاف خدمة معينة. ويمكنك استخدام الأمر restart لإعادة التشغيل. إليك المثال التالي الذي يوضح تشغيل الخدمة gitea-db، وإيقافها ثم إعادة تشغيلها:

$ podman-comopse start gitea-db

$ podman-compose stop gitea-db

$ podman-compose restart gitea-db

سحب صور الحاويات الضرورية دفعةً واحدة

لنفترض أن لديك عشر خدمات مختلفة في ملف كومبوز وأنك تريد تشغيل الحاويات معًا، إذًا بإمكانك استخدام أمر السحب pull كما يلي:

podman-compose pull

سيؤدي تشغيل الأمر pull إلى سحب كل الصور المحددة في ملف كومبوز.

تغيير اسم ملف كومبوز

قد ترغب بتغيير اسم ملف كومبوز (docker-compose.yml) إلى اسم آخر، لتنفيذ ذلك يمكنك استخدام أحد الخيارين التاليين:

podman-compose -f COMPOSE_FILE_NAME
podman-compose --file COMPOSE_FILE_NAME

على النحو التالي:

podman-compose --file my-compose-file.yml

إن تشغيل الأمر السابق يجعل أداة بودمان كومبوز تغير اسم الملف من docker-compose.yml إلى my-compose-file.yml.

الخلاصة

تهانينا! لقد وصلت إلى نهاية سلسلتنا التعليمية عن أداة بودمان التي تُعدّ أداةً رائعةً لإدارة الحاويات، وعند استخدامها مع أداة بودمان كومبوز يصبح بإمكانك إنشاء حاويات متعددة وتخصيصها وفق الإعدادات التي تناسبك. بها! ننصحك بتجربتها وشاركنا استفساراتك في قسم الأسئلة والأجوبة في أكاديمية حسوب.

ترجمة -وبتصرّف- للمقال Beginner's Guide to Using Podman Compose من موقع Linux Handbook.

اقرأ أيضًا

• المقال السابق: إدارة الحاويات محدودة الصلاحية Rootless Containers باستخدام أداة بودمان Podman
• تشغيل الحاويات تلقائيًا باستخدام أداة بودمان Podman
• الفرق بين أداتي دوكر Docker وبودمان Podman
• نظام كوبيرنتس Kubernetes وكيفية عمله

ستتعلم في هذا المقال كيفية التعامل مع الحاويات محدودة الصلاحية Rootless Containers باستخدام أداة بودمان. إن كنت تستخدم الحاويات لنشر البرمجيات، أو تستخدم أداة بودمان، أو أنك ترغب في رفع مستوى الأمان عن طريق تشغيل الحاويات محدودة الصلاحية rootless containers، فهذا المقال مناسب لك.

ما هي أداة بودمان Podman

إن أداة بودمان Podman هي أحد منتجات شركة Red Hat طُرِحَت كبديل فعّال عن أداة دوكر Docker ويمكنها أداء 99% من المهام التي تؤديها أداة دوكر. بعض ميزات بودمان هي دعم الحاويات محدودة الصلاحية rootless containers، واستخدام نموذج fork/exec لتشغيل الحاويات، وأنه لا يعمل وفق مبدأ البرنامج الخفي أي إنه daemon-less، وثمة كثير من الميزات الأخرى. أما مزايا الحاويات محدودة الصلاحية فهي واضحة، فهي لا تحتاج لصلاحيات الجذر الذي يملك وصولًا كاملًا إلى جميع موارد وملفات النظام كي تعمل، لذلك فإن تشغيلها أكثر أمانًا.

تشغيل حاويات بودمان محدودة الصلاحية Rootless Containers

إذا كنت متمرسًا في مجال تقنية المعلومات، فمن المحتمل أنك وقعت في أحد الخطأين التاليين:

• تشغيل الأمر docker باستخدام Sudo، وبالتالي زيادة امتيازاته.
• إضافة مستخدم محدود الصلاحيات non-root إلى مجموعة دوكر docker group. تلك أخطاء تُضِر بأمان النظام بصورة كبيرة؛ لأنك تسمح لبرنامج دوكر الخفي Docker daemon بالوصول إلى جهازك. وهذا يعرضك للخطر بطريقتين:
• يعمل برنامج دوكر الخفي (dockerd) كجذر، فإذا كانت ثمة ثغرة أمنية فيه، سيكون نظامك بكامله عرضةً للخطر لأن dockerd هي عملية تابعة للمستخدم الجذر.
• قد تحتوي الصورة التي تستخدمها على ثغرات أمنية. تخيّل ماذا سيحدث عند استخدام هذه الصورة بواسطة حاوية تعمل كعملية للمستخدم الجذر root process. يمكن لأحد المخترقين استخدام هذه الصورة للوصول إلى كافة موراد النظام.

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

إليك المزايا التي توفرها أداة بودمان عند إدارة الحاويات محدودة الصلاحية root-less containers:

• يمكنك تخصيص مجموعة من الحاويات المشتركة لكل مستخدم محلي. (على سبيل المثال، بإمكانك تشغيل Nextcloud وMariaDB لدى المستخدم nextcloud_user وتشغيل الحاويات Gitea وPostgreSQL لدى المستخدم gitea_user).
• حتى لو اختُرِقَت الحاوية، فلا يمكن التحكم بالنظام المضيف بكامله، لأن المستخدم المسؤول عن الحاوية ليس جذرًا. لكنه لن يعود صالحًا للاستخدام.

قيود استخدام حاويات بودمان محدودة الصلاحية

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

• لا يمكن تشارك صور الحاويات بين المستخدمين إذا سحب المستخدم user0 صورة الحاوية nginx:stable-alpine فيجب على المستخدم user1 سحبها بنفسه مرةً أخرى. لا توجد لحد الآن طريقة تسمح تشارك الصور بين المستخدمين، لكن يمكنك نسخ الصور من مستخدم لآخر باتباع هذا الدليل من شركة ريد هات Red Hat.
• لا يمكن ربط المنافذ ports binding ذوات الأرقام الأدنى من 1024، لكن ثمة طريقة لحل هذه المشكلة.
• لا يمكن للحاوية محدودة الصلاحية إرسال الطلب ping لأي من المضيفين hosts. لكن ثمة طريقة لحل هذه المشكلة.
• إذا عيّنت معرّفًا مميزًا UID لحاوية بودمان محدودة الصلاحية، فقد يفشل ذلك إن لم تسند المعرّف المميز UID إلى حاوية موجودة مسبقًا. إذًا، من الأفضل تشغيل بودمان من صدفة طرفية (shell) مستخدم موجود، والخيار الأفضل هو إنشاء خدمة systemd لتشغيلها تلقائيًا.

تشغيل حاويات محدودة الصلاحية Rootless Containers باستخدام بودمان

قبل أن تبدأ بتشغيل الحاويات محدودة الصلاحية، ثمة بعض المتطلبات التي عليك توفيرها.

تثبيت حزمة slirp4netns

تُستخدم الحزمة slirp4netns لتوفير خيارات الشبكة لوضع المستخدم user-mode networking لفضاءات أسماء الشبكة. يعد هذا الأمر ضروريًا كي تتفاعل الحاوية محدودة الصلاحية مع أي شبكة وبدونها لا يمكن للحاويات محدودة الصلاحية الاتصال بالإنترنت أو الشبكات الداخلية، مما يحد من فائدتها بشكل كبير. يمكنك تثبيت حزمة slirp4netns على التوزيعات المعتمدة على نظامي ديبيان Debian وأوبنتو Ubuntu باستخدام مدير الحزم apt:

sudo apt install slirp4netns

أما في التوزيعات المعتمدة على نظامي فيدورا Fedora وريد هات Red Hat فاستخدم مدير الحزم dnf لتثبيت الحزمة، على النحو التالي:

sudo dnf install slirp4netns

بالنسبة لمستخدمي Arch Linux فعليك استخدام الأمر pacman على النحو التالي:

sudo pacman -Sy slirp4netns

ضبط subuid و subgid على النحو الصحيح

نظرًا لأن حاويات بودمان محدودة الصلاحية تُشَغّل بواسطة مستخدم موجود على النظام، فإن المستخدم يحتاج إلى إذن لتشغيل هذه الحاوية بمعرّف مميز UID مختلف عن معرف المستخدم. وهذا ينطبق أيضًا على معرّف المجموعة GID. يُمنح كل مستخدم نطاقًا من المعرفات التي يُسمح له باستخدامها، تذكر المعرفات الفريدة UID في الملف ‎‎/etc/subuid‎‎‎‎‎‎، أما معرفات المجموعات GID فتذكر في الملف ‎‎‎‎‎‎‎/etc/subgid‎. وصيغة الملف هي على النحو التالي:

username:initial UID/GID allocated to user:range/size of allowed UIDs/GIDs

فلنفرض أن اسم المستخدم pratham يريد مئة معرّف مميز، والمستخدم krishna يريد ألفًا، إذًا ستكون صيغة الملف ‎/etc/subuid على النحو التالي:

pratham:100000:100
Krishna:100100:1000

يعني هذا أن المستخدم pratham يمكنه استخدام المعرّفات UID من المعرّف 100000 إلى 100100، والمستخدم krishna يمكنه استخدامها بدءً من المعرّف 100100 إلى 101100. يكون هذا عادةً مُعَدًا مسبقًا لكل مستخدم تنشئه، ويُحَدد للنطاق 65536 معرفًا قابلًا للاستخدام سواء كان معرفًا مميزًا UID أم معرّف مجموعة GID. ولكن، يجب أن تضبطه يدويًا في بعض الحالات. ولكن ليس عليك ضبط ذلك يدويًا لكل مستخدم، إذ يمكنك استخدام الأمر usermod لهذا الغرض. إليك صيغة الأمر المطلوبة:

sudo usermod --add-subuids START-RANGE --add-subgids START-RANGE USERNAME 

والآن استبدل كل من السلسلة START و RANGE و USERNAME بما يناسبك. ** تنبيه:** احرص على ضبط سماحيات الملفين ‎/etc/subuid و‎/etc/subgid على القيمة 644 وأن يكونا تابعين للمستخدم الجذر root:root.

ربط المنافذ ذات الأرقام الأدنى من 1024

إن استخدمت وكيلًا عكسيًا reverse proxy لبروتوكول SSL، فأنت تعلم أن المنفذين 80 و443 يجب أن يكونا متاحين لمزود الشهادات مثلLet's Encrypt. إذا حاولت ربط المنافذ الأقل من 1024 بحاوية بودمان محدودة الصلاحية، فستلاحظ أن ذلك غير متاح كميّزة جاهزة out of the box. إذ لا يُسمح للمستخدم غير الجذر بربط أي شيء على المنافذ الأدنى من المنفذ 1024. إذًا، كيف يمكن ربط المنافذ الأدنى بحاويات بودمان محدودة الصلاحية؟ عليك أولاً تحديد المنفذ الأدنى الذي تحتاجه. في حالتنا، تحتاج إلى المنفذين 80 و443 لنشر بروتوكول SSL، لذا فإن أقل منفذ تحتاجه هو المنفذ 80. والآن، أضف السطر التالي إلى الملف ‎/etc/sysctl.conf:

net.ipv4.ip_unprivileged_port_start=YOUR_PORT_NUMBER

ما ستفعله هو تغيير قيمة net.ipv4.ip_unprivileged_port_start إلى قيمة أدنى منفذ تحتاجه، إذًا عليك استبدال YOUR_PORT_NUMBER بالقيمة 80 كي تربط المنفذ 80 بحاوية محدودة الصلاحية.

أين توجد صور الحاويات

كما ذكرنا سابقًا فأحد قيود عمل أداة بودمان هي أنها لا تتيح مشاركة الصور بين المستخدمين. فيجب أن يسحب كل مستخدم الصورة، أو يجب نسخ الصورة من مستخدم لآخر. كلا الخيارين سيحجز ضعف أو أضعاف المساحة، حسب عدد نسخ الصور.حيث تُخَزّن صور حاويات المستخدم في المجلد الرئيسي، وبالتحديد داخل المجلد‎ ~/local/share/containers/storage/‎‎

والآن، بعد أن تحققتَ من توفر المتطلبات السابقة، يمكنك تشغيل الأمر podman run من صدفة خارجية non-root user's shell وإنشاء حاوية. سنستخدم خادم Caddy في مثالنا لنشر بروتوكول SSL. شغّل خادم Caddy في حاوية محدودة الصلاحية واربطه بمنفذ أدنى من المنفذ 1024 على النحو التالي:

$ whoami
pratham

$ podman run -d --name=prathams-caddy -p 80:80 -p 443:443 caddy:alpine
e6ed67eb90e6d0f3475d78b287af941bc873f6d62db60d5c13b1106af80dc5ff

$ podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS            PORTS                                     NAMES
e6ed67eb90e6  docker.io/library/caddy:alpine  caddy run --confi...  2 seconds ago  Up 2 seconds ago  0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp  prathams-caddy

$ ps aux | grep caddy
pratham     3022  0.0  0.0  85672  2140 ?        Ssl  06:53   0:00 /usr/bin/conmon --api-version 1 -c e6ed67eb90e6d0f3475d78b287af941bc873f6d62db60d5c13b1106af80dc5ff [...]
pratham     3025  0.1  0.3 753060 32320 ?        Ssl  06:53   0:00 caddy run --config /etc/caddy/Caddyfile --adapter caddyfile

لاحظ أن المستخدم pratham ليس جذرًا وأنه لا حاجة لاستخدام الأمر sudo لزيادة صلاحيات المستخدم. إذ استطعت تشغيل حاوية خادم Caddy محدودة الصلاحية باستخدام أداة بودمان. يُظهِر خرج الأمر ps أن رمز العملية PID ذو الرقم 3022هو عملية تابعة للمستخدم pratham وهي حاوية خادم Caddy (لكننا لم نُظهِر الخرج كاملًا في مثالنا). أما العملية 3025 فهي تابعة child process للعملية 3022 وهما تابعتان للمستخدم نفسه.

الخلاصة

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

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

ترجمة -وبتصرّف- للمقال Getting Started With Rootless Container Using Podman من Linux Handbook.

اقرأ أيضًا

• المقال السابق: تحديث حاويات بودمان Podman تلقائيًا
• تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة
• الفرق بين أداتي دوكر Docker وبودمان Podman
• الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟
• ما عليك معرفته عن الفرق بين دوكر والأجهزة الافتراضية
• أساسيات تنسيق الحاويات

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

لتسهيل العمل سنستخدم في هذا المقال صورة الخادم Caddy من مستودع Docker Hub.

تعيين مصدر جلب صور الحاويات

كي تستطيع استخدام صورة حاوية (container image) يجب أولًا سحب هذه الصورة من أحد المصادر باستخدام أداة إدارة الحاويات بودمان، يدعى هذا المصدر بسياسة التحديث التلقائي auto-update policy وهي تتضمن قواعد أو إعدادات تحدد زمان وكيفية تحديث الصور أو الحاويات بشكل تلقائي دون تدخل يدوي، مثلاً عند إصدار تحديث جديد للصورة، يتم تحميل التحديث وتطبيقه بشكل تلقائي دون تدخل المستخدم وذلك على النحو التالي:

• سجل registry: عند إسناد سجل (موقع) ما إلى سياسة التحديث التلقائي auto-update policy فإن بودمان سيسحب الصورة من سجل خارجي remote registry مثل Docker Hub أو Quay.io.

• مصدر محلي local: عند إسناد الخيار local إلى سياسة التحديث التلقائي، فإن أداة بودمان ستجلب الصورة من الصور المحلية. يُعدّ هذا الخيار هذا الخيار مفيدًا للمطورين الذين يرغبون في اختبار التعديلات المحلية قبل دفعها إلى سجل بعيد.

ملاحظة: نستخدم في أمثلة هذا المقال حاوية محدودة الصلاحية root-less container، وحاولنا قدر الإمكان ذكر الأوامر الخاصة بالحاويات كاملة الصلاحية root-full container. فإن استخدمت حاوية كاملة الصلاحية وواجهك خطأ يتعلق بصلاحيات المستخدم، فعليك استخدام الأمر sudo.

تفعيل التحديثات التلقائية لحاويات Podman

يمكنك الآن تفعيل التحديثات التلقائية لحاويات بودمان بعد أن أصبحت تعلم ما هو مفهوم سياسة التحديث التلقائي، وذلك باستخدام الأمر التالي:

io.containers.autoupdate=AUTO_UPDATE_POLICY

والآن استبدل السلسلة AUTO_UPDATE_POLICY بالخيار registry أو local.

ولكن كيف ستتحدث الحاوية تلقائيًا وأداة بودمان لا تعمل كبرنامج خفي؟

ضبط خدمة systemd

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

سنشرح في الخطوات التالية كيفية دمج حاويات بودمان سواء كانت حاويات كاملة أو محدودة الصلاحية، مع خدمة systemd وتشغيلها تلقائيًا عند الاقلاع.

الخطوة التمهيدية، إنشاء الحاوية

عليك التأكد أولًا أن لديك حاوية بودمان، سواء كانت قيد العمل أو متوقفة. استخدم الأمر التالي للتحقق من الحاويات الموجودة عندك:

podman container list

لتوضيح أمثلة هذا المقال، اسحب صورةً قديمةً من خادم Caddy (الإصدار 2.5.2-alpine) ثم أعد تسميتها بالاسم alpine، إذ ستساعد إعادة تسمية الصورة في توضيح عملية التحديث. ويمكنك التحقق من ذلك لأن معرف الصورتين هو نفسه. ثم أنشئ حاويةً من الصورة وسمّها prathams-caddy:

$ podman images
REPOSITORY               TAG           IMAGE ID      CREATED      SIZE
docker.io/library/caddy  2.5.2-alpine  d83af79bf9e2  2 weeks ago  45.5 MB
docker.io/library/caddy  alpine        d83af79bf9e2  2 weeks ago  45.5 MB


$ podman container list
CONTAINER ID  IMAGE                   COMMAND               CREATED        STATUS            PORTS       NAMES
99d1838dd999  localhost/caddy:alpine  caddy run --confi...  5 seconds ago  Up 6 seconds ago              prathams-caddy

كما تلاحظ فإن لدينا حاويةً تدعى prathams-caddy تعمل على صورة Caddy (الإصدار الأقدم). عندما تنشئ الحاوية Prathams-caddy أسند سياسة التحديث التلقائي io.containers.autoupdate على خيار السجل registry كما تعلمنا في الخطوة السابقة. إذا كان لديك حاوية بدون هذا التعديل، فلست بحاجة إلى إعادة إنشاء حاوية جديدة. سنتحدث عن ذلك في الخطوة التالية.

الخطوة الأولى، إنشاء ملف خدمة systemd للحاوية

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

عليك تشغيل الأمر التالي للحاويات كاملة الصلاحية root-full container:

sudo podman generate systemd -f --new --name CONTAINER_NAME

والأمر التالي للحاويات محدودة الصلاحية root-less container:

podman generate systemd -f --new --name CONTAINER_NAME

ثم استبدل CONTAINER_NAME باسم حاويتك، وسيتولد بعدها ملف باسم الحاوية كما يلي:

$ podman generate systemd -f --new --name prathams-caddy
/home/pratham/container-prathams-caddy.service

لاحظ من الخرج السابق إنشاء حاوية باسم container-prathams-caddy.service في الملف الحالي. سبق أن ضبطتَ ميزة التحديث التلقائي لهذه الحاوية. أما بالنسبة للحاويات التي لم تضبط فيها هذه الميزة، فليس عليك إعادة إنشاء الحاوية بل يكفي تعديل ملف خدمة systemd وإضافة السطر التالي إلى حقل ExecStart على النحو التالي:

[...]
ExecStart=/usr/bin/podman run \
    [...]
    --label io.containers.autoupdate=registry
[...]

وهكذا يستدعي ملف خدمة systemd أمر تشغيل حاويات بودمان podman run. وكل ما عليك فعله هو إضافة io.containers.autoupdate إلى الأمر podman run.

الخطوة الثانية، نقل ملف خدمة systemd

قبل تفعيل خدمة systemd، يجب عليك نقل ملف الخدمة إلى أحد المجلدين التاليين:

• /etc/systemd/system/ : إذا كانت الحاوية كاملة الصلاحية وتحتاج إلى امتيازات المستخدم المسؤول superuser.
• ~/.config/systemd/user/ : إذا كانت الحاوية محدودة الصلاحية، ضعها في مجلد المستخدم الذي سيشغلها. إن الحاوية Prathams-caddy في مثالنا هي حاوية محدودة الصلاحية، لذا عليك نقلها إلى مجلد المستخدم الخاص بك:

$ mv -v container-prathams-caddy.service ~/.config/systemd/user/
renamed 'container-prathams-caddy.service' -> '/home/pratham/.config/systemd/user/container-prathams-caddy.service'

الخطوة الثالثة، تفعيل خدمة systemd

أصبح بإمكانك الآن تفعيل خدمة systemd بعد أن نقلت ملف الخدمة إلى المجلد المناسب. لكن، يجب أولاً إعلام نظام systemd بالخدمة التي أنشأتها قبل إعادة تشغيل حاسوبك. وذلك بإعادة تحميل systemd باستخدام الأمر التالي إذا كانت الخدمة خاصةً بحاوية كاملة الصلاحية:

sudo systemctl daemon-reload

والأمر التالي للحاويات محدودة الصلاحية:

systemctl --user daemon-reload

أصبح بإمكانك الآن استخدام الأمر systemctl enable لتفعيل الخدمة:

# للحاويات كاملة الصلاحية
sudo systemctl enable SERVICE_NAME.service


# للحاويات محدودة الصلاحية
systemctl --user enable SERVICE_NAME.service

تحقق من حالة الخدمة، ستلاحظ أنها غير نشطة inactive (dead) وذلك لأن الخدمة تعمل عند إعادة إقلاع الحاسوب أو النظام، ولم ننفذ ذلك بعد.

$ systemctl --user enable container-prathams-caddy.service
Created symlink /home/pratham/.config/systemd/user/default.target.wants/container-prathams-caddy.service → /home/pratham/.config/systemd/user/container-prathams-caddy.service.


$ systemctl --user status container-prathams-caddy.service
○ container-prathams-caddy.service - Podman container-prathams-caddy.service
     Loaded: loaded (/home/pratham/.config/systemd/user/container-prathams-caddy.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:podman-generate-systemd(1)

والآن أوقف عمل الحاوية ثم استخدم الأمر التالي لحذفها podman container rm وأعد إقلاع جهازك بعدها.

$ podman stop prathams-caddy
prathams-caddy


$ podman container rm prathams-caddy
99d1838dd9990b2f79b4f2c83bc9bc16dfbaf3fdeeb6c6418ddd6e641535ce21

الخطوة الرابعة، تفعيل بقاء المستخدم نشطًا (اختيارية)

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

sudo loginctl enable-linger

الخطوة الخامسة، تفعيل خدمة التحديث التلقائي

كل ما عليك فعله الآن هو تفعيل خدمة التحديث التلقائي في بودمان باستخدام الأمر التالي:

sudo systemctl enable podman-auto-update.service

بعد تفعيل خدمة التحديث التلقائي podman-auto-update في بودمان، سيتحقق systemd من وجود صورة بحاجة إلى تحديث. إذا كان هناك تحديثات، تُحدّث الصور التي جلبت أولاً، ثم يُعاد تشغيل الحاوية، مع الاحتفاظ بالصورة القديمة في حالة الحاجة إلى التراجع عن التحديث لعدة أسباب.

ملاحظة: على الرغم من أن خدمة التحديث التلقائي في بودمان podman-auto-update.service تُفعّل على مستوى النظام، إلا أن أداة بودمان ليست أساسية في عديد من التوزيعات غير التابعة لتوزيعة فيدورا Fedora. لذلك، ربما تحتاج إلى تشغيل الأمر التالي لتفعيل الخدمة عند المستخدمين محدودي الصلاحية:

 systemctl --user Enable --now podman-auto-update.service

التحديث اليدوي

إن لم تكن من محبي التحديثات التلقائية، فيمكنك تحديث الحاويات يدويًا باستخدام أمر واحد فقط، بشرط أن تكون مدارةً بواسطة systemd.

هذا الأمر هو podman auto-update. وإن أردت التحقق من وجود تحديثات جديدة فقط، فأضف خيار dry-run-- حتى لا تُحَدّث أي حاوية.

والآن لنتحقق من إمكانية تحديث صورة الحاوية "2.5.2-alpine" إلى الإصدار "2.6.1-alpine" باستخدام الأمر podman auto-update:

$ podman container list
CONTAINER ID  IMAGE                   COMMAND               CREATED        STATUS            PORTS       NAMES
a712a3c8846b  docker.io/library/caddy:alpine  caddy run --confi...  2 seconds ago  Up 2 seconds ago              prathams-caddy

$ podman auto-update --dry-run
UNIT                                                     CONTAINER                                 IMAGE                          POLICY      UPDATED
container-prathams-caddy.service  a712a3c8846b (prathams-caddy)  caddy:alpine  registry    pending

لاحظ أن حالة العمود updated في خرج أمر التحديث التلقائي هي pending أو معلقة وهذا يعني أنه ثم تحديث متوفر. كي تحدّث الحاوية، أزل الخيار dry-run-- من الأمر السابق.

الخلاصة

قد تبدو عملية تفعيل التحديثات التلقائية لحاويات بودمان معقدةً بعض الشيء، ولكنها ستؤتي ثمارها على المدى الطويل. تُحدّث جميع الحاويات المُدارة عادة بصورة تلقائية عند منتصف الليل في حال وجود التحديثات. وإن حدثت اي مشكلة في الحاوية فإن systemd سيعيدها إلى صورة قديمة، بحيث تستمر الحاوية في العمل.

ترجمة وبتصرّف للمقال Automatically Updating Podman Containers من Linux Handbook.

اقرأ أيضًا

• المقال السابق: تشغيل الحاويات تلقائيًا باستخدام أداة بودمان Podman
• أساسيات تنسيق الحاويات
• ما الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟
• ما عليك معرفته عن الفرق بين دوكر والأجهزة الافتراضية

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

على الرغم من أن أداة بودمان لا تعمل كبرنامج خفي daemon، وتسمح للمستخدم محدود الصلاحيات unprivileged user بتشغيل الحاويات دون الحاجة إلى الوصول إلى الجذر، مما يزيد من أمان النظام. لكنها ليست أداةً مثاليةً بالكامل فهي لا تُتيح إعادة تشغيل الحاويات تلقائيًا بعد إقلاع الخادم.

سياسة إعادة تشغيل الحاويات

عند الاطلاع على صفحة التعليمات man الخاصة بالأمر podman-run ستجد أن خيار إعادة التشغيل restart-- لا يعيد تشغيل الحاويات عندما يقلع النظام. وسبب هذا يرجع إلى أن بنية بودمان لا تعتمد مبدأ البرنامج الخفي، أي إن بودمان لا يعمل تلقائيًا عند إقلاع النظام، وبالتالي فإن الحاويات لا تعمل عند الإقلاع أيضًا. على عكس أداة دوكر التي تعتمد مبدأ البرنامج الخفي الذي يعمل عند إقلاع النظام ويُشَغّل الحاويات المحددة.

حل مشكلة عدم التشغيل التلقائي للحاويات

أيًّا كانت توزيعة نظام التشغيل التي تعمل عليها فلا بد أنها تستخدم systemd كنظام تمهيد init، وهذا ما سنحاول الاستفادة منه في إيجاد حل للمشكلة.

الخطوة الأولى: إعداد الحاوية وتشغيلها

ثمة عدة طرق ممكنة لتشغيل الحاوية. إن كان لديك حاوية بسيطة فبإمكانك استخدام الأمر podman run. أو يمكنك استخدام ملف دوكر إن أردت حاويةً بإعدادات معقدة واحتجت لمزيد من التحكم بهذه الإعدادات. لتوضيح ذلك، سننشئ حاويةً من صورة الحاوية mariadb وسنسميها chitragupta-db.

$ podman ps
CONTAINER ID  IMAGE                             COMMAND               CREATED         STATUS             PORTS       NAMES
422eed872347  docker.io/library/mariadb:latest  --transaction-iso...  58 seconds ago  Up 58 seconds ago              chitragupta-db

يمكنك إيقاف الحاوية الجديدة لاحقًا.

الخطوة الثانية: إنشاء خدمة systemd

كما ذكرنا سابقًا، فإن بودمان ليس برنامجًا خفيًا أي إنه daemon-less لإدارة الحاويات. إذًا، فإن تشغيل حاويات بودمان يحتاج إلى تشغيل يدوي أو خارجي. سننفذ ذلك من خلال إنشاء خدمة systemd. حيث إن خدمة systemd هي نظام تمهيد init يدير الخدمات والبرامج الخفية في أنظمة تشغيل لينكس.

إنشاء ملف وحدة systemd

ليس عليك إنشاء ملف وحدة systemd يدويًا، إذ يمكن تنفيذ ذلك باستخدام الأمر podman generator systemd على النحو التالي:

podman generate systemd --new --name CONTAINER_NAME

لإنشاء ملف وحدة systemd للحاوية استخدم الأمر podman generate systemd متبوعًا باسم الحاوية، اسم الحاوية في مثالنا هو chitragupta-db:

كما تلاحظ فإن الأمر السابق نفّذ العمل المطلوب، ولكننا لم ننته من العمل بعد.

إن خرج الأمر podman generate systemd هو ما يجب أن يكون موجودًا في ملف وحدة systemd، لكن ثمة خيار مفيد يمكنك الاستعانة به بدلًا من نسخ الخرج ولصقه، وهو الخيار files -- أو اختصارًا f-. إذ سيؤدي استخدام هذا الخيار أولًا إلى ملء الملف بالمحتوى المطلوب بدلاً من طباعته على الطرفية، وثانيًا، إنشاء ملف باسم Container-CONTAINER_NAME.service في مجلد العمل الحالي.

$ podman generate systemd --new --name chitragupta-db -f
/home/pratham/container-chitragupta-db.service

$ ls *.service
Container-chitragupta-db.service

لاحظ أن اسم الحاوية في مثالنا هو chitragupta-db، وأنه أصبح لدينا ملف باسم container-chitragupta-db.service في المجلد الحالي. بما أن الأمر podman generate systemd سوف ينشئ ملف وحدة systemd فإن بإمكانك استخدام الخيارات التالية =after=, --requires=, --wants-- لتحديد الاعتماديات للحاويات.

نقل ملف خدمة systemd إلى موقع محدد

كما لاحظت فإن الأمر السابق سينشئ ملف وحدة systemd جديد في مجلد العمل الحالي، لكن ذلك ليس الخيار الأنسب. إليك المسار المناسب للملف بالنسبة للمستخدم المسؤول superuser: /etc/systemd/system/ أما بالنسبة للمستخدم محدود الصلاحيات non-root user فهو: ~/.config/systemd/user/ والآن عليك نقل الملف إلى المجلد المناسب. بما أن الحاوية في مثالنا هي حاوية محدودة الصلاحية، فعليك نقلها إلى المجلد config/systemd/user/.~.

$ mv -v container-chitragupta-db.service ~/.config/systemd/user/
renamed 'container-chitragupta-db.service' -> '/home/pratham/.config/systemd/user/container-chitragupta-db.service'

وهكذا بعد أن أنشأت ملف وحدة systemd بالاستعانة بأوامر الطرفية ونقلته إلى المجلد الصحيح، ما تبقى عليك الآن هو تفعيله.

الخطوة الثالثة: تفعيل حاوية خدمة systemd

عليك الآن أن تعيد إقلاع systemd كي تتفعل الخدمة التي أنشأتها في الخطوة السابقة. استخدم الأمر التالي لإعادة تشغيل خدمة systemd للمستخدم الجذر:

sudo systemctl daemon-reload

أما بالنسبة للمستخدم محدود الصلاحيات فعليك إزالة الأمر sudo وإضافة الخيار user--، كي يصبح الأمر على الشكل التالي:

systemctl --user daemon-reload

وهكذا سيُعاد تشغيل خدمة systemd دون إعادة إقلاع النظام، وسيُحدّث وتظهر الخدمة الجديدة container-chitragupta-db.service.

والآن أصبح بإمكانك تفعيل الخدمة الجديدة. استخدم الأمر التالي لتفعيل الخدمة للمستخدم الجذر:

sudo systemctl enable SERVICE_NAME.service

أما بالنسبة للمستخدم محدود الصلاحيات فعليك إزالة الأمر sudo وإضافة الخيار user--، كي يصبح الأمر على الشكل التالي:

systemctl --user enable SERVICE_NAME.service

ستحصل على الخرج التالي عند تفعيل الحاوية محدودة الصلاحية root-less container:

$ systemctl --user enable container-chitragupta-db.service
Created symlink /home/pratham/.config/systemd/user/default.target.wants/container-chitragupta-db.service → /home/pratham/.config/systemd/user/container-chitragupta-db.service.

يمكنك التحقق من حالة الخدمة بعد تفعيلها بإضافة الأمر status على الأمر السابق للمستخدم الجذر والمستخدم محدود الصلاحية وفقًا لما يلي:

# للمستخدم الجذر
sudo systemctl status SERVICE_NAME.service


# للمستخدم محدود الصلاحية
systemctl --user status SERVICE_NAME.service

إليك حالة الخدمة container-chitragupta-db:

$ systemctl --user status container-chitragupta-db.service
○ container-chitragupta-db.service - Podman container-chitragupta-db.service
     Loaded: loaded (/home/pratham/.config/systemd/user/container-chitragupta-db.service; enabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:podman-generate-systemd(1)

لا تقلق لأن حالة الخدمة تظهر غير نشطة inactive (dead)، إذ فعّلنا الخدمة الآن ويجب أن تعمل الخدمة عند إقلاع النظام، وليس الآن، وهذا هو المطلوب. إذا لم توقف الحاوية في الخطوة الأولى، فهذا هو الوقت المناسب لإيقافها عن طريق استخدام الأمر podman stop ثم استخدام
الأمر  podman container rm لحذفها، وإعادة إقلاع النظام بعدها لتشغيل خدمة الحاوية.

الخطوة الرابعة: تفعيل خدمة إعادة التشغيل

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

لتفعيل خدمة إعادة التشغيل عليك استخدام الأمر التالي:

systemctl --user enable podman-restart.service

يحرص الأمر podman-restart على إعادة تشغيل جميع الحاويات التي ضُبطت ليُعاد تشغيل دائمًا أي عند ضبط الأمر restart-policy على الخيار always.

الخطوة الخامسة، تفعيل بقاء المستخدم محدود الصلاحية نشطًا (خطوة اختيارية)

بما أنك فعّلت هذه الخدمة بواسطة مستخدم عادي محدود الصلاحية وليس المستخدم الجذر، هذا يعني أن المستخدم يحتاج إلى تسجيل الدخول عند التشغيل ويجب أن يظل نشطًا إن خرج من جلسة واجهة المستخدم الرسومية GUI أو من الطرفية. ويمكن تحقيق ذلك باستخدام الأمر loginctl من طرفية المستخدم نفسه، على النحو التالي:

sudo loginctl enable-linger

يضمن هذا الأمر تفعيل جلسة المستخدم عند الإقلاع وبقاءها نشطةً حتى بعد تسجيل الخروج من واجهة المستخدم الرسومية أو الطرفية.

وبهذا تكون قد فعّلتَ إعادة تشغيل حاويات بودمان عند الإقلاع. حيث ستؤدي إعادة تشغيل النظام إلى التشغيل التلقائي للحاويات التي أنشأت لها ملف وحدة systemd.

تعديل خدمة systemd

نعلم جميعًا أن الإعدادات الافتراضية تفيد المبتدئين دائمًا، إذ تساعد على تخفيف شعور الارتباك لديهم. تُعد الإعدادات الإفتراضية لملف systemd الذي أنشأته مثاليةً لمعظم الأشخاص، لكن إن لم تكن مبتدئًا فبإمكانك إضافة مزيد من التعديلات من خلال تعديل ملف systemd أو إنشاء خدمة مخصصة جديدة من الصفر.

الخلاصة

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

ترجمة وبتصرّف للمقال Autostarting Podman Containers من موقع Linux Handbook.

اقرأ أيضًا

• المقال السابق: إنشاء الحاويات وحذفها باستخدام أداة بودمان Podman
• نظام كوبيرنتس Kubernetes وكيفية عمله
• كيفية تأمين الحاويات عن طريق سي لينكس SELinux
• الفرق بين أداتي دوكر Docker وبودمان Podman

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

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

ما ستتعلمه في سلسلة تعرف على أداة بودمان Podman

سنتعلم في هذه سلسلة ما يلي:

• الفرق بين أداتي دوكر وبودمان
• إنشاء الحاويات وحذفها باستخدام أداة بودمان
• تفعيل حاويات بودمان تلقائيًا عند إقلاع النظام
• تحديث الحاويات
• مفهوم الحاويات محدودة الصلاحية Rootless containers
• مفهوم بودمان كومبوز Podman Compose

متطلبات هذه السلسلة

• معرفة مسبقة بمفهوم الحاويات
• تجربة مسبقة في التعامل مع دوكر
• خبرة في التعامل مع سطر الأوامر أو الطرفية Terminal في لينكس

كما تعلمنا في مقال سابق فإن أداة بودمان هي أداة بديلة عن دوكر تستخدم لإدارة الحاويات، ولها بنية أوامر مشابهة لأوامر دوكر. وسنتعلم في مقال اليوم كيفية إنشاء الحاويات وحذفها.

سحب الصور من سجل الصور باستخدام بودمان

عند إنشاء الحاويات، ستحتاج أولًا إلى صورة للحاوية image، إذ لا يمكنك تنفيذ شيء بدون الصورة. ولذلك عليك سحب pull الصورة من سجل الصور.

إليك بعض سجلات الصور الشهيرة:

• Docker Hub
• Quay.io
• سجلات الصور المستضافة مثل linuxserver.io

ولسحب صورة باستخدام بودمان فعليك استخدام الصيغة التالية:

podman pull [OPTIONS] FULLY_QUALIFIED_IMAGE_NAME[:tag|@digest]

لمعرفة معنى اسم الصورة المؤهل بالكامل FULLY_QUALIFIED_IMAGE_NAME واختصارًا FQIN، ألقِ نظرةً على الأمرين التاليين:

# باستخدام اسم الصورة المؤهل تمامًا
podman pull docker.io/library/debian

# بدون اسم الصورة المؤهل تمامًا
podman pull debian

كما تلاحظ، في اسم الصورة المؤهل بالكامل، يكون التنسيق على النحو التالي: السجل/اسم المستخدم/اسم الصورة. في مثالنا فإن docker.io هو عنوان سجل دوكر hub.docker.com.

لسحب وسم tag محدد، اكتب اسم الوسم بعد اسم الصورة، مسبوقًا بنقطتين (:). إليك مثالًا عن سحب الوسم stable-slim لصورة ديبيان:

podman pull docker.io/library/debian:stable-slim

عرض الصور المتاحة

بعد سحب صورة أو أكثر، يمكنك معاينة الصور المتوفرة محليًا باستخدام الأمر podman Images. عند سحب صورة debian:stable-slim، ستحصل على الخرج التالي:

$ podman images
REPOSITORY                TAG          IMAGE ID      CREATED     SIZE
docker.io/library/debian  stable-slim  86f9b934c377  2 days ago  77.8 MB

والآن بعد أن حصلت على الصورة يمكنك إنشاء حاوية جديدة

إنشاء حاوية جديدة

لإنشاء حاوية جديدة في بودمان، عليك استخدام الأمر podman run بالطريقة التالية:

podman run [OPTIONS] image [COMMAND [ARGS]]

والآن، سنضيف بعض الخيارات options على الأمر السابق، سنضيف أولًا الخيار d- لتشغيل الحاوية باستمرار في الخلفية، والخيار t- لتخصيص طرفية زائفة pseudo-TTY لصورة ديبيان كي تعمل باستمرار. يمكنك الاطلاع على قائمة الخيارات المتاحة من توثيقات بودمان.

والآن، سننشئ حاوية بسيطة تعتمد على صورة توزيعة ديبيان stable-slim التي سحبناها مسبقًا.

podman run -d -t debian:stable-slim

عند نجاح إنشاء الحاوية، ستحصل في الخرج output على سلسلة عشوائية من الأحرف والأرقام. هذه السلسلة هي معرف الحاوية الفريد unique container ID.

61d1b10b5818f397c6fd8f1fc542a83810d21f81825bbfb9603b7d99f6322845

عرض الحاويات

أولًا، لعرض الحاويات قيد التشغيل، عليك استخدم الأمر podman ps، وهو يشبه الأمر ps في لينكس، لكن بدلاً من إظهار عمليات النظام، فإنه يظهر الحاويات قيد التشغيل وتفاصيلها.

بما أننا استخدمنا الخيار t- لتشغيل حاوية دبيان، فلنرَ كيف تبدو نتيجة الأمر podman ps:

$ podman ps
CONTAINER ID  IMAGE         COMMAND         CREATED         STATUS         PORTS         NAMES
61d1b10b5818  docker.io/library/debian:stable-slim  bash        44 seconds ago  Up 44 seconds ago              gallant_mahavira

يمكنك الحصول على معلومات عن الحاوية باستخدام الأمر ps كمعرّف الحاوية الفريد القصير، والصورة المستخدمة لإنشاء هذه الحاوية، ومتى أُنشِئت الحاوية، ومنافذ الجهاز المضيف المسندة إلى منافذ الحاوية واسمها. ونلاحظ من الخرج أن الصورة المستخدمة هي debian:stable-slim أُنشِئت قبل 44 ثانية، أما اسم الحاوية فهو gallant_mahavira.

يمكنك تسمية الحاوية عند إنشائها باستخدام الخيار name CONTAINER_NAME--، فعندما لا تحدد اسم الحاوية، يُولَد اسم عشوائي لها. ثانيًا، لعرض الحاويات المتوقفة عن العمل Stopped containers عليك استخدام الأمر التالي:

podman container list -a

والآن، سنتعلم كيفية إيقاف الحاويات.

إيقاف الحاويات

لإيقاف الحاويات عليك استخدام الأمر podman stop مع معرّف الحاوية أو اسمها، وذلك وفق الصيغة التالية:

podman stop [CONTAINER_NAME|CONTAINER_ID]

والآن سنوقف الحاوية الجارية باستخدام اسمها:

$ podman stop gallant_mahavira
gallant_mahavira

والآن بإمكانك استخدام الأمر السابق لعرض جميع الحاويات الجارية والمتوقفة:

$ podman container list -a
CONTAINER ID  IMAGE                                 COMMAND     CREATED         STATUS                      PORTS       NAMES
61d1b10b5818  docker.io/library/debian:stable-slim  bash        14 minutes ago  Exited (137) 3 minutes ago              gallant_mahavira

ملاحظة: ترتبط كل من الأوامر podman container list and podman container ls، podman ps، podman container ps بنفس الملف الثنائي binary ولها نفس الاستخدام وتعطي نفس الخرج.

إعادة تشغيل الحاوية

لإعادة تشغيل حاوية ما بعد إيقاف عملها أو فشله، عليك استخدام الأمر podman start. فلنفترض أن الحاوية التي أنشأتها من صورة ديبيان فشلت لسبب ما، إذًا يمكنك إعادة تشغيلها عن طريق كتابة اسمها أو معرّفها بعد الأمر podman start كالتالي:

$ podman start 61d1b10b5818f397c6fd8f1fc542a83810d21f81825bbfb9603b7d99f6322845

حذف الحاويات

قبل حذف حاوية أو تدميرها عليك أولًا إيقافها، وبعدها يمكنك استخدام الأمر podman rm لحذفها. بمجرد حذف الحاوية، فإنها ستختفي ولن تظهر في خرج الأمر podman Container list -a. إليك المثال التالي على إيقاف وحذف حاوية باستخدام بودمان، والذي استخدمنا فيه اسم الحاوية ومعرفها.

$ podman ps
CONTAINER ID  IMAGE         COMMAND     CREATED         STATUS           PORTS       NAMES
61d1b10b5818  docker.io/library/debian:stable-slim  bash        44 minutes ago  Up 1 second ago              gallant_mahavira


$ podman stop gallant_mahavira
gallant_mahavira


$ podman rm 61d1b10b5818
61d1b10b5818f397c6fd8f1fc542a83810d21f81825bbfb9603b7d99f6322845


$ podman container list -a
CONTAINER ID  IMAGE         COMMAND     CREATED     STATUS      PORTS       NAMES

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

الخاتمة

تهانينا، لقد وصلت إلى نهاية المقال الثالث في سلسلتنا التعليمية حول أداة بودمان، وتعلمت كيفية إنشاء الحاويات وعرضها وإيقافها وحذفها، تابع قراءة باقي المقالات كي تتعلم المزيد حول بودمان. ترجمة -وبتصرف- للمقال Creating and Destroying Containers Using Podman من موقع Linux Handbook.

اقرأ أيضًا

• المقال السابق: الفرق بين أداتي دوكر Docker وبودمان Podman

• مدخل إلى حاويات لينكس LXC

• ما هي صورة الحاوية container image؟

• نظرة عامّة على إعداد الحاويات containerization على Docker

إن أداة بودمان Podman هي أداة مقدمة ومدعومة من قبل توزيعة ريد هات Red Hat كبديل عن أداة دوكر Docker. فأداة بودمان شبيهةً بدوكر ويمكنك بدء استخدامها إن كنت على معرفة بدوكر.

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

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

ما ستتعلمه سلسلة التعرف على أداة بودمان Podman

سنتعلم في هذه السلسلة ما يلي:

• الفرق بين أداتي دوكر وبودمان.
• إنشاء الحاويات وحذفها باستخدام أداة بودمان.
• تفعيل حاويات بودمان تلقائيًا عند إقلاع النظام.
• تحديث الحاويات.
• مفهوم الحاويات محدودة الصلاحية Rootless containers.
• مفهوم بودمان كومبوز Podman Compose.

متطلبات هذه السلسلة

• معرفة مسبقة بمفهوم الحاويات Containers.
• تجربة مسبقة في التعامل مع دوكر.
• خبرة في التعامل مع سطر الأوامر أو الطرفية Terminal في لينكس Linux.

سنناقش في مقال اليوم الفرق بين أداتي دوكر وبودمان بالتفصيل، حيث يترافق مصطلح الحاويات Containers في ذهننا مع أداة دوكر Docker، لكن دعونا نتعرف في مقالنا على الفرق بينها وبين أداة بودمان Podman التي ازداد استخدامها مع الحاويات.

ومع انتشار استخدام الحاويات أصبحت أداة دوكر، التي ظهرت في عام 2014، أشهر أداة لإدارة الحاويات. ونشرت شركة ريد هات Red Hat في عام 2018، أداة بودمان كبديل عن دوكر. وبما أن الأداتين لهما الغرض نفسه، سنتعرف في هذا المقال على مزايا كل منهما.

مفهوم الحاويات

لنفترض أنك تعمل كمهندس برمجيات وطُلِب منك نشر مجموعة برامج ذات مهام حرجة. ماذا ستفعل لو كان البرنامج الأول والبرنامج الثاني لهما نفس الاعتمادية dependency ولكنهما يعملان على إصدارات مختلفة من نفس الاعتمادية؟ أو لو كانت تبعية البرنامج الأول تتعارض مع الاعتمادية البرنامج الثاني؟

في هذه الحال عليك نشرهما في جهازين افتراضيين Virtual Machine مختلفين، لكن هذا يلغي قابلية التوسع scalability، لأنه عند تشغيل جهازين افتراضيين على نفس الجهاز، سيرث البرنامج 50% فقط من إجمالي قدرة الجهاز الحاسوبية. وعند زيادة عدد البرامج من برنامجين إلى عشرة سيتضح لك أن هذا الحل غير فعّال.

حيث إن إحدى مساوئ الآلات الافتراضية هي أنها تعمل بنظام تشغيل كامل، وهذا يُعد أمرًا سلبيًا في حالتنا. فلو كان عندنا عشرة أجهزة افتراضية تعمل بنظام تشغيل ريد هات RHEL، سيصبح عندنا عشر نسخ من نفس الثنائيات binaries، وسيؤدي ذلك إلى استهلاك غير فعّال لذاكرة الوصول العشوائي RAM. حتى إن أبسط عملية تثبيت installation ستحجز أكثر من 4 جيجابايت من مساحة القرص لكل جهاز افتراضي.

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

فالمشكلة تكمن في طبيعة عمل الآلات الافتراضية؛ فعندما تنشئ آلةً افتراضية، تُنشَأ نسخة افتراضية من العتاد hardware. أي نسخة افتراضية من وحدة المعالجة المركزية وذاكرة الوصول العشوائي، وذاكرة التخزين والموارد الأخرى، ولا بد أن لهذا حمل على الجهاز.

أما عند استخدام الحاويات، تُنشَأ نسخ من البرنامج مع اعتماديّاته، وهذا له حمل منخفض مقارنةً بالآلات الافتراضية.

الغرض من استخدام دوكر أو بودمان

ربما استخدمت برنامج فيرتشوال بوكس VirtualBox المُقدَّم من أوراكل Oracle لإدارة الآلات الافتراضية، والذي يُتيح لك إنشاء آلات افتراضية وتشغيلها أو إيقافها، وتعديلها، وحذفها. تُتيح كل من أداتي دوكر وبودمان ذلك، ولكنها تتعامل مع البرامج الموجودة في حاويات، وليس الآلات الافتراضية.

وعلى الرغم من أن كِلا الأداتين تعملان وفق فلسفتين مختلفين، إلا أن كلتاهما تساعدان على إدارة الحاويات. لذلك سنتعرف الفروق بينهما وأي منهما هو الأفضل وفقًا لغرض الاستخدام الذي تريده.

دوكر أم بودمان

يُعد كل من دوكر و بودمان من البرامج الممتازة لإدارة الحاويات. وعندما أعلنت شركة ريد هات عن طرحها لبودمان كبديل عن دوكر قالت إن بودمان متوافق مع واجهة سطر أوامر دوكر، أي إن الانتقال من دوكر إلى بودمان لا يتطلب تغييرات كبيرة على الشيفرة البرمجية. هذا يعني أنه يمكنك استبدال أمر docker بالأمر podman وسيعمل البرنامج.

ولكن ثمة بعض الاختلافات الأساسية، التي سنتعرف عليها:

أولًا، مفهوم البرنامج الخفي Daemon

إن الفرق الرئيسي الذي يميز بين أداتي دوكر وبودمان هو طريقة عملهما على نظام التشغيل. حيث تعمل نواة دوكر Docker core كبرنامج خفي dockerd، أي إنه يعمل دائمًا في الخلفية ويدير الحاويات. أما أداة بودمان فتشبه البرنامج العادي؛ أي إنه يبدأ العمل عند تنفيذ إجراء ما فيه (بدء أو إيقاف حاوية). تتميز طريقة عمل دوكر المعتمدة على البرنامج الخفي Daemon-based approach بما يلي:

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

ثانيًا، الأمان Security

إن أهم سبب لاستخدام بودمان بدلًا من دوكر هو الأمان، إذ طُرح بودمان كبديل أكثر آمنًا من دوكر. فإذا كنتَ مهتمًا بالأمان، فستجذبك اثنتان من ميزات بودمان الأساسية. ذكرنا آنفًا أن ما يميز بودمان عن دوكر هو أن بودمان لا يعمل كبرنامج خفي. أما الميزة الأساسية الثانية لبودمان هي أنه يمكنه تشغيل الحاويات دون صلاحيات الوصول إلى الجذر root. هذا يعني أنك لست بحاجة إلى امتيازات المستخدم المميز superuser لإدارة الحاويات. والآن، إليك ثلاثة أسباب تجعلك تفضل استخدام بودمان بدلًا عن دوكر إن كنت مهتمًا بالحصول على مستوى أعلى من الأمن.

السبب الأول، يعمل الأمر dockerd كمستخدم جذر

كما تعلم فإن نواة دوكر تعمل كبرنامج نظام خفي system daemon، أي كبرنامج ينفذه المستخدم المسؤول أو الجذر root user. سبق وذكرنا فوائد البرنامج الخفي، لكن ثمة بعض المشاكل الأمنية عند تشغيل البرنامج الخفي كمستخدم جذري. أولًا، إذا اختُرق برنامج دوكر الخفي (dockerd)، فيمكن لأحدهم أن يخترق نظامك من خلال الوصول إلى الجذر. ولا شك أنك لا تود حدوث ذلك. وهنا تتضح ميّزة بودمان إذ إنه لا يستخدم برنامجًا خفيًا وليس له متطلبات صارمة للوصول إلى الجذر. وهذا يقودنا إلى السبب الثاني.

السبب الثاني، يدعم بودمان الحاويات دون صلاحيات جذر

ربما سمعت أن بودمان يدعم تشغيل الحاويات دون الوصول إلى الجذر أو ما يعرف Root-less containers، وهذا أمر صحيح وأكثر أمنًا. والآن، لنفترض أن برنامج دوكر الخفي آمن، وأن صورة الحاوية التي تستخدمها فيها ثغرة أمنية. ولكن المطور لا يعرف ذلك. إذا شَغّلتَ هذه الصورة في حاوية تابعة للمستخدم الجذر، فاعلم أن الحظ ليس حليفك. أما عند استخدام بودمان، فيمكنك تشغيل الحاوية دون الحاجة إلى امتيازات الجذر. هذا يعني أنه إن احتوت صورة الحاوية على ثغرة أمنية، فلن يتعرض للخطر سوى المستخدم الذي يملك تلك الحاوية. أما بقية مستخدمي النظام فهم بأمان، ولا سيما المستخدم الجذر. وعلى الرغم من أن دوكر حصل مؤخرًا على دعم لتشغيل الحاويات محدودة الصلاحية Rootless containers ، لكن لا يزال ينقصه بعض الميزات، وهي أن دعم AppArmor غير موجود. وهو نظام التحكم الإلزامي بالوصول (MAC) الافتراضي الخاص بتوزيعتي ديبيان وأوبنتو

السبب الثالث، تحديث الصور تلقائيًا

قد يخطر في ذهنك أن تحديث الصور تلقائيًا لا يمكن أن يكون ميزة، لكنها كذلك. تذكر السبب الثاني الذي ذكرناه وافترض أن المطورين يعلمون بوجود الثغرة الأمنية، ثم أصدروا إعلانًا بذلك ونشروا الصورة المصححة. لكن ميزة التحديث التلقائي ليست مدمجة built in في دوكر، فماذا عن بودمان؟ يعتمد الجواب على كيفية تعريفنا لكلمة "مدمجة". نظرًا لأنه ليس لبودمان برنامج خفي، فإنه لا يمكنه إجراء فحوصات منتظمة للحصول على التحديثات. لكن بما أن بودمان هو أحد منتجات ريد هات Red Hat، فيمكن تحديث الحاويات تلقائيًا عن طريق systemd لأنه يتوافق معه، وهذا ما سنتحدث عنه في مقالنا التالي من هذه السلسلة.

ملاحظة: لا تعني الأسباب التي ذكرناها أن دوكر غير آمن وأنه يجب على الجميع استخدام بودمان، إذ لا يوجد شيء آمن بنسبة 100%. لكن وجب تسليط الضوء عليها من باب الاحتياط وأخذ الحذر.

ثالثًا، النهج المتبع في بودمان

ربما لاحظت أن دوكر يتّبِع نهج "الحل الواحد" وأن بودمان يتّبع نهجًا مختلفًا. وهذا يعني أنه ليس عليك سوى تثبيت الملف الثنائي binary لدوكر على نظامك. ويمكنك استخدام الأمر docker لإنشاء الصور ونشرها (إلى السجلات مثل سجل hub.docker.com) وإدارة الحاويات. ولكن بالنسبة لبودمان، نشرت شركة ريد هات Red Hat ثلاثة ثنائيات منفصلة. فعليك استخدام الأمر buildah لبناء الصور. ولنشرها على سجل مثل سجل hub.docker.com، فعليك استخدام الأمر skopeo. ولإدارة الحاويات، فاستخدم الأمر podman. كلا النهجين يؤدي الغرض المرجو منه، إذًا فالأمر يعتمد على ما تفضّله، هل تفضّل استخدام نهج الحل الشامل الذي يقدمه دوكر أم تفضل نهج الحل المتشعب لبودمان.

رابعًا، أداة دوكر سوارم Docker Swarm

تُعدّ أداة دوكر سوارم Docker Swarm مفيدةً لتوسيع نطاق الحاويات باستخدام عدة أجهزة حقيقية وافتراضية. إذ يمكنك وضع عدة حواسيب ضمن "سرب" أو swarm من أجل غرض محدد. فيمكن أن تخصص سربًا للتعامل مع طلبات قاعدة البيانات فقط، وسربًا آخر للتعامل مع خادم ويب. في حين أن هذه الميزة غير متوفرة في بودمان، إلا أنه يمكنك الاستفادة منها باستخدام Kubernetes. ويمكننا القول إن Kubernetes يستخدم على نطاق أوسع من Docker Swarm، وعند الحاجة إلى التوسع واستخدام عدة أجهزة، فإن Kubernetes يلبي احتياجاتك على أفضل وجه.

الخاتمة

تُعد أداة دوكر مرادفةً للحاويات. لكن أنشأت شركة ريد هات Red Hat أداة بودمان لإدارة الحاويات للتغلب على بعض أوجه القصور في عمل دوكر. وتوافق بودمان مع أوامر دوكر يُسهل التوجه نحو استخدامها دون الحاجة إلى ترك ما تعلمته عن دوكر. لا يعني ذلك أن المسؤولين عن أداة دوكر لا يعملون على تحسينها، إذ إن إضافة ميزة الحاويات محدودة الصلاحية rootless containers هي خير دليل على ذلك. والآن فإن الخيار متروك لك في استخدام الأداة التي تفضلها، وللتعرف على المزيد حول أداة بودمان، تابع مقالنا التالي. ترجمة وبتصرّف للمقال Understanding the Differences Between Podman and Docker من سلسلة Container Management With Podman.

اقرأ أيضًا

• مدخل إلى دوكر Docker
• ما الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟
• كيفية تأمين الحاويات عن طريق سي لينكس SELinux
• نظام كوبيرنتس Kubernetes وكيفية عمله

كوبرنيتس Kubernetes هو نظام فعّال ومفتوح المصدر لإدارة التطبيقات المغلفة داخل الحاويات والمبنية في بيئة عنقودية (Clustered environment)، طوّرته في البداية شركة جوجل ثم حظي بدعم مؤسسة CNCF أو Cloud Native Computing Foundation، وهدفه الأساسي توفير طرق مرنة لإدارة الخدمات والمكونات الموزعة في بنية تحتية متنوعة التقنيات.

فإذا كنت تتساءل ما هو Kubernetes؟ وما مكوناته الأساسية وما المشكلات التي يحلّها؟ وأي نموذج يعتمد في نشر التطبيقات وتوسعتها؟ فسيُجيبك هذا المقال على كل تساؤلاتك تلك.

ما هو Kubernetes؟

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

يُمَكِّنُك كوبرنيتس Kubernetes من تحديد كيفية تشغيل تطبيقاتك، وطريقة تفاعلها مع التطبيقات الأخرى ومع المصادر الخارجية، ويمنحك القدرة على توسيع مواردها الحاسوبية أو إنقاصها حسب الحاجة، ويسهل إجراء التحديثات التدريجية rolling updates بسلاسة دون انقطاع الخدمة، وتبديل حركة مرور البيانات بين إصداراتها المختلفة لاختبار الميزات الجديدة أو للتراجع عن عمليات النشر المصحوبة بالأخطاء أو غير ذلك. وتأتي إمكاناته هذه مما يوفره لمستخدميه من واجهات استخدام، ومنصة قوية قابلة للبناء حسب تفضيلاتهم، ومختلف الأساسيات التي يحتاجونها ليُنشئوا بيئات تطبيقاتهم كما يريدون بمرونة وموثوقية عالية.

ولمزيد من المعلومات حول تقنية كوبرنتيس Kubernetes والاطلاع على أكثر الأسئلة شيوعًا حولها تتصحك بمطالعة الفيديو التالي:

بنية Kubernetes

سنتعرّف على بنية Kubernetes وطريقة تصميمها وتنظيمها لنفهم إمكاناته الكبيرة التي يوفرها للمطورين. يشبه Kubernetes نظامًا مكوّنًا من عدة طبقات، وتُجَرِّد كل طبقة منه التعقيدات الموجودة في الطبقات الأدنى منها.

سبيل المثال تتضمن كائنات Pod (التي تمثل أصغر وحدة في Kubernetes والتي سنشرحها بعد قليل) عدة حاويات، وتشير الخدمة (Service) إلى عدة كائنات Pod وتوفر نقطة وصول واحدة إليها وقِس على ذلك، فيخفف هذا التجريد على المطوّر كمية التفاصيل التي عليه التعامل معها، فنحن هنا نتعامل مع مفاهيم منطقية دون أن نربطها بآلة فيزيائية أو افتراضية معينة.

يضم Kubernetes في قاعدته عنقودًا cluster من الآلات الفيزيائية أو الافتراضية (VMs) يجمعها مع بعضها شبكة اتصال مشتركة، ويُعدّ هذا العنقود المنصة الفيزيائية التي تُضبَط فيها جميع مكونات Kubernetes، وإمكاناته، وأحمال العمل workloads، ويُقصد بأحمال العمل هنا تطبيقك الذي ستُشغله ضمن الحاوية سواء كان تطبيق ويب أو أي نوع آخر من التطبيقات.

تتمتع كل آلة ضمن العنقود بدورٍ خاص في نظام Kubernetes. ويعمل خادم واحد (أو مجموعة خوادم في عمليات النشر التي تتطلب توافرية عالية) دور الخادم الرئيسي master server، فيكون بمثابة بوابة العنقود أو عقله المُدبِّر، ويؤدي مهامًا مثل: إتاحة واجهة برمجة التطبيقات Kubernetes API للمستخدمين والعملاء، والتحقق من سلامة الخوادم الأخرى وتقسيم العمل عليها (بعملية تسمى "الجدولة scheduling")، بالإضافة إلى تنظيم الاتصال بين مكونات العنقود (أو ما يُعرف بتنسيق الحاويات container orchestration). إذًا فالخادم الرئيسي هو نقطة الاتصال الأساسية مع عنقود Kubernetes والمسؤول عن معظم أعماله المركزية.

تدعى الآلات الأخرى في العنقود عقدًا nodes: وهي مجموعة خوادم مسؤولة عن استقبال أحمال العمل workloads وتشغيلها باستخدام الموارد الحاسوبية المتوفرة لها المحلية والخارجية. وتُجَهَّز كل عقدة ببرنامج لتشغيل الحاويات مثل دوكر Docker أو روكيت rkt، إذ إن Kubernetes يُشغِّل التطبيقات والخدمات ضمن حاويات containers ليؤمن لها المستويات المرجوة من العزل والمرونة والإدارة الفعالة، وتتلقى العقدة تعليمات العمل الخاصة بها من الخادم الرئيسي، فتُنشئ بناءً عليها حاوياتٍ جديدة أو تُدمِّر حاوياتٍ أخرى، وتُعدِّل قواعد المرور عبر الشبكة لتُوجّه حركة البيانات حسب المطلوب.

تعمل التطبيقات والخدمات على العنقود وهي ضمن الحاويات (كما ذكرنا أعلاه)، وتتأكد المكونات الأساسية باستمرار من توافق الحالة المرغوبة للتطبيقات مع الحالة الفعلية للعنقود. أما المستخدمون فيتفاعلون مع العنقود عبر الاتصال مع خادم Kubernetes API الرئيسي مباشرةً أو بواسطة تطبيقات العملاء clients والمكتبات البرمجية.

والخطوة الأولى التي يبدأ بها تشغيل أي تطبيق أو خدمة هي إعداد خطة تصريحية declarative plan بصيغة JSON أو YAML تتضمن ما ينبغي إنشاؤه لتشغيل التطبيق، وكيف سيُدّار. ثم يُحلل الخادم الرئيسي هذه الخطة، ويحدد أنسب الطرق لتشغيلها على البنية التحتية المتوفرة له، وذلك عبر فحص المتطلبات اللازمة والحالة الحالية للنظام والموازنة بينهما. وتمثل مجموعة التطبيقات التي خصصها المستخدم لتعمل وفق خطة محددة الطبقة الأخيرة في نظام Kubernetes.

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

مكونات الخادم الرئيسي Master Server

يتحكم الخادم الرئيسي بعناقيد Kubernetes، ويؤمن نقطة اتصال رئيسية لمدراء الأنظمة administrators والمستخدمين، ويوفر العديد من الأنظمة لإدارة العقد العاملة worker nods الأقل منه تطورًا على نطاق العنقود.

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

تُثبَّت مكونات الخادم الرئيسي (التي سنذكرها تاليًا) على خادم واحد أو على عدة خوادم حسب الحالة.

المَخزَّن العام للإعدادات etcd

يُعدّ المَخزَّن العام للإعدادات واحدًا من أهم المكونات الضرورية لعمل عنقود Kubernetes، يوفره مشروع etcd الذي أنشأه فريق تطوير CoreOS (وهو نظام التشغيل الموجه للحاويات ويمكنك معرفة المزيد عنه بقراءة مقدّمة إلى مكونات نظام CoreOS). و etcd هو نظام لتخزين ملفات الإعدادت وإدارتها بشكل موزع، وهو عبارة عن مَخزَنَ قيم-مفاتيح موزّع على المستوى العام لنظام Kubernetes، ويتصف بأنه خفيف في استخدام الموارد، ويمكن تهيئته لتمرير الإعدادات بين عدة عقد.

إذ يُخزِّن Kubernetes بيانات الإعدادات التي يُسمح لكل عقدة بالوصول إليها في مَخزَّن etcd. وتستخدم مكونات Kubernetes هذه البيانات لاكتشاف الخدمة المطلوبة، وتهيئة نفسها للعمل حسب المعطيات الجديدة، وتساهم أيضًا في الحفاظ على حالة العنقود بواسطة ميزات، مثل: اختيار القائد leader election، والقفل الموزع distributed locking وغيرها. وتجري عملية تعيين القيم أو استردادها بواسطة واجهة برمجة تطبيقات HTTP/JSON API بسيطة تجعل العملية سلسة وواضحة.

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

خادم kube-apiserver API

خادم API من أهم الخدمات المحورية على الخادم الرئيسي لعنقود Kubernetes، ويُعدّ نقطة الإدارة الرئيسية للعنقود بأكمله فهو يسمح للمستخدم بإعداد أحمال العمل والوحدات التنظيمية، والتحقق من توافق تفاصيل الخدمة على الحاويات المنشورة مع البيانات الموجودة في مخزَّن etcd. يمكنك النظر إلى خادم API مثل جسر يصل المكونات ببعضها، ويعمل للحفاظ على سلامة العنقود، ولنقل المعلومات والأوامر عبره.

يطبق هذا الخادم واجهة برمجة تطبيقات من نوع RESTful API، وتضع شهرتها الواسعة العديد من المكتبات والأدوات في أيدي مستخدمي Kubernetes لتيسير عليهم التخاطب مع خادم API. يتوفر لخادم kube-apiserver عميلٌ افتراضي يدعى kubectl يتيح لك الاتصال مع عنقود Kubernetes من حاسبك المحلي.

مدير التحكم kube-controller-manager

مدير التحكم controller manager هو خدمة عامة تتولى عدة مسؤوليات ضمن العنقود، أولها إدارة المتحكمات المختلفة التي تنظم حالة العنقود، وإدارة دورات حياة حمل العمل workload، بالإضافة لبعض المهام الروتينية الأخرى. فعلى سبيل المثال: يفحص متحكم النظائر replication controller عدد النظائر المحددة لكائن pod معين (أي عدد تكراراته أو النسخ المماثلة له)، ويتأكد أن هذا العدد مطابقٌ للعدد الفعلي المنشور حاليًا على العنقود. تُكتب تفاصيل العمليات جميعها في etcd، ويراقب مدير التحكم التغييرات التي تطرأ على المعلومات ضمنه بواسطة خادم API.

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

المُجَدّوِل kube-scheduler

الجدولة هي ربط أحمال العمل بالعقد؛ فتحدد خدمة المُجَدّوِل ما ستُنفذه كل عقدة. تقرأ الخدمة متطلبات تشغيل كل حمل عمل، وتُحلل مواصفات بيئة البنية التحتية الحالية المتوفرة، وبناءً على ذلك تقرر أي عقد أو مجموعة عقد هي المقبولة لتنفيذ العمل.

يتتبع المُجَدّوِل الإمكانات المتاحة على كل مضيف، ليضمن أن أحمال العمل لم تُجَدول على العقد بطريقة خاطئة تتعارض مع الموارد المتاحة. وبالتالي يعرف المُجَدّوِل في كل لحظة الموارد الإجمالية المتوفرة والموارد المخصصة حاليًّا لأحمال العمل.

مدير التحكم السحابي cloud-controller-manager

نظام Kubernetes قابلٌ للنشر في بيئات متعددة، ويمكنه التعامل مع خدمات البنى التحتية لمزودين مختلفين، فيأخذ معلومات عن حالة الموارد الحاسوبية التي توفرها للعنقود ويديرها حسب متطلباته. ولكونه يتعامل مع تمثيلات عامة للموارد الحاسوبية مثل: موازنات الحمل Load Balancers والحجوم التخزينية وغيرها، فإنه يحتاج لربط map هذه التمثيلات بالموارد الفعلية التي يوفرها له مزودو الخدمات السحابية المتعددون.

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

مكونات خادم العقدة Node Server

العقد Nodes في Kubernetes هي الخوادم التي تعمل عليها حاويات التطبيق؛ تتطلب العقد بعض الضروريات لتؤدي أعمالها في التخاطب مع مكونات الخادم الرئيسي، وضبط إعدادات الاتصال الشبكي للحاويات، وتشغيل أحمال العمل التي يكلفها بها الخادم الرئيسي.

بيئة تشغيل الحاوية Container Runtime

بيئة تشغيل الحاوية Container Runtime من أهم مكونات العقدة، ودوكر Docker هو من أشهر بيئات التشغيل المعتمدة، لكنه ليس الوحيد، إذ يوجد بدائل له أخرى مثل rkt المطُور من قبل CoreOS وكان يُعتبر بديلاً أكثر أماناً وقابلية للتحكم مقارنة بدوكر و runc وهو مكون منخفض المستوى يستخدمه دوكر نفسه لتنفيذ الحاويات.

تتولى أدوات بيئة تشغيل الحاوية عمليات بدء تشغيل الحاويات وإدارتها، والحاويات Containers هي تطبيقات خفيفة مغلفة في بيئة تشغيل معزولة، وتُعدّ المكون الأساسي في وحدات عمل عنقود Kubernetes، فتشتمل كل وحدة عمل على حاوية واحدة ينبغي نشرها أو أكثر حسب متطلبات المشروع. وعندما ترد أحمال العمل إلى العنقود تعمل بيئة تشغيل الحاوية على تشغيل الحاويات المطلوبة لتنفيذ العمل.

نقطة اتصال العقدة kubelet

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

تتواصل kubelet مع مكونات الخادم الرئيسي لإتمام عملية المصادقة بين العقدة والعنقود، وللحصول على الأوامر وتفاصيل الأعمال المُسندة إليها، والتي تردها بصيغة بيان manifest أو خطة تحدد حمل العمل المطلوب ومعطيات parameters التشغيل. تحافظ kubelet على حالة العمل على العقدة، وتتحكم ببيئة تشغيل الحاوية لإنشاء الحاويات أو تدميرها حسب الحاجة.

الوكيل kube-proxy

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

كائنات Kubernetes وأحمال العمل

يستخدم Kubernetes طبقات تجريد abstraction إضافية فوق الحاويات -التي تُعدّ الآلية الرئيسية لنشر التطبيقات المغلفة containerized applications- توفر هذه التجريدات للمستخدمين ميزات المرونة والتوسع وإدارة دورة الحياة، فبدلًا من تعاملهم مع الحاويات مباشرةً يتفاعلون مع المثيلات instances التي تتألف من مجموعة مكونات أولية يوفرها نموذج عمل كائن Kubernetes، سنعرض في هذه الفقرة كائنات Kubernetes وكيفية استخدامها للتعامل مع أحمال الحمل.

الكائنات Pods

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

تمثل الحاويات الموجودة في Pod واحد تطبيقًا واحدًا أي أنها تعمل معًا بارتباطٍ وثيق، فتتشارك دورة الحياة، وتُجدّوَل أعمالها على عقدة واحدة، وتُدار بصفتها وحدة واحدة، وتتقاسم بيئة التشغيل والموارد مثل: المساحات التخزينية وعناوين IP. فِكِّر دائمًا بالكائن Pod على أنه تطبيق واحد متجانس بالرغم من تعدد حاوياته، لتفهم كيف يتعامل معه العنقود، ويُدّير موارده، ويُجدّول مهامه.

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

لا يُدّير المستخدمون عمومًا كائنات Pods بأنفسهم، فهي لا توفر لهم المميزات التي غالبًا ما يحتاجونها لإدارة تطبيقاتهم، مثل: الإدارة المتقدمة لدورة حياة التطبيق أو إدارة عمليات التوسعة Scaling، وبالمقابل تشجعهم بنية Kubernetes على استخدام كائنات بمستوى أعلى، تستخدم بدورها كائنات Pods أو قوالب Pods لتأدية الوظائف.

متحكمات النظائر ومجموعات النظائر

يعمل معظم من يستخدم Kubernetes مع نظائر متعددة للكائنات Pods مطابقة لها تمامًا، بدلًا من التعامل مع Pods مفردة. تُنشئ هذه النظائر انطلاقًا من قوالب Pod، وتوسعها أفقيًا متحكماتٌ خاصة تدعى متحكمات النظائر Replication Controllers ومجموعات النظائر Replication Sets.

متحكم النظائر replication controller هو أحد كائنات Kubernetes، مسؤول عن تحديد قالب Pod الذي ستُبنى النظائر انطلاقًا منه، وأيضًا عن تحديد معطيات التحكم التي تُمَكِّنهُ من إدارة التوسعة الأفقية لنظائر Pod فيزيد عدد النظائر قيد التشغيل أو ينقصها حسب الحاجة. تمثل هذه العملية طريقةً سهلة لموازنة الحمل وتحسين التوافرية availability داخل نظام Kubernetes، فالقالب الذي ستنشئ منه النظائر الجديدة، والذي يشبه إلى حدٍ كبير تعريف للكائن Pod، يكون مضمنًا embedded في إعدادات متحكم النظائر.

يتأكد متحكم النظائر باستمرار من تطابق عدد Pods المنشورة فعليًّا على العنقود مع العدد المطلوب والمحدد في إعدادته. وفي حال فشل أي Pod أو مضيف، سيستجيب المتحكم على الفور، ويبدأ بتشغيل Pods جديدة لتعويض النقص. أما إذا طرأ أي تغيير على عدد النظائر المحدد في إعداداته بالزيادة أو النقصان فسيُشغِّل المتحكم حاويات جديدة أو يدمر الحاويات الموجودة أصلًا ليصل للعدد المطلوب. يؤدي متحكم النظائر أيضًا مهمة التحديثات التدريجية rolling updates فيَنقُل مجموعة Pods إلى الإصدار الجديد بالتتابع واحدًا تلو الآخر حتى لا يسبب انقطاع كلي للخدمة فيؤثر على توافرية التطبيق.

مجموعات النظائر Replication sets  تتمتع بتصميم مشابه لتصميم متحكم النظائر، مع مرونة أكبر في آلية تعريف المتحكم لكائنات Pods التي سيُدِّيرها. يتسع نطاق الاعتماد على مجموعات النظائر على حساب متحكمات النظائر، بسبب إمكاناتها الكبيرة في اختيار النظائر، لكنها بالمقابل قاصرة عن إجراء التحديثات التدريجية للتطبيق وترقية واجهاته الخلفية إلى إصدار جديد كما تفعل متحكمات النظائر، فقد صممت مجموعات النظائر لتعمل في وحدات تنظيمية أخرى أعلى منها مستوى تؤدي هذه المهمة.

تمامًا مثل Pods، تُعدّ متحكمات النظائر ومجموعات النظائر وحداتٍ أولية في نظام Kubernetes وناردًا ما يتعامل معها المستخدم العادي، رغم أنها توفر لتطبيقاته التوسعة الأفقية والوثوقية في العمل، إلَا أنها تفتقر لمميزات إدارة دورات الحياة بطريقة سلسة يفضلها المستخدمون والموجودة في مكونات Kubernetes الأكثر تعقيدًا.

النشر Deployments

يُعدّ النشر Deployments واحدًا من أشهر أحمال العمل التي تُنشئ وتُدار مباشرةً على Kubernetes. تستخدم عمليات النشر مجموعات النظائر بوصفها كتلة بناء أو مكون أساسي تُبنى منه، وهذا ما يمنح مجموعات النظائر المرونة التي تفتقدها في إدارة دورة الحياة.

للوهلة الأولى قد تبدو لك عمليات النشر deployments المكونة من اجتماع عدد من مجموعات النظائر مشابهة في وظائفها لمتحكمات النظائر، إلّا أنها في الواقع تعالج العديد من نقاط ضعفها في إطلاق التحديثات. فعند استخدام المتحكمات ينبغي عليك إعداد خطة لمتحكم النظائر الجديد الذي سيحل محل المتحكم الحالي، وستكون أعمال كثيرة مثل: سجلات تتبع الأحداث، واستعادة التطبيق في حال طرأ عطل في الشبكة، والتراجع عن التحديث rolling back، عملياتٍ صعبة التنفيذ أو تلقى مسؤوليتها على المستخدم.

إذًا فالنشر Deployments هو كائن عالي المستوى، ومصمم لتسهيل إدارة دورة حياة نظائر Pods، وهو أكثر الكائنات التي ستعمل معها مباشرةً في Kubernetes، إذ يمكنك تعديله بسهولة حسب ما تريد فكل ما يتطلبه الأمر تعديل إعداداته، وبعدها سيضبط Kubernetes مجموعات النظائر replica sets بناءً على إعداداتك، ويدير الانتقالات بين إصدارات التطبيق مع تفعيل اختياري لميزات مثل: سجل تتبع الأحداث والتراجع الآلي عن التحديث وغيرها.

مجموعات الحالة Stateful sets

مجموعات الحالة Stateful sets هي pod تحكم متخصصة نوعًأ ما، تضمن ترتيب طلبات إنشاء Pods في مجموعة الحالة، وأن يمتلك كل Pod في هذه المجموعة معرفًا فريدًا خاصًا به. وتوفر للمستخدمين تحكمًا دقيقًا في المشاريع ذات المتطلبات الخاصة سواءً على صعيد النشر أو الاستقرار الشبكي أو وجود البيانات الدائمة Persistent data التي تبقى متاحة لوقت طويل دون تغيير. فغالبًا ما ترتبط مجموعات الحالة بالتطبيقات الموجهة للبيانات، مثل قواعد البيانات التي تتطلب وصولًا دائمًا لوحدات التخزين نفسها في جميع الظروف حتى إذا أُعِيدَت جدولتها على عقدة جديدة.

توفر مجموعات الحالة مُعرِّفًا شبكيًا ثابتًا لكل Pod، هو اسمٌ عددي فريد يشير إلى Pod بعينها دائمًا حتى إذا انتقلت إلى عقدة أخرى. والأمر نفسه مع وحدات التخزين الدائمة التي تنتقل مع Pod إن أُعِيدَت جدولتها لسبب ما. علماً أن وحدات التخزين الدائمة هذه تبقى موجودة ولا تحذف تلقائيًا مع حذف Pod لمنع الفقدان غير المقصود للبيانات.

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

مجموعات برامج التشغيل الخلفية Daemon Sets

مجموعات البرامج الخفية Daemon sets هي نموذج متخصص آخر من متحكمات pod التي تُشَغِّل نسخة من pod معين على كل عقدة (أو مجموعة عقد مترابطة) في العنقود. وتبرز فائدتها عند نشر Pods الخدمية لعقد Kubernetes مثل Pods الصيانة وغيرها.

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

المهام Jobs والمهام الدورية Cron Jobs

تتصف معظم أحمال العمل التي أوردناها في المقال بدورة حياة طويلة الأمد تشبه دورة حياة الخدمة، لكن Kubernetes يستخدم أيضًا نوعًا آخر من أحمال العمل يسمى المهام jobs لتأمين سير عمل أشبه بالمأمورية المؤقتة task-based تخرج فيه الحاوية من الخدمة بعد مضي بعض الوقت وانتهاء مهمتها. تساعدك كائنات المهام Jobs على تنفيذ العمليات التي لا تتطلب تشغيل خدمات دائمة، مثل: العمليات الدفعية batch أو العمليات التي تُجرى لمرة واحدة.

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

مكونات أخرى لنظام Kubernetes

يوفر Kubernetes عددًا من التجريدات إضافةً إلى أحمال العمل تساعدك على إدارة تطبيقاتك، والتحكم بالشبكات، وتأمين الاستمرارية وغير ذلك، سنناقش بعضًا منها أدناه:

خدمات Kubernetes

استخدمنا مصطلح "خدمة service" بالمعنى التقليدي كما في أنظمة يونيكس، أي للدلالة على العمليات طويلة الأمد، والتي غالبًا ما تتصل بالشبكة، وتستجيب للطلبات. إنما في Kubernetes تعمل الخدمة بصفتها موازن حمل أساسي داخلي ومرسال لوحدات pods. وتجمع الخدمة مجموعات منطقية من pods التي تؤدي الوظيفة نفسها، وتقدمها بوصفها كيان واحد.

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

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

خدمات Kubernetes متاحة افتراضيًا داخل العنقود بعنوان IP الخاص بها، وإذا أردت طلبها من الخارج فيمكنك تحقيق ذلك بعدة طرق، تتمثل إحداها بفتح منفذ ثابت static port خاص بالخدمة على واجهة الشبكة الخارجية لكل عقدة، ثم توجيه حركة المرور الواردة إليه تلقائيًا إلى عنوان IP الداخلي للخدمة، وبالتالي إلى pods المناسبة. تسمى هذه الطريقة NodePort.

أو يمكنك استخدام خدمة خاصة من نوع موازن حمل LoadBalancer تُنشئ لك موازن حمل خارجي يوجه حركة البيانات نحو الخدمة الداخلية المقصودة، تُنَفَذ هذه الطريقة باستخدام تكامل موازن الحمل الخاص بمزود Kubernetes السحابي، إذ ينشئ مدير التحكم السحابي الموارد اللازمة ويربطها بعناوين خدمة موازن الحمل التي تشير لخدمتنا الداخلية المقصودة.

وحدات التخزين ووحدات التخزين الدائمة

تُعدّ مشاركة البيانات بين أكثر من حاوية مشاركةً موثوقة، والحفاظ عليها وضمان توفرها بين عمليات إعادة تشغيل الحاويات، تحدّيًا كبيرًا في العديد من بيئات الحاويات. وتوفر بعض بيئات تشغيل الحاويات آليات خاصة ترتبط وحدات التخزين بالحاوية، وتحافظ عليها بعد انتهاء عمر الحاوية، لكن هذه الآليات تفتقد غالبًا للمرونة في التنفيذ العملي.

يستخدم Kubernetes تجريدًا خاصًا لمعالجة هذا التحدّي يدعى وحدات التخزين volumes، يسمح للحاويات المغلفة في pod واحد بمشاركة البيانات فيما بينها، والإبقاء عليها متاحة لحين انتهاء عمل pod، وحتى إذا فشلت حاوية معينة أو توقفت لسبب من الأسباب فالبيانات المشتركة ستبقى قابلة للوصول طالما أن pod موجود، وعند إنهاء عمله يُحذف المجلد المشترك. يُسهّل ذلك مشاركة الملفات بين عناصر pod الواحد دون الحاجة لأي آليات خارجية معقدة، لكنه لا يُعدّ حلًا مناسبًا للبيانات الدائمة التي لا تتعلق بعمر pod بل تستمر بعدها.

لذا يوفر Kubernetes تجريدًا أقوى لتخزين البيانات الدائمة، يسمى وحدات التخزين الدائمة Persistent volumes، لا يرتبط بدورة حياة pod، ويسمح لمديري النظام بإعداد موارد التخزين على مستوى العنقود ليتمكن المستخدمون من حجزها لكائنات pod التي يُشغِّلونها حسب تفضيلاتهم. ويحدد كل مستخدم سياسة الاسترداد الخاصة به، التي تقرر فيما إذا كانت وحدة التخزين وبياناتها ستُحذف يدويًا من قبله أم آليًّا عند انتهاء عمر pod. يخفف استخدام وحدات التخزين الدائمة من المخاطر المترتبطة بحالات فشل العقدة، ويساعدك على زيادة مساحات التخزين المخصصة لصالح مشروعك عمّا هو متاحٌ له محليًّا على المضيف.

التعليقات التوضيحية Annotations والتسميات التوضيحية Labels

التسميات التوضيحية label هي تجريد تنظيمي في Kubernetes ينظم المفاهيم الأخرى في النظام ويوضحها، وهي علاماتٌ دلالية ترفق بكائنات Kubernetes لوسمها بوسمٍ خاص يشير لانتمائها لمجموعة معينة، أي أنها تُستَخدم لتصنيف الكائنات ولاستهداف مثيلات مختلفة لأغراض الإدارة أو التوجيه أو غيرها، فمثلًا تعتمد الخدمات على التسميات التوضيحية لمعرفة pods الواجهة الخلفية التي ينبغي توجيه الطلبات إليها، وكذلك الأمر مع كائنات التحكم التي تستعمل التسميات التوضيحية لتحديد pods التي ستعمل عليها.

تُوضع التسميات التوضيحية بهيئة أزواج مفتاح-قيمة، ويمكن أن تحظى الوحدة التنظيمية عدة لصائق، لكنها لا تحمل أبدًا إلّا بقيمة واحدة لكل مفتاح. ومفتاح "الاسم name" هو أشهر المفاتيح، ويُعدّ مُعَرِّفًا عامًا متعدد الأغراض، يمكنك أيضًا تصنيف الكائنات وفق معايير أخرى حسب احتياجات عملك، مثل: مرحلة التطوير، وإمكانية الوصول العام، وإصدار التطبيق… إلخ.

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

الخلاصة

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

ترجمة -وبتصرف- للمقال ?What is Kubernetes لصاحبه Justin Ellingwood.

اقرأ أيضًا

• تعلم أساسيات Kubernetes
• نشر تطبيق جانغو آمن وقابل للتوسيع باستخدام كوبيرنتس Kubernetes
• مدخل إلى Kubernetes
• ما الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟

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

يتناول المقال المفاهيم الأساسية للاستضافة السحابية، ويشرح آلية عمل الحوسبة الافتراضية Virtualization مع عرضٍ لأهم مكوناتها، وأخيرًا مقارنة موجزة بين الاستضافة السحابية والاستضافات الأخرى.

ما هي السحابة؟

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

كيف تعمل الحوسبة الافتراضية؟

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

الخوادم الافتراضية Virtual Servers

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

تُنشر الخوادم الافتراضية وتُدار بواسطة برنامج خاص يسمى المراقب Hypervisor ويكون موجودًا على المضيف الفيزيائي، وبواسطته تُثبت نظم التشغيل على الخوادم الافتراضية. عمليًّا يعادل استخدام الخادم الافتراضي استخدام خادم مادي مخصص فلن تشعر بفرق بينهما، رغم أن الخادم الافتراضي يتشارك موارد مضيفه مع الخوادم الافتراضية الأخرى التي تقاسمه الاستضافة.

المضيفون Hosts

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

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

المراقبون Hypervisors

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

KVM، تختصر العبارة Kernel-Based Virtual Machine أو الأجهزة الافتراضية المعتمدة على نواة لينكس. تمامًا كما يوحي الاسم فهي بنية تحتية للحوسبة الافتراضية مدمجة في نواة نظام لينكس، وبمجرد تفعيلها يتحول الخادم المثبت عليه لينكس إلى Hypervisor، ويمكنه استضافة الخوادم الافتراضية مباشرةً بدون أي إضافات أخرى. تختلف KVM عن بقية برامج Hypervisor بأنها لا تحتاج إلى القيام بعملية إنشاء أو محاكاة لمكونات نواة خاصة بالاستضافة الافتراضية. يمكنك التعرف عليها عن قرب بمراجعة المقال أساسيّات الحوسبة الافتراضيّة Virtualization باستخدام KVM على Red Hat Enterprise Linux.

Xen، من أشهر برامج Hypervisor، يعتمد على نواته المصغرة الخاصة لتأمين الأدوات اللازمة لدعم الخوادم الافتراضية بدون الحاجة لإجراء أي تعديل على نواة المضيف كما في KVM، يدعم Xen طريقتين مختلفتين للحوسبة الافتراضية: تدعى الطريقة الأولى الحوسبة شبه الافتراضية Paravirtualization، ليست حوسبة افتراضية كاملة لأنها لا تجري محاكاةً للعتاد الصلب إنما فقط تعديلات على نظم تشغيل الخوادم الافتراضية لتتمكن من التخاطب معه بكفاءة، أما الطريقة الثانية تسمى الحوسبة الافتراضية بمساعدة العتاد الصلب أو HVM فإنها تستخدم ميزات خاصة موجودة في بعض أنواع العتاد الصلب لمحاكاة الخادم الافتراضي بدون أي تعديل على نظام التشغيل. لاقت HVM انتشارًا واسعًا حوالي العام 2006 وخصوصًا مع توفر المعالجات الاستهلاكية عالية الأداء التي سمحت لمعظم الحواسيب المكتبية والمحمولة بتحقيق الأداء نفسه عند تشغيلها أجهزة افتراضية أو حاويات معتمدة على النوى المصغرة مثل حاويات دوكر.

ESXi، موجه للمؤسسات، طورته شركة VMware. ميزته الأساسية أنه لا يتطلب وجود نظام تشغيل على المضيف لأن ESXi نفسه يؤدي دور نظام التشغيل، يسمى هذا النوع من المراقبين بالنمط الأول type one، ويعمل بكفاءة عالية بسبب عدم وجود أي برمجية وسيطة بين العتاد الصلب والخوادم الافتراضية.

Hyper-V، من أشهر تقنيات الحوسبة الافتراضية المستخدمة مع خوادم ويندوز، تجده بين خدمات النظام في ويندوز سيرفر ومعظم نسخ الويندوز الحديثة، يتوفر أيضًا بوصفه خادمًا مستقلًا يمكنك العمل معه مباشرةً بدون نظام تشغيل آخر. يمكنك قراءة المقال تطبيق Hyper-V في ويندوز 10 المتضمن خطوات إرشادية لتثبيت Hyper-V.

لماذا أختار الاستضافة السحابية؟

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

التخصيص

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

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

التوسعة

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

التوسع الأفقي، أو scaling out هو زيادة عدد العقد في النظام العنقودي، قد يعني ذلك زيادة عدد خوادم الويب لتحسين إدارة حركة مرور البيانات إلى تطبيقك، أو إضافة خوادم لمناطق معينة لتسريع الاستجابة، أو زيادة عدد العاملين workers في قاعدة البيانات لرفع سرعة نقل البيانات أو غير ذلك.

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

بالنتيجة يستطيع المطورون توسعة استضافاتهم السحابية، إما أفقيًا بزيادة عدد عقد VPS التي يستخدمونها، أو عموديًا ترقية مواصفات الخادم، أو القيام بالأمرين معًا حسب احتياجات عملهم.

الخلاصة

نأمل أنك أخذت فكرةً جيدة عن آلية عمل الاستضافة السحابية، والعلاقة بين الخوادم الافتراضية والمراقب Hypervisor المسؤول عن إدارتها، وتبينت خصائص الاستضافة السحابية التي تميزها عن غيرها من الاستضافات، لتتمكن من اختيار الاستضافة المناسبة لحالتك.

ترجمة -وبتصرف- للمقال An Introduction to Cloud Hosting لصاحبه Josh Barnett.

اقرأ أيضًا

• المقال السابق: نظرة عامة على الحوسبة السحابية
• مقدمة إلى الخوادم السحابية
• مفهوم السحابة Cloud
• كل ما تود معرفته عن السحابة الهجينة Hybrid Cloud
• تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة

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

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

ما هي الحوسبة السحابية؟

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

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

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

تعريف الحوسبة السحابية

نورد فيما يلي تعريف الحوسبة السحابية حسب المعهد الوطني للمعايير والتكنولوجيا (NIST)، وهو وكالة غير تنظيمية تتبع لوزارة التجارة الأمريكية وتشجع على الابتكار:

اقتباس

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

يحدد NIST خمس خصائص رئيسية للحوسبة السحابية:

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

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

• تجميع الموارد: موارد مزود الخدمة السحابة مشتركة بين عدة مشتركين، مع ضمان الاستقلالية والخصوصية وحجب بيانات كل مشترك عن الآخرين.

• المرونة السريعة: يمكن للمشترك زيادة موارد الحوسبة السحابية المحجوزة لصالحه أو تخفيضها أو تعديلها حسب احتياجات عمله بسرعة ومرونة، على عكس التجهيزات والبرامج الموجودة لديه محليًّا في منزله أو شركته.

• قياس الخدمة: توفر الحوسبة السحابية أدوات خاصة لقياس نسب استخدام الموارد السحابية، ويدفع المشتركون مقابل الموارد التي استخدموها فقط في كل دورة فوترة.

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

تاريخ الحوسبة السحابية

ترجع جذور الحوسبة السحابية إلى خمسينيات القرن العشرين، عندما كانت الشركات والجامعات تؤجر حواسيبها المركزية للمستخدمين لأوقات عمل محددة، فقد كانت الحواسيب حينها غالية الثمن وكبيرة الحجم لدرجة لا تسمح للأفراد العاديين باقتنائها، فاستئجار العمل عليها كان سبيلهم الوحيد لاستخدامها. لاحقًا مع بداية الستينيات، بدأ علماء الحاسوب أمثال جون مكارثي John McCarthy من جامعة ستانفورد، وجي سي آر ليكليدر J.C.R Licklider  من وكالة مشاريع الأبحاث المتقدمة التابعة لوزارة الدفاع الأمريكية (ARPA)، باقتراح أفكار مهدت للحوسبة السحابية كما نعرفها اليوم، مثل: تصور مفهوم الحوسبة بهيئة مرفق عام أو منفعة عامة يمكن للناس الوصول إليها بواسطة شبكة من الحواسيب المنتشرة حول العالم.

وبالرغم من هذه الأفكار المبكرة لم تصبح الحوسبة السحابية حقيقة ملموسة ومفهومًا واسع الانتشار حتى العقد الأول من القرن الحادي والعشرين، فقد شهدت هذه الفترة إطلاق أشهر الخدمات السحابية العالمية، مثل: Amazon’s Elastic Compute وخدمة التخزين البسيطة S3 في العام 2006، و Heroku في 2007، و Google Cloud Platform في 2008، ومنصة Alibaba Cloud في 2009، و Windows Azure في 2010 المعروفة حاليًّا بمنصة Microsoft Azure، وأخيرًا SmartCloud من شركة IBM و DigitalOcean في العام 2011. ساعدت هذه الخدمات أصحاب الأعمال على ضبط نفقاتهم المالية، عبر تهجير البنى التقنية من مقرات شركاتهم إلى المنصات السحابية، وأيضًا أفادت المطورين المستقلين وفرق التطوير الصغيرة، فوفرت لهم الموارد الحاسوبية اللازمة لتطوير تطبيقاتهم ونشرها.

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

تتنوع التطبيقات القائمة على السحابة، فبعضها يعود للشركات نفسها التي تمتلك المنصات السحابية، مثل: تطبيقات جوجل (أي جيميل وجوجل درايف ومستندات جوجل)، وتطبيق مايكروسوفت 365 النسخة السحابية من Microsoft Office Suite، وبعضها الآخر مملوك لشركات أخرى استثمرت خدمات مزودي الخدمات السحابية ووائمت تطبيقاتها الموجودة مسبقًا معها، مثل تطبيق Adobe Creative Cloud. وظهرت أيضًا موجة من التطبيقات السحابية الخالصة المعتمدة على SaaS، أبرزها: منصة Spotify في 2008، وخدمة استضافة الملفات Dropbox التي انطلقت في 2009، ومنصة زووم لاتصالات الفيديو في العام 2012، و Slack للتواصل الاجتماعي في 2013. أصبحت البنية التقنية القائمة على السحابة خيارًا مفضلًا لكثير من الشركات، وعلى ما يبدو أن انتشارها أخذٌ بالازدياد أكثر فأكثر.

نماذج الحوسبة السحابية

تُقَدَّم الخدمات السحابية للمشتركين بنماذج متعددة كلٌ حسب احتياجات عمله، ولكل نموذم مستوى معين من الدعم والمرونة.

البنية التحتية بصيغة خدمة IaaS

البنية التحتية بصيغة خدمة Infrastructure as a Service واختصارها Iaas، هي تقديم مكونات البنية التحتية للمشترك حسب الطلب، مثل: نظم التشغيل والشبكات ومساحات التخزين وغيرها، يمثل هذا النموذج المكافئ الافتراضي للخوادم المادية، لأنه يغني المشترك عن شرائها وصيانتها، ويقدم له المرونة في توسيع الموارد حسب حاجته والدفع لقائها. يناسب Iaas الشركات الراغبة باستثمار الحوسبة السحابية، ولديها مهندسين ومديري نظم أكفاء وقادرين على تثبيت نظم التشغيل، وأدوات التطوير، وكافة مكونات البنية التحتية الأخرى، مع إعدادها وإدارتها، ويستخدمه أيضًا المطورون والباحثون وغيرهم من الراغبين بتخصيص البنية التحتية للحوسبة السحابية كما يريدون. تدعم خدمات IaaS كامل احتياجات البنية التحتية بسبب مرونتها العالية، بدءًا من البنية التحتية لحوسبة الشركة، وصولًا إلى استضافة الويب، وتحليل البيانات الضخمة.

النظام الأساسي بصيغة خدمة PaaS

النظام الأساسي بصيغة خدمة Platform as a Service واختصارها Paas، يعمل مزود الخدمة هنا على تثبيت البنية التحتية الأساسية، مثل: نظام التشغيل، والبرامج الأساسية الأخرى، ويكون مسؤولًا عن إعدادها وصيانتها، وهو ما يؤمن للمستخدمين بيئةً معيارية مستقرة الأداء، ومختبرة جيدًا، تتيح لهم التركيز على تطوير تطبيقاتهم ونشرها، لذا فمطورو البرمجيات وفرق التطوير التعاونية هم أكثر من يستخدم خدمات PaaS فهي تخفف عنهم عبء إعداد البيئة الحاسوبية للتطوير، وصيانتها فيما بعد، بالإضافة لكونها تناسب طبيعة العمل الموزع، وتسهل التعاون بينهم. إذًا PaaS خيارٌ مثالي لكل مطور لا يحتاج بالضرورة إلى تخصيص البنية التحتية لبيئته الحاسوبية بنفسه، أو يفضل تركيز اهتمامه على تطوير التطبيق بدلًا من تنفيذ مهام DevOps وإدارة النظام.

البرمجيات بصيغة خدمة SaaS

البرمجيات بصيغة خدمة Software as a Service واختصارها SaaS، هي تطبيقات قائمة على السحابة cloud-based، يصلها المستخدمون عبر الإنترنت، ولا يحتاجون لتثبيتها على أجهزتهم ولا إلى صيانتها، والأمثلة كثيرة نحو: مستندات جوجل، و GitHub، و Slack، و Adobe Creative Cloud وغيرها. تحظى خدمات SaaS بشعبية كبيرة بين الشركات والمستخدمين عمومًا لعدة أسباب أبرزها: سهولة الاعتماد عليها، وتبنيها نهجًا جديدًا للعمل، وإمكانية الوصول إليها من أي جهاز، وتوفيرها إصدارات أو باقات متنوعة تناسب جميع الفئات، مثل: المجانية، والمميزة Premium، والخاصة بالمؤسسات Enterprise. تتشابه SaaS مع PaaS بأنها تعفي المشترك من المسؤوليات الخاصة بالبنية التحتية للتطبيق فلا يتاح له التفاعل مع الواجهة إلّا التي يستخدمها.

البيئات السحابية

تستند الخدمات السحابية إلى موارد حاسوبية عامة أو خاصة، ولكل منها أغراض محددة:

السحابة العامة

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

السحابة الخاصة

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

السحابة الهجينة والسحابة المتعددة

تستخدم العديد من المؤسسات بيئة سحابية هجينة Hybrid Cloud تجمع بين السحابة العامة والخاصة، وتحقق التوازن بين حاجتها للاعتماد على مزود سحابة عامة في بعض الجوانب، وضرورة التزامها باللوائح التي تنظم عملها. أما السحابة المتعددة Multicloud فيقصد بها اعتماد المؤسسة على أكثر من مزود سحابي عام لتأمين احتياجاتها، على سبيل المثال: الاشتراك بالخدمات السحابية لأمازون وديجتال أوشن بالوقت نفسه.

فوائد الحوسبة السحابية

تقدم الحوسبة السحابية فوائد جمّة للأفراد أصحاب الأعمال والمطورين والمؤسسات المختلفة، تختلف باختلاف أهدافهم وطبيعة نشاطاتهم.

للأعمال والقطاعات المختلفة

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

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

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

للمطورين المستقلين

جعلت الحوسبة السحابية الموارد -التي كانت سابقًا حكرًا على الشركات والمؤسسات الكبيرة- في متناول المطورين المستقلين حسب الطلب عبر الإنترنت، وبتكاليف بسيطة نسبةً إلى تكاليفها السابقة، فيمكنهم الآن إنجاز عمليات نشر البرمجيات واختبارها بسرعة ويُسر باستخدام التطبيقات السحابية، وبالإضافة إلى ذلك سهلت هذه التطبيقات مثل GitHub مشاركة الشيفرات البرمجية بين المطورين، والتعاون على مشاريع مفتوحة المصدر. كما أتاحت المنصات التعليمية السحابية دورات برمجة تفاعلية ووسّعت خيارات التَعلُّم أمام المطورين، ومكنتهم من تعلم البرمجة بمرونة في الوقت الذي يناسبهم.

ساهمت هذه الموارد الحاسوبية والتعليمية القائمة على السحابة بتخفيف العوائق التي تحول دون تعلُّم المطورين المهارات البرمجية التي يحتاجونها، ونشرهم التطبيقات عبر إلى السحابة. فبوجودها لم يعد تلقي التدريب الرسمي، ووجود الشركة الداعمة، ورأس المال الكبير شروطًا إلزامية ليخوض الأفراد تجربة إنشاء التطبيقات ونشرها، بل ولينافسوا اللاعبين الأساسيين في هذا المجال.

للباحثين

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

للمعلمين والطلاب

أمنت الحوسبة السحابية للطلاب أدواتٍ وفرصًا متعددة لاستكمال تحصيلهم العلمي، وتطبيق مهاراتهم التقنية عمليًّا في أثناء تعلمهم. فهناك العديد من المنصات السحابية التي تتيح مشاركة البيانات والشيفرات البرمجية، وتدريسها، والتعاون عليها، مثل: GitHub، و Jupyter Notebooks، وهو ما يساعد الطلاب على صقل مهاراتهم والتدّرب العملي عليها عبر الدراسة، والنشر، والمساهمة في المشاريع مفتوحة المصدر والمشاريع البحثية المتعلقة بمجال دراستهم أو طموحاتهم المهنية. ويستطيع الطلاب أيضًا، مثل المطورين المستقلين، الاستفادة من موارد الحوسبة السحابية، ونشر شيفراتهم البرمجية والتطبيقات التي عملوا عليها للعموم لتلقي الآراء، وفهم المتطلبات والاحتياجات الحقيقية للعملاء وسوق العمل.

كما تساعد الحوسبة السحابية الطلاب والباحثين والمعلمين على دعم البنية التحتية الأكاديمية الخاصة بالمؤسسات العلمية التي ينتمون إليها، وزيادة مستوى التحكم في بيئاتها الحاسوبية، فيحددون مثلًا الأدوات والتطبيقات التي يفضلون استخدامها، ويخصصون وظائفها المختلفة حسب شروطهم، أو يضعون قيودًا على عمليات جمع البيانات أو غير ذلك. وفي هذا الإطار ظهرت مجموعة من المنصات المخصصة للقطاع الأكاديمي، والتي حلت بالتدريج مكان العروض السحابية الموجهة للأكاديميين، على سبيل المثال لا الحصر: منصة voyant التي توفر وظائف التحليل النصي للمستندات بدون برمجة، و منصة The HathiTrust التي تتيح الوصول إلى مجموعة كبيرة من المجلدات العلمية الإلكترونية في مختلف المجالات، بالإضافة إلى منصات Reclaim Hosting، و Commons in a Box، و Humanities Commons، و Manifold المتضمنة مجموعة مهمة من الأدوات التعليمية، والشبكية، والأدوات المساعدة على نشر البحوث المصممة خصيصًا لدعم الأكاديميين.

للبنية التحتية المجتمعية

يفضل بعض الأفراد والمجتمعات في الشركات أو فرق العمل تثبيت برنامجهم السحابي وإدارته بأنفسهم، لعدة أسباب منها: تلبية احتياجات مجتمعهم وقيمه التي يلتزم بها، وتخصيص وظائف البرنامج بالكيفية التي يريدونها، وحماية بيانات المستخدمين، والتحكم أكثر ببيئتهم الحاسوبية. ويوجد العديد من البرمجيات مفتوحة المصدر التي تؤمن طلبهم، على الرغم من كونها تتطلب جهدًا أكبر في الإدارة والتحكم، إلّا أنها تُعدّ بدائل مقبولة لخدمات SaaS التجارية، ومنصات التواصل الاجتماعي التجارية التي تحدّ غالبًا إمكانات التحكم والخصوصية وإدارة البيئة الحاسوبية الممنوحة للمستخدمين، وتفضلها بعض المجتمعات على خدمات SaaS بسبب مخاوفهم من طريقة تعامل المنصات الشهيرة والشركات التجارية مع البيانات الشخصية للمستخدمين، نذكر لك بعضًا من هذه المنصات مفتوحة المصدر على سبيل المثال لا الحصر: أداة التواصل الاجتماعي Mastodon، وبرنامج مؤتمرات الفيديو Jitsi، ومحرر النصوص التعاوني Etherpad، وأداة الدردشة Rocket Chat.

المخاطر والتكاليف والأخلاقيات في الحوسبة السحابية

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

اعتبارات تهم جميع مستخدمي السحابة

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

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

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

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

• التقيُّد بمزود معين: مستخدمو الخدمات السحابية المملوكة أو مغلقة المصدر هم الفئة الأكثر عرضة لخطر التقيُّد بمزود خدمة معين، فيصعب أو يستحيل عليهم تغيره فيما بعد، فقد نظموا جميع عملياتهم الحاسوبية لتتلائم مع نظامه المغلق. يساعدك استخدام المنصات السحابية مفتوحة المصدر في تخفيف هذه المخاطر، فتُسهّل عليك المعايير المفتوحة التي تعتمدها ترحيل عملياتك من مزود خدمة سحابية إلى آخر. لكن في جميع الأحوال، تُعدّ عمليات ترحيل الأنظمة من أدق العمليات التقنية التي ينبغي لمستخدمي الحوسبة السحابية إدراك حساسيتها وحاجتها لقدر كبير من العمل والتخطيط والخبرة.

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

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

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

اعتبارات إضافية تهم الشركات والمؤسسات

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

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

الملخص

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

ترجمة -وبتصرف- للمقال A General Introduction to Cloud Computing لصاحبته Erin Glass.

اقرأ أيضًا

• المقال السابق: مقدمة إلى الخوادم السحابية
• مفهوم السحابة Cloud
• تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة
• كل ما تود معرفته عن السحابة الهجينة Hybrid Cloud

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

ستصادف في هذا المجال مصطلحات "خادم" و"خادم سحابي" و"خادم ويب" بالتبادل، ويشير الخادم السحابي عادةً إلى بيئة لينكس كاملة أو فعليًّا إلى حاسوب كامل. تعمل الخوادم السحابية بصفتها أجهزة افتراضية (VMs) أو برمجيات تحاكي الحواسيب التقليدية، وتجدها دائمًا ضمن مجموعات كبيرة أو عناقيد Clusters في تقنية تسمى الحوسبة الافتراضية Virtualization. يمكنك معرفة المزيد عن آلية عملها بمراجعة مقال [مقدمة إلى الاستضافة السحابية]().

البرمجيات المستخدمة على السحابة

التعرُّف عليها ضروري لفهم الخوادم السحابية، سنعرضها باختصار:

نظم التشغيل: تثبيت نظام التشغيل هو خطوتك الأولى في إعداد الخادم السحابي، يعتمد معظم مستخدمي السحابة نظام تشغيل لينكس بتوزيعاته المختلفة، مثل: أوبنتو Ubuntu أو روكي لينكس Rocky Linux لبناء خوادمهم، نظرًا لانتشاره الواسع في بيئات الخوادم، والدعم الكبير الذي يحظى به من المجتمع التقني، والذي يسهل عليك إيجاد مصادر للتعلُّم، بالإضافة لكونه مجاني في الأساس، وحتى إن احتجت لتراخيص فتراخيصه مرنة موازنةً بغيره. يمكنك الاطلاع على مقال [كيف تختار توزيعة لينكس المناسبة لك؟]() لتتعرف أكثر على توزيعات لينكس، وتختار ما يناسبك منها.

برمجيات جانب الخادم: يقصد بها مجموعة واسعة من البرمجيات والأدوات المستخدمة لإعداد الخوادم، وهي مصممة للعمل في البيئات السحابية، ومناسبة تمامًا لها، حيث لا شاشات عرض ولا بيئة سطح مكتب، فغالبًا ما تُثَبّت برمجيات جانب الخادم Server-Side وتُضبَط إعداداتها باستخدام واجهة سطر الأوامر، ويصل إليها المستخدم النهائي عبر المتصفح أو التطبيقات الأخرى. تتنوع هذه الأدوات وسيساعدك فهم أساسياتها على تجهيز خادمك السحابي.

خوادم الويب: تسمح خوادم الويب لخادمك السحابي بالتواصل مع المستخدمين عبر الإنترنت بواسطة بروتوكول HTTP، وهي من أدوات جانب الخادم، تُبَرمَج للاستجابة بطريقة محددة مع كل طلب يطلبه العميل عبر برمجيات جانب العميل Client-Side، لنفترض على سبيل المثال: أن المستخدم طلب URL معين من المتصفح (الذي يلعب هنا دور العميل)، سيستجيب له الخادم، ويجلب مستند HTML المناسب، ثم يرسله للمتصفح فيعرض صفحة الويب المطلوبة. ستحتاج خادم ويب حتمًا، إذا كنت تبني خادمك السحابي من الصفر، وتنوي تجهيزه لاستضافة موقع إلكتروني أو تطبيق ويب، وأشهر خوادم الويب المستخدمة هي Nginx و Apache. يمكنك الاطلاع على مدخل إلى خادم الويب لمزيد من المعلومات.

خوادم API: واجهات برمجة التطبيقات أو APIs هي برمجيات وسيطة تسمح للتطبيقات المختلفة بالتخاطب مع بعضها. خادم الويب نفسه هو خادم API يطبق HTTP API، ويوجد أنواع كثيرة غيره، مثل APIs الخاصة بمعلومات الطقس أو رحلات الطيران أو غيرها، يستخدمها الخادم السحابي لتبادل البيانات مع التطبيقات الخارجية ومصادر البيانات الخارجية، وقد يتصل الخادم بأكثر من واجهة API حسب طبيعة تطبيقك، وتدعى نقاط اتصال API بالتطبيق، أي النقاط التي تنفذ عمليات API، بنقاط الوصول أو endpoints، وتكون مثلًا عناوين URL تدل على الموارد المطلوب الاستعلام عنها.

خوادم قواعد البيانات: يمكنك تسميها بقواعد البيانات فقط، وهي نوع آخر من خوادم API، لكنها بخلاف خوادم الويب لا تعرض البيانات المطلوبة منها بهيئة صفحات HTML ضمن المتصفح، إنما يجري التواصل معها عبر واجهات برمجة تطبيقات خاصة تسمى واجهات استعلام قاعدة البيانات. بعض قواعد البيانات متاح للاستعلام الخارجي عبر الويب، وبعضها الآخر مخصص للاستخدام الداخلي من قبل برمجياتك السحابية فقط.

اقتباس

تنويه: يطلق اسم استضافة Bare-Metal أو الاستضافة العتادية التي تتعامل مباشرة مع العتاد الصلب، على الحالة التي تُبنى فيها الخوادم بتثبيت لينكس مباشرةً على الحاسوب المادي المخصص، بدون أي طبقة من الحوسبة الافتراضية Virtualization وبدون أي مشتركين آخرين، وبسبب تراجع أعداد مزودي الخدمات السحابية ممن يقدمون هذا النوع من الاستضافة لمشتركيهم، يلجأ بعض أصحاب المشاريع الصغيرة لبناء خوادمهم بإعداد بيئة لينكس على جهاز راسبيري باي، لمعرفة المزيد يفيدك مقال إعداد استضافة لمدونة شخصية باستخدام راسبيري باي Raspberry Pi، وسلسلة دليل راسبيري باي على أكاديمية حسوب.

الخوادم السحابية وبدائلها

الخادم السحابي هو حاسوب افتراضي كامل، لذا فجميع المنتجات السحابية الأخرى تتعلق به، ومزودو الخدمة السحابية يقدمون لك في عروضهم ميزة أو وظيفة محددة فقط من وظائف هذا الخادم، على سبيل المثال استضافة ويب مخصصة أو استضافة قاعدة بيانات مخصصة، وكل حل سحابي يوفر خادم ويب أو قاعدة بيانات ينبثق فعليًّا من خادم سحابي، غالبًا ما تبنى الخوادم السحابية باستخدام عناقيد من الخوادم المادية أو الفيزيائية التي تعمل معًا بتقنية الحوسبة الافتراضية. فالفرق الجوهري إذًا بين الخادم السحابي (الذي يسمى VPS أو الخادم الافتراضي الخاص Virtual Private Server) والعروض السحابية الأخرى هو أنك تستطيع تثبيت التطبيقات التي تريدها على الخادم السحابي، وتشغيلها بحرية حسب احتياجك، بينما تفرض عليك العروض الأخرى مجموعة ميزات ووظائف بعينها لا يسعك الخروج عنها.

أحدثت الحوسبة الافتراضية تغييرًا كبيرًا في سوق الخدمات السحابية خلال العقود الماضية، فقبل ظهورها كان مزود الخدمة يوفر خادمًا مثل Nginx أو Apache لتقديم الاستضافة لعشرات المواقع مع أذونات مخصصة لكل مشترك، ولم يكن المشترك مسؤولًا عن أي مهام إدارية على الخادم، لكن بالمقابل اقتصرت المواقع المستضافة وقتها على المواقع ذات الطبيعة الثابتة أي التي تتضمن عناصر HTML و CSS وجافا سكريبت ثابتة بدون محرك خلفي، وأيضًا مواقع drop-in PHP التي لا تمتلك أي اعتماديات سوى خادم الويب.

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

هل أستخدم خادمًا سحابيًا لمشروعي؟

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

إضافةً إلى الخوادم السحابية، يوفر بعض مزودي الخدمات السحابية عروضًا أخرى يمكن تشبيهها بمضيفي الويب، تلائم مواقع الويب ذات المكونات الثابتة المعتمدة على ميزات جافا سكريبت الحديثة، التي تخفف الحاجة إلى الخادم الخلفي Backend، يسمى هذا النوع من الاستضافة نظام إدارة محتوى بدون رأس Headless CMS، ويقدم المزود معه عادةً أدوات تأليف ونماذج ويب تعد جزءًا من عرض أوسع يسمى البرنامج بصيغة خدمة أو Software As A Service.

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

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

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

كيفية تحديد مواصفات الخادم

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

تُحَدَّد مواصفات الخوادم السحابية عادةً بعدد نوى المعالجات المركزية CPU المتوفرة لديها، وحجم ذاكرة الوصول العشوائي RAM المتاحة، وما يخصص لها من مساحات تخزينية على الأقراص الصلبة. ونظرًا لاختلاف مقاييس سرعة الأقراص والمعالجات في الخوادم السحابية عنها في ظروف التشغيل في العالم الحقيقي، فقد اعتمد معظم مزودي الخدمات السحابية مواصفاتٍ موحدة لها، فمتوسط سرعة الأقراص يعادل تقريبًا سرعة أقراص SSD، وسرعة وحدة المعالجة المركزية تماثل سرعة نواة Intel Xeon. وبالإضافة إلى المواصفات السابقة يفرض بعض المزودين قيودًا على الخوادم السحابية في الطبقة الدنيا، مثل: تحديد عدد عمليات الإدخال والإخراج المسموحة على القرص (IOPS)، وإجمالي حركة المرور المتبادلة مع الخودام عبر الشبكة وغير ذلك، قد تسبب هذه القيود اختناقات لبعض البرامج المستضافة.

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

يُعطى لكل خادم سحابي عنوان IP عام مخصص له، للاتصال به عبر شبكة الإنترنت، وقد يكون العنوان من الإصدار الرابع IP4 وفق الصيغة 123.123.123.123 أو من الإصدار السادس IP6 من نمط 2001:0db8:0000:0000:0000:ff00:0042:8329، والحالة المعتادة أن يقابل عنوان IP اسم دومين مثل: https://my_domain.com. تتضمن بعض عروض الاستضافة السحابية تزويدك بعنوان IP لكل خادم VPS تحجزه، بينما يطلب منك بعض المزودين شراء عناوين IP بنفسك وتسجيلها للخوادم، تسمى هذه العناوين بعناوين IP المحجوزة Reserved IPs، وهي مناسبة لعمليات النشر واسعة النطاق.

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

الوصول للخادم السحابي

يتطلب الوصول إلى الخوادم السحابية إتقانك العمل في بيئة سطر الأوامر أو الطرفية Terminal محليًا أو عن بعد، وأكثر البروتوكولات استخدامًا في هذا المجال بروتوكول SSH الذي يستخدم البوابة 22 ويعتمد عليه مسؤولو الخادم، وبروتوكول HTTP على البوابة 80 و HTTPS على البوابة 443 المخصصين أكثر للمستخدم النهائي، تتمحور إدارة النظام السحابي حول هذه الخوادم والخدمات والبروتوكولات.

الخاتمة

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

ترجمة -وبتصرف- للمقال Cloud Servers: An Introduction لصاحبه Alex Garnett.

اقرأ أيضًا

• مفهوم السحابة Cloud
• تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة
• الحوسبة الافتراضية virtualization وأوجه اختلافها عن الحاويات containers
• كل ما تود معرفته عن السحابة الهجينة Hybrid Cloud

سنستكشف سويةً بتبسيط شديد ما هي تقنية كوبرنتيس Kubernetes أو K8s، وكيف تستعمل لأتمتة عملية نشر Deploy الحاويات containers على خوادم لينكس موزعة.

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

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

يُعد Helm مدير حزم ضمن كوبيرنتس Kubernetes، وهو يسمح للمطورين و المشغلين إعداد وتطوير التطبيقات ضمن عناقيد Kubernetes.

يُطلق على حزم Helm اسم المخططات Charts، وهي تتضمن قوالبًا لتعريف الموارد التي تضبط وتركب التطبيقات بأقل جهد ممكن. يستطيع المستخدم باستخدام القولبة templating إدارة المخططات وضبطها والتحكم بسلوكها بتمرير تعريفات متنوعة دون تعديل المخططات الأساسية. ويدير Helm تعريفات الموارد المخصصة إضافةً الى التعديلات على التعريفات المستخدمة مسبقًا. تسمى المخططات المنفذة مع المُخصصة من قبل المستخدم باسم الإصدار Release.

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

المتطلبات الأساسية

• عنقود Kubernetes يدعم التحكم بالوصول على أساس الدور role-based access control -أو اختصارًا RBAC- كما هو متاح في المخزن الرسمي.
• أداة موجه الأوامر"kubectl" ضمن الحاسب المحلي قادرة على الاتصال بالعنقود، والتي تُعد وفقًا للتوثيق الرسمي.

نتحقق من الاتصال بالعنقود بتنفيذ الأمر التالي:

$ kubectl cluster-info

يكون الاتصال بالعنقود ناجحًا ما لم تظهر أخطاء نتيجةً للأمر السابق، أما في حالة وجود عدة عناقيد، نحدد سياق context العنقود المطلوب عبر تنفيذ الأمر التالي:

$ kubectl config get-contexts

يظهر الخرج لائحةً بالإعدادات المتوفر ة كما يلي:

CURRENT   NAME                    CLUSTER                 AUTHINFO                      NAMESPACE
*         do-fra1-helm3-example   do-fra1-helm3-example   do-fra1-helm3-example-admin

تشير النجمة * إلى أن الاتصال الحالي خاص بالعنقود do-fra1-helm3-example؛ وللتبديل إلى عنقود آخر ننفذ الأمر التالي:

$ kubectl config use-context context-name

ننتقل إلى الخطوة التالية بعد التأكد من اختيار العنقود الذي نرغب باستخدامه لتثبيت مدير الحزم Helm عليه.

الخطوة 1- تثبيت مدير الحزم Helm 3

نعتمد طريقة تثبيت مدير الحزم Helm 3 باستخدام السكربت script المُتاح على الموقع الرسمي. نبدأ بالتنقل إلى المجلد "tmp/"حيث نخزّن البرنامج النصي الخاص بالتثبيت. نحقق التنقل بتنفيذ الأمر:

$ cd /tmp

نحمّل السكربت بتنفيذ الأمر التالي:

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3

يُعد التحقق من محتوى السكربت قبل تثبيته من الممارسات الجيدة المتعلّقة بالأمان، ونستخدم محرر النصوص المفضل من أجل ذلك، إذ نستعرض محتوى الملف "get_helm.sh" قبل تثبيته. نضيف قابلية التنفيذ إلى السكربت بعد التأكد من سلامته بتنفيذ الأمر التالي:

$ chmod u+x get_helm.sh

ننفذ السكربت لتبدأ عندها عملية تثبيت مدير الحزم Helm 3 عبر تنفيذ الأمر:

$ ./get_helm.sh

يظهر خرجٌ مشابهٌ لما يلي:

Downloading https://get.helm.sh/helm-v3.5.2-linux-amd64.tar.gz
Verifying checksum... Done.
Preparing to install helm into /usr/local/bin
helm installed into /usr/local/bin/helm

وبهذا ينتهي تثبيت مدير الحزم Helm 3 على الجهاز المحلي.

الخطوة 2- إعداد مخازن المخططات

تُخزّن مخططات مدير الحزم Helm ضمن مخازن مخططات قابلة للاستضافة من أي مستخدم وضمن أي جهاز. لا يترافق مدير الحزم Helm 3 عادةً مع أي مخزن مُعد مسبقًا. وعلى الرغم من أن النسخ السابقة من مدير الحزم Helm تضمنت مخزن مخططات مركزي منسق، إلا أنّ تصميم مدير الحزم Helm 3 يحُث المطورين على إدارة مخازنهم الخاصة، إذ يسمح ذلك بحرية أكبر وكذلك الحصول على إصدارات بصورةٍ أسرع، ومعنى ذلك أننا نحتاج إضافة مخزن مستضيف لكل مخطط نستخدمه ضمن مدير الحزم Helm. نستخدم الموقع ArtifactHub.io لإيجاد المخزن المناسب، وهو موقع مفتوح المصدر مُدار من قبل CNCF التي تدير مخططات مدير الحزم Helm ومخازنها، كما تتعقب أكثر المخططات شعبيةً وفائدةً والتي تستخدمها مشاريع CNCF الأخرى. ولذلك تختلف عن المخازن المستقرة "stable" التي استخدمتها الإصدارات السابقة من مدير الحزم Helm. يتضمن الموقع كثيرًا من المخططات المهمة للمشاريع الشائعة، مثل مشاريع Nginx، ومشاريع أدوات المراقبة.

نبحث عن المخططات الواجب تثبيتها عبر الصفحة الرئيسية، إذ نبدأ بالبحث عن "nginx" مثلًا لتظهر المخططات المتعلّقة به.

نثبت النسخة المجانية Community edition المدارة من قبل فريق Kubernetes، كما نبحث عن "ingress-nginx" ونختاره من بين النتائج كما في الشكل التالي:

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

ننقر على الزر الازرق الموجود إلى جانب الأمر لنسخه، ونبدأ بنسخ وتنفيذ الأمر الأول:

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

ننفذ الأمر helm repo add لاضافة المخزن إلى مدير الحزم Helm، إذ يتطلب هذا الأمر تمرير متغيرين، هما: اسم المخزن ورابطه، ويظهر خرجٌ مشابهٌ لما يلي:

"ingress-nginx" has been added to your repositories

ننفذ الأمر التالي لإعلام مدير الحزم Helm بوجود مخزن جديد يجب عليه التعرّف على محتواه:

$ helm repo update

يظهر الخرج التالي ليشير إلى نجاح التحديث:

Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "ingress-nginx" chart repository
Update Complete. ⎈Happy Helming!⎈

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

الخطوة 3- تثبيت مخطط Helm

يملك كل مخطط متغيرات خاصة بالإعداد تحدد سلوكه، إذ تُخزَّن هذه المتغيرات ضمن الملف "values.yaml" الموجود ضمن المخطط، ونستطيع التعرّف على هذه المتغيرات بتنفيذ الأمر التالي مع ضرورة استبدال chart_name باسم المخطط الذي نريد معرفة متغيراته كما يلي:

$ helm show values chart_name

نتعرّف على المتغيرات الخاصة بمخطط "ingress-nginx" بتنفيذ الأمر التالي:

$ helm show values ingress-nginx/ingress-nginx

يظهر خرج طويل جدًا يمثل محتويات "values.yaml" الخاص بمخطط "ingress-nginx".

نثبت المخطط باستخدام الأمرhelm install على النحو التالي:

$ helm install release_name repository/chart_name

عرّفنا الإصدار بأنه عينة من المخطط والتي ندعوها بالأمر السابق باسم "ingress-nginx". يثبّت الأمر السابق المخطط ضمن العنقود اعتمادًا على القيم الافتراضية للمتغيرات والتي تُعدّل عند الحاجة باستخدام set-- يتلوها اسم المتغير والقيمة الجديدة كما يلي:

$ helm install ingress-nginx/ingress-nginx --set variable_name=variable_value

يمكننا تكرار الإضافة set-- لجميع المتغيرات التي تحتاج للتعديل، وطالما أننا لن نخصّص المخطط الآن سنستخدم القيم الافتراضية في عملية التثبيت ونتابع بتنفيذ الأمر التالي:

$ helm install ingress-nginx ingress-nginx/ingress-nginx

يظهر الخرج التالي بعد نجاح العملية:

NAME: ingress-nginx
LAST DEPLOYED: Wed Feb 24 10:12:37 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status by running 'kubectl --namespace default get services -o wide -w ingress-nginx-controller'
…

يجب الانتباه إلى أن المتغير NAME يقابل اسم الإصدار الذي حددناه سابقًا. يُدرج مدير الحزم Helm المعلومات العامة، مثل حالة الإصدار ونطاق الاسم namespace التي نُشرت ضمنه. يختلف قسم الملاحظات NOTES بين المخططات وغالبًا ما يحتوي دليلًا مختصرًا أو تحذيرات من بعض المشاكل الشائعة عند استخدام موارد المخطط. يتضمن جزء الملاحظات تحذيرًا بأن إعداد موازن الحمل Load Balancer قيد الإنشاء وأن هذه العملية تستغرق وقتًا كي تنتهي. نتحقق من المخططات باستخدام الأمر التالي:

$ helm list

نجد أن المخطط "ingress-nginx" هو المخطط الوحيد المُتاح في الوقت الحالي:

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
ingress-nginx   default         1               2021-02-24 10:12:37.281049711 +0000 UTC deployed        ingress-nginx-3.23.0    0.44.0

ونجد الخدمات الخاصة بهذا المخطط ضمن العنقود عن طريق تنفيذ الأمر التالي:

$ kubectl get services

ليظهر خرجٌ مُشابهٌ لما يلي:

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.245.211.81   46.101.68.67   80:30704/TCP,443:30700/TCP   7m19s
ingress-nginx-controller-admission   ClusterIP      10.245.50.17    <none>         443/TCP                      7m19s
kubernetes                           ClusterIP      10.245.0.1      <none>         443/TCP                      83m

الآن، بعد أن نشرنا إصدارًا في العنقود، سنعدل ضبطه أثناء عملية النشر.

الخطوة 4 - ترقية الإصدار

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

يعرض المخطط "ingress-nginx" متغيرًا اسمه controller.replicaCount يتحكم بعدد حجيرات التحكم controller pods المنشورة، ويمكن التأكد من عددها باستخدام الأمر التالي وعادةً ما تكون القيمة الافتراضية لهذا المتغير تساوي الواحد:

$ kubectl get pods

يظهر الخرج بوجود حجيرة واحدة فقط على النحو التالي:

NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx-controller-7fc74cf778-kjtst   1/1     Running   0          12m

نستطيع إضافة مزيدٍ من الحجيرات من أجل التكرارية Redundancy (ثلاثة على سبيل المثال) عبر ترقية الإصدار وتعديل قيمة المتغير الى 4 من خلال الأمر التالي:

$ helm upgrade ingress-nginx ingress-nginx/ingress-nginx --set controller.replicaCount=3 --reuse-values

يمكن استخدام values -reuse--، الذي يوجّه مدير الحزم Helm ببناء التعديلات على أساس الإصدار المنشور مع الحفاظ على الإصدار السابق.

نلاحظ في الخرج أنّ مدير الحزم Helm يزيد من رقم الاشعار لهذه المراجعة للإشارة إلى ترقية الإصدار:

NAME: ingress-nginx
LAST DEPLOYED: Wed Feb 24 12:07:54 2021
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
…

يمكن الحصول على قائمة بالحجيرات المتاحة بتنفيذ الأمر التالي:

$ kubectl get pods

نلاحظ وجود ثلاث حجيرات عوضًا عن حجيرة واحدة:

NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx-controller-7fc74cf778-4hk9g   1/1     Running   0          18s
ingress-nginx-controller-7fc74cf778-kjtst   1/1     Running   0          22m
ingress-nginx-controller-7fc74cf778-wz595   1/1     Running   0          18s

سنتراجع في الخطوة التالية عن التغييرات ونحذف الإصدارات تمامًا.

الخطوة 5 - التراجع و حذف الإصدار

يخزّن مدير الحزم Helm رقم المراجعة لكل إصدار داخليًا، بحيث يزداد هذا الرقم عند ترقية الإصدار، ويسمح ذلك بالعودة الى المراجعة السابقة عند الحاجة. نستطيع إعادة عدد الحجيرات إلى واحد وهي القيمة الافتراضية التي عدلناها في الخطوة السابقة، ننفذ الأمر helm upgrade مرةً أخرى ونحدد العدد يدويًا لأنه تغيير بسيط. تصبح هذه العلمية في حالة المخططات الكبيرة التي تمتلك عددًا كبيرًا من المتغيرات دون جدوى ويجب أتمتة عملية تعديل هذه المتغيرات. نتراجع عن الإصدار بتنفيذ الأمر helm rollback:

$ helm rollback release_name release_revision

ويمكننا التراجع مثلًا عن التعديلات السابقة الخاصة بالمخطط "ingress-nginx" بالعودة الى المراجعة رقم 1 من خلال تنفيذ الأمر التالي:

$ helm rollback ingress-nginx 1

يظهر الخرج التالي الذي يشير إلى نجاح العملية:

Rollback was a success! Happy Helming!

نتحقق من رقم المراجعة الحالية عن طريق طلب قائمة الإصدارات بتنفيذ الأمر التالي:

$ helm list

نجد أن المراجعة أصبحت 3 بدلًا من 1:

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
ingress-nginx   default         3               2021-02-24 12:43:21.523664768 +0000 UTC deployed        ingress-nginx-3.23.0    0.44.0

ينظر مدير الحزم Helm لأي تغيير ومن ضمنها التراجع على أنه مراجعة جديدة للإصدار. نتحقق من أن المراجعة رقم 3 مماثلةٌ للأولى عن طريق التحقق من عدد الحجيرات المنشورة بتنفيذ الأمر التالي:

$ kubectl get pods

نلاحظ وجود حجيرةٍ واحدةٍ فقط في الخرج:

NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx-controller-7fc74cf778-kjtst   1/1     Running   0          41m

نستطيع حذف إصدار ما وكل المراجعات المتعلقة به بتنفيذ الأمر helm delete:

$ helm delete release_name

لم نعد بحاجة لمخطط "ingress-nginx"، لذالك نحذفه بتنفيذ الأمر التالي:

$ helm delete ingress-nginx

يظهر خرجٌ مشابهٌ لما يلي:

release "ingress-nginx" uninstalled

نتحقق من قائمة الإصدارات والتي يجب أن تكون فارغة بعد نجاح تنفيذ العملية بتنفيذ الأمر:

$ helm list

يظهر الخرج التالي ليشير إلى نجاح العملية:

NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

نستطيع إعادة استخدام اسم الإصدار في المستقبل لأنه أصبح متاحًا.

الخطوة 6- إنشاء مخططات مخصصة -خطوة اختيارية

نعمل على إنشاء مخطط مخصص يتضمن تعريف الموارد وكيفية تحزيم هذه المخططات من أجل إعادة استخدامها لاحقًا. ننشئ مخططًا جديدًا يُدعى "example-chart" بتنفيذ الأمر التالي:

$ helm create example-chart

ينشئ ذلك مجلّدًا جديدًا يدعى "example-chart" يحتوي المجلدات ضمن البنية التالية:

charts/
templates/
├─ tests/
│  ├─ test-connection.yaml
├─ deployment.yaml
├─ hpa.yaml
├─ ingress.yaml
├─ NOTES.txt
├─ service.yaml
├─ serviceaccount.yaml
├─ _helpers.tpl
Chart.yaml
values.yaml

توجد تعريفات الموارد التي ثبتّها المخطط على العنقود الهدف في المجلد "templates"، إذ ينشئ مدير الحزم Helm مجموعة من التعريفات الافتراضية مثل نقطة بداية لتنشر متحكم "Nginx ingress". نستخدم هنا صيغة قولبة Go على الرغم من أنّ لاحقة الملف هي "YAML"، لتبقى قابلة للتخصيص عبر المتغيرات التي يمكن تمريرها عند تنفيذ الأمر. نتحقق من ذلك بإظهار محتوى الملف "service.yaml" بتنفيذ الأمر التالي:

$ cat example-chart/templates/service.yaml

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

apiVersion: v1
kind: Service
metadata:
  name: {{ include "mychart.fullname" . }}
  labels:
    {{- include "mychart.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    {{- include "mychart.selectorLabels" . | nindent 4 }}

تُعرض المتغيرات المرجعية للمستخدم وتُعرّف ضمن الملف "values.yaml"؛ وتُخزن نصوص "NOTES" التي يظهرها مدير الحزم Helm ضمن الملف "NOTES.txt" ويجري قولبتها؛ كما تُعرّف بيانات التعريف للمخطط، مثل الاسم و النسخة ونسخة البرمجيات المنشورة ضمن الملف "Chart.yaml"، الذي يتضمن المحتوى التالي:

 apiVersion: v2 name: mychart description: A Helm chart for Kubernetes … type: application … version: 0.1.0 … appVersion: "1.16.0"

نتحقق مما سينشره Helm بتمرير dry-run-- و debug-- للأمر helm install مع الإشارة إلى المجلّد الذي يحتوي المخطط:

$ helm install example-chart --dry-run --debug ./example-chart

يظهر خرج طويل يتضمن جميع تعريفات الموارد التي تطبق على العنقود أثناء العمل على المخطط، كما يمكن استخدام upgrade helm لدفع النسخة الجديدة الى Kubernetes.

$ helm package ./example-chart

يظهر خرجٌ مشابهٌ لما يلي:

Successfully packaged chart and saved it to: …/example-chart-0.1.0.tgz

نستطيع تثبيت المخطط المحزّم كما نثبّت أي مخطط من المخازن المضافة إلى مدير الحزم Helm:

$ helm install example-chart example-chart-0.1.0.tgz

الخاتمة

قدم هذا المقال طريقة استخدام مدير الحزم Helm لتثبيت وترقية البرمجيات المنشورة إلى عنقود Kubernetes، كما أضفنا مخازن المخططات واستخدمنا موقع ArtifactHub للمساعدة في إيجادها، وأنشأنا مخططا مخصصًا جديدًا وتحكمنا بمراجعات الإصدار وبيّنا طريقة التراجع عن الإصدار إذا اقتضى الأمر.

ترجمة وبتصرف للمقال How To Install Software on Kubernetes Clusters with the Helm 3 Package Manager لمؤلفيه Savic و Brian Boucheron.

اقرأ أيضًا

• مدخل إلى Helm: مدير حزم Kubernetes
• ما الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟
• تعلم أساسيات Kubernetes
• نظام كوبيرنتس Kubernetes وكيفية عمله

يشير الناس عادةً لأي مجموعةٍ من مفاهيم الحوسبة المترابطة بمصطلح السحابة cloud، ولكن في الواقع السحابة هي مجموعةٌ من الأقراص والمعالجات والذواكر وغيرها من موارد عمليات المعالجة computing resources -سواءٌ كانت فيزيائية أو افتراضية- المستضافة عن بُعد remotely hosted والمُستخدمة في طرف العميل، سواء أكان هذا العميل صفحة ويب أو تطبيق للهاتف أو تطبيق سطح مكتب تقليدي، بهدف استثمار المساحات التخزينية وإمكانات الحوسبة العالية؛ ويُقصد بمصطلح الاستضافة عن بُعد remotely hosting طريقة توصيل التطبيقات وقواعد البيانات والملفات للمستخدمين من الخوادم البعيدة الموجودة خارج مراكز البيانات، إذ يمكن للمستخدم الوصول إلى التطبيق وبياناته من خلال تسجيل الدخول بأمان إلى الخادم البعيد عبر السحابة وذلك خلال متصفح الإنترنت عادةً)،

وليس من السهل التفريق تمامًا بين مفهوم الحوسبة السحابية والحوسبة التقليدية القائمة على نموذج خادم/عميل؛ ولكن تتميز الحوسبة السحابية عمومًا بالقدرة على التوسُّع، أي زيادة الموارد تلقائيًا حسب الحاجة أثناء التشغيل؛ كما تتميز بآلية التصميم أيضًا، إذ تكون مصادر الحوسبة في السحابة أكثر مرونةً ومتعددة الأغراض وقابلةً للاستخدام لأي وظيفة مطلوبة على نحوٍ أكبر موارنةً بحوسبة الخوادم التقليدية.

بعض الأمثلة على مفهوم السحابة

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

يجب ألا ننسى أن واجهة المستخدم في موقع الويب ما هي إلا جزءٌ بسيطٌ من مجموعةٍ كبيرةٍ من العمليات الجارية في كواليس أيّ تطبيق ويب، إذ تعمل مكوناتٌ عديدة من قواعد بيانات وأدوات تسجيل الأحداث وصولًا إلى آليات التنقيب عن البيانات وأدوات الذكاء الاصطناعي وعدد من البرمجيات الموزعة الخاصة بتنفيذ المتطلبات أو الآلاف منها معًا لتشغّل خدمة ويب وتمكنَّك من استخدام أي أداة على الانترنت. وقد تتواجد المكونات المذكورة أعلاه على أي حاسوب في أي مكان، ولكن تتواجد غالبًا على السحابة.

كيفية عمل السحابة

صُممت مراكز البيانات لكي تحوي العديد من خوادم الأغراض العامة مع ما يلزم من إمكانات الحوسبة والتخزين، لمشاركة هذه الموارد بين التطبيقات المتعددة المُستضافة في هذه المراكز لتوفير البيانات الخاصة بها. وتُجمَّع في كثير من الحالات كافّة التطبيقات والمكتبات اللازمة لتشغيلها مع نظام التشغيل على أجهزة افتراضية virtual machines تعمل ضمن الجهاز الفيزيائي الفعلي بغض النظر عن نوع نظام تشغيله، وتدعى هذه التقنية باسم التقنية الافتراضية virtualization؛ وهي تجعل التطبيقات أكثر قابليةً للتنقل والعمل في بيئات مختلفة، شرط أن تكون قادرةً على تشغيل جهاز افتراضي ضمنها.

من هنا أتى مفهوم الحوسبة المرنة elastic computing أو السحابة المرنة elastic cloud؛ فعندما يُصمّم تطبيق ليتوسع أو يتقلص حسب حجم الطلبات عليه فمن الممكن استخدام عدد أكبر أو أقل من الأجهزة الافتراضية بمرونة حسب الحالة؛ كما تعمل الأجهزة الافتراضية بمرونة أيضًا من ناحية التخزين، فمن الممكن استخدام محركات الأقراص الثابتة المتصلة بالعديد من الأجهزة الفيزيائية المختلفة والتعامل معها كما لو كانت موردًا واحدًا، مما يقلل من هدر الموارد ويسهّل عملية تطوير التطبيقات التي تتطلب كميات بيانات كبيرة جدًا.

قد تكون مراكز البيانات التي تستضيف موارد الحوسبة السحابية عامّةً أو خاصّةً أو هجينة hybrid cloud؛ فمن الممكن استئجار موارد الحوسبة السحابية العامة من قبل مجموعة متنوعة من الشركات؛ وقد تقرر المؤسسة إنشاء سحابة خاصة مستضافة في مركز البيانات الخاص بها أو في جزء محجوز خصيصًا لها من مركز بيانات آخر من أجل الحصول على مستويات أعلى من الأمان والمرونة، أو حتى بهدف توفير التكاليف؛ أمّا السحب الهجينة فتتميز بقدرتها على الاستفادة من موارد السحب العامة والخاصة وذلك وفقًا لمتغيرات الطلب والأولوية.

مفهوم السحابة مفتوحة المصدر

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

• OpenStack وهو مشروع مفتوح المصدر متخصص بإنشاء وإدارة البنية الأساسية للسحابة، بما يتضمن وسائط التخزين، وإمكانات الموارد الحاسوبية وإدارة الشبكات، كما يتضمّن العديد من المشاريع للمساعدة في التعامل مع كل ما يتعلّق بالسحابة بدءًا من إدارة حسابات المستخدمين وحتى استثمار قاعدة البيانات (المرحلة اللاحقة لتطويرها).
• حاويات Linux والتي ظهرت أصلًا بمثابة طريقة لتطوير تطبيقات السحابة، وتعتمد على الإجرائيات الخاصّة بالنواة Linux kernel مثل بديلٍ أسرع من الأجهزة الافتراضية التقليدية، كما أنّها تساعد المطورين على بناء الحاويات باستخدام مشاريع، مثل Docker و Kubernetes لتحقيق التناغم بين التطبيقات التي أُنشأت على عدّة حاويات.
• البيانات الضخمة و إنترنت الأشياء Internet of Things، وهما من أهم مستخدمي موارد الحوسبة السحابية، حيث تُطوَّر في كل منهما العديد من الأدوات لدعم التطبيقات لتكوت مفتوحة المصدر تمامًا.
• إضافةً للعديد من الأدوات الأخرى ابتداءً من حزم خوادم الويب Linux / Apache / MySQL / PHP وصولًا إلى تطبيقات التخزين السحابي ومحررات النصوص التشاركية.

ترجمة -وبتصرف- للمقال what is the cloud?‎ من موقع opensource.com.

اقرأ أيضًا

• الانتقال إلى الحوسبة السحابيّة
• تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة

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

مقدمة إلى OpenStack

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

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

كيف يستخدم OpenStack في بيئة السحابة؟

تدور فكرة السحابة حول توفير الحوسبة للمستخدمين النهائيين عند بُعد، بحيث يعمل البرنامج الفعلي مثل خدمة على خوادم موثوقة وقابلة للتوسع، بدلاً من تثبيت البرنامج وتشغيله على حاسوب كل مستخدم نهائي، وتشير الحوسبة السحابية إلى أشياء مختلفة، ولكنها تتحدث عادةً عن تشغيل عناصر مختلفة "مثل خدمة"، وقد تشمل هذه العناصر البرامج أو المنصات أو البنية التحتية، ويعدّ OpenStack بنيةً تحتيةً كخدمة Infrastructure as a service، والتي تختصر إلى IaaS، أي أنه يسهّل على المستخدمين إضافة نسخة جديدة بسرعة، مع إمكانية تشغيل مكونات السحابة الأخرى، وتشغل البنية التحتية منصةً platform يمكن للمطور من خلالها إنشاء تطبيقات برمجية تُقدم إلى المستخدمين النهائيين.

مكونات OpenStack

يمكن لأي شخص إضافة مكونات إضافية إلى OpenStack لتساعده على تلبية احتياجاته، لأنه مفتوح المصدر، لكن مجتمعه حدد تسعة مكونات رئيسية لتكون جزءًا من نواته، وتوزّع مثل جزء من أي نظام OpenStack، ويضمن مجتمعه صيانتها رسميًا، وهذه المكونات التسعة هي:

• Nova: هو محرك الحوسبة الأساسي لـ OpenStack، ويستخدم لنشر وإدارة أعداد كبيرة من الأجهزة الافتراضية والنُسخ الأخرى للتعامل مع مهام الحوسبة.
• Swift: هو نظام تخزين الكائنات والملفات، بدلًا من الفكرة التقليدية للإشارة إلى الملفات من خلال موقعها على محرك الأقراص، ويمكن للمطورين الرجوع إلى معرف فريد يشير إلى الملف أو جزء من المعلومات، أما مكان تخزين هذه المعلومات فيحدده OpenStack، مما يجعل التوسع أمرًا سهلًا، إذ لا يقلق المطورون بشأن سعة النظام الذي يعمل عليه البرنامج، ويصبح على النظام -لا على المطور- إيجاد أفضل السبل للتأكد من النسخ الاحتياطي للبيانات في حالة فشل اتصال الجهاز أو الشبكة.
• Cinder: هو أحد مكونات التخزين الكتلي، وهو أكثر تشابهًا مع المفهوم التقليدي المتمثل في قدرة الحاسوب على الوصول إلى مواقع محددة على محرك الأقراص، وهذه الطريقة التقليدية للوصول إلى الملفات مهمة في السيناريوهات التي تكون فيها سرعة الوصول إلى البيانات هي الأمر الأكثر أهميةً.
• Neutron: يوفر إمكانية الربط الشبكي لـ OpenStack، ويساعد على ضمان إمكانية اتصال مكونات نشر OpenStack ببعضها بسرعة وكفاءة.
• Horizon: لوحة تحكم OpenStack، وهي الواجهة الرسومية الوحيدة له، لذلك قد يكون هذا هو المكون الأول الذي يراه المستخدمون الذين يرغبون في تجربته، ويمكن للمطورين الوصول إلى جميع مكونات OpenStack من خلال واجهة برمجة التطبيقات API، لكن لوحة القيادة Horizon توفر لمسؤولي النظام القدرة على الاطلاع على ما يجري في السحابة، وإدارتها حسب الحاجة.
• Keystone: هو المسؤول عن توفير خدمات الهوية في OpenStack، وهو في الأساس قائمة مركزية لجميع مستخدمي سحابة OpenStack، مربوطة بجميع خدمات السحابة التي يمكنهم استخدامها، ويوفر Keystone وسائل متعددةً للوصول، مما يعني أنه يمكن للمطورين تعيين طرق وصول المستخدم الحالية بدل Keystone بسهولة.
• Glance: يوفر خدمات الصور images لـ OpenStack، وهي نُسخ (أو نسخ الافتراضية) من الأقراص الثابتة، و يسمح باستخدام هذه الصور مثل قوالب عند نشر نُسخ آلة افتراضية جديدة.
• Ceilometer: يوفر خدمات القياس عن بُعد، والتي تسمح للسحابة بتقديم خدمات الفوترة لمستخدمي السحابة، كما يحتفظ بعدد يمكن التحقق منه لاستخدام كل مستخدم للمكونات المختلفة لسحابة OpenStack.
• Heat: هو مكون التنظيم في OpenStack، ويسمح للمطورين بتخزين متطلبات تطبيق السحابة في ملف يحدد الموارد اللازمة للتطبيق، مما يساعد على إدارة البنية التحتية اللازمة لتشغيل خدمة السحابة.

من يمكنه استخدام OpenStack ؟

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

كيف أبدأ مع OpenStack؟

إذا رغبت في تجربة OpenStack فقط، فأحد موارد البداية دون الالتزام بأي موارد مادية هو TryStack، الذي يتيح لك اختبار تطبيقاتك في بيئة الاختبار sandbox لفهم كيفية عمل OpenStack فهمًا أفضل، وما إذا كان هو الحل المناسب لك.

يبحث OpenStack دائمًا عن مساهمين جدد، لذا ضع في حسبانك الانضمام إلى OpenStack Foundation إذا كانت لديك خبرة تقنية واهتمام في هذا المجال.

ترجمة -وبتصرف- للمقال ?What is OpenStack من موقع opensource.com.

اقرأ أيضًا

• المدخل الشامل لتعلم علوم الحاسوب
• الانتقال إلى الحوسبة السحابيّة
• تعلم أساسيات Kubernetes

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

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

المراقب hypervisor

يُستخدم المراقِب Hypervisor لإنشاء وتشغيل الأجهزة الافتراضية، وهو صنفان، يسمى الأول بالنمط الأول type one أو الخادم الحقيقي bare metal، حيث تشغّل آلات الضيف الافتراضية مباشرةً على عتاد النظام، وتعمل مثل نظام تشغيل، ويدعى الصنف الثاني بالنمط الثاني type two أو المراقب المستضاف Hosted، وهو يشبه التطبيقات التقليدية التي يمكن تشغيلها وإيقافها مثل أي برنامج عادي، وهذا التقسيم غير شائع في الأنظمة الحديثة، خاصةً مع أنظمة مثل KVM، اختصار الأجهزة الافتراضيّة المعتمدة على نواة لينكس Kernel-based Virtual Machine، وهو جزء من نواة نظام لينكس Linux يمكنه تشغيل الأجهزة الافتراضية مباشرةً على العتاد الفعلي.

الجهاز الافتراضي virtual machine

الجهاز الافتراضي هو المحاكي المكافئ لنظام الحاسوب الذي يعمل على نظام آخر، ويمكنه الوصول إلى أي عدد من الموارد، مثل القدرة على المعالجة computing power، وكذلك الوصول المحدود إلى وحدة المعالجة المركزية والذاكرة في الجهاز المضيف، كما يمكنه استخدام واحد أو أكثر من أجهزة أقراص التخزين المادية أو الافتراضية، والوصول إلى واجهة شبكة افتراضية أو حقيقية، بالإضافة إلى أي أجهزة، مثل بطاقات الفيديو أو أجهزة USB، أو أي عتاد آخر مشترك مع الجهاز الافتراضي، ويشار إلى تخزين الجهاز الافتراضي على قرص افتراضي باسم صورة قرص disk image، وقد تحتوي على ملفات تشغيل الجهاز الافتراضي، أو على أي متطلبات محددة للتخزين.

الحاوية container

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

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

تضيف أدوات أتمتة تكنولوجيا المعلومات مثل Ansible، ومنصات مشاريع الخدمات مثل OpenShift، إمكانيات إضافيةً لتسهيل إدارة الحاويات.

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

الموازنة بين الجهاز الافتراضي والحاوية

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

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

لم كل هذا الاهتمام بالحاويات؟

كان مشروع Docker مفتوح المصدر أحد أكبر أسباب الاهتمام بتكنولوجيا الحاويات مؤخرًا، وهو أداة سطر أوامر command line سهّلت على كل من المطورين ومسؤولي النظام إنشاء الحاويات والتعامل معها، على غرار الطريقة التي سهّل بها Vagrant على المطورين استكشاف الأجهزة الافتراضية.

Docker هو أداة سطر أوامر لتعريف محتويات حاوية لينكس في تعليمات برمجية، والتي يمكن بعد ذلك إصدارها وإعادة إنتاجها ومشاركتها وتعديلها بسهولة، كما لو أنها شيفرة مصدرية لبرنامج.

اهتمت الحاويات أيضًا ببنية الخدمات المصغرة microservice، وهو نمط تصميم لتطوير التطبيقات، تُقسم فيه التطبيقات المعقدة إلى أجزاء أصغر قابلة للتركيب وتعمل معًا، ويطوَّر كل مكون على حدة، ثم تجمع المكونات لتكوين التطبيق، ويمكن أن تعمل كل خدمة داخل الحاوية، كما يمكن توسيعها باستقلالية عن بقية التطبيق حسب الحاجة.

المحافظة على أمان الحاويات

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

يشرح Dan Walsh خبير أمن الحواسيب، والمعروف بعمله على SELinux، بعض الطرق التي يعمل عليها المطورون ليتأكدوا من ضمان Docker وأدوات الحاويات الأخرى لميزات الأمان، بالإضافة إلى ميزات الأمان الموجودة في Docker، مثل حماية ملفات النظام، وفضاءات الأسماء Namespace التي توفر بعض الأمان.

ترجمة -وبتصرف- للمقالين What are Linux containers? وWhat is virtualization? من موقع opensource.com.

اقرأ أيضًا

• الفرق بين Docker والأجهزة الافتراضية
• أبرز المفاهيم التي ينبغي معرفتها عن الحاويات
• مدخل إلى Kubernetes

كانت مواقع الويب مجرد ملفات نصيةً موضوعةً في مجلد، وتُشارَك مع العالم، وتنزَّل وتُعرَض في متصفح الويب، وكان هذا كل ما يجري خلال المعاملة transaction، ولكن الأمور أصبحت أكثر تعقيدًا، وصارت المواقع الإلكترونية تُشغل نماذج من التعليمات البرمجية، مما مكّن المبرمجين من إعداد ما يسمى "بتطبيقات الويب Web Applications"، مثل عربات التسوق، وبوابات تسجيل الدخول، وعملاء البريد الإلكتروني على الإنترنت، ومحررات الصور وغيرها.

ما إن بدأ تشغيل الويب للتطبيقات، حتى أدرك مهندسو النظم ومصمموها أن الشبكة كانت في الأساس حاسوبًا عملاقًا Supercomputer، وأنه يجب إدارة الموارد على عُقد هذا الحاسوب، تمامًا مثلما تُدار على حاسوب محمول عند تشغيل العديد من التطبيقات في وقت واحد.

كان بإمكاننا نسبيًا توقع الوقت المستغرق للحوسبة في أيام الحواسيب المركزية mainframe، إذ حجزنا موعدًا لاستخدام الحاسوب حرفيًا، ووضعنا مبدأً لإدارة الموارد اعتمد على قاعدة "من يأتي أولاً يُخدم أولاً"، لكن هذا قطعًا لا يصلح عند التعامل مع مليارات المستخدمين، فقد يحتاج أي عدد منهم إلى كل قدرة المعالجة للحاسوب في أي لحظة، ثم اعتقدنا في وقت لاحق أن الحل هو التوسع، أي المزيد من الخوادم التي تُشغل المزيد من نسخ التطبيقات، مما يعني إمكانية استخدام هذه التطبيقات من قبل مزيد من الأشخاص في أي وقت، ولكن قد يكون تشغيل 100 خادم مكلفًا عندما تزيد حركة المرور traffic، لذا فالمشكلة ليست في كيفية إدارة موارد الخادم الذي يشغِّل تطبيقًا ما فقط، بل في كيفية إدارة هذه الموارد ديناميكيًا أيضًا، أي اعتمادًا على عدد الأشخاص الذين يطلبون الوصول للتطبيق.

ما هو Kubernetes؟

Kubernetes (والذي يُشار إليه بالاختصار K8s) هو حل مفتوح المصدر لأتمتة النشر والتوسع الديناميكي للتطبيقات المغلفة في حاويات عبر الإنترنت، ويستخدم Kubernetes ما يسمى بالحاويات containers، وهي نظام في لينكس Linux يجمع التطبيقات في وحدات منطقية لتُدار بطريقة مركزية وآمنة، وهي مصممة لتكون سريعة الزوال، أي يمكن أن تتعطل الحاوية أو تتوقف دون فقد بيانات المستخدم، لأن البيانات تُحفظ خارج الحاوية، وتعدّ التطبيقات المعبأة في حاويات تطبيقات قابلةً للتخلص منها، ويمكن لمجموعة من الخوادم إطلاق نُسخ جديدة من التطبيق عندما يحتاج إليها الكثير من المستخدمين، أو تشغيل نُسخ أقل عندما يحتاج إليها بضع مئات من المستخدمين فقط، ويستطيع مسؤول النظام تنفيذ ذلك يدويًا أو من خلال كتابة سلسلة من السكربتات لمراقبة حركة المرور والاستجابة، لكن Kubernetes يجعل ذلك آليًا.

يمكن تثبيت Kubernetes للاختبار أو للإنتاج، فإذا كان الهدف تعلمه أو تجربة إنشاء تطبيق قائم على السحابة فقط، فيمكن تشغيل Kubernetes أو OpenShift أو OKD محليًا على حاسوبك، أما للمشاريع الجادة فيمكن بناء عنقود cluster خاص بك، وللبيئات الإنتاجية الكبيرة يمكن تثبيت OKD أو Kubernetes.

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

يسهّل Kubernetes إدارة الحاويات، إلا أنه عبارة عن مجموعة أدوات تصنعها بنفسك غالبًا، ويمكن تنزيله وتشغيله تمامًا مثلما طوِّر، ولكن ذلك يعني أنك ستطور أدواتك الخاصة لدعم عناقيدك فيه، وتوجد بعض الأدوات التي تساعد في ذلك، مثل Kubash وهي واجهة سطرية تفاعلية لعنقودك للمساعدة في إنشاء صور الحاويات وتوفير المضيفين، وKonveyor وهي سلسلة أدوات كاملة للمساعدة في ترحيل مجموعتك وتحسينها، وHelm وهو مدير الحزم، وغيرها الكثير.

ما هي OpenShift و OKD؟

OpenShift هي منصة لتطبيق Kubernetes مبنية للسحابة، بينما OKD هو المشروع الأولي له، وهو مفتوح المصدر.

تتجه البنية التحتية الحديثة إلى تعدد السحابات Multicloud والسحابة الهجينة hybrid cloud، لذا احتاج مسؤولو النظام والمطورين إلى منصة مستقرة وقابلة للتنبؤ، ويوفر OKD المرونة للمهندسين عند اختيار السحابة التي تعمل عليها بنيتهم التحتية، كما توفر للمسؤولين وصولًا سهلًا إلى إدارة المستخدمين والموارد، وتتيح للمطورين تطوير تطبيقات knative (أي أصيلةً مع "Kubernetes") وجاهزة للنشر على السحابة، كما أنها لوحة تحكم وطبقة تجريد abstraction وسلسلة أدوات في آن واحد.

OpenShift وOKD هي توزيعات Kubernetes، ويمكن للمسؤولين تشغيلها مع الاستمرار في استخدام جميع أوامر Kubernetes الأكثر شيوعًا، مثل kubectl وkubeadm وما إلى ذلك، ويمكن للمسؤولين استخدام جميع أوامر لينكس المألوفة لديهم لإدارة نظام التشغيل المضيف، لأن Kubernetes يعمل ويتفاعل مباشرةً مع نظام لينكس Linux وحاوياته.

كيف يعمل نظام Kubernetes؟

تعمل التطبيقات الموجودة على السحابة داخل حاويات، والحاويات ليست أشياءً ماديةً، بل هي مفهوم برمجي يعني تجميع العمليات الجارية على الخادم معًا لتتشارك في موارد معينة، وتشغَّل الحاويات عادةً بواسطة CRI-O أو Podman أو LXC أو Docker.

يُطلق على وحدة التنظيم الرئيسية في Kubernetes عند تشغيل التطبيقات اسم pod، وهي عبارة عن مجموعة من الحاويات، تُدار معًا على نفس الجهاز أو الجهاز الافتراضي أو العقدة، وهي مصممة لتتواصل مع بعضها البعض بسهولة، ويمكن تنظيم عدد منها في خدمة، وهي مجموعة pod تعمل معًا، وتُنظم بواسطة نظام من العناوين labels، مما يسمح بتخزين البيانات الوصفية حول كائنات مثل pods في Kubernetes.

يمكن تنظيم كل هذه الأجزاء بطريقة متوافقة، ويمكن التنبؤ بها من خلال واجهة برمجة التطبيقات API، أو من خلال OpenShift أو OK أو تعليمات محددة مسبقًا أو باستخدام أوامر طرفية.

ترجمة -وبتصرف- للمقال ?What is Kubernetes من موقع opensource.com.

اقرأ أيضًا

• مدخل إلى Kubernetes
• تعلم أساسيات Kubernetes
• مدخل إلى Helm: مدير حزم Kubernetes
• كيفية إعداد مكدس السجلات EFK على Kubernetes

أصبحت الحاويات Containers جزءًا من جميع نواحي بيئة تكنولوجيا المعلومات، وغيرتها تغييرًا جذريًا. فما هي المفاهيم التي عليك أن تعرفها عن الحاويات؟

غير الاحتواء Containerization بيئة تكنولوجيا المعلومات تغييرًا جذريًا بسبب قيمته الكبيرة والفوائد الجمّة التي أكسبها لهذا القطاع. فتقريبًا لن تجد ابتكارًا حديثًا في مجال الأعمال لا يُعدّ الاحتواء عاملًا مساهمًا فيه، هذا إن لم يكن عنصرًا محوريًا فيه.

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

وعند حديثنا عن السرعة والخفة والمرونة التي يعدنا بها الاحتواء الذي يتبع نهج العمليات والتطوير، لا نغفل العامل الحاسم، ألا وهو عامل الأمن. أدى هذا إلى ظهور مفهوم DevSecOps، الذي يدمج الأمن ب_ منذ البداية وخلال دورة حياة التطبيق الذي تحتويه الحاويات. يحسّن الاحتواء الأمن بدرجة كبيرة افتراضيًا لأنه يعزل التطبيق عن المضيف وعن التطبيقات الأخرى التي تحتويها الحاويات.

ماهي الحاويات؟

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

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

معمارية الحاوية

باختصار، توفر الحاوية العزلة من خلال استغلال تقنيات النواة مثل مجموعات التحكم cgroups وفضاءات أسماء النواة kernel namespaces وSELinux. تتشارك الحاويات مع المضيف بالنواة مما يتيح لها استهلاك موارد أقل من الذي تستهلكه الآلة الافتراضية virtual machine.

مزايا الحاويات

توفر معماريتها الخفة التي لا يمكن أن توفرها الآلات الافتراضية. فضلًا عن ذلك، تدعم الحاويات نموذجًا أكثر مرونةً فيما يتعلق بموارد الحوسبة والذاكرة، وتتيح ما يسمى بأنماط تدفق الموارد resource-burst التي تمكن التطبيقات من استهلاك قدر أكبر من الموارد عند اللزوم ضمن الحدود المحددة لها. بعبارة أخرى، توفر الحاويات مرونةً وقابليةً للتوسع لن تحظى بهما عند تشغيل تطبيقك على آلة افتراضية.

تسهِّل الحاويات مشاركة التطبيقات ونشرها على سحابات عامة أو خاصة. والأهم من ذلك، توفر التوافق الذي يساعد فرق العمليات والتطوير في تبسيط عملية نشر التطبيق على عدة منصات.

كما تتيح الحاويات مجموعة مشتركة من اللبنات الأساسية building blocks التي يمكن أن يعاد استخدامها في أي من مراحل التطوير لإنشاء بيئات مطابقة بغرض التطوير والاختبار والتجميع والإنتاج، موسعةً بذلك مفهوم "اكتب مرةً واحدةً، وطبق حيثما شئت".

تبسِّط الحاويات عملية تحقيق المرونة والتوافق والقدرة على نشر التطبيقات بسرعة مقارنةً بالبيئات الافتراضية، وهذا هو جوهر العمليات والتطوير.

عامل Docker

أصبح دوكر Docker مترادفًا مع الحاويات، إذ أنه أحدث ثورةً في عالم الحاويات وعمّمها، رغم أن تقنية الحاويات كانت موجودةً قبل ظهور دوكر. فقد كانت تستخدم مثلًا في تجزئات حجم العمل Workload partitions من AIX وحاويات سولاريس Solaris، وحاويات لينوكس LXC التي أنشئت لتشغيل عدة بيئات تعمل بنظام تشغيل لينوكس على مضيف واحد يعمل بنظام تشغيل لينوكس أيضًا.

تأثير نظام Kubernetes

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

يوفر نظام كوبيرنيتيس نهجًا شاملًا لإدارة الحاويات. يمكنه تشغيل الحاويات عبر عنقود cluster لتفعيل خصائص مثل التوسيع التلقائي للموارد السحابية، الذي يشمل متطلبات التطبيقات التي توجهها الأحداث، بأسلوب مؤتمت وتوزيعي. وإن هذا يضمن التوافر العالي high availability "مجانًا" (إذ لا يبذل المطورون أو مدراء النظام أي جهود إضافية لتحقيقه). تسهِّل أنظمة مثل أوبين شيفت وكوبيرنيتيس اعتماد الحاويات.

هل ستستبدل الحاويات الآلات الافتراضية؟

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

تعمل حاليًا الحاويات والآلات الافتراضية كحلول مكملة لبعضها وليس كتقنيات متنافسة. إذ تعمل الحاويات فوق الآلات الافتراضية لزيادة التوفر، وخاصةً للتطبيقات التي يجب أن تكون مستقرة، وتستفيد من تقنية البيئة الافتراضية التي تسهِّل إدارة بنية العتاد الصلب (مثل التخزين والربط الشبكي) اللازمة لدعم الحاويات.

ماذا عن الحاويات بنظام تشغيل ويندوز؟

تبذل شركة مايكروسوفت والمجتمع مفتوح المصدر جهودًا كبيرةً لإنجاح الحاويات بنظام التشغيل ويندوز. سرَّعت مشغلات كوبيرنيتيس اعتماد الحاويات التي تعمل على ويندوز، وتتيح منتجات مثل أوبين شيفت openshift خدمة Windows worker nodes لتشغيل حاويات بنظام تشغيل ويندوز.

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

مستقبل الحاويات

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

ستكون الحاويات حلًا طويل الأمد إذ ستظهر في المستقبل القريب العاجل حالات استخدام أخرى لها، مثل الحوسبة الحدّية خفية الخوادم serverless on the edge، وستغير طريقة تفكيرنا في سرعة نقل المعلومات من وإلى الأجهزة الرقمية. والطريقة الوحيدة للصمود في ظل هذه التغييرات هي التكيف معها.

ترجمة -وبتصرف- للمقال ‎6 container concepts you need to understand لصاحبه Mike Calizo.

اقرأ أيضًا

• نظرة عامّة على إعداد الحاويّات containerization على Docker
• كيفية مشاركة البيانات بين حاويات Docker
• ثلاث نصائح لتسمية حاويات Docker

يمكن أن يكون نشر التطبيقات في Kubernetes، نظام تنسيق الحاويات القوي والشائع، أمرًا معقدا. قد يتضمن إعداد تطبيق واحد إنشاء التعامل مع موارد Kubernetes المترابطة، مثل كائنات Pod، والخدمات وعمليات النشر والنسخ المتماثلة، يتطلب كل منها كتابة ملف YAML مفصل.

Helm هو مدير حزم يسمح للمطورين والمشغلين بتحزيم التطبيقات والخدمات وإعدادها ونشرها على عناقيد Kubernetes بسهولة أكبر؛ وهو الآن مشروع رسمي من مشاريع منصة Kubernetes الرسمية، ويمثّل جزءًا من مؤسسة الحوسبة السحابية الأصيلة (Cloud Native Computing Foundation)، وهي مؤسسة غير ربحية تدعم المشاريع مفتوحة المصدر التي تشكّل جزءًا من النظام البيئي لمنصة Kubernetes، والمشاريع التي تدور حولها.

سنقدم في هذ المقال نظرة عامة على Helm والتجريدات المختلفة التي يستخدمها لتبسيط نشر التطبيقات في Kubernetes. إذا كنت جديدًا على Kubernetes، فقد يكون من المفيد قراءة مقدمة عن Kubernetes أولاً للتعرف على المفاهيم الأساسية.

نظرة عامة على Helm

تحوي غالبية لغات البرمجة وأنظمة التشغيل على مدير حزم خاص بها للمساعدة في تثبيت البرامج وصيانتها. يقدّم Helm مجموعة الميزات الأساسية نفسها التي يقدّمها الكثير من مديري الحزم المشهورين مثل apt في توزيعة دبيان و pip في بيئة تطوير بايثون.

يستطيع Helm:

• تثبيت البرامج.
• تثبيت اعتماديّات البرامج تلقائيا.
• ترقية البرامج.
• إعداد عمليات نشر البرامج.
• إحضار حزم البرامج من المستودعات.

يوفر Helm هذه الوظائف من خلال المكونات التالية:

• أداة سطر الأوامر، helm، التي توفر واجهة مستخدم لجميع وظائف Helm.
• مكوّن مرافق للخادم، tiller، يعمل على عنقود Kubernetes الخاصة بك، ويستمع إلى الأوامر من helm، ويتعامل مع إعدادات إصدارات البرامج وعمليّات نشرها على عنقود Kubernetes.
• صيغة تحزيم خاصّة بمدير الحزم Helm، وتسمى charts.
• مستودع رسمي لحزم Charts، مع حزم جاهزة لمشاريع برمجية مفتوحة المصدر شائعة.

سنحقق في تنسيق الحزم بمزيد من التفاصيل بعد ذلك. سنفصّل في ما يلي حول صيغة التحزيم Charts.

صيغة التحزيم Charts

يُطلَق على حزم Helm اسم Charts، وتتكون من عدد قليل من ملفات الإعداد المكتوبة بلغة YAML وبعض القوالب التي تُصيَّر (Rendered) ضمن ملف التبيان (Manifest file) في Kubernetes. في ما يلي البنية القاعدية لمجلّد حزمة بصيغة Chart:

package-name/
  charts/
  templates/
  Chart.yaml
  LICENSE
  README.md
  requirements.yaml
  values.yaml

هذه المجلدات والملفات لها الوظائف التالية:

• /charts: يمكن وضع اعتماديّات الحزم المُدارة يدويًا في هذا المجلد، على الرغم من أنه من الأفضل عادةً استخدام requirements.yaml لربط الاعتماديّات بالحزمة ديناميكيّا.
• /templates: يحتوي هذا المجلد على ملفات القوالب التي تُدمَج مع قيم الإعداد (من ملف values.yaml وسطر الأوامر) وتُصيّر ضمن ملفّات تبيان Kubernetes. تستخدم القوالب تنسيق القوالب في لغة برمجة Go.
• Chart.yaml: ملف YAML يحتوي على بيانات وصفية حول الحزم، مثل اسم الحزمة وإصدارها، ومعلومات المشرف، وموقع الويب ذي الصلة، والكلمات الرئيسية للبحث.
• LICENSE: ترخيص نص عادي للحزمة.
• README.md: ملف تمهيدي يحتوي على معلومات لمستخدمي الحزمة.
• requirements.yaml: ملف YAML يسرد اعتماديّات الحزمة.
• values.yaml: ملف YAML بقيم الإعدادات الافتراضية للحزمة.

يمكن للأمر helm تثبيت حزمة من مُجلد محلي، أو من مجلّد بالبنية أعلاه مضغوط ضمن ملف tar.gz.. يمكن أيضًا تنزيل هذه الحزم وتثبيتها تلقائيًا من مستودعات حزم Helm.

سنلقي في ما يلي نظرة على مستودعات حزم Helm.

مستودعات الحزم

يتمثّل مستودع حزم Helm في موقع ويب بسيط يقدّم ملفّ index.yaml وحزمة Helm مضغوطة في ملفtar.gz. . يحتوي الأمر helm على خيارات متاحة للمساعدة في التحزيم بصيغة Helm وإنشاء ملف index.yaml المطلوب. يمكن تقديم هذه الملفات بواسطة أي خادم ويب أو خدمة تخزين أو مضيف مواقع ثابتة مثل صفحات GitHub.

يأتي Helm مهيأ مسبقًا بمستودع حزم مبدئي، يوصف بأنه مستقر (stable). يشير هذا المستودع إلى مجموعة تخزين Google على الرابط https://kubernetes-charts.storage.googleapis.com. يمكن العثور على مصدر المستودع المستقر على مستودع Git التالي.

يمكن إضافة مستودعات بديلة باستخدام الأمر helm repo add. في ما يلي مستودعات بديلة شائعة:

• مستودع incubator الرسمي الذي يحتوي على حزم غير جاهزة بعد لتكون ضمن المستودع المستقر. يمكن العثور على تعليمات استخدام Incubator في صفحة Github التالية.
• مستودع Bitnami الذي يوفر حزمًا غير متوفّرة في المستودع الرسمي المستقر.

سواء كنت تثبّت حزمة طوّرتها محليًا، أو حصلت عليها من مستودع، فستحتاج إلى تهيئتها لإعداداتك الخاصة، وهو ما سننظر فيه الفقرة التالية

إعداد حزم Helm

عادةً ما تأتي حزم Helm بقيم الإعدادات الافتراضية في ملف values.yaml. قد تكون بعض التطبيقات قابلة للنشر كاملةً باستخدام القيم الافتراضية، ولكن ستحتاج عادةً إلى إعادة تعيين قيم لتلبية احتياجاتك.

يحدّد مطوّر الحزمة القيم التي تمكن إعادة تعيينها. تُستخدم بعض القيم لإعداد وظائف Kubernetes، في حين تُمرَّر أخرى عبر الحاويّة لإعداد التطبيق نفسه.

فيما يلي مقتطف من مثال لملف قيم:

service:
  type: ClusterIP
  port: 3306

هذه خيارات لإعداد مورد خدمة Kubernetes. يمكنك استخدام helm inspect values chart-name لتفريغ كل قيم الإعداد المتاحة للحزمة.

يمكن تجاوز هذه القيم عن طريق كتابة ملف YAML خاص بك واستخدامه عند تشغيل الأمر helm install، أو من خلال تعيين الخيارات فرديًّا في سطر الأوامر مع الخيار set--. ما عليك سوى تحديد تلك القيم التي تريد تغييرها من الإعدادات الافتراضية.

تُسمى حزم Helm المنشورة بإعداد معين بالإصدار (release).

الإصدارات

أثناء تثبيت الحزمة، يجمع Helm بين القوالب والإعدادات المُخصّصة من طرف المستخدم والقيم الافتراضية في value.yaml. تُحوّل تلك الإعدادات إلى ملف Manifest في Kubernetes تُنشَر بعد ذلك عبر واجهة تطبيقات Kubernetes. ينتج عن ذلك إنشاء إصدار، وهو إعداد ونشر محدّديْن لحزمة معينة.

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

قد ترغب أيضًا في ترقية نظائر مختلفة من الحزمة فرديّا. ربما يكون تطبيق جاهزًا لخادم MySQL مُحدَّث ولكن تطبيقًا آخر ليس كذلك. باستخدام Helm، يمكنك ترقية كل إصدار على حدة.

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

إنشاء الحزم

إذا لم تتمكن من العثور على حزمة موجود للبرنامج الذي تنشره، فقد ترغب في إنشاء الحزمة الخاص بك. يمكن لمدير الحزم Helm إنشاء بنية جاهزة لمجلد الحزمة باستخدام الأمر helm create chart-name. سيؤدي هذا إلى إنشاء مجلد يحتوي على الملفات والمجلدات التي ناقشناها في قسم ضيغة التحزيم أعلاه.

من هناك، ستحتاج إلى ملء البيانات الوصفية للحزمة الخاصة بك في Chart.yaml ووضع ملفات تبيان Kubernetes في مجلد templates. ستحتاج بعد ذلك إلى استخلاص متغيرات الإعداد المناسبة من ملفات التبيان إلى ملف القيم values.yaml، ثم تضمينها مرة أخرى في ملفات التبيان باستخدام نظام القوالب.

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

خاتمة

في هذا المقال استعرضنا Helm، مدير حزم Kubernetes. ألقينا نظرة عامة على هندسة Helm، ومكوناته helm و tiller، وفصّلنا صيغة حزم Helm، وألقينا نظرة على مستودعات الحزم. تطرّقنا كذلك إلى كيفية إعداد حزم Helm، وكيف تُدمَج الإعدادات والحزم وتُنشَر كإصدارات على عناقيد Kubernetes. أخيرًا، تطرقنا إلى أساسيات إنشاء حزمة في حالة عدم توفر حزمة مناسب بالفعل.

لمزيد من المعلومات حول Helm ، ألق نظرة على وثائق Helm الرسمية. تحقق من مستودع helm/charts على Github للعثور على الحزم الرسمية.

ترجمة - وبتصرّف - للمقال An Introduction to Helm, the Package Manager for Kubernetes لصاحبه Brian Boucheron.