પ્રોક્સી કન્ટેનર DNS કન્ટેનરનો આપમેળે ઉપયોગ કેમ નથી કરતું

એક જ Docker હોસ્ટ પર પ્રોક્સી અને DNS સર્વર ચલાવવાથી તેમના DNS માર્ગો જોડાતા નથી. ત્રણ અલગ સંબંધો મહત્વના છે:

• નેટવર્ક પહોંચ. અલગ Compose પ્રોજેક્ટમાં સામાન્ય રીતે અલગ ડિફોલ્ટ નેટવર્ક હોય છે. સેવાઓને યોગ્ય શેર્ડ નેટવર્ક પર મૂકો, ક્યાં તો એક પ્રોજેક્ટની અંદર અથવા પ્રોજેક્ટ વચ્ચે સ્પષ્ટ રીતે શેર કરેલા નેટવર્ક દ્વારા.
• સેવા શોધ. કસ્ટમ Docker નેટવર્કનું એમ્બેડેડ DNS કન્ટેનર નામોને રિઝોલ્વ કરી શકે છે. તે એપ્લિકેશનને પડોશી શોધવા દે છે; પરંતુ તે પડોશીને આપમેળે તેના DNS રિઝોલ્વર તરીકે પસંદ કરતું નથી.
• રિઝોલ્વર પસંદગી. પ્રોક્સી કન્ટેનરની અંદર વપરાતું રિઝોલ્વર ઓળખો. Composeનું dns ફીલ્ડ DNS સર્વર સરનામાં લે છે. એપ્લિકેશનમાં રિઝોલ્વ થતું dns.local જેવું નામ તેને તે ફીલ્ડ માટે માન્ય મૂલ્ય બનાવતું નથી.

પ્રોક્સી કન્ટેનરથી તેના ગોઠવેલા રિઝોલ્વર સરનામા સુધી ક્વેરીને અનુસરો. તે સરનામે રૂટ અને DNS શ્રોતા છે તેની ખાતરી કરો. હોસ્ટ પોર્ટ 53 પ્રકાશિત કરવાથી હોસ્ટ બાજુએ એક્સેસ માર્ગ બને છે; પરંતુ તે કન્ટેનરને તેનો ઉપયોગ કરવાનું કહેતું નથી. નેટવર્ક શેર કરતા કન્ટેનર તેના બદલે સીધા સંચાર કરી શકે છે.

જો ગોઠવણી DNS કન્ટેનરના સરનામાનો સંદર્ભ આપે, તો તેને સુસંગત IPAM ગોઠવણી હેઠળ સ્થિર રાખો. ગઈકાલના કન્ટેનરમાંથી કોપી કરેલું ગતિશીલ રીતે ફાળવેલું સરનામું પુનઃનિર્માણ વખતે નિષ્ફળ થઈ શકે છે. રિઝોલ્વરનો અપસ્ટ્રીમ માર્ગ પણ તપાસો: જવાબ વગરની ક્વેરી તેની જાત પર પાછી મોકલવાથી અપ્રાપ્ય રિઝોલ્વર કરતાં અલગ નિષ્ફળતા ઊભી થાય છે.

અંતે, ગંતવ્યને કોણ રિઝોલ્વ કરે છે તે ઓળખો. CONNECT નામ રિઝોલ્વ કરતું HTTP પ્રોક્સી આ કન્ટેનર માર્ગ વાપરી શકે છે; સ્થાનિક રીતે રિઝોલ્વ કરતું SOCKS ક્લાયન્ટ ન પણ કરે. હોસ્ટ લુકઅપ હોસ્ટના માર્ગને સાબિત કરે છે, પ્રોક્સી પ્રક્રિયાના નહીં.