Sidekiq कार्यकर्ताले देख्ने प्रोक्सी वातावरण

कामले आफ्नो Sidekiq कार्यकर्ताको वातावरण प्रयोग गर्छ, नयाँ टर्मिनल वा Rails वेब प्रक्रिया होइन। जसको HTTP क्लाइन्टले यी चरहरू पढ्छ, त्यस्तो अग्रभूमि कार्यकर्ताका लागि:

http_proxy=http://proxy.example.net:8080 \
https_proxy=http://proxy.example.net:8080 \
bundle exec sidekiq

Sidekiq ले अभिलेख गरेको systemd-व्यवस्थित Linux व्यवस्थाका लागि, मानहरू वास्तविक कार्यकर्ता युनिटको drop-in मा राख्नुहोस्:

[Service]
Environment="http_proxy=http://proxy.example.net:8080"
Environment="https_proxy=http://proxy.example.net:8080"

युनिट परिभाषाहरू पुनः लोड गर्नुहोस् र तैनाथीको सामान्य पुनःसुरु प्रक्रियाबाट कार्यकर्ता प्रतिस्थापन गर्नुहोस्। अवस्थित कार्यकर्तामा Rails कोड पुनः लोड गर्दा त्यसको वंशानुगत वातावरण प्रतिस्थापन हुँदैन।

सार्वजनिक-सेवा जाँचले यी मानहरूमा HTTP प्रोक्सी सूचीबाट कुनै अन्त्यबिन्दु प्रयोग गर्न सक्छ, जब सार्वजनिक मध्यस्थहरूलाई अनुमति छ र कार्यकर्ताको क्लाइन्टसँग कुनै कन्फिगर गरिएको वा संरक्षित प्रोक्सी प्रमाणहरू छैनन्। धेरै पङ्क्ति-विशिष्ट युनिटहरू भएमा, असफल काम कुनले सम्पादन गर्यो पहिचान गर्नुहोस्। अर्को कार्यकर्ताको सफलताले यसको कन्फिगरेसन प्रमाणित गर्दैन।

त्यो युनिट र HTTP क्लाइन्ट सँगै अभिलेख गर्नुहोस्। स्पष्ट रूपमा कन्फिगर गरिएको क्लाइन्टले कार्यकर्तालाई दिइएका चरहरूको वास्ता नगरी अर्को मार्ग प्रयोग गर्न सक्छ; त्यस अवस्थामा यसले समर्थन गर्ने इन्टरफेस कन्फिगर गर्नुहोस्।