CI रनरको VPN: टनेल बिल्डभन्दा लामो बाँच्छ?
साझा CI रनरले कामहरूबीच रुट र प्रक्रियाहरू राख्छ। कामअघि, क्रममा र पछि VPN को अवस्था योजना गर्नुहोस्, र कामको स्वामित्वको जडान मात्र सफा गर्नुहोस्।
एउटा डिप्लोयमेन्ट काम जडान हुन्छ, आफ्नो आर्टिफ्याक्ट प्रतिलिपि गर्छ र सफलता रिपोर्ट गर्छ। यसले खोलेको टनेल अर्को काम सुरु हुँदा पनि चालु हुन सक्छ, र यसले बदलेको रुट सम्पूर्ण होस्टको हो। बिल्डको नतिजा आदेशको वर्णन गर्छ, पछाडि छोडेको अवस्थाको होइन। VPN लाई आयु भएको स्रोतका रूपमा लिनुहोस्, चरणको सुरुवातको एक लाइनका रूपमा होइन।
यो होस्टमा अरू के चल्छ
एउटा Jenkins नोडले एकैचोटि धेरै executor चलाउन सक्छ, र होस्टका रुट, resolver सेटिङ वा प्रणाली-व्यापी जडान बदल्ने कामले ती सबैका लागि बदल्छ। अर्को कामले त्यो देख्छ कि देख्दैन भन्ने रुट र फिल्टरिङ नीतिमा निर्भर छ, VPN बारेको सामान्य नियममा होइन। रिपोजिटरी पहुँच, आर्टिफ्याक्ट पहुँच र नियन्त्रण च्यानल रनरलाई अझै चाहिने छुट्टाछुट्टै आवश्यकता हुन्। पूर्ण टनेल छान्नुअघि तिनलाई डिप्लोयमेन्ट गन्तव्यको सूचीमा थप्नुहोस्।
यदि नियन्त्रण च्यानलले टनेल पार गर्ने हो भने, डिजाइनले त्यो जानाजान भन्नुपर्छ। रोलब्याकमा त्यो पत्ता लगाउनु योजना होइन। दुई सूची लेख्नुहोस्: कामले निजी रूपमा कहाँ पुग्नुपर्छ, र रनरले जसरी पनि कहाँ पुग्नुपर्छ।
यो कामलाई निजी पहुँच चाहिन्छ नै?
टनेल थप्नुअघि बिल्ड चरणलाई त्यो चाहिन्छ कि भनी सोध्नुहोस्। निजी डिप्लोयमेन्ट एजेन्टले स्वीकृत आर्टिफ्याक्ट ल्याएर डिप्लोयमेन्ट गर्न सक्छ, जसले सामान्य बिल्ड चरणलाई निजी सञ्जालबाहिर राख्छ। त्यो विभाजन सामान्यतया हरेक बिल्ड चरणलाई टनेलबाट रुट गर्न सिकाउनुभन्दा सस्तो हुन्छ।
सीमा बानीबाट होइन, कार्यप्रवाहबाट छान्नुहोस्। जवाफ होइन भए, यो पृष्ठको बाँकी अनावश्यक छ, र त्यो नै उपलब्ध उत्तम नतिजा हो।
अर्को कामले उत्तराधिकारमा पाउने अवस्था
कामअघि, निजी पहुँच हुँदा र काम सकिएपछि—रद्द गर्ने समेत—के सत्य हुनुपर्छ भनी वर्णन गर्नुहोस्। अन्तिम अवस्था नै सबैभन्दा बढी अव्यक्त रहन्छ, र त्यही अर्को कामले उत्तराधिकारमा पाउँछ। त्यसलाई कसैको सम्झनामा छोड्नुभन्दा pipeline को छेउमा लेख्नुहोस्।
| Moment | What proves it | What leaks if it is skipped |
|---|---|---|
| Job start: pre-flight route check | The route table shows no tunnel from an earlier job, and the profile list is empty | A stale route sends deployment traffic into a dead tunnel |
| Job end: disconnect and shred | The profile is down and the temporary key file is gone | The next job inherits an open tunnel and a usable credential |
| Cancelled job: reboot or disposal | The host is replaced or rebooted before the next job starts | A killed process leaves the tunnel up with no owner |
समर्पित वा एकपटक प्रयोग हुने एजेन्टले ती सीमा लागू गर्न सजिलो बनाउँछ। कन्टेनर वा नेमस्पेसले मात्र तब सहयोग गर्छ जब त्यसको सञ्जाल र विशेषाधिकार व्यवस्थाले परिवर्तनलाई साँच्चै अलग गर्छ।
प्रोग्राम होइन, जडान रोक्नुहोस्
यो कामले सुरु गरेको जडान बन्द गर्न र त्यसका अस्थायी प्रमाणहरू हटाउन pipeline को अन्त्य मार्ग प्रयोग गर्नुहोस्। अरू कामले प्रयोग गर्ने होस्टमा प्रोग्रामको नामले प्रक्रिया मिलाउनु हुँदैन; बरु त्यो विशिष्ट जडान रोक्नुहोस्। तलका दुई आदेश नै सम्पूर्ण सफाइ हुन्, र कुनै पनि प्रक्रिया खोज्नमा निर्भर छैन।
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"अन्त्य गर्नु अलगाव होइन: मर्ने रनरले आफ्नो खोलेको टनेल राख्छ, र जबरजस्ती रोकिएको प्रक्रियाले ब्लक पूरै छोड्छ। त्यसैले सफाइको आदेश मात्र सम्पूर्ण डिजाइन हुन सक्दैन। व्यवहारमा यसरी असफल हुन्छ: डिप्लोयमेन्ट काम प्रतिलिपि चरणमा रद्द हुन्छ, अन्त्य ब्लक कहिल्यै चल्दैन, र त्यही होस्टको अर्को काम जीवित टनेल र पुग्न नसकिने सञ्जालतर्फ देखाउने रुटसहित सुरु हुन्छ। विफलता अर्को बिल्डमा 'DNS' समस्याजस्तो देखिन्छ, यो निम्त्याउने काम सकिएको घण्टौंपछि।
कामको आउटपुटमा प्रोफाइलको नाम र प्रमाणको बाटो लेख्नुहोस्। पहिचान नभएको खाली डिस्कनेक्ट आदेश पछि अडिट गर्न गाह्रो हुन्छ। लगको लाइनले पनि ब्लक चलेको प्रमाण दिन्छ, जब पछिको अन्वेषणले सोध्छ।
कामलाई अरू कसैले नप्रयोग गर्ने होस्ट दिनुहोस्
एकपटक प्रयोग हुने पूर्वाधारले उत्तराधिकारको समस्या व्यवस्थापन गर्नुभन्दा हटाउँछ। हरेक कामका लागि नयाँ एजेन्ट रुट, प्रोफाइल र अरूका प्रमाणबिना सुरु हुन्छ, र त्यसको विनाशले कामले छोडेको सबै सफा गर्छ। यसले हरेक बिल्डमा बढी खर्च गर्छ, र सफाइ कोडमा निर्भर नहुने सीमाको यो इमानदार मूल्य हो। उत्पादन सञ्जाल छुने कामका लागि, घटना गनेपछि सामान्यतया यही सस्तो विकल्प हो।
जहाँ साझा रनर रहनैपर्छ, त्यहाँ असफलता र रद्दलाई सफल प्रतिलिपिजत्तिकै होसियारीसाथ परीक्षण गर्नुहोस्। परीक्षणले यो काम आधा बाटोमा रद्द भए अर्को कामले के देख्नेछ भनी देखाउनुपर्छ। काम त्यतिबेला सकिन्छ जब त्यसको पहुँच र अस्थायी अवस्था सकिन्छ, प्रतिलिपि आदेशले शून्य फर्काउँदा होइन।