की कॉपी न करता Raspberry Pi VPN उपकरण पुन्हा तयार करा

प्रतिमेवरून एकदा बूट केल्याने Pi पुनर्निर्माणयोग्य उपकरण होत नाही। तुम्हाला पुन्हा लागू करता येणारा छोटा इनपुट संच हवा: देखभाल केलेला आधार, जाहीर केलेले कॉन्फिगरेशन, अनुप्रयोगाचा कायम डेटा आणि फक्त त्या बोर्डची अशी उपकरण ओळख। शेवटचे विसरल्यास प्रत्येक बदल हा एका क्रेडेन्शियलचा क्लोन होतो।

खालील टप्पे साधनाची शिफारस नसून कामाचा क्रम आहेत। ते व्यक्त करू शकणारी कोणतीही कॉन्फिगरेशन प्रणाली पुरेशी आहे।

आधी चार प्रकारचे इनपुट सूचीबद्ध करा

आधार प्रतिमा आणि तिची पॅकेजेस ऑपरेटिंग सिस्टम, आर्किटेक्चर आणि अद्यतने कुठून येतात हे ठरवतात, आणि प्रतिमा बिल्डर तेव्हाच मदत करतो जेव्हा त्याने नाव दिलेले साधन तुमच्या आवृत्तीसाठी अजूनही देखभाल केले जाते। जाहीर केलेले कॉन्फिगरेशन हा माणूस पुनरावलोकन करणारा भाग आहे: नेटवर्क भूमिका, सेवा सेटिंग्ज आणि प्रत्येक सेवेला लागणाऱ्या जीवनचक्र क्रिया। कायम अनुप्रयोग डेटा म्हणजे सेवा पुन्हा निर्माण करू शकत नाही ते सर्व, आणि त्याचे स्थान व बॅकअप पद्धत त्या अनुप्रयोगाची आहे, प्रतिमेची नाही। उपकरण ओळख आणि गुपिते हे चौथे इनपुट आहेत, आणि कार्यरत कार्डचे क्लोन करताना लोक नेमके हेच विसरतात।

काहीही पुन्हा तयार करण्यापूर्वी चार याद्या लिहा। रिकाम्या ओळीची यादी म्हणजे तुम्ही अजून न घेतलेला निर्णय।

गुपिते रिपॉझिटरीबाहेर ठेवा आणि ती कुठे राहतात ते सांगा

रिपॉझिटरी पुनरावलोकन केलेल्या टेम्पलेट्स आणि गुप्त नसलेल्या कॉन्फिगरेशनसाठी चांगले घर आहे, आणि VPN खाजगी की, पुन्हा वापरता येणारी प्रशासकीय क्रेडेन्शियल्स आणि निदान संग्रहांसाठी वाईट घर आहे। गुपित उपकरणावर असलेच पाहिजे असेल, तर ते कुठून येते, कोण वाचू शकतो आणि ते कसे फिरवले जाते हे नोंदवा। एकाच SD कार्डवर राहणारी की हा एकच अपयश बिंदू आहे, तर प्रत्येक बोर्डवर कॉपी केलेली की मालक नसलेले संपूर्ण ताफ्याचे क्रेडेन्शियल आहे। दोन्हीपैकी कोणतेही पुनर्प्राप्ती योजना नाही।

चाचणी सोपी आहे: उद्या रिपॉझिटरी गळली तर हल्लेखोराला काय मिळेल? टेम्पलेट्स आणि टोपोलॉजी नोंदी टिकतात। कार्यरत ओळख टिकत नाही।

पुन्हा चालवता येणारे स्वयंचलनाकडे असू द्या

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

प्रशासनाचे टप्पेही वेगळे करा। बूटस्ट्रॅप कनेक्टिव्हिटी, नित्य कॉन्फिगरेशन आणि VPN-अवलंबून व्यवस्थापन या तीन वेगळ्या खिडक्या आहेत, आणि पुनर्निर्माणामुळे त्याखालील नेटवर्क रीसेट झाले तर तिसरे तुमचा स्वतःचा प्रवेश काढून टाकू शकते। स्वतंत्र प्रवेशमार्ग ठेवा।

डेटा आणि ओळख जाणीवपूर्वक पुनर्संचयित करा

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

ओळखीबाबत, तुम्ही तेच उपकरण पुनर्प्राप्त करत आहात की बदली नोंदवत आहात हे ठरवा, कारण या वेगळ्या स्वच्छतेच्या वेगळ्या क्रिया आहेत।

दुसरीकडे ओळख सक्रिय करण्यापूर्वी जुन्या साथीदाराचा प्रवेश जुळवून घ्या, आणि त्यानंतरच पुनर्निर्मित उपकरण वेगळ्या किंवा पुनर्प्राप्ती वातावरणात तपासा। आवश्यक डेटा, योग्य ओळख, मालक असलेला अद्यतन मार्ग आणि इच्छित नेटवर्क धोरण तपासा।

बूट करण्यायोग्य प्रतिमा चारपैकी एक इनपुट आहे, आणि ती पुन्हा तयार करणे सर्वात सोपे आहे।