Jobbet använder miljön hos sin egen Sidekiq-worker, inte en ny terminal eller en Rails-webbprocess. För en worker i förgrunden vars HTTP-klient läser dessa variabler:

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

För Sidekiqs dokumenterade systemd-hanterade Linux-uppsättning placerar du värdena i drop-in-filen för den faktiska worker-enheten:

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

Läs in enhetsdefinitionerna igen och ersätt workern via distributionens vanliga omstartsprocedur. Att läsa in Rails-kod igen i en befintlig worker ersätter inte dess ärvda miljö.

En kontroll av en offentlig tjänst kan använda en slutpunkt från HTTP-proxylistan i dessa värden när offentliga mellanhänder är tillåtna och workerns klient inte har konfigurerade eller sparade proxyuppgifter. Med flera köspecifika enheter identifierar du vilken som körde det misslyckade jobbet. En framgång från en annan worker fastställer inte den här workerns konfiguration.

Registrera den enheten och HTTP-klienten tillsammans. En uttryckligen konfigurerad klient kan använda en annan väg oavsett variablerna som levereras till workern; konfigurera i så fall det gränssnitt den stöder.

Relaterade artiklar