Docker Proxy: कॉर्पोरेट फ़ायरवॉल के पीछे कंटेनरों को काम में लाने की संपूर्ण गाइड

अधिकांश एंटरप्राइज़ नेटवर्क इंटरनेट ट्रैफ़िक की निगरानी और फ़िल्टरिंग के लिए प्रॉक्सी सर्वर का उपयोग करते हैं। जब Docker रजिस्ट्री से इमेज़ पुल करने की कोशिश करता है तो यह बाधाएँ पैदा करता है। आपको अपने होम नेटवर्क पर काम करने वाली चीज़ों के लिए भी कनेक्शन टाइमआउट, ऑथेंटिकेशन एरर, और फेल्ड बिल्ड्स मिलेंगे। ये प्रॉक्सी-संबंधित समस्याएँ उन विकास टीमों को रोक सकती हैं जिन्हें बेस इमेज़ तक पहुँच नहीं मिल पाती।

Docker प्रॉक्सी कॉन्फ़िगरेशन इन कनेक्टिविटी समस्याओं को हल करता है, साथ ही कैशिंग के ज़रिए प्रदर्शन में सुधार और कॉर्पोरेट सुरक्षा आवश्यकताओं को पूरा करता है। एक बार कॉन्फ़िगर हो जाने पर, आपके कंटेनर नेटवर्क प्रतिबंधों की परवाह किए बिना इमेज़ पुल कर पाएँगे।

इस ट्यूटोरियल में, मैं आपको Docker डेमन प्रॉक्सी सेटिंग्स सेट करने, कंटेनर एनवायरनमेंट वेरिएबल्स कॉन्फ़िगर करने और Docker Compose में प्रॉक्सी कॉन्फ़िगरेशन हैंडल करने की प्रक्रिया समझाऊँगा।

Docker में नए हैं और नेटवर्किंग कॉन्सेप्ट से घबराहट हो रही है? Docker की बुनियादी बातें से शुरुआत करें और चरणबद्ध ढंग से आत्मविश्वास बढ़ाएँ।

Docker प्रॉक्सी आर्किटेक्चर को समझना

Docker इकोसिस्टम के अलग-अलग हिस्सों को अलग-अलग लेयर पर प्रॉक्सी कॉन्फ़िगरेशन की ज़रूरत होती है।

प्रॉक्सी आपके Docker घटकों और बाहरी नेटवर्क के बीच मध्यस्थ की तरह काम करते हैं। जब Docker को इमेज़ पुल करनी होती हैं, कंटेनरों को इंटरनेट एक्सेस चाहिए होता है, या बिल्ड्स को बाहरी संसाधनों की आवश्यकता होती है, तो प्रॉक्सी सर्वर इन कनेक्शनों को नियंत्रित और मॉनिटर करते हैं। वे आपके कंटेनराइज़्ड ऐप्लिकेशनों और बाहरी दुनिया के बीच बैठते हैं और अनुरोधों व प्रतिक्रियाओं को फ़िल्टर करते हैं।

संगठन Docker के साथ प्रदर्शन, सुरक्षा और अनुपालन के लिए प्रॉक्सी का उपयोग करते हैं।

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

Docker प्रॉक्सी कॉन्फ़िगरेशन चार लेयर पर होता है:

• क्लाइंट प्रॉक्सी: Docker CLI कमांड जैसे docker pull और docker push को प्रभावित करता है

• डेमन प्रॉक्सी: नियंत्रित करता है कि Docker डेमन बाहरी रजिस्ट्री तक कैसे पहुँचता है  

• कंटेनर रनटाइम प्रॉक्सी: कंटेनरों के अंदर ऐप्लिकेशन के लिए प्रॉक्सी वेरिएबल सेट करता है

• बिल्ड-टाइम प्रॉक्सी: docker build ऑपरेशन के दौरान सेटिंग्स संभालता है जब Dockerfiles को इंटरनेट एक्सेस चाहिए होता है

हर लेयर का अपना उद्देश्य है और अपनी कॉन्फ़िगरेशन पद्धति चाहिए।

Docker नेटवर्किंग को समझना यह समझने से शुरू होता है कि कंटेनर कैसे संचार करते हैं। 

प्रॉक्सी के साथ Docker को कॉन्फ़िगर करना

कॉर्पोरेट प्रॉक्सी के साथ Docker को काम में लाने के लिए आपको Docker डेमन और क्लाइंट—दोनों सेट करने होंगे।

क्यों? क्योंकि ये अलग-अलग प्रकार के नेटवर्क अनुरोध संभालते हैं। 

डेमन इमेज़ पुल, पुश और रजिस्ट्री ऑथेंटिकेशन मैनेज करता है, जबकि क्लाइंट CLI ऑपरेशन और API कॉल संभालता है। किसी एक की भी सेटिंग छूटने पर ऐसे गैप रह जाते हैं जहाँ Docker ऑपरेशन कनेक्शन एरर के साथ फेल हो सकते हैं।

Docker डेमन को कैसे कॉन्फ़िगर करें

Docker डेमन /etc/docker/daemon.json से प्रॉक्सी सेटिंग्स पढ़ता है। अगर यह फ़ाइल मौजूद नहीं है तो इसे बनाएँ:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}संचालित द्वारा

noProxy फ़ील्ड उन पतों की सूची देता है जिन्हें प्रॉक्सी को बायपास करना चाहिए। यहाँ अपने आंतरिक रजिस्ट्री डोमेन और localhost पते शामिल करें।

systemd सर्विस ओवरराइड सेट करना

systemd-आधारित Linux सिस्टम पर, आपको Docker सर्विस को भी प्रॉक्सी का उपयोग करने के लिए कॉन्फ़िगर करना होगा। ओवरराइड डायरेक्टरी और कॉन्फ़िगरेशन फ़ाइल बनाएँ:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/http-proxy.confसंचालित द्वारा

इसके बाद, ये एनवायरनमेंट वेरिएबल्स http-proxy.conf फ़ाइल में जोड़ें:

[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.company.com"संचालित द्वारा

यह सुनिश्चित करता है कि Docker डेमन प्रक्रिया स्वयं आपके प्रॉक्सी के माध्यम से बाहरी सेवाओं तक पहुँच सके।

Docker तब तक प्रॉक्सी परिवर्तन नहीं उठाएगा जब तक आप डेमन को रीस्टार्ट नहीं करते। systemd को रीलोड करने और Docker को रीस्टार्ट करने के लिए ये कमांड चलाएँ:

sudo systemctl daemon-reload
sudo systemctl restart dockerसंचालित द्वारा

डेमन रीलोड systemd को नई सर्विस कॉन्फ़िगरेशन पढ़ने के लिए कहता है, जबकि Docker रीस्टार्ट daemon.json बदलाव लागू करता है।

प्लेटफ़ॉर्म-विशिष्ट बातें

Docker Desktop सर्वर इंस्टॉलेशनों से अलग तरह से प्रॉक्सी कॉन्फ़िगरेशन हैंडल करता है। Windows और macOS पर, Resources - Proxies सेक्शन में Docker Desktop GUI से प्रॉक्सी सेटिंग्स सेट करें। ये सेटिंग्स अपने-आप डेमन और क्लाइंट—दोनों को कॉन्फ़िगर करती हैं।

Docker Engine उपयोग करने वाले Linux होस्ट्स पर ऊपर बताई गई मैनुअल कॉन्फ़िगरेशन चाहिए। कुछ डिस्ट्रीब्यूशन Docker को अलग तरह से पैकेज करते हैं, तो जाँचें कि आपका सिस्टम dockerd को सीधे उपयोग करता है या किसी अलग सर्विस मैनेजर के माध्यम से।

अपनी कॉन्फ़िगरेशन की जाँच

साधारण पुल कमांड से जाँचें कि Docker बाहरी रजिस्ट्री तक पहुँच सकता है:

docker pull hello-worldसंचालित द्वारा

आप डेमन की प्रभावी कॉन्फ़िगरेशन भी देख सकते हैं:

docker system info | grep -i proxyसंचालित द्वारा

यह दिखाता है कि Docker ने आपकी प्रॉक्सी सेटिंग्स का पता लगाया और लागू किया है या नहीं।

अगर पुल अब भी फेल हों, तो यह पुष्ट करने के लिए अपने प्रॉक्सी सर्वर लॉग देखें कि Docker अनुरोध सही तरह रूट कर रहा है।

नेटवर्किंग समस्याओं में अटके हैं? कनेक्टिविटी की दिक्कतों से बचने के लिए Docker पोर्ट ठीक से एक्सपोज़ करें।

प्रॉक्सी एनवायरनमेंट वेरिएबल्स सेट करना

Docker CLI कमांड्स को डेमन सेटिंग्स से अलग अपनी प्रॉक्सी कॉन्फ़िगरेशन चाहिए। एनवायरनमेंट वेरिएबल्स आपको यह नियंत्रित करने की लचीलापन देती हैं कि Docker क्लाइंट्स कॉर्पोरेट प्रॉक्सी के माध्यम से कैसे कनेक्ट हों।

क्लाइंट प्रॉक्सी docker pull, docker push, और docker login जैसे Docker CLI ऑपरेशन नियंत्रित करते हैं। जब आप ये कमांड चलाते हैं, Docker क्लाइंट रजिस्ट्री को HTTP अनुरोध भेजता है और उसे पता होना चाहिए कि किस प्रॉक्सी सर्वर का उपयोग करना है। क्लाइंट प्रॉक्सी सेटिंग्स के बिना, ये ऑपरेशन फेल हो जाते हैं भले ही डेमन ठीक से कॉन्फ़िगर हो।

JSON कॉन्फ़िगरेशन विधि

सबसे साफ़ तरीका Docker के कॉन्फ़िगरेशन फ़ाइल ~/.docker/config.json का उपयोग करता है:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}संचालित द्वारा

यह तरीका प्रॉक्सी सेटिंग्स को Docker की कॉन्फ़िगरेशन तक सीमित रखता है और आपके सिस्टम पर अन्य ऐप्लिकेशनों को प्रभावित नहीं करता।

एनवायरनमेंट वेरिएबल विकल्प

आप मानक प्रॉक्सी एनवायरनमेंट वेरिएबल्स भी सेट कर सकते हैं जिन्हें Docker अपने-आप डिटेक्ट कर लेगा, इन कमांड्स का उपयोग करके:

export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.comसंचालित द्वारा

ये वेरिएबल्स किसी भी ऐसे ऐप के लिए काम करते हैं जो प्रॉक्सी मानकों का सम्मान करता है—सिर्फ Docker के लिए नहीं।

ग्लोबल बनाम प्रति-उपयोगकर्ता कॉन्फ़िगरेशन

सिस्टम-व्यापी कॉन्फ़िगरेशन के लिए, एनवायरनमेंट वेरिएबल्स को /etc/environment में जोड़ें या /etc/profile.d/ में एक स्क्रिप्ट बनाएँ:

# /etc/profile.d/proxy.sh
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.comसंचालित द्वारा

प्रति-उपयोगकर्ता कॉन्फ़िगरेशन के लिए, उन्हें अपने शेल प्रोफ़ाइल (~/.bashrc, ~/.zshrc) में जोड़ें या JSON कॉन्फ़िग विधि का उपयोग करें। प्रति-उपयोगकर्ता सेटिंग्स डेवलपर्स को अलग-अलग प्रॉक्सी इस्तेमाल करने या टेस्टिंग के लिए उन्हें पूरी तरह बायपास करने की लचीलापन देती हैं।

सुरक्षा संबंधी विचार

आपको कभी भी यूज़रनेम और पासवर्ड को कॉन्फ़िगरेशन फ़ाइलों या एनवायरनमेंट वेरिएबल्स में हार्डकोड नहीं करना चाहिए। 

प्लेन टेक्स्ट में प्रॉक्सी क्रेडेंशियल्स सुरक्षा जोखिम पैदा करते हैं, खासकर साझा वातावरणों या वर्शन कंट्रोल सिस्टम में।

इसके बजाय, इन तरीकों का उपयोग करें:

• जहाँ संभव हो, अपने प्रॉक्सी सर्वर को IP-आधारित ऑथेंटिकेशन के लिए कॉन्फ़िगर करें
• ऑथेंटिकेशन के लिए क्रेडेंशियल हेल्पर्स या सुरक्षित स्टोरेज सिस्टम का उपयोग करें
• Docker ऑपरेशन के लिए न्यूनतम अनुमतियों वाले सर्विस अकाउंट सेट करें

यदि आपको क्रेडेंशियल्स शामिल करने ही हों, तो http://username:[email protected]:8080 फ़ॉर्मैट का उपयोग करें, लेकिन इन्हें प्रतिबंधित परमिशन वाली सुरक्षित फ़ाइलों में स्टोर करें।

बिल्ड-टाइम प्रॉक्सी कॉन्फ़िगरेशन

Docker बिल्ड्स को प्रॉक्सी सेटिंग्स स्पष्ट रूप से बिल्ड आर्ग्युमेंट्स के ज़रिए पास करनी पड़ती हैं:

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  -t myapp .संचालित द्वारा

बिल्ड आर्ग्युमेंट्स बिल्ड कॉन्टेक्स्ट के अंदर एनवायरनमेंट वेरिएबल्स बन जाते हैं।

यह RUN निर्देशों को आपके प्रॉक्सी के माध्यम से पैकेज और निर्भरताएँ डाउनलोड करने देता है। इन आर्ग्युमेंट्स के बिना, जब Dockerfiles सॉफ़्टवेयर इंस्टॉल करने या इंटरनेट से संसाधन फ़ेच करने की कोशिश करते हैं तो बिल्ड्स फेल हो जाते हैं।

बिल्ड-टाइम प्रॉक्सी सेटिंग्स अंतिम इमेज़ में तब तक बनी नहीं रहतीं जब तक आप उन्हें अपने Dockerfile में ENV निर्देशों से स्पष्ट रूप से सेट न करें।

एनवायरनमेंट वेरिएबल्स आपको अपने वर्कफ़्लो के सही स्तर पर प्रॉक्सी सेटिंग्स संभालने की लचीलापन देते हैं।

क्या आपको बिल्ड आर्ग्युमेंट्स उलझाऊ लगते हैं? Docker build args में महारत हासिल करें वास्तविक, काम करने वाले उदाहरणों के साथ।

कंटेनर और बिल्ड-टाइम प्रॉक्सी इंजेक्शन

Docker क्लाइंट कॉन्फ़िगरेशन आपको आधा रास्ता ही ले जाती है—आपके कंटेनरों और बिल्ड्स को अपनी अलग प्रॉक्सी सेटिंग्स चाहिए। इस सेक्शन में, मैं रनटाइम और बिल्ड टाइम पर प्रॉक्सी कॉन्फ़िगरेशन इंजेक्ट करना दिखाऊँगा।

रनटाइम एनवायरनमेंट वेरिएबल्स

कंटेनर आपके होस्ट की प्रॉक्सी सेटिंग्स इनहेरिट नहीं करते।

कंटेनर शुरू करते समय आपको प्रॉक्सी वेरिएबल्स स्पष्ट रूप से पास करने होंगे। Docker आपको यह कई तरीकों से देता है, इस पर निर्भर करता है कि आप सभी कंटेनर कॉन्फ़िगर करना चाहते हैं या सिर्फ़ कुछ विशेष।

संगत प्रॉक्सी सेटिंग्स के लिए JSON कॉन्फ़िगरेशन सबसे साफ़ तरीका है—जैसा कि पहले चर्चा हुई। दोहराने के लिए, इसे अपने ~/.docker/config.json में जोड़ें:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}संचालित द्वारा

Docker अपने-आप ये वेरिएबल्स हर कंटेनर में इंजेक्ट कर देता है जिसे आप शुरू करते हैं। कोई अतिरिक्त फ़्लैग नहीं चाहिए।

CLI फ़्लैग प्रति-कंटेनर अधिक नियंत्रण देते हैं:

docker run \
  --env HTTP_PROXY=http://proxy.company.com:8080 \
  --env HTTPS_PROXY=http://proxy.company.com:8080 \
  --env NO_PROXY=localhost,127.0.0.1 \
  nginxसंचालित द्वारा

आप पूरा एनवायरनमेंट फ़ाइल भी पास कर सकते हैं:

# proxy.env
HTTP_PROXY=http://proxy.company.com:8080
HTTPS_PROXY=http://proxy.company.com:8080
NO_PROXY=localhost,127.0.0.1

docker run --env-file proxy.env nginxसंचालित द्वारा

मौजूदा कंटेनरों में स्टार्टअप के बाद docker exec के ज़रिए प्रॉक्सी वेरिएबल्स इंजेक्ट किए जा सकते हैं:

docker exec -e HTTP_PROXY=http://proxy.company.com:8080 container_name curl google.comसंचालित द्वारा

यह तरीका एकबारगी कमांड्स के लिए काम करता है लेकिन कंटेनर रीस्टार्ट के बाद बना नहीं रहता।

बिल्ड-टाइम प्रॉक्सी कॉन्फ़िगरेशन

प्रॉक्सी वातावरण में तब तक इमेज़ बिल्ड फेल होंगी जब तक आप प्रॉक्सी सेटिंग्स स्पष्ट रूप से पास नहीं करते।

बिल्ड आर्ग्युमेंट्स बिल्ड के दौरान प्रॉक्सी वेरिएबल्स इंजेक्ट करने का मानक तरीका हैं:

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  --tag myapp .संचालित द्वारा

आपके Dockerfile को इन आर्ग्युमेंट्स का उपयोग करने के लिए इन्हें घोषित करना होगा:

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Use proxy for package installation
RUN apt-get update && apt-get install -y curl

# Don't persist proxy in final imageसंचालित द्वारा

Dockerfile घोषणाएँ आपको डिफ़ॉल्ट प्रॉक्सी मान सेट करने देती हैं:

ARG HTTP_PROXY=http://proxy.company.com:8080
ARG HTTPS_PROXY=http://proxy.company.com:8080

ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY

RUN pip install requestsसंचालित द्वारा

ENV निर्देश आपके बिल्ड में सभी अगली RUN कमांड्स के लिए प्रॉक्सी वेरिएबल्स उपलब्ध कराता है।

आपको पता होना चाहिए कि BuildKit की सीमाएँ नए Docker वर्ज़न में प्रॉक्सी समस्याएँ पैदा कर सकती हैं। BuildKit बिल्ड कॉन्टेक्स्ट को आक्रामक रूप से कैश करता है, जो कभी-कभी प्रॉक्सी परिवर्तनों को नज़रअंदाज़ कर देता है।

आप BuildKit को प्रॉक्सी अपडेट पहचानने के लिए बाध्य कर सकते हैं:

DOCKER_BUILDKIT=1 docker build \
  --no-cache \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --tag myapp .संचालित द्वारा

या, आप प्रॉक्सी-संवेदनशील बिल्ड्स के लिए BuildKit को पूरी तरह डिसेबल कर सकते हैं:

DOCKER_BUILDKIT=0 docker build --build-arg HTTP_PROXY=$HTTP_PROXY --tag myapp .संचालित द्वारा

जहाँ तक मल्टी-स्टेज बिल्ड्स की बात है, उन्हें सभी स्टेज में सुसंगत प्रॉक्सी कॉन्फ़िगरेशन चाहिए:

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Build stage
FROM python:3.13 AS builder
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY requirements.txt .
RUN pip install -r requirements.txt

# Runtime stage
FROM python:3.13-slim AS runtime
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY --from=builder /usr/local/lib/python*/site-packages /usr/local/lib/python*/site-packages
RUN apt-get update && apt-get install -y curl

# Clear proxy variables for final image
ENV HTTP_PROXY=
ENV HTTPS_PROXY=
ENV NO_PROXY=संचालित द्वारा

प्रत्येक स्टेज बिल्ड आर्ग्युमेंट्स को इनहेरिट करता है लेकिन पिछले स्टेज के एनवायरनमेंट वेरिएबल्स को नहीं। जिन-जिन स्टेज में ज़रूरत हो, वहाँ प्रॉक्सी वेरिएबल्स स्पष्ट रूप से सेट करें।

संक्षेप में—एक बार कॉन्फ़िगर करें, हर जगह इंजेक्ट करें।

क्या आप अपने प्रॉक्सी-इनेबल्ड कंटेनरों में ENTRYPOINT बनाम CMD को लेकर उलझे हैं? व्यावहारिक उदाहरणों के साथ पूरा विश्लेषण पाएँ।

कंटेनरों में पैकेज मैनेजर को प्रॉक्सी के साथ कॉन्फ़िगर करना

Docker की प्रॉक्सी सेटिंग्स अपने-आप कंटेनरों के अंदर पैकेज मैनेजर तक नहीं जातीं। आपको प्रत्येक पैकेज मैनेजर को अलग से कॉन्फ़िगर करना होगा ताकि वह आपके कॉर्पोरेट प्रॉक्सी के माध्यम से पैकेज डाउनलोड कर सके।

apt-get, yum, और apk जैसे पैकेज मैनेजर सीधे पैकेज रिपॉज़िटरी से HTTP कनेक्शन बनाते हैं। प्रतिबंधित नेटवर्क वातावरण में, जब तक पैकेज मैनेजर को आपके प्रॉक्सी सर्वर की जानकारी न हो, ये कनेक्शन फेल हो जाते हैं।

मानक एनवायरनमेंट वेरिएबल्स काफ़ी नहीं हैं। अधिकांश पैकेज मैनेजर की अपनी कॉन्फ़िगरेशन फ़ाइलें होती हैं जो सिस्टम-व्यापी प्रॉक्सी सेटिंग्स को ओवरराइड कर देती हैं।

Ubuntu/Debian: apt-get कॉन्फ़िगरेशन

apt-get के लिए एक प्रॉक्सी कॉन्फ़िगरेशन फ़ाइल बनाएँ जिसे वह पैकेज इंस्टॉलेशन के दौरान पढ़ेगा।

अपने Dockerfile में यह जोड़ें:

FROM python:3.13

# Configure apt proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf && \
    echo 'Acquire::https::Proxy "http://proxy.company.com:8080";' >> /etc/apt/apt.conf.d/proxy.conf

RUN apt-get update && apt-get install -y curl wgetसंचालित द्वारा

/etc/apt/apt.conf.d/proxy.conf फ़ाइल apt-get को निर्देश देती है कि सभी पैकेज डाउनलोड आपके प्रॉक्सी के माध्यम से रूट किए जाएँ। यह फ़ाइल आपके बिल्ड में RUN कमांड्स के बीच बनी रहती है।

आप आंतरिक रिपॉज़िटरी के लिए प्रॉक्सी अपवाद भी सेट कर सकते हैं:

RUN echo 'Acquire::http::Proxy::internal.company.com "DIRECT";' >> /etc/apt/apt.conf.d/proxy.confसंचालित द्वारा

Alpine Linux: apk कॉन्फ़िगरेशन

Alpine apk पैकेज मैनेजर का उपयोग करता है, जो /etc/apk/repositories और एनवायरनमेंट वेरिएबल्स से प्रॉक्सी सेटिंग्स पढ़ता है।

FROM python:3.13-alpine

# Configure apk proxy
ENV HTTP_PROXY=http://proxy.company.com:8080
ENV HTTPS_PROXY=http://proxy.company.com:8080

RUN apk add --no-cache curl wgetसंचालित द्वारा

Alpine का apk मानक HTTP प्रॉक्सी एनवायरनमेंट वेरिएबल्स का पालन करता है, इसलिए अलग कॉन्फ़िगरेशन फ़ाइलों की ज़रूरत नहीं। लेकिन अधिक नियंत्रण के लिए आप एक बना सकते हैं:

RUN echo 'http_proxy=http://proxy.company.com:8080' > /etc/environment && \
    echo 'https_proxy=http://proxy.company.com:8080' >> /etc/environmentसंचालित द्वारा

CentOS/RHEL: yum कॉन्फ़िगरेशन

CentOS और RHEL सिस्टम yum या dnf का उपयोग करते हैं, जो /etc/yum.conf से प्रॉक्सी सेटिंग्स पढ़ते हैं।

FROM centos:8

# Configure yum proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/yum.conf

RUN yum update -y && yum install -y curl wgetसंचालित द्वारा

नए CentOS वर्ज़न जो dnf का उपयोग करते हैं, उनके लिए यह इस्तेमाल करें:

FROM centos:stream9

# Configure dnf proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/dnf/dnf.conf

RUN dnf update -y && dnf install -y curl wgetसंचालित द्वारा

आप प्रॉक्सी रूटिंग से विशिष्ट डोमेन को बाहर करने के लिए यह कमांड जोड़ सकते हैं:

RUN echo 'proxy_exclude=internal.company.com,localhost' >> /etc/yum.confसंचालित द्वारा

प्रॉक्सी फ़ंक्शनैलिटी की जाँच

सबसे पहले, आपको सत्यापित करना है कि आपका पैकेज मैनेजर प्रॉक्सी के माध्यम से रिपॉज़िटरी तक पहुँच सकता है।

अपने Dockerfile में टेस्ट कमांड जोड़ें:

FROM python:3.13

# Configure proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf

# Test package manager connectivity
RUN apt-get update && \
    apt-get install -y --dry-run curl && \
    echo "Package manager proxy test passed"

# Install actual packages
RUN apt-get install -y curl python3-pipसंचालित द्वारा

--dry-run फ़्लैग बिना कुछ इंस्टॉल किए पैकेज रेज़ोल्यूशन टेस्ट करता है। अगर यह सफल हो जाए, तो आपकी प्रॉक्सी कॉन्फ़िगरेशन काम कर रही है।

आप कनेक्शन समस्याओं को डिबग करने के लिए वर्बोज़ आउटपुट के साथ भी टेस्ट कर सकते हैं:

RUN apt-get -o Debug::Acquire::http=true updateसंचालित द्वारा

यह दिखाता है कि apt-get वास्तव में किन URL तक पहुँचने की कोशिश करता है और प्रॉक्सी कनेक्शन सफल होते हैं या नहीं।

Alpine टेस्टिंग के लिए, यह उपयोग करें:

RUN apk update --verbose && \
    apk add --simulate curl && \
    echo "Alpine proxy test passed"संचालित द्वारा

संक्षेप में, प्रत्येक पैकेज मैनेजर को अलग-अलग कॉन्फ़िगर करें, और आपके बिल्ड किसी भी प्रॉक्सी के पीछे काम करेंगे।

प्रॉक्सी-संबंधित बिल्ड आर्टिफ़ैक्ट्स को साफ़ करना है? Docker prune कमांड्स स्पेस खाली करेंगी और आपके सिस्टम को साफ़ रखेंगी।

एडवांस्ड प्रॉक्सी इम्प्लीमेंटेशन

बेसिक HTTP प्रॉक्सी शुरुआत के लिए ठीक हैं, लेकिन प्रोडक्शन वातावरण में रजिस्ट्री ऐक्सेस और इमेज़ कैशिंग पर अधिक नियंत्रण चाहिए। बेहतर प्रदर्शन और विश्वसनीयता के लिए कैशिंग प्रॉक्सी और रजिस्ट्री मिरर इस तरह सेट करें।

कैशिंग प्रॉक्सी रजिस्ट्री

बार-बार वही बेस इमेज़ पुल करना बैंडविड्थ बर्बाद करता है और बिल्ड धीमे करता है।

कैशिंग प्रॉक्सी आपके Docker क्लाइंट और Docker Hub जैसी बाहरी रजिस्ट्री के बीच बैठती हैं। वे अक्सर एक्सेस की जाने वाली इमेज़ लोकल में स्टोर करती हैं, ताकि अगली बार पुल इंटरनेट की बजाय आपके आंतरिक नेटवर्क से हों।

एंटरप्राइज़ वातावरण के लिए सबसे लोकप्रिय विकल्प Harbor है:

# docker-compose.yml for Harbor
version: '3.8'
services:
  harbor-core:
    image: goharbor/harbor-core:v2.8.0
    environment:
      - CORE_SECRET=your-secret-key
      - JOBSERVICE_SECRET=your-job-secret
    ports:
      - "80:8080"
    volumes:
      - ./harbor.yml:/etc/core/app.confसंचालित द्वारा

आप harbor.yml एडिट करके Harbor को प्रॉक्सी कैश के रूप में कॉन्फ़िगर कर सकते हैं:

# harbor.yml
hostname: harbor.company.com
http:
  port: 80

database:
  password: harbor-db-password

data_volume: /data

proxy_cache:
  - endpoint: https://registry-1.docker.io
    username: your-dockerhub-username
    password: your-dockerhub-tokenसंचालित द्वारा

यदि आपको बेसिक कैशिंग के लिए सरल विकल्प चाहिए, तो Docker Registry Proxy का उपयोग करें। ऐसे करें:

docker run -d \
  --name registry-proxy \
  -p 5000:5000 \
  -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
  -v registry-cache:/var/lib/registry \
  registry:2संचालित द्वारा

फिर, अपने Docker क्लाइंट्स को कैशिंग प्रॉक्सी की ओर इंगित करें:

{
  "registry-mirrors": ["http://harbor.company.com"]
}संचालित द्वारा

कैशिंग प्रॉक्सी से मिलने वाले सभी फ़ायदे यहाँ हैं:

• पहले डाउनलोड के बाद तेज़ इमेज़ पुल
• इंटरनेट बैंडविड्थ उपयोग में कमी
• जब बाहरी रजिस्ट्री में समस्याएँ हों तो बेहतर बिल्ड विश्वसनीयता
• केंद्रीकृत ऐक्सेस कंट्रोल और इमेज़ स्कैनिंग

रजिस्ट्री मिरर और BuildKit

रजिस्ट्री मिरर आपको इमेज़ पुल को आंतरिक या भौगोलिक रूप से नज़दीकी रजिस्ट्री की ओर रीडायरेक्ट करने देते हैं।

सिंगल मिरर कॉन्फ़िगरेशन सभी Docker Hub अनुरोधों को एक मिरर से होकर रूट करता है:

{
  "registry-mirrors": ["https://mirror.company.com"],
  "insecure-registries": ["harbor.company.com:5000"]
}संचालित द्वारा

इसे /etc/docker/daemon.json में जोड़ें और Docker रीस्टार्ट करें। सभी docker pull कमांड पहले मिरर आज़माएँगे, मिरर अनुपलब्ध होने पर Docker Hub पर वापस जाएँगे।

एकाधिक मिरर रिडंडंसी देते हैं:

{
  "registry-mirrors": [
    "https://mirror1.company.com",
    "https://mirror2.company.com",
    "https://registry-1.docker.io"
  ]
}संचालित द्वारा

Docker सफल होने तक क्रम में मिरर आज़माएगा।

BuildKit मिरर सेटअप को अलग कॉन्फ़िगरेशन चाहिए क्योंकि BuildKit कुछ डेमन सेटिंग्स को बायपास करता है:

# buildkitd.toml
debug = true

[registry."docker.io"]
  mirrors = ["mirror.company.com"]

[registry."mirror.company.com"]
  http = true
  insecure = trueसंचालित द्वारा

आप कस्टम कॉन्फ़िग के साथ BuildKit शुरू कर सकते हैं:

buildkitd --config=/etc/buildkit/buildkitd.tomlसंचालित द्वारा

या, BuildKit की इनलाइन मिरर कॉन्फ़िगरेशन का उपयोग करें:

docker buildx create \
  --name mybuilder \
  --config /etc/buildkit/buildkitd.toml \
  --useसंचालित द्वारा

अंत में, Docker Hub से पुल करने वाली इमेज़ बनाकर अपने मिरर सेटअप को टेस्ट करें:

FROM python:3.13-slim
RUN pip install requestsसंचालित द्वारा

docker build --progress=plain .संचालित द्वारा

--progress=plain फ़्लैग दिखाता है कि BuildKit वास्तव में किस रजिस्ट्री से संपर्क कर रहा है। आपको अपने मिरर URL बिल्ड आउटपुट में दिखाई देने चाहिए।

बस इतना ही!

जटिल मल्टी-कंटेनर प्रॉक्सी सेटअप मैनेज कर रहे हैं? Docker Compose नेटवर्किंग और सर्विस डिस्कवरी को सरल बनाता है।

सुरक्षा कड़ा करना

प्रॉक्सी कॉन्फ़िगरेशन नए हमले के अवसर खोलते हैं जिन पर सावधानी से ध्यान देने की ज़रूरत है। यहाँ बताया गया है कि Docker सॉकेट ऐक्सेस को कैसे लॉकडाउन करें और प्रॉक्सी क्रेडेंशियल्स को एक्सपोज़र से कैसे बचाएँ।

Docker सॉकेट प्रॉक्सी

Docker का सॉकेट सीधे एक्सपोज़ करना बड़ा सुरक्षा जोखिम बनाता है।

Docker सॉकेट (/var/run/docker.sock) आपके पूरे होस्ट सिस्टम तक रूट-लेवल एक्सेस देता है। कोई भी प्रक्रिया जो इस सॉकेट पर लिख सकती है, वह होस्ट फाइलसिस्टम ऐक्सेस वाले कंटेनर चला सकती है, प्रिविलेज बढ़ा सकती है, या कंटेनर आइसोलेशन को पूरी तरह तोड़ सकती है।

डायरेक्ट सॉकेट माउंटिंग खतरनाक है:

# DON'T DO THIS
docker run -v /var/run/docker.sock:/var/run/docker.sock myappसंचालित द्वारा

यह पैटर्न Docker-in-Docker सेटअप और CI/CD पाइपलाइनों में दिखता है, लेकिन यह सुरक्षा के लिए दुःस्वप्न है। कोई भी समझौता किया हुआ कंटेनर पूरे Docker डेमन को नियंत्रित कर सकता है।

सॉकेट प्रॉक्सी सेवाएँ एक सुरक्षित मध्य परत बनाती हैं। वे Docker API कॉल्स को फ़िल्टर करती हैं और यह सीमित करती हैं कि कंटेनर वास्तव में क्या कर सकते हैं।

Tecnativa का docker-socket-proxy उपयोग करें:

# docker-compose.yml
version: '3.8'
services:
  docker-proxy:
    image: tecnativa/docker-socket-proxy
    environment:
      - CONTAINERS=1
      - IMAGES=1
      - NETWORKS=1
      - VOLUMES=1
      - BUILD=0
      - COMMIT=0
      - CONFIGS=0
      - SECRETS=0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "2375:2375"संचालित द्वारा

प्रॉक्सी केवल विशिष्ट Docker API एंडपॉइंट्स एक्सपोज़ करता है। अनुमत ऑपरेशनों के लिए एनवायरनमेंट वेरिएबल्स को 1 पर और ब्लॉक किए गए के लिए 0 पर सेट करें।

आपके ऐप्लिकेशन कच्चे सॉकेट की बजाय प्रॉक्सी से कनेक्ट होते हैं:

docker run --env DOCKER_HOST=tcp://docker-proxy:2375 myappसंचालित द्वारा

अनुसरण करने के लिए कुछ अतिरिक्त सॉकेट हार्डनिंग रणनीतियाँ:

• सॉकेट प्रॉक्सी को अलग नेटवर्क सेगमेंट पर चलाएँ
• क्लाइंट और प्रॉक्सी के बीच TLS ऑथेंटिकेशन का उपयोग करें
• संदिग्ध API कॉल्स के लिए सॉकेट प्रॉक्सी लॉग्स मॉनिटर करें
• प्रॉक्सी ऐक्सेस क्रेडेंशियल्स को नियमित रूप से रोटेट करें

क्रेडेंशियल प्रबंधन

प्लेन टेक्स्ट URL में प्रॉक्सी क्रेडेंशियल्स हर जगह दिखते हैं—लॉग्स, प्रोसेस लिस्ट, एनवायरनमेंट डंप्स।

कभी भी क्रेडेंशियल्स को प्रॉक्सी URL में एम्बेड न करें:

# SECURITY RISK - credentials visible in process list
export HTTP_PROXY=http://admin:[email protected]:8080संचालित द्वारा

ps aux या एनवायरनमेंट वेरिएबल डंप्स तक ऐक्सेस रखने वाला कोई भी व्यक्ति आपका प्रॉक्सी पासवर्ड देख सकता है। इसमें ऐप्लिकेशन लॉग्स, कंटेनर इन्स्पेक्शन और सिस्टम मॉनिटरिंग टूल्स शामिल हैं।

इसके बजाय, ऑथेंटिकेशन फ़ाइलों का उपयोग करें:

# Create credentials file with restricted permissions
echo "admin:password123" > ~/.proxy-creds
chmod 600 ~/.proxy-creds

# Configure proxy without embedded credentials
export HTTP_PROXY=http://proxy.company.com:8080संचालित द्वारा

अपने प्रॉक्सी सर्वर को फ़ाइल से क्रेडेंशियल्स पढ़ने के लिए कॉन्फ़िगर करें या बाहरी ऑथेंटिकेशन सिस्टम का उपयोग करें।

TLS प्रॉक्सी सभी प्रॉक्सी ट्रैफ़िक को एन्क्रिप्ट करते हैं, जिनमें ऑथेंटिकेशन हैंडशेक भी शामिल हैं:

# HTTPS proxy encrypts credentials in transit
export HTTPS_PROXY=https://proxy.company.com:8443संचालित द्वारा

अपने प्रॉक्सी सर्वर को उचित TLS सर्टिफ़िकेट्स—चाहे CA से हों या क्लाइंट मशीनों पर वितरित स्व-हस्ताक्षरित सर्टिफ़िकेट्स—के साथ सेट करें।

सर्टिफ़िकेट-आधारित ऑथेंटिकेशन पासवर्ड को पूरी तरह समाप्त कर देता है:

# Client certificate authentication
export HTTPS_PROXY=https://proxy.company.com:8443
curl --cert client.crt --key client.key --cacert proxy-ca.crt https://example.comसंचालित द्वारा

प्रॉक्सी यूज़रनेम/पासवर्ड की बजाय क्लाइंट सर्टिफ़िकेट्स को वैलिडेट करता है। समझौता होने पर सर्टिफ़िकेट्स को व्यक्तिगत रूप से रद्द किया जा सकता है।

Kubernetes सीक्रेट मैनेजमेंट प्रॉक्सी क्रेडेंशियल्स को कंटेनर इमेज़ से बाहर रखता है:

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded
  password: cGFzc3dvcmQxMjM=  # base64 encodedसंचालित द्वारा

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: myapp
        env:
        - name: PROXY_USER
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: username
        - name: PROXY_PASS
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: passwordसंचालित द्वारा

सीक्रेट्स at rest एन्क्रिप्टेड रहते हैं और रनटाइम पर इंजेक्ट होते हैं, बिना इमेज़ लेयर्स में दिखाई दिए।

सॉकेट ऐक्सेस लॉकडाउन करें और अपने क्रेडेंशियल्स एन्क्रिप्ट करें—भविष्य में आप स्वयं को धन्यवाद देंगे।

क्या आप अपने प्रॉक्सी सेटअप के लिए Docker के विकल्पों पर विचार कर रहे हैं? सही कंटेनराइज़ेशन टूल चुनने के लिए Docker बनाम Podman की तुलना देखें।

आम समस्याओं का ट्रबलशूटिंग

प्रॉक्सी समस्याएँ टाइमआउट, कनेक्शन फ़ेल्योर और रहस्यमयी बिल्ड एरर के रूप में आती हैं जो आपके नेटवर्क के बाहर ठीक से काम करती हैं। यहाँ सबसे आम Docker प्रॉक्सी समस्याओं का निदान और समाधान करने का एक व्यवस्थित तरीका है।

स्ट्रक्चर्ड डायग्नोस्टिक अप्रोच

बुनियादी चीज़ों से शुरू करें और स्टैक में ऊपर की ओर बढ़ें।

कदम 1: होस्ट से प्रॉक्सी कनेक्टिविटी सत्यापित करें

टेस्ट करें कि आपका प्रॉक्सी सर्वर पहुँच योग्य है या नहीं:

curl -x http://proxy.company.com:8080 https://registry-1.docker.io/v2/संचालित द्वारा

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

कदम 2: Docker डेमन प्रॉक्सी सेटिंग्स जाँचें

सत्यापित करें कि डेमन आपकी प्रॉक्सी कॉन्फ़िगरेशन पढ़ रहा है:

docker info | grep -i proxyसंचालित द्वारा

आपको अपने प्रॉक्सी URL सूचीबद्ध दिखने चाहिए। अगर वे गायब हैं, तो /etc/docker/daemon.json जाँचें और Docker सर्विस रीस्टार्ट करें।

कदम 3: Docker क्लाइंट ऑपरेशन टेस्ट करें

एक साधारण इमेज़ पुल करने की कोशिश करें:

docker pull hello-worldसंचालित द्वारा

सफलता का मतलब है कि आपकी क्लाइंट प्रॉक्सी सेटिंग्स काम कर रही हैं। विफलता डेमन-लेवल प्रॉक्सी समस्याओं की ओर इशारा करती है।

कदम 4: कंटेनर-लेवल कनेक्टिविटी टेस्ट करें

एक कंटेनर चलाएँ और आउटबाउंड कनेक्शन टेस्ट करें:

docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  python -c "import urllib.request; print(urllib.request.urlopen('https://pypi.org').getcode())"संचालित द्वारा

यह अलग करता है कि समस्या Docker ऑपरेशन में है या कंटेनर नेटवर्किंग में।

आम समस्याएँ और समाधान

समस्या: docker pull टाइमआउट होता है

यह एरर तब दिखता है जब Docker बाहरी रजिस्ट्री तक नहीं पहुँच पाता:

Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io: no such hostसंचालित द्वारा

समस्या कहाँ हो रही है, यह अलग करने के लिए बेसिक कनेक्टिविटी टेस्ट से शुरू करें:

# Check if DNS resolution works through proxy
nslookup registry-1.docker.io

# Test direct registry access
curl -I https://registry-1.docker.io/v2/

# Verify daemon proxy configuration
sudo journalctl -u docker.service | grep -i proxyसंचालित द्वारा

DNS और प्रॉक्सी कॉन्फ़िगरेशन समस्याओं को संबोधित करके इसे ठीक करें:

• /etc/docker/daemon.json में DNS सर्वर्स जोड़ें

• आंतरिक DNS सर्वर्स के लिए NO_PROXY कॉन्फ़िगर करें

• जाँचें कि प्रॉक्सी HTTPS CONNECT मेथड सपोर्ट करता है या नहीं

समस्या: बिल्ड्स के दौरान पैकेज इंस्टॉलेशन फेल होता है

कंटेनरों के अंदर पैकेज मैनेजर रिपॉज़िटरी तक नहीं पहुँच पाते, इस तरह के एरर दिखते हैं:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/Releaseसंचालित द्वारा

अस्थायी कंटेनर में सीधे पैकेज मैनेजर कनेक्टिविटी टेस्ट करें:

# Test package manager connectivity in a running container
docker run -it --rm python:3.13 bash
apt-get update -o Debug::Acquire::http=trueसंचालित द्वारा

वर्बोज़ आउटपुट ठीक-ठीक दिखाता है कि कनेक्शन कहाँ फेल हो रहा है।

इसे ठीक करने के लिए पैकेज मैनेजर को आपके प्रॉक्सी का उपयोग करने के लिए कॉन्फ़िगर करें:

• Dockerfile में पैकेज मैनेजर प्रॉक्सी सेटिंग्स कॉन्फ़िगर करें
• Docker बिल्ड को प्रॉक्सी बिल्ड आर्ग्युमेंट्स पास करें
• जाँचें कि प्रॉक्सी पैकेज रिपॉज़िटरी डोमेन्स को ब्लॉक तो नहीं कर रहा

समस्या: BuildKit प्रॉक्सी सेटिंग्स को नज़रअंदाज़ करता है

BuildKit लेगेसी बिल्डर से अलग प्रॉक्सी हैंडलिंग उपयोग करता है, जिससे ऐसे एरर आते हैं:

failed to solve: failed to fetch remote https://github.com/user/repo.gitसंचालित द्वारा

अपने बिल्डर कॉन्फ़िगरेशन जाँचकर देखें कि समस्या BuildKit-विशिष्ट है या नहीं:

# Check BuildKit configuration
docker buildx inspect

# Build with legacy builder
DOCKER_BUILDKIT=0 docker build .संचालित द्वारा

यदि लेगेसी बिल्डर काम करता है, तो आपके पास BuildKit प्रॉक्सी कॉन्फ़िगरेशन समस्या है।

इन तरीकों से BuildKit प्रॉक्सी समस्याएँ ठीक करें:

• buildkitd.toml में BuildKit-विशिष्ट प्रॉक्सी सेटिंग्स कॉन्फ़िगर करें
• प्रॉक्सी वेरिएबल्स स्पष्ट रूप से पास करने के लिए --build-arg का उपयोग करें
• प्रॉक्सी-संवेदनशील बिल्ड्स के लिए BuildKit डिसेबल करें

समस्या: कंटेनर बाहरी सेवाओं तक नहीं पहुँच पा रहा

कंटेनर के अंदर आपका ऐप्लिकेशन बाहरी API से कनेक्ट होने में विफल रहता है:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='api.example.com', port=443)संचालित द्वारा

कंटेनर के अंदर से कनेक्टिविटी टेस्ट करके इसे डिबग करें:

# Test from inside the container
docker exec container_name curl -v https://api.example.com

# Check container environment variables
docker exec container_name env | grep -i proxyसंचालित द्वारा

यह दिखाता है कि प्रॉक्सी वेरिएबल्स मौजूद हैं या नहीं और कनेक्शन प्रयास सफल होता है या नहीं।

कंटेनर कनेक्टिविटी समस्याओं को सही प्रॉक्सी कॉन्फ़िगरेशन सुनिश्चित करके हल करें:

• रनटाइम पर प्रॉक्सी एनवायरनमेंट वेरिएबल्स पास करें
• ऐप्लिकेशन-विशिष्ट प्रॉक्सी सेटिंग्स कॉन्फ़िगर करें
• गंतव्य को NO_PROXY सूची में जोड़ें

लॉग विश्लेषण और कनेक्टिविटी टेस्टिंग

Docker डेमन लॉग्स प्रॉक्सी नेगोशिएशन और विफलताओं की पूरी कहानी बताते हैं।

systemd-आधारित सिस्टम पर, रीयल-टाइम में Docker सर्विस लॉग्स फॉलो करने के लिए journalctl का उपयोग करें:

# SystemD systems
sudo journalctl -u docker.service -fसंचालित द्वारा

पारंपरिक लॉग फ़ाइलों का उपयोग करने वाले सिस्टम के लिए, सीधे Docker लॉग देखें:

# Direct log file
sudo tail -f /var/log/docker.logसंचालित द्वारा

लॉग्स में विशिष्ट प्रॉक्सी-संबंधित पैटर्न देखें। Connection refused एरर दिखाते हैं कि प्रॉक्सी सर्वर पहुँच योग्य नहीं है। Authentication failures "407 Proxy Authentication Required" संदेश के रूप में दिखाई देते हैं। Timeout एरर नेटवर्क रूटिंग समस्याएँ या प्रॉक्सी सर्वर ओवरलोड का संकेत देते हैं।

कंटेनर-स्तरीय टेस्टिंग curl और wget के साथ आपको प्रॉक्सी व्यवहार की विस्तृत जानकारी देती है।

हैंडशेक के दौरान वास्तव में क्या होता है, यह देखने के लिए अपने प्रॉक्सी के माध्यम से HTTP कनेक्शन टेस्ट करें:

# Test HTTP proxy
docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v http://httpbin.org/ipसंचालित द्वारा

वर्बोज़ आउटपुट DNS रेज़ोल्यूशन, प्रॉक्सी कनेक्शन स्थापना और वास्तविक HTTP अनुरोध प्रवाह दिखाता है। आपको "Connected to proxy.company.com" जैसी पंक्तियाँ दिखेंगी, इसके बाद "CONNECT httpbin.org:80" यदि प्रॉक्सी टनल सही काम कर रही है।

HTTPS कनेक्शनों के लिए प्रॉक्सी को CONNECT मेथड सपोर्ट करना चाहिए:

# Test HTTPS proxy
docker run --rm \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v https://httpbin.org/ipसंचालित द्वारा

आउटपुट में "CONNECT httpbin.org:443 HTTP/1.1" देखें। यदि "Method not allowed" या इसी तरह के एरर दिखें, तो आपका प्रॉक्सी HTTPS टनलिंग सपोर्ट नहीं करता।

प्रॉक्सी URL में क्रेडेंशियल्स एम्बेड करके ऑथेंटिकेशन टेस्ट करें:

# Test with authentication
docker run --rm \
  -e HTTPS_PROXY=http://user:[email protected]:8080 \
  python:3.13-slim \
  wget -O- https://httpbin.org/ipसंचालित द्वारा

ऑथेंटिकेशन विफलताएँ "407 Proxy Authentication Required" प्रतिक्रियाओं के रूप में दिखती हैं। सफल ऑथेंटिकेशन सीधे लक्षित अनुरोध तक आगे बढ़ता है।

नेटवर्क-स्तरीय डिबगिंग tcpdump के साथ Docker और आपके प्रॉक्सी सर्वर के बीच वास्तविक पैकेट कैप्चर करती है।

अपने प्रॉक्सी की ओर बहने वाला सारा ट्रैफ़िक देखने के लिए tcpdump चलाएँ:

# Capture proxy traffic
sudo tcpdump -i any host proxy.company.com and port 8080संचालित द्वारा

यह रॉ पैकेट कैप्चर कनेक्शन प्रयास, डेटा ट्रांसफ़र और कनेक्शन समाप्ति दिखाता है। TCP कनेक्शन स्थापना (SYN/ACK पैकेट्स) के बाद HTTP ट्रैफ़िक देखें। कनेक्शन टाइमआउट बार-बार आने वाले SYN पैकेट्स के रूप में दिखते हैं जिनका कोई रिस्पॉन्स नहीं होता।

DNS रेज़ोल्यूशन टेस्टिंग प्रॉक्सी भ्रम का एक आम स्रोत समाप्त करती है।

कई प्रॉक्सी समस्याएँ वास्तव में छिपी हुई DNS समस्याएँ होती हैं। कंटेनरों के अंदर DNS रेज़ोल्यूशन टेस्ट करें:

# Test DNS inside containers  
docker run --rm python:3.13-slim nslookup registry-1.docker.ioसंचालित द्वारा

यदि यह फेल हो जाए, तो कंटेनर बिल्कुल भी डोमेन नाम रेज़ॉल्व नहीं कर सकता। समस्या अलग करने के लिए पब्लिक DNS सर्वर का उपयोग करने की कोशिश करें:

# Test with custom DNS
docker run --dns 8.8.8.8 --rm python:3.13-slim nslookup registry-1.docker.ioसंचालित द्वारा

कॉर्पोरेट वातावरण में अक्सर ऐसे DNS सर्वर होते हैं जो केवल नेटवर्क के अंदर से काम करते हैं। आपके प्रॉक्सी को HTTP ट्रैफ़िक के साथ-साथ DNS अनुरोधों को भी संभालने की ज़रूरत हो सकती है, या आपको कंटेनरों में ऐसे विशिष्ट DNS सर्वर कॉन्फ़िगर करने पड़ सकते हैं जो आपके प्रॉक्सी के माध्यम से काम करते हों।

हर लेयर को व्यवस्थित रूप से जाँचें, और आप मूल कारण तक पहुँच जाएँगे।

ऐसे विकल्प ढूँढ रहे हैं जो प्रॉक्सी को अलग तरीके से हैंडल करते हों? हमारे पास Docker विकल्प पर एक गाइड है ताकि आप 2025 के कंटेनराइज़ेशन टूल्स के पूरे परिदृश्य का पता लगा सकें।

निष्कर्ष

Docker प्रॉक्सी कॉन्फ़िगरेशन केवल इमेज़ डाउनलोड करवाने के बारे में नहीं है—यह एंटरप्राइज़ वातावरण में विश्वसनीय, सुरक्षित कंटेनराइज़्ड ऐप्लिकेशन बनाने के बारे में भी है।

मैंने आपको चार अलग-अलग लेयर पर प्रॉक्सी सेटिंग्स कॉन्फ़िगर करना दिखाया: क्लाइंट ऑपरेशन, डेमन प्रक्रियाएँ, कंटेनर रनटाइम और बिल्ड-टाइम ऑपरेशन। हर लेयर का एक विशिष्ट उद्देश्य है और अपनी कॉन्फ़िगरेशन पद्धति चाहिए, JSON फ़ाइलों और एनवायरनमेंट वेरिएबल्स से लेकर पैकेज मैनेजर सेटिंग्स और BuildKit कॉन्फ़िगरेशन तक। लेयर्ड प्रॉक्सी रणनीति आपको सिंगल पॉइंट ऑफ़ फेल्योर से बचाती है।

Docker, कंटेनराइज़ेशन और सुरक्षा में गहराई से देखना चाहते हैं? हमारे क्यूरेटेड कोर्सेज़ की सूची देखें:

• Introduction to Docker
• Intermediate Docker
• Containerization and Virtualization Concepts
• Containerization and Virtualization with Docker and Kubernetes
• DevOps Concepts
• Introduction to Kubernetes