Sidekiq 워커가 보는 프록시 환경

작업은 새 터미널이나 Rails 웹 프로세스가 아니라 자신의 Sidekiq 워커 환경을 사용합니다. HTTP 클라이언트가 이 변수들을 읽는 포그라운드 워커라면:

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

Sidekiq가 문서화한 systemd 관리 Linux 구성에서는 값을 실제 워커 유닛의 drop-in에 넣습니다:

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

유닛 정의를 다시 로드하고 배포의 일반적인 재시작 절차로 워커를 교체합니다. 기존 워커에서 Rails 코드를 다시 로드해도 상속된 환경은 교체되지 않습니다.

공용 서비스 점검은 공용 중계자가 허용되고 워커의 클라이언트에 구성되었거나 보관된 프록시 자격 증명이 없을 때 이 값에 HTTP 프록시 목록의 엔드포인트를 사용할 수 있습니다. 큐별 유닛이 여러 개라면 실패한 작업을 실행한 유닛이 어느 것인지 확인합니다. 다른 워커의 성공은 이 워커의 구성을 증명하지 않습니다.

그 유닛과 HTTP 클라이언트를 함께 기록합니다. 명시적으로 구성된 클라이언트는 워커에 전달된 변수와 무관하게 다른 경로를 쓸 수 있습니다. 그런 경우 지원하는 인터페이스를 구성합니다.