محیط پراکسی از دید یک کارگر Sidekiq

کار از محیط کارگر Sidekiq خود استفاده می‌کند، نه از یک ترمینال جدید یا فرآیند وب Rails. برای یک کارگر پیش‌زمینه که کلاینت HTTP آن این متغیرها را می‌خواند:

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

برای چیدمان لینوکسی مدیریت‌شده با systemd که Sidekiq مستند کرده است، مقادیر را در فایل drop-in واحد واقعی کارگر قرار دهید:

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

تعاریف واحد را دوباره بارگذاری کنید و کارگر را از طریق رویه راه‌اندازی مجدد معمول استقرار جایگزین کنید. بارگذاری مجدد کد Rails در یک کارگر موجود محیط به‌ارث‌رسیده آن را جایگزین نمی‌کند.

یک بررسی سرویس عمومی می‌تواند از یک نقطه پایانی از فهرست پراکسی HTTP در این مقادیر استفاده کند، زمانی که واسطه‌های عمومی مجاز باشند و کلاینت کارگر هیچ اعتبارنامه پراکسی پیکربندی‌شده یا نگه‌داشته‌شده نداشته باشد. با چندین واحد مخصوص صف، مشخص کنید کدام یک کار ناموفق را اجرا کرده است. موفقیت یک کارگر دیگر پیکربندی این یکی را اثبات نمی‌کند.

آن واحد و کلاینت HTTP را با هم ثبت کنید. یک کلاینت که صریحاً پیکربندی شده است می‌تواند صرف‌نظر از متغیرهای تحویل‌شده به کارگر از مسیر دیگری استفاده کند؛ در آن صورت رابط پشتیبانی‌شده آن را پیکربندی کنید.