બેશ સ્ક્રિપ્ટીંગ શ્રેષ્ઠ પ્રેક્ટિસ: વિશ્વસનીય અને પ્રદર્શન બેશ સ્ક્રિપ્ટ્સ માટે ઝડપી માર્ગદર્શિકા

મનાપી દ્વારા શેલ વૉલપેપર

બેશ સ્ક્રિપ્ટને ડીબગ કરવું એ ઘાસની ગંજીમાંથી સોય શોધવા જેવું છે, ખાસ કરીને જ્યારે બંધારણ, લોગીંગ અને વિશ્વસનીયતાના મુદ્દાઓને સમયસર ધ્યાનમાં લીધા વિના હાલના કોડબેઝમાં નવા ઉમેરાઓ દેખાય છે. તમે તમારી પોતાની ભૂલોને લીધે અથવા સ્ક્રિપ્ટના જટિલ ઢગલાનું સંચાલન કરતી વખતે આવી પરિસ્થિતિઓમાં તમારી જાતને શોધી શકો છો.

ટીમ 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"

આ મને સ્ક્રિપ્ટ્સમાં સમસ્યા/ધીમા વિસ્તારોને ઓળખવામાં મદદ કરે છે જેને ઑપ્ટિમાઇઝેશનની જરૂર હોય છે.

સારા નસીબ!

બીજું શું વાંચવું:

1. જાઓ અને GPU કેશ.
2. Mail.ru ક્લાઉડ સોલ્યુશન્સના S3 ઑબ્જેક્ટ સ્ટોરેજમાં વેબહુક્સ પર આધારિત ઇવેન્ટ-આધારિત એપ્લિકેશનનું ઉદાહરણ.
3. ડિજિટલ ટ્રાન્સફોર્મેશન વિશે અમારી ટેલિગ્રામ ચેનલ.

સોર્સ: www.habr.com