דער פּראָקסי־סביבה ווי אַ Sidekiq־אַרבעטער זעט אים
שאַפט פּראָקסי־וואַריאַבלען ווען דער Sidekiq־פּראָצעס הייבט אָן, אַרײַנגערעכנט אַ systemd־דינסט־קאָנפיגוראַציע פֿאַר פֿאַרוואַלטעטע אַרבעטער.
די אויפֿגאַבע ניצט די סביבה פֿון איר אייגענעם 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־קליענט צוזאַמען. אַ קליענט וואָס איז בפֿירוש קאָנפיגורירט קען ניצן אַן אַנדער וועג אָן זיך רעכענען מיט די וואַריאַבלען וואָס מע גיט דעם אַרבעטער; אין אַזאַ פֿאַל קאָנפיגורירט די צובינד וואָס ער שטיצט.