होस्ट र वेब कन्टेनरका लागि 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 का स्थानीय अनुप्रयोग र सेवा मार्गहरू अभिप्रेत प्रत्यक्ष दायरामा राख्नुहोस्। आन्तरिक डोमेन वा ठेगाना दायरा थप्दा बाइपास सिन्ट्याक्सलाई वास्तविक उपभोक्तासँग मिलाउनुहोस्।

सम्बन्धित लेखहरू