Docker: suuna üks konteiner VPN-i kaudu ja jäta teine otse

Üks host, kaks töökoormust ja nõue, mis need lahutab: allalaadimisklient, mis peab väljuma kommertsliku VPN-i kaudu, ja haldusliides, mis peab jätkama hosti ühenduse kasutamist. VPN-kliendi paigaldamine hosti rikub nõude kohe, sest siis jagavad mõlemad töökoormused ühte väljapääsu. Muster, mis tegelikult töötab, on viia tunnel omaette konteinerisse ja lasta ainult neil töökoormustel, kes seda vajavad, liituda selle konteineri võrgu nimeruumiga. Kõik muu hoiab tavalist Dockeri teed ja järgnevad üksikasjad on tagajärjed sellest, kes nimeruumi omab.

Miks jagatud nimeruum reegleid muudab

Konteiner, mis liitub teise nimeruumiga, ei saa oma võrgupinu. See näeb samu liideseid, sama marsruutimistabelit ja sama loopbacki nagu konteiner, millega see liitus, ja just seetõttu on muster kasulik: töökoormus lahendab ja ühendub tavapäraselt ning tunnel selle all püüab liikluse kinni, ilma et rakendus sellest teaks. Hind on see, et igal võrguseadmel on nüüd üks omanik ja liituv konteiner ei ole see.

See omandireegel vastab enamikule seadistusküsimustele enne, kui need esitatakse. Kui seade elab võrgupinus, kuulub see kõrvalkonteinerile. Kui see kirjeldab protsessi, jääb see töökoormuse juurde.

Loopback on see osa, mis inimesi üllatab. Liituva konteineri sees localhost lahendub kõrvalkonteineri loopbackiks, mitte oma privaatseks, nii et teenus, mis seob end 127.0.0.1-ga ja ootab isolatsiooni, jagab nüüd seda aadressi tunnelikonteineriga.

Avalda pordid konteineril, mis nimeruumi omab

Pordi vastendus kuulub nimeruumi omanikule ka siis, kui kuulav protsess töötab teises konteineris. Deklareeri vastendus kõrvalkonteineril ja jäta töökoormusele tema enda protsessiseadistus puutumata. Vastendus liituval teenusel ei saa jõustuda, ükskõik kas mootor selle tagasi lükkab või selle vaikselt eirama olenevalt sellest, kuidas konteiner käivitatakse, ja seetõttu kaob liides, mis oli hetk tagasi kättesaadav, niipea kui muster rakendatakse.

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

Loe seda plokki kolme otsusena, mitte kolme teenusena. Kõrvalkonteiner omab tunnelit ja avaldatud porti; liituv klient ei deklareeri üldse ühtegi võrku; otsene klient hoiab oma vastendust vaikevõrgus. Võimekus NET_ADMIN on see, mis lubab kõrvalkonteineril liideseid luua ja marsruute muuta, ja see on põhjus, miks see konteiner vajab rohkem õigusi kui töökoormused, mida ta teenindab.

Otseseks jääv teenus hoiab oma võrku

Töökoormus, mis ei tohi tunnelist läbi minna, hoiab vaikesilda või oma kasutaja määratud võrku, oma avaldatud pordi ja oma väljapääsuga. Kiusatus on see kõrvalkonteineri võrku kinnitada, et kaks konteinerit saaksid nime järgi rääkida, kuid see üks samm viib selle liikluse vaikselt tunnelisse. Kui neil on vaja teineteiseni jõuda, ehita eraldi kasutaja määratud võrk, kinnita mõlemad selle külge ja jäta kõrvalkonteiner ainsaks väljapääsuks.

Hoia kaks küsimust lahus: millised konteinerid jõuavad teineteiseni ja milline kust väljub. Nende ühendamine on kõige tavalisem viis, kuidas see disain muutub taas kogu hosti hõlmavaks VPN-iks.

Tõrgete maatriks esimeseks tunniks

Enamik esimesi katseid ebaõnnestub ühel neljast viisist ja igal on erinev põhjus. Kontrolli neid selles järjekorras, sest kaks esimest selgitavad peaaegu iga raportit.

Neljas rida on see, mida inimesed ekslikult rakenduse veaks diagnoosivad. Töökoormuse enda loopbacki vastu kirjutatud sond testib nüüd tunnelikonteinerit, nii et see kas ebaõnnestub või teatab täiesti valest teenusest.

Kui üks hostinimi vajab tunnelit

Mõnikord on täistunnel liiga palju: üks sisemine nimi peab minema ettevõtte VPN-i kaudu, samal ajal kui kohalik sokkel või kuvaühendus jätkab töötamist. Täistunnel konteineri sees lõhub selle tee ja kõik hostile adresseeritu, seega suuna ainult see prefiks, mida on vaja. Kliendi ümber olev jaotatud marsruutimise mähis teeb seda, saates nimetatud hosti tunnelist läbi ja jättes varasema marsruudi kõige muu jaoks puutumata.

Vali see siis, kui pead jõudma ainult ühe teenuseni ega ürita liigutada kogu konteineri liiklust. See on teine tööriist kui kõrvalkonteiner ja vastab teisele küsimusele.

Kontrolli ja tee see siis taaskäivitusele vastupidavaks

Küsi igalt konteinerilt, milliselt aadressilt see paistab tulevat. Tunneli oma peaks välja printima pakkuja aadressi ja otsene hosti väljapääsu. Identsed vastused tähendavad, et otsene teenus päris vale nimeruumi või hostitasandi VPN püüab endiselt kõike kinni, ja need kaks parandust on erinevad. Käivita kontroll uuesti pärast igat compose’i muudatust, sest ühest kopeeritud teenuseplokist piisab probleemi tagasitoomiseks.

Kolm asja kipuvad hiljem katki minema. DNS järgib nimeruumi omanikku, seega lahendaja ja otsingudomeeni seaded kuuluvad kõrvalkonteinerile, mitte hostile. Portide edasisaatmisega VPN muudab taasühendamisel oma kuulamisporti, seega pakkuja edasisaadetud port ja konteineripoolne kuulamisport tuleb tagasi kirjutada kliendi seadistusse või pordi vastendusse, tavaliselt väikese uuendajaga, mis loeb pakkuja API-t. Ja iga sond, mis on kirjutatud localhost vastu, küsib nüüd tunnelikonteinerilt, mitte töökoormuselt.

Kirjuta muster üles, sealhulgas see, milline konteiner nimeruumi omab ja millised pordid sellele kuuluvad. Järgmine inimene lisab teenuse, kopeerib vale ploki ja taastoodab selle artikli esimese tõrke.