Най-добри практики за Bash скриптове: Бързо ръководство за надеждни и производителни Bash скриптове

Shell тапет от manapi

Отстраняването на грешки в bash скриптове е като търсене на игла в купа сено, особено когато се появят нови допълнения в съществуващата кодова база без своевременно разглеждане на проблемите на структурата, регистрирането и надеждността. Можете да попаднете в такива ситуации поради собствени грешки или когато управлявате сложни купчини скриптове.

Отбор Облачни решения на Mail.ru преведе статия с препоръки, които ще ви помогнат да пишете, отстранявате грешки и поддържате по-добре вашите скриптове. Вярвате или не, нищо не може да се сравни с удоволствието от писането на чист, готов за използване bash код, който работи всеки път.

В статията авторът споделя какво е научил през последните няколко години, както и някои често срещани грешки, които са го хванали неподготвен. Това е важно, защото всеки разработчик на софтуер в даден момент от кариерата си работи със скриптове за автоматизиране на рутинни работни задачи.

Манипулатори на капани

Повечето 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 е вградена команда в shell, която ви помага да регистрирате функция за почистване, която се извиква в случай на някакви сигнали. Въпреки това трябва да се внимава с манипулатори като напр 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 за откриване на грешки по време на разработката

Струва си да интегрирате нещо подобно Проверка на черупката във вашите канали за разработка и тестване, за да проверите вашия 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. Go и GPU кешове.
2. Пример за управлявано от събития приложение, базирано на уеб кукички в хранилището на обекти S3 на Mail.ru Cloud Solutions.
3. Нашият телеграм канал за дигиталната трансформация.

Източник: www.habr.com