Jobben bruker miljøet til sin egen Sidekiq-worker, ikke en ny terminal eller en Rails-nettprosess. For en worker i forgrunnen der HTTP-klienten leser disse variablene:

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

For Sidekiqs dokumenterte systemd-administrerte Linux-oppsett plasserer du verdiene i drop-in-filen til den faktiske worker-enheten:

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

Last enhetsdefinisjonene på nytt og bytt ut workeren via distribusjonens vanlige omstartprosedyre. Å laste Rails-kode på nytt i en eksisterende worker erstatter ikke det arvede miljøet.

En sjekk mot en offentlig tjeneste kan bruke et endepunkt fra HTTP-proxylisten i disse verdiene når offentlige mellomledd er tillatt og workerens klient ikke har konfigurerte eller lagrede proxy-påloggingsdetaljer. Med flere køspesifikke enheter må du identifisere hvilken som kjørte den mislykkede jobben. En suksess fra en annen worker fastslår ikke denne workerens konfigurasjon.

Registrer den enheten og HTTP-klienten sammen. En eksplisitt konfigurert klient kan bruke en annen rute uavhengig av variablene som leveres til workeren; konfigurer i så fall grensesnittet den støtter.

Relaterte artikler