ඔබ යෙදුමට network_mode: service:vpn එකතු කර ස්ටැක් නැවත ආරම්භ කරන විට db තවදුරටත් විසඳෙන්නේ නැති නිසා යෙදුම මිය යයි. compose ගොනුවේ කිසිවක් නැවත නම් නොකළ නිසා පැහැදිලි සැකකරුවෝ DNS සහ දත්ත සමුදායයි. සැබෑ වෙනස කුඩා හා අමුතුයි: එම නාමය පවතින Compose ජාලයේ සාමාජිකත්වය යෙදුම නතර කළේය. දත්ත සමුදාය කුමන නාම අවකාශයකින් පිළිතුරු දිය යුතු දැයි ඔබ තීරණය කරන තෙක් සෑම සත්කාරක නාම නිවැරදි කිරීමක්ම අනුමානයකි.

db සත්කාරක නාමය විසඳීම නතර වූයේ ඇයි

network_mode භාවිතා කරන සේවාවකට Compose ජාලයක තමන්ගේම ලිපිනයක් නැත; එය නම් කළ සේවාවේ නාම අවකාශය ණයට ගනී. එම අවකාශය තමන්ගේම අතුරුමුහුණත්, මාර්ග, තොටුපළ අවකාශය සහ විසඳන්නා ගෙන එයි, එමෙන්ම එය යෙදුමේ backend ජාලයට ඇති සම්බන්ධය ප්‍රතිස්ථාපනය කරයි. db නාමය කිසිදා වියුක්ත නොවීය: එය එම ජාලයේ ජීවත් වූ අතර එහි ඇතුළත DNS හරහා විසඳුණි. සම්බන්ධය ඉවත් කරන්න, නාමයට විසඳීමට තැනක් නැත.

මෙය සත්කාරකයෙන් නොව බහාලුම් තුළින් තහවුරු කරන්න. යෙදුමේ අසාර්ථක වුවත් දත්ත සමුදාය බහාලුමේ සාර්ථක වන සොයාගැනීම යනු නාමය හරි බවත් සාමාජිකත්වය නොවන බවත් ය. එම ප්‍රතිඵලය නිවැරදි කිරීම යෙදුමේ විසඳන්නා සැකසුම්වල නොව compose තෝපොලොජියේ තබයි.

ගොනුව සංස්කරණය කිරීමට පෙර ප්‍රශ්න තුනක්

ඒවාට පිළිවෙලින් පිළිතුරු දෙන්න, මන්ද එකින් එක තෝපොලොජිය පටු කරයි. දත්ත සමුදාය කුමකට පිළිතුරු දිය යුතුද: වෙනත් බහාලුම් භාවිතා කරන සත්කාරක නාමයකටද, නැතහොත් loopback මත යෙදුමට පමණක්ද? යෙදුම සත්කාරකයට තොටුපළක් පළ කළ යුතුද, එයට හිමිකම් කුමන සේවාවටද? දත්ත සමුදාය සත්කාරකයෙන් හෝ වෙනත් යන්ත්‍රයකින් ළඟා විය හැකි විය යුතුද, නැතහොත් උමග තුළින් පමණක්ද?

දත්ත සමුදායට තමන්ගේම නාමයක් අවශ්‍ය නම් සහ යෙදුම කිසිවක් පළ නොකරන්නේ නම්, ඒවා වෙන වෙනම සම්බන්ධතා මත තබන්න. යෙදුම තොටුපළක් පළ කළ යුතු නම් සහ සියල්ල උමග හරහා ගමන් කරන්නේ නම්, දත්ත සමුදාය VPN නාම අවකාශයේ තබා loopback භාවිතා කරන්න. දෙකම මිශ්‍ර කිරීමෙන් පිරිසිදුව ආරම්භ වී සම්බන්ධ වන විට අසාර්ථක වන ස්ටැක් එකක් සෑදේ.

දත්ත සමුදාය ඇති තැනම තබන්න

කුඩා වෙනස නාම අවකාශයේ හිමිකරු දැනටමත් දත්ත සමුදාය අඩංගු ජාලයට සම්බන්ධ කරයි. යෙදුම vpn ස්ටැක් බෙදාගන්නා නිසා එම සම්බන්ධය උරුම වේ, සහ db පෙර මෙන්ම විසඳේ.

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

යෙදුමට networks ද එකතු නොකරන්න. Compose එම සේවාවේ network_mode සමඟ එම ගුණාංගය ප්‍රතික්ෂේප කරයි, දෝෂය යුගලයට නොව ගොනුවට යොමු කරයි. VPN සේවාදායකය තම නාම අවකාශය තුළ backend ගමනාන්තය පෙරහන් කරන්නේ නම්, එහි අනුග්‍රාහක දේශීය ජාල ප්‍රතිපත්තියද සකසන්න; හවුල් සම්බන්ධය මාර්ගයක් දෙයි නමුත් එම පෙරහන අවලංගු නොකරයි.

දත්ත සමුදාය නාම අවකාශයට ගෙනයන්න

විශාල වෙනස දත්ත සමුදාය එම නාම අවකාශයේම තබා යෙදුම සැබෑ තොටුපළ සමඟ 127.0.0.1 වෙත යොමු කරයි. වෙනස් බහාලුම්වල ආරම්භ වූ නිසා පමණක් ක්‍රියාවලි දෙකකට එකම ලිපිනය සහ තොටුපළ යුගලම බැඳිය නොහැක, එබැවින් wildcard ලිපිනයේද සවන් දෙන දත්ත සමුදායක් එසේ කරන අනෙක් සියල්ල සමඟ ගැටෙනු ඇත. ගෙනයාමට පෙර සවන්දෙන්නා පරීක්ෂා කරන්න.

පළ කළ තොටුපළ නාම අවකාශය ඇති සේවාවට අයත් වේ. යෙදුමට ports එකතු කිරීම network_mode සමඟ ප්‍රතික්ෂේප වේ, සහ වෙනම යෙදුම් ලිපිනයක් ගොතනු ලැබීම නොපවතින අතුරුමුහුණතක් විස්තර කරයි.

සූදානම, අවහිර කිරීම සහ විසඳන්නා

depends_on බහාලුම් ආරම්භය අනුපිළිවෙල කරයි; එය උමග ක්‍රියාත්මක බවට සාක්ෂියක් නොවන අතර උමග වැටුණු විට එය ගමනාගමනය නවත්වන්නේ නැත. ළඟාවීම, උමගේ සූදානම සහ අසාර්ථකතා අවහිර කිරීම තනි තනි අවශ්‍යතා තුනක් ලෙස සලකන්න. පළමුවැන්න පමණක් තෘප්ත කරන ස්ටැක් හොඳ දිනක අත් පරීක්ෂණය සමත් වන අතර නරක දිනක කාන්දු වේ. පිළිතුරු තුන compose ගොනුව අසල ලියන්න, ඊළඟ පුද්ගලයා බලන තැන.

නාම අවකාශය බෙදාගැනීම යනු යෙදුම VPN බහාලුමේ විසඳන්නා උරුම කරගනී යන්නද වේ, උමග DNS සේවාදායක බල කරන විට එය උපකාරී වන අතර නොකරන විට ව්‍යාකූල කරයි. සත්කාරකයේ විසඳන්නා අදාළ යැයි උපකල්පනය කරනවාට වඩා නාම අවකාශයේ සැබවින්ම ඇත්තේ කුමක්දැයි පරීක්ෂා කරන්න. Compose සේවා යොමුව එකම තැනක network_mode, ports සහ යැපීම්වල හැසිරීම ලේඛනගත කරයි, network_mode සේවාවකට තමන්ගේම ලිපිනයක් නොමැති බවද ඇතුළුව.

අදාළ ලිපි