Bash-skripti parim praktika: lühike juhend usaldusväärsete ja efektiivsete bash-skriptide jaoks

Shelli taustafoto autor manapi

Bash-skriptide tõrkeotsing on nagu nõela otsimine heinas, eriti kui olemasolevas koodibaasis ilmuvad uued lisandused, ilma et struktuuri, logimise ja usaldusväärsuse küsimusi õigel ajal arutletaks. Sellistes olukordades võib sattuda probleemidesse nii oma vigade tõttu kui ka keeruliste skriptikogumite haldamisel.

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

Artiklis jagab autor oma viimaste aastate jooksul omandatud teadmisi ja mõningaid levinud vigu, mis on teda ootamatult kätte saanud. See on oluline, sest iga tarkvaraarendaja töötab oma karjääri teatud etapis skriptidega rutiinsete tööülesannete automatiseerimiseks.

Püügihaldurid

Enamikest bash-skripti, millega olen kokku puutunud, ei ole kunagi kasutatud tõhusat puhastusmehhanismi, kui skripti käivitamise ajal tekib midagi ootamatut.

Ootamatuseid võib tekkida väljastpoolt, näiteks tuumalt signaali saamise tõttu. Selliste olukordade käsitlemine on äärmiselt oluline, et skriptid oleksid piisavalt usaldusväärsed tootmisse süsteemides. Kasutan sageli väljumisprotseduure, et reageerida sellistes olukordades:

function handle_exit() {
  	// Lisa siia puhastuskood
  	// näiteks rm -f "/tmp/${lock_file}.lock"
  	// välju sobiva olekukoodiga
}
  
// trap  
trap handle_exit 0 SIGHUP SIGINT SIGQUIT SIGABRT SIGTERM

trap — on sisseehitatud käsk shellis, mis aitab sul registreerida puhastusfunktsiooni, mis kutsutakse esile mistahes signaalide korral. Kuid tuleb olla ettevaatlik selliste käitlejate puhul nagu SIGINT, mis põhjustab skripti katkestamist.

Lisaks tuleks enamikul juhtudel püüda ainult EXIT, kuid idee on see, et sa saad tõeliselt kohandada skripti käitumist iga konkreetse signaali jaoks.

Sisseehitatud funktsioonid set — kiire lõpetamine vea korral

On oluline reageerida vigadele kohe, kui need ilmnevad, ja kiiresti lõpetada töö. Pole midagi hullemat kui jätkata sellise käsu täitmist:

rm -rf ${directory_name}/*

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

Selliste stsenaariumide käitlemiseks 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äitmise kohe, kui ta kohtab mis tahes mitte-null lõpetamiskoodi, määramata muutujaid, valeid käske, mis on edastatud toru 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 täitmise, kui ilmneb „töötlemata” tagastuskoode (välja arvatud null). Seetõttu on parem luua kohandatud veahaldus, 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

Selline skriptide kirjutamine kutsub teid üles paremini tähelepanu pöörama igasuguste käskude käitumisele skriptis ja arvestama võimalike vigade tekkimisega enne, kui need teid üllatavad.

ShellCheck vigade tuvastamiseks arendamise käigus

Tasub integreerida midagi sellist nagu ShellCheck teie arendus- ja testimisprotsessidesse, et kontrollida oma bash-koodi parimate praktikate järgimist.

Ma kasutan seda oma kohalikes arenduskeskkondades, et saada aruandeid süntaksist, semantikast ja mõningatest vigadest koodis, mille ma arendamise käigus olen võinud tähelepanuta jätta. See on statilise analüüsi tööriist teie bash-skriptide jaoks, mida ma soovitan tungivalt kasutada.

Oma exit-koodide kasutamine

POSIX-i tagastuskoodid ei ole lihtsalt null või üks, vaid null või mitte-null väärtus. Kasutage neid võimalusi kasutajate vigade koode (vahemikus 201-254) erinevate viga olukordade jaoks.

Seda teavet saab seejärel kasutada teiste skriptide poolt, mis ümbritsevad teie skripti, et täpselt mõista, millist tüüpi viga on juhtunud, 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 ettevaatlikud muutuja nimedega, mida te määratlete, et vältida keskkonnaparameetrite juhuslikku ülekirjutamist.

Logifunktsioonid

Ilus ja struktureeritud logimine on oluline, et mõista teie skripti täitmise tulemusi. Nagu teiste kõrgema taseme programmeerimiskeelte puhul, kasutan ma alati oma bash-skripte kirjutades isiklikke logimisfunktsioone, näiteks __msg_info, __msg_error ja nii edasi.

See aitab tagada standardiseeritud logistruktuuri, muutes väärtusi 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"

Püüan tavaliselt oma skripte kirjutades kasutada mingisugust mehhanismi __init, kus sellised loggeri muutujad ja muud süsteemimuutujad initsialiseeritakse või seatakse vaikimisi väärtustesse. Need muutujad võivad samuti saada väärtusi käsurea parameetritest skripti käivitamise ajal.

Näiteks midagi sellist:

$ ./run-script.sh --debug

Kui sellist skripti käitatakse, on tagatud, et süsteemi üldised seaded on seatud vaikimisi väärtustesse, kui need on kohustuslikud, või vähemalt initsialiseeritud millegagi sobivaga, kui see on vajalik.

Olen tavaliselt valikute tegemisel, mida initsialiseerida ja mida mitte, kompromissi kasutajaliidese ja konfiguratsiooni detailide vahel, millesse kasutaja peab süvenema.

Taaskasutatava ja puhta süsteemi arhitektuur

Modulaarne / korduvkasutatav kood

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

Hoian eraldi repositooriumi, mida saab kasutada uue projekti / bash skripti initsialiseerimiseks, mida soovin arendada. Kõik, mida saab taaskasutada, saab salvestada repositooriumisse ja kasutada teistes projektides, mis soovivad selliseid funktsioone kasutada. Selline projektide korraldamine vähendab oluliselt teiste skriptide suurust ning tagab, et koodibaas on väike ja lihtsalt testitav.

Nagu ülaltoodud näites, sisaldavad kõik logimisfunktsioonid, nagu __msg_info, __msg_error ja muud, näiteks Slacki raportid, on eraldi common/* ja laaditakse dünaamiliselt teistes stsenaariumites, nagu daily_database_operation.sh.

Jätke pärast end puhta süsteemiga

Kui laadite skripti täitmise ajal mõned ressursid üles, on soovitatav hoida kõiki selliseid andmeid ühises kataloogis, millel on juhuslik nimi, näiteks /tmp/AlRhYbD97/*. Saate kasutada juhusliku teksti genereerijaid katalooge nime valimiseks:

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

Töö lõpetamisel võib selliste kataloogide puhastamine olla tagatud ülaltoodud lõksude käitlejates. Kui ajutiste kataloogide hooldamine unustatakse, võivad need koguneda ja teatud hetkel põhjustada ootamatuid probleeme hostis, näiteks täis ketas.

Lukufailide kasutamine

Tihti on vajalik tagada, et hostis töötaks korraga ainult üks skripti eksemplar. Seda saab teha lukufailide abil.

Ma tavaliselt loon lukufailid /tmp/project_name/*.lock ja kontrollin nende olemasolu skripti alguses. See aitab skripti õigesti lõpetada ja vältida süsteemi oleku ootamatuid muutusi teise paralleelselt töötava skripti poolt. Lukufailid pole vajalikud, kui peate kindlustama, et sama skript käivituks paralleelselt antud hostis.

Mõõtke ja parandage

Me peame sageli töötama stsenaariumitega, mis kestavad pikema aja, näiteks igapäevased andmebaasi toimingud. Need toimingud hõlmavad tavaliselt järgmisi samme: andmete laadimine, anomaaliate kontrollimine, andmete importimine, olekuteate saatmine ja nii edasi.

Sellistel juhtudel püüan alati stsenaariumi jagada väikesteks skriptideks ja edastada nende olekut ning täitmise aega järgmiste abil:

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

Hiljem saan ma vaatada täitmise aega järgmise abil:

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

See aitab mul välja selgitada probleemsed/aeglased kohad skriptides, mis vajavad optimeerimist.

Edu!

Mida veel lugeda:

1. Go ja GPU vahemälu.
2. Näide sündmustest juhitud rakendusest, mis põhineb veebikonksudel objekti S3 ladustamises Mail.ru Pilveteenustes.
3. Meie telegrammi kanal digitaalse transformatsiooni kohta.

Allikas: habr.com