কাজটি তার Sidekiq কর্মীর পরিবেশ ব্যবহার করে, নতুন টার্মিনাল বা Rails ওয়েব প্রক্রিয়া নয়। এমন একটি সামনের সারির কর্মীর জন্য যার 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 ক্লায়েন্ট একসাথে রেকর্ড করুন। স্পষ্টভাবে কনফিগার করা ক্লায়েন্ট কর্মীর কাছে দেওয়া ভেরিয়েবল নির্বিশেষে অন্য পথ ব্যবহার করতে পারে; সেক্ষেত্রে এর সমর্থিত ইন্টারফেস কনফিগার করুন।

সম্পর্কিত নিবন্ধ