שיטות מומלצות ל-Bash Scripting: מדריך מהיר לתסריטי Bash אמינים וביצועיים

טפט מעטפת מאת manapi

איתור באגים בסקריפטים של bash הוא כמו לחפש מחט בערימת שחת, במיוחד כאשר תוספות חדשות מופיעות בבסיס הקוד הקיים ללא התחשבות בזמן בבעיות של מבנה, רישום ואמינות. אתה יכול למצוא את עצמך במצבים כאלה או בגלל הטעויות שלך או בעת ניהול ערימות מורכבות של סקריפטים.

קבוצה פתרונות ענן של Mail.ru תרגם מאמר עם המלצות שיעזרו לך לכתוב, לנפות באגים ולתחזק את התסריטים שלך בצורה טובה יותר. תאמינו או לא, שום דבר לא מנצח את הסיפוק של כתיבת קוד 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 היא פקודה מובנית של מעטפת המסייעת לך לרשום פונקציית ניקוי הנקראת במקרה של אותות כלשהם. עם זאת, יש לנקוט זהירות מיוחדת עם מטפלים כגון 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 לתוך צינורות הפיתוח והבדיקה שלך כדי לבדוק את קוד ה-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

אני שומר מאגר נפרד שבו אוכל להשתמש כדי לאתחל פרויקט/סקריפט bash חדש שאני רוצה לפתח. כל דבר שניתן לעשות בו שימוש חוזר יכול להיות מאוחסן במאגר ולאחזר על ידי פרויקטים אחרים שרוצים להשתמש בפונקציונליות הזו. ארגון פרויקטים כך מפחית משמעותית את גודלם של סקריפטים אחרים וגם מבטיח שבסיס הקוד קטן וקל לבדיקה.

כמו בדוגמה למעלה, כל פונקציות הרישום כגון __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 caches.
2. דוגמה לאפליקציה מונעת אירועים המבוססת על webhooks באחסון האובייקטים S3 של Mail.ru Cloud Solutions.
3. ערוץ הטלגרם שלנו על טרנספורמציה דיגיטלית.

מקור: www.habr.com