Docker: usmerite eno vsebnik v VPN in pustite drugega neposredno

En gostitelj, dve delovni obremenitvi in zahteva, ki ju ločuje: odjemalec za prenašanje, ki mora izhajati skozi komercialni VPN, in vmesnik za upravljanje, ki mora še naprej uporabljati povezavo gostitelja. Namestitev odjemalca VPN na gostitelja zahtevo takoj prekrši, saj si takrat obe obremenitvi delita en izhod. Vzorec, ki resnično deluje, je premakniti tunel v lasten vsebnik in dovoliti samo tistim obremenitvam, ki ga potrebujejo, da se pridružijo imenskemu prostoru omrežja tega vsebnika. Vse ostalo obdrži običajno pot Dockerja, podrobnosti, ki sledijo, pa so posledice tega, kdo ima imenski prostor.

Zakaj si deljeni imenski prostor spreminja pravila

Vsebnik, ki se pridruži imenskemu prostoru drugega, ne dobi lastnega omrežnega sklada. Vidi iste vmesnike, isto usmerjevalno tabelo in isti loopback kot vsebnik, h kateremu se je pridružil, in prav zato je vzorec uporaben: obremenitev običajno razrešuje in se povezuje, tunel pod njo pa prestreže promet, ne da bi aplikacija to vedela. Cena je, da ima vsaka omrežna nastavitev zdaj enega lastnika, vsebnik, ki se pridruži, pa to ni.

To pravilo lastništva odgovori na večino vprašanj o konfiguraciji, preden so postavljena. Če nastavitev živi v omrežnem skladu, pripada stranskemu vsebniku. Če opisuje proces, ostane pri obremenitvi.

Loopback je del, ki ljudi preseneti. Znotraj vsebnika, ki se pridruži, se localhost razreši v loopback stranskega vsebnika, ne v lastnega zasebnega, zato si storitev, ki se veže na 127.0.0.1 in pričakuje izolacijo, zdaj deli ta naslov z vsebnikom tunela.

Objavite vrata na vsebniku, ki ima imenski prostor

Preslikava vrat pripada lastniku imenskega prostora, tudi ko poslušajoči proces teče v drugem vsebniku. Razglasite preslikavo na stranskem vsebniku in pustite obremenitvi, da ohrani lastno konfiguracijo procesa nedotaknjeno. Preslikava na storitvi, ki se pridruži, ne more začeti veljati, ne glede na to, ali jo pogon zavrne ali jo glede na način zagona vsebnika tiho prezre, in zato vmesnik, ki je bil pred trenutkom dosegljiv, izgine takoj, ko se vzorec uporabi.

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

Berite ta blok kot tri odločitve, ne kot tri storitve. Stranski vsebnik ima tunel in objavljena vrata; odjemalec, ki se pridruži, ne razglasi nobenega omrežja; neposredni odjemalec obdrži lastno preslikavo v privzetem omrežju. Zmožnost NET_ADMIN je tisto, kar stranskemu vsebniku omogoča ustvarjanje vmesnikov in spreminjanje poti, in zato ta vsebnik potrebuje več pravic kot obremenitve, ki jih oskrbuje.

Storitev, ki ostane neposredna, obdrži lastno omrežje

Obremenitev, ki ne sme iti skozi tunel, obdrži privzeti most ali lastno omrežje, ki ga določi uporabnik, z lastnimi objavljenimi vrati in lastnim izhodom. Mikavno je, da bi jo priključili na omrežje stranskega vsebnika, da bi se vsebnika lahko pogovarjala po imenu, vendar ta en korak tiho premakne njen promet v tunel. Če se morata doseči, zgradite ločeno omrežje, ki ga določi uporabnik, priključite oba nanj in pustite stranski vsebnik kot edino pot navzven.

Držite vprašanji ločeni: kateri vsebniki se lahko dosežejo in kateri kam izhaja. Njuna združitev je najpogostejši način, da se ta zasnova spet spremeni v VPN za celega gostitelja.

Matrika napak za prvo uro

Večina prvih poskusov spodleti na enega od štirih načinov, vsak pa ima drugačen vzrok. Preverite jih v tem vrstnem redu, saj prva dva pojasnita skoraj vsako poročilo.

Četrta vrstica je tista, ki jo ljudje napačno diagnosticirajo kot napako aplikacije. Preizkus, napisan proti lastnemu loopbacku obremenitve, zdaj preizkuša vsebnik tunela, zato bodisi spodleti bodisi poroča popolnoma napačno storitev.

Ko eno ime gostitelja potrebuje tunel

Včasih je polni tunel preveč: eno notranje ime mora iti skozi podjetniški VPN, medtem ko lokalna vtičnica ali zaslonska povezava še deluje. Polni tunel znotraj vsebnika zlomi to pot in vse, kar je naslovljeno na gostitelja, zato usmerjajte samo predpono, ki to potrebuje. Ovoj s split-routing okoli odjemalca to stori, pošlje imenovanega gostitelja skozi tunel in prejšnjo pot pusti nedotaknjeno za vse drugo.

Izberite to, ko morate doseči samo eno storitev in ne poskušate premakniti vsega prometa vsebnika. To je drugo orodje kot stranski vsebnik in odgovarja na drugo vprašanje.

Preverite in nato poskrbite, da bo prestalo ponovni zagon

Vprašajte vsak vsebnik, s katerega naslova se zdi, da prihaja. Tisti v tunelu bi moral izpisati naslov ponudnika, neposredni pa izhod gostitelja. Enaki odgovori pomenijo, da je neposredna storitev podedovala napačen imenski prostor ali da VPN na ravni gostitelja še vedno prestreže vse, in ta dva popravka sta različna. Znova zaženite preverjanje po vsaki spremembi compose, saj en kopiran blok storitve zadostuje, da se težava vrne.

Tri stvari se običajno pokvarijo pozneje. DNS sledi lastniku imenskega prostora, zato nastavitve razreševalnika in iskalne domene pripadajo stranskemu vsebniku, ne gostitelju. VPN s posredovanjem vrat spremeni svoja poslušajoča vrata pri ponovnem povezovanju, zato je treba posredovana vrata ponudnika in poslušajoča vrata na strani vsebnika znova zapisati v konfiguracijo odjemalca ali v preslikavo vrat, običajno z majhnim posodabljalnikom, ki bere API ponudnika. In vsak preizkus, napisan proti localhost, zdaj sprašuje vsebnik tunela, ne obremenitve.

Zapišite vzorec, vključno s tem, kateri vsebnik ima imenski prostor in katera vrata mu pripadajo. Naslednja oseba bo dodala storitev, kopirala napačen blok in ponovila prvo napako iz tega članka.