होस्ट और वेब कंटेनर के लिए DDEV प्रॉक्सी सेटिंग्स

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

माउंट किया गया Wget कॉन्फ़िगरेशन Wget को ठीक कर सकता है जबकि Drush या Composer अपरिवर्तित रहते हैं। उस प्रोग्राम से शुरू करें जो असफल अनुरोध कर रहा है, फिर उसी प्रोग्राम की लॉन्च सीमा पर प्रॉक्सी प्रदान करें।

होस्ट प्रोग्राम

सामान्य वेरिएबल का समर्थन करने वाले होस्ट प्रोग्रामों के लिए, प्रदान करें:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080
export no_proxy=localhost,127.0.0.1,::1,.ddev.site

HTTPS वेरिएबल HTTPS गंतव्यों का चयन करता है; इसका HTTP URL प्रॉक्सी श्रोता का वर्णन करता है। HTTP प्रॉक्सी सूची से कोई एंडपॉइंट तब उम्मीदवार होता है जब संबंधित होस्ट या वेब-कंटेनर डाउनलोड किसी सार्वजनिक मार्ग का उपयोग कर सके।

कंटेनर बिल्ड और रनटाइम

DDEV proxies अनुभाग का मौजूदा ~/.docker/config.json में दस्तावेज़ीकरण करता है:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.example:8080",
      "httpsProxy": "http://proxy.example:8080",
      "noProxy": "localhost,127.0.0.1,::1,.ddev.site"
    }
  }
}

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

बेस-इमेज पुल

अनुपस्थित बेस-इमेज Docker डेमन द्वारा डाउनलोड की जाती है। ऊपर का क्लाइंट कॉन्फ़िगरेशन उस डेमन की प्रॉक्सी सेट नहीं करता, और गर्म इमेज कैश पुल को पूरी तरह टाल सकता है।

DDEV के स्थानीय एप्लिकेशन और सेवा मार्गों को इच्छित प्रत्यक्ष दायरे में रखें। आंतरिक डोमेन या पता श्रेणियाँ जोड़ते समय बायपास सिंटैक्स को वास्तविक उपभोक्ता के अनुरूप बनाएँ।

संबंधित लेख