CI/CD पाइपलाइनों के लिए प्रॉक्सी: बंद संसाधनों तक पहुँच के लिए GitHub Actions, GitLab CI और Jenkins की सेटिंग

क्या आपका पाइपलाइन 403 Forbidden या Connection refused त्रुटि के साथ गिरता है जब आप बाहरी API को कॉल करने या निर्भरता डाउनलोड करने की कोशिश करते हैं? संभावना है कि आपके CI/CD सर्वर का IP पता संसाधन की ओर से अवरुद्ध है। प्रॉक्सी इस समस्या को हल करती है: आप ट्रैफ़िक को आवश्यक IP के माध्यम से रूट करते हैं और पाइपलाइन बिना किसी रुकावट के काम करती है। इस लेख में - GitHub Actions, GitLab CI और Jenkins के लिए चरण-दर-चरण निर्देश।

CI/CD में प्रॉक्सी की आवश्यकता: वास्तविक परिदृश्य

CI/CD पाइपलाइन निश्चित IP पते वाले सर्वरों पर काम करती हैं - GitHub, GitLab के क्लाउड रनर्स या अपने स्वयं के Jenkins एजेंट पर। ये IP अच्छी तरह से ज्ञात हैं, और कई बाहरी सेवाएँ या तो इन्हें अवरुद्ध करती हैं या अनुरोधों की संख्या को सीमित करती हैं। यहाँ कुछ विशिष्ट स्थितियाँ हैं जहाँ प्रॉक्सी के बिना काम नहीं चल सकता:

भू-सीमित संसाधनों तक पहुँच

कई कॉर्पोरेट npm रजिस्ट्री, Maven रिपॉजिटरी और आंतरिक API केवल कुछ देशों या IP रेंज से उपलब्ध हैं। यदि आपका GitHub Actions रनर उस क्षेत्र में है जो लक्षित सेवा के फ़ायरवॉल स्तर पर अवरुद्ध है, तो पाइपलाइन निर्भरता डाउनलोड या डेटा भेजने में असमर्थ होगी। आवश्यक भू-स्थान के साथ प्रॉक्सी इस समस्या को बिना अवसंरचना को बदले हल करती है।

रेट लिमिटिंग और IP द्वारा अवरोध

GitHub Actions के क्लाउड रनर्स Microsoft Azure के IP रेंज का उपयोग करते हैं। कई सार्वजनिक API इन रेंज को जानते हैं और उन पर कठोर सीमाएँ लागू करते हैं - या पूरी तरह से अवरुद्ध करते हैं। उदाहरण के लिए, सार्वजनिक डेटा का पार्सिंग, परीक्षण के दौरान तीसरे पक्ष के API के लिए अनुरोध, सीमित CDN से वितरण डाउनलोड करना - ये सभी नियमित रूप से क्लाउड रनर्स के IP के कारण टूटते हैं। प्रॉक्सी के माध्यम से रोटेशन रेट लिमिटिंग को बायपास करने की अनुमति देता है।

वास्तविक वेबसाइटों के साथ एकीकरण परीक्षण

यदि आपके एकीकरण परीक्षण वास्तविक वेबसाइटों या मार्केटप्लेस (Wildberries, Ozon, Avito, Amazon) को कॉल करते हैं, तो ये वेबसाइटें हर बार रनर से एक ही IP देखती हैं और इसे जल्दी से अवरुद्ध कर देती हैं। IP रोटेशन के साथ प्रॉक्सी परीक्षणों को स्थिरता से पास करने की अनुमति देती है बिना CAPTCHA और अवरोधों के।

आंतरिक कॉर्पोरेट संसाधनों तक पहुँच

कॉर्पोरेट नेटवर्क अक्सर बाहरी दुनिया से बंद होते हैं। यदि पाइपलाइन को आंतरिक सर्वर पर तैनात करना है या बंद API को कॉल करना है, तो प्रॉक्सी (या SOCKS5 टनल) कॉर्पोरेट नेटवर्क के भीतर क्लाउड रनर और बंद अवसंरचना के बीच पुल बन जाता है।

विज्ञापन और मार्केटिंग एकीकरण का परीक्षण

Facebook Ads API, TikTok Ads API या Google Ads API के साथ काम करने वाली टीमें अक्सर CI/CD के माध्यम से अभियान बनाने को स्वचालित करती हैं। इन प्लेटफार्मों में IP के लिए कठोर नियम होते हैं: डेटा सेंटर के IP से अनुरोध अवरुद्ध हो सकते हैं या अतिरिक्त सत्यापन की आवश्यकता हो सकती है। पाइपलाइन में निवासी प्रॉक्सी अनुरोधों को सामान्य उपयोगकर्ता ट्रैफ़िक के समान बनाते हैं।

पाइपलाइन के लिए कौन सा प्रॉक्सी प्रकार चुनें

प्रॉक्सी के प्रकार का चयन कार्य पर निर्भर करता है। CI/CD पाइपलाइनों के लिए तीन विकल्प प्रासंगिक हैं - प्रत्येक के अपने फायदे और सीमाएँ हैं:

GitHub Actions में प्रॉक्सी सेट करना

GitHub Actions आज का सबसे लोकप्रिय CI/CD उपकरण है। यहाँ प्रॉक्सी सेटिंग्स पर्यावरण चर और रिपॉजिटरी के रहस्यों के माध्यम से की जाती हैं। आइए चरण-दर-चरण समझते हैं।

चरण 1: प्रॉक्सी डेटा को रिपॉजिटरी के रहस्यों में जोड़ें

कभी भी YAML फ़ाइल में प्रॉक्सी का लॉगिन और पासवर्ड सीधे न लिखें। GitHub Secrets का उपयोग करें:

1. रिपॉजिटरी खोलें → Settings → Secrets and variables → Actions
2. New repository secret पर क्लिक करें
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: GitHub Actions में SOCKS5 प्रॉक्सी

यदि आप 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: GitLab CI/CD Variables में चर जोड़ें

1. प्रोजेक्ट खोलें → Settings → CI/CD → Variables अनुभाग
2. Add variable पर क्लिक करें
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

Self-hosted 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. Manage Jenkins → System खोलें
2. HTTP Proxy Configuration अनुभाग खोजें
3. फील्ड भरें: सर्वर, पोर्ट, उपयोगकर्ता नाम, पासवर्ड
4. No Proxy Host फ़ील्ड में आंतरिक पते को कॉमा से अलग करके निर्दिष्ट करें
5. परीक्षण के लिए Test URL पर क्लिक करें और सहेजें

यह सेटिंग Jenkins के प्लगइन्स और अपडेट को लोड करने पर प्रभाव डालती है, लेकिन स्वचालित रूप से पाइपलाइन के रनटाइम वातावरण में नहीं जाती। पाइपलाइनों के लिए अलग सेटिंग की आवश्यकता है।

विधि 2: Declarative Pipeline के माध्यम से environment में प्रॉक्सी

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 Credentials में प्रॉक्सी क्रेडेंशियल्स जोड़ें

1. Manage Jenkins → Credentials → System → Global credentials खोलें
2. Add Credentials पर क्लिक करें
3. प्रकार: Secret text
4. ID: proxy-url-credential
5. गुप्त: http://user:[email protected]:port

विधि 3: Java प्रोजेक्ट के लिए JVM पैरामीटर के माध्यम से प्रॉक्सी

यदि आपका पाइपलाइन 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 के अंदर पैकेज स्थापित करने के लिए), तो build arguments का उपयोग करें:

# .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 daemon के लिए प्रॉक्सी का वैश्विक सेटअप

Self-hosted रनर्स पर, Docker daemon के लिए प्रॉक्सी सेट किया जा सकता है - तब सभी कंटेनर बिना 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 में Masked variables और GitHub में Encrypted secrets का उपयोग करें - ये लॉग में छिपे रहते हैं
• ✅ Jenkins में Secret text या Username with password प्रकार का उपयोग करें
• ✅ आंतरिक पते के लिए NO_PROXY जोड़ें - अपनी अवसंरचना के लिए ट्रैफ़िक प्रॉक्सी के माध्यम से नहीं जाना चाहिए
• ✅ प्रॉक्सी पासवर्ड को नियमित रूप से घुमाएँ - केवल रहस्य भंडार में अपडेट करें, पाइपलाइन कोड को न बदलें
• ✅ जहाँ संभव हो, प्रॉक्सी के लिए IP प्रमाणीकरण का उपयोग करें (रनर के IP को व्हाइटलिस्ट करें) - यह पासवर्ड से अधिक सुरक्षित है
• ✅ असामान्य गतिविधि के लिए प्रॉक्सी के लॉग की जाँच करें

प्रॉक्सी URL प्रारूप: क्या कहाँ डालना है

आम गलतियाँ और उन्हें कैसे ठीक करें

सही सेटअप के बाद भी समस्याएँ उत्पन्न हो सकती हैं। यहाँ सबसे सामान्य गलतियाँ और उनके समाधान दिए गए हैं:

त्रुटि: प्रॉक्सी प्रमाणीकरण आवश्यक (407)

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

त्रुटि: प्रॉक्सी के माध्यम से कनेक्शन टाइमआउट

त्रुटि: उपकरण HTTP_PROXY चर को अनदेखा करता है

त्रुटि: आंतरिक सेवाएँ भी प्रॉक्सी के माध्यम से जाती हैं

निष्कर्ष

CI/CD पाइपलाइन में प्रॉक्सी सेट करना एक बार का कार्य नहीं है, बल्कि स्वचालन की सही वास्तुकला का हिस्सा है। हमने तीन मुख्य उपकरणों पर चर्चा की: GitHub Actions (Secrets और पर्यावरण चर के माध्यम से), GitLab CI (मास्किंग के साथ Variables के माध्यम से) और Jenkins (Credentials Store और Declarative Pipeline के माध्यम से)। सभी के लिए मुख्य सिद्धांत समान हैं: कभी भी क्रेडेंशियल्स को कोड में न रखें, आंतरिक पते के लिए NO_PROXY का उपयोग करें और विशिष्ट कार्य के लिए प्रॉक्सी का प्रकार चुनें।

सही प्रॉक्सी प्रकार का चयन पाइपलाइन की स्थिरता के लिए महत्वपूर्ण है। निर्भरता डाउनलोड करने और मानक API को कॉल करने के लिए तेज़ डेटा सेंटर प्रॉक्सी पर्याप्त हैं। यदि आपकी पाइपलाइन वास्तविक वेबसाइटों पर एकीकरण परीक्षण कर रही है, विज्ञापन प्लेटफार्मों (Facebook Ads API, TikTok Ads API) के साथ काम कर रही है या मार्केटप्लेस को कॉल कर रही है - तो निवासी प्रॉक्सी का उपयोग करें: उनके IP सामान्य उपयोगकर्ता ट्रैफ़िक के रूप में माने जाते हैं और बहुत कम ही अवरोधों या रेट लिमिटिंग के अधीन होते हैं।

मुख्य नियम: पाइपलाइन की शुरुआत में प्रॉक्सी का परीक्षण एक अलग चरण में करें - यह समस्याओं का तेजी से निदान करने की अनुमति देगा और लंबी निर्माण प्रक्रिया के अंत में त्रुटियों की खोज में समय बर्बाद नहीं करेगा। प्रॉक्सी सेट करने के तुरंत बाद curl -v https://api.ipify.org चरण जोड़ें - यह दिखाएगा कि अनुरोध किस IP से जा रहे हैं और पुष्टि करेगा कि प्रॉक्सी सही ढंग से काम कर रही है।