Zadanie korzysta ze środowiska swojego workera Sidekiq, a nie z nowego terminala czy procesu webowego Rails. Dla workera na pierwszym planie, którego klient HTTP czyta te zmienne:

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

Dla opisanego przez Sidekiq układu Linuksa zarządzanego przez systemd umieść wartości w pliku drop-in rzeczywistej jednostki workera:

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

Przeładuj definicje jednostki i zastąp workera zwykłą procedurą restartu wdrożenia. Przeładowanie kodu Rails w istniejącym workerze nie zastępuje jego odziedziczonego środowiska.

Sprawdzenie usługi publicznej może użyć punktu końcowego z listy proxy HTTP w tych wartościach, gdy publiczni pośrednicy są dozwoleni, a klient workera nie ma skonfigurowanych ani zachowanych danych uwierzytelniających proxy. Przy kilku jednostkach specyficznych dla kolejek ustal, która wykonała nieudane zadanie. Sukces innego workera nie potwierdza konfiguracji tego.

Zapisz tę jednostkę i klienta HTTP razem. Klient skonfigurowany jawnie może używać innej trasy niezależnie od zmiennych przekazanych workerowi; w takim przypadku skonfiguruj jego obsługiwany interfejs.

Powiązane artykuły