De proxy-omgeving zoals een Sidekiq-worker die ziet

De taak gebruikt de omgeving van zijn eigen Sidekiq-worker, niet een nieuwe terminal of een Rails-webproces. Voor een worker op de voorgrond waarvan de HTTP-client deze variabelen leest:

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

Voor de door Sidekiq gedocumenteerde, door systemd beheerde Linux-opstelling zet u de waarden in de drop-in van de daadwerkelijke worker-unit:

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

Herlaad de unitdefinities en vervang de worker via de gebruikelijke herstartprocedure van de deployment. Rails-code herladen in een bestaande worker vervangt de geërfde omgeving niet.

Een controle van een publieke dienst kan in deze waarden een eindpunt uit de HTTP-proxylijst gebruiken wanneer publieke tussenpartijen zijn toegestaan en de client van de worker geen geconfigureerde of bewaarde proxyreferenties heeft. Met meerdere wachtrijspecifieke units stelt u vast welke het mislukte werk heeft uitgevoerd. Een succes van een andere worker bewijst de configuratie van deze niet.

Leg die unit en de HTTP-client samen vast. Een expliciet geconfigureerde client kan een andere route gebruiken ongeacht de variabelen die aan de worker zijn geleverd; configureer in dat geval de interface die deze ondersteunt.