Docker: irányítson át egy konténert VPN-en, és tartson egy másikat közvetlenül
Adjon a belső alagútnak saját konténert, csak a rá szoruló szolgáltatásokkal ossza meg azt a névteret, majd vegye figyelembe, ami a tulajdonost követi: portok, localhost, DNS.
Egy gazdagép, két munkaterhelés és egy követelmény, amely elválasztja őket: egy letöltőügyfél, amelynek kereskedelmi VPN-en kell kijönnie, és egy felügyeleti felület, amelynek továbbra is a gazdagép kapcsolatát kell használnia. A VPN-ügyfél gazdagépre telepítése azonnal meghiúsítja a követelményt, mert akkor mindkét munkaterhelés egyetlen kimenetet oszt meg. A minta, amely valóban működik, az, hogy az alagutat a saját konténerébe helyezzük, és csak azoknak a munkaterheléseknek engedjük, amelyeknek szükségük van rá, hogy csatlakozzanak ahhoz a hálózati névtérhez. Minden más a szokásos Docker-útvonalon marad, és az ezt követő részletek annak következményei, hogy ki birtokolja a névteret.
Miért változtatja meg a megosztott névtér a szabályokat
Az a konténer, amely egy másik névteréhez csatlakozik, nem kap saját hálózati vermet. Ugyanazokat az interfészeket, ugyanazt az útválasztási táblázatot és ugyanazt a loopbacket látja, mint a konténer, amelyhez csatlakozott, és pontosan ezért hasznos a minta: a munkaterhelés normálisan oldja fel és kapcsolódik, az alatta lévő alagút pedig elkapja a forgalmat anélkül, hogy az alkalmazás tudna róla. Az ára az, hogy minden hálózati beállításnak most egyetlen tulajdonosa van, és a csatlakozó konténer nem ő.
Ez a tulajdonosi szabály a legtöbb konfigurációs kérdésre válaszol, mielőtt feltennék őket. Ha egy beállítás a hálózati veremben él, a mellékkonténerhez tartozik. Ha a folyamatot írja le, a munkaterhelésnél marad.
A loopback az a rész, amely meglepi az embereket. A csatlakozó konténeren belül a localhost a mellékkonténer loopbackjére oldódik fel, nem egy saját privátra, így az a szolgáltatás, amely 127.0.0.1-hez kötődik és elkülönítést vár, most megosztja ezt a címet az alagút konténerével.
Tegye közzé a portokat azon a konténeren, amely a névteret birtokolja
A portleképezés a névtér tulajdonosáé, akkor is, ha a figyelő folyamat a másik konténerben fut. Deklarálja a leképezést a mellékkonténeren, és hagyja, hogy a munkaterhelés érintetlenül tartsa a saját folyamatkonfigurációját. A csatlakozó szolgáltatáson lévő leképezés nem léphet életbe, akár elutasítja a motor, akár csendben figyelmen kívül hagyja attól függően, hogyan indul a konténer, és ezért tűnik el egy pillanattal korábban elérhető felület, amint a mintát alkalmazzák.
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"]Olvassa ezt a blokkot három döntésként, nem három szolgáltatásként. A mellékkonténer birtokolja az alagutat és a közzétett portot; a csatlakozó ügyfél egyáltalán nem deklarál hálózatot; a közvetlen ügyfél megtartja saját leképezését az alapértelmezett hálózaton. A képesség NET_ADMIN az, ami lehetővé teszi a mellékkonténer számára az interfészek létrehozását és az útvonalak módosítását, és ez az oka annak, hogy ez a konténer több jogosultságot igényel, mint az általa kiszolgált munkaterhelések.
A közvetlenül maradó szolgáltatás megtartja saját hálózatát
Az a munkaterhelés, amely nem mehet át az alagúton, megtartja az alapértelmezett hidat vagy a saját felhasználó által definiált hálózatát, saját közzétett portjával és saját kimenetével. Csábító a mellékkonténer hálózatához csatolni, hogy a két konténer név szerint beszélhessen, de ez az egy lépés csendben az alagútba mozgatja a forgalmát. Ha el kell érniük egymást, építsen külön felhasználó által definiált hálózatot, csatolja mindkettőt hozzá, és hagyja a mellékkonténert az egyetlen kifelé vezető útnak.
Tartsa külön a két kérdést: mely konténerek érhetik el egymást, és melyik hol lép ki. Ezek összevonása a leggyakoribb módja annak, hogy ez a terv ismét az egész gazdagépre kiterjedő VPN-né váljon.
Hibamátrix az első órára
A legtöbb első próbálkozás négy módon szokott meghiúsulni, és mindegyiknek más az oka. Ebben a sorrendben ellenőrizze őket, mert az első kettő szinte minden jelentést megmagyaráz.
| 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 |
A negyedik sor az, amelyet az emberek tévesen alkalmazáshibának diagnosztizálnak. A munkaterhelés saját loopbackje ellen írt próba most az alagút konténerét teszteli, tehát vagy meghiúsul, vagy teljesen rossz szolgáltatást jelent.
Amikor egyetlen gazdagépnévnek kell az alagút
Néha a teljes alagút túl sok: egy belső névnek vállalati VPN-en kell átjutnia, miközben egy helyi socket vagy megjelenítési kapcsolat tovább működik. A konténeren belüli teljes alagút megtöri ezt az utat és mindent, ami a gazdagépnek van címezve, ezért csak azt az előtagot irányítsa, amelynek szüksége van rá. Az ügyfél körüli osztott útválasztási burkoló ezt teszi, a megnevezett gazdagépet az alagúton keresztül küldi, és minden más számára érintetlenül hagyja az előző útvonalat.
Ezt akkor válassza, ha csak egy szolgáltatást kell elérnie, és nem próbálja a konténer teljes forgalmát átmozgatni. Ez más eszköz, mint a mellékkonténer, és más kérdésre válaszol.
Ellenőrizze, majd tegye újraindítást túlélővé
Kérdezze meg minden konténertől, milyen címről látszik jönni. Az alagútban lévőnek a szolgáltató címét kell kiírnia, a közvetlennek pedig a gazdagép kimenetét. Az azonos válaszok azt jelentik, hogy a közvetlen szolgáltatás rossz névteret örökölt, vagy egy gazdagépszintű VPN még mindig mindent elkap, és ez a két javítás különbözik. Minden compose-szerkesztés után futtassa újra az ellenőrzést, mert egyetlen másolt szolgáltatásblokk is elég a probléma visszahozásához.
Három dolog szokott később elromlani. A DNS a névtér tulajdonosát követi, ezért a feloldó és a keresési tartomány beállításai a mellékkonténerhez tartoznak, nem a gazdagéphez. A porttovábbítást használó VPN újracsatlakozáskor megváltoztatja a figyelő portját, ezért a szolgáltató továbbított portját és a konténer oldali figyelő portot vissza kell írni az ügyfél konfigurációjába vagy a portleképezésbe, általában egy kis frissítővel, amely a szolgáltató API-ját olvassa. És minden próba, amelyet a localhost ellen írtak, most az alagút konténerét kérdezi, nem a munkaterhelést.
Írja le a mintát, beleértve azt is, melyik konténer birtokolja a névteret és mely portok tartoznak hozzá. A következő ember hozzáad egy szolgáltatást, lemásolja a rossz blokkot, és újra előállítja a cikk első hibáját.