Docker බහාලුම් VPN හි DNS විසඳන්නා නොසලකා හරින්නේ ඇයි

VPN ක්‍රියාත්මකයි, බ්‍රවුසරය අභ්‍යන්තර අඩවි වෙත ළඟා වෙයි, නමුත් බහාලුමට තවමත් එම නම් විසඳිය නොහැක. පැකේජ ස්ථාපනය EAI_AGAIN වැනි නම්-විසඳීම් දෝෂයකින් මිය යයි, නැතහොත් යෙදුමකට සත්කාරක යන්ත්‍රය කිසිදු පැමිණිල්ලකින් තොරව විසඳන දත්ත සමුදාය සත්කාරකය සොයාගත නොහැක. බහාලුම VPN ස්ථාපනය කළ විසඳන්නා භාවිත නොකරයි. බහාලුම සෑදූ විට Docker සත්කාරකයේ විසඳන්නා සැකසුම පිටපත් කළ අතර, ඉන් පසු කිසිවක් එය නැවත පිටපත් නොකළේය.

එක් යන්ත්‍රයක විසඳන්නාගේ දර්ශන දෙකක්

Linux තුළ, Docker නිර්මාණයේදී සෑම බහාලුමකටම සත්කාරකයේ විසඳන්නා සැකසුමේ පිටපතක් ලබා දෙයි, loopback ලිපින පෙරහන් කරයි, සහ 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 තුළ එම සැකසුම සේවාව යටතේ ලැයිස්තුවක් වන අතර, එහිදී එය යමෙකුගේ shell ඉතිහාසය වෙනුවට අනුවාද පාලනයේ ජීවත් වේ.

/etc/docker/daemon.json හි dns අරේ සෑම නව බහාලුමකටම අදාළ වේ, එය වඩා පිළිවෙලක් ලෙස පෙනුනද එසේ නොවේ. උමං වසා ඇති විටද එය අදාළ වන අතර, එවිට VPN හරහා පමණක් ළඟා විය හැකි විසඳන්නෙකු සාමාන්‍ය රූප ඇදගැනීම කඩා දමයි. බහාලුමකට වෙන් වූ සැකසුම් තර්ක කිරීමටද ආපසු හැරවීමටද පහසුය.

විකල්පය B: බහාලුමට සත්කාරක ජාලය බෙදා ගැනීමට ඉඩ දීම

සත්කාරක ජාලකරණය පිටපත සම්පූර්ණයෙන්ම මගහරියි, මන්ද බහාලුම සත්කාරකයේ විසඳන්නා සහ සත්කාරකයේ උමං භාවිත කරයි. එය ඔබට අවශ්‍ය වූ ජාල හුදකලාවද ඉවත් කරයි, සහ Docker Desktop යටතේ එය එකම ලෙස හැසිරෙන්නේ නැත. Linux හි අභ්‍යන්තර නම් විසඳිය යුතු එක්-වරක් මෙවලමකට එය ප්‍රායෝගික තේරීමයි.

build සඳහා කිසිදු විකල්පයක් අදාළ නොවේ, මන්ද build පියවර ධාවන කාලයේ ධජ උරුම නොකරයි. වේදිකාව අවසර දෙන තැන සත්කාරක ජාලකරණය සමඟ build කරන්න, නැතහොත් යැපුම් ස්ථාපනය උමං අවශ්‍ය නොවන අදියරක තබන්න.

කිසිදු විකල්පයක් නොවිසඳන දේ

බහාලුමට එතැනට මාර්ගයක් නොමැති නම් DNS ලිපිනය නිෂ්ඵලය. VPN විසඳන්නා සාමාන්‍යයෙන් උමංගේ ලිපින අවකාශය තුළ වාඩි වේ, එබැවින් බහාලුමට එම උපසර්ගයට මාර්ගයක් අවශ්‍යය. Docker හි පෙරනිමි පාලම සාමාන්‍යයෙන් සත්කාරකය හරහා පිටතට මාර්ග කරයි, සත්කාරකයට උමං මාර්ගය ඇති විට සහ ඉදිරියට යැවීම සක්‍රීය විට එය ප්‍රමාණවත්ය. ස්වකීය ලිපින තටාක සහිත අභිරුචි පාලම් ජාල VPN උපජාලය සමඟ ගැටිය හැක, එවිට විමසුම් සම්පූර්ණයෙන්ම වෙනත් තැනකට යයි.

විසඳන්නාම දෝෂ නිරාකරණය කිරීමට පෙර Docker ජාලයේ උපජාලය VPN උපජාලය සමඟ සසඳන්න. අතිච්ඡාදනය කැඩුණු DNS සේවාදායකයක් මෙන් හරියටම පෙනෙන අසමත්වීමක් නිපදවයි.

බහාලුම තුළ තහවුරු කරන්න

බ්‍රවුසරයක් හෝ භාෂා ධාවන කාලයක් වෙනුවට බහාලුම තුළ getent hosts db.internal සමඟ පරීක්ෂා කරන්න, මන්ද ඒවා තමන්ගේම DNS ප්‍රතිපත්තියක් සහ තමන්ගේම හැඹිලියක් යොදයි. getent නම විසඳා යෙදුම තවමත් අසමත් වන්නේ නම්, විසඳන්නා දැන් නිවැරදියි සහ ඉතිරි ගැටලුව යෙදුම් මට්ටමේය. එය විසඳන්නේ නැත්නම්, DNS පියවර අවසන් නැත.

DNS සැකසුම් වෙනස් කිරීමෙන් පසු බහාලුම නැවත සාදන්න. ධාවනය වන බහාලුමක් තුළ /etc/resolv.conf සංස්කරණය කිරීම එය සමඟ අතුරුදහන් වන අතර වින්‍යාස ගැටලුව යමෙකුට එය නැවත ආරම්භ කිරීමට ගතවන තරම් කාලයක් සඟවයි.