Завдання використовує середовище свого воркера Sidekiq, а не новий термінал чи вебпроцес Rails. Для воркера на передньому плані, чий HTTP-клієнт читає ці змінні:

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

Для описаного в документації Sidekiq розміщення Linux під керуванням systemd помістіть значення в drop-in фактичного юніта воркера:

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

Перезавантажте визначення юніта й замініть воркер звичайною процедурою перезапуску розгортання. Перезавантаження коду Rails у наявному воркері не замінює його успадковане середовище.

Перевірка публічної служби може використати кінцеву точку зі списку HTTP-проксі в цих значеннях, якщо публічні посередники дозволені й клієнт воркера не має налаштованих чи збережених облікових даних проксі. За кількох юнітів для окремих черг визначте, який виконав невдале завдання. Успіх іншого воркера не доводить конфігурацію цього.

Зафіксуйте цей юніт і HTTP-клієнт разом. Явно налаштований клієнт може використовувати інший маршрут незалежно від змінних, переданих воркеру; у такому разі налаштуйте підтримуваний ним інтерфейс.

Схожі статті