प्रॉक्सी का CI/CD में एकीकरण: GitHub Actions और GitLab के लिए सेटअप

```html

तैनाती और परीक्षण के स्वचालन के दौरान, CI/CD प्रक्रियाओं में प्रॉक्सी सर्वर का उपयोग करने की आवश्यकता अक्सर होती है। यह कॉर्पोरेट सुरक्षा नीतियों, भू-स्थानिक कार्यक्षमताओं का परीक्षण करने या निर्भरताओं को डाउनलोड करते समय दर-सीमा को बायपास करने से संबंधित हो सकता है। इस मार्गदर्शिका में, हम लोकप्रिय CI/CD प्लेटफार्मों के लिए प्रॉक्सी के व्यावहारिक सेटअप पर चर्चा करेंगे, जिसमें तैयार कॉन्फ़िगरेशन के उदाहरण शामिल हैं।

CI/CD प्रक्रियाओं में प्रॉक्सी की आवश्यकता क्यों है

स्वचालित तैनाती प्रक्रियाओं में प्रॉक्सी सर्वरों का उपयोग कई महत्वपूर्ण कार्यों को हल करता है। सबसे पहले, कई कॉर्पोरेट नेटवर्क सुरक्षा नियंत्रण और लॉगिंग के लिए सभी आउटगोइंग ट्रैफ़िक को कॉर्पोरेट प्रॉक्सी के माध्यम से भेजने की आवश्यकता होती है। सही सेटअप के बिना, CI/CD पाइपलाइन निर्भरताओं को डाउनलोड नहीं कर सकेगी या बाहरी सेवाओं से कनेक्ट नहीं कर सकेगी।

दूसरी बात, भू-स्थानिक लॉजिक वाले अनुप्रयोगों का परीक्षण करते समय विभिन्न देशों से कार्यक्षमता की जांच करना आवश्यक है। उदाहरण के लिए, यदि आप क्षेत्रीय सामग्री या मूल्य निर्धारण के साथ सेवा विकसित कर रहे हैं, तो स्वचालित परीक्षणों को विभिन्न स्थानों से उपयोगकर्ताओं का अनुकरण करना चाहिए। यहां रेसिडेंशियल प्रॉक्सी मदद करते हैं, जिनके पास आवश्यक क्षेत्रों से IP पते होते हैं।

तीसरी वजह — दर-सीमा और ब्लॉक को बायपास करना। पाइपलाइन के बार-बार चलने पर, विशेष रूप से बड़े टीमों में, CI/CD सर्वर बाहरी सेवाओं के API द्वारा सीमाओं के अधीन हो सकते हैं। उदाहरण के लिए, GitHub API या पैकेज रजिस्ट्रियों द्वारा अनुरोधों की सीमा से अधिक होने पर IP को अस्थायी रूप से ब्लॉक किया जा सकता है। प्रॉक्सी का रोटेशन लोड को वितरित करने में मदद करता है।

महत्वपूर्ण: CI/CD प्रक्रियाओं के लिए कनेक्शन की स्थिरता महत्वपूर्ण है। ऐसे प्रॉक्सी का उपयोग करें जिनका अपटाइम 99.5% से कम न हो और प्रतिक्रिया समय तेज हो (200ms से कम)। अस्थिर प्रॉक्सी आकस्मिक निर्माण विफलताओं और टीम के समय की जांच में बर्बादी का कारण बनेंगी।

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 Secrets के माध्यम से क्रेडेंशियल्स का सुरक्षित भंडारण

यदि प्रॉक्सी प्रमाणीकरण की आवश्यकता है, तो कभी भी कार्यप्रवाह फ़ाइल में लॉगिन और पासवर्ड को स्पष्ट रूप से न रखें। 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

अपने रिपॉजिटरी की सेटिंग्स में सीक्रेट्स बनाएं: 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 प्रॉक्सी सेटअप के लिए कई स्तर प्रदान करता है: रनर स्तर पर, प्रोजेक्ट स्तर पर और विशिष्ट जॉब स्तर पर। चयन इस बात पर निर्भर करता है कि क्या सभी प्रोजेक्ट्स के लिए प्रॉक्सी की आवश्यकता है या केवल विशिष्ट के लिए।

GitLab रनर स्तर पर प्रॉक्सी सेटअप

यदि आप स्वयं-होस्टेड GitLab रनर का उपयोग कर रहे हैं और सभी प्रोजेक्ट्स को प्रॉक्सी के माध्यम से काम करना चाहिए, तो इसे रनर कॉन्फ़िगरेशन में सेट करें। फ़ाइल को संपादित करें /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 वेरिएबल्स का उपयोग करें: Settings → CI/CD → Variables. प्रोटेक्टेड और मास्केड वेरिएबल्स बनाएं:

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 मास्टर के लिए वैश्विक सेटिंग्स, विशिष्ट एजेंटों के लिए सेटिंग्स या व्यक्तिगत पाइपलाइन के स्तर पर सेटिंग्स।

Jenkins के लिए वैश्विक प्रॉक्सी सेटअप

Jenkins को प्लगइन अपडेट और अन्य आंतरिक कार्यों के लिए प्रॉक्सी सेट करने के लिए, Manage Jenkins → Manage Plugins → Advanced पर जाएं। HTTP Proxy Configuration अनुभाग में, निम्नलिखित निर्दिष्ट करें:

Server: proxy.example.com
Port: 8080
User name और Password (यदि प्रमाणीकरण की आवश्यकता हो)
No Proxy Host: 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 क्रेडेंशियल्स स्टोर का उपयोग करें। Manage Jenkins → Manage Credentials में "Username with password" प्रकार के क्रेडेंशियल्स बनाएं, फिर उन्हें पाइपलाइन में उपयोग करें:

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

CI/CD में Docker के लिए प्रॉक्सी

Docker आधुनिक CI/CD प्रक्रियाओं का एक अभिन्न हिस्सा है। Docker के लिए प्रॉक्सी सेटअप में अपनी विशेषताएँ हैं, क्योंकि प्रॉक्सी को Docker डेमन और कंटेनरों दोनों के लिए सेटअप करना आवश्यक है।

Docker डेमन के लिए प्रॉक्सी सेटअप

Docker डेमन को प्रॉक्सी के माध्यम से छवियाँ डाउनलोड करने के लिए, एक 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

संग्रह के दौरान कंटेनरों के लिए प्रॉक्सी

यदि कंटेनरों को संग्रह के दौरान प्रॉक्सी के माध्यम से पहुंच की आवश्यकता है (जैसे, पैकेज स्थापित करने के लिए), तो 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 पाइपलाइन में बिल्ड आर्ग्स पास करें:

# 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 के साथ प्रॉक्सी

CI/CD में Docker Compose का उपयोग करते समय, 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 के लिए, CI पाइपलाइन में settings.xml बनाएं:

- 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 तीन स्तरों के सीक्रेट्स प्रदान करता है: रिपॉजिटरी, वातावरण और संगठन। प्रॉक्सी क्रेडेंशियल्स के लिए उपयोग करें:

रिपॉजिटरी सीक्रेट्स — उन प्रोजेक्ट्स के लिए जहां प्रॉक्सी केवल एक रिपॉजिटरी में आवश्यक है
संगठन सीक्रेट्स — यदि एक प्रॉक्सी सभी संगठन के प्रोजेक्ट्स में उपयोग की जाती है
वातावरण सीक्रेट्स — स्टेजिंग/प्रोडक्शन वातावरण में विभिन्न प्रॉक्सी के लिए

सुरक्षा के महत्वपूर्ण नियम:

कभी भी सीक्रेट्स को लॉग में न दिखाएँ: GitHub स्वचालित रूप से उन्हें मास्क करता है, लेकिन echo से बचना बेहतर है
विभिन्न वातावरणों के लिए विभिन्न क्रेडेंशियल्स का उपयोग करें
प्रॉक्सी के पासवर्ड को नियमित रूप से रोटेट करें (कम से कम 90 दिनों में)
ब्रांच प्रोटेक्शन नियमों के माध्यम से सीक्रेट्स तक पहुंच को सीमित करें

GitLab CI/CD वेरिएबल्स

GitLab वेरिएबल्स के लिए अतिरिक्त सुरक्षा विकल्प प्रदान करता है:

Protected — वेरिएबल केवल प्रोटेक्टेड ब्रांचेस (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 क्रेडेंशियल्स स्टोर

Jenkins क्रेडेंशियल्स स्टोर कई प्रकार के क्रेडेंशियल्स को संग्रहीत करने का समर्थन करता है। प्रॉक्सी के लिए अनुशंसित है:

प्रॉक्सी के लिए लॉगिन/पासवर्ड के लिए "Username with password" का उपयोग करें
विभिन्न टीमों/प्रोजेक्ट्स के लिए फ़ोल्डर-स्तरीय क्रेडेंशियल्स सेट करें
पाइपलाइन में सुरक्षित उपयोग के लिए क्रेडेंशियल्स बाइंडिंग प्लगइन सक्षम करें
क्रेडेंशियल्स के उपयोग को ट्रैक करने के लिए ऑडिट लॉगिंग सेट करें

बाहरी सीक्रेट प्रबंधन सिस्टम

एंटरप्राइज वातावरणों के लिए, विशेष सीक्रेट प्रबंधन सिस्टम का उपयोग करने की सिफारिश की जाती है: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault या Google Secret Manager। GitHub Actions में HashiCorp Vault के साथ एकीकरण का उदाहरण:

- 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:// भूल गए)
प्रॉक्सी प्रमाणीकरण की आवश्यकता है, लेकिन क्रेडेंशियल्स नहीं भेजे गए हैं
Firewall CI/CD रनर से प्रॉक्सी के लिए कनेक्शन को ब्लॉक करता है

समाधान:

# 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 certificate problem: unable to get local issuer certificate" या "CERT_UNTRUSTED" जैसी त्रुटियाँ।

कारण: कॉर्पोरेट प्रॉक्सी अक्सर SSL निरीक्षण करते हैं, प्रमाणपत्रों को बदलते हैं। CI/CD रनर कॉर्पोरेट 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 में अन्य सेवाओं के नाम

समस्या: प्रॉक्सी क्रेडेंशियल्स लॉग में दिखाई देते हैं

लक्षण: CI/CD में प्रॉक्सी पासवर्ड स्पष्ट रूप से लॉग में दिखाई देते हैं।

कारण: पर्यावरण चर को echo या कमांड के विस्तृत मोड के माध्यम से आउटपुट करना।

समाधान:

# ❌ बुरा - लॉग में क्रेडेंशियल्स
- name: Debug proxy
  run: |
    echo "Proxy: $HTTP_PROXY"  # http://user:pass@host:port दिखाएगा
    curl -v ...  # विस्तृत मोड क्रेडेंशियल्स दिखाता है

# ✅ अच्छा - सुरक्षित आउटपुट
- 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 Secrets के माध्यम से क्रेडेंशियल्स का सुरक्षित भंडारण

विशिष्ट चरणों के लिए प्रॉक्सी सेटअप

GitLab CI/CD के साथ प्रॉक्सी का एकीकरण

GitLab रनर स्तर पर प्रॉक्सी सेटअप

.gitlab-ci.yml के माध्यम से सेटअप

क्रेडेंशियल्स के लिए GitLab CI/CD वेरिएबल्स का उपयोग

Jenkins में प्रॉक्सी कॉन्फ़िगरेशन

Jenkins के लिए वैश्विक प्रॉक्सी सेटअप

Jenkins पाइपलाइन के लिए प्रॉक्सी सेटअप

प्रॉक्सी के लिए Jenkins क्रेडेंशियल्स का उपयोग

Jenkins एजेंटों के लिए प्रॉक्सी सेटअप

CI/CD में Docker के लिए प्रॉक्सी

Docker डेमन के लिए प्रॉक्सी सेटअप

संग्रह के दौरान कंटेनरों के लिए प्रॉक्सी

Docker Compose के साथ प्रॉक्सी

पैकेज प्रबंधकों के लिए प्रॉक्सी सेटअप

NPM और Yarn

Python pip और Poetry

Maven और Gradle

प्रॉक्सी क्रेडेंशियल्स का सुरक्षित भंडारण

GitHub Actions Secrets

GitLab CI/CD वेरिएबल्स

Jenkins क्रेडेंशियल्स स्टोर

बाहरी सीक्रेट प्रबंधन सिस्टम

सामान्य समस्याओं का समाधान

समस्या: निर्भरताओं को डाउनलोड करते समय कनेक्शन टाइमआउट

समस्या: SSL प्रमाणपत्र सत्यापन विफल

समस्या: प्रॉक्सी कुछ कमांड के लिए काम करता है, लेकिन दूसरों के लिए नहीं

समस्या: प्रॉक्सी चालू होने पर आंतरिक सेवाएँ अनुपलब्ध हैं

समस्या: प्रॉक्सी क्रेडेंशियल्स लॉग में दिखाई देते हैं

निष्कर्ष