Bash სკრიპტის საუკეთესო პრაქტიკა: სწრაფი გზამკვლევი სანდო და შესრულების Bash სკრიპტებისთვის

Shell ფონი მანაპის მიერ

bash სკრიპტების გამართვა ჰგავს ნემსის ძიებას თივის გროვაში, განსაკუთრებით მაშინ, როდესაც ახალი დამატებები ჩნდება არსებულ კოდების ბაზაში სტრუქტურის, ჭრისა და საიმედოობის საკითხების დროული განხილვის გარეშე. თქვენ შეგიძლიათ აღმოჩნდეთ ასეთ სიტუაციებში ან საკუთარი შეცდომების გამო, ან სკრიპტების რთული გროვის მართვისას.

გუნდი Mail.ru Cloud Solutions თარგმნა სტატია რეკომენდაციებით, რომელიც დაგეხმარებათ დაწეროთ, გამართოთ და უკეთ შეინახოთ თქვენი სკრიპტები. დაიჯერეთ თუ არა, არაფერი აჭარბებს სუფთა, გამოსაყენებლად მზა ბაშ კოდის დაწერის კმაყოფილებას, რომელიც მუშაობს ყოველ ჯერზე.

სტატიაში ავტორი იზიარებს იმას, რაც მან ისწავლა ბოლო რამდენიმე წლის განმავლობაში, ისევე როგორც ზოგიერთ გავრცელებულ შეცდომებს, რომლებმაც ის გაუფრთხილდა. ეს მნიშვნელოვანია, რადგან პროგრამული უზრუნველყოფის ყველა შემქმნელი, თავისი კარიერის გარკვეულ მომენტში, მუშაობს სკრიპტებთან რუტინული სამუშაო ამოცანების ავტომატიზაციისთვის.

ხაფანგის დამმუშავებლები

bash სკრიპტების უმეტესობა, რომელსაც მე შევხვედრივარ, არასდროს იყენებს ეფექტურ გასუფთავების მექანიზმს, როდესაც რაღაც მოულოდნელი ხდება სკრიპტის შესრულების დროს.

სიურპრიზები შეიძლება წარმოიშვას გარედან, როგორიცაა სიგნალის მიღება ბირთვიდან. ასეთი შემთხვევების დამუშავება ძალზე მნიშვნელოვანია იმისთვის, რომ სკრიპტები საკმარისად საიმედო იყოს წარმოების სისტემებზე გასაშვებად. მე ხშირად ვიყენებ გასასვლელის დამმუშავებლებს, რომ ვუპასუხო ასეთ სცენარებს:

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

სკრიპტების ამ გზით დაწერა გაიძულებთ, იყოთ უფრო ფრთხილად სკრიპტის ყველა ბრძანების ქცევასთან დაკავშირებით და განჭვრიტოთ შეცდომის შესაძლებლობა, სანამ ის გაოცებთ.

ShellCheck აღმოაჩინოს შეცდომები განვითარების დროს

ღირს მსგავსი რაღაცის ინტეგრირება ShellCheck თქვენი განვითარებისა და ტესტირების მილსადენებში, რათა შეამოწმოთ თქვენი bash კოდი საუკეთესო პრაქტიკის წინააღმდეგ.

მე მას ვიყენებ ჩემს ადგილობრივ განვითარების გარემოში, რათა მივიღო ანგარიშები სინტაქსის, სემანტიკისა და კოდის ზოგიერთი შეცდომის შესახებ, რომელიც შეიძლება გამომრჩეს შემუშავებისას. ეს არის სტატიკური ანალიზის ინსტრუმენტი თქვენი bash სკრიპტებისთვის და მე გირჩევთ გამოიყენოთ იგი.

საკუთარი გასასვლელი კოდების გამოყენებით

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
}

შენიშვნა: გთხოვთ, განსაკუთრებით ფრთხილად იყოთ თქვენ მიერ განსაზღვრულ ცვლადების სახელებთან, რათა თავიდან აიცილოთ შემთხვევითი გადაფარვა გარემოს ცვლადები.

ჟურნალის ფუნქციები

ლამაზი და სტრუქტურირებული ჟურნალი მნიშვნელოვანია თქვენი სკრიპტის შედეგების ადვილად გასაგებად. როგორც სხვა მაღალი დონის პროგრამირების ენების შემთხვევაში, მე ყოველთვის ვიყენებ ბუნებრივ ჟურნალის ფუნქციებს ჩემს bash სკრიპტებში, როგორიცაა __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 და სხვები, როგორიცაა Slack-ის ანგარიშები, ცალკე მოცემულია 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. ღონისძიებაზე ორიენტირებული აპლიკაციის მაგალითი, რომელიც დაფუძნებულია webhooks-ზე Mail.ru Cloud Solutions-ის S3 ობიექტების საცავში.
3. ჩვენი ტელეგრამის არხი ციფრული ტრანსფორმაციის შესახებ.

წყარო: www.habr.com