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 સેવાને પોતાનું સરનામું કેમ નથી તેનો પણ સમાવેશ થાય છે.