Содержание
Если вы хотите перевести свою домашнюю лабораторию на качественно новый уровень, вам помогут автоматизации. Чем больше процессов в вашем окружении вы можете настроить на самоуправление, тем больше времени у вас остается на создание и эксперименты с другими крутыми вещами. Если вы управляете контейнерами, виртуальными машинами или кластером Ceph, существует несколько скриптов автоматизации для домашней лаборатории, которые помогут поддерживать всё в рабочем и стабильном состоянии. Давайте рассмотрим десять скриптов автоматизации, которые должны быть в каждой домашней лаборатории в 2025 году.
Должны ли скрипты быть сложными?
Короткий ответ: нет, не должны! Вы увидите, что приведенные ниже скрипты в основном состоят из очень небольшого количества строк кода на Bash. Вы можете начать писать скрипты, просто поместив обычные команды Bash, которые вы вводили бы вручную, в файл .sh и выполнив его.
А теперь перейдем к скриптам!
1. Скрипт очистки Docker
Я часто использую Docker-контейнеры в моей домашней лаборатории, но частые эксперименты с множеством контейнеров создают беспорядок на Docker-хостах. Со временем вы будете накапливать устаревшие образы от остановленных контейнеров, зависшие тома и неиспользуемые сети. Если вы используете Docker-контейнеры на нескольких хостах или у вас работает Swarm-кластер, эти неиспользуемые данные будут суммироваться и быстро съедать дисковое пространство.
Простой скрипт очистки, который может вернуть тонны пространства, может выглядеть примерно так:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
#!/bin/bash # Логирование вывода с временной меткой LOG_FILE="/var/log/docker-cleanup.log" echo "=== Очистка Docker: $(date) ===" | tee -a "$LOG_FILE" # Проверка, запущен ли Docker if ! docker info >/dev/null 2>&1; then echo "Ошибка: Docker не запущен" | tee -a "$LOG_FILE" exit 1 fi # Показать использование диска до очистки echo "Использование диска до очистки:" | tee -a "$LOG_FILE" df -h / | tail -1 | tee -a "$LOG_FILE" # Выполнить очистку echo "Запуск очистки..." | tee -a "$LOG_FILE" docker system prune -a -f --volumes 2>&1 | tee -a "$LOG_FILE" # Показать использование диска после очистки echo "Использование диска после очистки:" | tee -a "$LOG_FILE" df -h / | tail -1 | tee -a "$LOG_FILE" echo "Очистка завершена" | tee -a "$LOG_FILE" |
Если вы хотите менее агрессивную версию, вы можете использовать что-то вроде приведенной ниже, которая не будет удалять образы из остановленных контейнеров, которые вы, возможно, захотите перезапустить позже:
|
1 2 3 |
#!/bin/bash docker system prune -f --volumes docker image prune -f # Удаляет только зависшие образы |
Вы можете запускать любой из этих скриптов вручную или настроить его выполнение по расписанию cron еженедельно. Если вы используете Ansible или конвейеры GitLab (что я очень рекомендую), вы можете запускать эту команду перед выполнением обновлений.
2. Автоматизация резервного копирования Proxmox
Если вы запускаете Proxmox Backup Server (PBS) (а вы должны это делать, если у вас есть Proxmox), вы, вероятно, уже знакомы с тем, насколько хорошо он работает. Но даже без Proxmox Backup Server вы можете использовать скрипты для создания резервных копий. Вместо ручного создания снимков или запуска заданий резервного копирования в графическом интерфейсе Proxmox вы можете использовать скрипт, который позаботится об этом.
Взгляните на следующие скрипты автоматизации для домашней лаборатории с Proxmox Backup Server:
|
1 2 3 4 5 |
#!/bin/bash vms=$(qm list | awk 'NR>1 {print $1}') for vm in $vms; do vzdump $vm --mode snapshot --storage pbs-backup --compress zstd done |
Без Proxmox Backup Server:
|
1 2 3 4 5 |
#!/bin/bash vms=$(qm list | awk 'NR>1 {print $1}') for vm in $vms; do vzdump $vm --mode snapshot --storage nfs-backups --compress zstd done |
3. Скрипт проверки состояния Ceph или MicroCeph
Если вы углубились в запуск Ceph в Proxmox или Microceph, как это сделал я со своими узлами Kubernetes и Docker Swarm, вы хотите иметь хорошее общее представление о состоянии вашего программно-определяемого хранилища. Следующий скрипт проверяет состояние кластера и предупреждает вас, если в вашем окружении Ceph что-то происходит.
Эта проверка включает статус в оповещении. Она добавляет имя хоста для сред с несколькими кластерами и показывает детали состояния только тогда, когда есть проблема.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
#!/bin/bash HEALTH=$(ceph health) STATUS=$(echo "$HEALTH" | awk '{print $1}') # Показать детали для устранения неполадок if [ "$STATUS" != "HEALTH_OK" ]; then echo "=== Обнаружена проблема со здоровьем Ceph ===" ceph health detail # Отправить оповещение с фактическим статусом curl -X POST -H "Content-Type: application/json" \ --max-time 10 \ -d "{\"text\":\"Кластер Ceph на $(hostname) в состоянии *${STATUS}*\n```${HEALTH}```\"}" \ https://hooks.slack.com/services/XXXX || \ echo "ОШИБКА: Не удалось отправить уведомление в Slack" >&2 exit 1 fi echo "Кластер Ceph здоров" exit 0 |
Вы можете привязать это к Discord, Teams или любому вебхуку, который вы хотите использовать для оповещений. В MicroCeph это также можно выполнить из crontab на одном узле для мониторинга всего кластера.
4. Автоматический мониторинг истечения срока действия SSL-сертификатов
Даже если вы используете сертификаты Let’s Encrypt для своей домашней лаборатории (и вам стоит это делать для защиты сервисов), автоматическое продление иногда может дать сбой или что-то пойти не так в процессе. Скрипт проверки срока действия сертификата может помочь вам следить за ситуацией до того, как ваши сервисы перестанут работать из-за ошибок сертификатов.
Следующий скрипт помогает вам обнаружить сбои автоматического продления до истечения срока действия сертификата. Вы можете запускать его ежедневно с помощью задания CRON или в небольшом Docker-контейнере.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#!/bin/bash DOMAINS=("jellyfin.homelab.local" "nextcloud.homelab.local") WEBHOOK="https://ntfy.sh/mylab" for domain in "${DOMAINS[@]}"; do # Получить дату истечения срока действия сертификата expiry=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null | \ openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2) if [ -n "$expiry" ]; then expiry_epoch=$(date -d "$expiry" +%s) now_epoch=$(date +%s) days_left=$(( ($expiry_epoch - $now_epoch) / 86400 )) if [ $days_left -lt 7 ]; then curl -d "Сертификат для $domain истекает через $days_left дней!" "$WEBHOOK" fi echo "$domain: до истечения срока действия $days_left дней" else echo "ОШИБКА: Не удалось проверить $domain" fi done |
5. Скрипт инвентаризации домашней лаборатории
Вам не нужно сложное корпоративное программное обеспечение для создания очень подробной инвентаризации ваших сетей. Все, что вам нужно, это установленный nmap, и тогда вы можете запустить скрипт инвентаризации, который вызывает nmap для инвентаризации вашей сети. Он будет сообщать имена хостов, IP-адреса и открытые порты.
Вы можете решить, как обрабатывать вывод. Вы можете выводить данные в JSON, CSV, TXT или другой формат. Если вы используете NetBox или phpIPAM, тот же скрипт может отправлять обновления напрямую в их API.
Просто замените в скрипте на ваш диапазон сети.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#!/bin/bash SUBNET="192.168.1.0/24" OUTPUT="inventory_$(date +%Y%m%d).txt" echo "Инвентаризация домашней лаборатории - $(date)" > "$OUTPUT" echo "================================" >> "$OUTPUT" nmap -sn "$SUBNET" -oG - | grep "Up" | awk '{print $2, $3}' | while read ip hostname; do echo "Сканирование $ip ($hostname)..." ports=$(nmap -p 22,80,443,445,3000,8006,8080,9090 --open "$ip" | grep "^[0-9]" | awk '{print $1}') echo "$ip | $hostname | $ports" >> "$OUTPUT" done echo "Инвентаризация сохранена в $OUTPUT" cat "$OUTPUT" |
6. Скрипт автоматического обновления контейнеров
Я настоятельно рекомендую использовать что-то вроде Watchtower для обновления ваших контейнеров. Вы также можете использовать Portainer, если запускаете его, или Shepherd для Docker Swarm. Однако, опять же, вам не нужно специализированное решение для этого. Вы можете запускать обновления контейнеров самостоятельно, используя скрипт BASH. Взгляните на скрипт ниже.
Следующий скрипт:
- Обновляет только контейнеры, которые действительно изменились
- Автоматически очищает старые образы
- Может уведомлять о произошедших обновлениях
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
#!/bin/bash # Скрипт автоматического обновления контейнеров с проверками безопасности COMPOSE_DIR="/opt/docker/services" LOG_FILE="/var/log/docker-updates.log" WEBHOOK="https://ntfy.sh/homelab-updates" # Опциональное уведомление log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE" } cd "$COMPOSE_DIR" || exit 1 log "Запуск проверки обновлений контейнеров..." # Загрузить новые образы docker compose pull 2>&1 | tee -a "$LOG_FILE" # Проверить, были ли обновлены какие-либо образы if docker compose pull --dry-run 2>&1 | grep -q "Downloaded newer image"; then log "Найдены обновления, применение изменений..." # Пересоздать только контейнеры с новыми образами docker compose up -d 2>&1 | tee -a "$LOG_FILE" # Очистить старые образы для экономии места docker image prune -f >> "$LOG_FILE" 2>&1 # Отправить уведомление (опционально) curl -d "🔄 Docker-контейнеры обновлены в homelab" "$WEBHOOK" 2>/dev/null log "Обновление завершено" else log "Обновления недоступны" fi # Показать, что сейчас запущено docker compose ps >> "$LOG_FILE" |
Запускайте этот скрипт каждую ночь или еженедельно, в зависимости от того, как часто ваши контейнеры получают обновления. Это простой способ оставаться в актуальном состоянии без ручного вмешательства. В Docker Swarm или Portainer вы можете запускать это через вебхук, чтобы обеспечить безопасное rolling-обновление.
7. Скрипт очистки снимков
Этот скрипт для пользователей VMware vSphere. Снимками часто злоупотребляют. Хотя они отлично подходят для использования, когда они нужны, их часто оставляют на неопределенный срок, что в целом снижает производительность. Хотя vSphere теперь имеет много встроенных интеллектуальных функций в vCenter для планирования постепенного удаления снимков, вы также можете запланировать выполнение этого с помощью скрипта.
|
1 2 3 4 5 6 7 |
# Удалить снимки старше 3 дней $SnapshotAge = (Get-Date).AddDays(-3) Get-VM | Get-Snapshot | Where-Object {$_.Created -lt $SnapshotAge} | ForEach-Object { Write-Host "Удаление снимка: $($_.Name) на $($_.VM) (Создан: $($_.Created))" Remove-Snapshot -Snapshot $_ -Confirm:$false } |
8. Плейбук управления обновлениями Ansible
Патчинг нескольких Linux-систем не должен быть рутиной. Вы можете использовать Ansible для автоматизации этого процесса без каких-либо проблем. Даже если у вас всего 3-4 Linux-виртуальные машины, это может сэкономить вам кучу времени.
Сначала простой файл инвентаризации (что-то вроде ~/homelab/inventory.ini):
|
1 2 3 4 5 6 7 8 9 10 |
[webservers] nginx01 ansible_host=192.168.1.10 nginx02 ansible_host=192.168.1.11 [databases] postgres ansible_host=192.168.1.20 [all:vars] ansible_user=your-user ansible_become=yes |
Следующий скрипт позволит вам обновлять системы как на базе Debian, так и на базе RHEL. Он проверяет, не требуется ли перезагрузка, и предоставляет вам отчет о том, что произошло с обновлениями. Вы можете запланировать его еженедельное выполнение с помощью CRON, и вам больше не придется вручную подключаться к вашим машинам и запускать обновления!
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
--- - name: Обновить все системы hosts: all tasks: - name: Обновить пакеты apt (Debian/Ubuntu) apt: upgrade: dist update_cache: yes when: ansible_os_family == "Debian" - name: Обновить пакеты yum (RHEL/Rocky) yum: name: '*' state: latest when: ansible_os_family == "RedHat" - name: Проверить, требуется ли перезагрузка stat: path: /var/run/reboot-required register: reboot_required - name: Уведомить, если требуется перезагрузка debug: msg: "{{ inventory_hostname }} требуется перезагрузка!" when: reboot_required.stat.exists |
9. Скрипт плавного отключения, запускаемый от ИБП
Если ваша домашняя лаборатория работает от ИБП (что является отличной идеей), вы можете запускать автоматические отключения, чтобы предотвратить повреждение данных, когда сервер просто «умирает» при разрядке батареи ИБП. Network UPS Tools (NUT Server) может запускать скрипт для отключения ваших систем в правильном порядке и помочь защитить ваши данные.
Сначала установите NUT:
|
1 |
apt install nut |
Далее следует скрипт отключения. Вы можете создать его и сохранить как /usr/local/bin/ups-shutdown.sh.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
#!/bin/bash LOG="/var/log/ups-shutdown.log" log() { echo "[$(date)] $1" | tee -a "$LOG" } log "Низкий заряд батареи ИБП - инициирование плавного отключения" # Сначала выключить ВМ/контейнеры log "Выключение ВМ..." ssh proxmox1 "qm list | awk 'NR>1 {print \$1}' | xargs -I {} qm shutdown {}" sleep 30 # Выключить серверы приложений log "Выключение серверов приложений..." ssh docker01 "shutdown -h +1" # Подождать, пока всё остановится sleep 60 # Выключить хранилище ПОСЛЕДНИМ (Ceph, NAS и т.д.) log "Выключение хранилища..." ssh storage01 "shutdown -h now" # Наконец, выключить этот хост log "Выключение хоста мониторинга ИБП" shutdown -h now |
Настройте NUT для его вызова (/etc/nut/upsmon.conf):
|
1 2 |
NOTIFYCMD /usr/local/bin/ups-shutdown.sh NOTIFYFLAG ONBATT SYSLOG+EXEC |
Это гарантирует, что ваши системы хранения будут отключены последними и помогает предотвратить повреждение файловой системы. Вы можете протестировать скрипт, отключив ИБП, а затем просто убедиться, что вы готовы к последовательности отключения.
10. Самовосстанавливающийся монитор служб
Службы могут аварийно завершаться, а контейнеры останавливаться, когда вы меньше всего этого ожидаете. Самовосстанавливающийся монитор служб с помощью скрипта может проверять, действительно ли службы работают и отвечают, а затем автоматически перезапускать их, чтобы «самостоятельно исправить» проблему без необходимости постоянного присмотра с вашей стороны.
Даже самые надежные службы время от времени завершаются аварийно. Вместо их ручного перезапуска вы можете использовать небольшой самовосстанавливающийся скрипт для мониторинга и автоматического перезапуска остановленных служб или контейнеров.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
#!/bin/bash WEBHOOK="https://ntfy.sh/homelab-alerts" check_and_heal() { local name=$1 local check_cmd=$2 local heal_cmd=$3 if ! eval "$check_cmd" &>/dev/null; then echo "[$(date)] $name не работает, попытка перезапуска..." eval "$heal_cmd" sleep 5 # Проверить, что он вернулся в работу if eval "$check_cmd" &>/dev/null; then curl -d "Успешно перезапущен $name" "$WEBHOOK" 2>/dev/null else curl -d "Не удалось перезапустить $name - требуется ручное вмешательство!" "$WEBHOOK" 2>/dev/null fi fi } # Проверить, работают ли контейнеры И отвечают ли они check_and_heal "Nginx" \ "curl -f http://localhost:80" \ "docker restart nginx" check_and_heal "Jellyfin" \ "curl -f http://localhost:8096" \ "docker restart jellyfin" check_and_heal "Portainer" \ "curl -fk https://localhost:9443" \ "docker restart portainer" # Проверить службы systemd check_and_heal "SSH" \ "systemctl is-active sshd" \ "systemctl restart sshd" |
Затем вы можете запланировать его выполнение с помощью CRON каждые 5 минут, как показано ниже:
|
1 |
*/5 * * * * /usr/local/bin/service-monitor.sh |
Хорошая вещь в этом скрипте мониторинга служб заключается в том, что он фактически гарантирует, что службы отвечают, а не просто работают. Он также уведомит, если восстановление не удалось, так что вы будете знать, нужно ли вам вручную вмешаться и запустить всё заново.
Создайте себе библиотеку скриптов для домашней лаборатории
Я настоятельно рекомендую каждому создать Git-репозиторий для своих скриптов. Добавьте каждый скрипт в виде отдельного файла и затем создайте короткий README в формате markdown, объясняющий, что это за скрипт и что он делает. Контроль версий в Git поможет вам отслеживать любые изменения или улучшения, которые вы захотите внести.
Если вы запускаете что-то вроде GitLab или Gitea, вы можете использовать конвейеры для автоматизации ваших скриптов и планирования их запуска. Именно так вы можете развить свою домашнюю лабораторию от нескольких базовых скриптов до полноценной DevOps-площадки. Со временем у вас будет полная библиотека автоматизации, на которую вы сможете опираться в других проектах. Это очень помогает в обучении.
Подводя итоги
Надеюсь, эти 10 практичных скриптов автоматизации, которые мы здесь выделили, дадут вам некоторые представления о том, насколько мощными могут быть автоматизация и скрипты в вашей домашней лаборатории. Начните с малого — с проблемы, задачи или просто рутинного действия, которое вы хотите автоматизировать, а затем работайте над скриптом для этого. Я не являюсь большим поклонником использования ИИ для создания скриптов, но он может значительно ускорить процесс.
Вы можете использовать эти скрипты для автоматизации очистки, резервного копирования, мониторинга, управления исправлениями и многого другого. Вы можете использовать их для Proxmox, VMware, Docker, Ceph и многого другого. Подумайте о том, что вы делаете вручную, и посмотрите, сможете ли вы автоматизировать это с помощью скрипта. Вы будете поражены тем, насколько это может быть легко.
