डॉकर में इमेज और कंटेनर एप्लिकेशन के लिए प्रॉक्सी सेटअप: पूर्ण गाइड

क्या आप कॉर्पोरेट नेटवर्क में Docker के साथ काम कर रहे हैं, सीमित पहुंच वाले सर्वर पर हैं या चाहते हैं कि आपके कंटेनर एक विशिष्ट IP के माध्यम से इंटरनेट से जुड़ें? सही प्रॉक्सी सेटअप के बिना, Docker बस Docker Hub या किसी अन्य रजिस्ट्री से छवियों को डाउनलोड नहीं कर सकेगा। इस लेख में, हम प्रॉक्सीकरण के सभी स्तरों का विश्लेषण करेंगे - डेमन से लेकर अलग कंटेनर तक।

Docker के लिए प्रॉक्सी की आवश्यकता क्यों है

Docker एक उपकरण है जो लगातार बाहरी संसाधनों से संपर्क करता है। प्रत्येक docker pull या docker build पर, डेमन Docker Hub, GitHub कंटेनर रजिस्ट्री, Google कंटेनर रजिस्ट्री या आपके निजी रजिस्ट्री में जाता है। और यहीं समस्याएं शुरू होती हैं।

ऐसी स्थितियाँ जहाँ प्रॉक्सी की आवश्यकता होती है:

• कॉर्पोरेट नेटवर्क जिसमें फ़ायरवॉल है - सभी ट्रैफ़िक को कॉर्पोरेट प्रॉक्सी सर्वर के माध्यम से जाना चाहिए, अन्यथा कनेक्शन अवरुद्ध हो जाएगा।
• भौगोलिक प्रतिबंध - Docker Hub या अलग रजिस्ट्री आपके देश या डेटा सेंटर से उपलब्ध नहीं हैं।
• सीमित सर्वर जिसमें सीधे इंटरनेट का एक्सेस नहीं है - बंद सर्किट में VPS, जहाँ इंटरनेट केवल गेटवे के माध्यम से उपलब्ध है।
• कंटेनरों के आउटगोइंग ट्रैफ़िक का नियंत्रण - आप चाहते हैं कि कंटेनरों के भीतर अनुप्रयोग एक विशिष्ट IP के माध्यम से नेटवर्क से जुड़ें, जैसे कि पार्सिंग, API अनुरोधों या भू-निर्भर सामग्री का परीक्षण करने के लिए।
• अनामिकरण अनुरोध - कंटेनर से बाहरी सेवाओं को कॉल करते समय सर्वर का वास्तविक IP छिपाना।
• रेट लिमिटिंग - Docker Hub अनाम उपयोगकर्ताओं के लिए खींचने के अनुरोधों की संख्या को सीमित करता है (6 घंटे में 100 खींचना)। IP रोटेशन के साथ प्रॉक्सी के माध्यम से इस सीमा को बायपास किया जा सकता है।

यह समझना महत्वपूर्ण है कि Docker एक एप्लिकेशन नहीं है, बल्कि कई घटकों की एक प्रणाली है। डेमन (dockerd) होस्ट पर रहता है और छवियों को खींचता है। कंटेनर अपने नेटवर्क सेटिंग्स के साथ अलग-थलग प्रक्रियाएँ हैं। इसलिए, डेमन और कंटेनरों के लिए प्रॉक्सी सेट करना दो अलग-अलग कार्य हैं, जिन्हें अलग-अलग तरीके से हल किया जाता है।

Docker में प्रॉक्सीकरण के तीन स्तर

कॉन्फ़िगरेशन में जाने से पहले, आर्किटेक्चर को समझना आवश्यक है। Docker में तीन स्वतंत्र स्तर हैं, प्रत्येक को प्रॉक्सी के लिए अलग सेटअप की आवश्यकता होती है:

एक सामान्य गलती - केवल एक स्तर पर प्रॉक्सी सेट करना और यह देखकर आश्चर्यचकित होना कि छवियाँ फिर भी नहीं खींची जा रही हैं या अनुप्रयोग प्रॉक्सी को नहीं देखता। चलिए हम प्रत्येक स्तर का विस्तार से विश्लेषण करते हैं।

Docker डेमन के लिए प्रॉक्सी सेटअप (छवियों को खींचना)

यह सबसे महत्वपूर्ण सेटिंग है यदि आप प्रॉक्सी के माध्यम से छवियाँ खींचना चाहते हैं। Docker डेमन एक सिस्टम सेवा है, जो systemd के माध्यम से शुरू होती है। आपके उपयोगकर्ता या यहां तक कि रूट के पर्यावरण चर उसे दिखाई नहीं देते हैं। प्रॉक्सी को सेवा के वातावरण में ही पास करना आवश्यक है।

विधि 1: systemd ओवरराइड के माध्यम से (अनुशंसित)

सेवा सेटिंग्स को ओवरराइड करने के लिए एक निर्देशिका बनाएं:

sudo mkdir -p /etc/systemd/system/docker.service.d

निम्नलिखित सामग्री के साथ /etc/systemd/system/docker.service.d/http-proxy.conf नामक एक फ़ाइल बनाएं:

[Service]
Environment="HTTP_PROXY=http://username:password@proxy-host:port"
Environment="HTTPS_PROXY=http://username:password@proxy-host:port"
Environment="NO_PROXY=localhost,127.0.0.1,::1,your-private-registry.example.com"

यदि प्रॉक्सी बिना प्रमाणीकरण के है - तो बस username:password@ हटा दें। फ़ाइल बनाने के बाद, systemd कॉन्फ़िगरेशन को पुनः लोड करें और Docker को पुनः प्रारंभ करें:

sudo systemctl daemon-reload
sudo systemctl restart docker

सुनिश्चित करें कि सेटिंग्स लागू हुई हैं:

sudo systemctl show --property=Environment docker

आउटपुट में आपके चर HTTP_PROXY और HTTPS_PROXY दिखाई देने चाहिए।

विधि 2: ~/.docker/config.json के माध्यम से (Docker डेस्कटॉप और नए संस्करण)

Docker Engine 23.0 से एक अधिक सुविधाजनक तरीका आया है - क्लाइंट कॉन्फ़िगरेशन फ़ाइल के माध्यम से प्रॉक्सी सेट करना। ~/.docker/config.json फ़ाइल बनाएं या संपादित करें:

{
  "proxies": {
    "default": {
      "httpProxy": "http://username:password@proxy-host:port",
      "httpsProxy": "http://username:password@proxy-host:port",
      "noProxy": "localhost,127.0.0.1,::1"
    }
  }
}

यह तरीका इस मायने में सुविधाजनक है कि इसे रूट अधिकारों और डेमन को पुनः प्रारंभ करने की आवश्यकता नहीं होती। सेटिंग्स स्वचालित रूप से निर्माण के दौरान कंटेनरों में पास की जाती हैं। हालाँकि, डेमन के खींचने के अनुरोधों को प्रबंधित करने के लिए systemd के माध्यम से एक तरीका आवश्यक है।

निर्माण के समय कंटेनर के भीतर प्रॉक्सी

जब Docker एक छवि बनाता है और RUN apt-get install, RUN pip install या RUN npm install जैसे कमांड निष्पादित करता है - ये कमांड अस्थायी कंटेनर के भीतर निष्पादित होते हैं। इसके पास डिफ़ॉल्ट रूप से होस्ट प्रॉक्सी तक पहुंच नहीं होती है। प्रॉक्सी को स्पष्ट रूप से निर्माण तर्कों के माध्यम से पास करना आवश्यक है।

--build-arg के माध्यम से प्रॉक्सी पास करना

docker build \
  --build-arg HTTP_PROXY=http://proxy-host:port \
  --build-arg HTTPS_PROXY=http://proxy-host:port \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  -t my-image .

Dockerfile में सेटअप

यदि प्रॉक्सी केवल निर्माण के चरण में आवश्यक है और आप नहीं चाहते कि यह अंतिम छवि में शामिल हो - तो ARG का उपयोग करें, ENV नहीं:

FROM ubuntu:22.04

# निर्माण तर्क घोषित करें
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# उन्हें कमांड में उपयोग करें
RUN apt-get update && apt-get install -y curl wget

# इस ब्लॉक के बाद प्रॉक्सी ENV कंटेनर में नहीं होगा

यदि प्रॉक्सी चल रहे कंटेनर में भी आवश्यक है - तो ENV का उपयोग करें:

FROM python:3.11

ENV HTTP_PROXY=http://proxy-host:port
ENV HTTPS_PROXY=http://proxy-host:port
ENV NO_PROXY=localhost,127.0.0.1

RUN pip install requests beautifulsoup4

CMD ["python", "app.py"]

चलते हुए कंटेनर के लिए प्रॉक्सी

यह अनुप्रयोगों के लिए सबसे सामान्य परिदृश्य है जो काम करते समय HTTP अनुरोध करते हैं - पार्सर, बॉट, माइक्रोसर्विसेज जिन्हें एक विशिष्ट IP के माध्यम से बाहर निकलने की आवश्यकता होती है। यहाँ सेटअप अधिकतम सरल है: कंटेनर चलाते समय पर्यावरण चर पास करना आवश्यक है।

docker run के माध्यम से

docker run \
  -e HTTP_PROXY=http://username:password@proxy-host:port \
  -e HTTPS_PROXY=http://username:password@proxy-host:port \
  -e NO_PROXY=localhost,127.0.0.1 \
  my-image

अधिकांश लोकप्रिय HTTP पुस्तकालय स्वचालित रूप से HTTP_PROXY और HTTPS_PROXY चर को पकड़ लेते हैं: Python requests, curl, wget, Go का net/http, Node.js https-proxy-agent और अन्य। कोड में कुछ अतिरिक्त लिखने की आवश्यकता नहीं है।

.env फ़ाइल के माध्यम से

सेटिंग्स को .env फ़ाइल में रखना और इसे संपूर्ण रूप से पास करना अधिक सुविधाजनक है:

# .env फ़ाइल
HTTP_PROXY=http://username:password@proxy-host:port
HTTPS_PROXY=http://username:password@proxy-host:port
NO_PROXY=localhost,127.0.0.1

docker run --env-file .env my-image

SOCKS5 प्रॉक्सी कंटेनर में

यदि आप SOCKS5 प्रॉक्सी का उपयोग कर रहे हैं (उदाहरण के लिए, रहवासी प्रॉक्सी आमतौर पर इस प्रोटोकॉल का समर्थन करते हैं), तो सिंटैक्स थोड़ा भिन्न होता है:

docker run \
  -e ALL_PROXY=socks5://username:password@proxy-host:port \
  my-image

ध्यान दें: सभी पुस्तकालय SOCKS5 को पर्यावरण चर के माध्यम से बिना अतिरिक्त निर्भरताओं के समर्थन नहीं करते हैं। Python requests को requests[socks] स्थापित करने की आवश्यकता है, curl को libcurl-socks के समर्थन के साथ संकलित किया जाना चाहिए।

Docker Compose में प्रॉक्सी

वास्तविक परियोजनाओं में सामान्यतः docker run का उपयोग नहीं किया जाता है। अक्सर Docker Compose के साथ काम किया जाता है, जहाँ कई सेवाएँ एक ही फ़ाइल में वर्णित होती हैं। यहाँ प्रॉक्सी सेटिंग प्रत्येक सेवा के स्तर पर या वेरिएबल फ़ाइल के माध्यम से की जाती है।

विकल्प 1: docker-compose.yml में environment

version: '3.8'

services:
  scraper:
    image: my-scraper:latest
    environment:
      - HTTP_PROXY=http://username:password@proxy-host:port
      - HTTPS_PROXY=http://username:password@proxy-host:port
      - NO_PROXY=localhost,127.0.0.1
    restart: unless-stopped

  api:
    image: my-api:latest
    # यह सेवा बिना प्रॉक्सी के है - केवल आंतरिक संसाधनों को कॉल करती है
    ports:
      - "8080:8080"

विकल्प 2: .env फ़ाइल के माध्यम से (अनुशंसित)

.env को docker-compose.yml के साथ निर्देशिका में बनाएं। Docker Compose स्वचालित रूप से इस फ़ाइल को पकड़ता है:

# .env
PROXY_HOST=proxy-host
PROXY_PORT=8080
PROXY_USER=username
PROXY_PASS=password

version: '3.8'

services:
  scraper:
    image: my-scraper:latest
    environment:
      - HTTP_PROXY=http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}
      - HTTPS_PROXY=http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}
      - NO_PROXY=localhost,127.0.0.1

Compose में निर्माण के दौरान प्रॉक्सी

यदि Compose में build अनुभाग है और निर्माण के चरण में प्रॉक्सी पास करने की आवश्यकता है:

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        HTTP_PROXY: http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}
        HTTPS_PROXY: http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}
    environment:
      - HTTP_PROXY=http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}
      - HTTPS_PROXY=http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}

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

प्रॉक्सी के प्रकार का चयन कार्य पर निर्भर करता है। Docker वातावरण के लिए तीन मुख्य प्रकार प्रासंगिक हैं, प्रत्येक का अपना स्थान है:

छवियों को खींचने और CI/CD के लिए डेटा सेंटर प्रॉक्सी सबसे उपयुक्त हैं - वे बड़े छवियों (कई गीगाबाइट) को डाउनलोड करते समय अधिकतम गति और लंबे निर्माण के लिए स्थिर कनेक्शन प्रदान करते हैं।

पार्सर कंटेनरों के लिए, जिन्हें वेबसाइटों की सुरक्षा को बायपास करना और सामान्य उपयोगकर्ता के रूप में दिखना है, रहवासी प्रॉक्सी सबसे उपयुक्त हैं। उनके पास वास्तविक घरेलू उपयोगकर्ताओं के IP होते हैं, जो तीव्र अनुरोधों के बावजूद अवरोधन की संभावना को कम करता है।

मोबाइल प्लेटफार्मों के साथ काम करने वाले अनुप्रयोगों के लिए - Instagram Graph API, TikTok API, सेवाओं के मोबाइल संस्करणों के लिए मोबाइल प्रॉक्सी पर विचार करना चाहिए। वे सेलुलर ऑपरेटरों के IP का उपयोग करते हैं और एंटी-बॉट सिस्टम के लिए न्यूनतम संदेह उत्पन्न करते हैं।

प्रोटोकॉल: HTTP बनाम SOCKS5

Docker डेमन केवल HTTP/HTTPS प्रॉक्सी का समर्थन करता है - SOCKS5 छवियों को खींचने के लिए काम नहीं करता। यदि आपके पास SOCKS5 प्रॉक्सी है और छवियाँ डाउनलोड करनी हैं, तो आपको privoxy या microsocks जैसे स्थानीय कनवर्टर का उपयोग करना होगा, जो HTTP को स्वीकार करेगा और SOCKS5 के माध्यम से प्रॉक्सी करेगा।

रनटाइम कंटेनरों के लिए स्थिति बेहतर है: अधिकांश HTTP पुस्तकालय SOCKS5 को सीधे ALL_PROXY=socks5://... के माध्यम से समर्थन करते हैं।

सामान्य त्रुटियाँ और उन्हें कैसे ठीक करें

हम Docker में प्रॉक्सी सेट करते समय सबसे सामान्य समस्याओं का विश्लेषण करेंगे:

त्रुटि 1: प्रॉक्सी होस्ट पर सेट है, लेकिन Docker इसे नहीं देखता

कारण: Docker डेमन एक सिस्टम सेवा के रूप में चलता है और वर्तमान उपयोगकर्ता के पर्यावरण चर को विरासत में नहीं लेता, भले ही आपने टर्मिनल में export HTTPS_PROXY=... सेट किया हो।

हल: प्रॉक्सी को systemd ओवरराइड के माध्यम से सेट करें (ऊपर के अनुभाग में विधि 1)। सुनिश्चित करें कि आप systemctl daemon-reload && systemctl restart docker चलाते हैं।

त्रुटि 2: apt-get / pip / npm निर्माण के दौरान काम नहीं करते

कारण: डेमन के लिए प्रॉक्सी सेटिंग स्वचालित रूप से Dockerfile में RUN के भीतर कमांड पर लागू नहीं होती। ये दो अलग-अलग संदर्भ हैं।

हल: प्रॉक्सी को --build-arg के माध्यम से पास करें या ~/.docker/config.json का उपयोग करें जिसमें proxies अनुभाग हो (Docker 23.0+, स्वचालित रूप से निर्माण के दौरान तर्क पास करता है)।

त्रुटि 3: आंतरिक सेवाएँ प्रॉक्सी के माध्यम से उपलब्ध नहीं हैं

कारण: प्रॉक्सी आंतरिक पते के लिए अनुरोधों को प्रॉक्सी करने की कोशिश कर रहा है, जो बाहर से उपलब्ध नहीं हैं।

हल: सभी आंतरिक डोमेन और उप-नेटवर्क को NO_PROXY में जोड़ें। कॉर्पोरेट नेटवर्क के लिए सामान्य सूची: localhost,127.0.0.1,::1,.internal,.local,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

त्रुटि 4: प्रॉक्सी प्रमाणीकरण काम नहीं कर रहा है - पासवर्ड में विशेष वर्ण

यदि पासवर्ड में विशेष वर्ण (@, #, %) हैं, तो URL ठीक से पार्स नहीं होता है।

हल: पासवर्ड को URL-कोडिंग में एन्कोड करें। उदाहरण के लिए, p@ss#word → p%40ss%23word। Python में आप जल्दी से एन्कोडेड संस्करण प्राप्त कर सकते हैं:

python3 -c "from urllib.parse import quote; print(quote('p@ss#word', safe=''))"
# आउटपुट: p%40ss%23word

त्रुटि 5: प्रॉक्सी काम कर रहा है, लेकिन SSL प्रमाणपत्र की जांच नहीं हो रही है

कॉर्पोरेट प्रॉक्सी अक्सर SSL निरीक्षण (MITM) करते हैं और प्रमाणपत्रों को बदलते हैं। इस स्थिति में, Docker त्रुटि देता है:

हल: कॉर्पोरेट रूट प्रमाणपत्र को होस्ट पर विश्वसनीय में जोड़ें और Docker को पुनः प्रारंभ करें। Ubuntu/Debian पर:

sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
sudo systemctl restart docker

त्रुटि 6: Kubernetes / Docker Swarm - प्रॉक्सी सभी नोड्स पर काम नहीं कर रहा है

क्लस्टर वातावरण में, प्रत्येक नोड पर प्रॉक्सी को अलग से सेट करना आवश्यक है। Kubernetes के लिए, Pods के मैनिफेस्ट में या ConfigMap के माध्यम से पर्यावरण चर को अतिरिक्त रूप से सेट करना आवश्यक है। इसे Ansible या अन्य कॉन्फ़िगरेशन प्रबंधन उपकरणों के माध्यम से स्वचालित किया जा सकता है।

निष्कर्ष

Docker में प्रॉक्सी सेट करना एक सेटिंग नहीं है, बल्कि तीन स्वतंत्र स्तर हैं: छवियों को खींचने के लिए डेमन, निर्माण के लिए निर्माण समय और चल रहे कंटेनरों के लिए रनटाइम। इस आर्किटेक्चर को समझने के बाद, आप यह लचीले ढंग से प्रबंधित कर सकते हैं कि कौन सा ट्रैफ़िक प्रॉक्सी के माध्यम से जाता है और कौन सा सीधे।

सही सेटअप के लिए संक्षिप्त चेकलिस्ट:

• ✅ छवियों को खींचने के लिए - HTTP_PROXY और HTTPS_PROXY के साथ systemd ओवरराइड सेट करें
• ✅ निर्माण के लिए - प्रॉक्सी को --build-arg या ~/.docker/config.json के माध्यम से पास करें
• ✅ रनटाइम के लिए - -e या --env-file के माध्यम से पर्यावरण चर का उपयोग करें
• ✅ हमेशा आंतरिक पते के लिए NO_PROXY सेट करें
• ✅ Dockerfile में प्रॉक्सी के पासवर्ड को न रखें - build-args और .env फ़ाइलों का उपयोग करें
• ✅ CI/CD पाइपलाइनों के लिए तेज़ डेटा सेंटर प्रॉक्सी चुनें
• ✅ पार्सर कंटेनरों के लिए - रहवासी या मोबाइल प्रॉक्सी

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