compile ও converge পর্যায়ে Chef প্রক্সি সেটিংস

previous = Chef::Config[:http_proxy]
Chef::Config[:http_proxy] = 'http://proxy.example.net:8080'

remote_file '/var/tmp/package.zip' do
  source 'https://downloads.example.net/package.zip'
end

Chef::Config[:http_proxy] = previous

এই সাধারণ রিসোর্সটি কিছু ডাউনলোড করার আগেই অস্থায়ী মানটি মুছে যায়:

1. Compile: শীর্ষ-স্তরের Ruby মানটি সংরক্ষণ করে, অস্থায়ী প্রক্সি সেট করে, remote_file ঘোষণা করে এবং মানটি পুনরুদ্ধার করে।
2. Converge: রিসোর্সটি তখনকার উপলব্ধ কনফিগারেশন দিয়ে তার কাজ সম্পাদন করে।

উপযুক্ত অভ্যন্তরীণ বর্জনের সঙ্গে একটি স্থিতিশীল ক্লায়েন্ট প্রক্সি এই সময়জনিত সমস্যা এড়ায়। shell wildcard নিয়ম ধরে নেওয়ার বদলে ইনস্টল করা ক্লায়েন্টের নথিভুক্ত বর্জন-সিনট্যাক্স ব্যবহার করুন। অনুমোদিত পাবলিক পথে স্বাধীন পাবলিক-আর্টিফ্যাক্ট ডাউনলোডের জন্য, Chef ক্লায়েন্টের কোনো কনফিগার করা বা সংরক্ষিত প্রক্সি অ্যাকাউন্ট না থাকলে HTTP প্রক্সি তালিকার একটি এন্ট্রি স্থিতিশীল HTTP এন্ডপয়েন্ট যোগাতে পারে। এর অভ্যন্তরীণ বর্জনগুলো রাখুন; ঠিকানা বেছে নিলে compile ও converge কখন এটি ব্যবহার করবে তা বদলায় না।

যদি একটি অপারেশনের বিশেষ পথ দরকার হয়, তার কনফিগারেশন পরিবর্তন ও সম্পাদন একই সুযোগে রাখুন। উপযুক্ত unified-mode আচরণসহ একটি কাস্টম রিসোর্স একটি বিকল্প, কিন্তু Chef::Config গ্লোবালই থাকে। ডাউনলোড ব্যর্থ হলে এবং ফাইলটি ইতিমধ্যে হালনাগাদ হলে এটি পুনরুদ্ধার করুন। আপডেট নোটিফিকেশন শর্তহীনভাবে চলে না, এবং পরবর্তী ক্লিনআপ রিসোর্স একটি এক্সেপশনের পরে কখনোই নাও চলতে পারে।

একটি lazy source প্রপার্টি সেই প্রপার্টির মূল্যায়ন বিলম্বিত করে, আশপাশের Ruby অ্যাসাইনমেন্ট নয়। ডাউনলোড যখন সেই সময়েই হওয়া উচিত, তখন compile-সময়ের রিসোর্স এক্সিকিউশন একটি পৃথক সমর্থিত বিকল্প; এটি নির্ভরতা ও নোটিফিকেশনের সময়ও বদলায়। ঘোষণার ক্রম বিচ্ছিন্নতা দেবে বলে আশা না করে, HTTP ক্লায়েন্ট কখন তার প্রক্সি সেটিং ব্যবহার করে তার ভিত্তিতে বেছে নিন।