סביבת ה-proxy כפי שעובד Sidekiq רואה אותה
ספקו משתני proxy כשתהליך Sidekiq מתחיל, כולל תצורת שירות systemd לעובדים מנוהלים.
המשימה משתמשת בסביבה של עובד ה-Sidekiq שלה, ולא במסוף חדש או בתהליך אינטרנט של Rails. עבור עובד בקדמה שקליינט ה-HTTP שלו קורא את המשתנים האלה:
http_proxy=http://proxy.example.net:8080 \
https_proxy=http://proxy.example.net:8080 \
bundle exec sidekiqעבור הסידור של לינוקס המנוהל ב-systemd כפי שתיעד Sidekiq, שימו את הערכים בקובץ ה-drop-in של יחידת העובד בפועל:
[Service]
Environment="http_proxy=http://proxy.example.net:8080"
Environment="https_proxy=http://proxy.example.net:8080"טענו מחדש את הגדרות היחידה והחליפו את העובד דרך הליך ההפעלה מחדש הרגיל של הפריסה. טעינה מחדש של קוד Rails בעובד קיים אינה מחליפה את הסביבה שירש.
בדיקת שירות ציבורי יכולה להשתמש בנקודת קצה מתוך רשימת ה-proxy של HTTP בערכים האלה כאשר מתווכים ציבוריים מותרים ולקליינט של העובד אין פרטי proxy מוגדרים או שמורים. עם כמה יחידות ייעודיות לתורים, זהו איזו מהן הרצה את המשימה שנכשלה. הצלחה של עובד אחר אינה מבססת את התצורה של זה.
תעדו את היחידה ואת קליינט ה-HTTP יחד. קליינט שמוגדר במפורש יכול להשתמש במסלול אחר ללא תלות במשתנים שנמסרו לעובד; במקרה כזה הגדירו את הממשק הנתמך שלו.