ادغام پروکسی در CI/CD: تنظیمات برای GitHub Actions و GitLab

```html

هنگام اتوماسیون استقرار و تست، اغلب نیاز به استفاده از سرورهای پروکسی در فرآیندهای CI/CD وجود دارد. این ممکن است به سیاست‌های امنیتی شرکتی، تست ویژگی‌های جغرافیایی یا دور زدن محدودیت‌های نرخ هنگام بارگذاری وابستگی‌ها مربوط باشد. در این راهنما، پیکربندی عملی پروکسی برای پلتفرم‌های محبوب CI/CD را با نمونه‌های آماده بررسی خواهیم کرد.

چرا به پروکسی در فرآیندهای CI/CD نیاز داریم

استفاده از سرورهای پروکسی در فرآیندهای اتوماسیون استقرار چندین مشکل حیاتی را حل می‌کند. اولاً، بسیاری از شبکه‌های شرکتی نیاز دارند که تمام ترافیک خروجی از طریق پروکسی‌های شرکتی برای کنترل امنیت و ثبت وقایع عبور کند. بدون پیکربندی صحیح، خط لوله CI/CD به سادگی نمی‌تواند وابستگی‌ها را بارگذاری کند یا به سرویس‌های خارجی متصل شود.

ثانیاً، هنگام تست برنامه‌هایی با منطق جغرافیایی، باید عملکرد را از کشورهای مختلف بررسی کرد. به عنوان مثال، اگر شما سرویسی با محتوای منطقه‌ای یا قیمت‌گذاری توسعه می‌دهید، تست‌های خودکار باید کاربران را از مکان‌های مختلف شبیه‌سازی کنند. در اینجا پروکسی‌های مسکونی با آدرس‌های IP از مناطق مورد نیاز کمک می‌کنند.

دلیل سوم — دور زدن محدودیت‌های نرخ و مسدودیت‌ها. هنگام اجرای مکرر خط لوله، به ویژه در تیم‌های بزرگ، سرورهای CI/CD ممکن است تحت محدودیت‌های API سرویس‌های خارجی قرار بگیرند. به عنوان مثال، API گیت‌هاب یا مخازن بسته ممکن است به طور موقت IP را در صورت تجاوز از حد درخواست‌ها مسدود کنند. چرخش پروکسی کمک می‌کند تا بار را توزیع کنیم.

مهم: برای فرآیندهای CI/CD، ثبات اتصال حیاتی است. از پروکسی‌هایی با زمان کارکرد حداقل 99.5% و زمان پاسخ سریع (کمتر از 200 میلی‌ثانیه) استفاده کنید. پروکسی‌های ناپایدار منجر به سقوط‌های تصادفی در ساخت و از دست رفتن زمان تیم برای تحقیق خواهند شد.

تنظیم پروکسی در GitHub Actions

GitHub Actions — یکی از محبوب‌ترین پلتفرم‌ها برای CI/CD است. تنظیم پروکسی در اینجا از طریق متغیرهای محیطی انجام می‌شود که می‌توان آنها را در سطح workflow یا کل سازمان تعیین کرد. چندین روش برای ادغام را بررسی خواهیم کرد.

تنظیم پایه از طریق متغیرهای محیطی

ساده‌ترین روش — تنظیم متغیرهای محیطی HTTP_PROXY و HTTPS_PROXY در ابتدای job. بیشتر ابزارها (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 Secrets

اگر پروکسی نیاز به احراز هویت دارد، هرگز نام کاربری و رمز عبور را به صورت آشکار در فایل workflow ذخیره نکنید. از GitHub Secrets استفاده کنید:

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

secrets را در تنظیمات مخزن ایجاد کنید: Settings → Secrets and variables → Actions → New repository secret. 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 چندین سطح تنظیم پروکسی را ارائه می‌دهد: در سطح runner، در سطح پروژه و در سطح job خاص. انتخاب بستگی به این دارد که آیا پروکسی برای تمام پروژه‌ها نیاز است یا فقط برای پروژه‌های خاص.

تنظیم پروکسی در سطح GitLab Runner

اگر از GitLab Runner خود میزبانی شده استفاده می‌کنید و همه پروژه‌ها باید از طریق پروکسی کار کنند، آن را در پیکربندی 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"

پس از تغییر پیکربندی، runner را دوباره راه‌اندازی کنید: sudo gitlab-runner restart. اکنون همه jobs در این runner به طور خودکار از پروکسی استفاده خواهند کرد.

تنظیم از طریق .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 در تنظیمات پروژه استفاده کنید: Settings → CI/CD → Variables. متغیرهای protected و masked را ایجاد کنید:

PROXY_URL — URL کامل با اطلاعات اعتبار (masked)
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 برای به‌روزرسانی پلاگین‌ها و سایر عملیات داخلی استفاده خواهد کرد، به Manage Jenkins → Manage Plugins → Advanced بروید. در بخش HTTP Proxy Configuration، موارد زیر را مشخص کنید:

سرور: proxy.example.com
پورت: 8080
نام کاربری و رمز عبور (در صورت نیاز به احراز هویت)
No Proxy Host: localhost,127.0.0.1,.internal

این تنظیم فقط بر خود Jenkins تأثیر می‌گذارد، اما بر jobs تأثیری ندارد. برای jobs به یک پیکربندی جداگانه نیاز است.

تنظیم پروکسی برای Jenkins Pipeline

در 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 Credentials برای پروکسی

برای ذخیره‌سازی امن اطلاعات اعتبار پروکسی از Jenkins Credentials Store استفاده کنید. یک اعتبار از نوع "Username with password" در Manage Jenkins → Manage Credentials ایجاد کنید، سپس از آنها در خط لوله استفاده کنید:

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) استفاده می‌کنید، پروکسی را برای هر نماینده به طور جداگانه تنظیم کنید. در پیکربندی نماینده (Manage Jenkins → Manage Nodes → Configure) در متغیرهای محیطی اضافه کنید:

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 daemon و هم برای کانتینرها تنظیم کنید.

تنظیم پروکسی برای Docker daemon

برای اینکه Docker daemon بتواند تصاویر را از طریق پروکسی دانلود کند، یک فایل 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 . .

# حذف متغیرهای پروکسی برای runtime
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 Secrets

GitHub Actions سه سطح از اسرار را ارائه می‌دهد: repository، environment و organization. برای اطلاعات اعتبار پروکسی از موارد زیر استفاده کنید:

Repository secrets — برای پروژه‌هایی که پروکسی فقط در یک مخزن نیاز است
Organization secrets — اگر یک پروکسی در تمام پروژه‌های سازمان استفاده شود
Environment secrets — برای پروکسی‌های مختلف در محیط‌های staging/production

قوانین مهم امنیتی:

هرگز اسرار را در لاگ‌ها نمایش ندهید: GitHub به طور خودکار آنها را ماسک می‌کند، اما بهتر است از echo اجتناب کنید
از اطلاعات اعتبار مختلف برای محیط‌های مختلف استفاده کنید
به طور منظم رمزهای عبور پروکسی را چرخش دهید (حداقل هر 90 روز)
دسترسی به اسرار را از طریق قوانین حفاظت از branch محدود کنید

GitLab CI/CD Variables

GitLab گزینه‌های اضافی برای محافظت از متغیرها را ارائه می‌دهد:

Protected — متغیر فقط در branches محافظت‌شده (main، production) در دسترس است
Masked — مقدار به طور خودکار در لاگ‌ها پنهان می‌شود
Environment scope — محدودیت استفاده برای محیط‌های خاص

پیکربندی توصیه‌شده برای اطلاعات اعتبار پروکسی:

# Settings → CI/CD → Variables
PROXY_USER: myuser (Protected: Yes, Masked: Yes)
PROXY_PASS: secret123 (Protected: Yes, Masked: Yes)
PROXY_HOST: proxy.example.com (Protected: No, Masked: No)
PROXY_PORT: 8080 (Protected: No, Masked: No)

Jenkins Credentials Store

Jenkins Credentials Store از چندین نوع ذخیره‌سازی اطلاعات اعتبار پشتیبانی می‌کند. برای پروکسی، توصیه می‌شود:

از "Username with password" برای نام کاربری/رمز عبور پروکسی استفاده کنید
برای تیم‌ها/پروژه‌های مختلف، اعتبارهای سطح Folder را تنظیم کنید
پلاگین Credentials Binding را برای استفاده امن در Pipeline فعال کنید
برای پیگیری استفاده از اطلاعات اعتبار، logging audit را تنظیم کنید

سیستم‌های خارجی مدیریت اسرار

برای محیط‌های سازمانی، توصیه می‌شود از سیستم‌های تخصصی مدیریت اسرار استفاده کنید: 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، اغلب با مشکلات مشابهی مواجه می‌شوید. رایج‌ترین مشکلات و راه‌حل‌های آنها را بررسی خواهیم کرد.

مشکل: Connection timeout هنگام بارگذاری وابستگی‌ها

علائم: npm install، pip install یا docker pull با خطای timeout پس از 30-60 ثانیه به پایان می‌رسند.

دلایل:

سرور پروکسی در دسترس نیست یا بارگذاری شده است
فرمت URL پروکسی نادرست است (http:// را در ابتدا فراموش کرده‌اید)
پروکسی نیاز به احراز هویت دارد، اما اطلاعات اعتبار منتقل نشده است
Firewall اتصال از 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. زمان timeout را برای 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 certificate verification failed

علائم: خطاهایی مانند "SSL certificate problem: unable to get local issuer certificate" یا "CERT_UNTRUSTED".

دلیل: پروکسی‌های شرکتی اغلب SSL inspection را انجام می‌دهند و گواهی‌ها را تغییر می‌دهند. 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 را غیرفعال کنید (برای production توصیه نمی‌شود!)
- 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

مشکل: اطلاعات اعتبار پروکسی در لاگ‌ها ظاهر می‌شود

علائم: در لاگ‌های CI/CD، رمزهای عبور پروکسی به صورت آشکار قابل مشاهده است.

دلیل: نمایش متغیرهای محیطی از طریق 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 را نشان می‌دهد
    
# از secrets برای ماسک کردن استفاده کنید
- 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 را به درستی برای استثنای سرویس‌های محلی و داخلی تنظیم کنید، اتصال به پروکسی را قبل از عملیات اصلی تست کنید و لاگ‌ها را برای نشت داده‌های حساس نظارت کنید. برای محیط‌های production حساس، توصیه می‌شود از سیستم‌های خارجی مدیریت اسرار مانند 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 Secrets

تنظیم پروکسی برای مراحل خاص

ادغام پروکسی با GitLab CI/CD

تنظیم پروکسی در سطح GitLab Runner

تنظیم از طریق .gitlab-ci.yml

استفاده از متغیرهای GitLab CI/CD برای اطلاعات اعتبار

پیکربندی پروکسی در Jenkins

تنظیم جهانی پروکسی برای Jenkins

تنظیم پروکسی برای Jenkins Pipeline

استفاده از Jenkins Credentials برای پروکسی

تنظیم پروکسی برای نمایندگان Jenkins

پروکسی برای Docker در CI/CD

تنظیم پروکسی برای Docker daemon

پروکسی برای کانتینرها در حین ساخت

Docker Compose با پروکسی

تنظیم پروکسی برای مدیران بسته

NPM و Yarn

Python pip و Poetry

Maven و Gradle

ذخیره‌سازی امن اطلاعات اعتبار پروکسی

GitHub Actions Secrets

GitLab CI/CD Variables

Jenkins Credentials Store

سیستم‌های خارجی مدیریت اسرار

حل مشکلات رایج

مشکل: Connection timeout هنگام بارگذاری وابستگی‌ها

مشکل: SSL certificate verification failed

مشکل: پروکسی برای برخی از دستورات کار می‌کند، اما برای دیگران کار نمی‌کند

مشکل: سرویس‌های داخلی هنگام فعال بودن پروکسی در دسترس نیستند

مشکل: اطلاعات اعتبار پروکسی در لاگ‌ها ظاهر می‌شود

نتیجه‌گیری