بروكسي لـ GitLab: كيفية إعداد الوصول للفريق وCI/CD بدون انقطاع

```html

GitLab هي منصة شهيرة لتخزين الكود وإدارة عمليات DevOps، والتي تستخدمها آلاف الفرق حول العالم. ولكن ماذا تفعل إذا تم حظر الوصول إلى GitLab على مستوى مزود الخدمة أو الشبكة المؤسسية أو حتى الدولة بأكملها؟ والأسوأ من ذلك - عندما تتعطل خط أنابيب CI/CD في منتصف الليل فقط لأن الـ runner لا يمكنه الوصول إلى المستودع.

في هذه المقالة، سنناقش كيفية إعداد بروكسي لـ GitLab على مستوى عميل Git، وGitLab Runner، والخادم المؤسسي - بحيث يعمل الفريق بالكامل بشكل مستقر من أي نقطة في العالم.

لماذا تحتاج إلى بروكسي لـ GitLab: سيناريوهات حقيقية

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

السيناريو 1: تم حظر GitLab بواسطة المزود أو على مستوى الدولة

في بعض البلدان والشبكات المؤسسية، يتم تقييد الوصول إلى gitlab.com. يفتح المطور الطرفية، ويكتب git pull - ويتلقى timeout. يعمل البروكسي في هذه الحالة كوسيط: يتم توجيه حركة المرور ليس مباشرة إلى gitlab.com، ولكن عبر خادم وسيط في بلد لا توجد فيه قيود.

السيناريو 2: فريق موزع في دول مختلفة

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

السيناريو 3: CI/CD runner لا يمكنه الوصول إلى التبعيات الخارجية

يقوم GitLab Runner بتشغيل خط الأنابيب، وفي مرحلة npm install أو pip install، يتعطل كل شيء - لأن الخادم الذي يعمل عليه الـ runner موجود في شبكة مغلقة بدون وصول مباشر إلى الإنترنت. يسمح البروكسي للـ runner بالحصول على التبعيات الخارجية دون فتح الوصول الكامل إلى الإنترنت للخادم بأكمله.

السيناريو 4: GitLab المستضاف ذاتيًا خلف جدار ناري مؤسسي

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

السيناريو 5: مراقبة وتدقيق حركة المرور

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

من المهم فهمه قبل الإعداد:

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

ما هو نوع البروكسي المناسب لـ GitLab

يعمل GitLab عبر بروتوكولات HTTPS وSSH. هذا يحدد على الفور أنواع البروكسي القابلة للتطبيق وأيها غير قابلة للتطبيق. دعنا نستعرض الخيارات.

نوع البروكسي	البروتوكول	مناسب لـ GitLab	متى تستخدمه
بروكسي HTTP/HTTPS	HTTP، HTTPS	✓ نعم	Git عبر HTTPS، واجهة ويب GitLab
بروكسي SOCKS5	TCP (أي)	✓ نعم (أفضل خيار)	Git عبر HTTPS وSSH، CI/CD
بروكسي SOCKS4	TCP	~ جزئي	فقط إذا لم يكن هناك SOCKS5
بروكسي شفاف	HTTP	✗ لا	غير مناسب - لا يتجاوز الحجب

للاستخدام مع GitLab، الخيار الأمثل هو SOCKS5. يعمل على مستوى TCP، لذا يقوم بتوجيه كل من اتصالات HTTPS (واجهة الويب، git clone عبر HTTPS) وSSH (git push/pull عبر SSH على المنفذ 22 أو 443) بشكل جيد.

بروكسي سكني مقابل بروكسي مراكز البيانات لـ GitLab

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

إذا كان IP المؤسسي الخاص بك قد تم إدراجه في قائمة الحظر الخاصة بـ GitLab (يحدث ذلك أحيانًا أثناء الفحص العدواني أو بعد حوادث أمنية)، فعندئذٍ يجب النظر في بروكسي سكني - حيث أن عناوين IP الخاصة بها تعود لمستخدمين حقيقيين في المنازل ونادرًا ما يتم حظرها من قبل المنصات.

إعداد البروكسي لعميل Git (عالميًا)

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

الخيار A: بروكسي HTTPS لـ Git

إذا كنت تعمل مع GitLab عبر HTTPS (عنوان المستودع يبدأ بـ https://)، نفذ في الطرفية:

# إعداد بروكسي HTTP عالمي
git config --global http.proxy http://عنوان_البروكسي_الخاصة_بك:المنفذ

# إذا كان البروكسي يتطلب مصادقة
git config --global http.proxy http://اسم_المستخدم:كلمة_المرور@عنوان_البروكسي_الخاصة_بك:المنفذ

# لبروكسي SOCKS5 (موصى به)
git config --global http.proxy socks5://عنوان_البروكسي_الخاصة_بك:المنفذ

# تحقق من تطبيق الإعداد
git config --global --get http.proxy

الخيار B: بروكسي فقط لـ gitlab.com (لا يؤثر على مستودعات أخرى)

إذا كنت لا تريد أن يتم تطبيق البروكسي على جميع عمليات Git (على سبيل المثال، يعمل GitHub أو Bitbucket بشكل طبيعي)، يمكنك إعداد البروكسي فقط لنطاق معين:

# بروكسي فقط لـ gitlab.com
git config --global http.https://gitlab.com.proxy socks5://عنوان_البروكسي_الخاصة_بك:المنفذ

# أو لخادم GitLab المستضاف ذاتيًا
git config --global http.https://git.yourcompany.com.proxy socks5://عنوان_البروكسي_الخاصة_بك:المنفذ

الخيار C: SSH عبر البروكسي (لمن يعمل عبر SSH)

إذا كنت تقوم باستنساخ المستودعات عبر SSH ([email protected]:...)، يتم إعداد البروكسي في ملف تكوين SSH، وليس في Git. افتح الملف ~/.ssh/config وأضف:

# لنظام Linux/macOS - عبر nc (netcat)
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand nc -X 5 -x عنوان_البروكسي_الخاصة_بك:المنفذ %h %p

# لنظام Windows - عبر connect.exe (Git for Windows)
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand connect -S عنوان_البروكسي_الخاصة_بك:المنفذ %h %p

بعد الإعداد، تحقق من الاتصال باستخدام الأمر ssh -T [email protected]. إذا تم الإعداد بشكل صحيح، سترى رسالة ترحيب من GitLab.

كيفية تعطيل البروكسي عندما لم يعد مطلوبًا

# إزالة البروكسي العالمي
git config --global --unset http.proxy

# إزالة البروكسي لنطاق معين
git config --global --unset http.https://gitlab.com.proxy

بروكسي لـ GitLab Runner وخطوط CI/CD

GitLab Runner هو وكيل يقوم بتنفيذ المهام من .gitlab-ci.yml. إذا كان الـ runner موجودًا في شبكة مغلقة أو على خادم مع وصول محدود إلى الإنترنت، يجب إعداد البروكسي بشكل منفصل. إعدادات عميل Git للمطور لن تساعد هنا - يعمل الـ runner على جهاز آخر.

الطريقة 1: متغيرات البيئة في تكوين الـ runner

افتح ملف تكوين GitLab Runner (عادةً /etc/gitlab-runner/config.toml) وأضف متغيرات البيئة في قسم [runners.env]:

[[runners]]
  name = "my-runner"
  url = "https://gitlab.com/"
  token = "رمز_التوكن_الخاصة_بك"
  executor = "shell"
  environment = [
    "HTTP_PROXY=http://عنوان_البروكسي_الخاصة_بك:المنفذ",
    "HTTPS_PROXY=http://عنوان_البروكسي_الخاصة_بك:المنفذ",
    "NO_PROXY=localhost,127.0.0.1,نطاقك_الداخلي.com"
  ]

بعد تغيير التكوين، أعد تشغيل الـ runner: sudo gitlab-runner restart

الطريقة 2: المتغيرات في .gitlab-ci.yml (على مستوى خط الأنابيب)

إذا لم تكن مسؤولاً عن الـ runner أو كنت ترغب في إعداد البروكسي فقط لمشروع معين، أضف المتغيرات مباشرة في ملف خط الأنابيب:

variables:
  HTTP_PROXY: "http://عنوان_البروكسي_الخاصة_بك:المنفذ"
  HTTPS_PROXY: "http://عنوان_البروكسي_الخاصة_بك:المنفذ"
  NO_PROXY: "localhost,127.0.0.1,.internal.company.com"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - npm install   # الآن ستذهب عبر البروكسي
    - npm run build

الطريقة 3: المتغيرات في إعدادات مشروع GitLab (بدون دفع إلى المستودع)

أفضل طريقة للبيانات الحساسة (بروكسي يتطلب مصادقة): انتقل إلى الإعدادات → CI/CD → المتغيرات لمشروعك وأضف المتغيرات HTTP_PROXY، HTTPS_PROXY، NO_PROXY كمتغيرات محمية (masked). ستكون متاحة تلقائيًا في جميع خطوط الأنابيب، ولكن لن تكون مرئية في السجلات.

بروكسي لـ Docker executor

إذا كان الـ runner يستخدم Docker executor، فإن الحاويات بشكل افتراضي لا ترث إعدادات البروكسي الخاصة بالمضيف. يجب إما إضافة المتغيرات إلى config.toml في قسم [runners.docker]، أو إنشاء ملف /etc/systemd/system/docker.service.d/proxy.conf على المضيف الذي يعمل عليه الـ runner:

[Service]
Environment="HTTP_PROXY=http://عنوان_البروكسي_الخاصة_بك:المنفذ"
Environment="HTTPS_PROXY=http://عنوان_البروكسي_الخاصة_بك:المنفذ"
Environment="NO_PROXY=localhost,127.0.0.1"

بعد ذلك: sudo systemctl daemon-reload && sudo systemctl restart docker

بروكسي لخادم GitLab المستضاف ذاتيًا

إذا كنت تدير خادم GitLab الخاص بك (المثبت عبر Omnibus أو Helm)، فإن البروكسي مطلوب حتى يتمكن GitLab نفسه من الوصول إلى الخدمات الخارجية: إرسال الإشعارات، الاتصال بأنظمة CI الخارجية، تحميل صور المستخدمين، التكامل مع Jira أو Slack.

الإعداد في gitlab.rb (تثبيت Omnibus)

افتح ملف /etc/gitlab/gitlab.rb وأضف أو قم بإلغاء تعليق الأسطر التالية:

# بروكسي لـ GitLab (Omnibus)
gitlab_rails['env'] = {
  "http_proxy" => "http://عنوان_البروكسي_الخاصة_بك:المنفذ",
  "https_proxy" => "http://عنوان_البروكسي_الخاصة_بك:المنفذ",
  "no_proxy" => "localhost,127.0.0.1,نطاقك_الداخلي"
}

# إذا كان البروكسي يتطلب مصادقة:
gitlab_rails['env'] = {
  "http_proxy" => "http://اسم_المستخدم:كلمة_المرور@عنوان_البروكسي_الخاصة_بك:المنفذ",
  "https_proxy" => "http://اسم_المستخدم:كلمة_المرور@عنوان_البروكسي_الخاصة_بك:المنفذ",
  "no_proxy" => "localhost,127.0.0.1"
}

بعد تغيير التكوين، قم بتطبيق الإعدادات: sudo gitlab-ctl reconfigure

إعداد الاتصالات الصادرة عبر منطقة الإدارة

في GitLab 15.0+، تم إضافة إمكانية إعداد البروكسي مباشرة عبر واجهة الويب: انتقل إلى منطقة الإدارة → الإعدادات → الشبكة → الطلبات الصادرة. هنا يمكنك تحديد البروكسي للويب هوكس الصادرة وتقييد نطاقات IP التي يمكن لـ GitLab الوصول إليها. هذا مفيد للأمان - يمنع هجمات SSRF عبر الويب هوكس.

تنظيم الوصول لجميع أعضاء الفريق عبر البروكسي

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

النهج 1: خادم بروكسي مؤسسي

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

النهج 2: مرآة (mirror) المستودع

يدعم GitLab مرآة المستودعات. يمكن إعداد GitLab المستضاف ذاتيًا في الشبكة الداخلية كمرآة لـ gitlab.com. يعمل المطورون مع الخادم الداخلي، ويتزامن مع الخارجي عبر البروكسي. هذا يقلل من الاعتماد على جودة اتصال البروكسي لكل مطور.

النهج 3: الإعداد التلقائي عبر dotfiles أو سكربت onboarding

بالنسبة للفرق التي يقوم فيها كل مطور بإعداد البيئة بنفسه، من المناسب إنشاء سكربت onboarding يقوم تلقائيًا بتطبيق الإعدادات المطلوبة لـ Git. يتم تخزين السكربت في المستودع المؤسسي ويتم تشغيله عند إعداد مكان العمل الجديد.

#!/bin/bash
# setup-git-proxy.sh - تشغيله عند إعداد مكان العمل الجديد

PROXY_HOST="proxy.company.com"
PROXY_PORT="3128"

echo "إعداد بروكسي Git للوصول إلى GitLab..."
git config --global http.https://gitlab.com.proxy "socks5://${PROXY_HOST}:${PROXY_PORT}"
git config --global http.sslVerify true
echo "تم! تحقق: git config --global --list | grep proxy"

قائمة التحقق لنشر الفريق

• تحديد ما إذا كان البروكسي مطلوبًا على مستوى المطورين، أو الـ runners، أو خادم GitLab (أو الثلاثة)
• اختيار نوع البروكسي: SOCKS5 لأقصى توافق
• إعداد NO_PROXY لجميع النطاقات والخدمات الداخلية
• التحقق من عمل مفاتيح SSH عبر البروكسي (خطوة منفصلة!)
• توثيق الإعدادات في ويكي المؤسسة
• إنشاء سكربت onboarding للموظفين الجدد
• إعداد مراقبة توفر خادم البروكسي

مشاكل شائعة وحلولها

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

المشكلة 1: مشكلة شهادة SSL: غير قادر على الحصول على شهادة الجهة المصدرة المحلية

تحدث هذه الخطأ عندما يقوم خادم البروكسي (خاصةً المؤسسي) بتنفيذ فحص SSL - حيث يستبدل شهادة GitLab بشهادته الخاصة. لا يثق Git بهذه الشهادة. الحل: إضافة الشهادة الجذرية المؤسسية إلى الموثوق بها.

# حل مؤقت (للتصحيح، ليس للإنتاج!)
git config --global http.sslVerify false

# الحل الصحيح: إضافة الشهادة المؤسسية
git config --global http.sslCAInfo /المسار/إلى/corporate-ca-bundle.crt

المشكلة 2: البروكسي يعمل لـ HTTPS، لكن SSH لا يعمل

هذه حالة كلاسيكية: تم إعداد http.proxy في Git، وعمل استنساخ HTTPS، لكن عمليات SSH لا تزال لا تمر. السبب: حركة مرور SSH لا تمر عبر بروكسي HTTP. يجب إعداد ~/.ssh/config بشكل منفصل كما هو موضح في قسم عميل Git.

بديل: التبديل للعمل مع GitLab عبر HTTPS بدلاً من SSH. للقيام بذلك، قم بتغيير عنوان الـ remote:

# تحقق من الـ remote الحالي
git remote -v

# تغيير من SSH إلى HTTPS
git remote set-url origin https://gitlab.com/username/repo.git

المشكلة 3: يتعطل خط CI/CD في مرحلة استنساخ المستودع

يقوم الـ runner باستنساخ المستودع مباشرة من GitLab، باستخدام رمز التوكن. إذا كان الـ runner موجودًا خلف بروكسي، يجب أن يتم الاستنساخ أيضًا عبر البروكسي. تأكد من أن المتغيرات HTTP_PROXY و HTTPS_PROXY تم إعدادها في config.toml، وليس فقط في .gitlab-ci.yml - حيث يتم تطبيق المتغيرات من ملف CI بعد الاستنساخ، وليس قبله.

المشكلة 4: يعمل البروكسي، لكنه بطيء جدًا

إذا كانت عمليات push/pull تعمل، لكنها تستغرق 5-10 مرات أكثر من الوقت المعتاد، قد تكون المشكلة في عرض النطاق الترددي لخادم البروكسي أو موقعه الجغرافي. عند العمل مع مستودعات كبيرة (أكثر من 100 ميجابايت)، من المهم اختيار بروكسي ذو زمن انتقال منخفض وعرض نطاق ترددي عالي. بروكسي مراكز البيانات في هذه الحالة يفضل على السكنية - حيث يوفر قناة أكثر استقرارًا.

المشكلة 5: تتطلب المصادقة عبر البروكسي إدخال كلمة المرور مرة أخرى

إذا كان البروكسي يتطلب مصادقة أساسية، وكان Git يطلب كلمة المرور في كل مرة، قم بإعداد مساعد الاعتماد:

# macOS - استخدام Keychain
git config --global credential.helper osxkeychain

# Windows - استخدام Windows Credential Manager
git config --global credential.helper manager

# Linux - التخزين المؤقت لمدة ساعة واحدة
git config --global credential.helper "cache --timeout=3600"

الخاتمة والتوصيات

إعداد البروكسي لـ GitLab هو مهمة تتطلب العمل على عدة مستويات في نفس الوقت. يكفي للمطور على جهاز العمل الخاص به كتابة بضعة أسطر في تكوين Git أو SSH. بالنسبة لـ CI/CD، يجب إضافة متغيرات البيئة إلى تكوين الـ runner أو إعدادات المشروع. ولـ GitLab المستضاف ذاتيًا - تحديث gitlab.rb وإعادة تكوين الإعدادات.

القواعد الرئيسية التي ستساعد في تجنب معظم المشاكل:

• استخدم SOCKS5 - فهو يعمل مع كل من HTTPS وSSH
• دائمًا قم بإعداد NO_PROXY للخدمات الداخلية
• لا تقم بإيقاف التحقق من SSL في الإنتاج - أضف الشهادة المؤسسية
• لـ CI/CD، قم بتثبيت البروكسي في config.toml، وليس فقط في .gitlab-ci.yml
• وثق الإعدادات - سيشكرك المطور الجديد في الفريق

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