VPN සම්බන්ධ වූ පසු Docker වෙළුම මවුන්ට් අසාර්ථක වේ: daemon පරීක්ෂා කරන්න

මෙම ගැටලුව පිළිබඳ සෑම ලේඛනයක්ම පාහේ වෙළුමට දොස් පවරයි, සහ නිවැරදි කිරීම මෙතරම් කාලයක් ගැනීමට හේතුව ද එයමය. ඔබට වැඩ කළ bind mount එකක් තිබුණි, ආයතනික VPN සම්බන්ධ විය, සහ docker compose up දැන් නැති වූ source path, හිස් ඩිරෙක්ටරියක්, හෝ එන්ජිම සෑදීමට ප්‍රතික්ෂේප කරන mount එකක් සමඟ අසාර්ථක වේ. මා පිරිසිදු කළ පරිසරවල Compose ගොනුව වෙනස් වී නොතිබූ අතර මාර්ගය නිවැරදි විය. වෙනස් වූයේ කුමන daemon එකට ඉල්ලීම ලැබුණේ ද යන්නයි, සහ mount දෝෂය එම වෙනස මුලින්ම පෙනුණු පළමු තැන පමණි.

වෙළුම කිසිදා නොසෙල්වුණි; ඉල්ලීම සෙල්වුණි

එක් -v /srv/app:/app flag එකක් යනු ඔබේ shell කරන ඩිරෙක්ටරි පිටපතක් නොවේ. ක්ලයන්ට් එය API ඉල්ලීමක් බවට පත් කරයි, සහ පිළිතුරු දෙන daemon එක /srv/app තමන්ගේම ගොනු පද්ධතියට එරෙහිව විසඳයි. දෙපැත්තම එකම කර්නලයේ ධාවනය වන විට, එය ඔබ ගොනු කළමනාකරුවෙකු තුළ දකින මාර්ගයයි. endpoint වෙනස් වන විට, එම අකුරු පේළියම ඔබේ ව්‍යාපෘති ඩිරෙක්ටරිය ගැන කිසිදා නොඇසූ යන්ත්‍රයක සොයනු ලැබේ, සහ daemon එක මූලාශ්‍රය නැති බව වාර්තා කරයි නැතහොත් එහි තැන හිස් ඩිරෙක්ටරියක් නිශ්ශබ්දව සාදයි.

නම් කළ වෙළුමක් දිගටම වැඩ කරමින් bind mount එකක් නොකරන්නේ එබැවිනි. -v appdata:/app daemon එකට අයත් ගබඩාව නම් කරයි, එබැවින් කිසිදු host මාර්ගයක් යම් නිශ්චිත තැනක පැවතිය යුතු නොවේ. එක් සේවාවක් bind mount එකකින් නම් කළ වෙළුමකට මාරු කිරීමෙන් දෝෂය නැති වුවහොත්, ඔබ ගැටලුව නිවැරදි කර නැත. ක්ලයන්ට් සහ daemon මාර්ගය කුමන ගොනු පද්ධතියට අයත් ද යන්න ගැන එකඟ නොවන බව ඔබ තහවුරු කළේය, සහ එම එකඟ නොවීම ඔබට නැවත සැබෑ host ඩිරෙක්ටරියක් අවශ්‍ය වන මොහොතේ ආපසු පැමිණේ.

මවුන්ට් එක ස්පර්ශ කිරීමට පෙර endpoint මුද්‍රණය කරන්න

සැකසුම් කිහිපයකට ක්ලයන්ට් එක endpoint එකකට යොමු කළ හැක, සහ ඒවා සැමවිටම එකඟ නොවේ: --context flag එකක්, DOCKER_CONTEXT, DOCKER_HOST වත්මන් shell තුළ, සහ ක්ලයන්ට් වින්‍යාසයේ සුරකින ලද context. ප්‍රමුඛතාව ගැන සිතනවා වෙනුවට සියල්ල මුද්‍රණය කර පිළිතුරු සසඳන්න.

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

ක්ලයන්ට් වින්‍යාසය පිහිටන්නේ ~/.docker/config.json Linux සහ macOS තුළ, සහ %USERPROFILE%\.docker\config.json Windows තුළ ය, සහ වත්මන් ටර්මිනලයේ export කළ අගය සුරකින ලද අගය අභිබවා යන්නේ එම සැසියට පමණි. endpoint එක දේශීය socket එකක් වෙනුවට hostname එකක් නම්, නාම විසඳීම සහ මාර්ග එය ගොඩ බසින තැන තීරණය කරයි, සහ VPN ක්ලයන්ට් එක නැවත ලියන්නේ එයමය. මාර්ගයක් එකතු කරන හෝ resolver එක මාරු කරන උමගකට පෙර මෙම ලැප්ටොප් පරිගණකය අදහස් කළ නමක් ආයතනික ජාලය තුළ ඇති ලිපිනයකට යැවිය හැක.

වින්‍යාසය වෙනුවට තත්ත්වය සසඳන්න. උමග වැසී ඇති විට docker ps -a සහ docker images ධාවනය කරන්න, පසුව උමග විවෘතව ඇති විට නැවතත්. වෙනස් කන්ටේනර ලැයිස්තුවක් ඕනෑම වින්‍යාස ගොනුවකට වඩා ශක්තිමත් සාක්ෂියකි, මන්ද එය ඔබේ ඉල්ලීමට වෙනත් daemon එකක් පිළිතුරු දුන් බව පෙන්වයි.

මාර්ගය එහි තිබේ දැයි daemon එකෙන් අසන්න

ඔබ පැමිණියේ කුමන daemon එකට දැයි දැනගත් පසු, එයට ඩිරෙක්ටරිය දෙස බැලීමට සලස්වන්න. --mount ආකෘතිය කෙටි flag එකට වඩා පැහැදිලි පණිවිඩයක් සමඟ අසාර්ථක වේ, මන්ද එය කන්ටේනරය ආරම්භ කිරීමට පෙර මූලාශ්‍රය වලංගු කරයි:

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

එය මූලාශ්‍රය නැති බව වාර්තා කරන්නේ නම්, පිළිතුරු දුන් යන්ත්‍රයේ එය සාදන්න, නැතහොත් සේවාව නම් කළ වෙළුමකට යොමු කර දත්ත එහි පිටපත් කරන්න. මෙම පරීක්ෂාවට පෙර වෙළුම් නැවත සෑදීම සහ එන්ජිම නැවත ස්ථාපනය කිරීම ඔබ නොකළ යුතු දෙයයි. එම ක්‍රියා පරිසරය නොගැළපීම සඟවා තැබීමට තරම් වෙනස් කරයි, නමුත් එය එහි තැනම තබයි.

තවත් එක් මාර්ගයක් සම්පූර්ණයෙන්ම වෙනත් තැනක ගමන් කරයි: image එකක් ඇදගැනීම daemon එකේ කටයුත්තකි, ක්ලයන්ට් එකේ නොවේ. සාර්ථක ඇදගැනීමක් ඔප්පු කරන්නේ daemon එකට registry එකකට ළඟා විය හැකි බව පමණි, සහ වැඩ කරන bind mount එකක් ඔප්පු කරන්නේ මාර්ගයක් විසඳුණු බව පමණි. සෑම මාර්ගයක්ම එය සැබවින්ම ක්‍රියාත්මක වන තැන පරීක්ෂා කරන්න, නැතහොත් වැරදි එකකට දහවල් කාලයක් ගත කරනු ඇත.

ඉන්ට්‍රානෙට් නාම අසාර්ථක වන්නේ වෙනත් හේතුවක් නිසා

එම වාර්තාවේ දෙවන භාගය සාමාන්‍යයෙන් වන්නේ කන්ටේනරයට intranet.corp.exampleවෙත ළඟා විය නොහැකි වීමයි. එය වෙනම යාන්ත්‍රණයකි, දෙවන වෙළුම් ගැටලුවක් නොවේ. කන්ටේනරයට එහි /etc/resolv.conf ලැබෙන්නේ ආරම්භ වන විට ය, එය daemon resolver සැකසුම්වලින් ජනනය වේ, එබැවින් කන්ටේනරය සෑදීමෙන් පසු VPN එකතු කළ DNS සේවාදායකය කන්ටේනරය නැවත සෑදෙන තෙක් එහි නොපෙනේ.

පරිශීලක-නිර්වචිත ජාලයක Docker හි අන්තර්ගත resolver එක බාහිර විමසුම් host හි වින්‍යාස කළ සේවාදායකවලට යොමු කරයි, එය VPN host resolver නැවත ලියන විට උපකාරී වන අතර බෙදුණු DNS අභ්‍යන්තර කලාපයක් daemon තවදුරටත් නොදකින සේවාදායකයකට යවන විට හානි කරයි. පටු, පැහැදිලි සිතියම්කරණය කිසිදා නොවෙනස් වන නාම සඳහා වන තර්කය මඟහරියි:

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

මෙය කන්ටේනරයේ hosts ගොනුවට සටහනක් ලියයි, එබැවින් කන්ටේනරය උමග ගැන කිසිවක් නොදැනගනී, සහ ලිපිනය ද කැටි කරයි. අභ්‍යන්තර host එක ගමන් කරන විට, යමෙක් Compose ගොනුව සංස්කරණය කරන තෙක් සටහන වැරදි ලෙසම පවතී. ස්ථිර උපකරණයකට හෝ පින් කළ දත්ත සමුදායකට එය භාවිත කරන්න, සහ ගමන් කරන නාම DNS වෙත භාර දෙන්න.

නැවත ස්ථාපනයක් සැබවින්ම වෙනස් කරන්නේ කුමක්ද

Docker Desktop නැවත ස්ථාපනය කිරීම VM, socket සහ context ලැයිස්තුව නැවත සාදයි, සහ මවුන්ට් එක නැවත වැඩ කරන්නට පටන් ගනී. එම ප්‍රතිඵලය සැබෑ ය සහ එය කිසිවක් උගන්වන්නේ නැත, එබැවින් ඊළඟ VPN යාවත්කාලීනයෙන් පසු එමම දෝෂය ආපසු පැමිණේ. නැවත ස්ථාපනය ක්ලයන්ට් භාවිත කළ endpoint එක ප්‍රතිස්ථාපනය කළේය; එය ඔබේ ව්‍යාපෘතිය නම් කරන මාර්ගය daemon සැබවින්ම කියවන ගොනු පද්ධතිය සමඟ සමඟි නොකළේය.

මගේ කාර්ය අනුපිළිවෙල කෙටිය. ක්ලයන්ට් භාවිත කරන්නේ කුමන endpoint එකදැයි තහවුරු කරන්න. කන්ටේනර ලැයිස්තු සසඳා කුමන daemon එක පිළිතුරු දුන්නේ දැයි තහවුරු කරන්න. එම daemon එකට source path ලැයිස්තුගත කරන්න කියන්න. ඊට පසුව පමණක් මවුන්ට් එක සංස්කරණය කරන්න, hosts සටහනක් එකතු කරන්න, නැතහොත් වෙළුම් වර්ගයක් වෙනස් කරන්න. ඔබ VPN හරහා වැඩ කරන කණ්ඩායමක් සඳහා Compose ගොනුව නඩත්තු කරන්නේ නම්, daemon සතු විය යුතු දත්ත සඳහා නම් කළ වෙළුම්වලට මුල් තැන දෙන්න, එවිට host මාර්ගය කිසිදා ගිවිසුමේ කොටසක් නොවනු ඇත.