Скрипти в Bash з set -euo pipefail, перехопленням та логуванням

Автоматизація завдань за допомогою Bash — це різниця між системою, яка вимагає постійного моніторингу, та тією, яка просто... Він працює самостійно та сповіщає вас, коли щось піде не так.У середовищах DevOps та системного адміністрування, гарне написання сценаріїв — це не просто ланцюжок КомандиЙдеться про уникнення тихих збоїв, можливість швидкого налагодження та залишення чітких слідів у logs щоб дізнатися, що і коли сталося.

Коли ви починаєте серйозно працювати зі скриптами, виявляєте, що Bash за замовчуванням досить поблажливий: якщо щось піде не так, сценарій зазвичай продовжувати роботу так, ніби нічого не сталося, використовуючи порожні змінні або неповні результатиОсь звідки беруться жахливі історії, такі як усічені резервні копії (для яких бажано Синхронізація за допомогою rsync у Linux), масові видалення через погано побудовані маршрути або розгортання, які здавалися правильними, але зазнали невдачі на півдорозі. Ось чому навчитися правильно його використовувати має такий сенс. set -euo pipefail, перехоплення та пристойна система логування.

Чому Bash залишається ключовим у DevOps

У повсякденній роботі систем та DevOps Bash залишається інструментом, який завжди є: на серверах. Linuxконтейнери, машини CI/CD, скрипти обслуговування… Його найбільша перевага полягає в тому, що Ви не залежите від встановлення середовища виконання або зовнішніх бібліотекЗавдяки оболонкі, яку система вже містить, ви можете автоматизувати все: від перевірок справності до повного розгортання.

Ця перевага має один нюанс: з погано написаними скриптами команда занадто легко може зазнати невдачі, і Решта сценарію продовжується так, ніби все пройшло ідеально.Якщо до цього додати критичні завдання (резервне копіювання, ротацію журналів, видалення файлів, заплановані виконання), ризик не є теоретичним: рано чи пізно щось зламається, а ви навіть не помітите.

Ось чому так важливо, окрім автоматизації, включати її з самого початку. обробка помилок, налагодження та структуроване ведення журналуІ саме тут вступають у гру три елементи, які повторюються в усіх хороших прикладах скриптингу в сучасному Bash: set -euo pipefail, перехоплення та узгоджена система логування.

Практичний приклад: сценарій моніторингу зі суворою обробкою помилок

Дуже корисним шаблоном є створення скрипта моніторингу, який збирає ключову системну інформацію (процесор, пам'ять, диск, мережа, процеси, останні журнали…), а також безпечно виходити з ладу, залишаючи чіткі сліди у файлі журналуЦей тип скрипта можна використовувати вручну, з cron або для підтримки конвеєрів CI/CD.

загальна ідея Загальна ідея полягає в тому, щоб мати скрипт із:

• Суворий режим активовано Використовуйте `set -euo pipefail` для раннього збою та запобігання продовженню роботи в несумісних станах.
• пастка на ERR та сигнали типу INT або TERM записати помилки та прибрати їх перед відходом.
• Централізована функція ведення журналу який записує в консоль файл з позначкою часу та рівнем (INFO, WARNING, ERROR).
• Модульні перевірки Журнали процесора, пам'яті, диска, мережі та системи.
• Додаткове встановлення залежностей такі як sysstat, lm-sensors або net-tools, адаптовані до Debian/Ubuntu або RHEL/CentOS/Fedora.

звичний У сценарії такого типу часто можна побачити щось на кшталт:

• Колірні змінні щоб виділити попередження та помилки в термінал (ЧЕРВОНИЙ, ЗЕЛЕНИЙ, ЖОВТИЙ, СИНІЙ, НК).
• Маршрути, як /var/log/system-monitor.log для загальних журналів та /var/log/system-metrics.log для періодичних показників.
• Налаштовувані пороги сповіщення: наприклад, ALERT_CPU_THRESHOLD=80, ALERT_MEM_THRESHOLD=80, ALERT_DISK_THRESHOLD=85.
• Un інтервал моніторингу MONITOR_INTERVAL для повторення перевірок кожні X секунд, якщо ви запускаєте скрипт у циклі.

На основі цього створюється надійний скрипт, який не лише збирає інформацію, але й Він правильно реагує на збої, залишає чіткі докази та може бути інтегрований у більші процеси..

Активуйте суворий режим: встановіть -euo pipefail та захистіть IFS

Більшість «дивних» проблем у Bash виникають через те, що оболонка за замовчуванням Він не вважає серйозним, що команда не виконується або змінна не існує.Щоб забезпечити безпечнішу поведінку, часто активується те, що багато хто називає «суворим режимом Bash».

Основні компоненти цього суворого режиму:

• множина -e: призводить до завершення скрипта, щойно команда повертає код виходу, відмінний від 0, за винятком деяких спеціальних контекстів (if, while, &&, ||…).
• встановити -u o встановити -o іменник: викликає помилку, коли ви намагаєтеся використати змінну, яка не визначена, замість того, щоб розглядати її як порожній рядок.
• set -o pipefail: створює код виходу в конвеєрі, який є кодом першої команди, що завершилася невдало, а не лише останньої.
• IFS=$'\n\t': обмежує внутрішній роздільник полів розривом рядка та табуляцією, щоб запобігти розриву пробілів циклами for через списки файлів або подібні дії.

Поєднання всього призводить до чогось дуже поширеного в заголовку серйозних скриптів:

set -euo pipefail
IFS=$'\n\t' надійне узголів'я ліжка

Це запобігає ситуаціям, коли проміжна команда в конвеєрі завершується невдачею, але виконання скрипта продовжується, оскільки остання команда повертає 0. Це також запобігає... змінні з орфографічними помилками або невизначені змінні мовчки перетворюються на порожні рядки, що часто є джерелом неправильних шляхів або логічних умов, які ніколи не виконуються.

Пастки set -e: чому це не магія і може зламати ваш скрипт

Хоча це й дуже корисно, set -e не є панацеєюЙого поведінка має нюанси, які можуть вразити, якщо ви не розумієте, як це працює. Наприклад, деякі конструкції, такі як:

• Команди всередині if, while o until.
• вирази с && y || для контролю потоку.
• Деякі арифметичні розклади.

Вони не призводять до «негайного виходу», якого ви могли б очікувати. Класичним прикладом є арифметичне розкладання з пост-інкрементом:

((contador++))

Арифметичне розкладання повертає значення, яке Bash інтерпретує як код виходу. У випадку пост-інкременту, коли вираз повертає 0, це вважається успішним, але в інших випадках він може повертати 1, що з set -e призводить до того, що скрипт тут і завершитьсяЩось таке невинне, як лічильник всередині циклу, може призвести до передчасного завершення роботи вашого скрипта.

На противагу цьому, такі конструкції, як ((++i)) або ((i+=1)) Вони поводяться по-різному та не викликають однакову проблему. Це показує, що З set -e вам потрібно добре знати конструкції, які ви використовуєтетому що є багато пограничних випадків.

Тому кілька авторів та досвідчених адміністраторів рекомендують використовувати set -e, особливо під час тестування...як агресивний спосіб пошуку слабких місць, але у виробництві вони віддають перевагу більш явному підходу: ручній перевірці вихідних кодів та точно вирішити, коли і як сценарій буде перервано.

пастка: фіксує помилки та сигнали для їх очищення та належного реєстрування

Команда пастка Це ще один важливий гравець, коли ми говоримо про захисні скрипти в Bash. По суті, він дозволяє вам вказувати, які команди або функції ви хочете виконати, коли оболонка отримує знак або особлива подія (наприклад, ПОМИЛКА або ВИХІД).

типове використання Типове використання trap у надійних скриптах:

• ПОМИЛКА перехоплення 'error_handling_function': виконати логіку обробки помилок одразу після невдалого виконання команди.
• перехоплення 'функція_очищення' INT TERMреагувати на такі сигнали, як CTRL+C (SIGINT) або запити на зупинку (SIGTERM).
• ВИХІД перехоплення 'function_finalization': виконати блок після виходу зі скрипта, незалежно від того, чи все пройшло добре чи ні.

Уявіть собі скрипт, який після отримання комбінації клавіш CTRL+C, замість того, щоб різко зупинитися, викликає функцію очистка що видаляє тимчасові файли, закриває з’єднання або залишає чітке повідомлення в журналах:

trap 'limpieza' TERM INT
function limpieza(){
echo "Ejecutando limpieza, el usuario uso CTRL + C"
# ... lógica de limpieza ...
} профілактичні дії

Цей шаблон особливо корисний у тривалих процесах (резервне копіювання, ETL, розгортання), де вас цікавить мати можливість контрольованого переривання, не залишаючи систему в нестабільному стані.

Що можна і що не можна захопити за допомогою пастки ERR

поширений приклад Багато посібників пропонують використовувати щось на кшталт:

trap 'echo "Error en línea $LINENO" >&2' ERR лінія захоплення

реєструвати несправності за вашим номером лінії. Це нормально, але бажано зрозумійте свої межіПастка може:

• Виконувати додатковий код, коли спрацьовує помилка ERRНаприклад, запис у журнал з датою, скриптом та рядком.
• Отримайте доступ до коду виходу останньої команди за допомогою $?.
• Знати рядок скрипта з $LINENO, дуже корисно для налагодження.

Що це не можна зробити Пастка ERR використовується для "врятування" стандартного виводу помилок (stderr) команди, яка вже виконувалася, якщо ви попередньо не перенаправили її до файлу або дескриптора, який потім можна прочитати. Сама помилка є текстовий потік, а не одне значення.

Деякі шаблони передбачають перенаправлення stderr усього скрипта до тимчасового журналу та, в перехопленні, Додайте заголовок із датою, файлом та рядком. Це дозволяє вам співвіднести цей блок помилок з точкою у скрипті, де стався збій. Це більше роботи, але коли щось аварійно завершує роботу у продакшені, ви цінуєте наявність контексту.

Вхід у Bash: запис лише необхідного, відформатованого та без захаращення

Якщо ви автоматизуєте навіть мінімально критичні завдання, вам потрібно знати що сталося, коли і з яким результатомОсь чому майже всі приклади серйозного написання скриптів зрештою включають централізовану функцію ведення журналу, яка уніфікує формат.

типова функція Типова функція може виглядати так:

log_message() {
local level="$1"
local message="$2"
local timestamp=$(date "+%Y-%m-%d %H:%M:%S")
echo -e "${timestamp} ${message}" | tee -a "$LOG_FILE"
} уніфікований формат

приклади За допомогою чогось подібного ви можете зателефонувати:

• log_message "INFO" "Початок перевірки процесора"
• log_message "ПОПЕРЕДЖЕННЯ" "Використання диска перевищує 85%"
• log_message "ПОМИЛКА" "Не вдалося підключитися до бази даних"

і завжди використовуйте один і той самий формат із чітко позначеною датою та рівнем. трійник Це також дозволяє переглядати повідомлення на екрані та одночасно зберігати його у файлі журналу, що дуже зручно як для інтерактивного використання, так і для подальшого аналізу.

Ще одна гарна практика — розділяти журнали активності (що робить скрипт) та показники або журнали результатів (значення процесора, оперативної пам'яті, диска тощо) у різних файлах. Наприклад:

• /var/log/system-monitor.log для подій та повідомлень.
• /var/log/system-metrics.log для періодичних записів про стан.

сприяє інтеграції Це спрощує передачу даних зовнішнім інструментам, парсерам або навіть рішенням для спостереження без змішування людських повідомлень з машинними даними.

Перевірка стану системи: процесор, пам'ять, диск, мережа та журнали

Дуже поширеним використанням Bash у середовищах Linux є реалізація скрипта "швидкої перевірки системи", який збирає всю необхідну інформацію одночасно. основна інформація для діагностики проблемЦей тип скрипта зазвичай включає кілька блоків:

• Завантаження процесораносити mpstat якщо він доступний (завдяки пакету sysstat), або вдавшись до top у пакетному режимі, щоб отримати зведення про використання процесора.
• Найбільше процесів на процесор: з ps aux --sort=-%cpu | head -n N щоб побачити, що споживає найбільше ресурсів.
• Дисковий простір: з df -h, звертаючи особливу увагу на кореневий розділ та будь-які критично важливі для додатків томи або бази даних (див. як звільнити місце в linux).
• Оперативна пам'ять та пам'ять підкачки: через free -hщоб побачити, скільки використовується, і чи використовується надмірне використання swap.
• Стан мережі: перевірка зовнішнього з'єднання за допомогою запиту ping на відому IP-адресу (зазвичай 8.8.8.8) та отримання списку активних інтерфейсів за допомогою ip addr showта використовуючи такі інструменти, як мережевий кіт (nc/ncat) для більш просунутого тестування.
• Останні системні журнали: малювання останніх ліній за допомогою journalctl -n або еквівалент, для виявлення помилок служби безпосередньо перед запуском скрипта.

Результат зазвичай зберігається у файлі журналу або відображається у форматі на екрані, слугуючи Короткий огляд стану системи які ви можете переглянути самостійно або інтегрувати в інструменти моніторингу.

Автоматичне встановлення залежностей та перевірка привілеїв

передумови Важливою деталлю багатьох скриптів адміністрування є те, що перед тим, як зробити щось серйозне, вони перевіряють виконання двох умов:

• Скрипт працює як корінь (або через південь).
• Необхідні інструменти встановлені залежно від операційної системи.

root-перевірка Перевірка root-доступу зазвичай виконується за допомогою $EUID:

check_root() {
if ; then
log_message "ERROR" "Este script necesita privilegios de root para instalar paquetes."
log_message "WARNING" "Por favor, ejecute con sudo."
exit 1
fi
} Це не спрацює, якщо у вас немає root-прав.

Таким чином, ви уникаєте подальших помилок через недостатні дозволи та надсилаєте чітке повідомлення для користувача з самого початку.

виявити дистрибутив Встановлення залежностей зазвичай підтримується /etc/os-release щоб визначити родину розподілу:

• En Debian / Ubuntu він використовується apt-get для встановлення таких пакетів, як sysstat, lm-sensors, net-tools.
• En CentOS / RHEL / Fedora було б витягнуто dnf o yum з еквівалентними пакетами (lm_sensors, net-tools тощо).

Сповіщення, cron та експорт журналів: переведення скрипта у продакшн

Щойно у вас є достатньо надійний скрипт перевірки або автоматизації, наступним логічним кроком буде інтегрувати це в повсякденне життя:

• Сповіщення електронною поштою, через Slack або інші каналиНаприклад, якщо використання диска перевищує 90%, ви надсилаєте електронного листа за допомогою mailx або вебхука Slack. Типова схема полягає в перевірці значення за допомогою df/awk/sed і, якщо воно перевищує певний поріг, ініціювання сповіщення.
• Періодичне виконання за допомогою cronдодати такий запис 0 8 * * * /ruta/a/script.sh щоб він виконувався щодня у певний час.
• Перенаправлення виводу до файлів журналів: виконати ./script.sh > /var/log/system-check.log 2>&1 якщо ви хочете записати весь стандартний вивід та вивід помилок в один файл.

Важливо розуміти, що якщо ваш сценарій розроблений для зупинись на першій помилці Завдяки `set -euo pipefail`, це означає, що cron або CI/CD конвеєр, який його викликає, чітко побачить ненульовий код виходу коли трапляється збій, що дозволяє запускати процеси відновлення, позначати збірки як невдалі тощо.

Налагодження в Bash: встановлення -x, -v, -ny трасування у файл

Bash не має налагоджувача, як деякі інші мови, але він надає кілька... дуже потужні опції налагодження які, за умови правильного використання, заощаджують багато годин на роздуми про те, чому це відбувається?:

• множина -x o встановити -o xtrace: відображає кожну виконану команду з усіма її параметрами, що вже розгорнуті. Ідеально підходить для перегляду фактичних значень змінних.
• встановити -v o встановити -o багатослівний: Друкує рядки скрипту під час їх читання, навіть до розгортання. Корисно для розуміння потоку.
• встановити -n o встановити -o noexec: аналізує синтаксис без виконання коду, ідеально підходить для виявлення пропущених лапок, фігурних дужок або дужок.
• встановити -uЯк уже згадувалося, це призводить до збою, коли використовуються невизначені змінні, що дуже корисно під час налагодження логічних помилок.

Крім того, ви можете обмежити дію цих опцій певний фрагмент сценарію обгортаючи його за допомогою set -x / set +x, наприклад:

set -x
# bloque problemático
read -p "Pass Dir name : " D_OBJECT
read -p "Pass File name : " F_OBJECT
set +x слід часу

#!/bin/bash
exec 6> salida_debug.log
BASH_XTRACEFD="6"
set -x
# ... resto del script ... трасування перенаправлення

Таким чином, вся інформація про налагодження зберігається в debug_output.logІ ви можете продовжувати бачити лише "звичайний" вивід скрипта в терміналі.

Типовий приклад помилки з невизначеними змінними

Дуже поширеною проблемою, коли ви не використовуєте set -u, є виклик змінні, яких не існує без вашого розуміння. Уявіть собі скрипт, який запитує ім'я об'єкта, а потім перевіряє, чи це файл чи каталог, але неправильно визначає ім'я змінної:

#!/bin/bash
read -p "Nombre del Objeto : " OBJECT
if ]; then
echo "$OBJECT es un archivo"
elif ]; then
echo "$OBJECT es un directorio"
fi змінна похибка

Como $OBJECT1 не визначеноBash розширює його до порожнього рядка, тести -fy -d не видають помилку, вони просто не виконуються, і скрипт завершується з кодом 0. Нічого не "відбувається", але логічно результат не є очікуваним.

Якщо замість цього ви запустите скрипт з bash -u назва_скрипта або активний встановити -uВи одразу отримаєте помилку "Незв'язана змінна", яка безпосередньо призведе до помилки типу. У поєднанні з bash -x назва_скрипта Або, використовуючи `set -x`, ви також побачите, який саме рядок та значення використовуються, що значно спрощує налагодження.