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

बिल्ड रनरलाई 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 बारे केही पनि प्रमाणित गर्दैन, त्यसैले एकाइको स्थिति होइन, मार्ग परीक्षण गर्नुहोस्। मार्ग नै टाढाका प्रयोगकर्तालाई साँच्चै चाहिने कुरा हो।