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

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

لماذا لم ينتشر لينكس من قبل؟

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

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

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

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

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

هل سيعمل لينكس على حاسوبي القديم؟

يستهلك نظام ويندوز في العادة بين 2-4 جيجابايت من الذاكرة العشوائية (الرام) دون استخدام الحاسوب فعليًا في تنفيذ أي مهام، بينما تستهلك أنظمة لينكس ذات الواجهات الخفيفة مثل XFCE أو LXQt حوالي 500 - 800 ميجابايت فقط، مما يترك لك مساحة أكبر في الذاكرة للمهام والبرامج التي ستعمل عليها. إليك بعض الأمثلة الأخرى التي تتميز فيها أنظمة لينكس:

تقليل الضغط على المعالج

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

الأمان من الفيروسات

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

خفة النظام وسرعته

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

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

مشاكل أقراص HDD

يعاني نظام ويندوز من مشكلة تجزئة الملفات fragmentation مع الأقراص الصلبة القديمة من نوع HDD بسبب نظام ملفات NTFS الذي يستخدمه، أما أنظمة لينكس فتستخدم أنظمة ملفات أسرع ولا تعاني من هذه المشكلة، مثل ext4 أو Btrfs.

الاستقرار البرمجي

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

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

أنظمة لينكس حرة ومجانية

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

ماذا عن البرامج التي أستخدمها؟

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

حتى في حالة البرامج المتخصصة قد تجد إما نسخة منها تعمل على الويب في المتصفح بغض النظر عن نظام التشغيل التي تعتمد عليه، أو برامج بديلة له، فمثلًا لدينا برنامج جِمب GIMP البديل لبرنامج فوتوشوب، وبرنامج إنكسكيب Inkscape البديل لبرنامج Illustrator، وبرنامج بلندر Blender البديل لبرنامج التصميم ثلاثي الأبعاد 3ds Max، والذي تستخدمه كل من وكالة ناسا ووكالة إيسا للفضاء في تصميم محاكاة واقعية للثقوب السوداء مثلًا، وكذلك شركة BMW في تصميم منتجاتها، وقس عليها في البرامج الهندسية وبرامج التصميم والفيديو وغيرها.

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

أمثلة التوزيعات المتاحة

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

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

توزيعة فيدورا

توفر توزيعة فيدورا Fedora Linux عدة إصدارات للتحميل مباشرة موجهة للاستخدامات المختلفة، لكن سنركز على إصدارين فقط هما جنوم Gnome وكِدي بلازما KDE Plasma، وهما بيئتا سطح مكتب أو واجهات مرئية لسطح المكتب، هذا ما تتعامل معه كل يوم من قوائم وأزرار وأيقونات وغيرها، وتشبه بيئة جنوم الواجهة المرئية لنظام ماك. انظر الصورة التالية من بيئة جنوم لتوزيعة فيدورا:

والصورة التالية من بيئة كِدي بلازما، وهي أشبه بنظام ويندوز في الاستخدام ومناسبة أكثر لمن تعود عليه:

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

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

توزيعة أوبنتو

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

وهذا المثال من بيئة كِدي:

تصدر توزيعة أوبنتو الجديدة كل ستة أشهر كذلك، مرة في أبريل ومرة في أكتوبر وتحمل التوزيعة حينها اسم العام والشهر -مثال: أوبنتو 25.10 صدرت في شهر أكتوبر عام 2025-، ويستمر الدعم لمدة 9 أشهر لكل إصدار. كذلك تُصدر كل عامين إصدارًا له دعم لمدة خمس سنوات فيما تسميه الدعم طويل الأمد Long Term Support LTS، ويصدر في العادة في شهر أبريل من الأعوام ذات الأرقام الزوجية، على سبيل المثال كانت الإصدارات طويلة الدعم السابقة في أبريل 2022، وأبريل 2024، ويُتوقع أن تخرج الثالثة وقت كتابة هذا المقال في أبريل 2026.

توزيعة أوبن سوزا

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

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

انظر المثال التالي من بيئة كِدي في أوبن سوزا Leap:

كلمة حول بيئات سطح المكتب

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

وإذا جربت إحدى التوزيعات ولم تعجبك البيئة الموجودة فيها فتستطيع تثبيت واحدة أخرى على نفس النظام دون أن تغير النسخة التي لديك كما كان يحدث في ويندوز، تستطيع تخيل الأمر كأن لديك إصدارات ويندوز 10 و8 و7 وXP على نفس الحاسوب، وتختار ما تشاء منها في كل مرة تسجل الدخول!

النظام الحي

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

تثبيت النظام

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

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

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

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

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

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

خاتمة

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

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

اقرأ أيضًا

• كيفية تثبيت توزيعة أوبنتو من لينكس بأبسط طريقة
• ما هو نظام التشغيل لينكس؟
• تعرف على سطح مكتب أوبونتو 20.04
• ما هو نظام لينكس ولماذا توجد 100 توزيعة منه؟

جنو نانو GNU Nano هو محرر نصوص لأنظمة التشغيل التي تشبه نظام التشغيل يونكس أو بيئات التشغيل التي تستخدم سطر الأوامر كواجهة للإدخال، طُرح لأول مرة عام 1999 بواسطة Chris Allegretta وهو يحاكي محرر النصوص بيكو Pico.

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

اختصارات لوحة المفاتيح الشائعة لمحرر النصوص نانو Nano

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

البداية مع محرر النصوص نانو Nano

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

1. التعرف على الواجهة

سيظهر لنا الخرج التالي عند فتح محرر النصوص نانو Nano عن طريق فتح نافذة الطرفية وكتابة الأمر nano فيها كما في الشكل:

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

يستخدم محرر النصوص نانو nano رمزين مرتبطين لكل اختصار، وذلك بخلاف محررات واجهة المستخدم الرسومية GUI والتي تعرض الرمز مباشرةً كما يلي:

• الرمز ^ وهو الرمز الأساسي الذي يشير إلى المفتاح CTRL
• الرمز M والمعروف باسم مفتاح الوصف meta key ويشير إلى المفتاح ALT

وبالتالي إذا أردنا استخدام الاختصار G^ فلا بد من الضغط على CTRL+G؛ أما عندما نريد استخدام الاختصار M-A، فسيتوجب علينا الضغط على ALT+A.

2. فتح أو إنشاء الملفات باستخدام محرر النصوص نانو Nano

لفتح ملف باستخدام محرر النصوص نانو nano، كل ما علينا فعله هو كتابة الأمر nano ثم إتباعه باسم الملف `nano .

على سبيل المثال إذا أردنا فتح الملف mylogs.log بمحرر النصوص نانو nano، فيكفي كتابة الأمر التالي:

nano mylogs.log

أما إذا كان الملف غير موجود وأردنا إنشاء ملف جديد باستخدام محرر النصوص نانو nano والكتابة فيه، فيجب علينا كتابة اسم الملف غير الموجود بعد الأمر nano، وسيفتح لنا ملف فارغ يمكننا إجراء التغييرات التي نريدها فيه <nano  <NewFile. على سبيل المثال، يمكننا إنشاء ملف جديد باسم unknown.txt وكتابة بعض الأسطر فيه ثم نحفظ التغييرات كما يلي:

nano <NewFile>

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

على سبيل المثال، سنكتب رسالة تهنئة في محرر النصوص نانو nano ثم نحفظ الملف باسم Hello.txt كما في الشكل:

3. التنقل ضمن الملف

يمكن التنقل ضمن محرر النصوص نانو Nano عن طريق مفاتيح الأسهم على عكس محررات النصوص المتقدمة مثل محرر النصوص فيم Vim، وفيما يلي بعض النصائح والملاحظات من أجل التنقل ضمن الملف بسرعة أكبر:

• الضغط \ + ALT للذهاب إلى بداية الملف
• الضغط / + ALT للذهاب إلى نهاية الملف

يمكن أيضًا القفز إلى سطر محدد من خلال الضغط على _ + CTRL وإدخال رقم السطر الذي نريد كما في الشكل:

4. عمليات القص والنسخ واللصق في محرر النصوص نانو Nano

يمكن في حال استخدامنا لبيئة سطح المكتب اختيار النص باستخدام الفأرة والضغط على Ctrl + Shift + C لنسخ النص المحدد ومن ثم لصقه باستخدام Ctrl + Shift + V.

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

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

نستطيع بعد تحديد النص القيام بأحد الأمرين:

• الضغط Alt + 6 لنسخ النص المحدد
• الضغط Ctrl + K لقص النص المحدد
• وبعد قص أو نسخ النص، نضغط Ctrl + U للصق النص.

يمكننا على سبيل المثال لصق النص المنسوخ في نهاية الملف كما في الشكل:

5. حذف أسطر في محرر النصوص نانو Nano

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

1. استخدام زر التراجع backspace عدة مرات لحذف النصوص أو الأسطر
2. استخدام قص الأسطر بالضغط على الاختصار Ctrl + K

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

يمكننا تحديد عدة أسطر أو كلمات لقصها من أجل التخلص منها (حذفها) من خلال استخدام مفاتيح الأسهم كما يلي:

1. الانتقال باستخدام مفاتيح الأسهم إلى النقطة التي تريد حذف الأسطر ابتداءً منها
2. الضغط على الاختصار Alt + A لوضع العلامة
3. الضغط على الاختصار / + ALT للإنتقال إلى نهاية الملف
4. الضغط على الاختصار Ctrl + K لقص النص المحدد

6. التراجع والإعادة

تشير عملية التراجع Undo إلى العدول عن آخر عملية قام بها المستخدم، بينما تشير عملية الإعادة Redo إلى تكرار آخر عملية تم التراجع عنها.

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

• للتراجع عن آخر عملية، نستخدم الاختصار Alt + U
• لتكرار أو إعادة آخر عملية تم التراجع عنها، نستخدم الاختصار Alt + E

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

7. البحث والاستبدال

تتم عملية البحث والاستبدال في محرر النصوص نانو Nano باستخدام ثلاث خطوات بسيطة جدًا وهي:

1. الضغط Ctrl + R ثم كتابة الكلمة أو المصطلح الذي نريد البحث عنه ثم نضغط Enter
2. ندخل الكلمة الجديدة المراد الاستبدال بها
3. ستظهر الكلمات المطابقة واحدةً تلو الأخرى وسيسألنا إذا كنا نريد استبدالها أم لا، وللقيام بعمليات الاستبدال دفعةً واحدة، سنضغط على الرمز A.

سنستبدل في المثال التالي الكلمة quick بالكلمة lazy كما في الشكل:

8. الحفظ والخروج من محرر النصوص نانو Nano

تتم عملية الحفظ والخروج من محرر النصوص نانو Nano بطريقة سهلة للغاية وعن طريق خطوتين فقط هما:

1. الضغط على الاختصار Ctrl + O لحفظ التغييرات
2. الضغط على الاختصار Ctrl + X للخروج من محرر النصوص

ملاحظة: يمكن الخروج من محرر النصوص نانو Nano بدون حفظ التغييرات، وذلك بالضغط مباشرةً على الاختصار Ctrl + X، ومن ثم الضغط على المفتاح N.

عند الضغط على الاختصار Ctrl + O لحفظ التغييرات، سيسألنا المحرر عما إذا كنا نريد حفظ تلك التغييرات باسم الملف نفسه أو باسم ملف مختلف، لذا يمكن انتقاء أحد الخيارين ثم الضغط المفتاح Enter لحفظ التغييرات.

هناك ميزة أخرى رائعة في محرر النصوص نانو Nano، وهي الطريقة التي يخبرنا بها بالتغييرات التي لم تُحفظ بعد، حيث ستظهر علامة النجمة * بجانب اسم الملف كما في الشكل:

بعد الانتهاء من ذلك، سنضغط على الاختصار Ctrl + X للخروج من محرر النصوص نانو Nano.

إذا رغبنا في الخروج من محرر النصوص نانو nano بدون حفظ التغييرات، سنتبع الخطوات البسيطة التالية:

1. الضغط على الاختصار Ctrl + X
2. الضغط على الاختصار N للخروج من محرر النصوص نانو Nano بدون حفظ التغييرات

9. طريقة الحصول على المساعدة من محرر النصوص نانو Nano

تُعَد عملية المساعدة في محرر النصوص نانو nano مفيدةً جدًا في الأوقات الصعبة التي لا تعرف فيها ماذا تفعل، وكل ما علينا القيام به هو الضغط على الاختصار Ctrl + G وسيحضر لنا قائمةً بجميع الاختصارات المتوفرة في محرر النصوص نانو nano مع وصف بسيط لها كما في الشكل:

الخلاصة

بهذا نكون قد تعرفنا على الأوامر الأساسية لمحرر النصوص نانو Nano. نتمنى لكم الاستفادة الجيدة من هذا المقال، وفي حال كان لديكم أي تساؤل يمكن تركه في قسم التعليقات أسفل المقال أو كتابته في قسم الأسئلة والأجوبة في الأكاديمية.

ترجمة وبتصرف للمقال Nano Editor Basic Commands لكاتبه Sagar Sharma.

اقرأ أيضًا

• مقارنة بين محرر النصوص فيم Vim ونانو Nano
• معالجة النصوص على RedHat Enterprise Linux: تحريرها بـ Nano و Vim والبحث فيها بـ grep
• تعرف على محرر النصوص فيم Vim

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

تشغيل خادم MongoDB

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

يمكن الاتصال مع خادم MongoDB بواسطة الصدفة MongoDB Shell، وعند بدء التشغيل سيكون المنفذ 27017 هو المنفذ الافتراضي للاتصال بخادم MongoDB؛ أما إذا أردنا الوصول إلى الخادم من واجهة الويب فيمكننا ذلك باستخدام المنفذ الناتج عن إضافة 1000 إلى رقم منفذ بدء التشغيل، فنكتب عندها الرابط http://localhost:28017 في متصفحنا.

الاتصال بخادم MongoDB من الصدفة Shell

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

mongodb://localhost

وبمجرد تنفيذ الأمر سنحصل على الخرج التالي:

إذا عُدنا الآن إلى نافذة موجه الأوامر التي شغلنا فيها خادم MongoDB، وهو نفسه الملف التنفيذي mongod، سنجد أنها تتضمن خرجًا يشبه التالي:

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

ملاحظة: سيظهر هذا السطر عندما ينجح اتصالنا مع الخادم

صيغ متنوعة لأمر الاتصال مع خادم MongoDB

يمكن ذكر الصيغ الآتية لأوامر الاتصال مع خادم MongoDB

الاتصال بقاعدة البيانات الافتراضية باستخدام اسم مستخدم وكلمة مرور

يمكننا الاتصال مع خادم MongoDB بواسطة اسم مستخدم وكلمة مرور محددين وفق الصيغة العامة username@hostname/dbname، بحيث نعدل اسم المستخدم username إلى اسم المستخدم الذي نود الاتصال بواسطته مع كلمة المرور الخاصة به، كما نبدل اسم الحاسوب المضيف hostname إلى اسم الحاسوب المضيف الفعلي، و dbname إلى اسم قاعدة البيانات؛ وإذا أردنا الاتصال بقاعدة البيانات الافتراضية، يكفي أن نترك اسم قاعدة البيانات فارغ، كما هو الحال في المثال التالي:

mongodb://mongo_admin:AxB6_w3r@localhost/

ولتوضيح الشيفرة أعلاه، يشير mongo_admin إلى اسم المستخدم، و AxB6_w3r إلى كلمة المرور الخاصة به؛ وهو يحاول الاتصال بقاعدة البيانات الافتراضية الموجودة على الحاسوب المحلي localhost.

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

الاتصال بقاعدة بيانات معينة باستخدام اسم مستخدم وكلمة مرور

سنستخدم الصيغة العامة السابقة نفسها username@hostname/dbname مع تعديل كلمة dbname إلى اسم قاعدة البيانات التي نريد بالاتصال بها، وفق التالي:

mongodb://mongo_admin:AxB6_w3r@localhost/w3r

وباستخدام هذا الأمر سيتصل المستخدم mongo_admin صاحب كلمة المرور AxB6_w3r بقاعدة البيانات w3r الموجودة على الحاسوب المحلي، وسيكون الخرج كما يلي:

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

الاتصال بقاعدة بيانات معينة باستخدام اسم مستخدم وكلمة مرور ومَنفَذ معين

يجري هذا الاتصال بطريقة مشابهة للسابق، بحيث نستخدم الصيغة username@hostname/dbname ونضع اسم المستخدم وكلمة المرور؛ وبدلًا من dbname، نكتب اسم قاعدة البيانات التي نريد الاتصال بها، يتبعها رقم المَنفَذ port الذي حددناه للاتصال معها، كما هو الحال في المثال التالي:

mongodb://mongo_admin:AxB6_w3r@localhost/w3r:29000

بمعنى أن المستخدم mongo_admin الذي كلمة مروره AxB6_w3r سيحاول الاتصال بقاعدة البيانات w3r الموجودة على الحاسوب المحلي، وذلك عبر المنفذ 29000. وفي الحالات التي لا نذكر فيها رقم منفذ محدد، سيجري الاتصال عبر المنفذ الافتراضي 27107، بحيث سيكون خرج الأمر كما يلي:

الاتصال بخوادم MongoDB متعددة تعمل على أجهزة متعددة

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

في المثال التالي صيغة الأمر المناسب لهذا النوع من الاتصال:

mongodb://example_host1.com:27017,example_host2.com:27017

الاتصال بخوادم MongoDB متعددة تعمل على الجهاز نفسه ولكل منها منفذ خاص

سنستخدم الأمر التالي للاتصال بخوادم MongoDB المتعددة التي تعمل على الجهاز نفسه، لكن على منافذ ports مختلفة. سيفيدنا هذا أيضًا في مجموعات النسخ المتماثلة replica sets:

mongodb://example_host1.com:27110,example_host1.com:27111

الخيارات المرتبطة بالصيغ السابقة

يبين الجدول التالي الخيارات التي يمكننا استخدامها مع صيغ أوامر الاتصال السابقة:

خاتمة

تعرفنا في هذا المقال على الطرق المتنوعة للاتصال مع خادم MongoDB عبر الصدفة mongo shell. وسواءٌ كان ذلك على مُضيف واحد أو على مضيفين متعددين، يرتكز الاتصال على تحديد أربع أمور أساسية هي بيانات المستخدم الذي سيُنجِز الاتصال، واسم قاعدة البيانات، والمَنْفَذ الخاص بها، واسم المُضيف؛ ويمكننا استخدام الخيارات التي عرضناها في الجدول حسب ما تقتضيه طبيعة مشروعنا.

ترجمة -وبتصرف- لمقال MongoDB connections من موقع w3resource.

اقرأ أيضًا

• طريقة تثبيت MongoDB على ويندوز ولينكس
• كيفية تثبيت وتأمين MongoDB على أوبونتو 18.04
• كيفية إنشاء واستخدام النسخ الاحتياطي لقواعد بيانات MongoDB على نظام أوبنتو
• دليلك الشامل إلى قواعد البيانات DataBase

سنعرض في هذا المقال طريقة تثبيت MongoDB على نظامي تشغيل ويندوز ولينكس، مع تمهيد بسيط لبدء العمل مع الصدفة mongo shell التي تمكننا من التفاعل مع قاعدة البيانات.

اقتباس

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

التحميل Download

يمكن تحميل ذ الثنائية المُعدّة مسبقًا Pre-built binary packages مباشرةً من موقعها الرسمي، لذا ما علينا سوى اختيار النسخة المناسبة ورقم الإصدار، ونظام التشغيل ويندوز أم لينكس، ونوعه 32 بت أم 64 بت؛ وعند انتهاء التحميل سيكون من السهل تثبيتها كما سنعرض في الفقرات التالية.

فك الضغط Unzip

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

إنشاء مجلد بيانات MongoDB

سننشئ أيضًا مجلدًا خاصًا بالبيانات نسميه data، ثم ننشئ بداخله مجلدًا آخر يسمى db، وهذا هو الاسم الافتراضي للمجلد الذي تخزن فيه MongoDB البيانات، ولأن هذا المجلد لا ينشأ تلقائيًا عند تثبيت MongoDB، فقد أنشأناه يدويًا.

ينبغي إنشاء المجلد data على الجذر مباشرةً، أي على (\:C أو \:D أو نحو ذلك) في ويندوز، وعلى (/) في لينكس، كما يلي:

إنشاء المجلدات في ويندوز (أنشأنا المجلدات على القرص \:D في مثالنا):

إنشاء المجلدات في لينكس:

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

تشغيل خادم MongoDB من موجه الأوامر

لتشغيل خادم MongoDB من موجه الأوامر، لا بد من فتح المجلد mongodb الذي أجرينا فيه عملية فك الضغط سابقًا، ثم نفتح المجلد الفرعي ضمنه bin، ونشَغِّل الملف التنفيذي mongod.exe.

تشغيل خادم MongoDB كخدمة ويندوز

اقتباس

اقتباس

هذه الفقرة خاصة بنظام ويندوز فقط.

سنحتاج لتنفيذ الأمر التالي بصلاحيات مدير نظام administrator لتشغيل خادم MongoDB كخدمة ويندوز:

mongod --bind_ip  yourIPadress  --logpath  "C:\data\dbConf\mongodb.log"  --logappend  --dbpath  "C:\data\db"  --port yourPortNumber --serviceName "YourServiceName" --serviceDisplayName "YourServiceName" --install

لا ننسَ ضبط قيم الوسطاء Arguments ضمن الأمر بما يناسب حالتنا كما هو موضح في الجدول التالي:

تمهيد لاستخدام الصدفة Shell الخاصة بنظام MongoDB

لا بد لنا من الحرص على العمل من مستخدم يملك صلاحيات مدير نظام، ثم نشَغَّل الملف التنفيذي mongo.exe الموجود ضمن المجلد bin، أحد المجلدات الفرعية للمجلد الذي ثَبَّتنا فيه MongoDB، وبمجرد تشغيله ستفتح أمامنا الصدفة shell الخاصة بإدارة نظام MongoDB، وهي من نوع JavaScript shell، كما في الصورة التالية:

يمكننا ملاحظة أن MongoDB قد اتصل مباشرةً بقاعدة بيانات مستندية document database تجريبية تدعى test.

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

سنجري الآن بعض العمليات البسيطة لاختبار الصدفة shell، ونكتب مثلًا عمليةً حسابيةً طالما أن الصدفة مكتوبة بلغة JavaScript، ويمكن أيضًا استخدام الأمر db فهو يعطينا اسم قاعدة البيانات المتصل بها:

لنجرب الآن إدخال سجل بسيط وإرجاع بعض المعلومات منه:

أدخلنا في السطر الأول القيمة 8 إلى الحقل z التابع للمجموعة w3r، ثم استعلمنا عن البيانات؛ علمًا أن المجموعات collections في MongoDB تكافئ الجداول في قواعد البيانات العلائقية.

واجهة الويب لنظام MongoDB

يمكن الوصول إلى واجهة الويب الخاصة بإدارة MongoDB ومراقبته عبر منفذٍ port خاص، يكون رقمه هو نفسه رقم المنفذ المخصص لخادم MongoDB مضافًا إليه 1000.

فعلى سبيل المثال، إذا كنا نستخدم المنفذ الافتراضي لخادم MongoDB وهو 27017 فمعنى ذلك أنه يمكن الوصول إلى واجهة الويب من المنفذ 28017.

الخاتمة

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

ترجمة -وبتصرف- لمقال Install MongoDB on Windows ومقال Install MongoDB on Linux من موقع w3resource.

اقرأ أيضًا

• كيفية تثبيت وتأمين MongoDB على أوبونتو 18.04
• كيفية إنشاء واستخدام النسخ الاحتياطي لقواعد بيانات MongoDB على نظام أوبنتو
• دليلك الشامل إلى قواعد البيانات DataBase

قد يكون اختيار قاعدة البيانات المناسبة للمشروع أمرًا صعبًا، خاصةً مع وجود العديد من الخيارات.

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

نظرة عامة على MariaDB و MySQL

نشأت كل من MariaDB وMySQL من الجذور نفسها، إذ يعود أصلهما إلى نظام قاعدة بيانات إنجرس Ingres الذي طوّرته جامعة كاليفورنيا في بيركلي.

طُوِّرت MySQL لأول مرة في عام 1995 واكتسبت شعبيةً كبيرةً لأنها كانت سهلة الاستخدام وسريعة، ولكن أصبح هناك خلاف بين مالكي MySQL وأوراكل Oracle لاحقًا، لذا جرى تطوير قاعدة بيانات جديدة بالاسم MariaDB.

تم تطوير قاعدةَ بيانات MariaDB من طرف نفس مطوري MySQL في عام 2009، وكان الهدف هو الحفاظ على ميزات MySQL نفسها مع إضافة ميزات جديدة أيضًا.

تنمو الآن MariaDB و MySQL كل على حدة، ولكل منهما ميزاتها وفوائدها الرئيسية.

الميزات والفوائد الرئيسية

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

ميزات وفوائد MariaDB

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

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

تتضمن بعض ميزات MariaDB الميزة MCS لتحليل البيانات وميزة MaxScale للمحافظة على سير الأمور وموازنة العمل وميزة Galera Cluster لنسخ البيانات بدقة.

ميزات وفوائد MySQL

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

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

مقارنة بين MariaDB و MySQL

هناك العديد من الاختلافات الرئيسية بين MySQL و MariaDB بالرغم من وجود بنية ووظائف متشابهة كما هو موضح في الجدول التالي:

المقارنة بين معايير قياس الأداء

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

يوضح الرسم البياني التالي عدد العمليات التي يمكن إجراؤها في الثانية OPS لأربعة إصدارات مختلفة من قواعد البيانات (MariaDB 10.0.21 و MariaDB 10.0.18 و MySQL 5.6.27 و MySQL 5.7.9) عند إجراء عمليات قراءة بسيطة مع أعداد مختلفة من المستخدمين من 1 إلى 256. يُظهِر الرسم البياني التالي أن الإصدار MySQL 5.7.9 أفضل من الإصدارات الأخرى دائمًا، مما يعني أن الإصدارات الأحدث أفضل.

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

تُعَد هذه المقارنة مهمةً لفهم الاختلافات في السرعة وكمية العمل التي يمكن لكل إصدار التعامل معها بين MariaDB وMySQL، مما يساعدنا في اتخاذ خيارات مناسبة لترقية قاعدة بياناتنا وإعدادها الصحيح، ولكن يمكن أن تختلف خصائص الأداء المحددة وفقًا لعوامل مثل العتاد وحِمل العمل والضبط.

التعامل مع أحمال العمل ذات حركة المرور العالية

يمكن ضبط كل من MariaDB و MySQL وتحسينهما للتعامل مع متطلبات التطبيقات ذات الطلب الكبير عند التعامل مع أحمال العمل ذات حركة المرور العالية، حيث تشمل العوامل الرئيسية التي يجب مراعاتها ما يلي:

المقارنة من حيث محركات التخزين

يؤثر اختيار محرّك التخزين تأثيرًا كبيرًا على أداء قاعدة البيانات ووظائفها، حيث تدعم كل من MariaDB و MySQL محرّكات متعددة، ولكن MariaDB تقدم مجموعةً أوسع من الخيارات، بما في ذلك XtraDB و ColumnStore، مما يوسّع إمكاناتها إلى ما هو أبعد من InnoDB و MyISAM وغيرها من محرّكات MySQL.

تدعم MariaDB أيضًا كلًا من Blackhole و CSV و Aria و InnoDB و Archive و Connect و Cassandra Storage Engine، والعديد من المحرّكات الأخرى؛ بينما تتضمن محركات التخزين التي تدعمها MySQL أيضًا MyISAM و Merge و Federated و Archive و Memory و CSV و Blackhole و Example.

ملاحظة: لا يهم عدد محركات التخزين التي تدعمها قاعدة البيانات، فالمهم هو استخدام قاعدة البيانات التي تدعم المحرّك المناسب للمتطلبات.

المقارنة من حيث تحسين الاستعلامات

تتضمن كل من MariaDB و MySQL ميزات تحسين الاستعلام لتحسين الأداء وتقليل استهلاك الموارد، إذ يمكن أن تساعد هذه الميزات في ضمان تنفيذ الاستعلامات بكفاءة وتجنب الأعباء غير الضرورية.

تتضمن بعض تقنيات تحسين الاستعلامات الشائعة ما يلي:

المقارنة من حيث البحث عن نص كامل

يمكن لكل من MariaDB و MySQL البحث عن كلمات كاملة في النص، ويُعَد ذلك مفيدًا لأشياء مثل محركات البحث وأنظمة إدارة المستندات والمتاجر الإلكترونية.

قد تختلف طريقة البحث عن الكلمات الكاملة التي تستخدمها MariaDB و MySQL بعض الشيء في كيفية عملها ومدى سرعتها، لذا يُفضَّل التحقق من احتياجات تطبيقنا ومقارنة كيفية بحث كلتا قاعدتي البيانات عن الكلمات الكاملة.

دعم JSON

تدعم كل من MariaDB و MySQL تنسيق JSON وتنفذان العديد من الدوال نفسها، ولكن تخزّن MySQL تقارير JSON ككائنات ثنائية، بينما تخزنها MariaDB كسلاسل نصية.

تظهر MySQL و MariaDB اختلافات في إمكاناتهما على التعامل مع JSON بالرغم من ارتباطهما الوثيق، حيث تفتخر MariaDB بمجموعة أوسع من دوال JSON بما في ذلك JSON_QUERY و JSON_EXISTS، والتي تفتقر MySQL إليها؛ ولكن MySQL تقدم الدالة JSON_TABLE لهيكلة بيانات JSON ضمن جدول، والتي هي ميزة غير موجودة في MariaDB.

التوافق مع Oracle

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

قد تجد المؤسسات ذات الاستثمار الأكبر في نظام أوراكل البيئي أن قاعدة بيانات MySQL بديل جذاب بسبب وضع التوافق مع أوراكل، ولكن يُعَد دعم MySQL للغة PL/SQL الخاصة بأوراكل محدودًا. تُعَد قاعدة بيانات MariaDB خيارًا أفضل، إذ يمكنها العمل مع صيغة أوراكل ولديها دعم كامل للغة PL/SQL، ويكون ذلك مناسبًا للشركات التي تريد التحول من أوراكل مع الاحتفاظ بشيفرتها البرمجية القديمة واستخدام ميزات إجرائية متقدمة.

ميزات الأمان

تحمي كلٌّ من MySQL و MariaDB البيانات من خلال التحقق من هوية المستخدمين واستخدام التشفير، ولكنهما تطبّقان التشفير بطريقة مختلفة، إذ تتيح MySQL إمكانية اختيار كيفية تشفير سجلات الإعادة والتراجع، ولكنها لا تحمي مساحات الجدول المؤقتة أو السجلات الثنائية. وتحتوي MariaDB على مزيدٍ من الخيارات للتشفير بما في ذلك حماية السجلات الثنائية والجداول المؤقتة، مما يجعل البيانات أكثر أمانًا.

تستخدم MySQL و MariaDB أيضًا طرقًا مختلفةً للتحقق من هوية المستخدمين، إذ تحتوي MySQL على validate_password للتأكد من قوة كلمات المرور، وتحتوي MariaDB على مزيد من الخيارات مع إضافات مختلفة للتحقق من صحة البيانات. يُعَد أمان كلمة المرور أفضل في MariaDB باستخدام إضافة الاستيثاق ed25519 في الإصدار 10.4، والتي تُعَد أكثر أمانًا من طريقة SHA-1 القديمة، مما يعني أن MariaDB ملتزمة بأن تكون آمنة جدًا.

تجمع الخيوط Thread Pooling

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

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

التراخيص والقيود

تستخدم كل من MariaDB و MySQL ترخيص جنو العمومي General Public License -أو GPL اختصارًا، لكنهما يتبعان خطط ترخيص مختلفة. تُعَد MariaDB مرخصةً بالكامل بموجب ترخيص GPL، مما يعني أنها ستكون مجانيةً ومفتوحة المصدر دائمًا، ويُعَد ذلك مهمًا للمستخدمين الذين يقدّرون أهمية مجانية البرمجيات.

تُعَد MySQL مُرخصَّة بترخيص مزدوج، فهي تحتوي على إصدار ترخيص GPL عام وإصدار تجاري خاص؛ إذ يحتوي الإصدار التجاري على مزيد من الميزات والدعم مثل تجمّع الخيوط، كما قد يؤدي ذلك إلى جعلها أسرع، ولكنه يمنع المستخدمين من تغيير الشيفرة البرمجية.

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

اختيار قاعدة البيانات الصحيحة

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

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

حالات استخدام MariaDB و MySQL

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

استخدام MariaDB مع WordPress

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

من ناحية أخرى، يمكن لقاعدة بيانات MariaDB التعامل مع عدد أكبر من الاتصالات والمعاملات مقارنةً بقاعدة بيانات MySQL.

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

استخدام MariaDB مع موقع Cloudways

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

ملاحظة: لا يمكن تخفيض إصدار MariaDB مرةً أخرى بعد الترقية إلى الإصدار الأعلى.

الخلاصة

بهذا نكون قد وضحنا ميزات MariaDB و MySQL الرئيسية لإظهار الاختلاف بينهما لتسهيل المفاضلة بين قاعدة بيانات MariaDB أو MySQL.

ترجمة -وبتصرّف- للقسم MariaDB vs MySQL: Understanding Key Differences and Choosing the Right Database لصاحبته Hafsa Tahir.

اقرأ أيضًا

• كيفية استيراد وتصدير قواعد بيانات MySQL أو MariaDB
• كيفية تأمين قواعد البيانات MySQL ,MariaDB على خواديم لينكس
• كيفية تغيير مجلد تخزين بيانات MariaDB إلى مكانٍ آخر
• تعلم أساسيات MySQL
• كيفية ربط قاعدة بيانات MariaDB بتطبيق لارافيل Laravel

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

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

لذا سنعرض بهذا المقال بعضًا من أبرز ميزات صدفة Fish.

1. تمييز الصيغة لونيا

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

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

2. الاقتراحات التلقائية

توفّر صدفة Fish اقتراحات للأوامر أثناء كتابتنا لها، ويمكننا تطبيقها بكل سهولة باستخدام مفتاح Tab كما يتضح بهذا الشكل بنسخة SVG.

ستظهر الاقتراحات بلون باهت أثناء الكتابة لتسهيل آلية الاستفادة منها، وفي حال كان سطر الاقتراح مناسبًا بالكامل، فيمكننا الضغط على مفتاح السهم الأيمن لاستكماله تلقائيًا.

3. صفحة المساعدة التفاعلية لخيارات الأوامر

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

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

fish_update_completions

إذ سيُحلّل هذا الأمر محتوى صفحات المساعدة.

وبذلك وعند كتابة أمر معين، ما علينا سوى وضع إشارة الشرِطة (-) لإضافة الخيارات ثم الضغط على مفتاح Tab، وستظهر اقتراحات كما هو واضح هنا من صفحة المساعدة للخيارات المُتاحة للأمر مع توصيف مختصر لكل منها.

يمكننا التمرير عبر الخيارات وقراءة وصفها ضمن أداة عرض النصوص التفاعلية pager التي تظهر، ثم اختيار المناسب منها بناءً على وظيفته.

تُسهّل هذه الميزة العمل مقارنةً بحالة استخدام أمر من قبيل command -h.

4. استخدام الاختصارات بدلًا من الأسماء البديلة

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

فعلى سبيل المثال، سنعين فيما يلي المقطع sch كاختصار للأمر pacman -Ss المُتعلّق بالبحث عن الحزم:

abbr -a sch pacman -Ss

وبذلك في كل مرة نكتب فيها sch ونضغط على مفتاح المسافة، سيتم استبداله تلقائيًا بالأمر pacman -Ss.

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

ملاحظة: يكمن الفرق بين الأسماء البديلة والاختصارات في كون الاسم البديل يعمل في الخلفية دون أن يظهر الأمر الفعلي الذي يشير إليه; أمّا الاختصار, فيُظهر الأوامر الفعلية، كما تُسجّل بشكلها الصحيح في سجل الأوامر.

5. مساعدة شاملة قائمة على الويب

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

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

help

وسيؤدي ذلك إلى فتح صفحة المساعدة في متصفح الويب.

ومنها يُمكن الرجوع إلى التوثيق الشامل بكل سهولة.

6. الإعدادات المعتمدة على الويب

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

يمكن كتابة الأمر التالي أثناء تشغيل صدفة Fish:

fish_config

وسيؤدي ذلك إلى فتح صفحة الإعدادات كواجهة رسومية ضمن متصفح الويب.

يمكننا من خلال هذه الصفحة تغيير الألوان، أو اختيار موجّه مختلف من الخيارات المُتاحة وضبط غيرها من التعديلات.

7. الانتقال التلقائي إلى المجلدات كبديل عن الأمر CD

لسنا بحاجة إلى كتابة الأمر cd إذا أردنا الانتقال إلى مجلد معيّن، إذ يكفي كتابة اسم المجلد، وهذا كل ما في الأمر!

فعلى سبيل المثال، إذا كنا في المجلد Home ورغبنا بالانتقال إلى المجلد الفرعي Downloads، فيكفي أن نكتب كلمة Downloads، كما ستعرض الصدفة اقتراحات للإكمال التلقائي أثناء الكتابة.

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

8. تنقل أسهل بين المسارات

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

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

9. البحث التفاعلي في السجل

يمكننا البحث عن أمر معيّن في سجل الأوامر على نحوٍ تفاعليّ في صدفة Fish، وللقيام بذلك نستخدم الاختصار المعروف وهو مفتاح CTRL مع حرف R.

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

10. المتغيرات العمومية

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

ولإنشاء متغير عمومي، سنستخدم الأمر التاليك

set -U my_variable 10

ستُحفظ قيمة المتغير my_variable لتكون 10، وستبقى محفوظةً حتى بعد إعادة تشغيل النظام.

ولا حاجة لإضافتها إلى ملف تهيئة بيئة الصدفة RC أو ملف التكوين الشخصي Profile.

11. الوضع الخاص

توفّر صدفة Fish وضعًا خاصًا، وفيه لا تُحفظ الأوامر التي نُدخلها في سجل الأوامر ولا تُخزّن على القرص.

وللانتقال إلى الوضع الخاص، نستخدم الأمر التالي:

fish -P

وبمجرد الانتهاء من العمل، يمكننا الخروج من الوضع الخاص بكتابة الأمر:

exit

الخلاصة

لا يُعدّ ما قدمناه في هذا المقال إلّا غيضًا من فيض لاستكشافه في صدفة Fish، إذ توفّر صدفة Fish العديد من الميزات التي تُسهّل الاستخدام، من قبيل:

• تحرير الأوامر مُتعدّدة الأسطر بسهولة بالضغط على مفتاح ALT مع مفتاح ENTER
• التبديل بين أنماط اختصارات لوحة المفاتيح الخاصّة بمحرّريّ النصوص Emacs (الافتراضي) وVim
• صيغة بسيطة وواضحة لكتابة النصوص البرمجية

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

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

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

ننصحكم بتجربة صدفة Fish ومراقبة سير الأمور، فربما ستجعلونها صدفتكم الافتراضية!

ترجمة -وبتصرف- للمقال 11 Fish Shell Features That Make it More Awesome Than Bash لصاحبيه Abhishek Prakash وSreenath.

اقرأ أيضًا

• مدخل إلى صدفة باش Bash
• أساسيات استخدام صدفة psql
• قراءة وضبط متغيرات الصدفة Shell والبيئة في لينكس

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

مقدمة عن منهجية DevOps وخطوط التكامل والتسليم المستمر CI/CD

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

هناك بعض الأدوات الضرورية لتحقيق بيئة DevOps، لكن المفتاح الرئيسي هو إنشاء منهجية عمل Pipeline يُطبّق فيها التكامل المستمر والنشر المستمر CI/CD، بحيث تحتوي على مراحل مختلفة مثل مرحلة التطوير DEV، والتكامل INT، والاختبار TST، والتحقق من الجودة QA، واختبار قبول المستخدم UAT، والتحضير STG، والانتاج PROD؛ وتؤتمت فيها المهام اليدوية، لكي يستطيع المطورون العمل بمرونة وكتابة شيفرة عالية الجودة، والنشر مرات عديدة.

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

1. استخدام اُطر عمل التكامل والنشر المستمر CI/CD

أول ما نحتاج إليه هو إحدى أدوات التكامل والنشر المستمر CI/CD، ويُنصح لهذا الغرض باستخدام أداة جنكينز Jenkins، وهي أداة مفتوحة المصدر ومبنية على لغة جافا Java وترخيص MIT، وهي ما ساهم في نشر منهجية DevOps لتصبح المعيار الأساسي.

ولتبسيط الأمر، يمكننا تخيل أن أداة Jenkins هي جهاز تحكم عن بعد يمكنه التخاطب مع خدمات وأدوات عدة المختلفة وإدارتها، وهي عديمة النفع بمفردها، ولكنها تصير أكثر قوةً عند استخدامها مع أدوات وخدمات مختلفة. وهي واحدة من العديد من أدوات CI/CD مفتوحة المصدر التي يمكن الاستفادة منها لإنشاء منهجية عمل DevOps.

فيما يلي بعض الأدوات الأخرى:

توضح الصورة التالية سير عمليات DevOps باستخدام أدوات التكامل والنشر المستمر CI/CD:

وبهذا تكون قد أصبحت لدينا أداة CI/CD قيد التشغيل في مضيفنا المحلي، ولكن لا يمكن الاستفادة منها في شيء الآن. سنتابع شرح باقي الخطوات كي نتعلم كيفية استخدام الأدوات لبناء منهجية عمل DevOps.

2. إدارة الشيفرة المصدرية Source Code Management

إن أفضل وأسهل طريقة للتأكد من أن أدوات CI/CD تعمل جيدًا هي استخدامها مع إحدى أدوات إدارة الشفرة المصدرية Source Code Management أو اختصارًا: SCM، وذلك لأن الشيفرة التي نكتبها عند تطوير تطبيق ما باستخدام إحدى لغات البرمجة مثل لغة جافا Java أو بايثون Python أو C++‎ أو لغة جو Go، أو جافاسكربت Javascript، أو غيرها، يطلق عليها اسم الشيفرة المصدرية Source Code.

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

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

ثمة أدوات عدة لإدارة الشيفرة المصدرية، لكن غيت Git أفضلها، وفيما يلي ذكر لأدوات أخرى مفتوحة المصدر:

توضح الصورة الآتية كيف تبدو منهجية عمل DevOps عند استخدام إحدى أدوات إدارة الشيفرة المصدرية SCM:

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

3. إنشاء أداة لأتمتة عمليات بناء الشيفرة

يمكن الآن الإطلاع على تعديلات الشيفرة وإضافة تعديلاتنا، كما يمكن التعاون مع مطورين آخرين في كتابة الشيفرة. للتأكيد، يجب علينا تجميع التطبيق قبل ذلك ووضعه في تنسيق حزمة قابلة للنشر أو تشغيله كملف قابل للتنفيذ Executable لجعله تطبيق ويب. يمكننا ملاحظة أن لغات البرمجة المُفسَّرة مثل جافاسكربت JavaScript أو PHP لا تحتاج إلى تجميع Compilation، وهنا علينا استخدام إحدى أدوات أتمتة عمليات بناء البرامج Build Automation Tool، والتي تهدف إلى إنشاء شيفرة مصدرية بتنسيق معين، وأتمتة عمليات تنظيف الشيفرة وتجميعها واختبارها ونشرها في موقع معين.

تختلف أدوات البناء وفقًا للغة البرمجة، وفيما يلي بعض الأدوات الشائعة مفتوحة المصدر:

يمكننا الآن إضافة ملفات إعدادات أداة أتمتة بناء الشيفرة إلى أداة إدارة الشيفرة المصدرية SCM وستتولى أداة التكامل والنشر المستمر CI/CD أمر بنائها.

4. اختيار خادم تطبيقات الويب

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

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

بعد تحديد خادم الويب المناسب، نستطيع القول أنه قد أصبحت لدينا منهجية عمل DevOps شبه مُعَدّة للاستخدام.

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

5. اختبار تغطية الشيفرة Code Testing Coverage

قد يكون اختبار الشيفرة أمرًا مرهقًا ولكنه ضروري ويجب إجراؤه باكرًا لاكتشاف الأخطاء ورفع جودة الشيفرة وضمان رضا العملاء؛ ولكن توجد أدوات عدة مفتوحة المصدر لاختبار الشيفرة وتحسين جودتها, ويمكن توصيل معظم أدوات التكامل والنشر المستمر CI/CD مع أدوات الاختبار وأتمتة العملية.

أُطُر اختبار الشيفرة البرمجية Code Test Frameworks

هناك نوعان من أدوات اختبار الشيفرة، هما:

1. أُطُر اختبار الشيفرة البرمجية Code test framework: وتساعد في كتابة الاختبارات وتشغيلها
2. أدوات تحسين الجودة Code Quality Suggestion Tools: وتقدم اقتراحات تساعد على تحسين جودة الشيفرة البرمجية

في الآتي جدول مكون من أهم أُطُر الاختبار:

أما عن أدوات تحسين الجودة Code Quality Suggestion Tools، فيمكن ذكر الأدوات الآتية:

وكما نلاحظ، معظم الأدوات والأطر التي ذكرناها مكتوبة بلغة جافا، أو بايثون، أو جافا سكربت؛ أما لغتا C++‎ وC#‎ فهما من لغات البرمجة الخاصة Proprietary لكن المُترجِم المستخدم لترجمتهما GCC مفتوح المصدر.

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

خطوات إضافية لتحسين المنهجية

سنوضح فيما يلي بعض الخطوات الإضافية التي يمكن القيام بها لتحسين منهجية عمل DevOps الخاصة بنا.

استخدام الحاويات Containers

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

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

توجد خيارات مختلفة للحاويات، لكن دوكر Docker وكوبرنيتس Kubernetes هما الأكثر شيوعًا.

أدوات الأتمتة الوسيطة Middleware automation tools

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

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

وفيما يلي بعض أدوات الأتمتة الوسيطة مفتوحة المصدر:

الخلاصة

تعلّمنا في هذا المقال كيفية إنشاء منهجية عمل لإنتاج البرمجيات بأسلوب DevOps باستخدام أدوات مفتوحة المصدر، وتعرفنا على أشهر أدوات التكامل والنشر المستمر CI/CD مفتوحة المصدر وأدوات إدارة الشيفرة المصدرية واختبارها، ويمكنك من الآن بدء تجربة إنشاء منهجية DevOps لمشروعك البرمجي الحقيقي.

ترجمة، وبتصرّف، للمقال A beginner's guide to building DevOps pipelines with open source tools لكاتبه Bryant Son.

اقرأ أيضًا

• دليل المبتدئين في مجال DevOps وأهم ممارساته وأدواته
• المدخل الشامل لتعلم DevOps
• ما هي الغاية من DevOps؟
• أفضل 5 لغات برمجة لـ DevOps

أَحدَثَت مشاريع الحوسبة السحابية الأصيلة Cloud-native Computing تغييرًا كبيرًا في طريقة بناء التطبيقات ونشرها، ووفرت وسائل متنوعة تُسَهِّل العمل، بدايةً من أدوات التكامل Integrating وتحزيم Packaging شيفرة التطبيق تمهيدًا لنشره، ووصولًا إلى أدوات التوسعة Scaling وغير ذلك.

تندرج هذه الأعمال جميعها تحت مظلة DevOps وتُعدّ الحاويات في عصرنا الحالي أشهر مفاهيم DevOps الحديث وأكثرها تأثيرًا، وسنعرض في مقالنا هذا مثالًا عمليًّا عن نشر تطبيق ريآكت React بمساعدة الحاويات؛ إذ سننشئ صورة دوكر Docker للتطبيق ثم نرفعها إلى سجل الحاويات Container Registry وننشرها باستخدام خادم Droplet من منصة DigitalOcean.

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

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

• إنشاء حساب على منصة DigitalOcean.
• تثبيت كل من دوكر Docker ومدير الحزم npm على جهازننا
• تشغيل خادم Droplet على DigitalOcean
• إعداد سجل الحاويات على DigitalOcean

تثبيت Docker

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

docker --version
Docker version 26.0.0, build 2ae903e

إنشاء تطبيق ريآكت

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

npm create vite@latest react-app -- --template react

سيُنشئ هذا الأمر تطبيقًا تجريبيًّا ضمن المجلد react-app، وبعدها يمكن الانتقال للمجلد وتشغيل التطبيق بواسطة الأوامر التالية:

cd react-app
npm install
npm run dev

وعند الانتهاء من التشغيل سنحصل على رسالة شبيهة بالتالي:

OutputVITE v5.2.11  ready in 712 ms
➜  Local:   http://localhost:5173/
➜  Network: use --host to expose
➜  press h + enter to show help

يمكن الآن فتح التطبيق من المتصفح بكتابة العنوان localhost:5173 كما يلي:

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

إنشاء الملف Dockerfile

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

تُنشَئ صور دوكر باستخدام ملف خاص يدعى Dockerfile يتضمن التعليمات البرمجية اللازمة لبناء الصورة؛ إذ تتكون الصورة image من عدة طبقات layers للقراءة فقط. وعند إضافة أي تعليمة إلى الملف Dockerfile، تُضَاف طبقة جديدة إلى الصورة.

تُخَزَّن هذه الطبقات بهيئة قيم مُعَمَّاة hash من نوع SHA-256، ويمكن معرفة المزيد عن بنية صور الحاويات بمطالعة مقال ما هي صورة الحاوية container image؟

إذًا تُبنى صور دوكر بإنشاء الملف Dockerfile ويشمل ذلك خطوتين أساسيتين:

• بناء التطبيق
• إعداد خادم nginx وتشغيله لخدمة التطبيق

تنويه: ستُكتَب جميع التعليمات التي ننفذها في هاتين الخطوتين ضمن الملف Dockerfile.

1. بناء التطبيق

سنوجه Docker في البداية ليستخدم أحدث نسخة من Node.js لتكون الركيزة التي سيبني عليها تطبيق React وفق التالي:

FROM node:latest AS builder

بعد ذلك سنحَدِّد مجلد العمل WORKDIR الذي ستُنَفَّذ فيه جميع التعليمات اللاحقة، والذي سيكتمل فيه تطبيقنا:

WORKDIR /app

سننسخ بعدها الملف package.json إلى الحاوية builder ونشَغِّل npm install لتثبيت جميع الاعتماديات المطلوبة في الملف package.json وبذلك نضمن أن تطبيق React يمتلك كل ما يحتاجه ليعمل بصورة سليمة:

COPY package.json .
RUN npm install

والآن. يمكن نسخ بقية ملفات المشروع إلى الحاوية وتشغيل npm run build لتصريف compile التطبيق وفق الأمر التالي الذي سيُحَوِّل الشيفرة المصدرية لتطبيقنا إلى حزمة bundle جاهزة لبيئة الإنتاج ومُخَزَّنة في المجلد /dist ومُضبوطة لتعمل بكفاءة وأداء جيد:

COPY . ./
RUN npm run build

2. إعداد خادم nginx للتطبيق وتشغيله

يشتهر NGINX بالكفاءة والسرعة، لذا يُعدّ خيارًا مناسبًا للاستخدام كخادم ويب لتطبيقنا حتى يصله بالمستخدمين، وسنعتمد لبنائه أحدث صورة nginx متوفرة؛ ثم نستبدل ملف الإعدادات الافتراضي الذي يأتي مع الصورة default.conf بملف إعدادات مشروعنا ليتمكن خادم nginx من تلبية طلبات المستخدمين الواردة إلى التطبيق.

وذلك وفق الأوامر التالية:

FROM nginx:latest
RUN rm -rf /etc/nginx/conf.d/default.conf
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf

سننسخ بعد ذلك تطبيق ريآكت الذي حوّلناه إلى حزمة في الخطوة السابقة، وذلك من المجلد dist في الحاوية builder إلى المجلد الذي يتوقع nginx أن يجد ملفات تطبيقنا فيه، ليستطيع خدمة المستخدمين، وذلك وفق الأمر التالي:

COPY --from=builder /app/dist /usr/share/nginx/html

سنضبط بعد ذلك قيمة مجلد العمل WORKDIR داخل حاوية nginx ليشير إلى مجلد التطبيق:

WORKDIR /usr/share/nginx/html

ثم نشَغِّل خادم nginx بواسطة الأمر التالي، الذي يوجه Docker لبدء تشغيله والحفاظ عليه في حالة عمل:

CMD ["/bin/bash", "-c", "nginx -g "daemon off;""]

إذا جمعنا كل التعليمات السابقة معًا، فستشكل الملف Dockerfile:

# ------------------------
# Step 1: Build react app
# ------------------------

# Use node:latest as the builder image
FROM node:latest AS builder

# Set the working directory
WORKDIR /app

# Copy package.json and install app dependencies
COPY package.json .
RUN npm install

# Copy other project files and build
COPY . ./
RUN npm run build

# --------------------------------------
# Step 2: Set up nginx to serve the app
# --------------------------------------
# Use nginx:latest as the base image
FROM nginx:latest

# Overwriting nginx config with our own config file
RUN rm -rf /etc/nginx/conf.d/default.conf
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf

# Copy over the build created in the Step 1
COPY --from=builder /app/dist /usr/share/nginx/html

# Set the working directory
WORKDIR /usr/share/nginx/html

# Start nginx server
CMD ["/bin/bash", "-c", "nginx -g \"daemon off;\""]

لذا سننشئ ملفًا نصيًّا باسم Dockerfile ضمن المجلد الجذر لتطبيقنا كما يلي:

touch Dockerfile

مع نسخ التعليمات السابقة ضمنه.

إنشاء ملف إعدادات NGINX

ذكرنا في الخطوة السابقة الخاصة بإعداد خادم NGINX أننا سنستبدل ملف الإعدادات الافتراضي للخادم بملف إعدادات مشروعنا، فكيف ننشئ ملف إعدادات المشروع؟

سنتوجه في البداية إلى مجلد الجذر لتطبيقنا ثم ننشئ بداخله مجلدًا جديدًا باسم nginx، وننشئ بداخله ملفًا نصيًّا يدعى default.conf كما يلي:

mkdir nginx
cd nginx && touch default.conf

ثم ننسخ الإعدادات التالية والصقها ضمنه:

server {
  listen 80;
  add_header Cache-Control no-cache;
  location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
    try_files $uri $uri/ /index.html;
    expires -1;
  }
  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
    root   /usr/share/nginx/html;
  }
}

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

بناء صورة التطبيق image

سنستخدم هننا تعليمة cd للعودة إلى مجلد الجذر لتطبيقنا حيث يوجد الملف Dockerfile، ثم ننفِّذ الأمر التالي:

docker image build -t react-app:v1.0 . --platform linux/amd64

تتميز كل صورة دوكر عن غيرها باسم name ووسم tag خاصين بها يُكتَبان بعد الراية t-؛ فالصورة في مثالنا تدعى react-app، ولها الوسم v1.0؛ أما الراية platform-- فتساعدنا على تحديد المنصة التي تُبنى الصور من أجلها، وتُعَدُّ خيارًا مهمًا في الحالات التي نحتاج فيها لبناء صورة متعددة المنصات cross-platform حتى تُحَِّدد الأنظمة التي ستتوافق معها.

سنحصل على نتيجة تشبه التالي بعد الانتهاء من بناء الصورة:

[+] Building 113.9s (17/17) FINISHED
=> [internal] load build definition from Dockerfile
=> => transferring dockerfile: 982B
...
...
=> => writing image sha256:d125b102b094224c82ddb69f9ece98c7161c8660fe72fd5aec57e41a6d72cf2f
=> => naming to docker.io/library/react-app:v1.0

يمكن استخدام الأمر التالي الذي يعرض صور دوكر الموجودة لتتحقق من صحة بناء الصورة:

docker image list

وسنحصل على النتيجة التالية:

OutputREPOSITORY   TAG   IMAGE ID       CREATED         SIZE
react-app    v1.0  d125b102b094   6 minutes ago   188MB

وكما نلاحظ، فصورة التطبيق التي بنيناها ضمن قائمة الصور الموجودة.

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

لننتقل الآن إلى الخطوة التالية وهي تخزين الصورة في مكان مركزي يُسَهِّل توزيعها ونشرها، وهنا يأتي دور سجل الحاويات Container Registry.

رفع صورة التطبيق إلى سجل الحاويات

سجل الحاويات Container Registry هو مخزون مركزي من صور الحاويات، يمكن رفع صورنا إليه وسحبها منه عندما نحتاجها من أي مكان وفي أي وقت، وذلك بعدة طرق. إما محليًّا، أو عبر عنقود Kubernetes، أو عبر خطوط أنابيب CI/CD، أو غير ذلك.

لنبدأ الآن خطوات رفع push الصورة react-app إلى السجل.

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

يمكننا البدء إذًا بإعداد سجل الحاويات المجاني free-tier registry، واختيار أحد مواقع مراكز البيانات في المنطقة، مع تسمية السجل باسم مناسب مثل my-container-registry، كما هو الحال في الصورة التالية:

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

سنحتاج الآن لمفتاح الواجهة البرمجية API للاتصال بالسجل، لذا سنتوجه إلى تبويب tokens من الصفحة الرئيسية لحسابنا على المنصة وننشئ مفتاحًا جديدًا خاصًا بنا كما هو الحال في الصورة التالية:

سنملأ الآن النموذج الظاهر أمامنا بعد الضغط على زر إنشاء رمز جديد Generate New Token ونفَعِّل خيار التحكم الكامل Full Access طالما أنه لن يكون هناك أكثر من مستخدم وحيد للرمز، إذ لا توجد أي مخاطر أمنية.

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

والآن يمكننا تسجيل الدخول إلى سجل الحاويات باستخدام بيانات حسابنا، وذلك عبر كتابة الأمر التالي في الطرفية terminal:

docker login registry.digitalocean.com

سيُطلب منا عندها إدخال اسم المستخدم وكلمة المرور:

OutputUsername: ravish.foo@bar.com
Password:
Login Succeeded

وبإدخالهما تكتمل عملية تسجيل الدخول ويمكن رفع صورة تطبيقنا إلى السجل؛ ويجري ذلك بخطوتين، أولاهما عبر وسم tag الصورة بوسم خاص للرفع كما يلي:

docker tag react-app:v1.0 registry.digitalocean.com/my-container-registry/react-app

وثانيهما رفع الصورة إلى السجل كما يلي:

docker push registry.digitalocean.com/my-container-registry/react-app

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

OutputUsing default tag: latest
The push refers to repository [registry.digitalocean.com/my-container-registry/react-app]
5f70bf18a086: Pushed
fafde3127bc5: Pushed
155c640ab606: Pushed
993afd9f06ad: Pushed
9fd54926bcae: Pushed
175aa66db4cc: Pushed
e6380a7057a5: Pushed
1db2242fc1fa: Pushed
b09347a1aec6: Pushed
bbde741e108b: Pushed
52ec5a4316fa: Pushed
latest: digest: sha256:227a8c3ede3fc5c81b281228600bec84939f8a4a0cc770fc6e5527b3261e77f4 size: 2608

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

يمكننا ملاحظة أن الصورة react-app التي رفعناها إلى السجل تحمل الوسم الافتراضي latest لأننا لم نعطها وسمًا خاصًا عند الرفع، فأي صورة تُرفع للسجل دون وسم تُمنح افتراضيًا الوسم latest، ويمكن بالتأكيد تغيير هذا الوسم إلى أي وسم آخر تريده بواسطة خاصية الإصدار Versioning.

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

بهذا نكون انتهينا من بناء صورة التطبيق وأصبحت جاهزة على سجل الحاويات، كل ما علينا الآن تشغيل خادم Droplet لنشر deploy الحاوية باستخدام هذه الصورة.

تشغيل خادم Droplet

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

عمليًّا، ستكفينا الخطة ذات 6$ لبناء خادم Droplet مناسب لنشر الحاوية، وسيساعدنا هذا الدليل على إتمام العملية؛ إذ سنختار في البداية نظام التشغيل وليكن أوبنتو، وعند اكتمال تشغيل الخادم سيظهر أمامنا في لوحة تحكم حسابنا كما في الصورة التالية:

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

يمكن الآن فتح جلسة اتصال ssh مع الخادم كما يلي، وذلك باستخدام عنوان IP المخصص له وكلمة المرور لحساب الجذر root التي تُطلب منا أثناء إعداد الخادم:

ssh root@143.244.130.234
root@143.244.130.234's password:

يمكن أيضًا اختيار عدم المطالبة بكلمة مرور عند الاتصال مع الخادم ببروتوكول ssh إذا أردنا ذلك.

ستظهر أمامنا رسالة الترحيب التالية بمجرد نجاح الاتصال:

Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-9-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Mon Apr 29 08:07:53 UTC 2024

  System load:  0.32              Processes:             106
  Usage of /:   9.3% of 23.17GB   Users logged in:       0
  Memory usage: 40%               IPv4 address for eth0: 143.244.130.234
  Swap usage:   0%                IPv4 address for eth0: 10.47.0.5

47 updates can be applied immediately.
To see these additional updates run: apt list --upgradable

*** System restart required ***
Last login: Mon Apr 29 08:07:55 2024 from 198.211.111.194
root@ubuntu-s-1vcpu-1gb-blr1-01:~#

وبهذا صرنا متصلين بالخادم ويمكننا تنفيذ التعليمات عليه.

سحب صورة التطبيق من سجل الحاويات

من المهم في البداية التأكد من وجود Docker ضمن الخادم، وذلك بكتابة الأمر التالي:

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker --version
Docker version 24.0.5, build ced0996

وإذا لم يكن موجودًا يمكننا تثبيته باستخدام الأمر التالي:

root@ubuntu-s-1vcpu-1gb-blr1-01:~# snap install docker

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

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker login registry.digitalocean.com
Username: ravish.foo@bar.com
Password:
Login Succeeded

بعد ذلك نستطيع سحب pull صورة التطبيق من السجل كما يلي:

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker pull registry.digitalocean.com/my-container-registry/react-app

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

OutputUsing default tag: latest
latest: Pulling from my-container-registry/react-app
b0a0cf830b12: Already exists
8ddb1e6cdf34: Already exists
5252b206aac2: Already exists
988b92d96970: Already exists
7102627a7a6e: Already exists
93295add984d: Already exists
ebde0aa1d1aa: Already exists
6156e0586e61: Already exists
88bdf71f3911: Pull complete
f5524cce8c8a: Pull complete
4f4fb700ef54: Pull complete
Digest: sha256:227a8c3ede3fc5c81b281228600bec84939f8a4a0cc770fc6e5527b3261e77f4
Status: Downloaded newer image for registry.digitalocean.com/my-container-registry/react-app:latest
registry.digitalocean.com/my-container-registry/react-app:latest

وكما نلاحظ، فالأمر السابق قد سَحَبَ الصورة ذات الوسم latest أي الصورة الأحدث، لأننا لم نُحَدِّد أي وسم آخر في أمر السحب، وفي مثل هذه الحالة يسحب docker الصورة latest تلقائيًا.

تشغيل الحاوية

لدينا الآن صورة عن أحدث إصدار من التطبيق تشمل كل الاعتماديات اللازمة لعمله، ويمكننا تشغيل الحاوية بواسطتها وفق الأمر التالي:

docker run -dp 80:80 registry.digitalocean.com/my-container-registry/react-app

وكتوضيح للشيفرة أعلاه، تجعل الراية d- الحاوية تعمل في الخلفية، وتصل الراية p 80:80 البوابة 80 في الخادم المضيف بالبوابة 80 في الحاوية لتتجه حركة مرور البيانات الواردة للخادم إلى بوابة الحاوية.

البوابة 80 هي البوابة المعيارية لحركة البيانات وفق البروتوكول HTTP وقد ضبطنا الخادم nginx ليستقبل الطلبات عبرها.

سننفِّذ الآن الأمر التالي للتأكد من أن الحاوية قيد التشغيل:

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker ps -a

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

يمكننا تجربة ذلك عبر كتابة عنوان IP لخادم Droplet في متصفحنا وستفتح أمامنا واجهة تطبيق React:

يمكننا إيقاف تشغيل الحاوية بواسطة الأمر:

docker stop <container_id>

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

docker rm <container_id>

الخلاصة

يمكن الانطلاق مما تعلمناه هنا وتطوير آلية نشر تطبيقاتنا عبر أتمتة عمليات بناء النسخ ورفعها إلى سجل الحاويات وسحبها منه؛ حيث يمكن مثلًا كتابة سكريبت Bash يتكامل مع GitHub فيبني تلقائيًا صورة جديدة لتطبيقنا ويرفعها إلى سجل الحاويات مع كل عملية إيداع commit تنفذها على التطبيق، كما نستطيع إنشاء خط أنابيب للنشر المستمر والتسليم المستمر CI/CD يؤتمت عملية سحب الصور من السجل ونشرها على السحابة، فضلًا عن إمكانية استخدام عناقيد Kubernetes في عمليات النشر واسعة النطاق، والتي تتيح لنا إمكانية إدارة مجموعة كاملة من الحاويات بدلًا واحدة.

ترجمة -وبتصرف- لمقال How to deploy your React app using Container Registry لصاحبيه Ravish Ahmad Khan و Anish Singh Walia.

اقرأ أيضًا

• مدخل إلى الحاويات
• مدخل إلى دوكر Docker
• التعامل مع حاويات Docker
• أساسيات تنسيق الحاويات

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

سنلقي الضوء في مقالنا هذا على مفهوم تخصص DevOps وأهميته، ونستعرض أساليبه، وأطر عمله، وأدواته.

ما هو تخصص DevOps

لا يوجد تعريف واحد لمصطلح DevOps، لكن يمكن أن نعُدّه إطار عمل يضمن التعاون بين فرق التطوير Development المسؤولة عن كتابة الشيفرة البرمجية للتطبيق، وفرق العمليات Operations المسؤولة عن نشر الشيفرات والبرامج في بيئات الإنتاج بسرعة وبطريقة مؤتمتة Automated وقابلة للتكرار أي يمكن تشغيلها عدة مرات دون مشكلات.

ومصطلح DevOps هو دمج لكلمتي تطوير Development وعمليات Operations. وهو تقنية مهمة جدًا تساعد على زيادة سرعة تسليم التطبيقات والخدمات، وتتيح للمؤسسات خدمة عملائها بكفاءة أعلى، وتزيد قدرتها على المنافسة في السوق.

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

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

التحديات التي يواجهها فريق التطوير

يكون المطورون متحمسين عادةً ومستعدين لتبني أساليب وتقنيات جديدة لحل المشكلات، لكنهم قد يواجهون التحديات التالية:

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

التحديات التي يواجهها فريق العمليات

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

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

كيف تعالج منهجية DevOps تحديات فريقي التطوير والعمليات

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

ولتحقيق هذه الأهداف يجب على الشركات تحقيق التالي:

• تقليل احتمالية فشل الإصدارات الجديدة بجعل كل تحديث أصغر وأسهل في الاختبار
• زيادة وتيرة النشر عن طريق إطلاق نسخ محدثة بوتيرة أسرع وبشكل منتظم
• تقصير وقت التعافي MTTR في حال حدوث خلل بعد نشر إصدار جديد، لتعود الخدمة لطبيعتها بسرعة
• تسريع وقت التسليم Lead Time، أي تقليل المدة بين اكتشاف المشكلة وإطلاق الإصلاح الخاص بها

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

يهتم نهج DevOps بمعالجة مجموعة متنوعة من المشكلات التي تنتج عن المنهجيات السابقة، بما في ذلك:

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

مقارنة بين منهجية أجايل Agile و DevOps وتقنية Waterfall التقليدية

تُقارَن DevOps مع المنهجيات الأخرى في مجال تقنية المعلومات، ولا سيّما منهجيّتي أجايل Agile والشلال Waterfall.

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

والآن لنقارن بين منهجية الشلال أو تدفق المياه Waterfall التقليدية ومنهجية DevOps لفهم الفوائد التي تقدمها DevOps. سنفترض أن لدينا السيناريو التالي:

لدينا تطبيق سيُشغَّل بعد أربعة أسابيع، واكتملت عملية كتابة الشيفرة بنسبة 85%، وبدأت عملية شراء الخوادم التي ستُرفع الشيفرة البرمجية عليها.

يوضّح الجدول التالي الفروقات بين تطبيق المنهجيتين في هذه الحالة:

دورة حياة المشاريع في DevOps

سنستعرض فيما يلي بعض الممارسات الشائعة في منهجية DevOps.

التخطيط المستمر Continuous Planning

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

التطوير التعاوني Collaborative Development

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

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

الاختبار المستمر Continuous Testing

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

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

الإصدار المستمر Continuous Release والنشر المستمر Continuous Deployment

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

تلعب الأتمتة دورًا رئيسيًا في ضمان إصدار البرنامج بتكرار وموثوقية؛ إذ إن أحد الأهداف الرئيسية هو أتمتة العمليات اليدوية مثل عملية بناء التطبيقات والانحدار Regression والنشر وتوفير البنية التحتية.

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

المراقبة المستمرة Continuous Monitoring

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

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

المراجعة والتقييم والتحسين Optimization

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

فوائد تطبيق منهجية DevOps في بيئة العمل

يؤمّن تطبيق منهجية DevOps بيئة عمل يتعاون فيها فريق التطوير وفريق إدارة البرمجيات ويعملان كفريق واحد لتحقيق أهداف مشتركة. ويتميز ذلك بتنفيذ التكامل المستمر والتسليم المستمر CI/CD، مما يتيح إصدار البرامج بسرعة وأخطاء أقل ويعود علينا بجملة من الفوائد تشمل:

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

مبادئ DevOps

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

ومن أهم هذه المبادئ نذكر:

1. التطوير والاختبار في بيئة شبيهة ببيئة الإنتاج

الهدف من هذا المبدأ هو السماح لفرق التطوير وفرق ضمان الجودة Quality Assurance -أو اختصارًا QA- بتطوير البرمجيات واختبارها في بيئات قريبة من بيئات الإنتاج Production Systems، كي يعاينوا أداء التطبيقات قبل أن تصبح جاهزة للنشر.

يجب أن يتعرض التطبيق لأنظمة شبيهة بالإنتاج في وقت مبكر قدر الإمكان من دورة حياته لمعالجة الأمور التالية:

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

2. النشر باستخدام عمليات موثوقة وقابلة للتكرار

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

3. مراقبة الجودة التشغيلية Operational Quality

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

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

4. جمع تقييمات وآراء موسعة حول التطبيق

إن أحد أهداف عمليات DevOps هو تمكين المؤسسات من التفاعل وإجراء التغييرات بسرعة أكبر. يتطلب تحقيق هذا الهدف في مجال تسليم البرمجيات جمع تقييمات وآراء Feedback مبكرة، ومن ثم التعلم بسرعة من كل إجراء.

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

قائمة بأهم أدوات DevOps

من أهم أدوات DevOps مفتوحة المصدر في مجال تطوير البرمجيات وإدارة العمليات نذكر الآتي:

أهم أدوات عملية التطوير Development

• مرحلة التخطيط: أداة Kanboard وWekan وأنا وGitLab وTuleap و Redmine وبدائل جيرا JIRA مثل Mattermost و Roit.im و IRC.
• مرحلة كتابة الشيفرة: غيت Git و Gerrit و Bugzilla و جينكينز Jenkins.
• مرحلة بناء التطبيق: Apache Maven و Gradle و Apache Ant و Packer
• مرحلة الاختبار: JUnit و Cucumbe و Selenium و Apache JMeter

أهم أدوات عملية إدارة العمليات Operations

• مرحلة الإصدار والنشر والتشغيل: Kubernetes و Nomad و جينكينز Jenkins و Zuul و Spinnaker و Ansible و Apache ZooKeeper و etcd و Netflix Archaius و Terrafo
• مرحلة المراقبة: Prometheus و Nagios و InfluxDB و Fluentd وكما هو موضح، فقد دمجنا مرحلة التشغيل الأخيرة مع مرحلتي الإصدار والنشر بسبب تشابه أدواتها.

الخاتمة

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

ترجمة، وبتصرّف، للمقال A beginner's guide to everything DevOps لكاتبه Sameer S Paradkar.

اقرأ أيضًا

• المدخل الشامل لتعلم DevOps
• كيفية تحقيق نهج DevSecOps بنجاح
• دليلك الشامل عن النشر المستمر Continuous Delivery
• دليل المبتدئين لمنهجية أجايل Agile
• ما هو إطار عمل تطوير البرمجيات المرن Lean Software Development

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

• البرمجيات كخدمات سحابية 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

نشرح في هذه المقالة طريقة التعامل مع نظام إدارة قواعد البيانات MongoDB الذي يمتاز بكونه نظام غير علاقي وموجه نحو المستندات document-oriented، أي أنه يخزن البيانات في هيئة مستندات، ومثله مثل بقية أنظمة إدارة قواعد البيانات فهو يتعامل مع البيانات عبر أربع عمليات أساسية نسميها اختصارًا عمليات CRUD تشمل:

• عمليات الإنشاء Create أي كتابة بيانات جديدة لقاعدة البيانات
• عمليات القراءة Read‎ وهي عمليات الاستعلام التي نحصل بواسطتها على البيانات المخزنة
• عمليات التحديث Update وتعني العمليات التي تسبب تغييرًا في البيانات الموجودة ضمن قاعدة البيانات
• عمليات الحذف Delete وهي العمليات التي تؤدي إلى إزالة البيانات نهائيًا من قاعدة البيانات

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

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

لمتابعة سير العمل في هذا المقال يتوجب امتلاك معرفة أساسية بكيفية استخدام واجهة أوامر Mongodb المعروفة باسم Mongodb Shell وتنفيذ أوامر قاعدة البيانات.كما يجب توفّر خادم يعمل بنظام Ubuntu يحتوي على مستخدم عادي غير الجذر يمتلك صلاحيات sudo، مع تفعيل جدار الحماية الافتراضي UFW على الخادم، ويجب تثبيت MongoDB على الخادم، وتأمين قاعدة البيانات بإنشاء مستخدم إداري administrative user على قاعدة البيانات لديه صلاحية مسؤول وتفعيل المصادقة authentication في قاعدة البيانات لأنها تكون مُعطلة تلقائيًا. يمكن الاستعانة بمقال كيفية تثبيت وتأمين MongoDB على أوبونتو فهو يتضمن كل الخطوات اللازمة.

الاتصال بخادم MongoDB

قبل البدء بتنفيذ عمليات CRUD على البيانات، علينا الاتصال بقاعدة بيانات MongoDB عبر الصدفة MongoDB Shell. فإذا كان خادم MongoDB الذي نعمل عليه مبني على خادم بعيد وليس على جهازنا المحلي، نفتح جلسة SSH للاتصال به كما يلي:

$ ssh sammy@your_server_ip

ولمطالعة المزيد من المعلومات حول SSH ننصح بمشاهدة الفيديو التالي:

بعدها نتصل بتطبيق MongoDB المُثَبَّت على الخادم بواسطة مستخدم يتمتع بصلاحيات القراءة والكتابة على البيانات،  وسيكون أمر الاتصال بالصيغة التالية:

$ mongo -u AdminSammy -p --authenticationDatabase admin

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

ملاحظة: بمجرد إنشاء اتصال جديد مع خادم MongoDB سيصلنا تلقائيًا بقاعدة البيانات الاختبارية لنظام MongoDB تدعى test، ويمكن الانتقال إلى قاعدة بياناتنا الخاصة باستخدام الأمر use متبوعًا باسم قاعدة البيانات كما في المثال التالي:

use database_name

والآن بعد أن جهزنا الاتصال بخادم MongoDB، يمكننا البدء بالعملية الأولى من عمليات CRUD وهي Create لإنشاء مستندات جديدة.

إنشاء المستندات

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

ستكون المستندات التي تتضمن معلومات عن أهرامات الجيزة The Pyramids of Giza مثلًا وفق الصيغة التالية:

{
    "name": "The Pyramids of Giza",
    "city": "Giza",
    "country": "Egypt",
    "gps": {
        "lat": 29.976480,
        "lng": 31.131302
    }
}

تُكتب مستندات MongoDB وتعالج بصيغة BSON، وهي تمثيل ثنائي لملفات JSON سهل القراءة والفهم ويوفر بعض الإضافات التي تسمح بتخزين أنواع بيانات إضافية لا تدعمها صيغة JSON. تُمثَّل البيانات الموجودة في هذه المستندات بهيئة أزواج حقل وقيمة field: value.

يتضمن المستند الذي أنشأناه أربعة حقول يشير الحقل الأول إلى اسم المعلم الأثري، يليه المدينة في الحقل الثاني، والبلد في الحقل الثالث، وتحتوي هذه الحقول الثلاثة على سلاسل نصية strings، أما الحقل الأخير والمسمى gps، فهو مستند متداخل nested document أي مستند داخل مستند يعرض معلومات عن الموقع الجغرافي للمكان الأثري ويتضمن إحداثيات خطوط الطول والعرض يمثلها الحقلان lat و lng والقيم ضمنهما من نوع  عدد عشري.

تنتمي المستندات في MongoDB دائمًا إلى مجموعات collections، وهي تكافئ الجداول tables في قواعد البيانات العلاقية مثل MySQL أما المستندات في MongoDB فهي تشبه الصفوف rows ضمن كل جدول 

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

لنكتب إذًا أمر الإنشاء التالي في نافذة الصدفة:

> db.monuments.insertOne(
> {
>  "name": "The Pyramids of Giza",
>  "city": "Giza",
>  "country": "Egypt",
>  "gps": {
>  "lat": 29.976480,
>  "lng": 31.131302
>   }
>  }
> )

نلاحظ هنا أننا لم ننشئ المجموعة monuments مُسبقًا قبل إدراج المستندات ضمنها، فنظام MongoDB مرن من هذه الناحية فالمجموعة ستنشأ تلقائيًا مع إدراج أول مستند فيها، وبذلك فإن التابع insertOne()‎ لم يُنشئ المستند فحسب بل أنشأ المجموعة أيضًا.

سنحصل على الخرج التالي الذي يعلمنا بنجاح تنفيذ التابع insertOne()‎ وإنشاء المستند المطلوب، بالإضافة إلى إرجاع مُعَرّف الكائن ObjectId الخاص به والذي ينشأ تلقائيًا لكل كائن أو مستند جديد:

{
  "acknowledged" : true,
  "insertedId" : ObjectId("6105752352e6d1ebb7072647")
}

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

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

> db.monuments.count()

سيُرجع التابع count القيمة 1 لأننا أدخلنا مستندًا واحدًا فقط في المجموعة:

1

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

> db.monuments.insertMany([
>    {"name": "The Valley of the Kings", "city": "Luxor", "country": "Egypt", "gps": { "lat": 25.746424, "lng": 32.605309 }},
>    {"name": "Arc de Triomphe", "city": "Paris", "country": "France", "gps": { "lat": 48.873756, "lng": 2.294946 }},
>    {"name": "The Eiffel Tower", "city": "Paris", "country": "France", "gps": { "lat": 48.858093, "lng": 2.294694 }},
>    {"name": "Acropolis", "city": "Athens", "country": "Greece", "gps": { "lat": 37.970833, "lng": 23.726110 }},
>    {"name": "The Great Wall of China", "city": "Huairou", "country": "China", "gps": { "lat": 40.431908, "lng": 116.570374 }},
>    {"name": "The Statue of Liberty", "city": "New York", "country": "USA", "gps": { "lat": 40.689247, "lng": -74.044502 }}
> ])

تُحيط الأقواس المربعة [] بالمستندات الستة في المثال أعلاه، فهي تشكل مصفوفة من العناصر، ويفصل بين كل عنصر وآخر فاصلة , فعندما نريد تمرير عدة كائنات في MongoDB أيًّا كان نوعها نمررها بشكل مصفوفة بين قوسين مربعين.

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

{
  "acknowledged" : true,
  "insertedIds" : [
    ObjectId("6105770952e6d1ebb7072648"),
    ObjectId("6105770952e6d1ebb7072649"),
    ObjectId("6105770952e6d1ebb707264a"),
    ObjectId("6105770952e6d1ebb707264b"),
    ObjectId("6105770952e6d1ebb707264c"),
    ObjectId("6105770952e6d1ebb707264d")
  ]
}

لنتأكد من صحة أمر إنشاء المستندات الجديدة بالاستعلام عن عدد المستندات في المجموعة monuments:

> db.monuments.count()

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

7

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

قراءة المستندات

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

لنبدأ بقراءة المستندات السبعة من المجموعة monuments بعملية واحد باستخدام التابع ()find:

> db.monuments.find()

يؤدي استخدام التابع ()find بدون وسطاء إلى إرجاع جميع البيانات الموجودة في المجموعة المحددة وهي في حالتنا المجموعة monuments وسنحصل بالتالي على هذا الخرج:

{ "_id" : ObjectId("6105752352e6d1ebb7072647"), "name" : "The Pyramids of Giza", "city" : "Giza", "country" : "Egypt", "gps" : { "lat" : 29.97648, "lng" : 31.131302 } }
{ "_id" : ObjectId("6105770952e6d1ebb7072648"), "name" : "The Valley of the Kings", "city" : "Luxor", "country" : "Egypt", "gps" : { "lat" : 25.746424, "lng" : 32.605309 } }
{ "_id" : ObjectId("6105770952e6d1ebb7072649"), "name" : "Arc de Triomphe", "city" : "Paris", "country" : "France", "gps" : { "lat" : 48.873756, "lng" : 2.294946 } }
{ "_id" : ObjectId("6105770952e6d1ebb707264a"), "name" : "The Eiffel Tower", "city" : "Paris", "country" : "France", "gps" : { "lat" : 48.858093, "lng" : 2.294694 } }
{ "_id" : ObjectId("6105770952e6d1ebb707264b"), "name" : "Acropolis", "city" : "Athens", "country" : "Greece", "gps" : { "lat" : 37.970833, "lng" : 23.72611 } }
{ "_id" : ObjectId("6105770952e6d1ebb707264c"), "name" : "The Great Wall of China", "city" : "Huairou", "country" : "China", "gps" : { "lat" : 40.431908, "lng" : 116.570374 } }
{ "_id" : ObjectId("6105770952e6d1ebb707264d"), "name" : "The Statue of Liberty", "city" : "New York", "country" : "USA", "gps" : { "lat" : 40.689247, "lng" : -74.044502 } }

تعرض الصدفة MongoDB Shell المستندات السبعة بكامل حقولها، ونلاحظ أن لكل حقل مُعَرّف خاص id_ رغم أننا لم نُعَرِّفه عند إنشاء المستندات، وذلك لأن MongoDB كما ذكرنا تُنشئ المُعرفات تلقائيًا مع أوامر الإدخال وهي تعمل كمفاتيح رئيسية للمستندات الخاصة بها.

نلاحظ أيضًا أن طريقة عرض البيانات ضمن الصدفة MongoDB Shell صعب القراءة نوعًا ما، وخاصة إذا كانت المستندات كثيرة الحقول أو تتضمن مستندات متداخلة فالمستند الواحد سيظهر بجميع بياناته بسطر واحد، ويمكن تحسين الإظهار وجعله أسهل في القراءة باستخدام الخاصية ()pretty مع التابع ()find كما يلي:

> db.monuments.find().pretty()

الآن ستعرض الصدفة MongoDB Shell الخرج بالطريقة التالية، حيث تفرد لكل مستند عدة أسطر يبدأ كل منها بمسافة بادئة indentation:

{
  "_id" : ObjectId("6105752352e6d1ebb7072647"),
  "name" : "The Pyramids of Giza",
  "city" : "Giza",
  "country" : "Egypt",
  "gps" : {
    "lat" : 29.97648,
    "lng" : 31.131302
  }
}
{
  "_id" : ObjectId("6105770952e6d1ebb7072648"),
  "name" : "The Valley of the Kings",
  "city" : "Luxor",
  "country" : "Egypt",
  "gps" : {
    "lat" : 25.746424,
    "lng" : 32.605309
  }
}
. . .

لنستخدم بعض الوسطاء مع التابع ()find لتضييق نتائج البحث فمثالنا السابق أرجع كافة مستندات المجموعة من دون أي تصفية.

ذكرنا سابقًا أن MongoDB تعطي مُعَرِّفًا فريدًا لكل مستند، لنأخذ مثلًا المستند المُسمى "The Valley of the Kings" والذي يشير لأحد المعالم الأثرية في مجموعتنا وله المُعرِّف ‎ObjectId("6105770952e6d1ebb7072648")‎ الذي يميزه عن غيره، علمًا أن مُعرِّف الكائن ObjectId ليس من مجرد سلسلة ست عشرية فهو بحد ذاته كائن أيضًا وهو نوع خاص من البيانات تستخدمه MonogoDB لتخزين مُعَرِّفات الكائنات،  ويمكن مطالعة المزيد عن أنواع البيانات التي تتعامل معها MongoDB.

سُنمَرِّر الآن هذا المُعَرِّف كوسيط للتابع ()find بهيئة مستند يسمى مستند تصفية الاستعلام query filter document، تتمتع مستندات تصفية الاستعلام بنفس بنية مستندات مجموعة البيانات أي بنية حقل وقيمة لكنها تستخدم لغرض خاص هو تصفية نتائج الاستعلام.

يتضمن مستند تصفية الاستعلام في حالتنا الحقل id_ والقيمة التي تمثل Objectid للمستند "The Valley of the Kings"، وسيأخذ الاستعلام عندها الصيغة التالية:

> db.monuments.find({"_id": ObjectId("6105770952e6d1ebb7072648")}).pretty()

يستخدم مستند تصفية الاستعلام في هذا المثال شرط المساواة لإرجاع النتائج، فستُرجع ()find المستند الذي يطابق معرفه id_ القيمة ‎ObjectId("6105770952e6d1ebb7072648")‎ فقط ولن تُرجع معه أي مستند آخر.

سنحصل في هذه الحالة على الخرج التالي:

{
  "_id" : ObjectId("6105770952e6d1ebb7072648"),
  "name" : "The Valley of the Kings",
  "city" : "Luxor",
  "country" : "Egypt",
  "gps" : {
    "lat" : 25.746424,
    "lng" : 32.605309
  }
}

لنجرب مثالًا آخر، سنستعلم هنا عن جميع المعالم الأثرية الموجودة في فرنسا أي التي تحقق الشرط التالي:

> db.monuments.find({"country": "France"}).pretty()

سيُرجع هذا الاستعلام نتيجتين كما يلي:

{
  "_id" : ObjectId("6105770952e6d1ebb7072649"),
  "name" : "Arc de Triomphe",
  "city" : "Paris",
  "country" : "France",
  "gps" : {
    "lat" : 48.873756,
    "lng" : 2.294946
  }
}
{
  "_id" : ObjectId("6105770952e6d1ebb707264a"),
  "name" : "The Eiffel Tower",
  "city" : "Paris",
  "country" : "France",
  "gps" : {
    "lat" : 48.858093,
    "lng" : 2.294694
  }
}

الخطوة 4: تحديث المستندات

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

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

تستخدم MongoDB آلية مستند تصفية الاستعلام query filter document نفسها التي استخدمناها في الفقرة السابقة، وذلك للسماح للمستخدم بتحديد المستندات التي يود تحديثها.

يبين المثال التالي طريقة تغيير اسم أحد المعالم الأثرية وليكن مثلًا قوس النصر Arc de Triomphe حيث سنغير اسمه إلى Arc de Triomphe de l’Étoile، باستخدام التابع ()updateOne المخصص لتحديث مستند واحد فقط في كل عملية:

> db.monuments.updateOne(
>   { "name": "Arc de Triomphe" },
>   {
>     $set: { "name": "Arc de Triomphe de l'Étoile" }
>   }
> )

سيكون اسم المستند الذي نرغب بتعديله هو الوسيط الأول للتابع ()updateOne وهو في حالتنا { "name": "Arc de Triomphe" } وهو مستند تصفية استعلام مع شرط المساواة، وبالتالي سيُرجع لنا المستند الذي يطابق اسمه تمامًا القيمة المذكورة، وسيكون هو المستند الذي ننفذ عليه التعديل.

أما الوسيط الثاني فهو مستند التحديث update document الذي يتضمن التحديثات التي ينبغي أن تُطَبَّق عند تنفيذ التابع، يتكون مستند التحديث من عوامل تحديث operators تلعب دور المفاتيح keys، ومعاملات parameters مقابلة تمثل القيم الجديدة values. في حالتنا عامل التحديث هو set$ وهو المسؤول عن إعطاء قيم جديدة لحقول المستند التي تُكتب بصيغة كائنات JSON مثل { "name": "Arc de Triomphe de l'Étoile" } الذي يعني ضمنًا تعديل قيمة الحقل name لتصبح Arc de Triomphe de l'Étoile.

يُرجع تابع التحديث ()updateOne خرجًا يخبرنا بنتيجة عمله، فقد عثر على مستند واحد مطابق للشروط، وحَدَّث قيمته بنجاح، كما يلي:

{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }

تنويه: قد لا يكون مستند تصفية الاستعلام المستخدم كوسيط أول للتابع ()updateOne مُحَددًا ودقيقًا بما يكفي لإعطائنا نتيجة واحدة فيُرجِع عدة مستندات تتوافق مع شروط الاستعلام بدلًا من واحد، في هذه الحالة سيأخذ التابع ()updateOne أول مستند من هذه المستندات ويطَبِّق التعديلات عليه ويهمل البقية لأنه في نهاية الأمر مُخصص للعمل مع مستند واحد.

لنتأكد الآن من نجاح عملية التحديث، سنطلب جميع المعالم الأثرية الموجودة في فرنسا France وفق الآتي:

> db.monuments.find({"country": "France"}).pretty()

يؤكد لنا الخرج التالي تغيير طريقة كتابة Arc de Triomphe وبالتالي نجاح عملية التحديث:

{
  "_id" : ObjectId("6105770952e6d1ebb7072649"),
  "name" : "Arc de Triomphe de l'Étoile",
  "city" : "Paris",
  "country" : "France",
  "gps" : {
    "lat" : 48.873756,
    "lng" : 2.294946
  }
}
. . .

سنستعمل الآن التابع ()updateMany لتعديل أكثر من مستند في نفس الوقت.

لنفترض مثلًا أننا نريد إضافة حقل إلى كل مستند من مستندات المجموعة، يبين هذا الحقل اسم المُحرِّر editor الذي أدخل بيانات المعلم الأثري. طالما أننا سنُنَفِّذ التعديل على جميع المستندات في المجموعة، فسنستخدم إذًا مستند تصفية استعلام فارغ بلا أي شروط وبسببه سيؤثر ()updateMany على جميع مستندات المجموعة monuments ويُضيف إلى كل واحد منها حقلًا جديدًا يدعى editor ويحمل القيمة Sammy وفق التالي:

> db.monuments.updateMany(
>   { },
>   {
>    $set: { "editor": "Sammy" }
>   }
> )

سيعطي هذا التابع الخرج التالي الذي يعلمنا بنتيجة التنفيذ:

{ "acknowledged" : true, "matchedCount" : 7, "modifiedCount" : 7 }

عثرنا على سبعة مستندات مطابقة للشروط، وعَدَّلنا المستندات السبعة بنجاح.

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

> db.monuments.find().pretty()

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

{
  "_id" : ObjectId("6105752352e6d1ebb7072647"),
  "name" : "The Pyramids of Giza",
  "city" : "Giza",
  "country" : "Egypt",
  "gps" : {
    "lat" : 29.97648,
    "lng" : 31.131302
  },
  "editor" : "Sammy"
}
{
  "_id" : ObjectId("6105770952e6d1ebb7072648"),
  "name" : "The Valley of the Kings",
  "city" : "Luxor",
  "country" : "Egypt",
  "gps" : {
    "lat" : 25.746424,
    "lng" : 32.605309
  },
  "editor" : "Sammy"

}
. . .

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

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

حذف المستندات

إذا احتجنا لحذف بعض البيانات القديمة من قاعدة بيانات MongoDB فيمكن استخدام تابعين للحذف الأول هو التابع ()deleteOne لحذف مستند واحد من المستندات المطابقة لشروط مستند تصفية الاستعلام، والثاني هو التابع ()deleteMany لحذف عدة مستندات دفعة واحدة.

لنحاول حذف المستند الخاص بقوس النصر Arc de Triomphe de l’Étoile الذي عَدَّلنا اسمه قبل قليل، وذلك وفق الأمر التالي:

> db.monuments.deleteOne(
>     { "name": "Arc de Triomphe de l'Étoile" }
> )

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

نحصل بعد التنفيذ على خرج يشبه التالي:

{ "acknowledged" : true, "deletedCount" : 1 }

يبين هذا الخرج عدد المستندات المحذوفة بموجب الأمر السابق.

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

> db.monuments.find({"country": "France"}).pretty() 

ستتضمن نتيجة الاستعلام المستند الخاص ببرج إيفل The Eiffel Tower فقط لأننا حذفنا مستند قوس النصر Arc de Triomphe de l’Étoile:

{
  "_id" : ObjectId("6105770952e6d1ebb707264a"),
  "name" : "The Eiffel Tower",
  "city" : "Paris",
  "country" : "France",
  "gps" : {
    "lat" : 48.858093,
    "lng" : 2.294694
  },
  "editor" : "Sammy"
}

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

> db.monuments.deleteMany(
>  { "editor": "Sammy" }
> )

سيعلمنا الخرج بحذف ستة مستندات:

{ "acknowledged" : true, "deletedCount" : 6 }

ويمكن التأكد من النتيجة بالاستعلام عن عدد مستندات المجموعة monuments كما يلي:

> db.monuments.count()

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

0

تعني النتيجة 0 حذف جميع المستندات في المجموعة.

الخاتمة

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

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

ترجمة -وبتصرف- لمقال How To Perform CRUD Operations in MongoDB لصاحبه Mateusz Papiernik.

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

استخدام مفاتيح SSH

SSH هي اختصار لعبارة Secure Shell، وهو بروتوكول آمن ومُشفر للاتصال بالخوادم وإدارتها، وهو شائع الاستخدام فأي شخص يتعامل مع الخوادم سيقضي معظم وقته متصلًا بالخادم عبر جلسة اتصال طرفية terminal تستخدم برتوكول SSH، أما مفاتيح SSH أو SSH Keys فهي بديل آمن لعمليات تسجيل الدخول المستندة إلى كلمة مرور أي تلك التي تعتمد الاستيثاق بكلمة المرور، لأن هذه المفاتيح تستخدم التشفير لتأمين تسجيل الدخول إلى الخادم، وتُعَدُّ إجراءً ضروريًا يوصى به لجميع مستخدمي SSH.

لإجراء الاستيثاق authentication من خلال مفاتيح SSH نحتاج لتوليد مفتاحين، مفتاح عام public key مكن مشاركته مع الطرف الآخر، ومفتاح خاص private key سري يحتفظ به المستخدم ولا يشاركه مع أحد، تُسمى هذه الآلية التشفير غير المتماثل asymmetric encryption وقد تصادفنا في حالات استخدام أخرى.

بعد توليد مفتاح SSH العام ينبغي لنا وضعه على الخادم ضمن المسار المخصص له وهو عادةً المجلد ‎~/.ssh/authorized_keys، وبعدها يمكننا الاتصال بالخادم باستخدام مفاتيح SSH، ومعرفة المزيد عن الاستيثاق باستخدام كلمة المرور والاستيثاق باستخدام المفاتيح ننصح بمشاهدة الفيديو التالي:

كيف تعزز مفاتيح SSH أمان الاتصال مع الخادم

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

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

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

تنفيذ الاستيثاق بمفاتيح SSH على الخادم

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

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

من ناحية أخرى يُعدّ عدم السماح لمستخدم الجذر root بتسجيل الدخول مباشرةً عبر SSH واحدًا من أفضل الممارسات الأمنية الموصى بها، وذلك طبقًا لمبدأ إعطاء الامتيازات الأقل فبدلاً من المستخدم root نسجل الدخول بمستخدم عادي لا يملك امتيازات عالية، ثم نرفع امتيازاته حسب الحاجة بواسطة أداة مثل sudo، ويمكن تطبيق ذلك كما يلي: بعد التأكد من الاتصال بالخادم وإنشاء حساب لا يتمتع بامتيازات عالية لكنه قادر على العمل مع SSH، يمكن تعطيل عمليات تسجيل الدخول بواسطة مستخدم الجذر عبر تعديل قيمة السطر الخاص بذلك ضمن الملف ‎/etc/ssh/sshd_config على الخادم ليصبح PermitRootLogin no ثم نعيد تشغيل SSH باستخدام أمر مثل Sudo systemctl Restart sshd ليأخذ التعديل مفعوله.

الجدران النارية Firewalls

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

تُصَنَّف الخدمات الموجودة على أي خادم تقليدي إلى الفئات التالية:

• خدمات عامة Public متاحة لأي شخص عبر الإنترنت مثل خوادم الويب
• خدمات خاصة Private محصورة بالاتصالات من مواقع محددة أو حسابات مصرح لها بالوصول مثل لوحات تحكم قواعد البيانات
• خدمات داخلية Internal غير متاحة للعامة وتقبل الاتصالات المحلية فقط، مثل قواعد البيانات المحلية

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

كيف يحمي الجدار الناري التطبيقات

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

ويتحكم الجدار الناري المُعَدّ بطريقة سليمة بإمكانية الوصول إلى مكونات النظام الخاص بنا حسب طبيعة العمل، فلا يتيح الوصول لكل الخدمات والاتصالات على الخادم، بل يسمح بالوصول إلى خدمات معينة ويمنع الوصول إلى سواها، وذلك عبر فتح المنافذ ports الخاصة بها وإغلاق بقية المنافذ، مثلًا يمكن فتح المنفذ 22 لبروتوكول الاتصال SSH، والمنفذين 80 و 443 لخدمات الويب HTTP/HTTPS التي تعمل من المتصفح وغيرها، عمومًا كلما اختصرنا عدد المنافذ أو الخدمات المفتوحة كلما قللنا من الثغرات الأمنية التي يمكن أن يستغلها المخترق ومن احتمالية تعرضنا للهجمات الإلكترونية.

تشغيل الجدار الناري على الخادم

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

تحتفظ العديد من الجدران النارية البرمجية مثل UFW و firewalld بقواعدها rules ضمن ملف خاص يدعى iptables، ويمكن مطالعة المزيد عن هذا الموضوع بقراءة مقال كيفية إعداد جدار ناري باستخدام IPTables على Ubuntu 14.04، ومقال أساسيات IPTables - قواعد وأوامر شائعة للجدار الناري، إذ يساعد فهم iptables على التعامل مع حالات التعارض التي قد تنشأ من تسجيل بعض البرمجيات مثل Docker قواعدها الأمنية الخاصة بالتحكم بمنافذ الخادم ضمن الملف iptables إلى جوانب قواعد UFW المُسجلَّة فيه أيضًا.

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

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

شبكات السحابة الافتراضية الخاصة VPC Networks

شبكات السحابة الافتراضية الخاصة Virtual Private Cloud -أو VPC اختصارًا- ههي شبكات مخصصة لربط موارد البنية التحتية في السحابة، وتوفر اتصالًا آمنًا ومعزولًا عن الإنترنت العام.

كيف تعزز شبكات VPC أمان نظامنا

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

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

تطبيق شبكات VPC

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

شبكات VPN والشبكات الخاصة

الشبكة الافتراضية الخاصة virtual private network -أو  VPN اختصارًا- هي وسيلة لإنشاء اتصالات آمنة بين الحواسيب البعيدة تكافئ الاتصالات ضمن شبكة محلية خاصة local private network، يساعدك ذلك على إعداد خدماتك كما لو أنها في شبكة خاصة وأيضًا على الاتصال مع خوادمنا البعيدة بطريقة آمنة.

كيف تحسِّن شبكات VPN أمان النظام

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

تنفيذ شبكات VPN عمليًا

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

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

تدقيق الخدمات ومراجعتها

يُعدّ تحليل الأنظمة المستخدمة وفهم ثغراتها واحتمالات الهجمات التي قد تتعرض لها من أهم تدابير الحماية التي تساعدك على تأمين الخودام وبقية مكونات النظام بأفضل طريقة ممكنة.

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

كيف يساهم تدقيق الخدمات ومراجعتها بتعزيز أمان الأنظمة؟

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

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

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

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

تنفيذ تدقيق الخدمات ومراجعتها

نستخدم الأمر ss لتدقيق خدمات الشبكة العاملة على نظامنا، إذ يعرض هذا الأمر كافة منافذ TCP و UDP المستخدمة على الخادم. لنلقِ نظرة على المثال التالي المتضمن استخدام هذا الأمر مع الخيارات الخاصة بإظهار اسم البرنامج، ورقم العملية PID، والعناوين الشبكية المستخدمة للاستماع أو لتلقي اتصالات TCP و UDP:

$ sudo ss -plunt

وهذه دلالة كل واحد من الخيارات p و l و u و n و t المستخدمة أعلاه:

• الخيار p مسؤول عن إظهار رقم العملية PID المقابل لكل مِقبس socket
• يعرض الخيار l المقابس الفعالة التي تستمع listening حاليًّا للاتصالات
• يعمل u على تضمين مقابس UDP في المعلومات المعروضة عن الخدمات بالإضافة إلى مقابس TCP
• يعرض n بيانات رقمية عن حركة مرور البيانات
• يعمل t على تضمين مقابس TCP في المعلومات المعروضة عن الخدمات بالإضافة إلى مقابس UDP

وستحصل بعد تنفيذ الأمر على خرج يشبه التالي:

Netid       State        Recv-Q       Send-Q             Local Address:Port             Peer Address:Port      Process
tcp         LISTEN       0            128                      0.0.0.0:22                    0.0.0.0:*         users:(("sshd",pid=812,fd=3))
tcp         LISTEN       0            511                      0.0.0.0:80                    0.0.0.0:*         users:(("nginx",pid=69226,fd=6),("nginx",pid=69225,fd=6))
tcp         LISTEN       0            128                         [::]:22                       [::]:*         users:(("sshd",pid=812,fd=4))
tcp         LISTEN       0            511                         [::]:80                       [::]:*         users:(("nginx",pid=69226,fd=7),("nginx",pid=69225,fd=7))

الأعمدة الرئيسية في الخرج السابق هي: Netid و Local Address:Port و Process وهي الأجدر بالاهتمام، فإذا كانت قيمة العمود Local Address:Port هي 0.0.0.0 فإن الخدمة ستستقبل الاتصالات الواردة إليها على جميع واجهات الشبكة IPv4، وإذا كانت قيمته [::] فستتلقى الخدمة الاتصالات على جميع واجهات الشبكة من نوع IPv6، إذا طبقنا ذلك على المثال أعلاه سنجد أن كل من SSH و Nginx يستقبلان الاتصالات على جميع الواجهات العامة وبكلا النوعين IPv4 و IPv6.

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

التحديثات التلقائية غير المراقبة

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

كيف تُحسّن التحديثات التلقائية أمان النظام

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

تنفيذ التحديثات غير التلقائية على الخادم

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

البنية التحتية للمفتاح العام والتشفير بواسطة SSL أو TLS

إن البنية التحتية للمفتاح العام Public key infrastructure -أو PKI اختصارًا- هي نظام مخصص لإنشاء وإدارة الشهادات certificates والتحقق من صحتها بهدف تحديد هويات الأفراد وتشفير الاتصالات بينهم. تُستخدم شهادات SSL أو TLS في البداية لإجراء الاستيثاق authentication بين مكونات النظام، ثم تُستخدم بعد ذلك لإنشاء اتصالات مشفرة بين هذه المكونات لضمان الأمان وحماية البيانات المتبادلة.

دور PKI في تحسين أمان الأنظمة

يساعد إنشاء سُلطَة تصديق الشهادات Certificate Authority -أو AC اختصارًا- في تحسين أمان النظام عن طريق السماح لكل خادم بالتحقق من هويات الخوادم الأخرى وتشفير البيانات المتبادلة معها. هذا يمنع هجمات الرجل في المنتصف man-in-the-middle حيث يحاول المهاجم انتحال شخصية خادم آخر لاعتراض البيانات. يُضبَط كل خادم ليثق في سُلطَة التصديق المركزية، وبالتالي يثق في الشهادات التي تصدرها هذه السُلطَة، مما يزيد الأمان ويحمي البيانات.

إعداد بنية تحتية للمفتاح العام PKI

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

الخلاصة

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

ترجمة -وبتصرف- لمقال Recommended Security Measures to Protect Your Servers لصاحبيه Justin Ellingwood و Alex Garnett.

اقرأ أيضًا

• الهجمات الأمنية Security Attacks في الشبكات الحاسوبية
• كيفية تأمين الخوادم السحابية ضد هجمات حقن SQL
• ما هو الأمن السيبراني وما أهميته؟
• مقدمة في تأمين خادم لينكس

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

يشمل مقالنا ثلاثة أقسام:

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

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

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

أفضل ممارسات إدارة التطبيقات

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

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

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

أما إذا كنا نشغل تطبيقًا خاصًا طورناه بنفسنا أو تطبيقًا ثبَّناه من مستودعات Git لا يتضمن ملف تمهيد للتكامل مع systemd، وسيصعب كتابة الملف يدويًّا ولن تكون نتائجه مضمونة، لذا يلجأ مدراء الأنظمة لاستخدام أدوات خاصة بإدارة التطبيقات مثل مدير العمليات supervisor لتوفير الوقت والجهد والاستغناء عن كتابة ملفات التمهيد يدويًا، كما يمكننا أيضًا استخدام جدولة المهام بواسطة cron مع الصيغة reboot@ لأتمتة العملية.

ويمكن إعادة التشغيل باستخدام الأمر Sudo Shutdown now -r الذي يوقف جميع العمليات العاملة ويعيد تشغيل النظام مباشرةً، كما يمكننا جدولة إعادة التشغيل لتجري في وقت لاحق في ساعة ودقيقة معينة hh:mm بدل إعادة التشغيل الفوري، علمًا أن جميع الخدمات ونقاط الوصول endpoints الضرورية في بيئة الإنتاج ينبغي أن تعود للعمل بعد أي انقطاع طارئ.

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

إعدادات الترقية التلقائية

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

يوفر أوبنتو أداة فريدة لتثبيت التصحيحات الأمنية patches والترقيات الأخرى غير المُراقبة التي لا تحتاج إلى تدخل بشري لإنجازها، تسمى unattended-upgrades وهي مثبتة تلقائيًا في معظم خوادم أوبنتو، ويمكن تثبيتها يدويًا باستخدام أوامر apt التالية:

$ sudo apt update
$ sudo apt install unattended-upgrades

يمكن التأكد من عمل الخدمة unattended-upgrades باستخدام systemctl كما يلي:

$ sudo systemctl status unattended-upgrades.service

إذا كانت الخدمة تعمل، سنحصل على خرج يشبه التالي:

unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-02-14 17:51:49 UTC; 3h 4min ago
       Docs: man:unattended-upgrade(8)
   Main PID: 829 (unattended-upgr)
      Tasks: 2 (limit: 1137)
     Memory: 10.6M
     CGroup: /system.slice/unattended-upgrades.service

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

تُخَزَّن إعدادات هذه الأداة في الملف ‎/etc/apt/apt.conf.d/50unattended-upgrades ويمكننا فتحه وتحريره بواسطة أي محرر نصوص مثل نانو nano أو غيره كما يلي:

$ sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

بمجرد فتح الملف، سنلاحظ أنه سهل القراءة ومشروح جيدًا، ويتضمن مجموعة من التعليقات التي تشرح التعليمات البرمجية ووظائفها، تتضمن كتلة التعليمات الأولى في الملف أسماء الحزم التي ستُحَدِّثها الأداة تلقائيًا ولها القالب العام لأسماء مستودعات حزم أوبنتو، وهي افتراضيًا ملفات المستودع المركزي core repository وملفات مستودع الحماية security-، أما مستودعات updates- و proposition- و backports- فتحديثها مُعطّل افتراضيًا ويُترك للمستخدم حرية تفعيلها من عدمه، لأنها قد تتضمن تعديلات جذرية على حزم النظام لذا نجد أن أسطرها تبدأ برمز التعليق //، ويمكن إزالته إن رغبتنا بتفعيل التحديثات التلقائية لها.

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

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

بعد الانتهاء من إجراء التعديلات، نحفظ التغييرات على الملف ونغلقه بالخطوات التي تناسب محرر النصوص المستخدم ففي nano مثلًا نضغط على Ctrl+X ثم Y وبعدها Enter.

والآن نعيد تشغيل الخدمة unattended-upgrades وفق الأمر التالي لتصبح التعديلات سارية المفعول:

$ sudo systemctl restart unattended-upgrades.service

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

التحديث والتصحيح المباشر لنواة النظام

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

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

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

تفعيل التصحيح المباشر Livepatch لإبقاء الخادم يعمل عند تحديث النواة

يوفر نظام لينكس ميزة مفيدة تدعى التصحيح المباشر live patching تسمح لنا بتحديث النواة kernel دون إعادة التشغيل، ويُشرف على التصحيحات المباشرة -وفق هذه الميزة- أداتان أساسيتان هما:

• Canonical الخاصة بأنظمة أوبنتو حصرًا
• KernelCare التي تدعم معظم توزيعات لينكس الشهيرة إلى جانب أوبنتو

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

يمكن تسجيل الدخول إلى Canonical والحصول على مفتاح خاص بالتصحيح المباشرة من هذا الرابط، ويمكننا بعدها تثبيت الحزمة canonical-livepatch بواسطة snap -وهو مدير حزم آخر يعمل إلى جانب apt في أنظمة أوبنتو- كما يلي:

$ sudo snap install canonical-livepatch

ثم نكتب الأمر التالي لتفعيل الحزمة canonical-livepatch، ولا ننسى استبدال your-key بمفتاحنا الخاص الذي حصلنا عليه من موقع Canonical:

$ sudo canonical-livepatch enable your-key

بعد التنفيذ ستظهر رسالة واضحة تعلمنا بنجاح تثبيت الخدمة Successfully enabled device وبذلك ستصبح canonical-livepatch خدمة عاملة على نظامنا، وستعمل في الخلفية ويمكن التأكد من ذلك بالاستعلام عن حالتها بواسطة canonical-livepatch status كما يلي:

$ sudo canonical-livepatch status

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

last check: 50 seconds ago
kernel: 5.15.0-25-generic
server check-in: succeeded
patch state: ✓ all applicable livepatch modules inserted
patch version: 84.1
tier: updates (Free usage; This machine beta tests new patches.)
machine id: 2565a9e7fc9f4405a167e4caf9b9dcf3

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

الخلاصة

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

ترجمة -وبتصرف- لمقال How to Keep Ubuntu 22.04 Servers Updated لصاحبه Alex Garnett.

اقرأ أيضًا

• أساسيات إدارة الملفّات والتنقّل في لينكس
• الدليل الكامل لاستخدام أوامر apt في نظام لينكس
• تثبيت لينكس مع نظام ويندوز
• كيفية تثبيت التطبيقات في لينكس

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

لنشرح الطرق الثلاثة بالتفصيل في الفقرات التالية:

الطريقة الأولى: استخدام خيار --restart always

هذه الطريقة هي الإعداد الافتراضي لتشغيل الحاوية، فعندما نشغل حاوية دوكر باستخدام الأمر docker run يمكننا تحديد الخيار restart always-- لنقرر تشغيل الحاوية تلقائيًا عند إعادة تشغيل الخادم، أو عند توقف الحاوية لأي سبب كان.

يوضح المثال التالي تشغيل حاوية أباتشي مع تفعيل إعادة التشغيل التلقائي:

docker run -p 8080:80 --name apache -v "${PWD}":/usr/local/apache2/htdocs -d --restart always httpd

هنالك عدة احتمالات ممكنة للخيار restart-- نتحكم من خلالها في كيفية إعادة تشغيل الحاوية تلقائيًا تشمل التالي:

• restart no-- وهو الإعداد الافتراضي، ويعني عدم تشغيل الحاوية تلقائيًا عند توقف الحاوية لأي سبب كان
• restart always-- إعادة تشغيل الحاوية تلقائيًا بمجرد توقفها، وسيعاد تشغيل جميع الحاويات التي بدأ تشغيلها سابقًا باستخدام هذا الخيار
  تحذير: إذا كانت الحاوية تحتوي على خطأ برمجي تسبب في توقفها، فيتسبب هذا الخيار في محاولة إعادة تشغيلها بصورة مستمرة ومتكررة، إلا لو أوقفناها يدويًا باستخدام الأمر docker stop فعندها سيتوقف تشغيلها في نفس الجلسة، لكن ستعاد محاولة تشغيلها من جديد عند إعادة تشغيل الخادم
• restart unless-stopped-- يعمل هذا الخيار بشكل مشابه لخيار restart always-- الفرق هنا هو عدم إعادة تشغيل الحاوية التي أوقفناها يدويًا باستخدام docker stop
• restart on-failure-- إعادة تشغيل الحاوية تلقائيًا فقط في حالة توقفها بسبب خطأ ما

يمكننا معرفة سلوك إعادة التشغيل حاوية باستخدام الأمر docker inspect:

docker inspect <containername>
  ...
  "RestartPolicy": {
      "Name": "always",
      "MaximumRetryCount": 0
  },
  ...

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

docker update --restart on-failure <containername>

الطريقة الثانية: استخدام Docker Compose

يمكننا أيضًا تحديد طريقة إعادة التشغيل التلقائي للحاوية من خلال ملف docker-compose.yml باستخدام الكلمة المفتاحية restart كما يلي:

services:
   db:
     image: mariadb:latest
     restart: always

هناك أربعة إعدادات مسموح بها هنا وهي:

• no وهو الخيار الافتراضي ويعني إعادة تشغيل الحاوية يدويًا فقط
• always لإعادة تشغيل الحاوية دائمًا
• unless-stopped لإعادة تشغيل الحاوية في كافة الأحوال، إلا في حال أوقفناها يدويًا
• on-failure لإعادة تشغيل الحاوية فقط في حال توقفت نتيجة لحدوث خطأ

تتشابه دلالة الخيارات السابقة مع الخيارات المشروحة في الطريقة الأولى التي تستخدم الخيار restart-- مع الأمر docker run، لكن هنا سيكون المعامل restart: always ساري المفعول حتى نوقف الحاويات الموجودة في الملف docker-compose.yml ونحذفها يدويًا باستخدام الأمر docker-compose down.

ملاحظة: ينبغي التأكد من تحديد الكلمة المفتاحية restart في المستوى الصحيح داخل إعدادات الحاوية المعنية وهي db في المثال.

services:
  db:
    image: mariadb:latest
    volumes:
      - vol-db:/var/lib/mysql
    environment:
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: password
    restart: always

الطريقة الثالثة: إعادة تشغيل الحاوية باستخدام systemd

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

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

يمكن تحقيق ذلك باستخدام مدير الخدمات systemd، كما يمكننا استخدام supervisord أيضًا أو أي نظام مشابه آخر لإدارة الخدمات، ولكننا اخترنا systemd في مقالنا الحالي لكونه الأكثر استخدمًا وهو معتمد في معظم توزيعات لينكس.

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

• إمكانية بدء الخدمة بشكل صحيح عند تشغيل الجهاز
• إمكانية إعادة تشغيل الحاوية تلقائيًا في حال توقفت لأي سبب كان باستخدام إعداد Restart=always في ملف خدمة systemd
• سهولة مراجعة وإدارة سجلات الحاوية stdout بواسطة نظام تسجيل السجلات Journald
• استخدام كامل نظام systemd لإدارة المتطلبات كالتبعيات والأوامر التي يجب أن تنفذ قبل وبعد تشغيل الحاوية وتعريف متغيرات البيئة التي تحتاجها الحاوية بكفاءة

يعرض الكود التالي الحد الأدنى لمحتوى ملف خدمة systemd لتشغيل حاوية دوكر تحتوي على خادم nginx والموجود في المسار /etc/systemd/system/nginx.service:

[Unit]
Description=Docker container

[Service]
ExecStart=/usr/bin/docker run --name nginx \
    --net host \
    -v /srv/nginx/conf.d:/etc/nginx/conf.d \
    -v /srv/nginx/index.html:/usr/share/nginx/html/index.html \
    nginx

ExecStop=/usr/bin/docker stop nginx
ExecStopPost=/usr/bin/docker rm -f nginx

[Install]
WantedBy=multi-user.target

يحدد هذا الملف الأمور التالية:

• تشغيل الحاوية التي تحتوي على خادم nginx تلقائيًا عند تشغيل النظام
• إيقاف الحاوية بشكل صحيح عند إيقاف الخدمة
• حذف الحاوية بعد إيقافها
• تشغيل الخدمة تلقائيًا عند تشغيل النظام ووصوله لمرحلة multi-user target

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

سيعمل جزء WantedBy فقط عند تنفيذ الأمر systemctl enable nginx، وفي هذه الحالة ستفعَّل الخدمة عند بدء التشغيل لأنها ستكون مرتبطة بالوصول لمرحلة multi-user target في systemd، هذا يعني أنه عند تشغيل النظام، ستفعّل الخدمة تلقائيًا.

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

أيضًا، في حالتنا nginx التي هي خدمة عديمة الحالة stateless أي أنها لا تحفظ حالتها بين عمليات التشغيل المختلفة، لذا سيكون من الأفضل تحديث صورة دوكر الخاصة بالخدمة لأحدث إصدار متاح كلما شغلنا هذه الخدمة لنضمن بأنها تعمل بأحدث نسخة من الحاوية، ولتحقيق سنضيف أمر ExecStartPre المسؤول عن تنفيذ docker pull كي يعمل قبل الأمر ExecStart.

كما يمكننا فرض إعادة تشغيل الخدمة دائمًا في حال تعرضت لخطأ، وذلك كل 10 ثوانٍ مثلًا، من خلال الأسطر Restart و RestartSec والتي تشابه في تأثيرها الخيار restart=on-failure في أمر docker run الذي شرحناه في الطريقة الأولى.

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

لحل هذه المشكلة يمكن استخدام حل بسيط وهو استخدام الأمر ExecReload لإعادة تحميل عملية nginx داخل الحاوية فهذا يساعدنا عند الحاجة لتحديث إعدادات nginx أو إعادة تحميلها دون توقف الخدمة بالكامل، كما يمكننا استخدام حل بديل وهو إرسال إشارة باستخدام الأمر kill -s HUP، لنخبر nginx بأن يعيد تحميل إعداداته دون إيقافه بالكامل.

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

فيما يلي ملف الخدمة بعد إجراء التحسينات السابقة:

[Unit]
Description=Docker container
BindsTo=docker.service
After=docker.service

[Service]
Environment=NAME=%N
Environment=IMG=nginx
Restart=on-failure
RestartSec=10
ExecStartPre=-/usr/bin/docker kill ${NAME}
ExecStartPre=-/usr/bin/docker rm ${NAME}
ExecStart=/usr/bin/docker run --name ${NAME} \
    -p 80:80 \
    -p 443:443 \
    -v /srv/nginx/conf.d:/etc/nginx/conf.d \
    -v /srv/nginx/html:/usr/share/nginx/html/ \
    ${IMG}
ExecStop=/usr/bin/docker stop ${NAME}
ExecReload=/usr/bin/docker exec ${NAME} nginx -s reload

[Install]
WantedBy=multi-user.target

ملاحظة: يجري استبدال N% تلقائيًا باسم ملف الخدمة، وعلينا أن لا ننسى تشغيل الأمر systemctl daemon-reload في كل مرة نغير فيها إعدادات ملف الخدمة.

مراقبة سجلات الخدمة

عند تشغيل الخدمات باستخدام systemd مثل خدمة nginx في المثال السابق، ستوجه السجلات التي تنتج عن الخدمة إلى سجلات النظام journald، وهذا يسهل علينا الوصول لها وتحليلها.

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

journalctl -fu nginx

لا يمنعنا هذا الأسلوب من الحصول على ملفات سجلات منفصلة، فقد نحتاج لذلك كما في حالة استخدام virtualhosts لإدارة عدة مواقع ويب على نفس الخادم باستخدام nginx، في هذه الحالة سيكون من الأنسب لنا مشاركة مجلد السجلات الخاص بالحاوية وهو بشكل افتراضي /var/log/nginx مع جهاز المضيف حتى لا نفقدها عند إعادة التشغيل.

الخاتمة

تعرفنا في هذا المقال على ثلاث طرق مختلفة لإعادة تشغيل حاويات دوكر تلقائيًا بعد إعادة تشغيل الخادم، يعتمد اختيار الطريقة المناسبة على البئية ومتطلبات العمل، ففي الحالات البسيطة وإعدادات الحاوية الواحدة قد تكون طريقة restart-- في أمر docker run أو طريقة Docker Compose كافية. لكن في البيئات المعقدة التي تتضمن عدة خدمات ستوفر لنا طريقة systemd تحكمًا أكبر بالحاوية.

ترجمة -وبتصرف- للمقال Restart Docker Container Automatically After Reboot لكاتبه Umair Khurshid

اقرأ أيضًا

• ثلاث نصائح لتسمية حاويات Docker
• استخدام الأمر docker exec في حاويات Docker
• أساسيات تنسيق الحاويات
• مدخل إلى الحاويات

نشرح في هذا المقال إنشاء تطبيق مكتوب بلغة بايثون Python على كوبرنتس Kubernetes باستخدام منصة أوكتيتو Okteto التي تسهل عملية تطوير تطبيقات كوبرنتس Kubernetes، فهي تسمح للمطورين ببناء التطبيقات واختبارها مباشرة في عناقيد كوبرنتس Kubernetes clusters دون الحاجة لإعداد بيئات تطوير معقدة، كما توّفر منصة Okteto ميزة التحديثات المباشرة live updates للتطبيقات التي تعمل في عناقيد كوبرنتس مما يسمح للمطورين رؤية التعديلات على الشيفرة في الوقت الفعلي دون الحاجة إلى إعادة بناء التطبيقات أو إعادة نشرها.

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

لمتابعة خطوات هذا المقال، سنحتاج إلى ما يلي:

• عنقود كوبرنتس النسخة 1.28، وسنستخدم في مقالنا عنقود من منصة DigitalOcean، يحتوي على 3 عقد على الأقل
• تثبيت واجهة سطر الأوامر kubectl وضبطها للتواصل مع عنقود كوبرنتس
• حساب على مستودع دوكر هب
• تثبيت دوكر Docker على جهازنا المحلي
• مفتاح ترخيص لاستخدام منصة Okteto، ويمكن التسجيل في الإصدار التجريبي المجاني.
• تثبيت مدير الحزم Helm لتطوير التطبيقات ضمن عناقيد Kubernetes، باتباع الخطوة الأولى من المقال التالي.
• نطاق Domain مسجَّل ومربوط مع Load Balancer لإدارة حركة مرور التطبيقات، وإنشاء سجل A record باسم * وعنوان IP موازن الحِمل.

إنشاء تطبيق بايثون

علينا التأكد أولًا بأن بايثون مثبّت على جهاز يعمل بنظام التشغيل أوبنتو بكتابة الأمر التالي في الطرفية:

python3 --version

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

sudo apt install python3 python3-venv python3-pip -y

بعدها، ننشئ مجلد لتخزين شيفرة البرنامج وإعداداته:

mkdir my-app

ثم ننشئ بيئة افتراضية داخل مجلد التطبيق لوضع اعتماديات المشروع فيها:

cd my-app
python3 -m venv python-env

والآن نفعّل البيئة الافتراضية باستخدام الأمر التالي:

source python-env/bin/activate

ثم ننشئ ملف بايثون لكتابة شيفرة التطبيق فيه:

nano app.py

ونضيف له الشيفرة التالية:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    return "Hello, This is a simple Python App!"

if __name__ == '__main__':
    app.run(debug=True, host='0.0.0.0')

ثم نثبّت إطار عمل فلاسك Flask:

pip install flask

نشغّل التطبيق الآن باستخدام الأمر التالي:

python3 app.py 

سنحصل على هذا الخرج:

Output

* Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:5000
 * Running on http://172.20.10.2:5000
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 311-959-468

أصبح إطار فلاسك Flask يعمل على جهازنا المحلي، نتأكّد من ذلك باستخدام الأمر curl:

curl -X GET -H "Content-Type: application/json" http://localhost:5000

سنحصل على الرد التالي من تطبيق فلاسك:

Output
Hello, This is a simple Python App!

يدل هذا الخرج على أن تطبيق فلاسك قد نُفّذ بنجاح دون أخطاء.

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

deactivate

وبهذا تكون أنشأنا تطبيقنا واختبرنا عمله محليًا، وحان وقت الخطوة الثانية لتشغيل هذا التطبيق داخل دوكر Docker.

تشغيل تطبيق بايثون داخل دوكر Docker

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

nano Dockerfile

ثم نضيف عليه التعليمات التالية:

# Use an official Python runtime as a parent image
FROM python:3.8-slim

# Set the working directory in the container
WORKDIR /app

# Copy the current directory contents into the container at /app
ADD . /app

# Install any needed dependencies specified in requirements.txt
RUN pip install flask

# Make port 5000 available to the world outside this container
EXPOSE 5000

# Define environment variable
ENV NAME DockerizedPythonApp

# Run app.py when the container launches
CMD ["python3", "./app.py"]

فيما يلي شرح تعليمات ملف دوكر السابقة:

• تحدد التعليمة FROM python:3.8-slim الصورة الأساسية التي نحتاجها
• تضبط WORKDIR /app المجلد ‎/app مجلدًا للعمل داخل الحاوية container
• تنسخ التعليمة ADD . /app محتوى المجلد الحالي لمجلد حاوية التطبيق ‎/app
• تثبّت RUN pip install flask إطار العمل فلاسك Flask
• تستمع التعليمة EXPOSE 5000 على المنفذ 5000 للسماح بالاتصال
• يحدد CMD ["python3", "app.py"] الأمر الذي سينفذ عند تشغيل الحاوية وهو هنا الأمر app.py

بعدها سنشغّل الأمر التالي لبناء صورة دوكر وفقًا للتعليمات السابقة:

docker build -t my-app .

نستطيع تشغيل التطبيق الآن في الحاوية باستخدام الصورة التي أنشأناها:

docker run -dit -p 5000:5000 my-app:latest

يُشَغّل الأمر السابق حاوية من الصورة my-app ويضبط منفذ الحاوية على المنفذ المضيف 5000. نكتب الأمر التالي للتأكد من عمل الحاوية:

docker ps

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

Output
CONTAINER ID   IMAGE           COMMAND              CREATED         STATUS         PORTS                                       NAMES
761c54c77411   my-app:latest   "python3 ./app.py"   3 seconds ago   Up 3 seconds   0.0.0.0:5000->5000/tcp, :::5000->5000/tcp   pedantic_wescoff

نفتح متصفح الويب أو نستعمل موجّه الأوامر curl للوصول إلى التطبيق باستخدام العنوان ‎http://your-server-ip:5000/، وستظهر رسالة Hello, This is a simple Python App!‎ التي تشير لأن التطبيق يعمل داخل حاوية دوكر. وبهذا نكون شغّلنا تطبيق بايثون في حاوية دوكر بنجاح.

رفع صورة تطبيق بايثون إلى سجل DockerHub

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

docker login 

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

Output
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: username@gmail.com
Password: 
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

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

docker tag my-app yourusername/my-app:latest

يمكن الآن رفع الصورة إلى دوكر هب باستخدام الأمر docker push:

docker push yourusername/my-app:latest

نتأكّد بعدها أن الصورة أصبحت موجودة بالبحث عنها باستخدام طرفية دوكر هب Docker Hub CLI:

docker search yourusername/my-app

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

إنشاء ملف Kubernetes Manifests لنشر التطبيق

علينا الآن إنشاء ملف Kubernetes Manifests باستخدام منصة Okteto لضبط عملية التطوير والخدمات وموارد Ingressللتطبيق. نكتب الأمر التالي لإنشاء الملف:

nano k8s.yaml

ثم نضيف الإعدادات التالية إليه:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: yourusername/my-app
        name: my-app

---

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: ClusterIP
  ports:
  - name: "my-app"
    port: 5000
  selector:
    app: my-app

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    dev.okteto.com/generate-host: my-app
spec:
  rules:
    - http:
        paths:
          - backend:
              service:
                name: my-app
                port:
                  number: 5000
            path: /
            pathType: ImplementationSpecific

سينشر الملف السابق تطبيقنا بالاسم my-app باستخدام منصة Okteto، وسينشره داخليًا عبر خدمة ClusterIP على المنفذ 5000، ثم سيُعدّ مورد Ingress لتوجيه حركة مرور HTTP إلى التطبيق. وهنا استخدمنا التعليقات التوضيحية الخاصة بـمنصة Okteto لتفعيل بعض الميزات التي تقدمها مثل إنشاء اسم المضيف hostname تلقائيًا.

تثبيت Okteto باستخدام مدير الحزم Helm

لتثبيت Okteto باستخدام مدير الحزم Helm علينا أولًا إضافة مستودع Okteto Helm إلى عميل Helm:

helm repo add okteto https://charts.okteto.com

وبعد ذلك علينا تحديث مستودعات مدير الحزم Helm لنضمن أن لدينا معلومات حديثة عن المخططات أو الحزم التي تحتوي على تعريفات موارد Kubernetes اللازمة لتشغيل التطبيق:

helm repo update

ثم ننشئ ملف config.yaml:

nano config.yaml

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

license: INSERTYOURKEYHERE
subdomain: okteto.example.com

buildkit:
  persistence:
    enabled: true

registry:
  storage:
    filesystem:
      persistence:
        enabled: true

ثم نثبّت أحدث نسخة من Okteto باستخدام ملف الإعدادات config.yaml:

helm install okteto okteto/okteto -f config.yaml --namespace okteto --create-namespace

سنحصل على الخرج التالي عند انتهاء التثبيت:

Output
NAME: okteto
LAST DEPLOYED: Tue Mar 12 20:27:21 2024
NAMESPACE: okteto
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Congratulations! Okteto is successfully installed!

Follow these steps to complete your domain configuration:

1. Create a wildcard A record "*.okteto.example.com", pointing it to the Okteto NGINX ingress controller External-IP:

   $ kubectl get service -l=app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/component=controller --namespace=okteto

2. Access your Okteto instance at `https://okteto.okteto.example.com/login#token=88f8cc11`

ملاحظة: علينا الاحتفاظ برمز الوصول الشخصي Personal Access Tokens ذو القيمة 88f8cc11 من الشيفرة أعلاه لأننا سنحتاجه لتوثيق حسابنا في Okteto. ننتظر قليلًا ثم نجلب عنوان IP لخادم NGINX Ingress:

kubectl get service -l=app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/component=controller --namespace=okteto

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

Output
NAME                              TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
okteto-ingress-nginx-controller   LoadBalancer   10.101.31.239   45.76.14.191   80:31150/TCP,443:31793/TCP   3m21s

علينا إضافة العنوان الخارجي EXTERNAL-IP إلى سجل A تحت الاسم * في إعدادات بروتوكول DNS. والآن، نفتح المتصفح للوصول إلى Okteto باستخدام الرابط التالي: https://okteto.okteto.example.com/login#token=88f8cc11.

تثبيت وضبط إعدادات واجهة أوامر Okteto

تُتيح لنا واجهة أوامر Okteto مفتوحة المصدر تطوير التطبيقات مباشرة على Kubernetes. بإمكاننا تثبيت واجهة الأوامر على نظامي لينوكس Linux وماك MacOS باستخدام الأمر curl التالي:

sudo curl https://get.okteto.com -sSfL | sh

نتأكد من تثبيت واجهة أوامر Okteto باستخدام الأمر التالي الذي سيعرض تانسخة المثبّتة على جهازنا

Output
okteto version 2.25.2 

والآن علينا استخدام رمز الوصول الشخصي Personal Access Tokens للمصادقة:

okteto context use https://okteto.okteto.example.com --token 88f8cc11 --insecure-skip-tls-verify

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

Output
✓  Using okteto-admin @ okteto.okteto.example.com

نشغّل الأمر التالي للتأكد من إعدادات واجهة الأوامر:

okteto context list

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

Output
Name                                      Namespace     Builder                                 Registry
https://okteto.okteto.example.com *      okteto-admin  tcp://buildkit.okteto.example.com:443  registry.okteto.example.com
vke-4b7aaaa6-78fa-4a19-9fb3-cf7b8c1ec678  default       docker                                  -

إنشاء Okteto Manifest

علينا إنشاء ملف Okteto Manifest وضبط إعدادات بيئة التطوير لنتمكن من إنشاء تطبيقات بلغة بايثون. أولًا، ننشئ ملف okteto.yaml مخصص لتطبيق بايثون بسيط.

nano okteto.yaml

ثم نضيف الإعدادات التالية:

deploy:
  - kubectl apply -f k8s.yaml

dev:
  my-app:
    command: bash
    environment:
      - FLASK_ENV=development
    sync:
      - .:/app
    reverse:
      - 9000:9000
    volumes:
      - /root/.cache/pip

فيما يلي شرح الأوامر السابقة:

يتضمن القسم deploy إعدادات النشر. وعند تشغيل الأمر okteto up أو okteto deploy يُنَفَّذ الأمر kubectl apply -f k8s.yaml الذي ينشر موارد Kubernetes الموجودة في الملف k8s.yaml، ويُتيح ذلك فصل إعدادات النشر عن إعدادات التطوير.

يُحدد command: bash الأمر الذي يجب تشغيله عند بدء تشغيل بيئة التطوير ويحدد environment متغيرات البيئة التي يجب أن تكون في بيئة التطوير. وهنا صرّحنا أن متغيرات فلاسك FLASK_ENV يجب أن تكون في بيئة التطوير FLASK_ENV=development.

يحدد القسم sync القسم الملفات التي يجب مزامنتها من جهازنا المحلي مع ملفات بيئة التطوير، إذ يجب مزامنة المجلد (.) مع المجلد /app‎ من بيئة التطوير. ويوّضح  reverse قواعد توجيه المنافذ بين بيئة التطوير وجهازك المحلي. وفي مثالنا، يوجّه المنفذ 9000 من بيئة التطوير إلى المنفذ 9000 على جهازنا المحلي.

أخيرًا يوّضح v وحدات التخزين الإضافية التي ستُضاف إلى بيئة التطوير. وهنا سنضيف المجلد /root/.cache/pip، لنستخدمه لتخزين حزم pip في بيئة التطوير مؤقتًا.

الآن علينا نشر تطبيق بايثون إلى عنقود كوبرنيتس باستخدام الأمر التالي:

okteto deploy

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

Output
deployment.apps/my-app created
service/my-app created
ingress.networking.k8s.io/my-app created
 i  There are no available endpoints for 'Okteto'.
    Follow this link to know more about how to create public endpoints for your application:
    https://www.okteto.com/docs/cloud/ssl/
 ✓  Development environment 'Okteto' successfully deployed
 i  Run 'okteto up' to activate your development container

ثم نحدّث لوحة تحكم Okteto من المتصفح لتعاين التطبيق بعد نشره:

كما يمكننا الوصول إلى التطبيق من الرابط التالي: https://my-app-okteto-admin.okteto.example.com.

تطوير تطبيق بايثون في منصة كوبرنتس مباشرة

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

علينا أولًا تشغيل بيئة التطوير باستخدام Okteto:

okteto up

يُنشئ هذا الأمر بيئة تطوير وفقًا للإعدادات الموجودة في ملف okteto.yaml:

Output
i  Using okteto-admin @ okteto.okteto.example.com as context
 i  'Okteto' was already deployed. To redeploy run 'okteto deploy' or 'okteto up --deploy'
 i  Build section is not defined in your okteto manifest
 ✓  Persistent volume successfully attached
 ✓  Images successfully pulled
 ✓  Files synchronized
    Context:   okteto.okteto.example.com
    Namespace: okteto-admin
    Name:      my-app
    Reverse:   9000 <- 9000
root@my-app-okteto-7767588c8d-ndzj7:/app# 

نشغّل بعدها تطبيق بايثون:

python3 app.py 

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

* Serving Flask app 'app'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:5000
 * Running on http://10.244.97.92:5000
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 126-620-675

ثم نعدّل ملف التطبيق app.py:

nano app.py

وعدّل السطر التالي:

   return "Hello, This is a simple Python App Deployed on Kubernetes"

نحفظ الملف ثم نغلقه، وستٌطبَق التعديلات على الشيفرة البرمجية تلقائيًا في كوبرنتس. ثم نعيد تحميل صفحة التطبيق من متصفح الويب لتعاين التطبيق بعد التعديل.

الخاتمة

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

ترجمة -وبتصرّف- للمقال How to Deploy Python Application on Kubernetes with Okteto لكاتبيه hitjethva وEasha Abid.

اقرأ أيضًا

• إنشاء تطبيق ويب باستخدام إطار عمل فلاسك Flask من لغة بايثون
• نشر تطبيق جانغو آمن وقابل للتوسيع باستخدام كوبيرنتس Kubernetes
• تثبيت بايثون 3 وإعداد بيئتها البرمجية
• تعرّف على كوبرنيتس Kubernetes

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

العمل على نظام تشغيل ويندوز Windows

إذا كنا نستخدم نظام التشغيل ويندوز على جهازنا، فسنحتاج إلى تثبيت إحدى إصدارات برنامج OpenSSH لنتمكن من استخدام الأمر ssh من سطر الأوامر. أما إن فضّلنا العمل في برنامج PowerShell، فيمكن قراءة توثيقات مايكروسوفت لإضافة OpenSSH إلى PowerShell. أما في حال العمل في بيئة لينكس Linux كاملة، فيمكن إعداد WSL -أي نظام ويندوز الفرعي لنظام لينكس Windows Subsystem for Linux- وهو طبقة توافق لتشغيل أنظمة لينكس داخل أنظمة ويندوز، مما يتيح لنا تشغيل طرفية حقيقية مباشرةً في نظام ويندوز دون الحاجة لآلة افتراضية ويتضمن الأمر ssh. وأخيرًا، يمكننا تثبيت Git على نظام ويندوز، والذي يوفر طرفية Bash أصلية تتضمن أيضًا الأمر ssh. فجميع هذه البيئات الثلاثة مدعومة والخيار متروك لكم في العمل مع إحداها حسب ما تفضلونه.

العمل على نظام تشغيل لينكس Linux أو ماك Mac

إن كنا نستخدم نظام لينكس أو ماك فسيكون الأمر ssh جاهزًا في الطرفية، وفيما يلي صيغته الأساسية:

ssh remote_host

remote_host هو عنوان IP أو اسم النطاق domain الذي نريد الاتصال به.

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

ssh remote_username@remote_host

قد يُطلب منا إدخال كلمة مرور للاتصال بالخادم، وسنتحدث لاحقًا عن كيفية استخدام مفاتيح المصادقة المشفرة keys بدل كلمات المرور passwords.

نستخدم الأمر التالي للخروج من جلسة SSH والعودة إلى الصدفة:

Exit

آلية عمل بروتوكول SSH

يعمل بروتوكول SSH عن طريق توصيل برنامج عميل client program يسمى sshd مع خادم ssh، فبالعودة إلى مثالنا السابق، فإن ssh هو بمثابة برنامج العميل، أما خادم ssh فيعمل على الجهاز البعيد remote host الذي حددناه. يجب أن يبدأ خادم sshd بالعمل تلقائيًا في معظم بيئات لينكس. وإذا لم يعمل لسبب ما، فقد نحتاج إلى الوصول إلى الخادم من خلال إحدى طرفيّات المتصفح المعتمدة على الويب web-based console، أوالطرفيّة المحلية local serial console.

يعتمد الأمر اللازم لتشغيل خادم ssh على توزيعة لينكس التي نستخدمها، فعند استخدام توزيعة أوبنتو، يمكننا تشغيل الأمر التالي:

sudo systemctl start ssh

يُشغّل الأمر السابق خادم sshd وبإمكاننا الآن تسجيل الدخول إلى الخادم عن بعد.

كيفية ضبط إعدادات بروتوكول SSH

عندما نغيّر إعدادات بروتوكول SSH فإننا نغيّر أيضًا إعدادات خادم sshd. سنجد ملف الإعدادات ضمن المسار /etc/ssh/sshd_config. ومن الضروري أخذ نسخة احتياطيةً عن هذا الملف قبل بدء التعديل، باستخدام الأمر التالي:

sudo cp /etc/ssh/sshd_config{,.bak}

ثم نفتحه باستخدام محرر النصوص nano أو أي محرر آخر:

sudo nano /etc/ssh/sshd_config

لنطلع على بعض خيارات الملف:

Port 22

عند الإعلان عن منفذ جديد port declaration فإننا نحدد المنفذ الذي سيستخدمه خادم sshd للاتصال، والمنفذ الافتراضي لذلك هو 22. يُفضّل ألا نغيّر هذا الإعداد، إلا إن كان لدينا سبب لذلك. وسنوضح لاحقًا كيفية الاتصال بالمنفذ الجديد.

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

عند الإعلان عن مفاتيح المضيف host keys فإننا نحدد مكان البحث عن مفاتيح المضيف العامة global host keys. وسنتحدث عن ذلك لاحقًا.

SyslogFacility AUTH
LogLevel INFO

يحدد العنصران السابقان مستوى التسجيل logging level. إذ قد تكون زيادة التسجيل طريقة جيدة لاكتشاف المشكلات في SSH:

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

تحدد المعاملات السابقة بعض معلومات تسجيل الدخول:

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

X11Forwarding yes
X11DisplayOffset 10

• تضبط هذه المعاملات خاصيةً تسمى X11 Forwarding تتيح لنا عرض واجهة المستخدم الرسومية GUI للنظام البعيد على النظام المحلي، ويجب تفعيل هذا الخيار على الخادم واستخدامه مع عميل SSH أثناء الاتصال مصحوبًا بالخيار x-.

بعد التعديل على الملف نحفظه ثم نغلقه. وإن كنا نستخدم محرر النصوص nano، نضغط على المفتاحين Ctrl+X، ثم Y عندما يُطلب منا ذلك، ثم نضغط على مفتاح Enter. ولا ننسى إعادة تحميل خادم sshd لتنفيذ التعديلات التي أجريناها في الملف باستخدام الأمر التالي:

sudo systemctl reload ssh

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

تسجيل الدخول إلى SSH باستخدام مفاتيح المصادقة Keys

يُنصح لتسجيل الدخول إلى نظام بعيد استخدام كلمات المرور passwords أو مفاتيح المصادقة keys والتي تتصف بأنها أسرع وأكثر أمانًا من كلمات المرور.

آلية عمل المصادقة المعتمدة على المفاتيح

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

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

كيفية إنشاء مفاتيح المصادقة في بروتوكول SSH

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

ssh-keygen -t rsa

قد يُطلب منا تعيين كلمة مرور على ملفات المفاتيح نفسها، ولكن هذا الأمر غير شائع. يجب الضغط على مفتاح Enter لقبول الإعدادات الافتراضية. وستُنشأ المفاتيح في المجلد ‎~/.ssh/id_rsa.pub و المجلد ‎~/.ssh/id_rsa.

نغيّر مكان إنشاء المفاتيح إلى المجلد ‎.sshباستخدام الأمر التالي:

cd ~/.ssh

نستعرض سماحيات الملف باستخدام الأمر:

ls -l

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

-rw-r--r-- 1 demo demo  807 Sep  9 22:15 authorized_keys
-rw------- 1 demo demo 1679 Sep  9 23:13 id_rsa
-rw-r--r-- 1 demo demo  396 Sep  9 23:13 id_rsa.pub

نلاحظ أن الملف id_rsa قابل القراءة والكتابة بواسطة المالك فقط، مما يساعد على إبقاء الملف سريًّا. أما الملف id_rsa.pub فيمكن مشاركته وله سماحيات تمكّن ذلك.

نقل المفاتيح العامة إلى الخادم

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

ssh-copy-id remote_host

سيؤدي الأمر إلى إنشاء جلسة SSH، وبعد إدخال كلمة المرور، سيُنسخ المفتاح العام إلى ملف المفاتيح المعتمدة authorized keys في الخادم، مما يسمح لنا بتسجيل الدخول دون كلمة المرور في المرة القادمة.

الخيارات المتاحة لعميل SSH

هناك خيارات عدة عند الاتصال عبر بروتوكول SSH، بعضها قد يكون ضروريًا لمطابقة الإعدادات الموجودة في sshd عند المضيف البعيد remote host. مثلًا، إذا غيّرنا رقم المنفذ في إعدادات sshd، فعلينا تغييره عند العميل باستخدام الأمر التالي:

ssh -p port_number remote_host

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

إذا أردنا تنفيذ أمر واحد فقط على النظام البعيد، فيمكن تحديده بعد المضيف، كما يلي:

ssh remote_host command_to_run

سنتصل بالنظام البعيد وسيُنَفذ الأمر بعد إدخال مفتاح المرور. إن كانت خاصية X11 Forwarding مفعلةً على كلا الجهازين، فيمكننا تفعيل ميزاتها باستخدام الأمر التالي:

ssh -X remote_host

بشرط توفر الأدوات المناسبة لذلك على حاسوبنا، فبرامج واجهة المستخدم الرسومية التي نستخدمها على النظام البعيد ستُشَغّل الآن على نظامنا المحلي.

إلغاء التحقق من كلمة المرور

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

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

نفتح ملف إعدادات sshd كمستخدم مسؤول root user أو أو مستخدم يتمتع بامتيازات sudo باستخدام الأمر التالي:

sudo nano /etc/ssh/sshd_config

نبحث عن سطر Password Authentication ثم نزيل التعليق عنه بمسح رمز #، ونغيّر قيمته إلى القيمة no:

PasswordAuthentication no

أما الخيار PubkeyAuthentication و ChallengeResponseAuthentication فلا يحتاجان إلى تعديل، شريطة ألا نكون عدلنا هذا الملف، إذ يجب تركهما على الضبط الإفتراضي:

PubkeyAuthentication yes
ChallengeResponseAuthentication no

نحفظ الملف ونغلقه بعد الانتهاء من التعديلات. ثم نعيد تحميل برنامج ssh:

sudo systemctl reload ssh

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

الخاتمة

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

ترجمة ، وبتصرّف، للمقال How To Use SSH to Connect to a Remote Server لكاتبه Justin Ellingwood.

اقرأ أيضًا

• ما هي تقنية SSH؟
• أنفاق SSH، ماهيتها وكيفية إعدادها
• كيفيّة منع SSH من فصل الجلسات
• مدخل إلى طرفيّة لينكس Linux Terminal

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

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

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

ملاحظة: تختلف خطوات أتمتة نشر موقع مبني بلغة PHP عن خطوات نشر تطبيق Node.js. كما توجد حلول جاهزة أشمل تدعى حزم البناء buildpacks مثل دوكو Dokku تناسب مجموعة أوسع من التقنيات. سنشرح في هذا المقال أداة بسيطة لأتمتة عمليات نشر تطبيقات الويب الخاصة بنا، وذلك باستخدام خطافات الويب webhooks وحزم البناء buildpacks وملفات Procfiles في غيت هب GitHub. ويمكن الاطلاع على الشيفرة المصدرية source code للنموذج الأولي منها على موقع غيت هب GitHub. ملاحظة: تستخدم حزم البناء buildpacks لتحديد كيفية تكوين بيئة التطبيق قبل نشره، وتحدد ملفات Procfiles النصية أنواع العمليات في التطبيق، مما يسهل تشغيلها تلقائياً. وسنشرحها مفصلًا في الفقرات التالية.

بناء تطبيق الويب

ستكون أولى خطواتنا كتابة برنامج بسيط بلغة غو Go، لا تقلق إذا كنت لا تألف العمل بلغة غو GO فبنية الشيفرة البرمجية المستخدمة بسيطة نسبيًا وستجدها سهلة الفهم. ويمكن كتابة البرنامج باللغة التي تناسبنا. قبل البدء لنتأكد من تثبيت Go distribution على نظام التشغيل باتباع الخطوات المذكورة الموقع الرسمي، بعدها يفضل تنزيل الشيفرة المصدرية لأداتنا باستنساخ clone مستودع غيت هب GitHub repository، فهذا سيسهّل متابعة تتمة الخطوات، فمقاطع الشيفرة البرمجية في المستودع مسمّاة بنفس أسماء الملفات التي سنحددها في المقال. إن استخدام برنامج غو Go دونًا عن غيره لكتابة برنامجنا سيحدّ من حاجتنا للاستعانة باعتماديات dependencies خارجية، ففي حالتنا لن نحتاج لتشغيل برنامج غو على الخادم إلا لتثبيت غيت Git وباش Bash، كما أن البرنامج لا يستهلك الكثير من موارد الجهاز مثل الذاكرة رام RAM والمعالج CPU عندما نضبطه بطريقة صحيحة.

ما هي خطافات الويب Webhooks في غيت هب

تمكّننا خطافات الويب في غيت هب من ضبط المستودع GitHub repository ليصدّر الأحداث events كلما طرأ تغيير ضمن المستودع أو أجرى مستخدم إجراء معينًا في المستودع المستضاف، وهذا يتيح للمستخدمين التسجيل subscribe في هذه الأحداث وتلقي إشعارات بمختلف الأحداث التي تجري في مستودعنا وما يتعلق به من خلال استدعاءات الروابط URL invocations حيث سيستدعى عنوان URL معين تلقائيًا عندما يقع حدث معين في المستودع.

خطوات إنشاء Webhooks في غيت هب

يعد إنشاء خطاف ويب Webhooks عملية بسيطة سنلخصها في الخطوات التالية:

1. نفتح صفحة الإعدادات settings في مستودعنا
2. نضغط على خطافات الويب والخدمات Webhooks & Services في قائمة الخيارات
3. نضغط على زر إضافة خطاف ويب Add webhook.
4. ندخل رابط، ونضيف إن شئنا رمزًا سريًا secret يتيح للمستقبل التحقق من حمولة البيانات الواردة payload
5. نحدد الاختيارات الأخرى في الصفحة حسب متطلباتنا
6. أخيرًا، نضغط على الزر الأخضر Add webhook.

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

حزم البناء Buildpacks

أصبحت حزم البناء جزءًا لا يتجزأ من عملية نشر التطبيقات في وقتنا هذا، ويستخدمها العديد من مزودي المنصات كخدمة PaaS. حيث تتيح لنا حزم البناء تحديد كيفية ضبط مكدس التقنيات stack التي سنحتاجها لتشغيل تطبيقنا قبل أن ننشره، وكتابتها بغاية السهولة، ففي معظم الأحيان لن نحتاج حتى لكتابتها بنفسنا حيث تستطيع بإجراء بحث سريع على الإنترنت إيجاد حزم بناء جاهزة يمكننا استخدامها في عملية نشر تطبيقنا دون الحاجة إلى تعديلها. فمثلًا تقدم منصة Heroku توثيقًا شاملًا عن بنية حزم البناء وقائمة تضم أكثر حزم البناء المستخدمة وأفضلها بنيةً. تستخدم أداة الأتمتة التي نبنيها سكربت تصريف compile script لتجهيز التطبيق قبل تشغيله. ولا بد أن ننوه أننا لن نستفيض في كتابة حزم البناء، وإنما سنفترض أن سكربتات حزم البناء buildpack scripts الجاهزة تتوافق مع بيئة سطر الأوامر باش Bash، وأنها ستُشغَّل على نظام تشغيل أبونتو Ubuntu مثُبّت حديثًا ولم يطرأ عليه أي تعديل، ويمكن لاحقًا التوسّع أكثر فيها حسب متطلبات عملنا.

ملفات Procfiles

هي ملفات نصية بسيطة تمكّننا من تحديد مختلف أنواع الإجرائيات processes المستخدمة في تطبيقنا، وتُستخدم عادةً في معظم التطبيقات البسيطة إجرائية ويب web واحدة فقط تعالج طلبات بروتوكول HTTP. لكتابة هذه الملفات ما علينا سوى تحديد نوع إجرائية واحد في كل سطر وذلك بكتابة اسمها متبوعًا بنقطة مزدوجة : متبوعة بالأمر الذي سيولّد spawn هذه الإجرائية كمل يلي:

<type>: <command>

على سبيل المثال، إذا كان تطبيقنا مكتوب بنود جي إس Node.js، علينا تنفيذ الأمر node index.js لتشغيل خادم الويب. يمكن إذًا أن ننشئ ملف Procfile في المجلد الأساسي للشيفرة البرمجية ونسميه Procfile ونكتب ما يلي ضمنه:

web: node index.js

نلزم تطبيقاتنا بتحديد أنواع الإجرائيات في ملفات Procfiles لنتمكن من تشغيلها تلقائيًا بعد سحب pulling الشيفرة البرمجية.

معالجة الأحداث

نحتاج في برنامجنا إلى إضافة خادم HTTP مهمته استقبال طلبات POST الواردة من غيت هب، لذا علينا أن نخصص مسار رابط URL path لمعالجة هذه الطلبات. ونقدم في النموذج التالي مثالًا عن بنية الدالة function التي ستعالج الحمولات payloads الواردة من هذا النوع:

// hook.go
type HookOptions struct {
    App    *App
    Secret string
}


func NewHookHandler(o *HookOptions) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        evName := r.Header.Get("X-Github-Event")
        if evName != "push" {
            log.Printf("Ignoring '%s' event", evName)
            return
        }


        body, err := ioutil.ReadAll(r.Body)
        if err != nil {
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            return
        }


        if o.Secret != "" {
            ok := false
            for _, sig := range strings.Fields(r.Header.Get("X-Hub-Signature")) {
                if !strings.HasPrefix(sig, "sha1=") {
                    continue
                }
                sig = strings.TrimPrefix(sig, "sha1=")
                mac := hmac.New(sha1.New, []byte(o.Secret))
                mac.Write(body)
                if sig == hex.EncodeToString(mac.Sum(nil)) {
                    ok = true
                    break
                }
            }
            if !ok {
                log.Printf("Ignoring '%s' event with incorrect signature", evName)
                return
            }
        }


        ev := github.PushEvent{}
        err = json.Unmarshal(body, &ev)
        if err != nil {
            log.Printf("Ignoring '%s' event with invalid payload", evName)
            http.Error(w, "Bad Request", http.StatusBadRequest)
            return
        }


        if ev.Repo.FullName == nil || *ev.Repo.FullName != o.App.Repo {
            log.Printf("Ignoring '%s' event with incorrect repository name", evName)
            http.Error(w, "Bad Request", http.StatusBadRequest)
            return
        }


        log.Printf("Handling '%s' event for %s", evName, o.App.Repo)


        err = o.App.Update()
        if err != nil {
            return
        }
    })
}

نبدأ بالتحقق من نوع الحدث event الذي ولّد هذه الحمولة payload، وبما أن حدث الدفع push هو الحدث الوحيد الذي يهمنا يمكننا تجاهل بقية الأحداث. لكن حتى لو ضبطنا خطاف الويب ليصدّر أحداث الدفع فقط، لا بد أن نتوقع استقبال نوع آخر على الأقل من الأحداث على نقطة اتصال خطافنا hook endpoint التي تمثل الرابط الذي تُرسَل إليه البيانات وهو الحدث Ping.

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

ملاحظة: ننصح بوضع حد أقصى لحجم البيانات الذي يمكن التعامل معه قبل قراءة محتوى الطلب كاملًا، لكننا لن نتطرق إلى هذا في مقالنا وسنركز على الجوانب الأساسية للأداة فقط. بعدها، نستخدم هيكل بيانات struct من مكتبة GitHub client library for Go لتفريغ أو تحويل unmarshal حمولة البيانات الواردة فيها، وبما أننا نعلم أنه حدث دفع push فيمكننا استخدام بنية حدث الدفع. ثم نستخدم مكتبة التشفير القياسية بصيغة Json لتفريغ الحمولة إلى نسخة من البنية، ستنفذ بعدها بعض عمليات التحقق من الصحة وفي حال خلوها من أية مشكلة ستُستدعى الدالة التي تبدأ بتحديث تطبيقنا.

تحديث التطبيق

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

تهيئة المستودع المحلي

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

// app.go


func (a *App) initRepo() error {
    log.Print("Initializing repository")


    err := os.MkdirAll(a.repoDir, 0755)
    // Check err


    cmd := exec.Command("git", "--git-dir="+a.repoDir, "init")
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    cmd = exec.Command("git", "--git-dir="+a.repoDir, "remote", "add", "origin", fmt.Sprintf("git@github.com:%s.git", a.Repo))
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    return nil
}

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

1. ننشئ مجلدًا للمستودع المحلي local repository في حال عدم وجوده.
2. نستخدم بالأمر git init لإنشاء مستودع فارغ bare repository
3. نضيف رابطًا للمستودع البعيد remote repository إلى مستودعنا المحلي ونسميه origin. بعد تهيئة المستودع سيكون جلب التغييرات عملية بسيطة.

جلب التغييرات

لجلب التغييرات من المستودع البعيد لن نحتاج سوى لاستدعاء أمر واحد، وذلك وفق ما يلي:

// app.go


func (a *App) fetchChanges() error {
    log.Print("Fetching changes")


    cmd := exec.Command("git", "--git-dir="+a.repoDir, "fetch", "-f", "origin", "master:master")
    cmd.Stderr = os.Stderr
    return cmd.Run()
}

إن تنفيذ أمر جلب التغييرات git fetch إلى مستودعنا المحلي بهذه الطريقة يجنبنا مشاكل عجز Git عن التقدم السريع fast-forward في بعض الحالات. وصحيح أننا لا ننصح بالاعتماد على عمليات الجلب الإجبارية، لكن إن احتجنا إلى تنفيذ عملية دفع إجبارية إلى مستودعنا البعيد يمكن اتباع هذه الطريقة.

تصريف التطبيق

بما أننا نستخدم سكربتات من حزم البناء buildpacks لتصريف compile تطبيقاتنا التي ننشرها، تتمثل مهمتنا بتنفيذ الخطوات البسيطة التالية من أجل تحضير وتصريف التطبيق بشكل آلي:

// app.go


func (a *App) compileApp() error {
    log.Print("Compiling application")


    _, err := os.Stat(a.appDir)
    if !os.IsNotExist(err) {
        err = os.RemoveAll(a.appDir)
        // Check err
    }
    err = os.MkdirAll(a.appDir, 0755)
    // Check err
    cmd := exec.Command("git", "--git-dir="+a.repoDir, "--work-tree="+a.appDir, "checkout", "-f", "master")
    cmd.Dir = a.appDir
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    buildpackDir, err := filepath.Abs("buildpack")
    // Check err


    cmd = exec.Command("bash", filepath.Join(buildpackDir, "bin", "detect"), a.appDir)
    cmd.Dir = buildpackDir
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    cacheDir, err := filepath.Abs("cache")
    // Check err
    err = os.MkdirAll(cacheDir, 0755)
    // Check err


    cmd = exec.Command("bash", filepath.Join(buildpackDir, "bin", "compile"), a.appDir, cacheDir)
    cmd.Dir = a.appDir
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr
    return cmd.Run()
}

لنشرح الكود أعلاه خطوة بخطوة:

• نبدأ بحذف المجلد السابق الخاص بتطبيقنا في حال وجوده، ثم ننشئ مجلدًا جديدًا ونسحب checkout محتويات الفرع الرئيسي master branch إليه
• نستخدم بعد ذلك سكريبت detect الموجود ضمن حزمة البناء التي ضبطناها لنحدد إذا كان باستطاعتنا معالجة التطبيق
• ننشئ مجلد لذاكرة التخزين المؤقتة ونسميه cache من أجل عملية تصريف حزمة البناء إذا دعت الحاجة لذلك، علمًا أن المجلد قد يكون موجودًا مسبقًا في حال أجرينا عمليات تصريف سابقة
• يمكننا في هذه المرحلة استدعاء سكربت التصريف المسمى compile من حزمة البناء وجعله يجهّز كل ما يحتاجه التطبيق قبل تشغيله عندما تُشغَّل حزم البناء بطريقة صحيحة فستتكمن من التعامل مع التخزين المؤقت caching وإعادة استخدام الموارد مسبقة التخزين

إعادة تشغيل التطبيق

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

// app.go


func (a *App) stopProcs() error {
    log.Print(".. stopping processes")


    for _, n := range a.nodes {
        err := n.Stop()
        if err != nil {
            return err
        }
    }


    return nil
}


func (a *App) startProcs() error {
    log.Print("Starting processes")


    err := a.readProcfile()
    if err != nil {
        return err
    }


    for _, n := range a.nodes {
        err = n.Start()
        if err != nil {
            return err
        }
    }


    return nil
}

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

// node.go


func NewNode(app *App, name string, no int, port int) (*Node, error) {
    logFile, err := os.OpenFile(filepath.Join(app.logsDir, fmt.Sprintf("%s.%d.txt", name, no)), os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
    if err != nil {
        return nil, err
    }


    n := &Node{
        App:     app,
        Name:    name,
        No:      no,
        Port:    port,
        stateCh: make(chan NextState),
        logFile: logFile,
    }


    go func() {
        for {
            next := <-n.stateCh
            if n.State == next.State {
                if next.doneCh != nil {
                    close(next.doneCh)
                }
                continue
            }


            switch next.State {
            case StateUp:
                log.Printf("Starting process %s.%d", n.Name, n.No)


                cmd := exec.Command("bash", "-c", "for f in .profile.d/*; do source $f; done; "+n.Cmd)
                cmd.Env = append(cmd.Env, fmt.Sprintf("HOME=%s", n.App.appDir))
                cmd.Env = append(cmd.Env, fmt.Sprintf("PORT=%d", n.Port))
                cmd.Env = append(cmd.Env, n.App.Env...)
                cmd.Dir = n.App.appDir
                cmd.Stdout = n.logFile
                cmd.Stderr = n.logFile
                err := cmd.Start()
                if err != nil {
                    log.Printf("Process %s.%d exited", n.Name, n.No)
                    n.State = StateUp


                } else {
                    n.Process = cmd.Process
                    n.State = StateUp
                }


                if next.doneCh != nil {
                    close(next.doneCh)
                }


                go func() {
                    err := cmd.Wait()
                    if err != nil {
                        log.Printf("Process %s.%d exited", n.Name, n.No)
                        n.stateCh <- NextState{
                            State: StateDown,
                        }
                    }
                }()


            case StateDown:
                log.Printf("Stopping process %s.%d", n.Name, n.No)


                if n.Process != nil {
                    n.Process.Kill()
                    n.Process = nil
                }


                n.State = StateDown
                if next.doneCh != nil {
                    close(next.doneCh)
                }
            }
        }
    }()


    return n, nil
}


func (n *Node) Start() error {
    n.stateCh <- NextState{
        State: StateUp,
    }
    return nil
}


func (n *Node) Stop() error {
    doneCh := make(chan int)
    n.stateCh <- NextState{
        State:  StateDown,
        doneCh: doneCh,
    }
    <-doneCh
    return nil
}

قد تبدو كتابة هذه الشيفرة البرمجية للوهلة الأولى أكثر الخطوات تعقيدًا حتى الآن، لذا دعنا نبسطها بتقسيمها إلى 4 أجزاء: يمثل مضمون دالة NewNode أول جزئين، فعندما تُستدعَى هذه الدالة تهيئ populate نسخة من هيكل بيانات Node بإعدادات محددة وتولّد برنامجًا routine بلغة غو Go مهمته إيقاف الإجرائيات المقابلة لهذه العقدة وتشغيلها. 

يمثل التابعان Start وStop في بنية Node الجزئين التاليين، حيث توقَف الإجرائية أو تشغَّل بتمرير رسالة message خلال قناة معينة تفيد بأن برنامج غو هذا الذي ينفَّذ على كل عقدة على حدة يستمر في المراقبة. يمكن تمرير رسالة لتشغيل إجرائية ورسالة مختلفة لإيقافها.

بما أن الخطوات الفعلية لإيقاف أو تشغيل إجرائية تحدث ضمن برنامج Go routine، فلا مجال لحدوث حالات تسابق race conditions بسبب الطريقة التي تتم بها إدارة تشغيل الأكواد بشكل متوازي يبدأ برنامج غو Go routine حلقة لا نهائية infinite loop تبقى بانتظار رسالة message في قناة stateCh، فإذا مرت الرسالة في القناة يُرسَل طلب إلى العقدة node بتشغيل الإجرائية ضمن case StateUp، ونستخدم برنامج باش Bash لتنفيذ هذا الأمر. 

أثناء هذه العملية تُضبط العقدة الأمر بحيث يستخدم متغيرات البيئة environment variables التي حددها المستخدم، ويعيد توجيه الخرج القياسي standard output ومجاري الخطأ error streams إلى ملف سجل log file سبق تحديده. أما لإيقاف الإجرائية ضمن case StateDown فإن البرنامج يوقفها قسريًا باستخدام أمر kill. في حال رغبنا بإيقاف الإجرائية تدريجيًا يمكننا جعله يرسل إشارة SIGTERM والانتظار بضع ثوان قبل إيقافها. يسهّل تابعا Start و Stop تمرير الرسالة المناسبة إلى القناة، إذ يرسل التابع Start رسالة إلى القناة بتشغيل الإجرائية ويعود، في حين ينتظر تابع Stop أن تتوقف الإجرائية قبل أن يعود.

جمع الخطوات السابقة

لم يتبقَ لنا الآن سوى إضافة جميع الشيفرات السابقة إلى الدالة الرئيسية لبرنامجنا، حيث سيُنفَّذ تحميل ملف الإعدادت وتحليله parse، وتحديث حزم البناء، ومحاولة تحديث تطبيقنا لمرة واحدة، وتشغيل خادم الويب ليصغي إلى حمولات حدث الدفع push event التي ترد من غيت هب.

// main.go


func main() {
    cfg, err := toml.LoadFile("config.tml")
    catch(err)


    url, ok := cfg.Get("buildpack.url").(string)
    if !ok {
        log.Fatal("buildpack.url not defined")
    }
    err = UpdateBuildpack(url)
    catch(err)


    // Read configuration options into variables repo (string), env ([]string) and procs (map[string]int)
    // ...


    app, err := NewApp(repo, env, procs)
    catch(err)


    err = app.Update()
    catch(err)


    secret, _ := cfg.Get("hook.secret").(string)


    http.Handle("/hook", NewHookHandler(&HookOptions{
        App:    app,
        Secret: secret,
    }))


    addr, ok := cfg.Get("core.addr").(string)
    if !ok {
        log.Fatal("core.addr not defined")
    }


    err = http.ListenAndServe(addr, nil)
    catch(err)
}

بما أن أداتنا تتطلب أن تكون حزم البناء مستودعات غيت بسيطة، فلن تنفذ دالة UpdateBuildpack المتضمنة في شيفرة buildpack.go سوى عمليتي نسخ git clone وسحب git pull لرابط المستودع عند الضرورة وذلك لتحديث النسخة المحلية من حزمة البناء.

تجربة الأداة

في حال لم نستنسخ المستودع بعد فيمكن استنساخه الآن. وإذا كان بGo distribution مثبتًا فيمكن البدء بتصريف compile البرنامج.

mkdir hopper
cd hopper
export GOPATH=`pwd`
go get github.com/hjr265/toptal-hopper
go install github.com/hjr265/toptal-hopper

لنطلع على ما تنفذه هذه الأوامر على التوالي:

• إنشاء مجلد وتسميته hopper
• الانتقال إليه
• جعله المجلد الخاص بمساحة العمل GOPATH
• جلب الشيفرة من غيت هب إلى جانب مكتبات غو Go الضرورية، وتصريف البرنامج لشيفرة binary يمكن إيجادها في مجلد ‎$GOPATH/bin

قبل استخدام هذه الأداة على خادم علينا أن ننشئ تطبيق ويب بسيط لنختبر هذه الأداة عليه. في حال رغبنا بالحصول على تطبيق جاهز قد أنشأ صاحب المقال تطبيق ويب بسيط يعرض عبارة "Hello World" بلغة Node.js ورفعه إلى مستودع غيت هب آخر يمكننا اشتقاقه fork وإعادة استخدامه لاختبار الأداة. علينا في الخطوة التالية رفع الشيفرة الثنائية المصرَّفة compiled binary إلى خادم وإنشاء ملف إعدادات في المجلد ذاته:

# config.tml 


[core]
addr = ":26590"
[buildpack]
url = "https://github.com/heroku/heroku-buildpack-nodejs.git"


[app]
repo = "hjr265/hopper-hello.js"


    [app.env]
    GREETING = "Hello"


    [app.procs]
    web = 1


[hook]
secret = ""

لنبدأ بأول خيار في ملف الإعدادات لدينا وهو core.addr الذي يتيح لنا ضبط منفذ HTTP لخادم الويب الداخلي لبرنامجنا، وقد اخترناه في مثالنا هذا ليكون 26590: وهذا يعني أن برنامجنا سيصغي إلى حمولات حدث الدفع عن طريق الرابط http://{host}:26590/hook.

عندما نضبط خطاف الويب في غيت هب ما عليك سوى تبديل {host} أي المضيف باسم النطاق أو عنوان IP الذي يشير إلى خادمنا. وفي حال كنا نستخدم جدار حماية على خادمنا لا ننسى أن فتح هذا المنفذ عليه. ثم نحدد حزمة البناء بإضافة رابط غيت الذي يشير إليها، ونستخدم في مثالنا حزمة بناء بلغة Node.js الخاصة بهيروكو Heroku.

أما خيار app فقد حددنا ضمنه في خيار repo الاسم الكامل لمستودع غيت هب الذي يستضيف شيفرة التطبيق البرمجية، وبما أن رابط استضافة شيفرة التطبيق المستخدم في مثالنا https://github.com/hjr265/hopper-hello.js حددنا الاسم الكامل للمستودع hjr265/hopper-hello.js، ثم حددنا بعض متغيرات البيئة الخاصة بالتطبيق وعدد كل نوع من الإجرائيات التي نحتاجها، وأنهينا الملف باختيار رمز سري لنتحقق من حمولات حدث الدفع الواردة.

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

ما علينا الآن سوى إعداد خطاف ويب في مستودع غيت هب لتصدير أحداث الدفع وتوجيهها إلى الرابط http://{host}:26590/hook. ولا ننسى بالطبع استبدال {host} باسم النطاق أو عنوان IP الذي يشير إلى الخادم. لنختبر عمل الأداة التي بنيناها، نحاول إجراء بعض التغييرات على التطبيق وندفعها إلى غيت هب، ستلاحظ حينها أن أداة الأتمتة ستبدأ العمل فورًا وتٌحدّث المستودع على الخادم وتصّرف التطبيق ثم تعيد تشغيله.

الخاتمة

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

ترجمة -وبتصرّف- للمقال Deploy Web Applications Automatically Using GitHub Webhooks لصاحبه Mahmud Ridwan.

اقرأ أيضًا

• كيف تنشر تطبيق ويب بلغة Go باستخدام خادم Nginx على أوبنتو 18.04
• نشر تطبيقات الويب الموجهة لبيئة الإنتاج
• نشر تطبيق Node.js على الويب: خدمة هيروكو (Heroku) مثالًا
• الفرق بين أداتي دوكر Docker وبودمان Podman

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

ما هو نظام تشغيل لينكس؟

يعد لينكس نظام تشغيل مفتوح المصدر طوره المبرمج الأمريكي لينوس بنديكت تورڤالدس Linus Benedict Torvalds ليكون شبيهًا لنظام يونكس UNIX-Like ومتعدد التوزيعات، فمن أشهر توزيعاته دبيان Debian، وأوبونتو Ubuntu، وفيدورا Fedora، كما تتوفر توزيعات لينكس مدفوعة أيضًا وأشهرها ريد هات إنتربرايز لينكس Red Hat Enterprise Linux وسينت أو إس CentOS.

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

لماذا نستخدم لينكس عند تطوير التطبيقات؟

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

1. لينكس مجاني ومفتوح المصدر

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

2. يدعم لينكس قابلية التوسع

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

3. لينكس نظام تشغيل مستقر

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

4. يتميز لينكس بالأمان الشديد

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

5. تتعدد توزيعات نظام تشغيل لينكس

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

6. يدعم لينكس مختلف أنواع التطبيقات

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

7. يدعم لينكس مجموعة واسعة من لغات البرمجة

يدعم نظام لينكس جميع لغات البرمجة المستخدمة في تطوير البرمجيات تقريبًا، مثل: لغة بايثون ولغة جافا ولغة ++C، كما يدعم أكثر من مصرف Compiler لكل لغة، ما يعطينا مرونة في اختيار لغة البرمجة المفضلة لنا لتطوير التطبيقات.

8. يحظى لينكس بشهرة كبيرة ومجتمع واسع

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

9. يدعم لينكس مختلف محررات الأكواد

أيًا كانت تفضيلاتنا الشخصية فلا بد أن نجد محرر أكواد مناسبًا لنا ومدعومًا من نظام تشغيل لينكس، فمثلًا إن أردنا محرر نصوص بسيطًا وسهل الاستخدام فيمكن استخدام محرر Gedit، وفي حال كنا نفضل استخدام بيئة تطوير متكاملة فيمكننا الاختيار بين مجموعة واسعة من بيئات التطوير مثل NetBeans أو Eclipse أو IntelliJ IDEA.

10. يتميز لينكس بالمرونة

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

أمثلة على تطبيقات ناجحة تستخدم لينكس

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

سكايب Skype

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

ستيم Steam

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

دروب بوكس Dropbox

لا بد أن أي شخص يستخدم منصات التخزين السحابي لتخزين ملفاته يعرف جيدًا برنامج دروب بوكس ويعرف مكانته وأصالته بين سائر منصات التخزين السحابي؛ وقد استُخدِم نظام تشغيل لينكس عند تطوير دروب بوكس أيضًا.

الخاتمة

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

ترجمة -وبتصرف- لمقال Top 10 Benefits of Linux for App Development لكاتبه Janus Atienza

اقرأ أيضًا

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

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

إنشاء سكربت باش لإدارة المستخدمين

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

سنُجهّز في البداية ملفًا نصيًّا يتضمن الأسماء hostnames أو عناوين IP للخوادم المطلوب إنشاء المستخدم عليها.

يبين الملف servers.txt التالي على سبيل المثال أسماء خمسة خوادم:

kabary@handbook:~$ cat servers.txt
server1
server2
server3
server4
server5

لقد استخدمنا أسماء الخوادم هنا بدلًا من عناوين IP الخاصة بها لأن هذه العناوين مخزنة لدينا في الملف "etc/hosts/" الذي يتضمن الاسم hostname وعنوان IP المقابل له، وتستطيع أيضًا استخدام ملف إعدادات SSH.

والآن لنفحص سكربت إنشاء المستخدمين adduser.sh التالي:

#!/bin/bash

servers=$(cat servers.txt)

echo -n "Enter the username: "
read name
echo -n "Enter the user id: "
read uid

for i in $servers; do
echo $i
ssh $i "sudo useradd -m -u $uid $name"
if [ $? -eq 0 ]; then
echo "User $name added on $i"
else
echo "Error on $i"
fi
done

عند تنفيذ السكربت سيطلب منا إدخال اسم المستخدم والمُعرِّف الخاص به، ثم سيتصل السكربت بكل خادم من الخوادم المحددة في الملف servers.txt السابق عبر اتصال SSH ويُنشئ عليه المستخدم الذي طلبناه.

ننصح بمطالعة المزيد عن تقنية SSH للاتصال بالخوادم البعيدة عبر مشاهدة الفيديو التالي:

لنلاحظ الآن طريقة عمل السكربت بعد التنفيذ:

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

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

• ضرورة استخدم مفاتيح مرور pass phrases فارغة لجلسات ssh، أو استخدم الوكيل ssh-agent لتمرير هويتنا إلى الخادم البعيد حتى لا نضطر لإدخال كلمة المرور في أثناء عمل السكربت
• الحرص على امتلاك حساب مستخدم فعال وعالي الصلاحيات يتمتع بأذونات الوصول إلى جميع الخوادم المطلوبة بدون متطلبات تتعلق بكلمة المرور

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

أتمتة عمليات النسخ الاحتياطي

النسخ الاحتياطي مهمة أساسية لا غنى عنها في كل منظومة، وكثيرًا ما نستخدم سكربتات باش لأتمتة المهام، يبين السكربت backup.sh التالي مثالًا عليها:

#!/bin/bash

backup_dirs=("/etc" "/home" "/boot")
dest_dir="/backup"
dest_server="server1"
backup_date=$(date +%b-%d-%y)

echo "Starting backup of: ${backup_dirs[@]}"

for i in "${backup_dirs[@]}"; do
sudo tar -Pczf /tmp/$i-$backup_date.tar.gz $i
if [ $? -eq 0 ]; then
echo "$i backup succeeded."
else
echo "$i backup failed."
fi
scp /tmp/$i-$backup_date.tar.gz $dest_server:$dest_dir
if [ $? -eq 0 ]; then
echo "$i transfer succeeded."
else
echo "$i transfer failed."
fi
done

sudo rm /tmp/*.gzecho "Backup is done."

لنشرح السكربت أعلاه: أنشأنا في البداية مصفوفة تدعى backup_dirs سنكتب فيها أسماء المجلدات التي نريد أخذ نسخ احتياطية عنها، ثم عرّفنا ثلاثة متغيرات:

• dest_dir: لتحديد مجلد الوجهة الذي ستُحفظ فيه النسخ الاحتياطية
• dest_server: لتعيين الخادم الهدف
• backup_time: لتحديد تاريخ بدء عملية النسخ الاحتياطي

وبعدها أنشأنا حلقة for ستمر على المجلدات الموجودة في المصفوفة "backup_dirs" واحدًا واحدًا وتضغط كل مجلد منها باستخدام التعليمة tar وتحتفظ بالنسخة المضغوطة في المجلد المؤقت tmp/، ثم تنسخها إلى الخادم الهدف بواسطة التعليمة scp، وبعد اكتمال النسخ ستُحذف الملفات المضغوطة من المجلد tmp/.

يبين الخرج التالي أمثلة على طريقة عمل السكربت:

kabary@handbook:~$ ./backup.sh
Starting backup of: /etc /home /boot
/etc backup succeeded.
etc-Aug-30-20.tar.gz 100% 1288KB 460.1KB/s   00:02
/etc transfer succeeded.
/home backup succeeded.
home-Aug-30-20.tar.gz 100% 2543KB 547.0KB/s   00:04
/home transfer succeeded.
/boot backup succeeded.
boot-Aug-30-20.tar.gz 100%  105MB 520.2KB/s   03:26
/boot transfer succeeded.
Backup is done.

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

kabary@handbook:~$ crontab -e
0    0   *   *   * /home/kabary/scripts/backup.sh

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

مراقبة المساحات التخزينية المتوفرة على القرص الصلب

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

kabary@handbook:~$ df -h / /apps /database
Filesystem Size  Used Avail Use% Mounted on
/dev/sda5 20G  7.9G   11G  44% /
/dev/mapper/vg1-applv 4.9G  2.4G  2.3G  52% /apps
/dev/mapper/vg1-dblv 4.9G  4.5G  180M  97% /database

كما نلاحظ هنا فالمساحة المخصصة لقاعدة البيانات database/ على نظام الملفات هذا تكاد تنفذ فنسبة استخدامها 97%، يمكنك عرض نسبة الاستخدام فقط بدون التفاصيل الأخرى بواسطة الأمر awk.

دعونا لنستعمل الآن هذين الأمرين في السكربت disk_space.sh كما يلي:

#!/bin/bash
filesystems=("/" "/apps" "/database")
for i in ${filesystems[@]}; do
usage=$(df -h $i | tail -n 1 | awk '{print $5}' | cut -d % -f1)
if [ $usage -ge 90 ]; then
alert="Running out of space on $i, Usage is: $usage%"
echo "Sending out a disk space alert email."
echo $alert | mail -s "$i is $usage% full" your_email
fi
done

يبدأ السكربت بإنشاء مصفوفة تدعى filesystems نكتب فيها أسماء مسارات أنظمة الملفات التي نود مراقبتها، ويوجد بعدها حلقة تكرار تُنَفذ عند كل عنصر من عناصر المصفوفة، وتستعلم عن نسبة استخدام المساحة التخزينية المخصصة له فإذا كانت أكبر من 90% سيُرسل لنا السكربت تنبيهًا عبر البريد الإلكتروني يخبرنا بأن المساحة على وشك النفاذ.

ملاحظة: لاستخدام السكربت السابق يتوجب استبدال your_email بعنوان بريد إلكتروني حقيقي.

سنحصل على هذا الخرج بعد تنفيذ السكربت:

kabary@handbook:~$ ./disk_space.sh
Sending out a disk space alert email.

وستكون رسالة البريد الإلكتروني مشابهة للتالي:

لنفترض الآن أننا نرغب بجدولة السكربت disk_space.sh ليعمل كل ست ساعات مرة باستخدام مهام cron، فسنكتب التالي:

kabary@handbook:~$ crontab -e
0    */6 *       *       * /home/kabary/scripts/disk_space.sh

الخاتمة

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

ترجمة -وبتصرف- للمقال Automation With Bash.

اقرأ أيضًا

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

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

سنتعلم في هذا المقال كيفية إنشاء الدوال البرمجية Functions في سكربتات باش وتمرير الوسطاء إليها وإرجاع النتائج منها، كما سنتعرف على الفرق بين المتغيرات المحلية والمتغيرات العامة، وعلى ماهية الدوال العودية Recursive Functions وكيفية تحقيقها في باش.

إنشاء الدوال في باش

توجد صيغتان للتصريح عن الدوال البرمجية في باش، وتُعدّ الصيغة التالية هي الأكثر استخدامًا:

function_name () {
commands
}

أما الصيغة الثانية الأقل شهرة، فهي تبدأ بالكلمة المفتاحية function يليها اسم الدالة كما يلي:

function function_name {
commands
}

ينبغي الانتباه إلى الأساسيات التالية عن التعامل مع الدوال:

• لا تعمل الدالة أبدًا ما لم نقم باستدعائها
• لا يمكننا استدعاء الدالة قبل تعريفها، لذا نجد أن تعريف الدالة في تسلسل تعليمات السكربت يأتي قبل أي استدعاء لها
• نستدعي الدالة بكتابة اسمها فقط
• نمرر الوسيط إن وجد مباشرة بعد اسم الدالة

لنلقِ نظرة على السكربت fun.sh التالي:

#!/bin/bash

hello () {
echo "Hello World"
}

hello
hello
hello

عرّفنا في بداية السكربت دالة تدعى hello وظيفتها عرض العبارة Hello World على الطرفية Terminal، ثم استدعينا الدالة ثلاث مرات بكتابة اسمها، لذا عند تنفيذ السكربت ستظهر العبارة Hello World على الشاشة ثلاث مرات كالتالي:

kabary@handbook:~$ ./fun.sh
Hello World
Hello World
Hello World

إرجاع القيم من الدالة في باش

لا تُرجع لنا دوال باش قيمًا عند استدعائها على عكس السائد في معظم لغات البرمجة، فعند انتهاء التنفيذ الدالة تُرجع حالة الخروج من آخر أمر مُنفذ وتُخَزَّن الحالة في المتغير الخاص ‎‏‎‏‏‎‏?$، فإذا كان التنفيذ ناجحًا سيأخذ المتغير ‎‏‏‎‏?$ القيمة صفر، وإذا فشل التنفيذه فسيأخذ قيمة عدد صحيح موجب آخر يقع ضمن المجال [1-255] حسب سبب الفشل.

لكن يمكننا استخدام التعليمة return لتغيير حالة الخروج من الدالة كما يوضح السكربت error.sh التالي:

#! /bin/bash

error () {
blabla
return 0
}

error
echo "The return status of the error function is: $?"

إذا شغلنا السكربت السابق سنحصل على الخرج التالي:

kabary@handbook:~$ ./error.sh
./error.sh: line 4: blabla: command not found
The return status of the error function is: 0

الكلمة blabla التي كتبناها في جسم الدالة () error ما هي إلّا كلمة عشوائية لا تمثل أي أمر برمجي، لذا فالتعليمية return 0 هي السبب في حصولنا على حالة خروج صفرية من الدالة () error أي حالة خروج ناجحة، وبدونها ما كانت الدالة ستعطينا هذه النتيجة لأن blabla حتمًا سترجع رسالة خطأ مفادها لم يتم العثور على الأمر.

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

ملاحظة: لنتذكر دائمًا أن return تعني إنهاء تنفيذ الدالة والخروج منها.

تمرير الوسطاء إلى دالة باش

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

يوضح السكربت iseven.sh التالي طريقة القيام بذلك:

#!/bin/bash

iseven () {
if [ $(($1 % 2)) -eq 0 ]; then
echo "$1 is even."
else
echo "$1 is odd."
fi
}

iseven 3
iseven 4
iseven 20
iseven 111

تُميّز الدالة () iseven في الكود أعلاه بين الأعداد الزوجية والأعداد الفردية، وقد استدعيناها أربع مرات في السكربت وفي كل استدعاء مررنا لها عددًا مختلفًا، وطالما أننا كتبنا الوسيط مباشرة بعد الدالة فهو الوسيط الأول وسيُشير له المتغير $1.

لنختبر الآن طريقة عمل السكربت:

kabary@handbook:~$ ./iseven.sh
3 is odd.
4 is even.
20 is even.
111 is odd.

وسطاء الدالة مغايرين لوسطاء السكربت، وكل منهم يعمل في مستوى خاص مختلف عن الآخر، سيبين السكربت التالي funarg.sh الفرق:

#!/bin/bash

fun () {
echo "$1 is the first argument to fun()"
echo "$2 is the second argument to fun()"
}

echo "$1 is the first argument to the script."
echo "$2 is the second argument to the script."

fun Yes 7

والآن لنشغل السكربت مع تمرير وسيطين له، ونلاحظ النتيجة:

kabary@handbook:~$ ./funarg.sh Cool Stuff
Cool is the first argument to the script.
Stuff is the second argument to the script.
Yes is the first argument to fun()7 is the second argument to fun()

لقد استخدمنا المتغيرين $1 و $2 لوظيفتين، للتعبير عن الوسيطين الأول والثاني مرة للدالة ومرة للسكربت، وعند استدعائهما من داخل الدالة كان لهما معنى مختلف عن وسطاء السكربت.

المتغيرات المحلية والمتغيرات العامة داخل سكربتات باش

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

يوضح السكربت domain.sh bash التالي الفرق بينهما:

#!/bin/bash

v1='A'
v2='B'

myfun() {
local v1='C'
v2='D'
echo "Inside myfun(): v1: $v1, v2: $v2"
}

echo "Before calling myfun(): v1: $v1, v2: $v2"
myfun
echo "After calling myfun(): v1: $v1, v2: $v2"

عرّفنا في بداية السكربت متغيرين عامين Global هما v1 و v2، ثم في داخل الدالة ()myfun عرّفنا متغير محلي Local يدعى v1 باستخدام الكلمة المفتاحية local، وعدّلنا قيمة المتغير العام v2، نلاحظ أننا نستطيع استخدام الاسم نفسه لمتغيرات محلية مختلفة في دوال مختلفة.

إذا شغّلنا السكربت الآن سنحصل على النتيجة التالية:

kabary@handbook:~$ ./scope.sh
Before calling myfun(): v1: A, v2: B
Inside myfun(): v1: C, v2: D
After calling myfun(): v1: A, v2: D

نستنتج من المثال السابق ما يلي:

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

الدوال العودية Recursive Functions

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

تُعدّ دالة حساب العاملي factorial function مثال تقليدي على التعادوية، يوضحه السكربت factorial.sh التالي:

#!/bin/bash

factorial () {
if [ $1 -le 1 ]; then
echo 1
else
last=$(factorial $(( $1 -1)))
echo $(( $1 * last ))
fi
}

echo -n "4! is: "
factorial 4
echo -n "5! is: "
factorial 5
echo -n "6! is: "
factorial 6

تبدأ كل دالة عودية بتعريف حالة أساسية أو حدّية base case وعند الوصول إليها تنتهي الاستدعاءات الذاتية للدالة أي تنتهي العودية، والحالة الحدّية للدالة ()factorial في مثالنا السابق الواحد حيث أن عاملي العدد 1 هو العدد 1:

if [ $1 -le 1 ]; then
echo 1

لنوضح الآن الحالة العودية في دالة حساب العاملي: إن حساب العاملي لأي عدد صحيح موجب مثل n يساوي قيمة العدد n مضروبًا بحساب العاملي للعدد الأصغر منه n-1 وهكذا وفق المعادلة التالية:

factorial(n) = n * factorial(n-1)

وقد استخدمنا هذه المعادلة في كتابة الحالة العودية recursive case للدالة السابقة وفق التالي:

last=$(factorial $(( $1 -1)))
echo $(( $1 * last ))

لنشغّل السكربت ونتأكد من صحة النتائج:

kabary@handbook:~$ ./factorial.sh
4! is: 24
5! is: 120
6! is: 720

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

الخاتمة

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

ترجمة -وبتصرف- للمقال Using Functions in Bash.

اقرأ أيضًا

• المقال السابق: الحلقات في باش Bash
• أنشئ برنامجك النصي الأول على صدفة باش Bash
• استخدام الدوال في سكربات الصدفة Shell Scripts
• عمليات السلاسل النصية في باش Bash