एक लॅब सर्व्हर, तीन विश्वास भूमिका, एक अयशस्वीता डोमेन

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

सध्या सर्व काही सामायिक करणाऱ्या तीन भूमिका

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

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

खालील रेखाचित्र त्या विभाजनासाठी प्रारंभबिंदू आहे, उच्च उपलब्धतेचे वचन नाही। त्याकडे पडताळायच्या गृहीतकासारखे पहा, पूर्ण झालेल्या रचनेसारखे नाही।

तीन प्रक्रिया नाही, तीन भूमिका वेगळ्या करा

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

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

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

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

VPN पाहुण्याला फक्त स्वतःचे दरवाजे उघडू द्या

राउटरवर टनेल पोर्ट प्रकाशित करा आणि दुसरे काही नाही। पाहुणे व्यवस्थापन पोर्ट व्यवस्थापन मार्गाचे आहेत, इंटरनेटचे नाही, आणि हायपरवायझरचा स्वतःचा इंटरफेसही तिथेच आहे।

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

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

होस्टवर ऐकणारे आणि व्यवस्थापनासाठी न लागणारे काहीही अजिबात ऐकू नये। यात हायपरवायझर API येते, जे सार्वजनिक इंटरफेसवर उघडे ठेवणे सोपे आहे।

बिल्ड कामांना वेगळ्या प्रकारची सीमा लागते

CI काम रेपॉझिटरी-नियंत्रित आदेश चालवते, म्हणून त्याचा विश्वास कोण कोड पुश करू शकतो यावर अवलंबून असतो। शेल एक्झिक्युटर ते आदेश होस्टवर रनरच्या वापरकर्त्याप्रमाणे चालवतो, आणि ती उपलब्ध सर्वात रुंद सीमा आहे।

कंटेनर एक्झिक्युटर अरुंद असतात, आणि विशेषाधिकार प्राप्त कंटेनर अरुंदांपैकी नाही। रनरला स्वतःच्या नेटवर्क व्याप्तीसह स्वतःच्या पाहुण्यात ठेवा, आणि कामांना लागणारा आर्टिफॅक्ट व उपयोजन प्रवेशच द्या। निकामी होणाऱ्या कामगारांमुळे राखलेली स्थिती कमी होते; ते पोहोच किंवा रहस्यांचे उघड होणे कमी करत नाहीत। दोन्हींना अजूनही स्पष्ट मर्यादा लागतात।

सेवा पाहुण्याकडे डेटा आहे, म्हणून त्याची बॅकअप योजना हीच चालली पाहिजे। रेपॉझिटरी, अपलोड आणि डेटाबेस एकाच वेळापत्रकात ठेवा। कामाची स्थिती वाचण्याऐवजी पुनर्संचयन तपासा।

तिघेही सामायिक करतात त्या अयशस्वीतेची योजना करा

एक होस्ट एक अयशस्वीता डोमेन आहे। रीबूट एकाच क्षणी टनेल आणि प्रत्येक खाजगी सेवा काढून टाकतो, आणि तेव्हाच आत जाण्याचा मार्ग सर्वात महत्त्वाचा ठरतो।

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

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

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