NetworkAdmin.ru: “📱 Bash как DSL: пишем читаемые админские скрипты Многие админские bas…”

📱 Bash как DSL: пишем читаемые админские скрипты

Многие админские 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