Docker: ഒരു കണ്ടെയ്നർ VPN വഴി കടത്തി വിടുക, മറ്റൊന്ന് നേരിട്ട് നിലനിർത്തുക
ടണലിന് അതിന്റെ സ്വന്തം കണ്ടെയ്നർ നൽകുക, അത് ആവശ്യമുള്ള സേവനങ്ങൾക്ക് മാത്രം ആ നെയിംസ്പേസ് പങ്കിടാൻ അനുവദിക്കുക, തുടർന്ന് ഉടമയെ പിന്തുടരുന്നത് കണക്കിലെടുക്കുക: പോർട്ടുകൾ, localhost, DNS.
ഒരു ഹോസ്റ്റ്, രണ്ട് വർക്ക്ലോഡുകൾ, അവയെ വേർതിരിക്കുന്ന ഒരു ആവശ്യകത: ഒരു വാണിജ്യ VPN-ൽ നിന്ന് പുറത്തുവരേണ്ട ഡൗൺലോഡ് ക്ലയന്റ്, ഹോസ്റ്റിന്റെ കണക്ഷൻ തുടർന്നും ഉപയോഗിക്കേണ്ട മാനേജ്മെന്റ് ഇന്റർഫേസ്. VPN ക്ലയന്റ് ഹോസ്റ്റിൽ ഇൻസ്റ്റാൾ ചെയ്താൽ ആവശ്യകത ഉടൻ പരാജയപ്പെടും, കാരണം അപ്പോൾ രണ്ട് വർക്ക്ലോഡുകളും ഒരു എക്സിറ്റ് പങ്കിടുന്നു. യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന പാറ്റേൺ ടണൽ അതിന്റെ സ്വന്തം കണ്ടെയ്നറിലേക്ക് മാറ്റുകയും അത് ആവശ്യമുള്ള വർക്ക്ലോഡുകൾക്ക് മാത്രം ആ കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് നെയിംസ്പേസിൽ ചേരാൻ അനുവദിക്കുകയും ചെയ്യുക എന്നതാണ്. ബാക്കിയുള്ളതെല്ലാം സാധാരണ Docker പാത പിന്തുടരുന്നു, തുടർന്നുള്ള വിശദാംശങ്ങൾ നെയിംസ്പേസ് ആർക്കാണ് എന്നതിന്റെ അനന്തരഫലങ്ങളാണ്.
പങ്കിട്ട നെയിംസ്പേസ് നിയമങ്ങൾ എന്തുകൊണ്ട് മാറ്റുന്നു
മറ്റൊന്നിന്റെ നെയിംസ്പേസിൽ ചേരുന്ന കണ്ടെയ്നറിന് സ്വന്തം നെറ്റ്വർക്ക് സ്റ്റാക്ക് ലഭിക്കുന്നില്ല. അത് ചേർന്ന കണ്ടെയ്നറിന്റെ അതേ ഇന്റർഫേസുകൾ, അതേ റൂട്ടിംഗ് പട്ടിക, അതേ loopback എന്നിവ കാണുന്നു, അതുകൊണ്ടാണ് ഈ പാറ്റേൺ ഉപകാരപ്രദമാകുന്നത്: വർക്ക്ലോഡ് സാധാരണ രീതിയിൽ റിസോൾവ് ചെയ്ത് കണക്ട് ചെയ്യുന്നു, താഴെയുള്ള ടണൽ ആപ്ലിക്കേഷന് അറിയാതെ ട്രാഫിക് പിടിച്ചെടുക്കുന്നു. വില എന്നത് ഓരോ നെറ്റ്വർക്ക് സംബന്ധമായ ക്രമീകരണത്തിനും ഇപ്പോൾ ഒരു ഉടമ മാത്രമാണ് എന്നതും, ചേരുന്ന കണ്ടെയ്നർ അതല്ല എന്നതുമാണ്.
ഈ ഉടമസ്ഥാവകാശ നിയമം മിക്ക കോൺഫിഗറേഷൻ ചോദ്യങ്ങൾക്കും അവ ചോദിക്കുന്നതിന് മുമ്പേ ഉത്തരം നൽകുന്നു. ക്രമീകരണം നെറ്റ്വർക്ക് സ്റ്റാക്കിൽ ജീവിക്കുന്നെങ്കിൽ അത് സൈഡ്കാറിന്റേതാണ്. അത് പ്രക്രിയയെ വിവരിക്കുന്നെങ്കിൽ അത് വർക്ക്ലോഡിനൊപ്പം തുടരുന്നു.
loopback ആളുകളെ അത്ഭുതപ്പെടുത്തുന്ന ഭാഗമാണ്. ചേരുന്ന കണ്ടെയ്നറിനുള്ളിൽ, localhost സൈഡ്കാറിന്റെ loopback-ലേക്ക് റിസോൾവ് ചെയ്യുന്നു, സ്വന്തം സ്വകാര്യ ഒന്നിലേക്കല്ല, അതിനാൽ 127.0.0.1-ൽ ബന്ധിച്ച് ഒറ്റപ്പെടൽ പ്രതീക്ഷിക്കുന്ന സേവനം ഇപ്പോൾ ആ വിലാസം ടണൽ കണ്ടെയ്നറുമായി പങ്കിടുന്നു.
നെയിംസ്പേസ് ഉള്ള കണ്ടെയ്നറിൽ പോർട്ടുകൾ പ്രസിദ്ധീകരിക്കുക
പോർട്ട് മാപ്പിംഗ് നെയിംസ്പേസിന്റെ ഉടമയുടേതാണ്, കേൾക്കുന്ന പ്രക്രിയ മറ്റേ കണ്ടെയ്നറിൽ പ്രവർത്തിക്കുമ്പോഴും. മാപ്പിംഗ് സൈഡ്കാറിൽ പ്രഖ്യാപിക്കുക, വർക്ക്ലോഡ് അതിന്റെ പ്രക്രിയ കോൺഫിഗറേഷൻ മാറ്റമില്ലാതെ സൂക്ഷിക്കട്ടെ. ചേരുന്ന സേവനത്തിലെ മാപ്പിംഗിന് പ്രാബല്യത്തിൽ വരാൻ കഴിയില്ല, എഞ്ചിൻ അത് നിരസിച്ചാലും കണ്ടെയ്നർ എങ്ങനെ ആരംഭിക്കുന്നു എന്നതിന് അനുസരിച്ച് നിശ്ശബ്ദമായി അവഗണിച്ചാലും, അതുകൊണ്ടാണ് ഒരു നിമിഷം മുമ്പ് എത്താമായിരുന്ന ഇന്റർഫേസ് പാറ്റേൺ പ്രയോഗിച്ച ഉടൻ അപ്രത്യക്ഷമാകുന്നത്.
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]ഈ ബ്ലോക്ക് മൂന്ന് സേവനങ്ങളായല്ല, മൂന്ന് തീരുമാനങ്ങളായി വായിക്കുക. സൈഡ്കാർ ടണലും പ്രസിദ്ധീകരിച്ച പോർട്ടും ഉടമസ്ഥതയിലുള്ളതാണ്; ചേരുന്ന ക്ലയന്റ് ഒരു നെറ്റ്വർക്കും പ്രഖ്യാപിക്കുന്നില്ല; നേരിട്ടുള്ള ക്ലയന്റ് ഡിഫോൾട്ട് നെറ്റ്വർക്കിൽ സ്വന്തം മാപ്പിംഗ് സൂക്ഷിക്കുന്നു. കഴിവാണ് NET_ADMIN സൈഡ്കാറിന് ഇന്റർഫേസുകൾ സൃഷ്ടിക്കാനും റൂട്ടുകൾ മാറ്റാനും അനുവദിക്കുന്നത്, അതുകൊണ്ടാണ് ഈ കണ്ടെയ്നറിന് അത് സേവിക്കുന്ന വർക്ക്ലോഡുകളെക്കാൾ കൂടുതൽ പ്രത്യേകാവകാശങ്ങൾ ആവശ്യമായിരിക്കുന്നത്.
നേരിട്ട് തുടരുന്ന സേവനം അതിന്റെ സ്വന്തം നെറ്റ്വർക്ക് സൂക്ഷിക്കുന്നു
ടണലിലൂടെ പോകരുതാത്ത വർക്ക്ലോഡ് ഡിഫോൾട്ട് ബ്രിഡ്ജോ സ്വന്തം ഉപയോക്തൃ-നിർവചിത നെറ്റ്വർക്കോ സ്വന്തം പ്രസിദ്ധീകരിച്ച പോർട്ടും എക്സിറ്റും സഹിതം സൂക്ഷിക്കുന്നു. രണ്ട് കണ്ടെയ്നറുകൾക്ക് പേരിലൂടെ സംസാരിക്കാൻ അതിനെ സൈഡ്കാർ നെറ്റ്വർക്കിലേക്ക് ബന്ധിപ്പിക്കാൻ പ്രലോഭനമുണ്ട്, പക്ഷേ ആ ഒരു ചുവട് അതിന്റെ ട്രാഫിക് നിശ്ശബ്ദമായി ടണലിലേക്ക് മാറ്റുന്നു. അവ പരസ്പരം എത്തേണ്ടതുണ്ടെങ്കിൽ, വേറെ ഒരു ഉപയോക്തൃ-നിർവചിത നെറ്റ്വർക്ക് നിർമ്മിച്ച് രണ്ടിനെയും അതിലേക്ക് ബന്ധിപ്പിച്ച്, സൈഡ്കാറിനെ പുറത്തേക്കുള്ള ഏക വഴിയായി വിടുക.
രണ്ട് ചോദ്യങ്ങൾ വേർതിരിച്ച് നിർത്തുക: ഏത് കണ്ടെയ്നറുകൾക്ക് പരസ്പരം എത്താം, ഏതാണ് എവിടെ നിന്ന് പുറത്തുപോകുന്നത്. അവ കൂട്ടിച്ചേർക്കുന്നതാണ് ഈ രൂപകൽപ്പന വീണ്ടും മുഴുവൻ ഹോസ്റ്റ് വ്യാപിച്ചുള്ള VPN ആകുന്ന ഏറ്റവും സാധാരണ വഴി.
ആദ്യ മണിക്കൂറിനുള്ള പരാജയ മാട്രിക്സ്
മിക്ക ആദ്യ ശ്രമങ്ങളും നാലിൽ ഒരു വഴിയിൽ പരാജയപ്പെടുന്നു, ഓരോന്നിനും വ്യത്യസ്ത കാരണമുണ്ട്. ഈ ക്രമത്തിൽ അവ പരിശോധിക്കുക, കാരണം ആദ്യ രണ്ടെണ്ണം മിക്കവാറും എല്ലാ റിപ്പോർട്ടുകളും വിശദീകരിക്കുന്നു.
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
നാലാമത്തെ വരിയാണ് ആളുകൾ തെറ്റായി ആപ്ലിക്കേഷൻ ബഗ് എന്ന് രോഗനിർണയം ചെയ്യുന്നത്. വർക്ക്ലോഡിന്റെ സ്വന്തം loopback-നെതിരെ എഴുതിയ പരിശോധന ഇപ്പോൾ ടണൽ കണ്ടെയ്നറിനെ പരിശോധിക്കുന്നു, അതിനാൽ അത് പരാജയപ്പെടുകയോ തീർത്തും തെറ്റായ സേവനം റിപ്പോർട്ട് ചെയ്യുകയോ ചെയ്യുന്നു.
ഒരു ഹോസ്റ്റ്നാമിന് മാത്രം ടണൽ ആവശ്യമാകുമ്പോൾ
ചിലപ്പോൾ പൂർണ്ണ ടണൽ അധികമാണ്: ഒരു ആന്തരിക നാമം കോർപ്പറേറ്റ് VPN വഴി പോകണം, അതേസമയം പ്രാദേശിക സോക്കറ്റോ ഡിസ്പ്ലേ കണക്ഷനോ പ്രവർത്തിക്കുന്നു. കണ്ടെയ്നറിനുള്ളിലെ പൂർണ്ണ ടണൽ ആ പാതയും ഹോസ്റ്റിലേക്ക് അഭിസംബോധന ചെയ്തതെല്ലാം തകർക്കുന്നു, അതിനാൽ ആവശ്യമുള്ള പ്രിഫിക്സ് മാത്രം റൂട്ട് ചെയ്യുക. ക്ലയന്റിന് ചുറ്റുമുള്ള വിഭജിത റൂട്ടിംഗ് റാപ്പർ അത് ചെയ്യുന്നു, പേരിട്ട ഹോസ്റ്റിനെ ടണലിലൂടെ അയച്ച് ബാക്കിയെല്ലാത്തിനും മുൻ റൂട്ട് മാറ്റമില്ലാതെ വിടുന്നു.
ഒരു സേവനത്തിൽ മാത്രം എത്തേണ്ടതുണ്ടെങ്കിൽ, കണ്ടെയ്നറിന്റെ എല്ലാ ട്രാഫിക്കും മാറ്റാൻ ശ്രമിക്കുന്നില്ലെങ്കിൽ ഇത് തിരഞ്ഞെടുക്കുക. ഇത് സൈഡ്കാറിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു ഉപകരണമാണ്, വ്യത്യസ്തമായ ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.
പരിശോധിച്ച്, പിന്നെ അതിനെ റീസ്റ്റാർട്ട് അതിജീവിക്കുന്നതാക്കുക
ഓരോ കണ്ടെയ്നറിനോടും ഏത് വിലാസത്തിൽ നിന്നാണ് വരുന്നതായി തോന്നുന്നതെന്ന് ചോദിക്കുക. ടണലിലുള്ളത് ദാതാവിന്റെ വിലാസവും നേരിട്ടുള്ളത് ഹോസ്റ്റിന്റെ എക്സിറ്റും പ്രിന്റ് ചെയ്യണം. ഒരേ ഉത്തരങ്ങൾ എന്നാൽ നേരിട്ടുള്ള സേവനം തെറ്റായ നെയിംസ്പേസ് കൈവശപ്പെടുത്തി എന്നോ ഹോസ്റ്റ് തലത്തിലുള്ള VPN ഇപ്പോഴും എല്ലാം പിടിക്കുന്നു എന്നോ ആണ്, ആ രണ്ട് പരിഹാരങ്ങൾ വ്യത്യസ്തമാണ്. ഓരോ compose മാറ്റത്തിനും ശേഷം പരിശോധന വീണ്ടും പ്രവർത്തിപ്പിക്കുക, കാരണം ഒരു പകർത്തിയ സേവന ബ്ലോക്ക് പ്രശ്നം തിരികെ കൊണ്ടുവരാൻ മതിയാകും.
മൂന്ന് കാര്യങ്ങൾ പിന്നീട് തകരാൻ സാധ്യതയുണ്ട്. DNS നെയിംസ്പേസിന്റെ ഉടമയെ പിന്തുടരുന്നു, അതിനാൽ റിസോൾവറും സെർച്ച് ഡൊമെയ്നും ഹോസ്റ്റിലല്ല, സൈഡ്കാറിൽ ആയിരിക്കണം. പോർട്ട് ഫോർവേഡിംഗുള്ള VPN വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ അതിന്റെ കേൾക്കുന്ന പോർട്ട് മാറ്റുന്നു, അതിനാൽ ദാതാവിന്റെ ഫോർവേഡ് ചെയ്ത പോർട്ടും കണ്ടെയ്നർ ഭാഗത്തെ കേൾക്കുന്ന പോർട്ടും ക്ലയന്റ് കോൺഫിഗറേഷനിലേക്കോ പോർട്ട് മാപ്പിംഗിലേക്കോ തിരികെ എഴുതണം, സാധാരണയായി ദാതാവിന്റെ API വായിക്കുന്ന ഒരു ചെറിയ അപ്ഡേറ്റർ വഴി. കൂടാതെ localhost എതിരെ എഴുതിയ ഏത് പരിശോധനയും ഇപ്പോൾ വർക്ക്ലോഡിനെയല്ല, ടണൽ കണ്ടെയ്നറിനെയാണ് ചോദിക്കുന്നത്.
പാറ്റേൺ എഴുതി വയ്ക്കുക, ഏത് കണ്ടെയ്നർ നെയിംസ്പേസ് ഉള്ളതും ഏത് പോർട്ടുകൾ അതിന്റേതാണ് എന്നതും ഉൾപ്പെടെ. അടുത്ത ആൾ ഒരു സേവനം ചേർക്കും, തെറ്റായ ബ്ലോക്ക് പകർത്തും, ഈ ലേഖനത്തിലെ ആദ്യ പരാജയം പുനരാവിഷ്കരിക്കും.