بروكسي لخطوط CI/CD: إعداد GitHub Actions وGitLab CI وJenkins للوصول إلى الموارد المغلقة

هل يتعطل خط الأنابيب الخاص بك مع خطأ 403 Forbidden أو Connection refused عند محاولة الوصول إلى واجهة برمجة تطبيقات خارجية أو تنزيل تبعية؟ من المحتمل أن تكون المشكلة هي أن عنوان IP الخاص بخادم CI/CD الخاص بك محظور من جانب المورد. يحل البروكسي هذه المشكلة: تقوم بتوجيه حركة المرور عبر عنوان IP المطلوب ويعمل خط الأنابيب بدون انقطاع. في هذه المقالة - تعليمات خطوة بخطوة لـ GitHub Actions وGitLab CI وJenkins.

لماذا البروكسي في CI/CD: سيناريوهات حقيقية

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

الوصول إلى الموارد المحدودة جغرافيًا

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

تحديد معدل الطلبات والحظر حسب IP

تستخدم العدائين السحابيين لـ GitHub Actions عناوين IP من نطاقات Microsoft Azure. تعرف العديد من واجهات برمجة التطبيقات العامة هذه النطاقات وتطبق عليها حدود صارمة - أو تحظرها تمامًا. على سبيل المثال، فإن استخراج البيانات العامة، والطلبات إلى واجهات برمجة التطبيقات الخارجية أثناء الاختبارات، وتنزيل التوزيعات من CDN المحدودة - كل ذلك يتعطل بانتظام بسبب عناوين IP للعدائين السحابيين. يسمح التدوير عبر البروكسي بتجاوز تحديد معدل الطلبات.

اختبار التكامل مع مواقع حقيقية

إذا كانت اختبارات التكامل الخاصة بك تتصل بمواقع ويب حقيقية أو أسواق (Wildberries، Ozon، Avito، Amazon)، فإن هذه المواقع ترى نفس عنوان IP من العداء في كل مرة يتم فيها التشغيل وتقوم بحظره بسرعة. يسمح البروكسي مع تدوير IP للاختبارات بالمرور بشكل مستقر دون CAPTCHA أو حظر.

الوصول إلى الموارد الداخلية المؤسسية

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

اختبار التكامل الإعلاني والتسويقي

غالبًا ما تقوم الفرق التي تعمل مع واجهات برمجة تطبيقات إعلانات Facebook أو TikTok أو Google بأتمتة إنشاء الحملات عبر CI/CD. هذه المنصات لديها قواعد صارمة بشأن IP: يمكن حظر الطلبات من عناوين IP لمراكز البيانات أو تتطلب تحققًا إضافيًا. تجعل البروكسي السكنية في خط الأنابيب الطلبات تبدو مشابهة لحركة مرور المستخدم العادية.

أي نوع من البروكسي تختار لخط الأنابيب

يعتمد اختيار نوع البروكسي على المهمة. هناك ثلاثة خيارات مناسبة لخطوط أنابيب CI/CD - لكل منها مزاياها وقيودها:

إعداد البروكسي في GitHub Actions

GitHub Actions هي الأداة الأكثر شعبية في CI/CD اليوم. يتم إعداد البروكسي هنا من خلال متغيرات البيئة وأسرار المستودع. دعنا نفصلها خطوة بخطوة.

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

لا تكتب أبدًا اسم المستخدم وكلمة المرور للبروكسي مباشرة في ملف YAML لخط العمل. استخدم أسرار GitHub:

1. افتح المستودع → الإعدادات → الأسرار والمتغيرات → الإجراءات
2. اضغط على سر مستودع جديد
3. أنشئ سرًا PROXY_URL بقيمة على شكل http://user:[email protected]:port

الخطوة 2: استخدم متغيرات البيئة في خط العمل

معظم الأدوات (curl، wget، npm، pip، Maven) تلتقط تلقائيًا متغيرات البيئة القياسية HTTP_PROXY، HTTPS_PROXY و NO_PROXY. مثال على خط العمل:

name: Build with Proxy

on: [push]

env:
  HTTP_PROXY: ${{ secrets.PROXY_URL }}
  HTTPS_PROXY: ${{ secrets.PROXY_URL }}
  NO_PROXY: localhost,127.0.0.1,internal.company.com

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Run integration tests
        run: npm test

      - name: Call external API
        run: |
          curl -v https://api.example.com/data

الخطوة 3: بروكسي SOCKS5 في GitHub Actions

إذا كنت تستخدم SOCKS5 (موصى به لمعظم المهام)، فإن متغيرات البيئة القياسية غير كافية - تحتاج إلى نفق محلي. استخدم الأداة proxychains أو قم بإعداد microsocks:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Setup SOCKS5 proxy tunnel
        run: |
          sudo apt-get install -y proxychains4
          echo "socks5 proxy.host 1080 user password" >> /etc/proxychains4.conf

      - name: Run command through SOCKS5
        run: proxychains4 curl https://restricted-resource.com/api

إعداد البروكسي لأدوات معينة

تتجاهل بعض الأدوات المتغيرات النظامية وتتطلب إعدادًا منفصلًا:

إعداد البروكسي في GitLab CI

يوفر GitLab CI عدة مستويات لتعيين متغيرات البيئة: على مستوى المشروع، أو المجموعة، أو المثيل. وهذا يجعل إدارة البروكسي أكثر مرونة مقارنةً بـ GitHub Actions.

الخطوة 1: أضف المتغيرات إلى متغيرات CI/CD في GitLab

1. افتح المشروع → الإعدادات → CI/CD → قسم المتغيرات
2. اضغط على إضافة متغير
3. أضف المتغير PROXY_URL بنوع Masked (يخفي القيمة في السجلات)
4. القيمة: http://user:[email protected]:port

الخطوة 2: استخدم المتغيرات في .gitlab-ci.yml

variables:
  HTTP_PROXY: $PROXY_URL
  HTTPS_PROXY: $PROXY_URL
  NO_PROXY: "localhost,127.0.0.1,.internal.company.com"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20-alpine
  script:
    - npm ci
    - npm run build

integration_tests:
  stage: test
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest tests/integration/

deploy:
  stage: deploy
  script:
    - curl -X POST https://api.external-service.com/deploy
      -H "Authorization: Bearer $DEPLOY_TOKEN"
      -d '{"version": "$CI_COMMIT_SHA"}'

البروكسي فقط لبعض الوظائف

إذا كان البروكسي مطلوبًا في بعض الأماكن فقط (على سبيل المثال، فقط للاختبارات التكاملية، وليس للبناء)، قم بتعيين المتغيرات على مستوى وظيفة معينة، وليس على مستوى عالمي:

integration_tests:
  stage: test
  variables:
    HTTP_PROXY: $PROXY_URL
    HTTPS_PROXY: $PROXY_URL
  script:
    - pytest tests/integration/

build:
  stage: build
  # هنا لم يتم تعيين البروكسي - اتصال مباشر
  script:
    - npm ci && npm run build

GitLab Runner المستضاف ذاتيًا: إعداد البروكسي على مستوى العداء

إذا كنت تستخدم GitLab Runner الخاص بك، يمكنك تعيين البروكسي عالميًا في تكوين العداء. افتح الملف /etc/gitlab-runner/config.toml وأضف إلى قسم [runners.env]:

[[runners]]
  name = "my-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "docker"
  environment = [
    "HTTP_PROXY=http://user:[email protected]:port",
    "HTTPS_PROXY=http://user:[email protected]:port",
    "NO_PROXY=localhost,127.0.0.1"
  ]

هذا مريح عندما يجب أن تستخدم جميع خطوط الأنابيب على هذا العداء البروكسي - لا حاجة لتدوينه في كل .gitlab-ci.yml.

إعداد البروكسي في Jenkins

Jenkins هو الأكثر مرونة من بين الأدوات الثلاث، ولكنه أيضًا الأكثر تعقيدًا في الإعداد. يمكن تعيين البروكسي هنا على عدة مستويات: عالميًا لكل Jenkins، أو لخط أنابيب معين، أو لخطوة فردية.

الطريقة 1: إعدادات البروكسي العالمية في Jenkins

1. افتح إدارة Jenkins → النظام
2. ابحث عن قسم تكوين بروكسي HTTP
3. املأ الحقول: الخادم، المنفذ، اسم المستخدم، كلمة المرور
4. في حقل لا بروكسي مضيف، حدد العناوين الداخلية مفصولة بفواصل
5. اضغط على اختبار URL للتحقق واحفظ

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

الطريقة 2: البروكسي في خط الأنابيب القابل للتصريح عبر البيئة

pipeline {
    agent any

    environment {
        HTTP_PROXY  = credentials('proxy-url-credential')
        HTTPS_PROXY = credentials('proxy-url-credential')
        NO_PROXY    = 'localhost,127.0.0.1,internal.company.com'
    }

    stages {
        stage('Build') {
            steps {
                sh 'npm ci'
                sh 'npm run build'
            }
        }

        stage('Integration Tests') {
            steps {
                sh 'pytest tests/integration/'
            }
        }

        stage('Deploy') {
            steps {
                sh '''
                    curl -X POST https://api.external-service.com/deploy \
                    -H "Authorization: Bearer ${DEPLOY_TOKEN}" \
                    -d "version=${GIT_COMMIT}"
                '''
            }
        }
    }
}

الخطوة 3: أضف بيانات اعتماد البروكسي إلى بيانات اعتماد Jenkins

1. افتح إدارة Jenkins → بيانات الاعتماد → النظام → بيانات الاعتماد العالمية
2. اضغط على إضافة بيانات اعتماد
3. النوع: نص سري
4. المعرف: proxy-url-credential
5. السري: http://user:[email protected]:port

الطريقة 3: البروكسي عبر معلمات JVM لمشاريع Java

إذا كان خط الأنابيب الخاص بك يبني مشروع Java (Maven، Gradle)، فقد لا تعمل متغيرات البيئة النظامية - تستخدم JVM خصائص النظام الخاصة بها. أضفها إلى JAVA_OPTS:

environment {
    JAVA_OPTS = '-Dhttps.proxyHost=proxy.host -Dhttps.proxyPort=8080 -Dhttps.proxyUser=user -Dhttps.proxyPassword=password -Dhttp.nonProxyHosts=localhost|127.0.0.1|*.internal.com'
}

البروكسي داخل حاويات Docker في خط الأنابيب

تقوم معظم خطوط أنابيب CI/CD الحديثة بتشغيل الخطوات داخل حاويات Docker. تمرير البروكسي إلى الحاوية هو مهمة منفصلة يتم حلها بعدة طرق.

تمرير البروكسي عبر --build-arg عند بناء الصورة

إذا كان البروكسي مطلوبًا فقط أثناء بناء صورة Docker (على سبيل المثال، لتثبيت الحزم داخل Dockerfile)، استخدم معلمات البناء:

# في .github/workflows/build.yml أو .gitlab-ci.yml
docker build \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --build-arg HTTPS_PROXY=$HTTPS_PROXY \
  --build-arg NO_PROXY=$NO_PROXY \
  -t myapp:latest .

# في Dockerfile
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

RUN apt-get update && apt-get install -y curl
RUN npm ci

الإعداد العالمي لخادم Docker للبروكسي

على العدائين المستضافين ذاتيًا، يمكن إعداد البروكسي لخادم Docker بالكامل - بحيث تحصل جميع الحاويات تلقائيًا على البروكسي دون تغييرات في Dockerfile:

# /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://user:[email protected]:port"
Environment="HTTPS_PROXY=http://user:[email protected]:port"
Environment="NO_PROXY=localhost,127.0.0.1,registry.internal.com"

# تطبيق التغييرات:
# systemctl daemon-reload
# systemctl restart docker

الأمان: كيفية تخزين بيانات اعتماد البروكسي

تعتبر بيانات اعتماد البروكسي أسرارًا مثل مفاتيح API أو كلمات مرور قواعد البيانات. تعني تسربها أنه يمكن لأي شخص استخدام البروكسي الخاص بك على حسابك. إليك قواعد التخزين الآمن:

قائمة التحقق الأمنية

• ✅ لا تكتب أبدًا اسم المستخدم/كلمة المرور للبروكسي مباشرة في ملفات YAML لخط الأنابيب
• ✅ استخدم المتغيرات المخفية في GitLab والأسرار المشفرة في GitHub - فهي مخفية في السجلات
• ✅ في Jenkins، استخدم نوع نص سري أو اسم المستخدم مع كلمة المرور في مخزن بيانات الاعتماد
• ✅ أضف NO_PROXY للعناوين الداخلية - يجب ألا تمر حركة المرور إلى بنيتك التحتية عبر البروكسي
• ✅ قم بتدوير كلمات مرور البروكسي بانتظام - قم بتحديثها فقط في مخزن الأسرار، دون تغيير كود خط الأنابيب
• ✅ استخدم مصادقة IP للبروكسي (قائمة بيضاء لعنوان IP للعداء) حيثما كان ذلك مدعومًا - هذا أكثر أمانًا من كلمة المرور
• ✅ تحقق من سجلات البروكسي بحثًا عن نشاط غير عادي

تنسيق URL للبروكسي: ماذا تضع في أي مكان

الأخطاء الشائعة وكيفية إصلاحها

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

خطأ: يتطلب المصادقة عبر البروكسي (407)

خطأ: فشل التحقق من شهادة SSL

خطأ: انتهاء المهلة عبر البروكسي

خطأ: الأداة تتجاهل متغيرات HTTP_PROXY

خطأ: الخدمات الداخلية أيضًا تمر عبر البروكسي

الخاتمة

إعداد البروكسي في خط أنابيب CI/CD ليس مهمة لمرة واحدة، بل هو جزء من بنية الأتمتة الصحيحة. لقد ناقشنا الأدوات الثلاث الرئيسية: GitHub Actions (من خلال الأسرار ومتغيرات البيئة)، GitLab CI (من خلال المتغيرات مع التمويه) وJenkins (من خلال مخزن بيانات الاعتماد وخط الأنابيب القابل للتصريح). المبادئ الأساسية هي نفسها للجميع: عدم تخزين بيانات الاعتماد في الكود، واستخدام NO_PROXY للعناوين الداخلية، واختيار نوع البروكسي وفقًا للمهمة المحددة.

يعتبر اختيار نوع البروكسي الصحيح أمرًا حيويًا لاستقرار خط الأنابيب. لتنزيل التبعيات والاتصال بواجهات برمجة التطبيقات القياسية، يكفي استخدام بروكسي مراكز البيانات السريعة. إذا كان خط الأنابيب الخاص بك يقوم بإجراء اختبارات تكامل على مواقع حقيقية، أو يعمل مع منصات إعلانات (Facebook Ads API، TikTok Ads API) أو يتصل بالأسواق - استخدم بروكسي سكنية: يتم اعتبار عناوين IP الخاصة بها كحركة مرور مستخدم عادية ونادرًا ما تتعرض للحظر أو تحديد معدل الطلبات.

القاعدة الأساسية: اختبر البروكسي كخطوة منفصلة في بداية خط الأنابيب - سيسمح لك ذلك بتشخيص المشكلات بسرعة وعدم إضاعة الوقت في البحث عن خطأ في نهاية بناء طويل. أضف خطوة curl -v https://api.ipify.org مباشرة بعد إعداد البروكسي - ستظهر لك عنوان IP الذي تُرسل منه الطلبات وتؤكد أن البروكسي يعمل بشكل صحيح.