Docker: beindu einum gámi í gegnum VPN og hafðu annan beinan

Einn hýsill, tvö vinnuálag og krafa sem skilur þau að: niðurhalsbiðlari sem verður að koma út um verslunar-VPN og stjórnviðmót sem verður að halda áfram að nota tengingu hýsilsins. Að setja VPN-biðlarann á hýsilinn brýtur kröfuna samstundis, því þá deila bæði álögin einni útgöngu. Mynstrið sem virkar í raun er að færa gönguna í eigið gám og leyfa aðeins álögunum sem þurfa hana að ganga í nafnrými netsins í því gámi. Allt annað heldur venjulegri Docker-leið, og smáatriðin sem fylgja eru afleiðingar þess hver á nafnrýmið.

Hvers vegna sameiginlegt nafnrými breytir reglunum

Gám sem gengur í nafnrými annars fær ekki eigin netstakk. Það sér sömu viðmót, sömu leiðatöflu og sama loopback og gámið sem það gekk í, og einmitt þess vegna er mynstrið gagnlegt: álagið leysir og tengist venjulega, og göngin undir því grípa umferðina án þess að forritið viti af því. Kostnaðurinn er að hver netstilling hefur nú einn eiganda, og gámið sem gengur inn er það ekki.

Þessi eignarregla svarar flestum stillingarspurningum áður en þær eru bornar upp. Ef stilling býr í netstakkanum tilheyrir hún hliðargáminu. Ef hún lýsir ferlinu verður hún hjá álaginu.

Loopback er sá hluti sem kemur fólki á óvart. Inni í gáminu sem gengur inn leysist localhost í loopback hliðargámsins, ekki í eigin einkaloopback, svo þjónusta sem bindur sig við 127.0.0.1 og væntir einangrunar deilir nú þessu vistfangi með göngugáminu.

Birtu port á gáminu sem á nafnrýmið

Portvörpunin tilheyrir eiganda nafnrýmisins jafnvel þótt hlustunarferlið keyri í hinu gáminu. Lýstu vörpuninni á hliðargáminu og láttu álagið halda eigin ferlisstillingu ósnortinni. Vörpun á þjónustunni sem gengur inn getur ekki orðið virk, hvort sem vélbúnaðurinn hafnar henni eða hunsar hana hljóðlega eftir því hvernig gámið er ræst, og þess vegna hverfur viðmót sem var aðgengilegt fyrir augnabliki þegar mynstrið er notað.

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

Lestu þennan blokk sem þrjár ákvarðanir frekar en þrjár þjónustur. Hliðargámið á gönguna og birtu portið; biðlarinn sem gengur inn lýsir engu neti; beini biðlarinn heldur eigin vörpun á sjálfgefna netinu. Hæfileikinn NET_ADMIN er það sem gerir hliðargáminu kleift að búa til viðmót og breyta leiðum, og það er ástæðan fyrir því að þetta gám þarf meiri heimildir en álögin sem það þjónar.

Þjónustan sem verður bein heldur eigin neti

Álagið sem má ekki fara í gegnum gönguna heldur sjálfgefnu brúnni eða eigin neti skilgreindu af notanda, með eigin birtu porti og eigin útgöngu. Freistandi er að tengja það neti hliðargámsins svo gámin tvö geti talað saman eftir nafni, en það eitt skref færir umferð þess hljóðlega inn í gönguna. Ef þau þurfa að ná hvort öðru, byggðu sér net skilgreint af notanda, tengdu bæði við það og láttu hliðargámið vera eina leiðina út.

Haltu spurningunum tveimur aðskildum: hvaða gám ná hvort öðru og hvert fer út hvaðan. Að sameina þær er algengasta leiðin sem þessi hönnun verður aftur að VPN fyrir allan hýsilinn.

Bilunarmatrix fyrir fyrstu klukkustundina

Flest fyrstu tilraunir mistakast á einn af fjórum vegu og hver hefur aðra orsök. Athugaðu þær í þessari röð, því fyrstu tvær útskýra nánast hverja skýrslu.

Fjórða röðin er sú sem fólk greinir ranglega sem villu í forritinu. Prófun sem skrifuð var gegn eigin loopback álagsins er nú að prófa göngugámið, svo hún mistakast annaðhvort eða tilkynnir algjörlega ranga þjónustu.

Þegar eitt hýsilsnafn þarf gönguna

Stundum er full göng of mikið: eitt innra nafn verður að fara í gegnum fyrirtækja-VPN á meðan staðbundið socket eða skjátenging heldur áfram að virka. Full göng inni í gáminu brýtur þá leið og allt sem er beint að hýsilnum, svo beindu aðeins forskeytinu sem þarf á henni að halda. Skipt leiðarvafningur um biðlarann gerir þetta, sendir nefnda hýsilinn í gegnum gönguna og lætur fyrri leiðina ósnortna fyrir allt annað.

Veldu þetta þegar þú þarft aðeins að ná einni þjónustu og ert ekki að reyna að færa alla umferð gámsins. Þetta er annað tól en hliðargámið og svarar annarri spurningu.

Staðfestu og gerðu það svo að endurræsing standist

Spurðu hvert gám frá hvaða vistfangi það virðist koma. Það sem er í göngunni ætti að prenta vistfang veitandans og hið beina útgöngu hýsilsins. Eins svör þýða að beina þjónustan erfði ranga nafnrýmið eða að VPN á hýsilmissi er enn að grípa allt, og þessar tvær lagfæringar eru ólíkar. Keyrðu athugunina aftur eftir hverja compose-breytingu, því eitt afritað þjónustublokk nægir til að koma vandamálinu aftur.

Þrjú atriði hafa tilhneigingu til að brotna síðar. DNS fylgir eiganda nafnrýmisins, svo stillingar leysis og leitarsvæðis tilheyra hliðargáminu frekar en hýsilnum. VPN með portframsetningu breytir hlustunarportinu sínu við endurtengingu, svo framsetta port veitandans og hlustunarport gámhliðarinnar verða að skrifa aftur í stillingar biðlarans eða portvörpunina, venjulega með litlum uppfærsluhugbúnaði sem les API veitandans. Og hver prófun sem skrifuð er gegn localhost spyr nú göngugámið frekar en álagið.

Skrifaðu mynstrið niður, þar á meðal hvaða gám á nafnrýmið og hvaða port tilheyra því. Næsta manneskja bætir við þjónustu, afritar rangan blokk og endurtekur fyrstu bilunina í þessari grein.