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