Docker કન્ટેનર શા માટે VPN ના DNS રિઝોલ્વરને અવગણે છે

VPN ચાલુ છે, બ્રાઉઝર આંતરિક સાઇટ્સ સુધી પહોંચે છે, અને કન્ટેનર હજી પણ એ જ નામો ઉકેલી શકતું નથી. પેકેજ ઇન્સ્ટોલ EAI_AGAIN જેવી નામ-ઉકેલ ભૂલ સાથે મરી જાય છે, અથવા કોઈ એપ્લિકેશન એવું ડેટાબેઝ હોસ્ટ શોધી શકતું નથી જે હોસ્ટ મશીન કોઈ ફરિયાદ વિના ઉકેલે છે. કન્ટેનર VPN દ્વારા ઇન્સ્ટોલ કરેલા રિઝોલ્વરનો ઉપયોગ કરતું નથી. કન્ટેનર બન્યું ત્યારે Docker એ હોસ્ટનું રિઝોલ્વર કન્ફિગરેશન કોપી કર્યું, અને પછી કંઈએ તેને ફરીથી કોપી કર્યું નથી.

એક જ મશીન પર રિઝોલ્વરના બે દૃશ્યો

Linux પર, Docker દરેક કન્ટેનરને બનાવવાના સમયે હોસ્ટના રિઝોલ્વર કન્ફિગરેશનની કોપી આપે છે, લૂપબેક સરનામાં ફિલ્ટર કરે છે, અને 127.0.0.11 પર એમ્બેડેડ DNS સર્વર ચલાવે છે જે ક્વેરી બહાર મોકલે છે. કન્ટેનર શરૂ થયા પછી /etc/resolv.conf ફરીથી લખતું VPN ક્લાયન્ટ તેની અંદર કંઈ બદલતું નથી. કન્ટેનર ફરી ચાલુ કરવાથી ફક્ત ત્યારે જ મદદ મળે છે જ્યારે તે ક્ષણે હોસ્ટ રિઝોલ્વર સંજોગવશાત સાચું હોય.

macOS અથવા Windows પર Docker Desktop એક સ્તર ઉમેરે છે, કારણ કે ડેમન વર્ચ્યુઅલ મશીનમાં રહે છે. હોસ્ટનું VPN રિઝોલ્વર તે VM માટે કદી દૃશ્યમાન ન પણ હોય, તેથી ફરી ચાલુ કરવાથી કંઈ જ બદલાતું નથી. ઉપાય પસંદ કરતા પહેલાં બંને દૃશ્યોની તુલના કરો: હોસ્ટની રિઝોલ્વર યાદીની બાજુમાં docker exec mycontainer cat /etc/resolv.conf.

હોસ્ટ આંતરિક રિઝોલ્વર સૂચિબદ્ધ કરે અને કન્ટેનર જાહેર રિઝોલ્વર સૂચિબદ્ધ કરે તો તે જાહેર નામો ઉકેલશે અને આંતરિક નામોમાં નિષ્ફળ જશે. આ વિભાજન આ સમસ્યાની સહી છે.

વિકલ્પ A: દરેક કન્ટેનર માટે ટનલ રિઝોલ્વર પાસ કરવું

Docker દરેક કન્ટેનર માટે DNS સેટિંગ્સ સ્વીકારે છે, અને તે કામ કરતો સૌથી નાનો ફેરફાર છે. પહેલાં VPN ના રિઝોલ્વર સરનામાં વાંચો: macOS પર scutil --dns, Linux પર resolvectl status અથવા ક્લાયન્ટનું પોતાનું સ્ટેટસ આઉટપુટ. પછી તેમની સાથે કન્ટેનર શરૂ કરો, ઉદાહરણ તરીકે docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose માં એ જ સેટિંગ સેવા હેઠળની યાદી છે, જ્યાં તે કોઈના શેલ ઇતિહાસને બદલે વર્ઝન કંટ્રોલમાં રહે છે.

/etc/docker/daemon.json માં dns એરે દરેક નવા કન્ટેનર પર લાગુ થાય છે, જે વધુ ગોઠવાયેલું લાગે છે અને નથી. ટનલ બંધ હોય ત્યારે પણ તે લાગુ થાય છે, અને ત્યારે ફક્ત VPN દ્વારા પહોંચી શકાય તેવું રિઝોલ્વર સામાન્ય ઇમેજ પુલ તોડી નાખે છે. પ્રતિ-કન્ટેનર સેટિંગ્સ સમજાવવી સહેલી અને પાછી ખેંચવી સહેલી છે.

વિકલ્પ B: કન્ટેનરને હોસ્ટ નેટવર્ક શેર કરવા દેવું

હોસ્ટ નેટવર્કિંગ કોપીને સંપૂર્ણપણે ટાળે છે, કારણ કે કન્ટેનર હોસ્ટના રિઝોલ્વર અને હોસ્ટની ટનલ વાપરે છે. તે તમે સંભવતઃ ઇચ્છતા હતા તે નેટવર્ક અલગતા પણ દૂર કરે છે, અને Docker Desktop હેઠળ તે એ જ રીતે વર્તતું નથી. Linux પર આંતરિક નામો ઉકેલવા પડતા એક-વખતના સાધન માટે તે વ્યવહારુ પસંદગી છે.

બિલ્ડ માટે બંનેમાંથી કોઈ વિકલ્પ લાગુ પડતો નથી, કારણ કે બિલ્ડ પગલાં રનટાઇમ ફ્લેગ વારસામાં મેળવતા નથી. જ્યાં પ્લેટફોર્મ પરવાનગી આપે ત્યાં હોસ્ટ નેટવર્કિંગ સાથે બિલ્ડ કરો, અથવા ડિપેન્ડન્સી ઇન્સ્ટોલેશનને એવા તબક્કામાં રાખો જેને ટનલની જરૂર ન હોય.

બંને વિકલ્પો જે સુધારતા નથી

કન્ટેનર પાસે તેનો રસ્તો ન હોય તો DNS સરનામું નકામું છે. VPN રિઝોલ્વર સામાન્ય રીતે ટનલના સરનામા અવકાશની અંદર બેસે છે, તેથી કન્ટેનરને તે પ્રીફિક્સ સુધીનો રસ્તો જોઈએ. Docker નો ડિફોલ્ટ બ્રિજ સામાન્ય રીતે હોસ્ટ દ્વારા બહાર રૂટ કરે છે, અને હોસ્ટ પાસે ટનલ રૂટ હોય તથા ફોરવર્ડિંગ ચાલુ હોય ત્યારે તે પૂરતું છે. પોતાના સરનામા પૂલ સાથેના કસ્ટમ બ્રિજ નેટવર્ક VPN સબનેટ સાથે અથડાઈ શકે છે, અને પછી ક્વેરીઓ સાવ બીજે જ જાય છે.

રિઝોલ્વરનું જ ડિબગ કરતા પહેલાં Docker નેટવર્કનું સબનેટ VPN સબનેટ સામે તપાસો. ઓવરલેપ એવી નિષ્ફળતા ઉત્પન્ન કરે છે જે બગડેલા DNS સર્વર જેવી જ લાગે છે.

કન્ટેનરની અંદર ચકાસો

બ્રાઉઝર કે ભાષા રનટાઇમને બદલે કન્ટેનરની અંદર getent hosts db.internal વડે પરીક્ષણ કરો, કારણ કે તે પોતાની DNS નીતિ અને પોતાનું કેશિંગ લાગુ કરે છે. જો getent નામ ઉકેલે અને એપ્લિકેશન હજી નિષ્ફળ જાય, તો રિઝોલ્વર હવે સાચું છે અને બાકીની સમસ્યા એપ્લિકેશન સ્તરની છે. જો તે ઉકેલે નહીં, તો DNS પગલું પૂરું થયું નથી.

DNS સેટિંગ્સ બદલ્યા પછી કન્ટેનર ફરીથી બનાવો. ચાલુ કન્ટેનરની અંદર /etc/resolv.conf સંપાદિત કરવું તેની સાથે અદૃશ્ય થાય છે અને કન્ફિગરેશન સમસ્યાને બરાબર ત્યાં સુધી છુપાવે છે જ્યાં સુધી કોઈ તેને ફરી ચાલુ કરવામાં ન આવે.