პროქსის გარემო, როგორც მას 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 კლიენტი ერთად. ცხადად კონფიგურირებულ კლიენტს შეუძლია სხვა მარშრუტი გამოიყენოს მუშაკისთვის გადაცემული ცვლადების მიუხედავად; ამ შემთხვევაში დააკონფიგურირეთ მისი მხარდაჭერილი ინტერფეისი.