Die Proxy-Umgebung aus Sicht eines Sidekiq-Workers

Der Job nutzt die Umgebung seines Sidekiq-Workers, nicht ein neues Terminal oder einen Rails-Webprozess. Für einen Worker im Vordergrund, dessen HTTP-Client diese Variablen liest:

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

Für die von Sidekiq dokumentierte systemd-verwaltete Linux-Einrichtung gehören die Werte in das Drop-in der tatsächlichen Worker-Unit:

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

Laden Sie die Unit-Definitionen neu und ersetzen Sie den Worker über das übliche Neustartverfahren des Deployments. Das Neuladen von Rails-Code in einem bestehenden Worker ersetzt dessen geerbte Umgebung nicht.

Eine Prüfung über einen öffentlichen Dienst kann in diesen Werten einen Endpunkt aus der HTTP-Proxy-Liste verwenden, wenn öffentliche Vermittler zulässig sind und der Client des Workers keine konfigurierten oder gespeicherten Proxy-Anmeldedaten hat. Bei mehreren wartungsspezifischen Units ermitteln Sie, welche den fehlgeschlagenen Job ausgeführt hat. Ein Erfolg eines anderen Workers belegt die Konfiguration dieses Workers nicht.

Halten Sie diese Unit und den HTTP-Client gemeinsam fest. Ein ausdrücklich konfigurierter Client kann unabhängig von den an den Worker übergebenen Variablen eine andere Route nutzen; konfigurieren Sie in diesem Fall seine unterstützte Schnittstelle.