Авторский блог про сетевое и системное администрирование.
Сайт: networkadmin.ru
Реклама: @dad_admin
Биржа: https://telega.in/c/networkadminru
Post #852
1.73K
📱 Bash как DSL: пишем читаемые админские скрипты
Многие админские bash-скрипты со временем превращаются в свалку из if, grep, awk, sed и случайных команд, склеенных по принципу: работает - не трогай. Проблема в том, что через месяц такой скрипт уже тяжело читать. Через полгода - страшно менять. А если его откроет другой админ, он вообще решит, что это археология, а не автоматизация.
Один из рабочих подходов - писать bash не как набор команд, а как маленький DSL: domain-specific language, то есть мини-язык под свою задачу.
Идея простая: вместо простыни команд вы собираете скрипт из понятных функций с говорящими именами.
Например, не так:
А так:
Внутри этих функций может быть что угодно, но снаружи скрипт начинает читаться как сценарий действий, а не как трассировка мыслей уставшего админа.
Например:
Теперь верхний уровень скрипта выглядит уже не как набор случайных действий, а как понятный workflow:
👍 Что это дает на практике:
скрипт легче читать: сразу видно, что делает логика, без погружения в детали.
проще сопровождать: меняете реализацию внутри функции, не ломая структуру всего скрипта.
меньше копипасты: повторяющиеся куски уезжают в функции.
проще дебажить: если сломалось install_ssh_keys, вы уже знаете, где искать проблему.
➕ Еще один полезный прием - делать функции в стиле команд:
Такой bash уже напоминает не набор shell-команд, а язык операций для конкретной задачи.
Пример плохого Bash-скрипта:
Пример более читаемого подхода:
Да, bash не станет от этого python. Но даже в shell можно писать так, чтобы скрипт был похож на понятную инструкцию, а не на клубок из условий, пайпов и боли.
#bash #scripting
🧑💻 NetworkAdmin
Многие админские bash-скрипты со временем превращаются в свалку из if, grep, awk, sed и случайных команд, склеенных по принципу: работает - не трогай. Проблема в том, что через месяц такой скрипт уже тяжело читать. Через полгода - страшно менять. А если его откроет другой админ, он вообще решит, что это археология, а не автоматизация.
Один из рабочих подходов - писать bash не как набор команд, а как маленький DSL: domain-specific language, то есть мини-язык под свою задачу.
Идея простая: вместо простыни команд вы собираете скрипт из понятных функций с говорящими именами.
Например, не так:
useradd -m -s /bin/bash "$name"
mkdir -p "/home/$name/.ssh"
cp ./authorized_keys "/home/$name/.ssh/authorized_keys"
chown -R "$name:$name" "/home/$name/.ssh"
chmod 700 "/home/$name/.ssh"
chmod 600 "/home/$name/.ssh/authorized_keys"
А так:
create_user "$name"
install_ssh_keys "$name"
harden_ssh_dir "$name"
Внутри этих функций может быть что угодно, но снаружи скрипт начинает читаться как сценарий действий, а не как трассировка мыслей уставшего админа.
Например:
create_user() {
useradd -m -s /bin/bash "$1"
}
install_ssh_keys() {
local user="$1"
mkdir -p "/home/$user/.ssh"
cp ./authorized_keys "/home/$user/.ssh/authorized_keys"
chown -R "$user:$user" "/home/$user/.ssh"
}
harden_ssh_dir() {
local user="$1"
chmod 700 "/home/$user/.ssh"
chmod 600 "/home/$user/.ssh/authorized_keys"
}
Теперь верхний уровень скрипта выглядит уже не как набор случайных действий, а как понятный workflow:
create_user "$name"
install_ssh_keys "$name"
harden_ssh_dir "$name"
👍 Что это дает на практике:
скрипт легче читать: сразу видно, что делает логика, без погружения в детали.
проще сопровождать: меняете реализацию внутри функции, не ломая структуру всего скрипта.
меньше копипасты: повторяющиеся куски уезжают в функции.
проще дебажить: если сломалось install_ssh_keys, вы уже знаете, где искать проблему.
➕ Еще один полезный прием - делать функции в стиле команд:
require_root
check_dependencies
backup_config "/etc/nginx/nginx.conf"
deploy_new_config "./nginx.conf" "/etc/nginx/nginx.conf"
test_nginx_config
reload_nginx
Такой bash уже напоминает не набор shell-команд, а язык операций для конкретной задачи.
Пример плохого Bash-скрипта:
cp "$src" "$dst" &&
nginx -t &&
systemctl reload nginx ||
echo "something failed"
Пример более читаемого подхода:
deploy_config "$src" "$dst"
validate_nginx
reload_service nginx
Да, bash не станет от этого python. Но даже в shell можно писать так, чтобы скрипт был похож на понятную инструкцию, а не на клубок из условий, пайпов и боли.
#bash #scripting
🧑💻 NetworkAdmin
- 👍 9
- 💩 2
