स्क्रिप्ट और ऑटोमेशन जेनरेशन: बैश, पायथन और पावरशेल

लाभ:

• बैश, पायथन और पावरशेल की शक्तियों को समझने की क्षमता और कृत्रिम बुद्धिमत्ता सुरक्षित, संरक्षित स्क्रिप्ट ड्राफ्ट तैयार करती है
• सेट-यूओ पाइपफेल, खाली वेरिएबल चेकिंग, ड्राई-रन मोड और लॉगिंग जैसी स्क्रिप्ट में रेलिंग जोड़ने की क्षमता
• विनाशकारी आदेशों को पढ़ने और उन्हें एक अलग वातावरण में और पहले ड्राई-रन के साथ आज़माने की क्षमता, और स्क्रिप्ट में रहस्य को एम्बेड न करने का अनुशासन लागू करने की क्षमता।

DevOps की भावना को एक वाक्य में संक्षेपित किया गया है: "जो काम आप दो बार करते हैं उसे स्वचालित करें।" कोई भी दोहराव वाला कार्य जो मैन्युअल रूप से किया जाता है - लॉग क्लीनअप, बैकअप लेना, सर्वर स्वास्थ्य जांच, बैच फ़ाइल प्रोसेसिंग - समय लगता है और अंततः मानवीय त्रुटि से दूषित हो जाता है। स्क्रिप्ट्स इन कार्यों को संभालती हैं: छोटे प्रोग्राम जो अनुक्रमिक, विश्वसनीय और दोहराए जाने योग्य तरीके से आदेशों की एक श्रृंखला को निष्पादित करते हैं। DevOps पेशेवर अक्सर तीन भाषाओं का उपयोग करता है: बैश (लिनक्स/यूनिक्स शेल स्क्रिप्ट के लिए), पायथन (जटिल तर्क, एपीआई कॉलिंग, डेटा हेरफेर के लिए), और पावरशेल (विंडोज़ और क्लाउड प्रबंधन के लिए)।

एआई शायद वह जगह है जहां यह स्क्रिप्ट निर्माण में सबसे व्यावहारिक मूल्य प्रदान करता है: एक-वाक्य विवरण से एक कार्यशील ड्राफ्ट तैयार करना, एक रहस्यमय बग को हल करना, एक स्क्रिप्ट का दूसरी भाषा में अनुवाद करना। लेकिन एक स्क्रिप्ट आँख बंद करके चलाने पर खतरनाक होती है - एक गलत आरएम, एक रिमूव-आइटम -रिकर्स फ़ाइलों को अपरिवर्तनीय रूप से हटा देगा। इसीलिए इस इकाई का आदर्श वाक्य है: एआई को स्क्रिप्ट लिखने दें, आप इसे पढ़ें, पहले इसे सुरक्षित मोड में आज़माएं, फिर इसे चलाएं।

कौन सी भाषा चुनें और कब? अंगूठे का एक मोटा नियम: यदि कार्य में एक पंक्ति में कई सिस्टम कमांड चलाना शामिल है (फ़ाइल कॉपी करें, सेवा पुनरारंभ करें, संग्रह पुनर्प्राप्त करें) बैश सबसे स्वाभाविक विकल्प है क्योंकि लिनक्स सर्वर पर सर्वव्यापी है। यदि कार्य में निर्णय तर्क, लूपिंग, डेटा परिवर्तन, एपीआई का अनुरोध करना, या JSON प्रसंस्करण शामिल है - यानी, 20 लाइनों से अधिक तर्क - पायथन अपनी पठनीयता और समृद्ध पुस्तकालयों के लिए खड़ा है; एक जटिल बैश स्क्रिप्ट जल्दी ही समझ से बाहर हो जाती है, जबकि पायथन को बनाए रखना आसान रहता है। यदि कार्य में विंडोज़ सर्वर, सक्रिय निर्देशिका, या एज़्योर का प्रबंधन शामिल है, तो पावरशेल प्राकृतिक वातावरण है क्योंकि इसकी ऑब्जेक्ट-ओरिएंटेड प्रकृति इन प्लेटफार्मों के साथ गहराई से एकीकृत होती है। एआई से स्क्रिप्ट का अनुरोध करते समय यह निर्दिष्ट करना कि आपने कौन सी भाषा चुनी और क्यों, यह सुनिश्चित करता है कि आउटपुट आपके वातावरण के लिए उपयुक्त और मुहावरेदार है।

चरण दर चरण: सुरक्षित स्क्रिप्ट निर्माण

1. कार्य और वातावरण का वर्णन करें. यह क्या करेगा, कौन सा ओएस/शेल, क्या बाधाएं?
2. सुरक्षा रेलिंग के लिए पूछें. बैश में, सेट -यूओ पाइपफेल (त्रुटि पर रोकें, अपरिभाषित चर पर रोकें), खतरनाक संचालन के लिए पुष्टिकरण संकेत, हटाने के बजाय पहले आगे बढ़ें।
3. ड्राई-रन मोड का अनुरोध करें। स्क्रिप्ट को यह लिखने दें कि --ड्राई-रन के साथ क्या करना है, लेकिन ऐसा न करें।
4. पढ़ें और समझें। सत्यापित करें कि प्रत्येक पंक्ति क्या करती है, विशेष रूप से डिलीट/मूव/नेटवर्क ऑपरेशंस।
5. इसे एकांत वातावरण में आज़माएँ। परीक्षण फ़ोल्डर में, इसे नमूना डेटा के साथ चलाएँ।
6. लॉगिंग में जोड़ें. स्क्रिप्ट जो करती है उसे रिकॉर्ड करने दें ताकि उसे बाद में देखा जा सके।

सुरक्षित स्क्रिप्टिंग की अनिवार्यताएँ

एक प्रोडक्शन स्क्रिप्ट में ये रेलिंग शामिल होनी चाहिए:

• त्रुटि होने पर रुकना। बैश: सेट -यूओ पाइपफेल। पॉवरशेल: $ErrorActionPreference = 'रोकें'। यदि एक कदम विफल हो जाता है, तो अगला कदम भी काम नहीं करना चाहिए।
• निरर्थकता (दोहराव)। यदि स्क्रिप्ट दो बार चलती है, तो इससे दोहरा नुकसान नहीं होना चाहिए; "यदि आपके पास यह पहले से ही है, तो इसे छोड़ दें" तर्क।
• अनुमोदन एवं ड्राई-रन। विनाशकारी कार्रवाइयों के लिए "क्या आप निश्चित हैं?" या --ड्राई-रन ध्वज.
• इनपुट सत्यापन. क्या पैरामीटर अपेक्षा के अनुरूप हैं? एक खाली वैरिएबल rm -rf "$DIR"/ को rm -rf / आपदा में बदल सकता है।
• लॉगिंग. क्या किया गया और कब किया गया इसका रिकार्ड।

टिप: बैश में सबसे खतरनाक गलती एक खाली वेरिएबल को हटाना है। rm -rf "$DIR" $DIR खाली होने पर रूट निर्देशिका को हटाने का प्रयास करता है। सेट -यू (अपरिभाषित वेरिएबल पर रोकें) और हटाने से पहले जांचना [ -n "$DIR" ] एक जीवनरक्षक है। एआई से स्क्रिप्ट का अनुरोध करते समय स्पष्ट रूप से इन सुरक्षाओं का अनुरोध करें।

सुरक्षा: गुप्त और विनाशकारी आदेश

दो बड़े खतरे:

1. रहस्य को स्क्रिप्ट में एम्बेड करना। टोकन स्क्रिप्ट के भीतर पासवर्ड प्लेनटेक्स्ट नहीं होना चाहिए; पर्यावरण चर या वॉल्ट से पढ़ा जाना चाहिए। स्क्रिप्ट Git में जाती हैं; दफ़न रहस्य स्थायी रिसाव है.
2. विनाशकारी आदेश. आरएम -आरएफ, रिमूव-आइटम -रिकर्स -फोर्स, ड्रॉप टेबल, टेराफॉर्म नष्ट - जब आप इन्हें किसी स्क्रिप्ट में देखते हैं, तो रुकें और दो बार सोचें। पहले कभी भी उत्पाद में एआई द्वारा उत्पन्न विनाशकारी कमांड का प्रयास न करें।

सावधानी: जब आप एआई को "एक ऐसी स्क्रिप्ट लिखने के लिए कहते हैं जो इन फ़ाइलों को साफ करती है", तो उसके द्वारा उत्पन्न खोज ... -डिलीट या आरएम कमांड के दायरे को ध्यान से पढ़ें। एक वाइल्डकार्ड (*) या गलत पथ आप जितना हटाना चाहते हैं उससे अधिक हटा देगा। स्क्रिप्ट को हमेशा डिलीट करने के बजाय "लिस्ट टू डिलीट" मोड के साथ पहले चलाएं।

तीन भाषाओं की तुलना

कसौटी

बैश

अजगर

पॉवरशेल

जहां यह सबसे अच्छा है

लिनक्स शेल, कमांड चेन

जटिल तर्क, एपीआई, डेटा

विंडोज़ क्लाउड प्रबंधन

सीखने की अवस्था

मध्यम (फँसा हुआ)

आसान

मध्यम

त्रुटि प्रबंधन

सेट -यूओ पाइपफेल

प्रयास करें/छोड़ें

प्रयास करें/पकड़ें, -ErrorAction

सुवाह्यता

यूनिक्स/लिनक्स/मैक

हर जगह

क्रॉस-प्लेटफ़ॉर्म (पीएस 7+)

कब

संक्षेप में, सिस्टम काम करता है

20 पंक्तियों से अधिक लंबा तर्क

विंडोज़/एडी/एज़्योर

तीन मिनी मामले

केस 1 - 2 घंटे का शिल्प 5 मिनट में। एक इंजीनियर हर हफ्ते 40 सर्वरों से लॉग इकट्ठा करने और संग्रहीत करने में 2 घंटे खर्च कर रहा था। उन्होंने एआई को कार्य का वर्णन करने और -यूओ पाइपफेल + ड्राई-रन सुरक्षा सेट करने और एक बैश स्क्रिप्ट उत्पन्न करने के लिए कहा था। पहले स्क्रिप्ट को ड्राई-रन के साथ सत्यापित किया, फिर इसे निर्धारित कार्य (क्रोन) से जोड़ा। साप्ताहिक कार्य को घटाकर 5 मिनट कर दिया गया है और मानवीय त्रुटि समाप्त हो गई है।

केस 2 - शून्य परिवर्तनीय आपदा टल गई। AI द्वारा निर्मित सफाई स्क्रिप्ट में rm -rf "$TARGET"/* था, लेकिन यदि TARGET को कहीं निर्दिष्ट नहीं किया गया था, तो यह खाली रहता था। इंजीनियर की पढ़ाई के दौरान उन्हें इसका एहसास हुआ; सेट -u और [ -n "$TARGET" ] || निकास 1 नियंत्रण जोड़ा गया। परीक्षण के दौरान वेरिएबल शून्य रहा और स्क्रिप्ट विनाशकारी होने के बजाय सुरक्षित रूप से रुक गई।

केस 3 - एंबेडेड टोकन कैप्चर किया गया। सुविधा के लिए, AI ने Python स्क्रिप्ट में एक TOKEN = "ghp_realtoken" लाइन जोड़ी है जो API का अनुरोध करती है (उदाहरण के तौर पर)। इंजीनियर ने इसे हटा दिया और इसे os.environ["TOKEN"] के साथ पर्यावरण चर से पढ़ने में बदल दिया और टोकन को रद्द और नवीनीकृत किया। यदि स्क्रिप्ट Git के पास गई, तो टोकन सार्वजनिक हो जाएगा।

चार प्रतिलिपि योग्य टेम्पलेट

1) सुरक्षित बैश स्क्रिप्ट:

एक बैश स्क्रिप्ट लिखें: [कार्य]। अनिवार्य नियम:- शुरुआत में `सेट -यूओ पाइपफेल`।- जांचें कि जहां भी हटा/स्थानांतरित किया जा रहा है, वहां वेरिएबल खाली नहीं है।- `--ड्राई-रन` ध्वज: लिखें कि इस मोड में क्या करना है लेकिन ऐसा न करें।- रहस्य को एम्बेड न करें; पर्यावरण चर से पढ़ें. - प्रत्येक चरण पर सूचनात्मक लॉग प्रिंट करें। स्क्रिप्ट पर टिप्पणी करें और सबसे खतरनाक पंक्ति को चिह्नित करें।

2) स्क्रिप्ट विवरण/नियंत्रण:

निम्नलिखित स्क्रिप्ट का लाइन-दर-लाइन वर्णन करें और सुरक्षा की जांच करें: एम्बेडेड गुप्त, विनाशकारी कमांड (आरएम/रिमूव-आइटम/ड्रॉप), अमान्य इनपुट, त्रुटि प्रबंधन की कमी? प्रत्येक जोखिम को महत्व और सुधार के क्रम में लिखें। स्क्रिप्ट: [कोड]

3) भाषा अनुवाद:

उस [स्रोत भाषा] स्क्रिप्ट का [लक्ष्य भाषा] में अनुवाद करें। व्यवहार को शब्दशः बनाए रखें, लक्ष्य भाषा की मुहावरेदार त्रुटि प्रबंधन का उपयोग करें, किसी भी एम्बेडेड रहस्य को पर्यावरण चर में स्थानांतरित करें। उन बिंदुओं पर ध्यान दें जो अलग-अलग व्यवहार कर सकते हैं। स्क्रिप्ट: [CODE]

4) नियोजित कार्य (क्रोन/अनुसूचित कार्य):

इस स्क्रिप्ट का उपयोग करें [आवृत्ति: उदा. एक शेड्यूल परिभाषा लिखें ([क्रॉन/सिस्टमडी टाइमर/विंडोज टास्क शेड्यूलर]) जो [हर रात 02:00 बजे] चलेगी। विफलता पर मुझे कैसे चेतावनी दें (लॉग/एग्जिट कोड/अधिसूचना) और ओवरलैप को कैसे रोकें, जोड़ें।

कमजोर संकेत/मजबूत संकेत

कमजोर: "एक स्क्रिप्ट लिखें जो पुरानी फ़ाइलों को हटा देती है।"

परिणाम: एक स्कोपलेस, असुरक्षित, ड्राई-रनलेस आरएम स्क्रिप्ट; यदि यह गलत फ़ोल्डर में चलता है, तो यह अपरिवर्तनीय रूप से हटा दिया जाएगा।

सशक्त: "/var/log/app के अंतर्गत 30 दिनों से अधिक पुरानी .log फ़ाइलों को हटाने के लिए एक बैश स्क्रिप्ट लिखें। set -euo Pipefail का उपयोग करें, यदि लक्ष्य निर्देशिका खाली है तो रोकें, पहले --dry-run के साथ क्या हटाना है इसकी सूची बनाएं, प्रत्येक लेनदेन को लॉग करें, रहस्य को एम्बेड न करें। सबसे खतरनाक रेखा को चिह्नित करें।"

अंतर: दूसरा दावा पूरी गुंजाइश, सुरक्षा रेलिंग और ड्राई-रन की अपेक्षा देता है; आउटपुट को सुरक्षित रूप से चलाया जा सकता है।

सामान्य गलतियाँ

• स्क्रिप्ट को बिना पढ़े चलाना। विशेष रूप से पंक्तियों को हटाने/स्थानांतरित करने से आपदा उत्पन्न होती है।
• खाली चरों की जाँच नहीं की जा रही है। rm -rf "$X"/ के साथ रूट निर्देशिका को हटाने की क्लासिक आपदा।
• `set -euo Pipefail` / `-ErrorAction Stop` छोड़ें। एक कदम आगे बढ़ता है, स्क्रिप्ट आँख मूँद कर चलती रहती है।
• रहस्य को स्क्रिप्ट में एम्बेड करना। Git में लगातार रिसाव।
• ड्राई-रन के बिना विनाशकारी प्रक्रिया। पहले "मुझे दिखाओ कि क्या करना है", फिर करो।
• उत्पाद में पहला प्रयास कर रहा हूँ। पृथक परीक्षण वातावरण के बिना चल रहा है।

सारांश

DevOps स्वचालन की कला है; दोहराए जाने वाले कार्य को बैश, पायथन और पॉवरशेल स्क्रिप्ट को सौंपा गया है। एआई स्क्रिप्ट तैयार करने, डिबगिंग और भाषाओं का अनुवाद करने में बहुत उपयोगी है - लेकिन एक सुरक्षित स्क्रिप्ट में सेट-यूओ पाइपफेल, नल वैरिएबल चेकिंग, ड्राई-रन मोड, एम्बेडेड सीक्रेटलेसनेस और लॉगिंग जैसे त्रुटि गार्ड शामिल होने चाहिए। यह आपकी ज़िम्मेदारी है कि प्रत्येक स्क्रिप्ट को पढ़ें और परीक्षण करें, विशेष रूप से विनाशकारी कमांड वाली, एक अलग वातावरण में और पहले ड्राई-रन करें।

आवेदन कार्य

एक आवर्ती कार्य चुनें (लॉग संग्रह, बैकअप, सफाई)। (1) एआई को "सिक्योर बैश स्क्रिप्ट" टेम्पलेट के साथ एक संरक्षित स्क्रिप्ट तैयार करने को कहें। (2) सुरक्षा के लिए "स्क्रिप्ट विवरण/ऑडिट" टेम्पलेट के समान स्क्रिप्ट की जांच करें और एआई द्वारा चिह्नित सबसे खतरनाक लाइन ढूंढें। (3) पहले परीक्षण फ़ोल्डर में नमूना फ़ाइलों के साथ स्क्रिप्ट को --ड्राई-रन के साथ चलाकर इसके व्यवहार को सत्यापित करें।

चेकलिस्ट

• [ ] मैंने वह कार्य लिखा जो मैं नहीं चाहता, ओएस/शेल और सुरक्षा रेलिंग।
• [ ] स्क्रिप्ट में सेट -यूओ पाइपफेल / -एररएक्शन स्टॉप जैसी त्रुटि है।
• [ ] मैंने हटाने/स्थानांतरित करने से पहले खाली वैरिएबल और इनपुट जांच जोड़ी।
• [ ] विनाशकारी परिचालनों के लिए --ड्राई-रन/पुष्टिकरण तंत्र है।
• [ ] स्क्रिप्ट में कोई रहस्य अंतर्निहित नहीं है; मान पर्यावरण चर/केस से आते हैं।
• [ ] मैंने पहला परीक्षण ड्राई-रन के साथ एक पृथक परीक्षण वातावरण में किया।