ការអនុវត្តល្អបំផុតនៃស្គ្រីប Bash: ការណែនាំរហ័សចំពោះស្គ្រីប Bash ដែលអាចទុកចិត្តបាន និងដំណើរការ

ផ្ទាំងរូបភាពសែលដោយ manapi

ការបំបាត់កំហុសស្គ្រីប bash គឺដូចជាការស្វែងរកម្ជុលនៅក្នុងវាលស្មៅ ជាពិសេសនៅពេលដែលការបន្ថែមថ្មីលេចឡើងនៅក្នុងមូលដ្ឋានកូដដែលមានស្រាប់ដោយមិនបានពិចារណាទាន់ពេលវេលាអំពីបញ្ហានៃរចនាសម្ព័ន្ធ ការកាប់ឈើ និងភាពជឿជាក់។ អ្នក​អាច​ឃើញ​ខ្លួន​អ្នក​ស្ថិត​ក្នុង​ស្ថានភាព​បែប​នេះ​ដោយ​សារ​កំហុស​ផ្ទាល់​ខ្លួន​របស់​អ្នក​ឬ​នៅ​ពេល​ដែល​គ្រប់គ្រង​គំនរ​ស្គ្រីប​ដ៏​ស្មុគស្មាញ។

ក្រុមការងារ ដំណោះស្រាយពពក Mail.ru បកប្រែអត្ថបទដែលមានការណែនាំដែលនឹងជួយអ្នកក្នុងការសរសេរ បំបាត់កំហុស និងរក្សាស្គ្រីបរបស់អ្នកបានប្រសើរជាងមុន។ ជឿឬមិនជឿ គ្មានអ្វីដែលអាចយកឈ្នះការពេញចិត្តនៃការសរសេរកូដ bash ស្អាត និងរួចរាល់សម្រាប់ប្រើ ដែលដំណើរការរាល់ពេល។

នៅក្នុងអត្ថបទនេះ អ្នកនិពន្ធចែករំលែកនូវអ្វីដែលគាត់បានរៀនក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ ក៏ដូចជាកំហុសទូទៅមួយចំនួនដែលធ្វើអោយគាត់មានការប្រុងប្រយ័ត្ន។ នេះមានសារៈសំខាន់ណាស់ ពីព្រោះអ្នកបង្កើតកម្មវិធីគ្រប់រូប នៅចំណុចខ្លះក្នុងអាជីពរបស់ពួកគេ ធ្វើការជាមួយស្គ្រីប ដើម្បីធ្វើស្វ័យប្រវត្តិកម្មការងារជាប្រចាំ។

ឧបករណ៍ចាប់អន្ទាក់

ស្គ្រីប 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 ដើម្បីរកមើលកំហុសកំឡុងពេលអភិវឌ្ឍន៍

វាមានតម្លៃរួមបញ្ចូលអ្វីមួយដូចជា សែលឃេក ទៅក្នុងការអភិវឌ្ឍន៍ និងសាកល្បងបំពង់បង្ហូរប្រេងរបស់អ្នក ដើម្បីពិនិត្យមើលកូដ 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ដែលជាកន្លែងដែលអថេរ logger បែបនេះ និងអថេរប្រព័ន្ធផ្សេងទៀតត្រូវបានចាប់ផ្តើម ឬកំណត់ទៅជាតម្លៃលំនាំដើម។ អថេរទាំងនេះក៏អាចត្រូវបានកំណត់ពីជម្រើសបន្ទាត់ពាក្យបញ្ជាកំឡុងពេលហៅស្គ្រីប។

ឧទាហរណ៍អ្វីមួយដូចជា៖

$ ./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. ទៅ​និង​ឃ្លាំង​សម្ងាត់ GPU ។
2. ឧទាហរណ៍នៃកម្មវិធីដែលជំរុញដោយព្រឹត្តិការណ៍ផ្អែកលើ webhooks នៅក្នុងកន្លែងផ្ទុកវត្ថុ S3 នៃ Mail.ru Cloud Solutions ។
3. ប៉ុស្តិ៍ទូរលេខរបស់យើងអំពីការផ្លាស់ប្តូរឌីជីថល។

ប្រភព: www.habr.com