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 ક્લાયન્ટ ક્યારે તેનું પ્રોક્સી સેટિંગ વાપરે તે મુજબ પસંદ કરો.