Bash-skriptide parimad tavad: lühike juhend usaldusväärsete ja efektiivsete bash-skriptide loomiseks

Shelli taustapilt manapi poolt

Bash-skriptide tõrkeotsing on nagu nõela otsimine heinas, eriti kui olemasolevas koodibaasis ilmuvad uued lisandused ilma struktuuri, logimise ja usaldusväärsuse küsimuste õigeaegse kaalumiseta. Sellistes olukordades võib tekkida probleeme nii oma vigade tõttu kui ka keerukate skriptide haldamisel.

Meeskond Mail.ru Pilve Lahendused tõlkis artikli soovitustega, mis aitavad teil paremini kirjutada, tõrkeotsingut teha ja oma skripte hallata. Usuge või mitte, aga mitte miski ei saa võrreldagi rahuloluga, mida toob puhta, kasutamiseks valmis bash-koodi kirjutamine, mis töötab iga kord.

Artiklis jagab autor teavet, mida on ta viimase paar aasta jooksul õppinud, ning mõned levinud vead, mis on teda üllatanud. See on oluline, kuna iga tarkvaraarendaja töötab mingil hetkel oma karjääris skriptidega, et automatiseerida rutiinseid tööülesandeid.

Püüdja käsitlejad

Enamik bash-skripte, millega olen kokku puutunud, ei ole kunagi kasutanud tõhusat puhastusmechanismi, kui skripti käivitamise ajal juhtub midagi ootamatut.

Ootamatud olukorrad võivad tekkida väljastpoolt, näiteks kui tuum saadab signaali. Sarnaste olukordade käsitlemine on äärmiselt oluline, et skriptid oleksid piisavalt usaldusväärsed tootmisüsteemides käitamiseks. Kasutan sageli väljapääsukäsitlejaid, et reageerida järgmistele olukordadele:

function handle_exit() {
  // Lisa siia puhastuskood
  // näiteks rm -f "/tmp/${lock_file}.lock"
  // lahkuge sobiva olekukoodiga
}
  
// püüdke <HANDLER_FXN> <SIGNALITE LOETEL ÕIGUS>
püüdke handle_exit 0 SIGHUP SIGINT SIGQUIT SIGABRT SIGTERM

trap — on sisseehitatud käsu shellis, mis aitab teil registreerida puhastamisfunktsiooni, mida kutsutakse esile, kui mõni signaal ilmneb. Tuleks siiski olla erilise ettevaatlikkusega selliste käsitlejate osas nagu SIGINT, mis kutsub skripti katkestama.

Lisaks peaks enamikul juhtudel püüdma ainult EXIT, aga idee on selles, et saate tõeliselt kohandada skripti käitumist iga eraldi signaali jaoks.

Sisseehitatud funktsioonid set — kiire lõpetamine, kui ilmneb viga

On oluline reageerida vigadele kohe, kui need ilmnevad, ja kiiresti katkestada täitmine. Mitte midagi ei saa olla halvem kui jätkata sellise käsu täitmist:

rm -rf ${directory_name}/*

Pange tähele, et muutuja directory_name ei ole määratud.

Selliste stsenaariumide käsitlemiseks on oluline kasutada sisseehitatud funktsioone set, nagu set -o errexit, set -o pipefail või set -o nounset skripti alguses. Need funktsioonid tagavad, et teie skript lõpetab töö, kui see kohtab mingit mitte-null lõpetamiskoodi, määramata muutujaid, valeid käske, mis edastatakse kanalite kaudu jne:

#!/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

Märkus: sisseehitatud funktsioonid, nagu set -o errexit, lõpetavad skripti, kui ilmneb "töötlemata" tagastusväärtus (välja arvatud null). Seetõttu on parem luua kohandatud vigade töötlemine, näiteks:

#!/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

Selliste skriptide kirjutamine paneb teid hoolikalt jälgima kõigi skripti käskude käitumist ja arvestama, et viga võib tekkida enne, kui see teid üllatab.

ShellCheck vigade tuvastamiseks arendamise ajal

Tasub integreerida midagi sellist nagu ShellCheck oma arendus- ja testimisprotsessidesse, et kontrollida oma bash-koodi parimate praktikate rakendamise osas.

Kasutangi seda oma kohalikus arenduskeskkonnas, et saada aruandeid süntaksist, semantikast ja mõnest koodiveast, mis olen arendamise käigus võinud vahele jätta. See on staatilise analüüsi tööriist teie bash-skriptide jaoks ja soovitan selle rakendamist.

Oma väljundkoodide kasutamine

Väljastamisnumbri koodid POSIXis ei ole lihtsalt null või üks, vaid null või mitte-null väärtus. Kasutage neid võimalusi, et tagastada kohandatud veakoodid (vahemikus 201–254) erinevate veatüüpide jaoks.

Seda teavet saab seejärel kasutada teiste skriptide poolt, mis teie ümber pakendavad, et täpselt mõista, milline veatüüp toimus, ja reageerida vastavalt:

#!/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
}

Märkus: palun olge eriti ettevaatlik, milliseid muutujaid te määrate, et mitte juhuslikult keskkonnamuutujaid üle kirjutada.

Logifunktsioonid

Ilus ja struktureeritud logimine on oluline, et mõista teie skripti täitmise tulemusi. Nagu teistes kõrgemates programmeerimiskeeltes, kasutan ma alati oma bash skriptides logimise funktsioone, näiteks __msg_info, __msg_error ja nii edasi.

See aitab tagada standardiseeritud logistruktuuri, tehes muudatusi ainult ühes kohas:

#!/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"

Ma püüan tavaliselt oma skriptides omada mingit mehhanismi __init, kus sellised logeri muutujad ja teised süsteemimuutujad initsialiseeritakse või seatakse vaikimisi väärtustesse. Need muutujad võivad samuti olla seatud käivitusargumentide kaudu skripti käivitamise ajal.

Näiteks midagi sellist:

$ ./run-script.sh --debug

Kui selline skript käivitatakse, on tagatud, et süsteemiasetused on seatud vaikimisi väärtustesse, kui need on kohustuslikud, või vähemalt initsialiseeritud millegagi sobivaga, kui see on vajalik.

Ma põhjan tavaliselt oma valikut, mida initsialiseerida ja mida mitte, kompromissile kasutajaliidese ja konfiguratsioonide detailide vahel, millesse kasutaja võib/peab süvenema.

Arhitektuur taaskasutamise ja puhta süsteemi jaoks

Modulaarne / korduvkasutatav kood

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

Hoian eraldi hoidlat, mida saab kasutada uue bash projekti/skripti initsialiseerimiseks, mida soovin arendada. Kõik, mida saab uuesti kasutada, võib olla salvestatud hoidlas ja saadud teistes projektides, mis tahavad selliseid funktsioone kasutada. Selline projektide korraldus vähendab oluliselt teiste skriptide suurust ning tagab, et koodibaas on väike ja hõlpsasti testitav.

Nagu eespool toodud näites, sisaldavad kõik logimisfunktsioonid, näiteks __msg_info, __msg_error ja muud, näiteks Slacki aruanded, on eraldi common/* ja tõmmatakse dünaamiliselt teistes skriptides, nagu daily_database_operation.sh.

Jätke enda järel puhas süsteem

Kui laadite skripti käitamise ajal mingeid ressursse, on soovitatav hoida kõik sellised andmed üldises kataloogis juhusliku nimega, näiteks /tmp/AlRhYbD97/*Saate kasutada juhuslike tekstide genereerijaid, et valida katalooge nimi:

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

Pärast töö lõpetamist saab selliste kataloogide puhastamine tagada ülaltoodud lõksu töötlejates. Kui ajutiste kataloogide puhusele ei hoolitseta, kogunevad need ja mingil hetkel põhjustavad ootamatuid probleeme hostis, näiteks täis kõvaketas.

Lock-failide kasutamine

Sageli on vajalik tagada, et hostis oleks igal hetkel käimas ainult üks skript. Seda saab teha lock-failide abil.

Ma loon tavaliselt lock-failid /tmp/project_name/*.lock ja kontrollin nende olemasolu skripti alguses. See aitab skripti õigesti lõpetada ja vältida ootamatuid süsteemi oleku muutusi, kui teine skript töötab paralleelselt. Lock-failid ei ole vajalikud, kui peate sama skripti käivitama paralleelselt antud hostis.

Mõõtke ja parandage

Peame sageli töötama skriptidega, mis töötavad pikka aega, näiteks igapäevaste andmebaasi toimingutega. Need toimingud hõlmavad tavaliselt tegevuste järjestust: andmete laadimine, anomaaliate kontrollimine, andmete importimine, olekuteate saatmine jne.

Sellistes olukordades püüan alati skripti jagada eraldi väikesteks skriptideks ja edastada nende olek ja täitmise aeg järgmistel viisidel:

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

Hiljem saan vaadata täitmise aega järgmistel viisidel:

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

See aitab mul määrata probleemseid/aeglaseid kohti skriptides, mis vajavad optimeerimist.

Edu!

Mida veel lugeda:

1. Go ja GPU vahemälud.
2. Näide sündmustepõhisest rakendusest veebihookide põhjal Mail.ru Cloud Solutions objekti S3-hoidlas.
3. Meie Telegrami kanal digitaalse transformatsiooni kohta.

Allikas: habr.com