Bästa metoder för bash-skript: en kort guide till pålitliga och effektiva bash-skript

Shell-tapet av manapi

Att debugga bash-skript är som att leta efter en nål i en höstack, särskilt när nya tillägg dyker upp i en befintlig kodbas utan att strukturen, loggningen och tillförlitligheten beaktas i tid. I sådana situationer kan man drabbas av både egna misstag och av att hantera komplicerade skriptkaos.

Team Mail.ru Cloud Solutions Jag har översatt en artikel med rekommendationer som hjälper dig att skriva, debugga och upprätthålla dina skript på ett bättre sätt. Tro det eller ej, men ingenting kan jämföras med tillfredsställelsen av att skriva ren, användbar bash-kod som fungerar varje gång.

I artikeln delar författaren med sig av vad han har lärt sig under de senaste åren, samt några vanliga misstag som har överrumplat honom. Detta är viktigt eftersom varje mjukvaruutvecklare vid något tillfälle i sin karriär arbetar med skript för att automatisera rutinuppgifter.

Fångsthållare

De flesta bash-skript jag har stött på har aldrig använt en effektiv rengöringsmekanism när något oväntat inträffar under körning.

Uppgifter kan uppstå utifrån, som att få ett signal från kärnan. Att hantera sådana situationer är oerhört viktigt för att skripten ska vara tillräckligt tillförlitliga för att köras i produktionssystem. Jag använder ofta exit-hanterare för att reagera på sådana scenarier:

function handle_exit() {
  // Lägg till städkod här
  // till exempel rm -f "/tmp/${lock_file}.lock"
  // avsluta med en lämplig statuskod
}
  
// trap  <LISTA ÖVER SIGNALER ATT FÅNGSTI
trap handle_exit 0 SIGHUP SIGINT SIGQUIT SIGABRT SIGTERM

trap är en inbyggd kommandorad i terminalen som hjälper dig att registrera en rengöringsfunktion som kallas vid vissa signaler. Men särskild försiktighet bör iakttas med sådana hanterare som SIGINT, vilket orsakar avbrott i skriptet.

Dessutom bör endast fånga EXIT, men idén är att du faktiskt kan anpassa skriptets beteende för varje specifik signal.

Inbyggda funktioner set – snabb avslutning vid fel

Det är mycket viktigt att reagera på fel så snart de uppstår och snabbt avbryta exekveringen. Det kan inte bli värre än att fortsätta köra ett kommando som detta:

rm -rf ${directory_name}
*

Observera att variabeln directory_name inte är definierad.

För att hantera sådana scenarier är det viktigt att använda inbyggda funktioner set, såsom set -o errexit, set -o pipefail eller set -o nounset i början av skriptet. Dessa funktioner säkerställer att ditt skript avslutas så snart det stöter på vilken icke-noll exitkod som helst, användning av odefinierade variabler, felaktiga kommandon som passerar genom en pipeline och så vidare:

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

Anmärkning: inbyggda funktioner, som set -o errexit, avslutar skriptet så snart det finns en "obehandlad" returkod (utom noll). Därför är det bättre att införa användardefinierad felhantering, till exempel:

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

Att skriva sådana skript får dig att ta en noggrannare hänsyn till beteendet för alla kommandon i skriptet och förutse möjligheten av fel innan de överraskar dig.

ShellCheck för att identifiera fel under utvecklingen

Det är värt att integrera något som ShellCheck i dina utvecklings- och testpipeline för att kontrollera din bash-kod för bästa praxis.

Jag använder det i mina lokala utvecklingsmiljöer för att få rapporter om syntax, semantik och vissa fel i koden som jag kan ha missat under utvecklingen. Det är ett statiskt analysverktyg för dina bash-skript och jag rekommenderar starkt att använda det.

Användning av egna exit-koder

Returkod i POSIX är inte bara noll eller ett, utan noll eller ett icke-nollvärde. Använd dessa möjligheter för att returnera användardefinierade felkoder (mellan 201-254) för olika fel.

Denna information kan sedan användas av andra skript som omsluter ditt, för att exakt förstå vilken typ av fel som inträffade och reagera på lämpligt sätt:

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

Anmärkning: Vänligen var särskilt försiktig med namnen på variabler som du definierar för att undvika oavsiktlig åsidosättning av miljövariabler.

Logger-funktioner

En vacker och strukturerad loggning är viktig för att enkelt förstå resultaten av ditt skripts körning. Precis som i andra högprogrammeringsspråk använder jag alltid egna loggningsfunktioner i mina bash-skript, såsom __msg_info, __msg_error och hämta bilder från dab.semrush.com

Detta hjälper till att säkerställa en standardiserad loggningsstruktur genom att göra ändringar på ett enda ställe:

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

Jag försöker vanligtvis ha någon typ av mekanism i mina skript __init, där sådana loggvariabler och andra systemvariabler initieras eller sätts till standardvärden. Dessa variabler kan också sättas av kommandoradens parametrar vid anrop av skriptet.

Till exempel något i stil med:

$ ./run-script.sh --debug

När ett sådant skript körs, garanteras det att globala inställningar är inställda på standardvärden om de är obligatoriska, eller åtminstone initialiserade med något motsvarande om det är nödvändigt.

Jag baserar vanligtvis mitt val av vad som ska initieras och vad som inte ska initieras på en kompromiss mellan användargränssnittet och konfigurationsdetaljer som användaren kan/ska ta till sig.

Arkitektur för återanvändning och ren systemstatus

Modulär / återanvändbar kod

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

Jag har ett separat arkiv som kan användas för att initiera ett nytt projekt/bash-skript som jag vill utveckla. Allt som kan återanvändas kan sparas i arkivet och hämtas i andra projekt som vill använda sådana funktioner. Sådan projektorganisation minskar avsevärt storleken på andra skript och säkerställer också att kodbasen är liten och lätt att testa.

Som i det ovanstående exemplet finns alla loggningsfunktioner, såsom __msg_info, __msg_error och andra, som Slack-rapporter, lagrade separat i common/* och ansluts dynamiskt i andra scenarier, som daily_database_operation.sh.

Lämna efter dig ett rent system

Om du laddar ner några resurser under skriptets körning, rekommenderas det att lagra alla sådana data i en gemensam katalog med ett slumpmässigt namn, till exempel /tmp/AlRhYbD97/*Du kan använda slumpgeneratorer för att välja ett katalognamn:

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

Efter slutförandet kan rensning av sådana kataloger tillhandahållas i de hanterare som diskuterats ovan. Om temporära kataloger inte tas om hand, ackumuleras de och orsakar oväntade problem på värden, som till exempel en fullständig disk.

Användning av lås-filer

Ofta behöver vi säkerställa att endast en instans av skriptet körs på värden vid varje given tidpunkt. Detta kan göras med hjälp av lås-filer.

Jag brukar skapa lås-filer i /tmp/project_name/*.lock och kontrollerar deras existens i början av skriptet. Detta hjälper till att avsluta skriptet korrekt och undvika oväntade tillstånd i systemet från andra skript som körs parallellt. Lås-filer behövs inte om du behöver att samma skript kan köras parallellt på denna värd.

Mäta och förbättra

Vi arbetar ofta med skript som körs under lång tid, till exempel dagliga databashanteringsoperationer. Sådana operationer inkluderar vanligtvis en sekvens av steg: laddning av data, kontroll för anomalier, import av data, skickande av statusrapporter och så vidare.

I sådana fall försöker jag alltid dela upp skriptet i separata små skript och rapportera deras status och genomförd tid med hjälp av:

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

Senare kan jag se genomförd tid med hjälp av:

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

Det hjälper mig att identifiera problematiska/långsamma områden i skripten som behöver optimeras.

Lycka till!

Vad mer att läsa:

1. Go och GPU-cache.
2. Exempel på en event-driven applikation baserad på webhooks i S3-objekter i Mail.ru Cloud Solutions.
3. Vår Telegram-kanal om digital transformation.

Källa: habr.com