Docker: drejto një kontejner përmes VPN dhe mbaj një tjetër direkt

Një host, dy ngarkesa pune dhe një kërkesë që i ndan: një klient shkarkimi që duhet të dalë përmes një VPN komerciale dhe një ndërfaqe administrimi që duhet të vazhdojë të përdorë lidhjen e hostit. Instalimi i klientit VPN në host e shkel kërkesën menjëherë, sepse atëherë të dyja ngarkesat ndajnë një dalje të vetme. Modeli që funksionon vërtet është të zhvendoset tuneli në kontejnerin e vet dhe të lejohen vetëm ngarkesat që e kanë nevojë të bashkohen me hapësirën e emrave të rrjetit të atij kontejneri. Gjithçka tjetër mban rrugën e zakonshme të Docker, dhe detajet që vijojnë janë pasoja të kujt e zotëron hapësirën e emrave.

Pse një hapësirë emrash e përbashkët i ndryshon rregullat

Një kontejner që bashkohet me hapësirën e emrave të një tjetri nuk merr stivën e vet të rrjetit. Ai sheh të njëjtat ndërfaqe, të njëjtën tabelë rrugëtimi dhe të njëjtin loopback si kontejneri të cilit iu bashkua, dhe pikërisht për këtë modeli është i dobishëm: ngarkesa zgjidh dhe lidhet normalisht, dhe tuneli poshtë saj e kap trafikun pa e ditur aplikacioni. Kostoja është se çdo rregullim i rrjetit tani ka një pronar të vetëm, dhe kontejneri që bashkohet nuk është ai.

Ky rregull pronësie u përgjigjet shumicës së pyetjeve të konfigurimit para se ato të bëhen. Nëse një rregullim jeton në stivën e rrjetit, i takon kontejnerit anësor. Nëse përshkruan procesin, mbetet me ngarkesën.

Loopback është pjesa që i befason njerëzit. Brenda kontejnerit që bashkohet, localhost zgjidhet në loopback-un e kontejnerit anësor, jo në një privat të vetin, kështu që një shërbim që lidhet me 127.0.0.1 duke pritur izolim tani e ndan atë adresë me kontejnerin e tunelit.

Publikoni portat në kontejnerin që zotëron hapësirën e emrave

Hartëzimi i portave i takon pronarit të hapësirës së emrave, edhe kur procesi që dëgjon ekzekutohet në kontejnerin tjetër. Deklaroni hartëzimin në kontejnerin anësor, dhe lëreni ngarkesën ta mbajë konfigurimin e vet të procesit të paprekur. Një hartëzim në shërbimin që bashkohet nuk mund të hyjë në fuqi, qoftë kur motori e refuzon, qoftë kur e injoron në heshtje sipas mënyrës se si niset kontejneri, dhe për këtë një ndërfaqe që ishte e arritshme një çast më parë zhduket sapo zbatohet modeli.

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"]

Lexojeni atë bllok si tri vendime, jo si tri shërbime. Kontejneri anësor zotëron tunelin dhe portën e publikuar; klienti që bashkohet nuk deklaron asnjë rrjet; klienti direkt mban një hartëzim të vetin në rrjetin e paracaktuar. Aftësia NET_ADMIN është ajo që i lejon kontejnerit anësor të krijojë ndërfaqe dhe të ndryshojë rrugët, dhe është arsyeja pse ky kontejner kërkon më shumë privilegje sesa ngarkesat që shërben.

Shërbimi që mbetet direkt mban rrjetin e vet

Ngarkesa që nuk duhet të kalojë përmes tunelit mban urën e paracaktuar ose një rrjet të vetë përcaktuar nga përdoruesi, me portën e vet të publikuar dhe daljen e vet. Është joshëse ta lidhësh me rrjetin e kontejnerit anësor që dy kontejnerët të mund të flasin me emër, por ai hap i vetëm e zhvendos trafikun e saj në heshtje në tunel. Nëse duhet të arrijnë njëri-tjetrin, ndërtoni një rrjet të veçantë të përcaktuar nga përdoruesi, lidhni të dy me të, dhe lini kontejnerin anësor si rrugën e vetme nga jashtë.

Mbajini dy pyetjet të ndara: cilët kontejnerë mund të arrijnë njëri-tjetrin, dhe cili del nga ku. Bashkimi i tyre është mënyra më e zakonshme me të cilën ky dizajn kthehet përsëri në një VPN për të gjithë hostin.

Një matricë dështimesh për orën e parë

Shumica e përpjekjeve të para dështojnë në një nga katër mënyra, dhe secila ka një shkak të ndryshëm. Kontrollojini në këtë rend, sepse dy të parat shpjegojnë pothuajse çdo raport.

Rreshti i katërt është ai që njerëzit e diagnostikojnë gabimisht si një bug aplikacioni. Një provë e shkruar kundër loopback-ut të vetë ngarkesës tani po teston kontejnerin e tunelit, kështu që ose dështon ose raporton një shërbim plotësisht të gabuar.

Kur një emër i vetëm hosti ka nevojë për tunelin

Ndonjëherë një tunel i plotë është tepër: një emër i brendshëm duhet të kalojë përmes një VPN korporative ndërsa një socket lokal ose një lidhje ekrani vazhdon të funksionojë. Një tunel i plotë brenda kontejnerit e thyen atë rrugë dhe çdo gjë që i drejtohet hostit, prandaj drejtoni vetëm prefiksin që ka nevojë. Një mbështjellës i rrugëtimit të ndarë rreth klientit e bën këtë, duke e dërguar hostin e emërtuar përmes tunelit dhe duke e lënë rrugën e mëparshme të paprekur për gjithçka tjetër.

Zgjidhni këtë kur duhet të arrini vetëm një shërbim dhe nuk po përpiqeni të zhvendosni të gjithë trafikun e kontejnerit. Është një mjet tjetër nga kontejneri anësor dhe përgjigjet një pyetjeje tjetër.

Verifikoni, pastaj bëjeni t'i mbijetojë një rinisjeje

Pyetni çdo kontejner nga cila adresë duket se vjen. Ai në tunel duhet të shtypë adresën e ofruesit dhe ai direkt daljen e hostit. Përgjigjet identike nënkuptojnë që shërbimi direkt trashëgoi hapësirën e gabuar të emrave ose që një VPN në nivel hosti vazhdon ta kapë gjithçka, dhe ato dy korrigjime janë të ndryshme. Ekzekutoni kontrollin përsëri pas çdo redaktimi të compose, sepse një bllok shërbimi i kopjuar mjafton për ta rikthyer problemin.

Tri gjëra priren të prisheshin më vonë. DNS ndjek pronarin e hapësirës së emrave, prandaj rregullimet e zgjidhësit dhe të domenit të kërkimit i takojnë kontejnerit anësor, jo hostit. Një VPN me përcjellje portash e ndryshon portën e dëgjimit gjatë rilidhjes, prandaj porta e përcjellë e ofruesit dhe porta e dëgjimit në anën e kontejnerit duhet të shkruhen përsëri në konfigurimin e klientit ose në hartëzimin e portave, zakonisht nga një përditësues i vogël që lexon API-n e ofruesit. Dhe çdo provë e shkruar kundër localhost tani pyet kontejnerin e tunelit, jo ngarkesën.

Shkruajeni modelin, duke përfshirë cili kontejner zotëron hapësirën e emrave dhe cilat porta i takojnë. Personi tjetër do të shtojë një shërbim, do të kopjojë bllokun e gabuar dhe do të riprodhojë dështimin e parë në këtë artikull.