Docker: send én container gennem en VPN og hold en anden direkte

Én vært, to arbejdsbelastninger og et krav, der skiller dem: en downloadklient, der skal ud gennem en kommerciel VPN, og en administrationsgrænseflade, der skal blive ved med at bruge værtens forbindelse. Installerer man VPN-klienten på værten, fejler kravet med det samme, fordi begge arbejdsbelastninger så deler én udgang. Det mønster, der faktisk virker, er at flytte tunnelen ind i sin egen container og kun lade de arbejdsbelastninger, der har brug for den, tilslutte sig den containers netværksnavnerum. Alt andet beholder den almindelige Docker-vej, og detaljerne, der følger, er konsekvenser af, hvem der ejer navnerummet.

Hvorfor et delt navnerum ændrer reglerne

En container, der tilslutter sig en andens navnerum, får ikke sin egen netværksstak. Den ser de samme grænseflader, den samme rutetabel og det samme loopback som den container, den tilsluttede sig, og det er netop derfor, mønstret er nyttigt: arbejdsbelastningen opløser og forbinder normalt, og tunnelen nedenunder fanger trafikken, uden at applikationen ved det. Prisen er, at hver netværksindstilling nu har én ejer, og den tilsluttende container er ikke den ejer.

Den ejerskabsregel besvarer de fleste konfigurationsspørgsmål, før de stilles. Hvis en indstilling lever i netværksstakken, hører den til sidecar-containeren. Hvis den beskriver processen, bliver den hos arbejdsbelastningen.

Loopback er den del, der overrasker folk. Inde i den tilsluttende container opløses localhost til sidecar-containerens loopback, ikke til en privat af dens egen, så en tjeneste, der binder til 127.0.0.1 i forventning om isolering, nu deler den adresse med tunnelcontaineren.

Udgiv porte på den container, der ejer navnerummet

Portmappingen tilhører navnerummets ejer, selv når den lyttende proces kører i den anden container. Erklær mappingen på sidecar-containeren, og lad arbejdsbelastningen beholde sin egen proceskonfiguration urørt. En mapping på den tilsluttende tjeneste kan ikke træde i kraft, uanset om motoren afviser den eller stiltiende ignorerer den afhængigt af, hvordan containeren startes, og derfor forsvinder en grænseflade, der var tilgængelig for et øjeblik siden, så snart mønstret anvendes.

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

Læs den blok som tre beslutninger i stedet for tre tjenester. Sidecar-containeren ejer tunnelen og den udgivne port; den tilsluttende klient erklærer slet intet netværk; den direkte klient beholder en mapping af sin egen på standardnetværket. Evnen NET_ADMIN er det, der lader sidecar-containeren oprette grænseflader og ændre ruter, og det er grunden til, at denne container har brug for flere rettigheder end de arbejdsbelastninger, den betjener.

Tjenesten, der forbliver direkte, beholder sit eget netværk

Den arbejdsbelastning, der ikke må gå gennem tunnelen, beholder standardbroen eller et eget brugerdefineret netværk med sin egen udgivne port og sin egen udgang. Det er fristende at koble den til sidecar-containerens netværk, så de to containere kan tale sammen ved navn, men det ene skridt flytter stiltiende dens trafik ind i tunnelen. Hvis de skal nå hinanden, byg et separat brugerdefineret netværk, kobl begge til det, og lad sidecar-containeren være den eneste vej ud.

Hold de to spørgsmål adskilt: hvilke containere der kan nå hinanden, og hvilken der går ud hvor. At slå dem sammen er den mest almindelige måde, dette design bliver til en VPN for hele værten igen.

En fejlmatrix for den første time

De fleste første forsøg fejler på en af fire måder, og hver har en forskellig årsag. Kontroller dem i denne rækkefølge, fordi de første to forklarer næsten hver rapport.

Den fjerde række er den, folk fejldiagnosticerer som en programfejl. En probe, der blev skrevet mod arbejdsbelastningens eget loopback, tester nu tunnelcontaineren, så den fejler enten eller rapporterer en helt forkert tjeneste.

Når et enkelt værtsnavn har brug for tunnelen

Nogle gange er en fuld tunnel for meget: ét internt navn skal gennem en virksomheds-VPN, mens en lokal socket eller displayforbindelse bliver ved med at virke. En fuld tunnel inde i containeren bryder den vej og alt, der er adresseret til værten, så rut kun det præfiks, der har brug for det. En split-routing-indpakning omkring klienten gør det, sender det navngivne værtsnavn gennem tunnelen og lader den tidligere rute være urørt for alt andet.

Vælg dette, når du kun skal nå én tjeneste og ikke forsøger at flytte al containerens trafik. Det er et andet værktøj end sidecar-containeren, og det besvarer et andet spørgsmål.

Bekræft, og gør det så overlevelsesdygtigt over for en genstart

Spørg hver container, hvilken adresse den ser ud til at komme fra. Den tunnelerede bør udskrive udbyderens adresse, og den direkte bør udskrive værtens udgang. Identiske svar betyder, at den direkte tjeneste har arvet det forkerte navnerum, eller at en VPN på værtsniveau stadig fanger alt, og de to rettelser er forskellige. Kør kontrollen igen efter hver compose-redigering, fordi én kopieret tjenesteblok er nok til at genindføre problemet.

Tre ting plejer at gå i stykker senere. DNS følger navnerummets ejer, så resolver- og søgedomæneindstillinger hører til sidecar-containeren frem for værten. En port-forwardet VPN skifter sin lyttende port ved genopkobling, så udbyderens videresendte port og containerens lyttende port skal skrives tilbage i klientkonfigurationen eller portmappingen, normalt af en lille opdatering, der læser udbyderens API. Og enhver probe, der er skrevet mod localhost, spørger nu tunnelcontaineren i stedet for arbejdsbelastningen.

Skriv mønstret ned, inklusive hvilken container der ejer navnerummet, og hvilke porte der hører til det. Den næste person tilføjer en tjeneste, kopierer den forkerte blok og genskaber den første fejl i denne artikel.