تكامل البروكسي في CI/CD: الإعداد لـ GitHub Actions و GitLab

```html

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

لماذا نحتاج إلى الوكلاء في عمليات CI/CD

استخدام خوادم الوكيل في عمليات النشر الآلي يحل العديد من المهام الحرجة. أولاً، تتطلب العديد من الشبكات المؤسسية مرور كل حركة المرور الصادرة عبر الوكلاء المؤسسيين للتحكم في الأمان وتسجيل الدخول. بدون الإعداد الصحيح، لن يتمكن خط أنابيب CI/CD من تحميل التبعيات أو الاتصال بالخدمات الخارجية.

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

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

مهم: بالنسبة لعمليات CI/CD، تعتبر استقرار الاتصال أمرًا حيويًا. استخدم وكلاء بمعدل تشغيل لا يقل عن 99.5% واستجابة سريعة (أقل من 200 مللي ثانية). ستؤدي الوكلاء غير المستقرين إلى انهيارات عشوائية في البناء وفقدان الوقت لفريق العمل في التحقيق.

إعداد الوكيل في GitHub Actions

GitHub Actions هي واحدة من أكثر المنصات شيوعًا لعمليات CI/CD. يتم إعداد الوكيل هنا من خلال متغيرات البيئة، التي يمكن تعيينها على مستوى سير العمل أو على مستوى المؤسسة بأكملها. دعونا نستعرض بعض طرق الدمج.

الإعداد الأساسي عبر متغيرات البيئة

أسهل طريقة هي تعيين متغيرات البيئة HTTP_PROXY و HTTPS_PROXY في بداية الوظيفة. تستخدم معظم الأدوات (curl و wget و npm و pip) هذه المتغيرات تلقائيًا:

name: CI with Proxy

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
      NO_PROXY: localhost,127.0.0.1,.internal.domain
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Install dependencies
        run: npm install
      
      - name: Run tests
        run: npm test

متغير NO_PROXY مهم للغاية - فهو يستثني العناوين المحلية والخدمات الداخلية من التوجيه عبر الوكيل. بدونها، قد تحدث مشاكل في الاتصال بـ localhost أو حاويات Docker الداخلية.

تخزين بيانات الاعتماد بشكل آمن عبر أسرار GitHub

إذا كان الوكيل يتطلب مصادقة، فلا تقم أبدًا بتخزين اسم المستخدم وكلمة المرور بشكل مكشوف في ملف سير العمل. استخدم أسرار GitHub:

name: CI with Authenticated Proxy

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Configure Proxy
        run: |
          echo "HTTP_PROXY=http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}" >> $GITHUB_ENV
          echo "HTTPS_PROXY=http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}" >> $GITHUB_ENV
          echo "NO_PROXY=localhost,127.0.0.1" >> $GITHUB_ENV
      
      - name: Test proxy connection
        run: curl -I https://api.github.com
      
      - name: Install dependencies
        run: npm ci

أنشئ الأسرار في إعدادات المستودع: الإعدادات → الأسرار والمتغيرات → الإجراءات → سر مستودع جديد. أضف PROXY_USER و PROXY_PASS و PROXY_HOST و PROXY_PORT. ستتم تشفير هذه القيم ولن تكون متاحة في السجلات.

إعداد الوكيل لخطوات معينة

أحيانًا تحتاج إلى استخدام الوكيل فقط لعمليات معينة، مثل تحميل التبعيات فقط، ولكن ليس للنشر. قم بتعيين المتغيرات على مستوى خطوة معينة:

steps:
  - name: Download dependencies via proxy
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: Deploy without proxy
    run: ./deploy.sh

دمج الوكيل مع GitLab CI/CD

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

إعداد الوكيل على مستوى GitLab Runner

إذا كنت تستخدم GitLab Runner مستضاف ذاتيًا ويجب أن تعمل جميع المشاريع عبر الوكيل، قم بإعداده في تكوين العداء. قم بتحرير ملف /etc/gitlab-runner/config.toml:

[[runners]]
  name = "docker-runner"
  url = "https://gitlab.com/"
  token = "YOUR_TOKEN"
  executor = "docker"
  
  [runners.docker]
    image = "alpine:latest"
    privileged = false
    
  [runners.docker.services_environment]
    HTTP_PROXY = "http://proxy.example.com:8080"
    HTTPS_PROXY = "http://proxy.example.com:8080"
    NO_PROXY = "localhost,127.0.0.1,.gitlab.com"

بعد تغيير التكوين، أعد تشغيل العداء: sudo gitlab-runner restart. الآن ستستخدم جميع الوظائف على هذا العداء الوكيل تلقائيًا.

الإعداد عبر .gitlab-ci.yml

لإعداد الوكيل على مستوى مشروع معين، استخدم المتغيرات في ملف .gitlab-ci.yml. هذه طريقة أكثر مرونة، مما يسمح لمشاريع مختلفة باستخدام وكلاء مختلفة:

variables:
  HTTP_PROXY: "http://proxy.example.com:8080"
  HTTPS_PROXY: "http://proxy.example.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.internal"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "Proxy configured: $HTTP_PROXY"
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  script:
    - npm test
  dependencies:
    - build

استخدام متغيرات GitLab CI/CD لبيانات الاعتماد

لتخزين البيانات الحساسة، استخدم متغيرات CI/CD في إعدادات المشروع: الإعدادات → CI/CD → المتغيرات. أنشئ متغيرات محمية ومخفية:

PROXY_URL — عنوان URL الكامل مع بيانات الاعتماد (مخفي)
PROXY_HOST — مضيف خادم الوكيل
PROXY_PORT — المنفذ
PROXY_USER و PROXY_PASS — للتخزين المنفصل

ثم استخدمها في .gitlab-ci.yml:

build:
  stage: build
  before_script:
    - export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}"
    - export HTTPS_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}"
  script:
    - npm install
    - npm run build

تكوين الوكيل في Jenkins

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

الإعداد العالمي للوكيل لـ Jenkins

لإعداد الوكيل الذي سيستخدمه Jenkins لتحديث المكونات الإضافية وغيرها من العمليات الداخلية، انتقل إلى إدارة Jenkins → إدارة المكونات الإضافية → متقدم. في قسم تكوين وكيل HTTP، حدد:

الخادم: proxy.example.com
المنفذ: 8080
اسم المستخدم وكلمة المرور (إذا كانت المصادقة مطلوبة)
لا وكيل مضيف: localhost,127.0.0.1,.internal

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

إعداد الوكيل لخط أنابيب Jenkins

في Jenkinsfile، يمكنك تعيين متغيرات البيئة لخط الأنابيب بأكمله أو لمراحل معينة:

pipeline {
    agent any
    
    environment {
        HTTP_PROXY = 'http://proxy.example.com:8080'
        HTTPS_PROXY = 'http://proxy.example.com:8080'
        NO_PROXY = 'localhost,127.0.0.1,.internal'
    }
    
    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build'
            }
        }
        
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
    }
}

استخدام بيانات اعتماد Jenkins للوكيل

لتخزين بيانات اعتماد الوكيل بشكل آمن، استخدم مخزن بيانات اعتماد Jenkins. أنشئ بيانات اعتماد من نوع "اسم المستخدم مع كلمة المرور" في إدارة Jenkins → إدارة بيانات الاعتماد، ثم استخدمها في خط الأنابيب:

pipeline {
    agent any
    
    stages {
        stage('Build with Authenticated Proxy') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'proxy-credentials',
                    usernameVariable: 'PROXY_USER',
                    passwordVariable: 'PROXY_PASS'
                )]) {
                    sh '''
                        export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:8080"
                        export HTTPS_PROXY="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:8080"
                        npm install
                    '''
                }
            }
        }
    }
}

إعداد الوكيل لوكلاء Jenkins

إذا كنت تستخدم وكلاء Jenkins منفصلين (nodes)، قم بإعداد الوكيل لكل وكيل على حدة. في تكوين الوكيل (إدارة Jenkins → إدارة العقد → تكوين) أضف في متغيرات البيئة:

HTTP_PROXY=http://proxy.example.com:8080
HTTPS_PROXY=http://proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1

الوكيل لـ Docker في CI/CD

Docker هو جزء لا يتجزأ من عمليات CI/CD الحديثة. إعداد الوكيل لـ Docker له خصائصه الخاصة، حيث يجب إعداد الوكيل لكل من خادم Docker والحاويات.

إعداد الوكيل لخادم Docker

لكي يتمكن خادم Docker من تنزيل الصور عبر الوكيل، قم بإنشاء ملف drop-in لـ systemd. على نظام Linux، أنشئ دليلًا وملفًا:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf

أضف المحتوى التالي:

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.internal,docker.io"

أعد تحميل التكوين و Docker:

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl show --property=Environment docker

الوكيل للحاويات أثناء البناء

إذا كانت الحاويات بحاجة إلى الوصول عبر الوكيل أثناء البناء (على سبيل المثال، لتثبيت الحزم)، قم بتمرير المتغيرات عبر build args في Dockerfile:

FROM node:18-alpine

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}
ENV NO_PROXY=${NO_PROXY}

WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

# إزالة متغيرات الوكيل للوقت الفعلي
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

في خط أنابيب CI/CD، مرر build args:

# GitHub Actions
- name: Build Docker image with proxy
  run: |
    docker build \
      --build-arg HTTP_PROXY=${{ secrets.PROXY_URL }} \
      --build-arg HTTPS_PROXY=${{ secrets.PROXY_URL }} \
      --build-arg NO_PROXY=localhost,127.0.0.1 \
      -t myapp:latest .

# GitLab CI
docker build:
  script:
    - docker build 
        --build-arg HTTP_PROXY="${PROXY_URL}"
        --build-arg HTTPS_PROXY="${PROXY_URL}"
        -t myapp:latest .

Docker Compose مع الوكيل

عند استخدام Docker Compose في CI/CD، قم بإعداد الوكيل عبر environment في docker-compose.yml:

version: '3.8'

services:
  app:
    build:
      context: .
      args:
        - HTTP_PROXY=${HTTP_PROXY}
        - HTTPS_PROXY=${HTTPS_PROXY}
    environment:
      - HTTP_PROXY=${HTTP_PROXY}
      - HTTPS_PROXY=${HTTPS_PROXY}
      - NO_PROXY=localhost,127.0.0.1
    ports:
      - "3000:3000"

إعداد الوكيل لمديري الحزم

تتطلب مديري الحزم غالبًا إعدادًا إضافيًا للوكيل، خاصة إذا كانت تستخدم ملفات تكوين خاصة بها. دعونا نستعرض الإعدادات للمديرين الشائعين.

NPM و Yarn

يمكن أن يستخدم NPM كل من متغيرات البيئة HTTP_PROXY/HTTPS_PROXY، وكذلك تكوينه الخاص. للإعداد الصريح في CI/CD:

# في GitHub Actions أو GitLab CI
- name: Configure npm proxy
  run: |
    npm config set proxy http://proxy.example.com:8080
    npm config set https-proxy http://proxy.example.com:8080
    npm config set noproxy "localhost,127.0.0.1"

- name: Install dependencies
  run: npm install

# لـ Yarn
- name: Configure yarn proxy
  run: |
    yarn config set proxy http://proxy.example.com:8080
    yarn config set https-proxy http://proxy.example.com:8080

طريقة بديلة هي إنشاء ملف .npmrc في جذر المشروع (لكن لا تقم بارتكاب بيانات الاعتماد!):

# .npmrc (يتم إنشاؤه في CI)
proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
noproxy=localhost,127.0.0.1

Python pip و Poetry

يستخدم Pip متغيرات البيئة، ولكن يمكن أيضًا إعداده عبر التكوين:

# عبر متغيرات البيئة (موصى به لـ CI)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# أو عبر معلمات pip
pip install --proxy http://proxy.example.com:8080 -r requirements.txt

# لـ Poetry
poetry config http-basic.proxy http://proxy.example.com:8080
poetry install

Maven و Gradle

لمشاريع Java، يتطلب إعداد الوكيل إنشاء ملفات تكوين. لإنشاء Maven، قم بإنشاء settings.xml في خط أنابيب CI:

- name: Configure Maven proxy
  run: |
    mkdir -p ~/.m2
    cat > ~/.m2/settings.xml << EOF
    <settings>
      <proxies>
        <proxy>
          <id>http-proxy</id>
          <active>true</active>
          <protocol>http</protocol>
          <host>proxy.example.com</host>
          <port>8080</port>
          <nonProxyHosts>localhost|127.0.0.1</nonProxyHosts>
        </proxy>
      </proxies>
    </settings>
    EOF

- name: Build with Maven
  run: mvn clean install

لـ Gradle، أضف الإعدادات إلى gradle.properties:

systemProp.http.proxyHost=proxy.example.com
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=proxy.example.com
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|127.0.0.1

تخزين بيانات اعتماد الوكيل بشكل آمن

يعد تخزين بيانات اعتماد الوكيل جانبًا حرجًا من جوانب أمان CI/CD. يمكن أن تؤدي تسريبات هذه البيانات إلى استخدام غير مصرح به للوكيل وخسائر مالية. دعونا نستعرض أفضل الممارسات للمنصات المختلفة.

أسرار GitHub Actions

تقدم GitHub Actions ثلاثة مستويات من الأسرار: المستودع، البيئة، والمؤسسة. لبيانات اعتماد الوكيل، استخدم:

أسرار المستودع — للمشاريع التي تحتاج فيها الوكيل فقط في مستودع واحد
أسرار المؤسسة — إذا كان يتم استخدام وكيل واحد في جميع مشاريع المؤسسة
أسرار البيئة — لوكلاء مختلفين في بيئات staging/production

قواعد الأمان المهمة:

لا تقم أبدًا بإخراج الأسرار في السجلات: تقوم GitHub تلقائيًا بإخفائها، ولكن من الأفضل تجنب استخدام echo
استخدم بيانات اعتماد مختلفة لبيئات مختلفة
قم بتدوير كلمات مرور الوكيل بانتظام (مرة واحدة كل 90 يومًا على الأقل)
قم بتقييد الوصول إلى الأسرار من خلال قواعد حماية الفروع

متغيرات GitLab CI/CD

يقدم GitLab خيارات حماية إضافية للمتغيرات:

محمي — المتغير متاح فقط في الفروع المحمية (الرئيسية، الإنتاج)
مخفي — القيمة مخفية تلقائيًا في السجلات
نطاق البيئة — تقييد الاستخدام لبيئات معينة

التكوين الموصى به لبيانات اعتماد الوكيل:

# الإعدادات → CI/CD → المتغيرات
PROXY_USER: myuser (محمي: نعم، مخفي: نعم)
PROXY_PASS: secret123 (محمي: نعم، مخفي: نعم)
PROXY_HOST: proxy.example.com (محمي: لا، مخفي: لا)
PROXY_PORT: 8080 (محمي: لا، مخفي: لا)

مخزن بيانات اعتماد Jenkins

يدعم مخزن بيانات اعتماد Jenkins عدة أنواع من تخزين بيانات الاعتماد. للوكيل، يُوصى بـ:

استخدام "اسم المستخدم مع كلمة المرور" لاسم المستخدم/كلمة المرور للوكيل
إعداد بيانات اعتماد على مستوى المجلد لفرق/مشاريع مختلفة
تفعيل مكون ربط بيانات الاعتماد للاستخدام الآمن في خط الأنابيب
إعداد تسجيل تدقيق لتتبع استخدام بيانات الاعتماد

أنظمة إدارة الأسرار الخارجية

بالنسبة للبيئات المؤسسية، يُوصى باستخدام أنظمة متخصصة لإدارة الأسرار: HashiCorp Vault و AWS Secrets Manager و Azure Key Vault أو Google Secret Manager. مثال على التكامل مع HashiCorp Vault في GitHub Actions:

- name: Import Secrets from Vault
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    token: ${{ secrets.VAULT_TOKEN }}
    secrets: |
      secret/data/proxy proxy_user | PROXY_USER ;
      secret/data/proxy proxy_pass | PROXY_PASS ;
      secret/data/proxy proxy_host | PROXY_HOST

- name: Configure Proxy
  run: |
    export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:8080"
    npm install

حل المشكلات الشائعة

عند دمج الوكيل في CI/CD، غالبًا ما تظهر نفس المشكلات. دعونا نستعرض الأكثر شيوعًا وطرق حلها.

المشكلة: انتهاء مهلة الاتصال عند تحميل التبعيات

الأعراض: تنتهي عمليات npm install أو pip install أو docker pull بخطأ انتهاء المهلة بعد 30-60 ثانية.

الأسباب:

خادم الوكيل غير متاح أو محمل بشكل زائد
تنسيق URL الوكيل غير صحيح (نسيت http:// في البداية)
يتطلب الوكيل مصادقة، ولكن لم يتم تمرير بيانات الاعتماد
يمنع جدار الحماية الاتصال من CI/CD runner إلى الوكيل

الحل:

# 1. تحقق من توفر الوكيل
- name: Test proxy connectivity
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Proxy test completed"

# 2. زيادة مهلة npm
- name: Install with increased timeout
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. تحقق من تنسيق URL
- name: Debug proxy configuration
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # يجب أن يكون: http://user:pass@host:port

المشكلة: فشل التحقق من شهادة SSL

الأعراض: أخطاء من نوع "مشكلة شهادة SSL: غير قادر على الحصول على شهادة الجهة المصدرة المحلية" أو "CERT_UNTRUSTED".

السبب: غالبًا ما تقوم الوكلاء المؤسسية بتنفيذ فحص SSL، مما يؤدي إلى استبدال الشهادات. لا يثق CI/CD runner بـ CA المؤسسي.

الحل:

# الخيار 1: إضافة شهادة CA المؤسسية
- name: Install corporate CA certificate
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# الخيار 2: تعطيل التحقق من SSL (لا يُوصى به للإنتاج!)
- name: Install with SSL verification disabled
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# الخيار 3: استخدام الوكيل فقط لـ HTTP، و HTTPS مباشرة
- name: Selective proxy usage
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # لا نقوم بتعيين HTTPS_PROXY

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

المشكلة: يعمل الوكيل لبعض الأوامر، ولكن ليس للآخرين

الأعراض: يعمل npm install عبر الوكيل، ولكن git clone أو docker pull تتجاهل إعدادات الوكيل.

السبب: تستخدم الأدوات المختلفة آليات إعداد وكيل مختلفة. لدى Git و Docker ملفات تكوين خاصة بهما.

الحل:

# إعداد وكيل Git
- name: Configure Git proxy
  run: |
    git config --global http.proxy http://proxy.example.com:8080
    git config --global https.proxy http://proxy.example.com:8080

# إعداد وكيل Docker (انظر قسم Docker أعلاه)
# لـ wget/curl
- name: Configure wget/curl
  run: |
    echo "use_proxy = on" >> ~/.wgetrc
    echo "http_proxy = http://proxy.example.com:8080" >> ~/.wgetrc
    echo "https_proxy = http://proxy.example.com:8080" >> ~/.wgetrc

المشكلة: الخدمات الداخلية غير متاحة عند تشغيل الوكيل

الأعراض: بعد إعداد الوكيل، توقفت الاتصالات بـ localhost، أو حاويات Docker الداخلية، أو الخدمات المؤسسية عن العمل.

السبب: تم إعداد متغير NO_PROXY بشكل غير صحيح، حيث تذهب جميع الطلبات عبر الوكيل، بما في ذلك المحلية.

الحل:

# الإعداد الصحيح لـ NO_PROXY
env:
  HTTP_PROXY: http://proxy.example.com:8080
  HTTPS_PROXY: http://proxy.example.com:8080
  NO_PROXY: |
    localhost,
    127.0.0.1,
    0.0.0.0,
    .internal,
    .local,
    .corp.example.com,
    docker.internal,
    host.docker.internal

# لـ Docker Compose، أضف أيضًا
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db و redis — أسماء الخدمات الأخرى في compose

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

الأعراض: تظهر كلمات مرور الوكيل في السجلات بشكل مكشوف.

السبب: إخراج متغيرات البيئة عبر echo أو وضع verbose في الأوامر.

الحل:

# ❌ سيء - بيانات الاعتماد في السجلات
- name: Debug proxy
  run: |
    echo "Proxy: $HTTP_PROXY"  # سيظهر http://user:pass@host:port
    curl -v ...  # وضع verbose يظهر بيانات الاعتماد

# ✅ جيد - إخراج آمن
- name: Debug proxy (safe)
  run: |
    echo "Proxy host configured: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # سيظهر فقط host:port
    
# استخدم الأسرار للتعتيم
- name: Configure proxy
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # تقوم GitHub تلقائيًا بإخفائها
  run: |
    export HTTP_PROXY="$PROXY_URL"

الخاتمة

يعد دمج الوكيل في خط أنابيب CI/CD جانبًا مهمًا من الأتمتة، حيث يضمن الأمان، والامتثال للسياسات المؤسسية، وإمكانية اختبار ميزات الجغرافيا. في هذا الدليل، استعرضنا طرقًا عملية لإعداد الوكيل لـ GitHub Actions و GitLab CI و Jenkins و Docker ومديري الحزم الشائعين.

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

يعتمد اختيار نوع الوكيل على مهامك: عادةً ما تستخدم الشبكات المؤسسية الوكلاء HTTP/HTTPS الموجودين، بينما تناسب الوكلاء السكنيين اختبار ميزات الجغرافيا مع IP من الدول المطلوبة، ولتحميل التبعيات بسرعة عالية يمكن استخدام وكلاء مراكز البيانات. من المهم ضمان وقت تشغيل مرتفع لخوادم الوكيل، حيث أن عدم توفرها سيؤدي إلى انهيار جميع البناءات وتعطيل عمل فريق التطوير.

عند مواجهة مشكلات، ابدأ بالتحقق من التوفر الأساسي للوكيل عبر curl أو wget، ثم تحقق من صحة تنسيق URL وبيانات الاعتماد، وبعد ذلك انتقل إلى الإعدادات الخاصة بالأدوات المحددة. يتم حل معظم المشكلات من خلال الإعداد الصحيح لمتغيرات البيئة HTTP_PROXY و HTTPS_PROXY و NO_PROXY.

```

دمج البروكسي في خط أنابيب CI/CD: الإعداد لـ GitHub Actions و GitLab و Jenkins

لماذا نحتاج إلى الوكلاء في عمليات CI/CD

إعداد الوكيل في GitHub Actions

الإعداد الأساسي عبر متغيرات البيئة

تخزين بيانات الاعتماد بشكل آمن عبر أسرار GitHub

إعداد الوكيل لخطوات معينة

دمج الوكيل مع GitLab CI/CD

إعداد الوكيل على مستوى GitLab Runner

الإعداد عبر .gitlab-ci.yml

استخدام متغيرات GitLab CI/CD لبيانات الاعتماد

تكوين الوكيل في Jenkins

الإعداد العالمي للوكيل لـ Jenkins

إعداد الوكيل لخط أنابيب Jenkins

استخدام بيانات اعتماد Jenkins للوكيل

إعداد الوكيل لوكلاء Jenkins

الوكيل لـ Docker في CI/CD

إعداد الوكيل لخادم Docker

الوكيل للحاويات أثناء البناء

Docker Compose مع الوكيل

إعداد الوكيل لمديري الحزم

NPM و Yarn

Python pip و Poetry

Maven و Gradle

تخزين بيانات اعتماد الوكيل بشكل آمن

أسرار GitHub Actions

متغيرات GitLab CI/CD

مخزن بيانات اعتماد Jenkins

أنظمة إدارة الأسرار الخارجية

حل المشكلات الشائعة

المشكلة: انتهاء مهلة الاتصال عند تحميل التبعيات

المشكلة: فشل التحقق من شهادة SSL

المشكلة: يعمل الوكيل لبعض الأوامر، ولكن ليس للآخرين

المشكلة: الخدمات الداخلية غير متاحة عند تشغيل الوكيل

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

الخاتمة