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 க்கு எதிராக எழுதப்பட்ட எந்த ஆய்வும் இப்போது பணிச்சுமையை அல்ல, சுரங்கப்பாதை கொள்கலனைக் கேட்கிறது.
முறையை எழுதி வையுங்கள், எந்தக் கொள்கலன் பெயர்வெளியைக் கொண்டுள்ளது மற்றும் எந்தத் துறைமுகங்கள் அதற்குச் சொந்தம் என்பதையும் சேர்த்து. அடுத்த நபர் ஒரு சேவையைச் சேர்ப்பார், தவறான தொகுதியை நகலெடுப்பார், இந்தக் கட்டுரையின் முதல் தோல்வியை மீண்டும் உருவாக்குவார்.