🥇बैश स्क्रिप्ट सर्वोत्तम अभ्यास: विश्वसनीय, प्रदर्शन बैश स्क्रिप्ट के लिए एक त्वरित मार्गदर्शिका

मनापी द्वारा शैल वॉलपेपर

बैश स्क्रिप्ट को डिबग करना भूसे के ढेर में सुई ढूंढने जैसा है, खासकर जब संरचना, लॉगिंग और विश्वसनीयता के मुद्दों पर समय पर विचार किए बिना मौजूदा कोडबेस में नए जोड़ दिखाई देते हैं। आप या तो अपनी गलतियों के कारण या स्क्रिप्ट के जटिल ढेर का प्रबंधन करते समय खुद को ऐसी स्थितियों में पा सकते हैं।

टीम Mail.ru क्लाउड सॉल्यूशंस अनुशंसाओं के साथ एक लेख का अनुवाद किया गया है जो आपको अपनी स्क्रिप्ट को बेहतर ढंग से लिखने, डिबग करने और बनाए रखने में मदद करेगा। विश्वास करें या न करें, हर बार काम करने वाले स्वच्छ, उपयोग के लिए तैयार बैश कोड लिखने की संतुष्टि से बढ़कर कुछ नहीं है।

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

जाल संचालक

जब स्क्रिप्ट निष्पादन के दौरान कुछ अप्रत्याशित घटित होता है, तो मेरे सामने आई अधिकांश बैश स्क्रिप्ट कभी भी प्रभावी सफाई तंत्र का उपयोग नहीं करती हैं।

आश्चर्य बाहर से उत्पन्न हो सकता है, जैसे कोर से संकेत प्राप्त करना। ऐसे मामलों को संभालना यह सुनिश्चित करने के लिए बेहद महत्वपूर्ण है कि स्क्रिप्ट उत्पादन प्रणालियों पर चलने के लिए पर्याप्त विश्वसनीय हैं। मैं अक्सर इस तरह के परिदृश्यों पर प्रतिक्रिया देने के लिए निकास हैंडलर का उपयोग करता हूं:

function handle_exit() {
  // Add cleanup code here
  // for eg. rm -f "/tmp/${lock_file}.lock"
  // exit with an appropriate status code
}
  
// trap <HANDLER_FXN> <LIST OF SIGNALS TO TRAP>
trap handle_exit 0 SIGHUP SIGINT SIGQUIT SIGABRT SIGTERM

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

इसके अलावा, ज्यादातर मामलों में आपको केवल पकड़ना चाहिए EXIT, लेकिन विचार यह है कि आप वास्तव में प्रत्येक व्यक्तिगत सिग्नल के लिए स्क्रिप्ट के व्यवहार को अनुकूलित कर सकते हैं।

अंतर्निहित सेट फ़ंक्शंस - त्रुटि पर त्वरित समाप्ति

त्रुटियों के घटित होते ही तुरंत प्रतिक्रिया देना और निष्पादन को तुरंत रोकना बहुत महत्वपूर्ण है। इस तरह से कमांड चलाना जारी रखने से बुरा कुछ नहीं हो सकता:

rm -rf ${directory_name}/*

कृपया ध्यान दें कि वेरिएबल directory_name निर्धारित नहीं है।

ऐसे परिदृश्यों को संभालने के लिए अंतर्निहित फ़ंक्शंस का उपयोग करना महत्वपूर्ण है set, जैसे कि set -o errexit, set -o pipefail या set -o nounset स्क्रिप्ट की शुरुआत में. ये फ़ंक्शन यह सुनिश्चित करते हैं कि जैसे ही आपकी स्क्रिप्ट किसी गैर-शून्य निकास कोड, अपरिभाषित चर के उपयोग, पाइप के माध्यम से पारित अमान्य आदेशों आदि का सामना करेगी, वह बाहर निकल जाएगी:

#!/usr/bin/env bash

set -o errexit
set -o nounset
set -o pipefail

function print_var() {
  echo "${var_value}"
}

print_var

$ ./sample.sh
./sample.sh: line 8: var_value: unbound variable

नोट: जैसे अंतर्निहित कार्य set -o errexit, जैसे ही कोई "कच्चा" रिटर्न कोड (शून्य के अलावा) होगा, स्क्रिप्ट से बाहर निकल जाएगा। इसलिए कस्टम त्रुटि प्रबंधन शुरू करना बेहतर है, उदाहरण के लिए:

#!/bin/bash
error_exit() {
  line=$1
  shift 1
  echo "ERROR: non zero return code from line: $line -- $@"
  exit 1
}
a=0
let a++ || error_exit "$LINENO" "let operation returned non 0 code"
echo "you will never see me"
# run it, now we have useful debugging output
$ bash foo.sh
ERROR: non zero return code from line: 9 -- let operation returned non 0 code

इस तरह से स्क्रिप्ट लिखना आपको स्क्रिप्ट में सभी कमांड के व्यवहार के बारे में अधिक सावधान रहने और आपको आश्चर्यचकित करने से पहले त्रुटि की संभावना का अनुमान लगाने के लिए मजबूर करता है।

विकास के दौरान त्रुटियों का पता लगाने के लिए शेलचेक

यह कुछ इस तरह एकीकृत करने लायक है शेलचेक सर्वोत्तम प्रथाओं के विरुद्ध अपने बैश कोड की जांच करने के लिए अपने विकास और परीक्षण पाइपलाइनों में।

मैं इसका उपयोग अपने स्थानीय विकास परिवेशों में सिंटैक्स, शब्दार्थ और कोड में कुछ त्रुटियों पर रिपोर्ट प्राप्त करने के लिए करता हूं जो विकास के दौरान मुझसे छूट गई थीं। यह आपकी बैश स्क्रिप्ट के लिए एक स्थिर विश्लेषण उपकरण है और मैं इसका उपयोग करने की अत्यधिक अनुशंसा करता हूं।

अपने स्वयं के निकास कोड का उपयोग करना

POSIX में रिटर्न कोड केवल शून्य या एक नहीं हैं, बल्कि शून्य या गैर-शून्य मान हैं। विभिन्न त्रुटि मामलों के लिए कस्टम त्रुटि कोड (201-254 के बीच) वापस करने के लिए इन सुविधाओं का उपयोग करें।

इस जानकारी का उपयोग अन्य स्क्रिप्ट्स द्वारा किया जा सकता है जो आपको यह समझने के लिए लपेटती हैं कि वास्तव में किस प्रकार की त्रुटि हुई और तदनुसार प्रतिक्रिया करें:

#!/usr/bin/env bash

SUCCESS=0
FILE_NOT_FOUND=240
DOWNLOAD_FAILED=241

function read_file() {
  if ${file_not_found}; then
    return ${FILE_NOT_FOUND}
  fi
}

नोट: कृपया आपके द्वारा परिभाषित वेरिएबल नामों के साथ विशेष रूप से सावधान रहें ताकि आकस्मिक रूप से पर्यावरण वेरिएबल्स को ओवरराइड करने से बचा जा सके।

लॉगिंग फ़ंक्शन

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

यह केवल एक ही स्थान पर परिवर्तन करके एक मानकीकृत लॉगिंग संरचना प्रदान करने में मदद करता है:

#!/usr/bin/env bash

function __msg_error() {
    [[ "${ERROR}" == "1" ]] && echo -e "[ERROR]: $*"
}

function __msg_debug() {
    [[ "${DEBUG}" == "1" ]] && echo -e "[DEBUG]: $*"
}

function __msg_info() {
    [[ "${INFO}" == "1" ]] && echo -e "[INFO]: $*"
}

__msg_error "File could not be found. Cannot proceed"

__msg_debug "Starting script execution with 276MB of available RAM"

मैं आमतौर पर अपनी स्क्रिप्ट में किसी प्रकार का तंत्र रखने का प्रयास करता हूं __init, जहां ऐसे लॉगर वेरिएबल्स और अन्य सिस्टम वेरिएबल्स को आरंभीकृत किया जाता है या डिफ़ॉल्ट मानों पर सेट किया जाता है। इन वेरिएबल्स को स्क्रिप्ट इनवोकेशन के दौरान कमांड लाइन विकल्पों से भी सेट किया जा सकता है।

उदाहरण के लिए, कुछ इस प्रकार:

$ ./run-script.sh --debug

जब ऐसी स्क्रिप्ट निष्पादित की जाती है, तो यह सुनिश्चित करती है कि यदि आवश्यक हो तो सिस्टम-व्यापी सेटिंग्स डिफ़ॉल्ट मानों पर सेट की जाती हैं, या यदि आवश्यक हो तो कम से कम किसी उपयुक्त चीज़ के लिए प्रारंभ की जाती हैं।

मैं आम तौर पर उपयोगकर्ता इंटरफ़ेस और कॉन्फ़िगरेशन के विवरण के बीच एक ट्रेड-ऑफ़ पर क्या आरंभ करना है और क्या नहीं करना है, इस विकल्प को आधार बनाता हूं, जिसमें उपयोगकर्ता को गहराई से जाना चाहिए।

पुन: उपयोग और स्वच्छ प्रणाली की स्थिति के लिए वास्तुकला

मॉड्यूलर/पुन: प्रयोज्य कोड

├── framework
│   ├── common
│   │   ├── loggers.sh
│   │   ├── mail_reports.sh
│   │   └── slack_reports.sh
│   └── daily_database_operation.sh

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

जैसा कि ऊपर दिए गए उदाहरण में है, सभी लॉगिंग फ़ंक्शंस जैसे __msg_info, __msg_error और अन्य, जैसे स्लैक रिपोर्ट, अलग से शामिल हैं common/* और अन्य परिदृश्यों में गतिशील रूप से जुड़ें daily_database_operation.sh.

अपने पीछे एक स्वच्छ व्यवस्था छोड़ें

यदि आप स्क्रिप्ट चलने के दौरान कोई संसाधन लोड कर रहे हैं, तो ऐसे सभी डेटा को एक यादृच्छिक नाम के साथ साझा निर्देशिका में संग्रहीत करने की अनुशंसा की जाती है, उदाहरण के लिए /tmp/AlRhYbD97/*. आप निर्देशिका नाम का चयन करने के लिए यादृच्छिक टेक्स्ट जेनरेटर का उपयोग कर सकते हैं:

rand_dir_name="$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 16 | head -n 1)"

काम पूरा होने के बाद, ऊपर चर्चा किए गए हुक हैंडलर में ऐसी निर्देशिकाओं की सफाई प्रदान की जा सकती है। यदि अस्थायी निर्देशिकाओं पर ध्यान नहीं दिया जाता है, तो वे जमा हो जाती हैं और किसी स्तर पर होस्ट पर अप्रत्याशित समस्याएं पैदा करती हैं, जैसे कि पूर्ण डिस्क।

लॉक फ़ाइलों का उपयोग करना

अक्सर आपको यह सुनिश्चित करने की आवश्यकता होती है कि किसी भी समय होस्ट पर स्क्रिप्ट का केवल एक ही उदाहरण चल रहा हो। यह लॉक फ़ाइलों का उपयोग करके किया जा सकता है।

मैं आमतौर पर लॉक फ़ाइलें बनाता हूं /tmp/project_name/*.lock और स्क्रिप्ट की शुरुआत में उनकी उपस्थिति की जाँच करें। यह स्क्रिप्ट को शानदार ढंग से समाप्त करने में मदद करता है और समानांतर में चल रही किसी अन्य स्क्रिप्ट द्वारा सिस्टम स्थिति में अप्रत्याशित परिवर्तनों से बचता है। यदि आपको किसी दिए गए होस्ट पर समान स्क्रिप्ट को समानांतर में निष्पादित करने की आवश्यकता है तो लॉक फ़ाइलों की आवश्यकता नहीं है।

मापें और सुधारें

हमें अक्सर उन स्क्रिप्ट्स के साथ काम करने की आवश्यकता होती है जो लंबे समय तक चलती हैं, जैसे दैनिक डेटाबेस संचालन। इस तरह के ऑपरेशन में आम तौर पर चरणों का एक क्रम शामिल होता है: डेटा लोड करना, विसंगतियों की जांच करना, डेटा आयात करना, स्थिति रिपोर्ट भेजना, इत्यादि।

ऐसे मामलों में, मैं हमेशा स्क्रिप्ट को अलग-अलग छोटी स्क्रिप्ट में तोड़ने का प्रयास करता हूं और उनकी स्थिति और निष्पादन समय का उपयोग करके रिपोर्ट करता हूं:

time source "${filepath}" "${args}">> "${LOG_DIR}/RUN_LOG" 2>&1

बाद में मैं निष्पादन समय देख सकता हूँ:

tac "${LOG_DIR}/RUN_LOG.txt" | grep -m1 "real"

इससे मुझे स्क्रिप्ट में समस्या/धीमे क्षेत्रों की पहचान करने में मदद मिलती है जिन्हें अनुकूलन की आवश्यकता होती है।

भाग्य अच्छा है!

और क्या पढ़ें:

स्रोत: www.habr.com

बैश स्क्रिप्टिंग सर्वोत्तम अभ्यास: विश्वसनीय और प्रदर्शन बैश स्क्रिप्ट के लिए एक त्वरित मार्गदर्शिका