كيفية استضافة مستودع صور Docker وبناء صور Docker باستخدام نسخة GitLab المدارة ذاتيًا على Ubuntu 20.04

تقنية الحاويات تقدمت بشكل كبير في مجال تكنولوجيا تطوير البرمجيات كأكثر الطرق قبولاً لتعبئة ونشر التطبيقات في بيئات السحاب. وقد استلزم ذلك الحاجة إلى التكامل المستمر (CI) والنشر المستمر (CD) اللذين يمثلان جوانب محددة لـ DevOps. يستخدم مطورو ومهندسو البرمجيات الحاويات لتحقيق جانب CI/CD في بنية البرمجيات. الحاوية هي في الأساس منصة حوسبة محمولة ومستقلة بذاتها ومعبأة بالكامل. في حين أن هناك العديد من منصات الحاويات على الويب، فإن Docker هو الأكثر شيوعًا.

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

GitLab هو مستودع قائم على الويب لـ Git وهو أكثر من مجرد أداة للتحكم في الإصدارات. فهو يوفر أدوات DevOps للتكامل والنشر المستمر، وتتبع المشكلات، وسجلات صور Docker، والمزيد. ويقدم ثلاثة خيارات: GitLab Community Edition (CE)، وGitLab Enterprise Edition (EE)، وGitLab SaaS. GitLab CE و GitLab EE هما حلول مدارة ذاتيًا تتيح لك تنزيل وتثبيت وإدارة نسخة GitLab بنفسك. GitLab SaaS تستضيفه شركة GitLab inc، ولا داعي للقلق بشأن تثبيت أي شيء لاستخدامه.

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

في هذا الدرس، سنوضح كيفية بناء صورة Docker بسيطة واستضافتها باستخدام نسخة GitLab مستضافة ذاتيًا (سواء كنت تستخدم إصدار Community Edition أو Enterprise Edition – فإن تسلسل الخطوات هو نفسه).

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

لمتابعة كل خطوة في هذا الدرس، يرجى التأكد من أن لديك GitLab CI runner وخادم GitLab مستضاف ذاتيًا كما هو موضح أدناه.

1. خادم GitLab آمن

سنستخدم هذا لتخزين الكود المصدري، وتشغيل مهام CI/CD واستضافة سجل صور Docker. يجب أن يكون لديك خادم يحتوي على الأقل على 2 CPU من النوى و 4GB من RAM كما هو موصى به من قِبل GitLab لتثبيت نسخة GitLab مدارة ذاتيًا. ستحتاج أيضًا إلى اسم نطاق مسجل لتوجيهه إلى الخادم حيث سنستخدمه للحصول على شهادة SSL من Let’s Encrypt لتأمين الخادم. أدناه بعض الروابط التي يمكنك اتباعها لإعداد نسخة GitLab مستضافة ذاتيًا.

• قم بتسجيل اسم نطاق مع أي مسجل أسماء نطاقات من اختيارك و قم بتوجيهه إلى CloudSigma.
• اتبع هذا الدرس من أجل الإعداد الأولي لخادم Ubuntu, وإضافة مستخدم ليس بجذر (non-root)، و تمكين جدار حماية UFW الخاص بـ Ubuntu.
• أخيرًا، اتبع هذا الدرس لتثبيت وتكوين نسخة GitLab مستضافة ذاتيًا.

2. GitLab CI runner

يعد GitLab CI runner ضروريًا لتشغيل الوظائف المؤتمتة مقابل حالات الاختبار الخاصة بك. الدرس الخاص بـ كيفية إعداد خطوط أنابيب التكامل المستمر لـ GitLab على Ubuntu 20.04 يعطيك نظرة عامة على خادم GitLab CI ويوضح لك كيفية تشغيل الوظائف. اتبع الخطوات الواردة في الدرس لإعداد خدمة GitLab CI runner إذا لم تكن قد قمت بذلك بالفعل. يحتوي الدرس على تطبيق تجريبي Node.js مع حالات اختبار – سنستخدمه في هذا الدرس.

الآن، لنبدأ!

الخطوة 1: تكوين GitLab CI Runner ذو صلاحيات (Privileged)

في الدرس الخاص بكيفية إعداد GitLab CI Runner، قمنا بتكوين GitLab runner باستخدام sudo gitlab-runner register الأمر الذي سمح لنا بإضافة المعلمات المطلوبة بشكل تفاعلي. ومع أن هذا نجح في حالة الاستخدام السابقة لدينا، والتي كانت تشغيل عمليات البناء والاختبارات في حاويات Docker معزولة، إلا أنه قد لا يتعامل مع بناء صور Docker. يتطلب بناء صور Docker أن يمتلك الـ runner وصولاً كاملاً إلى خدمة Docker. يمكنك تحقيق هذا التكوين باستخدام الـ docker-in-docker صورة لتشغيل الوظائف. يتضمن هذا التكوين منح الـ runner وضع تشغيل ذو امتيازات.

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

سنقوم بإنشاء runner آخر بوضع التشغيل ذو الامتيازات. سيكون هذا الـ runner مخصصاً للمشروع بسبب الآثار الأمنية المذكورة أعلاه. سيقبل الوظائف من مشروع Node Pipeline الذي أنشأناه في الدرس التعليمي حول كيفية إعداد خطوط أنابيب CI المستمرة باستخدام GitLab.

أول شيء يجب عليك فعله هو التحقق من أن Shared Runners معطلة في المشروع. من صفحة المشروع الخاصة بمشروع Node Pipeline، انقر فوق Settings في القائمة اليسرى السفلية وحدد CI/CD في القائمة الفرعية:

ابحث عن زر Expand في قسم Runners وانقر فوقه للكشف عن تفاصيل حول الـ runners المتاحة:

انقر فوق مفتاح التبديل لـ Disable Shared Runners لهذا المشروع. إذا كنت قد أضفت runner مخصصاً للمشروع في القسم السابق، فقم بتعطيله أيضاً. سنقوم بإضافة runner مخصص للمشروع ذو امتيازات لتشغيل الوظائف لهذا المشروع. يضمن هذا عدم انتهائنا بأخطاء بناء في حال قام GitLab بتعيين الوظائف عشوائياً لـ runners لم يتم تسجيلها بوضع تشغيل ذو امتيازات. في لقطة الشاشة أعلاه، وتحت علامة التبويب Specific runners، يجب أن ترى رمز التسجيل الخاص بمشروعك. قم بتدوينه لأنك ستستخدمه أدناه.

ملاحظة: يمكن أيضاً تعيين runner مخصص للمشروع لمشاريع أخرى من قسم Admin panel > Runners. عند تحديد runner من قائمة الـ runners، ستصل إلى صفحة تكوين الـ runner. مرر لأسفل لعرض القسم Restrict projects for this runner:

حان الوقت لتشغيل الطرفية الخاصة بك. إذا لم تكن قد قمت بالخطوات الواردة في الدرس التعليمي حول كيفية إعداد خطوط أنابيب التكامل المستمر لـ GitLab على Ubuntu 20.04، فخذ استراحة من هذا الدرس التعليمي واتبع الخطوات حتى تتمكن من الحصول على خادم يحتوي على خدمة GitLab CI runner. خلاف ذلك، قم بالاتصال عبر SSH بـ خادم GitLab CI runner باستخدام مستخدم sudo الخاص بك للخطوات التالية.

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

يوضح هذا المخرج تسجيلاً ناجحاً:

للتحقق من أن نسخة GitLab الخاصة بك قد التقطت الـ runner، ارجع إلى المتصفح، وقم بتحديث صفحة Settings > CI/CD. قم بتوسيع قسم Runners ويجب أن ترى الـ runner الخاص بك تحت Specific Runners:

اختيارياً، إذا ذهبت إلى Admin Panel (من خلال النقر على زر Menu في الشريط العلوي واختيار Admin)، ثم حدد Runners في خيارات القائمة:

يجب أن تصل إلى هذه الصفحة التي تعرض جميع الـ runners المتاحة والمتصلة بـ نسخة GitLab الخاصة بك، سواء الـ runners المشتركة أو المخصصة للمشروع:

حتى هذه النقطة، قمت بإعداد runner بنجاح يمكنه بناء صور Docker.

الخطوة 2: تكوين سجل Docker الخاص بـ GitLab

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

قم بالتمرير لأسفل حتى ترى Container Registry Settings:

قم بإلغاء تعليق السطر الذي يحتوي على registry_external_url واضبطه على اسم نطاق مثيل GitLab الخاص بك، مع تحديد المنفذ 8888 في النهاية:

بعد ذلك، نحتاج إلى تحديد المكان الذي سيجد فيه السجل شهادات Let’s Encrypt عن طريق إضافة السطور التالية. تذكر تعديلها باستخدام اسم نطاق مثيل GitLab الفعلي الخاص بك:

بمجرد الانتهاء، احفظ الملف وأغلقه. أدخل الأمر التالي في الطرفية لإعادة تكوين GitLab:

بعد ذلك، انتظر بضع ثوانٍ حتى ينتهي تنفيذ الأمر. يجب أن ترى المخرجات التالية في حال النجاح:

بعد ذلك، نحتاج إلى التأكد من أن جدار الحماية (ufw) يسمح بمرور حركة المرور إلى منفذ السجل الذي قمنا بتعيينه باستخدام الأمر:

بعد ذلك، تحتاج إلى اختبار أن Docker Registry يعمل عن طريق تسجيل الدخول إليه من جهاز آخر مثبت عليه Docker باستخدام الأمر docker login. إذا لم تكن قد قمت بإعداد Docker في بيئتك المحلية، فيمكنك الاتصال عبر SSH بخادم تشغيل GitLab CI (runner) لأنه يحتوي بالفعل على Docker مثبتًا. بعد ذلك، قم بتنفيذ الأمر التالي، مع تحديد اسم نطاق مثيل GitLab الخاص بك بالطبع:

ستظهر مخرجاتك رسالة Login Succeeded كالتالي:

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

الخطوة 3: تعديل ملف gitlab-ci.yml وبناء صورة Docker

للمتابعة في هذه الخطوة، يجب أن يكون لديك مشروع Node Pipeline على مثيل GitLab الخاص بك. إليك عرض المشروع على GitLab:

لقد تحدثنا عن gitlab-ci.yml باعتباره الملف الذي يقرأه مشغل GitLab CI (runner) عند تشغيله لمعرفة كيفية بناء تطبيقك وإجراء الاختبارات الآلية. نحتاج إلى تعديل هذا الملف لإضافة تعليمات لبناء صور Docker. يمكنك اختيار تعديل هذا الملف مباشرة داخل واجهة GitLab. يمكنك أيضًا استنساخه على جهازك المحلي وتعديله باستخدام المحرر المفضل لديك، ثم إجراء commit و git push للعودة إلى GitLab. للاختصار، سنستخدم مثيل GitLab.

انقر فوق الملف لفتحه، ثم انقر فوق زر تعديل :

يؤدي هذا إلى فتح الملف ليكون جاهزًا للتعديل. احذف كل شيء من الملف وأضف الكود التالي:

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

دعنا نفهم ما يفعله الكود الذي أضفناه إلى ملف .gitlab-ci.yml . يخبر السطر الأول GitLab باستخدام صورة Docker-in-Docker الرسمية ويربطها بخدمة docker-in-docker (docker:dind). ثم نقوم بتعريف المراحل لـ build, ، test، و release. وتقوم مرحلة build ببناء الصورة باستخدام التعليمات الموجودة في Dockerfile ثم رفعها إلى Docker Registry

الذي قمنا بإعداده في خطوة سابقة.عندما تنجح مرحلة build، تقوم مرحلة test بتنزيل الصورة، وتشغيلها كحاوية، وتنفيذ الأمر npm test لإجراء اختبارات تلقائية بداخلها. إذا نجحت مرحلة test، تتولى مرحلة release المسؤولية. في مرحلة الإصدار، يتم تنزيل الصورة وتمييزها بـ node_pipeline:latest

. ثم يتم دفعها مرة أخرى إلى السجل.هذا مجرد تكوين أساسي لمشروع تجريبي. بالنسبة لمشاريعك الحقيقية، قد يكون لديك مراحل أخرى، على سبيل المثال , staging، production، وما إلى ذلك. عند حفظ الملف بعد التعديل، يتم تشغيل خط الأنابيب (pipeline). ثم يبدأ في تشغيل المهام. عد إلى صفحة

Node Pipeline. يجب أن ترى أن المهمة قيد التشغيل حاليًا:انقر على أيقونة مؤشر

CI

لعرض المراحل المختلفة للمهمة:كما ترى في لقطة الشاشة أعلاه، كانت جميع المراحل ناجحة وفقًا لأيقونات علامة الاختيار الخضراء. يمكنك النقر فوق كل مرحلة لعرض مخرجات المهمة: من القائمة اليسرى، انقر على Packages& Registries:

وحدد Container Registry:

يؤدي هذا إلى فتح صفحة تعرض صور Docker المتاحة للمشروع المحدد. يجب أن تظهر الصورة التي قمنا ببنائها وإصدارها في القائمة مع العلامة

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

node_pipeline

latest8090. إذا قمت بفتح متصفحك والانتقال إلى your-IP-address:8090 يفترض أن ترى الصفحة معروضة:

إذا كنت تستطيع رؤية مثل هذه الصفحة في متصفحك، فهذا يعني أنك قمت ببناء صورة Docker بنجاح ومشاركتها على Docker Registry. في المستقبل، إذا قمت بإجراء أي تغييرات على master ، فإن المراحل المحددة في ملف .gitlab-ci.yml ستعمل، وإذا نجحت، فسيتم إعادة بناء صورة Docker جديدة بالوسم latest ودفعها إلى السجل.

الخاتمة

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

هذا دليل تعليمي تمهيدي، يمنحك الأساسيات للبناء عليها. يرجى اتباع وثائق GitLab الرسمية لمعرفة المزيد عن GitLab. يمكن أن يوفر هذا الرابط معلومات حول GitLab Container Registry.

لمزيد من الموارد حول استخدام Docker، قد ترغب في الاطلاع على المزيد من البرامج التعليمية على مدونتنا:

• مشاركة البيانات بين حاويات Docker
• إعداد سجل Docker خاص على Ubuntu 18.04
• كيفية مشاركة البيانات بين حاوية Docker والمضيف
• تنظيف موارد Docker - الصور، والحاويات، ووحدات التخزين

حوسبة سعيدة!