Ang config ng VPN ay nakakaligtas sa muling paggawa ng container kung imo-mount mo ito
Ang file na inedit sa loob ng tumatakbong container ay nabubuhay sa layer na nawawala. Ihambing ang bind mounts, volumes at secrets, pagkatapos ay muling gumawa at i-verify ang apat na bagay.
Inedit mo ang config ng WireGuard sa loob ng tumatakbong container, gumagana ito, at binubura ito ng susunod na update ng image. Wala namang mali sa config. Nabuhay ang file sa writable layer ng container, na umiiral lamang para sa instance ng container na iyon. Ang mahalagang paghahambing ay hindi kung anong tool ang gagamitin, kundi kung anong mga input ang idinedeklara ng deployment mo. Anumang inedit mo sa kamay ay input na hindi alam ng deployment.
Dalawang uri ng estado, ang isa ay itinatapon
May writable layer ang container para sa mga pagbabagong ginawa sa runtime, at itinatapon ang layer na iyon kapag napalitan ang container. Hindi ito imbakan ng config at hindi ito backup. Ang image at ang mga idineklarang input ang buong depinisyon ng tumatakbo.
Itanong kung alin sa mga file ng VPN mo ang idineklarang input at alin ang aksidente:
docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpnInililista ng diff ang nabago sa writable layer, at iyon ang eksaktong set ng mga bagay na mawawala. Ipinapakita ng listahan ng mount ang natitira. Ang paghahambing ng dalawa ay sumasagot sa tanong bago ka mawalan ng anuman.
Bind mount, pinangalanang volume o secret: ano ang pinoprotektahan ng bawat isa
Maaaring maglaman ng profile ng VPN ang tatlo, at nagkakaiba sila sa kung sino ang makakabasa nito at ano ang nangyayari sa pagpapalit.
| Mechanism | Survives recreation | Who can read it |
|---|---|---|
| Writable layer | No | Anyone with container access, until it is gone |
| Bind mount | Yes, while the host path exists | Whatever the host permissions allow |
| Named volume | Yes, until the volume is removed | Managed by the runtime |
| Secret | Yes, as a declared input | The container process, by design |
Ang bind mount ay nagmamapa ng path ng host, kaya ang file ay protektado gaya ng path na iyon at nakikita gaya ng pinapayagan ng mga permiso ng host. Ang pinangalanang volume ay pinamamahalaan ng runtime at nakakaligtas sa pagtanggal ng container, kaya ito ang mas ligtas na default para sa estado na pagmamay-ari ng deployment. Ang mekanismo ng secret ay para sa materyal na ayaw mo sa isang image o sa isang environment variable.
Huwag ituring na pantay na proteksyon ang bawat environment variable at bawat file ng host, dahil hindi sila pantay.
Ang pag-edit sa loob ng container ang bitag
Ang bitag ay hindi ang tool, kundi ang direksyon ng pag-edit. Ang pagbabagong ginawa sa loob ng tumatakbong container ay hindi nakikita ng deployment, kaya ibinabalik ito nang tahimik ng susunod na muling paggawa at mukhang regression sa image ang sintomas. Kung kailangan mong magbago doon para mag-diagnose, kopyahin agad ito palabas at ilagay sa idineklarang input. Pagkatapos ay muling gumawa upang patunayan na ginagawa itong muli ng deployment.
Maaaring magdala ng mga pribadong key at materyal ng account ang profile, kaya ang backup ng file na iyon ay gawain sa paghawak ng mga lihim sa halip na pagkopya ng file. Panatilihing limitado ang pagmamay-ari at pag-access sa pagbasa sa aktwal na proseso ng container, sa halip na palawakin ang direktoryo ng host para mawala ang error sa permiso.
Ang pagpapalawak na iyon ang nagiging dahilan kung bakit ang kaginhawahan sa container ay nagiging pagkakalantad ng host.
Sadyang muling gumawa, pagkatapos ay i-verify ang apat na bagay
Itala ang bersyon ng image, ang kinakailangang device at kakayahan, ang koneksyon sa network at ang mga permanenteng input. Mahalaga ang listahan ng device at kakayahan para sa container ng VPN, dahil kailangan ng tunnel ang device ng network at ang pribilehiyong i-configure ito.
Tiyakin kung aling generated runtime state ang dapat muling itayo sa halip na i-save. Ang mga key na ginawa ng tunnel sa unang pag-start ay estado, at ang pagpapanatili o muling paggawa sa mga ito ay desisyong may kahihinatnan para sa bawat peer na nakakaalam ng lumang public key.
Pagkatapos ng kontroladong muling paggawa, i-verify ang identity, routing, DNS at ang kinakailangang failure block. Ang prosesong nagsisimula nang walang error ay hindi nagpapatunay ng alinman sa apat. Suriin ito habang aktibo ang tunnel at muli pagkatapos mong ihinto ito, dahil lumilitaw lamang ang failure block kapag nawala ang tunnel.
Magtabi ng kopya para sa pagbawi sa labas ng container
Magtabi ng kopya para sa pagbawi na nabubuhay nang hiwalay sa container, at subukan ang pagbawi nito sa dokumentadong proseso. Ang hindi nasubok na backup ng profile ng VPN ay isang pag-asa, lalo na kapag kasama sa landas ng pagbawi ang mga permiso na kailangan ng proseso ng container.
Kung mapalitan ang container na nagmamay-ari ng VPN, i-coordinate ang mga application na nagbabahagi ng network stack nito sa loob ng sinusuportahang lifecycle ng runtime.
Ang koordinasyong iyon ang pagkakaiba ng isang restart at isang pagkawala ng serbisyo. Dapat ilarawan ng deployment kung saan nagmumula ang config, at ang dokumentasyon ng volume ang lugar upang tingnan kung ano talaga ang pinapanatili ng runtime.