Најдобри практики за скриптирање Bash: Брз водич за сигурни и перформанси Bash скрипти

Тапет на школка од манапи

Дебагирањето на баш скриптите е како да барате игла во стог сено, особено кога се појавуваат нови додатоци во постоечката база на кодови без навремено разгледување на прашањата за структурата, евиденцијата и доверливоста. Може да се најдете во такви ситуации или поради ваши сопствени грешки или кога управувате со сложени купишта скрипти.

Тим Mail.ru Cloud Solutions преведе статија со препораки кои ќе ви помогнат да пишувате, дебагирате и подобро да ги одржувате вашите скрипти. Верувале или не, ништо не го надминува задоволството од пишувањето чист, подготвен за употреба баш-код кој работи секој пат.

Во написот, авторот го споделува она што го научил во текот на изминатите неколку години, како и некои вообичаени грешки што го фатиле на стража. Ова е важно бидејќи секој развивач на софтвер, во одреден момент од својата кариера, работи со скрипти за автоматизирање на рутинските работни задачи.

Ракувачи со стапици

Повеќето баш скрипти што сум ги сретнал никогаш не користат ефективен механизам за чистење кога ќе се случи нешто неочекувано за време на извршувањето на скриптата.

Изненадувања може да се појават однадвор, како што е примањето сигнал од јадрото. Ракувањето со такви случаи е исклучително важно за да се осигури дека скриптите се доволно сигурни за да можат да работат на системи за производство. Често користам управувачи за излез за да одговорам на вакви сценарија:

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 во вашите цевководи за развој и тестирање за да го проверите вашиот баш код во однос на најдобрите практики.

Го користам во моите средини за локален развој за да добивам извештаи за синтаксата, семантиката и некои грешки во кодот што можеби сум ги пропуштил додека ги развивав. Ова е алатка за статичка анализа за вашите баш скрипти и топло препорачувам да ја користите.

Користење на сопствените излезни шифри

Кодовите за враќање во 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 а други, како што се извештаите на 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. Одете и кешот на графичкиот процесор.
2. Пример за апликација управувана од настани базирана на веб-куки во складиштето на објекти S3 на Mail.ru Cloud Solutions.
3. Нашиот телеграмски канал за дигитална трансформација.

Извор: www.habr.com