DevOps مفتوح المصدر على نطاق واسع: تشغيل GitLab بنفسك

laptop screen showing code in a busy room

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

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

ما هو GitLab

ليس استضافة Git مع إضافات ملحقة بها. تطبيق Rails، وقاعدة PostgreSQL، وRedis، وGitaly لتخزين المستودعات، وSidekiq للمهام الخلفية، وسجل حاويات، معبّأة معاً كنظام واحد يغطي إدارة الإصدارات ومراجعة الشيفرة وتتبع المهام وCI/CD وسجلات الحزم والحاويات والفحص الأمني والنشر.

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

الحقيقة المعمارية المهمة هي نفسها في استضافة التحليلات بنفسك عبر Matomo أو أتمتة التسويق عبر Mautic أو مراسلة الفرق عبر Mattermost: يعمل حيث تضعه. مستودعاتك، وسجلات CI عندك، ومخرجات البناء عندك، وقاعدة بياناتك.

صورة الترخيص، بصراحة

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

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

الجزء المفاجئ: حزمة لينكس التي يثبّتها الجميع تقريباً هي بناء Enterprise Edition، وبلا مفتاح ترخيص فإنها تعمل بمستوى Free وتتصرف كأنها Community Edition. أي أنك لا تشغّل التوزيعة المرخّصة بـ MIT ما لم تكن قد اخترت حزمة CE عن قصد. عملياً نادراً ما يهم ذلك، لكن إن كان سبب استضافتك الذاتية سياسة صارمة للمصادر المفتوحة لا التحكم في البيانات، فالأمر يهم كثيراً، ولا يكاد أحد يتحقق منه.

المستويات التجارية هي Free، وPremium بـ 29 دولاراً لكل مستخدم شهرياً بفوترة سنوية، وUltimate بسعر حسب الطلب. يضيف Premium خطوط CI/CD متقدمة وإدارة مشاريع أفضل ودعماً ذا أولوية. ويضيف Ultimate حزمة الأمان والامتثال: اختبار أمان التطبيقات، وأمان سلسلة التوريد، وفحص الاعتماديات. وكلا المستويين المدفوعين يتضمنان الآن رصيد GitLab Credits لميزات الذكاء الاصطناعي، 12 دولاراً لكل مستخدم شهرياً في Premium و24 في Ultimate.

وإليك الحقيقة التي تغيّر الحساب لمعظم الفرق، وهي النقيض الدقيق لحالة Mattermost: المستوى Free في الإدارة الذاتية لا يضع حداً لعدد المستخدمين. أما سقف الخمسة مستخدمين الذي سمع عنه الناس فينطبق فقط على المجموعات الخاصة في GitLab.com. المستضاف ذاتياً يعطيك في Free مستخدمين بلا حد، وإدارة إصدارات، وCI/CD، وسجلات، وتأتي أنت بالتخزين والمنفّذين. ومؤسسة من مئة مهندس يمكنها العمل عليه بالكامل.

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

طريقة الإعداد

تركيب صغير

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

PostgreSQL هي قاعدة البيانات الوحيدة المدعومة. وأي إصدار يعتمد على إصدار GitLab لديك: 17.x تريد PostgreSQL من 14.14 إلى 16.x، و18.x تريد من 16.5 إلى 17.x، و19.x تريد 17.x. ويُنصح بـ Redis 7.2 والحد الأدنى 7.0، وValkey 7.2 يصلح بديلاً. نسخ مستقلة فقط، لأن نسخ Redis العنقودية وبلا خوادم غير مدعومة.

ثبّت بحزمة لينكس. هناك مخططات Helm ومشغّل Operator وصور Docker ومسار من الشيفرة المصدرية، لكن حزمة لينكس هي الخيار الأنضج وهي ما يعمل عليه GitLab.com نفسه. تأتي ومعها PostgreSQL وRedis وSidekiq، فتكفي آلة واحدة وملف إعداد واحد للحصول على نسخة عاملة.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

وبعد gitlab-ctl reconfigure واحد تصبح لديك نسخة. اضبط external_url بشكل صحيح من المرة الأولى، فهذه القيمة تنتهي محفورة في عناوين الاستنساخ وخطافات الويب وعناوين السجل.

تركيب إنتاجي

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

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

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

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

الأمور الثلاثة التي تسير على نحو خاطئ

كل ما سبق موجود في التوثيق. أما هذه فهي التي تُنتج الحوادث.

نسختك الاحتياطية لا تحتوي ما يفك تشفيرها

هذه أهم فقرة في المقال.

يلتقط gitlab-backup create الكثير: قاعدة البيانات، والمستودعات، وكائنات LFS، ومخرجات CI وسجلات المهام، وصور السجل، وويكي المشاريع، والملفات المرفوعة، ومحتوى Pages، وحالة Terraform، والمقتطفات. أما ما لا يلتقطه فهو مجلد الإعدادات، وتحديداً /etc/gitlab/gitlab-secrets.json.

هذا الملف يحمل مفتاح تشفير قاعدة البيانات. والتوثيق حاسم بشأن النتيجة: إن فقدته، فلن يستطيع تطبيق GitLab فك تشفير أي قيمة مشفّرة في قاعدة البيانات. أي متغيرات CI/CD، والرموز، وأسرار التحقق بخطوتين، وبيانات اعتماد التكاملات. ستكون لديك نسخة احتياطية تُستعاد إلى نسخة عاجزة عن قراءة أسرارها.

ومستثنى أيضاً: /etc/gitlab/gitlab.rb، ومفاتيح وشهادات TLS، ومفاتيح مضيف SSH، ومحتوى التخزين الكائني حين يكون مُعدّاً. وهذا الأخير يوقع تحديداً بمن أحسن الاختيار المعماري ثم افترض أن النسخة الاحتياطية تغطيه.

فانسخ /etc/gitlab على حدة، واحفظه في مكان غير مكان الأرشيف، لأنه مفتاح الأرشيف، ثم استعد كل شيء على آلة للاستعمال مرة واحدة وتأكد أنك تستطيع تسجيل الدخول وقراءة متغير CI. النسخة الاحتياطية غير المجرّبة ليست نسخة احتياطية، وفي حالة GitLab فالاستعادة غير المجرّبة تكون عادةً معطوبة.

لا يمكنك الترقية بقفزة واحدة

لدى GitLab محطات ترقية إلزامية، وهذا ليس إرشاداً. لا يمكنك تخطيها. ومنذ 17.5 صارت المحطات متوقعة وتقع عند x.2 وx.5 وx.8 وx.11، فالانتقال من 18.0 إلى 19.2 يعني المرور بـ 18.2 و18.5 و18.8 و18.11 و19.0.

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

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

التكلفة الحقيقية عند المنفّذين

خادم GitLab لا ينفّذ CI عندك. فـ GitLab Runner مكوّن منفصل تثبّته وتضبطه وتدفع ثمنه، على بنية تحتية توفّرها أنت. والمستوى Free في الإدارة الذاتية لا يتضمن أي دقائق حوسبة إطلاقاً، لأنه لا توجد قدرة حوسبة مرفقة تُعطى: أنت تأتي بآلاتك.

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

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

الانتقال من GitHub

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

والثغرات الموثّقة تستحق التخطيط لها. فالمنظمات والمجموعات لا تنتقل، ما يعني أن بنية المجموعات ستصممها أنت بدل أن ترثها، وهذا تحسين في الغالب. وتدفقات GitHub Actions لا تتحول إلى GitLab CI. وتعليقات طلبات السحب السابقة لعام 2017 تُستورد كمواضيع منفصلة بسبب قيود واجهة GitHub، والمستودعات التي تتجاوز نحو 30 ألف تعليق تحتاج تفعيل الطريقة البديلة لاستيراد التعليقات.

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

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

الزاوية الأوروبية

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

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

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

متى لا يستحق العناء

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

وإن كانت مؤسستك غارقة في منظومة GitHub فاحسب بصدق ما ستخسره. فـ Actions والسوق ومجرد أُلفة المنصة لدى كل مرشح توظّفه أصول حقيقية، والجواب ليس تلقائياً أن GitLab يفوز.

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

كيف نساعد

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

إن أردت نسخة GitLab مقاسة بصدق، أو ترحيلاً من GitHub يخطط له من سبق أن أنجز إعادة كتابة CI، أو مراجعةً لما إذا كانت نسختك الاحتياطية الحالية ستصمد أمام عطل حقيقي، فاكتب إلى office@c9group.dev. والمزيد عن عملنا في البنية التحتية على صفحة تحسين تكاليف AWS.

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

نُشر في: ٨ أغسطس ٢٠٢٦ التصنيفات: DevOps، المصادر المفتوحة، الخصوصية