Jobben brukar miljøet til sin eigen Sidekiq-arbeidar, ikkje ein ny terminal eller ein Rails-nettprosess. For ein arbeidar i framgrunnen der HTTP-klienten les desse variablane:

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

For det Sidekiq-dokumenterte systemd-styrte Linux-oppsettet legg du verdiane i drop-in-fila til den faktiske arbeidar-eininga:

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

Last einingdefinisjonane på nytt og byt ut arbeidaren via den vanlege omstartprosedyren til utrullinga. Å laste Rails-kode på nytt i ein eksisterande arbeidar erstattar ikkje det arva miljøet.

Ein sjekk mot ei offentleg teneste kan bruke eit endepunkt frå HTTP-proxylista i desse verdiane når offentlege mellomledd er tillatne og klienten til arbeidaren ikkje har konfigurerte eller lagra proxy-innloggingsdetaljar. Med fleire køspesifikke einingar må du identifisere kva for ei som køyrde den mislukka jobben. Ein suksess frå ein annan arbeidar fastslår ikkje konfigurasjonen til denne.

Registrer den eininga og HTTP-klienten saman. Ein eksplisitt konfigurert klient kan bruke ei anna rute uavhengig av variablane som blir leverte til arbeidaren; konfigurer i så fall grensesnittet han støttar.

Relaterte artiklar