கன்டெய்னர் VPN-மட்டும் API-ஐ அடையவில்லையா? அதை ஹோஸ்ட்டில் ப்ராக்ஸி செய்யுங்கள்

ஒரே இயந்திரத்தில் உள்ள உலாவி எந்தப் புகாரும் இல்லாமல் திறக்கும் API-க்கு எதிராக உங்கள் Compose சேவை நேரம் முடிந்துவிடுகிறது. அந்த வேறுபாடே துப்பு: வேலை செய்யும் கோரிக்கை VPN சுரங்கப்பாதை உள்ள ஹோஸ்ட்டிலிருந்து வெளியேறுகிறது, தொங்கும் கோரிக்கை தனது சொந்த பிணைய அடுக்கைக் கொண்ட கன்டெய்னரிலிருந்து வெளியேறுகிறது. கன்டெய்னருக்குள் எதுவும் சுரங்கப்பாதையின் வழிகளை அறியாது, எனவே பெயர் எப்படி எழுதப்பட்டாலும் தனிப்பட்ட இலக்கு அடைய முடியாததாகவே இருக்கும். தீர்வு ஹோஸ்ட் வழியாக வேண்டுமென்றே செய்யப்படும் தாவல், இன்னும் புத்திசாலித்தனமான வழி அட்டவணை அல்ல.

இரண்டு பாதைகள் ஏன் வேறுபடுகின்றன என்பதில் தொடங்கி, பின்னர் சுரங்கப்பாதை எங்கு வாழ வேண்டும் என்பதை முடிவு செய்யுங்கள்.

ஹோஸ்ட் ஏன் வேலை செய்கிறது, கன்டெய்னர் ஏன் செய்யவில்லை

சுரங்கப்பாதையை உயர்த்துவது ஹோஸ்ட்டுக்கு ஒரு இடைமுகம், வழிகளின் தொகுப்பு மற்றும் பொதுவாக VPN வழங்கும் தீர்வி பதிவைத் தருகிறது. கன்டெய்னர் அதிலிருந்து எதையும் மரபுரிமையாகப் பெறுவதில்லை: இது இயந்திரத்தின் பாலத்தில் ஒரு இடைமுகத்துடனும் அந்தப் பாலத்தை நோக்கும் இயல்புநிலை வழியுடனும் தொடங்குகிறது. ஹோஸ்ட்டில் நிறுவப்பட்ட வழிகள் அந்தப் பெயர்வெளிக்குள் இயங்கும் எதற்கும் தெரியாது.

அதனால்தான் அறிகுறிகள் வெறுமனே உடைந்ததாக அல்ல, முரண்பாடாகத் தெரிகின்றன. ஹோஸ்ட் தனிப்பட்ட பெயரைத் தீர்த்து இணைக்கிறது, ஏனெனில் அங்கே பெயரும் வழியும் இரண்டும் உள்ளன. கன்டெய்னர் தனது பொதியை பால வழியில் எதுவும் அடைய முடியாத தனிப்பட்ட முகவரிக்கு அனுப்புகிறது, கோரிக்கை நேரம் முடிகிறது. கன்டெய்னரின் hosts கோப்பில் பெயரைச் சேர்ப்பது எதையும் மாற்றாது, ஏனெனில் முகவரியே கன்டெய்னர் இருக்கும் இடத்திலிருந்து அடைய முடியாதது.

கன்டெய்னருக்குள் இருந்து ஹோஸ்ட்டை அடையுங்கள்

கன்டெய்னரில் உள்ள ஒரு செயல்முறை localhost ஐ அழைத்தால் அது கன்டெய்னரையே அழைக்கிறது. Docker Desktop host.docker.internal ஐ இயந்திரத்தை இயக்கும் கணினியை நோக்கித் திரும்பும் பெயராக வெளியிடுகிறது; Linux இயந்திரங்கள் சேவை கேட்காத வரை அதை வரையறுக்கப்படாததாக விடுகின்றன, கீழே உள்ள மேப்பிங் அதையே செய்கிறது. அதனால் பயன்பாடு தனிப்பட்ட முகவரிக்குப் பதிலாக ஒரு பெயரையும் துறையையும் இலக்காகக் கொள்கிறது.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

சுரங்கப்பாதை தாவலின் ஹோஸ்ட் பக்கத்திலேயே இருக்கும், அந்த மாறியில் உள்ள துறை ப்ராக்ஸி கேட்கும் துறை. சுரங்கப்பாதையை இழக்கும் கன்டெய்னர் இப்போது எப்போதும் இல்லாத வழியை முயற்சிப்பதற்குப் பதிலாக ஒரு தெரிந்த தாவலில் தோல்வியடைகிறது.

சுரங்கப்பாதை எங்கு வாழ்கிறது என்பதைத் தேர்ந்தெடுக்கவும்

தனிப்பட்ட API தேவைப்படும் Compose சேவைக்கு மூன்று வடிவங்கள் சாத்தியம், அவை எந்தச் செயல்முறை சுரங்கப்பாதையைக் கொண்டுள்ளது என்பதில் வேறுபடுகின்றன. VPN கிளையண்ட் கன்டெய்னர் படத்திற்குள் இயங்கலாம், அதற்கு சுரங்கப்பாதை சாதனத்தை வெளிப்படுத்தி அதனுடன் வரும் பிணைய நிர்வாக திறனை வழங்க வேண்டும். பயன்பாடு தனி சுரங்கப்பாதை கன்டெய்னரின் பிணைய பெயர்வெளியைப் பகிரலாம், அப்போது இரண்டு செயல்முறைகளும் ஒரு அடுக்கையும் ஒரு வழி அட்டவணையையும் காண்கின்றன. அல்லது சுரங்கப்பாதை ஹோஸ்ட்டிலேயே இருக்கலாம், ஹோஸ்ட்டிலிருந்து கன்டெய்னருக்கு ஒரு குறுகிய அனுப்பியுடன்.

முதல் இரண்டு சுயவிவர கோப்புகள், மறு இணைப்பு நடத்தை மற்றும் தீர்வி கொள்கையை திட்டத்திற்குள் இழுத்து, கோப்பில் உள்ள ஒவ்வொரு சேவையையும் சுரங்கப்பாதையின் ஆரோக்கியத்தைச் சார்ந்ததாக்குகின்றன. ஒரு API அழைப்புக்கு இது அதிக இணைப்பு. ஒரே ஒரு உள் முனைப்புள்ளியைப் படிக்கும் மேம்பாட்டு அடுக்குக்கு ஹோஸ்ட் பக்க அனுப்பி மிகச் சிறிய மாற்றம், மேலும் சான்றுகளை மேடைக் குழு நிர்வகிக்கும் இடத்திலேயே வைத்திருக்கிறது.

ஹோஸ்ட்டில் ஒரே குறுகிய பாதையை வெளியிடுங்கள்

அனுப்பி மரபுரிமையாகப் பெறுவதிலிருந்து தொடங்குங்கள்: சுரங்கப்பாதையைக் கொண்ட கணக்கின் கீழ் அதை இயக்குங்கள், அப்போது அதன் வெளிச்செல்லும் சாக்கெட்டுகள் ஹோஸ்ட்டின் வழிகளையும் ஹோஸ்ட்டின் தீர்வியையும் எடுத்துக்கொள்ளும். nginx இன் ஒரு location தொகுதி ஒரு பாதையை உள்ளடக்கும்.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

முகவரியையும் துறையையும் தற்காலிகமாகக் கருதி API உண்மையில் கேட்கும் இணையை இடுங்கள். ஒவ்வொரு கூடுதல் upstream உம் அதன் சொந்த location தொகுதிக்கு உரியது, ஒவ்வொரு தொகுதியும் இந்தச் சேவை அழைக்கும் பாதைகளை மட்டுமே அனுமதிக்க வேண்டும், இல்லையேல் ப்ராக்ஸி தனிப்பட்ட பிணையத்திற்குள் ஒரு பொது கதவாகிவிடும். host-gateway வழியாக வரும் வாடிக்கையாளர்களுக்கு கேட்பியை பால முகவரியிலும், வாடிக்கையாளர் ஹோஸ்ட்டின் பிணைய பெயர்வெளியைப் பகிரும்போது மட்டும் loopback இலும் பிணைக்கவும், ஒருபோதும் 0.0.0.0 இல் பிணைக்க வேண்டாம். இன்னும் காலியாக உள்ள துறையையும் தேர்ந்தெடுங்கள்: ஏற்கனவே எடுக்கப்பட்ட எண் ப்ராக்ஸி கேட்காமல் விட்டுவிடும், கன்டெய்னர் தொடர்ந்து நேரம் முடிந்துகொண்டே இருக்கும், இதை நீங்கள் தொடங்கிய பிணைய குறையிலிருந்து வேறுபடுத்த முடியாது.

துறைகள், பெயர்கள் மற்றும் TLS முடிவு

பெயர் தீர்வு வழிமாற்றம் போலவே பிரிகிறது. கன்டெய்னரின் பொது தேடல்கள் இயந்திரத்தின் தீர்வி வழியாகச் செல்கின்றன, எனவே ஹோஸ்ட்டில் தீர்க்கப்படும் தனிப்பட்ட பெயர் கன்டெய்னருக்குள் தீர்க்கப்படாது. தனிப்பட்ட பெயரைத் தீர்ப்பது ப்ராக்ஸியே, ஏனெனில் அது ஹோஸ்ட்டின் தீர்வியை மரபுரிமையாகப் பெறுகிறது.

TLS என்பது தள்ளிப்போடப்பட்டு பின்னர் அடுத்த தோல்வியை விளக்கும் முடிவு. ப்ராக்ஸி பைட்டுகளைத் தொடாமல் அனுப்பினால், கன்டெய்னர் API இன் சொந்த சான்றிதழைக் காண்கிறது, அதன் நம்பிக்கைக் கிடங்கில் உள் CA தேவைப்படுகிறது. ப்ராக்ஸி TLS ஐ முடித்தால், அந்த நம்பிக்கை ஹோஸ்ட்டுக்குச் செல்கிறது, பயன்பாடு பெறும் host தலைப்பிலிருந்து இணைப்புகளை உருவாக்கத் தொடங்குகிறது. ஒரே ஏற்பாட்டைத் தேர்ந்தெடுத்து ஒவ்வொரு வளத்திற்கும் பயன்படுத்துங்கள், ஏனெனில் மற்றது வழங்கும் திசைதிருப்பல் கன்டெய்னர் தீர்க்க முடியாத ஹோஸ்ட் பெயரை நோக்கிச் செல்கிறது.

சேவைக்குள் இருந்து சரிபார்க்கவும்

கோரிக்கையை ஹோஸ்ட்டிலிருந்து அல்ல, கன்டெய்னரிலிருந்து அனுப்புங்கள்: ப்ராக்ஸி பாதையில் ஒரு சாதாரண curl, பின்னர் பயன்பாட்டின் சொந்த ஆரோக்கியச் சோதனை. ப்ராக்ஸி பதிலளித்தும் பயன்பாடு இன்னும் தோல்வியடைந்தால், மூன்று விஷயங்களை ஒப்பிடுங்கள்: அது உருவாக்கும் அடிப்படை URL, அதன் சூழலில் உள்ள எந்தப் ப்ராக்ஸி மாறியும், அது நம்பும் CA. அனைத்தும் கன்டெய்னரின் சூழலிலும் பதிவுகளிலும் உள்ளன, அவற்றில் எதையாவது சரிசெய்வது VPN ஐத் தொடாமல் விடும்.

தேர்ந்தெடுத்த ஏற்பாட்டை புதியதாக இருக்கும்போதே திட்டத்தின் README இல் எழுதுங்கள். இல்லையேல் இந்த நேர முடிவைச் சந்திக்கும் அடுத்த நபர் சுரங்கப்பாதை ஹோஸ்ட்டில் வாழ்கிறது என்பதை மீண்டும் கண்டுபிடிப்பதில் அதே பிற்பகலைக் கழிப்பார்.