D'Proxy-Ëmwelt aus der Siicht vun engem Sidekiq-Worker

D'Aufgab benotzt d'Ëmwelt vu sengem Sidekiq-Worker, net en neien Terminal oder e Rails-Webprozess. Fir en Worker am Virdergrond, deem säin HTTP-Client dës Variabelen liest:

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

Fir déi vum Sidekiq dokumentéiert systemd-verwalt Linux-Arrangement setzt d'Wäerter an den Drop-in vun der tatsächlecher Worker-Unit:

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

Lued d'Unit-Definitiounen nei a ersetzt de Worker iwwer de normale Neistartprozedur vum Deployment. D'Rails-Code an engem existéierende Worker nei ze lueden ersetzt seng geierft Ëmwelt net.

Eng Prüfung vun engem ëffentleche Service kann en Endpunkt aus der HTTP-Proxy-Lëscht an dëse Wäerter benotzen, wann ëffentlech Vermëttler erlaabt sinn an de Client vum Worker keng konfiguréiert oder gespäichert Proxy-Umelleeungsdaten huet. Bei méi Queue-spezifeschen Uniten identifizéiert Der, wéi eng de feelgeschloenen Job ausgefouert huet. En Erfolleg vun engem anere Worker beleet net d'Konfiguratioun vun dësem.

Hält déi Unit an den HTTP-Client zesummen fest. En explizit konfiguréierte Client kann eng aner Route benotzen, onofhängeg vun de Variabelen, déi dem Worker ginn; konfiguréiert an deem Fall seng ënnerstëtzt Schnëttstell.