ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ Bash Script: ຄູ່ມືດ່ວນເພື່ອຄວາມຫນ້າເຊື່ອຖືແລະການປະຕິບັດ Bash Scripts

ຮູບວໍເປເປີ Shell ໂດຍ manapi

Debugging bash scripts ແມ່ນຄ້າຍຄືການຊອກຫາເຂັມໃນ haystack, ໂດຍສະເພາະໃນເວລາທີ່ການເພີ່ມໃຫມ່ປາກົດຢູ່ໃນ codebase ທີ່ມີຢູ່ແລ້ວໂດຍບໍ່ມີການພິຈາລະນາທັນເວລາກ່ຽວກັບບັນຫາຂອງໂຄງສ້າງ, ການຕັດໄມ້ແລະຄວາມຫນ້າເຊື່ອຖື. ທ່ານສາມາດຊອກຫາຕົວທ່ານເອງໃນສະຖານະການດັ່ງກ່າວບໍ່ວ່າຈະເປັນຍ້ອນຄວາມຜິດພາດຂອງທ່ານເອງຫຼືໃນເວລາທີ່ການຄຸ້ມຄອງ piles ສະລັບສັບຊ້ອນ.

ທີມງານ Mail.ru Cloud Solutions ແປບົດຄວາມທີ່ມີຄໍາແນະນໍາທີ່ຈະຊ່ວຍໃຫ້ທ່ານຂຽນ, ແກ້ບັນຫາ ແລະຮັກສາສະຄຣິບຂອງທ່ານໄດ້ດີຂຶ້ນ. ເຊື່ອຫຼືບໍ່, ບໍ່ມີຫຍັງເກີນຄວາມພໍໃຈຂອງການຂຽນລະຫັດ bash ທີ່ສະອາດ, ພ້ອມທີ່ຈະໃຊ້ໄດ້ທຸກຄັ້ງ.

ໃນບົດຂຽນ, ຜູ້ຂຽນໄດ້ແບ່ງປັນສິ່ງທີ່ລາວໄດ້ຮຽນຮູ້ໃນສອງສາມປີຜ່ານມາ, ເຊັ່ນດຽວກັນກັບບາງຂໍ້ຜິດພາດທົ່ວໄປທີ່ເຮັດໃຫ້ລາວຫລີກລ້ຽງ. ນີ້ແມ່ນສິ່ງສໍາຄັນເພາະວ່າຜູ້ພັດທະນາຊອບແວທຸກຄົນ, ໃນບາງຈຸດໃນການເຮັດວຽກຂອງພວກເຂົາ, ເຮັດວຽກກັບສະຄິບເພື່ອອັດຕະໂນມັດວຽກງານປົກກະຕິ.

ຈັບກັບດັກ

ສະຄຣິບ bash ສ່ວນໃຫຍ່ທີ່ຂ້ອຍພົບບໍ່ເຄີຍໃຊ້ກົນໄກການເຮັດຄວາມສະອາດທີ່ມີປະສິດທິພາບເມື່ອມີບາງສິ່ງບາງຢ່າງທີ່ບໍ່ຄາດຄິດເກີດຂື້ນໃນລະຫວ່າງການປະຕິບັດ script.

ຄວາມແປກໃຈສາມາດເກີດຂື້ນຈາກພາຍນອກ, ເຊັ່ນວ່າໄດ້ຮັບສັນຍານຈາກແກນ. ການຈັດການກໍລະນີດັ່ງກ່າວແມ່ນມີຄວາມສໍາຄັນທີ່ສຸດເພື່ອຮັບປະກັນວ່າສະຄິບມີຄວາມຫນ້າເຊື່ອຖືພຽງພໍທີ່ຈະດໍາເນີນການໃນລະບົບການຜະລິດ. ຂ້ອຍມັກຈະໃຊ້ຕົວຈັດການທາງອອກເພື່ອຕອບສະໜອງຕໍ່ກັບສະຖານະການເຊັ່ນນີ້:

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 ແມ່ນຄຳສັ່ງທີ່ສ້າງຂຶ້ນໃນແກະທີ່ຊ່ວຍໃຫ້ທ່ານລົງທະບຽນຟັງຊັນທຳຄວາມສະອາດທີ່ຖືກເອີ້ນໃນກໍລະນີມີສັນຍານໃດໆ. ຢ່າງໃດກໍຕາມ, ການດູແລພິເສດຄວນໄດ້ຮັບການປະຕິບັດກັບ handlers ເຊັ່ນ SIGINT, ເຊິ່ງເຮັດໃຫ້ script ຍົກເລີກ.

ນອກຈາກນັ້ນ, ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ທ່ານຄວນຈັບພຽງແຕ່ EXIT, ແຕ່ຄວາມຄິດແມ່ນວ່າຕົວຈິງແລ້ວທ່ານສາມາດປັບແຕ່ງພຶດຕິກໍາຂອງ script ສໍາລັບສັນຍານແຕ່ລະຄົນ.

ຟັງຊັນທີ່ກໍານົດໄວ້ໃນຕົວ - ການຢຸດເຊົາໄວຍ້ອນຄວາມຜິດພາດ

ມັນເປັນສິ່ງ ສຳ ຄັນຫຼາຍທີ່ຈະຕອບສະ ໜອງ ຂໍ້ຜິດພາດທັນທີທີ່ເກີດຂື້ນແລະຢຸດການປະຕິບັດຢ່າງໄວວາ. ບໍ່ມີຫຍັງຈະຮ້າຍແຮງໄປກວ່າການສືບຕໍ່ດໍາເນີນການຄໍາສັ່ງເຊັ່ນນີ້:

rm -rf ${directory_name}/*

ກະລຸນາສັງເກດວ່າຕົວແປ directory_name ບໍ່ໄດ້ກໍານົດ.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະນໍາໃຊ້ຫນ້າທີ່ສ້າງໃນເພື່ອຈັດການກັບສະຖານະການດັ່ງກ່າວ setເຊັ່ນ: set -o errexit, set -o pipefail ຫຼື set -o nounset ໃນຕອນຕົ້ນຂອງ script ໄດ້. ຟັງຊັນເຫຼົ່ານີ້ຮັບປະກັນວ່າສະຄິບຂອງທ່ານຈະອອກທັນທີທີ່ມັນພົບກັບລະຫັດອອກທີ່ບໍ່ແມ່ນສູນ, ການນໍາໃຊ້ຕົວແປທີ່ບໍ່ໄດ້ກໍານົດ, ຄໍາສັ່ງທີ່ບໍ່ຖືກຕ້ອງຜ່ານທໍ່, ແລະອື່ນໆ:

#!/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 ເພື່ອກວດຫາຄວາມຜິດພາດໃນລະຫວ່າງການພັດທະນາ

ມັນຄຸ້ມຄ່າທີ່ຈະປະສົມປະສານບາງສິ່ງບາງຢ່າງເຊັ່ນ: ກວດ Shell ເຂົ້າໃນການພັດທະນາແລະການທົດສອບທໍ່ຂອງທ່ານເພື່ອກວດເບິ່ງລະຫັດ bash ຂອງທ່ານຕໍ່ກັບການປະຕິບັດທີ່ດີທີ່ສຸດ.

ຂ້ອຍໃຊ້ມັນຢູ່ໃນສະພາບແວດລ້ອມການພັດທະນາທ້ອງຖິ່ນຂອງຂ້ອຍເພື່ອເອົາບົດລາຍງານກ່ຽວກັບ syntax, semantics, ແລະບາງຂໍ້ຜິດພາດໃນລະຫັດທີ່ຂ້ອຍອາດຈະພາດໃນຂະນະທີ່ພັດທະນາ. ນີ້ແມ່ນເຄື່ອງມືການວິເຄາະ static ສໍາລັບ script 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
}

ຫມາຍເຫດ: ກະລຸນາລະມັດລະວັງໂດຍສະເພາະກັບຊື່ຕົວແປທີ່ທ່ານກໍານົດເພື່ອຫຼີກເວັ້ນການ overriding ຕົວແປສະພາບແວດລ້ອມໂດຍບັງເອີນ.

ຟັງຊັນບັນທຶກ

ການຕັດໄມ້ທີ່ສວຍງາມແລະມີໂຄງສ້າງແມ່ນສໍາຄັນທີ່ຈະເຂົ້າໃຈຜົນໄດ້ຮັບຂອງສະຄິບຂອງທ່ານໄດ້ຢ່າງງ່າຍດາຍ. ເຊັ່ນດຽວກັນກັບພາສາການຂຽນໂປລແກລມລະດັບສູງອື່ນໆ, ຂ້ອຍສະເຫມີໃຊ້ຟັງຊັນບັນທຶກພື້ນເມືອງຢູ່ໃນສະຄິບ 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, ບ່ອນທີ່ຕົວແປ logger ດັ່ງກ່າວແລະຕົວແປລະບົບອື່ນໆແມ່ນເລີ່ມຕົ້ນຫຼືຕັ້ງເປັນຄ່າເລີ່ມຕົ້ນ. ຕົວແປເຫຼົ່ານີ້ຍັງສາມາດຖືກຕັ້ງຈາກຕົວເລືອກແຖວຄໍາສັ່ງໃນລະຫວ່າງການເອີ້ນ script.

ສໍາລັບຕົວຢ່າງ, ບາງສິ່ງບາງຢ່າງເຊັ່ນ:

$ ./run-script.sh --debug

ເມື່ອ script ດັ່ງກ່າວຖືກປະຕິບັດ, ມັນຮັບປະກັນວ່າການຕັ້ງຄ່າທົ່ວລະບົບຖືກຕັ້ງຄ່າເປັນຄ່າເລີ່ມຕົ້ນຖ້າພວກເຂົາຕ້ອງການ, ຫຼືຢ່າງຫນ້ອຍໄດ້ເລີ່ມຕົ້ນກັບບາງສິ່ງບາງຢ່າງທີ່ເຫມາະສົມຖ້າຈໍາເປັນ.

ຂ້ອຍມັກຈະອີງໃສ່ທາງເລືອກຂອງສິ່ງທີ່ຈະເລີ່ມຕົ້ນແລະສິ່ງທີ່ບໍ່ຄວນເຮັດໃນການຊື້ຂາຍລະຫວ່າງການໂຕ້ຕອບຜູ້ໃຊ້ແລະລາຍລະອຽດການຕັ້ງຄ່າທີ່ຜູ້ໃຊ້ສາມາດ / ຄວນເຈາະເຂົ້າໄປໃນ.

ສະຖາປັດຕະຍະກໍາສໍາລັບການນໍາໃຊ້ຄືນໃຫມ່ແລະສະພາບຂອງລະບົບທີ່ສະອາດ

ລະ​ຫັດ Modular/Reusable

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

ຂ້ອຍຮັກສາບ່ອນເກັບມ້ຽນແຍກຕ່າງຫາກທີ່ຂ້ອຍສາມາດໃຊ້ເພື່ອເລີ່ມຕົ້ນໂຄງການໃຫມ່ / script bash ທີ່ຂ້ອຍຕ້ອງການພັດທະນາ. ສິ່ງໃດກໍ່ຕາມທີ່ສາມາດນໍາໃຊ້ຄືນໄດ້ສາມາດຖືກເກັບໄວ້ໃນ repository ແລະດຶງຂໍ້ມູນໂດຍໂຄງການອື່ນໆທີ່ຕ້ອງການໃຊ້ຟັງຊັນນັ້ນ. ການຈັດຕັ້ງໂຄງການດ້ວຍວິທີນີ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງຂະຫນາດຂອງສະຄິບອື່ນໆແລະຍັງຮັບປະກັນວ່າຖານລະຫັດມີຂະຫນາດນ້ອຍແລະງ່າຍຕໍ່ການທົດສອບ.

ເຊັ່ນດຽວກັບຕົວຢ່າງຂ້າງເທິງ, ຫນ້າທີ່ບັນທຶກທັງຫມົດເຊັ່ນ: __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)"

ຫຼັງຈາກສໍາເລັດການເຮັດວຽກ, ການເຮັດຄວາມສະອາດຂອງໄດເລກະທໍລີດັ່ງກ່າວສາມາດສະຫນອງໃຫ້ຢູ່ໃນຕົວຈັບ hook ທີ່ສົນທະນາຂ້າງເທິງ. ຖ້າໄດເລກະທໍລີຊົ່ວຄາວບໍ່ໄດ້ຮັບການເບິ່ງແຍງ, ພວກມັນສະສົມແລະໃນບາງຂັ້ນຕອນເຮັດໃຫ້ເກີດບັນຫາທີ່ບໍ່ຄາດຄິດໃນເຈົ້າພາບ, ເຊັ່ນ: ແຜ່ນເຕັມ.

ການໃຊ້ໄຟລ໌ລັອກ

ເລື້ອຍໆທ່ານຕ້ອງການໃຫ້ແນ່ໃຈວ່າພຽງແຕ່ຫນຶ່ງຕົວຢ່າງຂອງສະຄິບແມ່ນແລ່ນຢູ່ໃນໂຮດໃນເວລາໃດກໍ່ຕາມ. ນີ້ສາມາດເຮັດໄດ້ໂດຍໃຊ້ໄຟລ໌ລັອກ.

ຂ້ອຍມັກຈະສ້າງໄຟລ໌ lock ໃນ /tmp/project_name/*.lock ແລະກວດເບິ່ງການປະກົດຕົວຂອງພວກເຂົາໃນຕອນຕົ້ນຂອງສະຄຣິບ. ອັນນີ້ຊ່ວຍໃຫ້ສະຄຣິບສິ້ນສຸດຢ່າງສະຫງ່າງາມ ແລະຫຼີກເວັ້ນການປ່ຽນແປງທີ່ບໍ່ຄາດຄິດຕໍ່ກັບສະຖານະຂອງລະບົບໂດຍສະຄຣິບອື່ນທີ່ເຮັດວຽກຂະໜານກັນ. ໄຟລ໌ລັອກບໍ່ຈໍາເປັນຖ້າທ່ານຕ້ອງການ script ດຽວກັນເພື່ອດໍາເນີນການຂະຫນານໃນໂຮດທີ່ກໍານົດໄວ້.

ວັດແທກແລະປັບປຸງ

ພວກເຮົາມັກຈະຕ້ອງເຮັດວຽກກັບ scripts ທີ່ໃຊ້ໃນໄລຍະຍາວ, ເຊັ່ນ: ການດໍາເນີນງານຂອງຖານຂໍ້ມູນປະຈໍາວັນ. ການດໍາເນີນງານດັ່ງກ່າວໂດຍປົກກະຕິປະກອບດ້ວຍລໍາດັບຂອງຂັ້ນຕອນ: ການໂຫຼດຂໍ້ມູນ, ການກວດສອບຄວາມຜິດປົກກະຕິ, ການນໍາເຂົ້າຂໍ້ມູນ, ການສົ່ງລາຍງານສະຖານະການ, ແລະອື່ນໆ.

ໃນກໍລະນີດັ່ງກ່າວ, ຂ້າພະເຈົ້າສະເຫມີພະຍາຍາມທໍາລາຍສະຄິບເປັນສະຄິບຂະຫນາດນ້ອຍແຍກຕ່າງຫາກແລະລາຍງານສະຖານະແລະເວລາປະຕິບັດຂອງເຂົາເຈົ້າໂດຍໃຊ້:

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

ຕໍ່ມາຂ້ອຍສາມາດເຫັນເວລາປະຕິບັດດ້ວຍ:

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

ນີ້ຊ່ວຍໃຫ້ຂ້ອຍລະບຸບັນຫາ / ພື້ນທີ່ຊ້າໃນສະຄິບທີ່ຕ້ອງການການເພີ່ມປະສິດທິພາບ.

ໂຊກດີ!

ມີຫຍັງອີກແດ່ທີ່ຈະອ່ານ:

1. ໄປແລະຖານຄວາມຈໍາ GPU.
2. ຕົວຢ່າງຂອງແອັບພລິເຄຊັນທີ່ຂັບເຄື່ອນດ້ວຍເຫດການໂດຍອີງໃສ່ webhooks ໃນການເກັບຮັກສາວັດຖຸ S3 ຂອງ Mail.ru Cloud Solutions.
3. ຊ່ອງທາງໂທລະເລກຂອງພວກເຮົາກ່ຽວກັບການຫັນເປັນດິຈິຕອນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com