Die proxy-omgewing soos 'n Sidekiq-werker dit sien

Die werk gebruik die omgewing van sy Sidekiq-werker, nie 'n nuwe terminaal of 'n Rails-webproses nie. Vir 'n voorgrondwerker wie se HTTP-kliënt hierdie veranderlikes lees:

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

Vir Sidekiq se gedokumenteerde systemd-bestuurde Linux-reëling, plaas die waardes in die drop-in van die werklike werker-eenheid:

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

Herlaai eenheiddefinisies en vervang die werker deur die ontplooiing se normale herbeginprosedure. Die herlaai van Rails-kode in 'n bestaande werker vervang nie sy geërfde omgewing nie.

'n Kontrole van 'n publieke diens kan 'n eindpunt uit die HTTP-proxylys in hierdie waardes gebruik wanneer openbare tussenbemiddelaars toegelaat word en die werker se kliënt geen opgestelde of bewaarde proxy-aanmeldings het nie. Met verskeie tou-spesifieke eenhede, identifiseer watter een die mislukte werk uitgevoer het. 'n Sukses van 'n ander werker bewys nie hierdie een se konfigurasie nie.

Teken daardie eenheid en HTTP-kliënt saam aan. 'n Kliënt wat eksplisiet opgestel is, kan 'n ander roete gebruik ongeag die veranderlikes wat aan die werker gelewer is; konfigureer in daardie geval sy ondersteunde koppelvlak.