Selectel تشرح تثبيت Jenkins على خادم سحابي: من الموارد إلى الـ pipeline

يتوقف البناء والنشر اليدويان عن العمل حين ينمو المشروع أسرع من الفريق. فكل تغيير في قاعدة الشيفرة يستدعي الخطوات نفسها: البناء، ثم تشغيل الاختبارات، ثم الإطلاق. وكلما زاد عدد هذه الخطوات ارتفع احتمال الخطأ. وقد نشر زافور، مطوّر الواجهات الأمامية في Selectel، على «هابر» دليلًا لمعالجة هذه المشكلة عبر Jenkins على خادم افتراضي سحابي: من اختيار الموارد إلى pipeline يعمل.

صدرت المادة في المدونة المؤسسية لـ Selectel، ويُطلب الخادم فيها من لوحة تحكم هذا المزوّد. لكن المخطط نفسه لا يكاد يعتمد على المزوّد، ويمكن نقله إلى أي آلة افتراضية تعمل بنظام Linux.

لماذا Jenkins وليس أداة CI المدمجة

تتمتع GitHub Actions وGitLab CI بميزة واضحة: فهما تعملان بجوار المستودع. لكن الثمن هو الارتباط بالمنصة. أما Jenkins فتصميمه مختلف. فهو خادم أتمتة مفتوح المصدر ومستقل، يجلب الشيفرة من أي مستودع Git ولا يهتم بمكان استضافته.

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

بحسب وصف الكاتب، يستطيع Jenkins:

• بناء المشاريع من أي مستودع Git؛
• تشغيل الاختبارات الآلية؛
• بناء صور Docker؛
• نشر التطبيقات على الخوادم المستهدفة.

ماذا في الدليل

يسير المقال وفق الترتيب المعتاد لإقامة خادم CI:

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

تحليل الموارد هنا أكثر فائدة مما يبدو. فـ Jenkins مكتوب بلغة Java، وتوصي وثائق المشروع للفرق الصغيرة بما لا يقل عن 4 غيغابايت من الذاكرة العشوائية ونحو 10 غيغابايت من القرص. أما الحد الأدنى البالغ 256 ميغابايت فلا يصلح إلا للتجربة. وتزيد عمليات البناء مع Docker والاختبارات الثقيلة متطلبات المعالج والقرص. وإذا جرى التقتير في مواصفات الخادم، فسيتعطل الـ pipeline بسبب نقص الذاكرة في أسوأ لحظة ممكنة. لا ترد أرقام الدليل نفسه في الإعلان، لذا ارجعوا إلى النص الكامل للمقال.

أين تكمن المطبّات

يستغرق تثبيت Jenkins دقائق معدودة. أما المشكلات فتبدأ بعد ذلك. تتطلب الإصدارات الحديثة نسخة حديثة من Java (17 أو 21)، وتُفتح واجهة الويب افتراضيًا على المنفذ 8080 دون HTTPS. وإذا تُركت هكذا، يصبح الخادم متاحًا لكل من يعرف عنوانه. كما يجب تحديث الإضافات: فعبرها تحديدًا تُسدّ الثغرات الأمنية بانتظام.

وثمة فخ آخر هو تخزين الإعدادات. فالـ pipeline الذي يُبنى بالنقر في الواجهة يستحيل مراجعته أو التراجع عنه. لذلك من الأفضل وصفه في Jenkinsfile وحفظه في المستودع بجوار الشيفرة.

ماذا نفعل بهذا عمليًا

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

• ابدؤوا بخادم صغير وراقبوا الذاكرة أثناء عمليات البناء؛
• أغلقوا الوصول إلى الواجهة عبر HTTPS مع تقييد الوصول بعنوان IP أو عبر VPN؛
• صِفوا الـ pipeline في Jenkinsfile واحفظوه في Git؛
• انقلوا عمليات البناء الثقيلة إلى وكلاء (agents) منفصلين عندما يعجز خادم واحد عن تحمّل الحمل.

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