curl, .NET અને કન્ટેનરમાં NO_PROXY સુસંગતતા
એક શેર કરેલી સીધી-રાઉટિંગ નીતિને નાના પ્રતિનિધિ ગંતવ્યોના સમૂહનો ઉપયોગ કરીને ક્લાયન્ટ-વિશિષ્ટ ગોઠવણીમાં ફેરવો.
એક ટીમ એક બાયપાસ શબ્દમાળા શેર કરેલી પર્યાવરણ ફાઇલમાં મૂકે છે. curl સીધું જાય છે, બીજી એપ્લિકેશન પ્રોક્સી વાપરે છે, અને કન્ટેનર ફરી અલગ રીતે વર્તે છે. શેર કરેલી ફાઇલે સમાન અક્ષરો વિતરિત કર્યા. પણ તેણે એક શેર કરેલો પાર્સર વિતરિત કર્યો નહીં.
ટકાઉ વસ્તુ નીતિ છે: કયા ગંતવ્યો સીધા હોવા જોઈએ, કઈ શરતો હેઠળ? તેને દરેક પ્રોગ્રામને જરૂરી શબ્દમાળાથી અલગ રાખો.
પહેલા અપેક્ષિત રૂટ લખો
ફક્ત સરળ સફળતાઓ નહીં, સીમાઓ સહિત પ્રતિનિધિ સરનામાં વાપરો:
| ગંતવ્યનો આકાર | નીતિના માલિક માટે પ્રશ્ન |
|---|---|
| મૂળ ડોમેન | તેને બાયપાસ કરવું જોઈએ, કે ફક્ત તેના બાળકોને? |
| એક સબડોમેન | તે સમાન રૂટ વારસામાં મેળવે છે? |
| એક શાબ્દિક ખાનગી IP | શું તે સરનામું આ ક્લાયન્ટથી સીધું પહોંચી શકાય છે? |
| હોસ્ટનામ હેઠળ સમાન સેવા | નામ-આધારિત અને સરનામા-આધારિત વિનંતીઓ સહમત થવી જોઈએ? |
| બીજું સેવા પોર્ટ | શું અપવાદ હોસ્ટને આવરે છે કે એક શ્રોતાને? |
પછી ગ્રાહકોને ઓળખો: ઇમેજ ખેંચતું ડિમન, કન્ટેનરની અંદરનો પ્રોગ્રામ, ભાષાની HTTP લાઇબ્રેરી અને એક ઇન્ટરેક્ટિવ બ્રાઉઝર બધા અલગ એન્ટ્રી હોઈ શકે છે. Docker ક્લાયન્ટ પ્રોક્સી ગોઠવણી કન્ટેનર પર્યાવરણ મૂલ્યો ભરી શકે છે, અંદરના દરેક ક્લાયન્ટને સમાન મેળ નિયમો લાગુ કરવાની જરૂર વગર.
આંધળી નકલ કરવાને બદલે અનુવાદ કરો
વાસ્તવિક તફાવતનું એક દસ્તાવેજીકૃત ઉદાહરણ મૂળ ડોમેનની સીમા છે. curlનું ડોમેન બાકાત નામ આપેલ ડોમેન અને મેળ ખાતા બાળકોને આવરે છે. .NETની પર્યાવરણ નીતિ નરી નામને અગ્ર બિંદુ સબડોમેન સ્વરૂપથી અલગ પાડે છે. હંમેશા અગ્ર બિંદુ ઉમેરો એવો સાર્વત્રિક નિયમ બંને નીતિઓને વિશ્વસનીય રીતે વ્યક્ત કરી શકતો નથી.
IP શ્રેણીનો સમર્થન પણ ગ્રાહક અને તેના સંસ્કરણ પર આધાર રાખે છે. નવા સ્વતંત્ર curl ધરાવતું મશીન હજી પણ જૂની libcurl સાથે જોડાયેલી એપ્લિકેશન, અથવા સંપૂર્ણ અલગ લાઇબ્રેરી વાપરતો ક્લાયન્ટ ચલાવી શકે છે. ઓપરેટિંગ સિસ્ટમનું પ્રકાશન સંપૂર્ણ ક્લાયન્ટ યાદી નથી.
દરેક ગ્રાહક માટે તેના સમર્થિત ગોઠવણી ઇન્ટરફેસ અને ઇચ્છિત રૂટની સૌથી નાની અભિવ્યક્તિ નોંધો. ટૂંકી સ્પષ્ટ હોસ્ટ યાદી એવી ચતુર પેટર્ન કરતાં વધુ સારી હોઈ શકે છે જેનો અર્થ કોઈ સમજાવી શકતું નથી.
ગોઠવણીના પુરાવાને જોડાણના પુરાવાથી અલગ રાખો
પાર્સ કરેલી સેટિંગ અથવા રાઉટિંગ-નિર્ણય API પ્રોગ્રામે શું પસંદ કર્યું તે બતાવી શકે છે. પછી વિનંતીનું પરિણામ બતાવે છે કે તે રૂટ વાપરી શકાય તેવો હતો કે નહીં. .NETમાં, HttpClient.DefaultProxy.IsBypassed જ્યારે ડિફોલ્ટ પ્રોક્સી વપરાતી નીતિ હોય ત્યારે તે ગોઠવણી-બાજુની તપાસ પૂરી પાડે છે. ફક્ત વિનંતીનો સમય પૂરો થયો એ કારણે પહોંચી ન શકાય તેવી સીધી સેવાને બાયપાસ-પાર્સર નિષ્ફળતા તરીકે નિદાન કરશો નહીં.
ક્લાયન્ટ અથવા બેઝ ઇમેજ અપડેટ કરતી વખતે સીમા ગંતવ્યો રાખો. તેઓ ભાવિ સુસંગતતા ફેરફારોને દૃશ્યમાન કરે છે, આખી ટીમને ફાઇલમાં બે સમાન દેખાતી ડોમેન એન્ટ્રી કેમ છે તે ફરીથી શોધવાની જરૂર વગર.