network_mode: service:vpn ഉം കാണാതായ db ഹോസ്റ്റ് നാമവും

നിങ്ങൾ ആപ്പിൽ 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 സേവനത്തിന് സ്വന്തം വിലാസം ഇല്ലാത്തത് എന്തുകൊണ്ടെന്നതും ഉൾപ്പെടെ.