કન્ટેનર ફક્ત VPN વાળા API સુધી પહોંચી શકતું નથી? હોસ્ટ પર પ્રોક્સી કરો

તમારી Compose સેવા એવા API સામે સમયસીમા વટાવે છે જે એ જ મશીનનું બ્રાઉઝર કોઈ ફરિયાદ વગર ખોલે છે. એ ફરક જ સંકેત છે: જે વિનંતી કામ કરે છે તે 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 માં લખો. નહીં તો આ સમયસીમા સાથે અથડાતી આગળની વ્યક્તિ એ જ બપોર ટનલ હોસ્ટ પર રહે છે તે ફરીથી શોધવામાં ગાળશે.