तुम्ही चालू कंटेनरमध्ये WireGuard कॉन्फिगरेशन संपादित करता, ते चालते, आणि पुढील image अद्यतन ते पुसून टाकते। काहीही चुकीचे कॉन्फिगर केलेले नव्हते। फाइल कंटेनरच्या लिहिण्यायोग्य थरात होती, जो फक्त त्या कंटेनर प्रतिकृतीसाठी अस्तित्वात असतो। महत्त्वाची तुलना कोणते साधन वापरायचे ही नाही, तर तुमची तैनाती कोणते इनपुट घोषित करते ही आहे। तुम्ही हाताने संपादित केलेले सर्व काही तैनातीला माहीत नसलेले इनपुट आहे।

दोन प्रकारची स्थिती, एक निरुपयोगी

कंटेनरमध्ये रनटाइमला केलेल्या बदलांसाठी लिहिण्यायोग्य थर असतो, आणि कंटेनर बदलला जातो तेव्हा तो थर टाकून दिला जातो। तो कॉन्फिगरेशन साठवण नाही आणि बॅकअप नाही। image आणि घोषित इनपुट हीच काय चालते याची पूर्ण व्याख्या आहे।

तुमच्या कोणत्या VPN फाइल घोषित इनपुट आहेत आणि कोणत्या योगायोग आहेत हे विचारा:

docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpn

diff लिहिण्यायोग्य थरात काय बदलले ते सूचीबद्ध करते, आणि तोच नाहीसे होणाऱ्या गोष्टींचा संच आहे। mount यादी काय टिकते ते दाखवते। दोन्हींची तुलना काही गमावण्यापूर्वी प्रश्नाचे उत्तर देते।

bind mount, नामांकित volume किंवा secret: प्रत्येक काय संरक्षित करते

तिन्ही VPN प्रोफाइल ठेवू शकतात, आणि कोण ते वाचू शकतो आणि बदलीच्या वेळी काय होते यात ते भिन्न आहेत।

MechanismSurvives recreationWho can read it
Writable layerNoAnyone with container access, until it is gone
Bind mountYes, while the host path existsWhatever the host permissions allow
Named volumeYes, until the volume is removedManaged by the runtime
SecretYes, as a declared inputThe container process, by design

bind mount होस्ट मार्गाचे नकाशे बनवते, म्हणून फाइल त्या मार्गाइतकी संरक्षित असते आणि होस्टच्या परवानग्या अनुमती देतील इतकी दृश्य असते। नामांकित volume रनटाइमद्वारे व्यवस्थापित होते आणि कंटेनर काढला तरी टिकते, ज्यामुळे ते तैनातीच्या मालकीच्या स्थितीसाठी अधिक सुरक्षित डीफॉल्ट बनते। secret यंत्रणा अशा सामग्रीसाठी आहे जी तुम्हाला image किंवा environment variable मध्ये नको आहे।

प्रत्येक environment variable आणि प्रत्येक होस्ट फाइल समान संरक्षण मानू नका, कारण ते नाहीत।

कंटेनरमध्ये संपादन हाच सापळा

सापळा साधन नाही, संपादनाची दिशा आहे। चालू कंटेनरमध्ये केलेला बदल तैनातीला अदृश्य असतो, म्हणून पुढील पुनर्निर्मिती तो शांतपणे परत आणते आणि लक्षण image मधील रिग्रेशनसारखे दिसते। निदानासाठी तिथे बदल करावा लागल्यास तो लगेच बाहेर कॉपी करा आणि घोषित इनपुटमध्ये ठेवा। नंतर पुन्हा तयार करा जेणेकरून तैनाती तो पुनरुत्पादित करते हे सिद्ध होईल।

प्रोफाइलमध्ये खाजगी किल्ल्या आणि खाते सामग्री असू शकते, ज्यामुळे त्या फाइलचा बॅकअप फाइल कॉपीऐवजी गुप्त हाताळणीचे काम बनते। मालकी आणि वाचन प्रवेश कंटेनरच्या प्रत्यक्ष प्रक्रियेपुरता मर्यादित ठेवा, परवानगी त्रुटी नाहीशी करण्यासाठी होस्ट डिरेक्टरी रुंदावण्याऐवजी।

तीच रुंदावणं कंटेनरमधील सोयीचे होस्टच्या उघडीकरणात रूपांतर करते।

जाणीवपूर्वक पुन्हा तयार करा, नंतर चार गोष्टी तपासा

image आवृत्ती, आवश्यक उपकरण आणि क्षमता, नेटवर्क जोडणी आणि कायम इनपुट लिहा। उपकरण आणि क्षमता यादी VPN कंटेनरसाठी विशेष महत्त्वाची आहे, कारण बोगद्याला नेटवर्क उपकरण आणि ते कॉन्फिगर करण्याचा विशेषाधिकार लागतो।

कोणती निर्मित रनटाइम स्थिती साठवण्याऐवजी पुन्हा बांधावी हे निश्चित करा। बोगद्याने पहिल्या सुरुवातीला निर्माण केलेल्या किल्ल्या स्थिती आहेत, आणि त्या ठेवणे किंवा पुन्हा निर्माण करणे हा जुन्या सार्वजनिक किल्लीला माहीत असलेल्या प्रत्येक peer साठी परिणाम असलेला निर्णय आहे।

नियंत्रित पुनर्निर्मितीनंतर ओळख, मार्गनिर्देशन, DNS आणि आवश्यक अयशस्वी-ब्लॉक तपासा। त्रुटींशिवाय सुरू होणारी प्रक्रिया या चारांपैकी एकही सिद्ध करत नाही। बोगदा चालू असताना आणि तो थांबवल्यानंतर पुन्हा ते तपासा, कारण अयशस्वी-ब्लॉक फक्त बोगदा गेल्यावरच दिसतो।

कंटेनरबाहेर पुनर्प्राप्ती प्रत ठेवा

कंटेनरपासून स्वतंत्र राहणारी पुनर्प्राप्ती प्रत ठेवा, आणि दस्तऐवजीकृत प्रक्रियेद्वारे ती पुनर्संचयित करण्याची चाचणी करा। VPN प्रोफाइलचा न तपासलेला बॅकअप एक आशा आहे, विशेषतः जेव्हा पुनर्प्राप्ती मार्गात कंटेनर प्रक्रियेला लागणाऱ्या परवानग्या असतात।

VPN असलेला कंटेनर बदलला तर त्याचा नेटवर्क स्टॅक सामायिक करणाऱ्या अनुप्रयोगांचे runtime च्या समर्थित जीवनचक्रात समन्वय करा।

हाच समन्वय पुन्हा सुरू करणे आणि व्यत्यय यातील फरक आहे। तैनातीने कॉन्फिगरेशन कुठून येते ते सांगावे, आणि volume दस्तऐवजीकरण हे runtime प्रत्यक्षात काय टिकवते हे तपासण्याचे ठिकाण आहे।

संबंधित लेख