कार्य अपने 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 क्लाइंट को साथ में दर्ज करें। स्पष्ट रूप से कॉन्फ़िगर किया गया क्लाइंट वर्कर को दिए गए चरों की परवाह किए बिना दूसरा मार्ग उपयोग कर सकता है; उस स्थिति में उसका समर्थित इंटरफ़ेस कॉन्फ़िगर करें।

संबंधित लेख