Docker: idaan ang isang container sa VPN at iwanang direkta ang isa
Bigyan ang tunnel ng sarili nitong container, hayaang ang mga serbisyong nangangailangan lang nito ang magbahagi ng namespace na iyon, pagkatapos isaalang-alang ang sumusunod sa may-ari: mga port, localhost, DNS.
Isang host, dalawang workload at isang pangangailangan na naghihiwalay sa kanila: isang download client na dapat lumabas sa isang komersyal na VPN, at isang interface ng pamamahala na dapat magpatuloy sa paggamit ng koneksyon ng host. Ang pag-install ng VPN client sa host ay agad na pumapalya sa pangangailangan, dahil pagkatapos ay nagbabahagi ang dalawang workload ng isang labasan. Ang pattern na talagang gumagana ay ilipat ang tunnel sa sarili nitong container at hayaang ang mga workload na nangangailangan lang nito ang sumali sa namespace ng network ng container na iyon. Ang lahat ng iba ay nagpapanatili ng karaniwang landas ng Docker, at ang mga detalyeng sumusunod ay mga bunga ng kung sino ang nagmamay-ari ng namespace.
Bakit binabago ng pinagsamang namespace ang mga patakaran
Ang container na sumasali sa namespace ng iba ay hindi nakakakuha ng sarili nitong stack ng network. Nakikita nito ang parehong mga interface, ang parehong talahanayan ng routing at ang parehong loopback tulad ng container na sinalihan nito, at iyon ang dahilan kung bakit kapaki-pakinabang ang pattern: ang workload ay nagre-resolve at kumokonekta nang normal, at ang tunnel sa ilalim ay humuhuli ng trapiko nang hindi alam ng application. Ang halaga ay ang bawat setting na may kinalaman sa network ay mayroon nang isang may-ari, at ang sumasaling container ay hindi iyon.
Ang tuntunin ng pagmamay-ari na ito ay sumasagot sa karamihan ng mga tanong sa configuration bago pa man itanong. Kung ang isang setting ay naninirahan sa stack ng network, ito ay pag-aari ng sidecar. Kung inilalarawan nito ang proseso, nananatili ito sa workload.
Ang loopback ang bahaging nagpapasorpresa sa mga tao. Sa loob ng sumasaling container, ang localhost ay nire-resolve sa loopback ng sidecar, hindi sa sarili nitong pribado, kaya ang isang serbisyong nagbubuklod sa 127.0.0.1 na umaasa ng paghihiwalay ay nagbabahagi na ngayon ng address na iyon sa container ng tunnel.
I-publish ang mga port sa container na nagmamay-ari ng namespace
Ang mapping ng port ay pag-aari ng may-ari ng namespace kahit na ang prosesong nakikinig ay tumatakbo sa kabilang container. Ipahayag ang mapping sa sidecar, at hayaang panatilihin ng workload ang sarili nitong configuration ng proseso na hindi ginalaw. Ang mapping sa sumasaling serbisyo ay hindi maaaring magkabisa, tanggihan man ito ng engine o hindi papansinin nang tahimik depende sa kung paano sinisimulan ang container, at iyon ang dahilan kung bakit ang isang interface na naaabot ilang sandali lang ang nakalipas ay nawawala sa sandaling ilapat ang pattern.
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"]Basahin ang bloke na iyon bilang tatlong desisyon hindi tatlong serbisyo. Ang sidecar ang may-ari ng tunnel at ng na-publish na port; ang sumasaling client ay hindi nagpapahayag ng anumang network; ang direktang client ay nagpapanatili ng sarili nitong mapping sa default na network. Ang kakayahan NET_ADMIN ang nagpapahintulot sa sidecar na lumikha ng mga interface at baguhin ang mga ruta, at iyon ang dahilan kung bakit kailangan ng container na ito ng mas maraming pribilehiyo kaysa sa mga workload na pinaglilingkuran nito.
Ang serbisyong nananatiling direkta ay nagpapanatili ng sarili nitong network
Ang workload na hindi dapat dumaan sa tunnel ay nagpapanatili ng default na tulay o sarili nitong network na tinukoy ng user, kasama ang sarili nitong na-publish na port at sarili nitong labasan. Nakakaakit na ikabit ito sa network ng sidecar upang makapag-usap ang dalawang container sa pamamagitan ng pangalan, ngunit ang isang hakbang na iyon ay tahimik na naglilipat ng trapiko nito sa tunnel. Kung kailangan nilang maabot ang isa't isa, bumuo ng hiwalay na network na tinukoy ng user, ikabit ang dalawa dito, at iwanan ang sidecar bilang nag-iisang daan palabas.
Panatilihing hiwalay ang dalawang tanong: aling mga container ang maaaring mag-abot sa isa't isa, at alin ang lumalabas saan. Ang pagsasama ng mga ito ang pinakakaraniwang paraan kung paano nagiging VPN para sa buong host muli ang disenyong ito.
Isang matrix ng mga pagkabigo para sa unang oras
Karamihan ng mga unang pagtatangka ay nabigo sa isa sa apat na paraan, at bawat isa ay may ibang dahilan. Suriin ang mga ito sa ganitong pagkakasunod-sunod, dahil ang unang dalawa ay nagpapaliwanag ng halos lahat ng ulat.
| 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 |
Ang ikaapat na hilera ang isa na mali ang diagnosis ng mga tao bilang bug ng application. Ang isang pagsusuring isinulat laban sa sariling loopback ng workload ay sumusubok na ngayon sa container ng tunnel, kaya ito ay nabigo o nag-uulat ng ganap na maling serbisyo.
Kapag kailangan ng tunnel ng isang hostname
Minsan ang buong tunnel ay sobra: isang panloob na pangalan ang dapat dumaan sa corporate VPN habang ang isang lokal na socket o koneksyon ng display ay patuloy na gumagana. Ang buong tunnel sa loob ng container ay sumisira sa landas na iyon at sa lahat ng naka-address sa host, kaya i-route lamang ang prefix na nangangailangan nito. Ang isang balot ng split routing sa paligid ng client ay gumagawa nito, ipinapadala ang pinangalanang host sa tunnel at iniiwan ang dating ruta na hindi ginalaw para sa lahat ng iba.
Piliin ito kapag kailangan mong maabot ang isang serbisyo lamang at hindi mo sinusubukang ilipat ang lahat ng trapiko ng container. Ito ay ibang tool mula sa sidecar at sumasagot sa ibang tanong.
I-verify, pagkatapos gawin itong matibay sa restart
Tanungin ang bawat container kung saang address ito tila nagmumula. Ang nasa tunnel ay dapat mag-print ng address ng provider at ang direkta ay ang labasan ng host. Ang magkaparehong sagot ay nangangahulugan na ang direktang serbisyo ay nagmana ng maling namespace o ang VPN sa antas ng host ay humuhuli pa rin ng lahat, at ang dalawang pagbabagong iyon ay magkaiba. Patakbuhin muli ang pagsusuri pagkatapos ng bawat pag-edit ng compose, dahil ang isang nakopyang bloke ng serbisyo ay sapat na upang maibalik ang problema.
Tatlong bagay ang kadalasang nasisira sa kalaunan. Ang DNS ay sumusunod sa may-ari ng namespace, kaya ang mga setting ng resolver at domain ng paghahanap ay pag-aari ng sidecar hindi ng host. Ang VPN na may port forwarding ay binabago ang port na pinakikinggan nito kapag muling kumonekta, kaya ang forward na port ng provider at ang port na pinakikinggan sa gilid ng container ay dapat na isulat muli sa configuration ng client o sa mapping ng port, kadalasan sa pamamagitan ng maliit na updater na bumabasa ng API ng provider. At anumang pagsusuring isinulat laban sa localhost ay nagtatanong na ngayon sa container ng tunnel hindi sa workload.
Isulat ang pattern, kasama kung aling container ang nagmamay-ari ng namespace at aling mga port ang pag-aari nito. Ang susunod na tao ay magdadagdag ng serbisyo, kokopyahin ang maling bloke at muling gagawin ang unang pagkabigo sa artikulong ito.