Windows (PowerShell): контроль критичных сервисов + авто-рестарт + Telegram
Проверяет список сервисов; если «Stopped» — перезапускает и шлёт алерт.
#windows #powershell #services #telegram
Проверяет список сервисов; если «Stopped» — перезапускает и шлёт алерт.
$token = "<BOT_TOKEN>"
$chatId = "<CHAT_ID>"
$services = @("Spooler","LanmanServer","Dhcp","Dnscache") # поменяй на свои
foreach ($s in $services) {
$svc = Get-Service -Name $s -ErrorAction SilentlyContinue
if ($null -ne $svc -and $svc.Status -ne 'Running') {
try {
Start-Service -Name $s -ErrorAction Stop
$msg = "✅ Сервис $s был остановлен и перезапущен."
} catch {
$msg = "❌ Не удалось запустить сервис $s: $($_.Exception.Message)"
}
$url = "https://api.telegram.org/bot$token/sendMessage"
Invoke-RestMethod -Uri $url -Method Post -Body @{chat_id=$chatId;text=$msg}
}
}
Планировщик задач: каждые 10–15 минут.
#windows #powershell #services #telegram
Windows: поднятие WSUS с нуля + автоматическая чистка
Чтобы экономить интернет-канал и ускорять обновления, админы поднимают локальный сервер WSUS. Настроить его можно за вечер, если идти по шагам.
1️⃣ Установка роли
Через PowerShell:
Мастер установки спросит:
Папку для хранения обновлений (лучше на отдельном диске).
Тип базы данных — встроенная WID (SQL не обязателен).
После установки запускаем мастер конфигурации.
2️⃣ Настройка сервера WSUS
▪️ Указываем апстрим-сервер (по умолчанию Microsoft Update).
▪️ Выбираем продукты: Windows 10/11, Windows Server 2019/2022.
▪️ Выбираем классификации:
Definition Updates (для Defender).
▪️ Настраиваем синхронизацию (ручная или по расписанию).
3️⃣ Настройка клиентов через GPO
В домене открываем GPMC → создаём политику.
Путь:
Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Update
Основные параметры:
Specify intranet Microsoft update service location → http://wsus-server:8530
Configure Automatic Updates → 4 (автоматическая загрузка и установка).
Automatic Maintenance Activation Boundary → время установки.
Применяем GPO к OU с нужными ПК.
4️⃣ Первичная проверка
На клиенте:
Через 10–15 минут клиент должен появиться в консоли WSUS.
5️⃣ Автоматическая чистка WSUS
WSUS очень быстро разрастается, поэтому включаем регулярное обслуживание.
PowerShell-скрипт для чистки (сохраняем как wsus_cleanup.ps1):
📌 Добавь этот скрипт в Task Scheduler (например, раз в неделю ночью).
6️⃣ Поддержка и обслуживание
Следим за размером базы и хранилища.
Проверяем отчёты о применении обновлений.
Раз в месяц вручную запускаем Server Cleanup Wizard для проверки.
📊 Теперь клиенты получают обновления локально:
— быстрее,
— без нагрузки на внешний канал,
— с автоматическим обслуживанием WSUS.
#windows #update #wsus #powershell #automation
Чтобы экономить интернет-канал и ускорять обновления, админы поднимают локальный сервер WSUS. Настроить его можно за вечер, если идти по шагам.
1️⃣ Установка роли
Через PowerShell:
Install-WindowsFeature -Name UpdateServices -IncludeManagementTools
Мастер установки спросит:
Папку для хранения обновлений (лучше на отдельном диске).
Тип базы данных — встроенная WID (SQL не обязателен).
После установки запускаем мастер конфигурации.
2️⃣ Настройка сервера WSUS
▪️ Указываем апстрим-сервер (по умолчанию Microsoft Update).
▪️ Выбираем продукты: Windows 10/11, Windows Server 2019/2022.
▪️ Выбираем классификации:
Critical Updates
Security Updates
Definition Updates (для Defender).
▪️ Настраиваем синхронизацию (ручная или по расписанию).
3️⃣ Настройка клиентов через GPO
В домене открываем GPMC → создаём политику.
Путь:
Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Update
Основные параметры:
Specify intranet Microsoft update service location → http://wsus-server:8530
Configure Automatic Updates → 4 (автоматическая загрузка и установка).
Automatic Maintenance Activation Boundary → время установки.
Применяем GPO к OU с нужными ПК.
4️⃣ Первичная проверка
На клиенте:
gpupdate /force
wuauclt /detectnow
Через 10–15 минут клиент должен появиться в консоли WSUS.
5️⃣ Автоматическая чистка WSUS
WSUS очень быстро разрастается, поэтому включаем регулярное обслуживание.
PowerShell-скрипт для чистки (сохраняем как wsus_cleanup.ps1):
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("localhost",$false)
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope `
-Property @{
DeclineSupersededUpdates = $true
DeclineExpiredUpdates = $true
CleanupObsoleteUpdates = $true
CompressUpdates = $true
CleanupObsoleteComputers = $true
CleanupUnneededContentFiles = $true
}
$cleanupManager = $wsus.GetCleanupManager()
$cleanupManager.PerformCleanup($cleanupScope)
Write-Output "WSUS cleanup complete"
📌 Добавь этот скрипт в Task Scheduler (например, раз в неделю ночью).
6️⃣ Поддержка и обслуживание
Следим за размером базы и хранилища.
Проверяем отчёты о применении обновлений.
Раз в месяц вручную запускаем Server Cleanup Wizard для проверки.
📊 Теперь клиенты получают обновления локально:
— быстрее,
— без нагрузки на внешний канал,
— с автоматическим обслуживанием WSUS.
#windows #update #wsus #powershell #automation
👍2
WSUS vs SCCM (ConfigMgr): когда пора апгрейдиться?
WSUS — простой сервер обновлений. Он кэширует патчи и раздаёт их клиентам. Но у него есть предел возможностей. Когда инфраструктура растёт, часто переходят на SCCM (Microsoft Endpoint Configuration Manager).
🔹 Что умеет WSUS
✅ Кэшировать обновления Microsoft (Windows, Office, Defender).
✅ Работает на встроенной базе WID или SQL.
✅ Управление через GPO.
✅ Бесплатен (часть Windows Server).
❌ Ограничения:
Только продукты Microsoft.
Нет детальной отчётности (какие апдейты встали, а какие нет).
Нет управления сторонними софтом/драйверами.
Консоль тормозит на больших базах (1000+ клиентов).
Требует ручной чистки и обслуживания.
🔹 Что добавляет SCCM (ConfigMgr)
✅ Полное управление обновлениями Microsoft + стороннего софта (Adobe, Java, драйверы).
✅ Поддержка Windows, Linux, macOS.
✅ Развёртывание ПО и конфигураций (application deployment).
✅ Инвентаризация железа и софта.
✅ Расширенная отчётность (какой апдейт где применился).
✅ Гибкие коллекции устройств, таргетинг, правила автоустановки.
✅ Интеграция с Intune (гибрид MDM).
❌ Минусы:
Сложнее в развертывании.
Требует полноценного SQL Server.
Нужны лицензии (Software Assurance или отдельные CAL).
🔹 Когда WSUS уже «не тянет»
Клиентов >1000.
Нужно управлять обновлениями сторонних приложений.
Требуется инвентаризация ПО/железа.
Руководство требует детальной отчётности.
Инфраструктура гибридная (on-prem + облако).
📌 Вывод
Для малого бизнеса или филиала на 100–500 ПК → WSUS = нормальное решение.
Для средней и крупной инфраструктуры → SCCM даёт полный контроль, особенно если нужно управлять не только апдейтами, но и всем софтом.
⚡ Совет: если WSUS уже «трещит по швам», попробуй Windows Update for Business (политики обновлений через Intune) — это упрощённый вариант для гибридных сетей.
#windows #update #wsus #sccm #configmgr
WSUS — простой сервер обновлений. Он кэширует патчи и раздаёт их клиентам. Но у него есть предел возможностей. Когда инфраструктура растёт, часто переходят на SCCM (Microsoft Endpoint Configuration Manager).
🔹 Что умеет WSUS
✅ Кэшировать обновления Microsoft (Windows, Office, Defender).
✅ Работает на встроенной базе WID или SQL.
✅ Управление через GPO.
✅ Бесплатен (часть Windows Server).
❌ Ограничения:
Только продукты Microsoft.
Нет детальной отчётности (какие апдейты встали, а какие нет).
Нет управления сторонними софтом/драйверами.
Консоль тормозит на больших базах (1000+ клиентов).
Требует ручной чистки и обслуживания.
🔹 Что добавляет SCCM (ConfigMgr)
✅ Полное управление обновлениями Microsoft + стороннего софта (Adobe, Java, драйверы).
✅ Поддержка Windows, Linux, macOS.
✅ Развёртывание ПО и конфигураций (application deployment).
✅ Инвентаризация железа и софта.
✅ Расширенная отчётность (какой апдейт где применился).
✅ Гибкие коллекции устройств, таргетинг, правила автоустановки.
✅ Интеграция с Intune (гибрид MDM).
❌ Минусы:
Сложнее в развертывании.
Требует полноценного SQL Server.
Нужны лицензии (Software Assurance или отдельные CAL).
🔹 Когда WSUS уже «не тянет»
Клиентов >1000.
Нужно управлять обновлениями сторонних приложений.
Требуется инвентаризация ПО/железа.
Руководство требует детальной отчётности.
Инфраструктура гибридная (on-prem + облако).
📌 Вывод
Для малого бизнеса или филиала на 100–500 ПК → WSUS = нормальное решение.
Для средней и крупной инфраструктуры → SCCM даёт полный контроль, особенно если нужно управлять не только апдейтами, но и всем софтом.
⚡ Совет: если WSUS уже «трещит по швам», попробуй Windows Update for Business (политики обновлений через Intune) — это упрощённый вариант для гибридных сетей.
#windows #update #wsus #sccm #configmgr
👍2
Linux: systemd timers вместо cron
Cron — это классика, но у него есть минусы: он не знает о состоянии системы и «пропускает» задачи, если сервер был выключен. Systemd timers решают эти проблемы и дают больше гибкости.
1️⃣ Создаём unit для скрипта
/etc/systemd/system/backup.service
💡 Type=oneshot подходит для одноразовых задач (бэкап, очистка логов, sync).
2️⃣ Создаём таймер
/etc/systemd/system/backup.timer
🔹 OnCalendar — расписание (аналог cron).
🔹 Persistent=true — если сервер был выключен в 02:00, задача выполнится при следующем старте.
🔹 RandomizedDelaySec=300 — случайная задержка до 5 минут → полезно при десятках серверов (чтобы они не падали на диск одновременно).
3️⃣ Запуск и проверка
Вывод покажет: какие таймеры активны, когда запускались и когда запустятся снова.
4️⃣ Дополнительные сценарии
OnBootSec=10min — запуск через 10 минут после старта системы.
OnUnitInactiveSec=1h — повтор каждые 60 минут.
AccuracySec=1m — точность до минуты (экономит ресурсы при сотнях таймеров).
📌 Преимущества systemd timers
✅ Помнят пропущенные задачи (в отличие от cron).
✅ Интеграция с journald → логи доступны через journalctl -u backup.service.
✅ Гибкие триггеры (OnBootSec, OnActiveSec, OnUnitInactiveSec).
✅ Поддержка случайных задержек (RandomizedDelaySec) для распределения нагрузки.
⚡ Итого: timers = cron 2.0. Если ты уже используешь systemd, смысла держать cron мало.
#linux #systemd #automation #scheduling
Cron — это классика, но у него есть минусы: он не знает о состоянии системы и «пропускает» задачи, если сервер был выключен. Systemd timers решают эти проблемы и дают больше гибкости.
1️⃣ Создаём unit для скрипта
/etc/systemd/system/backup.service
[Unit]
Description=Nightly backup job
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
💡 Type=oneshot подходит для одноразовых задач (бэкап, очистка логов, sync).
2️⃣ Создаём таймер
/etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily at 02:00
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300
[Install]
WantedBy=timers.target
🔹 OnCalendar — расписание (аналог cron).
🔹 Persistent=true — если сервер был выключен в 02:00, задача выполнится при следующем старте.
🔹 RandomizedDelaySec=300 — случайная задержка до 5 минут → полезно при десятках серверов (чтобы они не падали на диск одновременно).
3️⃣ Запуск и проверка
systemctl enable --now backup.timer
systemctl list-timers --all
Вывод покажет: какие таймеры активны, когда запускались и когда запустятся снова.
4️⃣ Дополнительные сценарии
OnBootSec=10min — запуск через 10 минут после старта системы.
OnUnitInactiveSec=1h — повтор каждые 60 минут.
AccuracySec=1m — точность до минуты (экономит ресурсы при сотнях таймеров).
📌 Преимущества systemd timers
✅ Помнят пропущенные задачи (в отличие от cron).
✅ Интеграция с journald → логи доступны через journalctl -u backup.service.
✅ Гибкие триггеры (OnBootSec, OnActiveSec, OnUnitInactiveSec).
✅ Поддержка случайных задержек (RandomizedDelaySec) для распределения нагрузки.
⚡ Итого: timers = cron 2.0. Если ты уже используешь systemd, смысла держать cron мало.
#linux #systemd #automation #scheduling
👍2
Linux: Nginx как Reverse Proxy — швейцарский нож для админа
Просто хостить сайт на сервере — это прошлое. Современный подход — спрятать ваше приложение (Apache, Gunicorn, Node.js) за Nginx, который будет работать как обратный прокси. Это повышает безопасность, гибкость и производительность.
1️⃣ Зачем это нужно?
SSL/TLS Termination: Nginx берёт на себя всю работу с шифрованием, разгружая ваше приложение. Управлять сертификатами в одном месте — бесценно.
Load Balancing: Легко распределять трафик на несколько серверов-бэкендов.
Security: Прячет архитектуру вашего бэкенда. Можно настроить файрвол на Nginx и заблокировать вредоносный трафик до того, как он дойдёт до приложения.
Кэширование: Nginx может кэшировать статический контент (CSS, JS, картинки) и отдавать его мгновенно.
2️⃣ Установка и базовая настройка
Устанавливаем Nginx и удаляем дефолтный конфиг.
3️⃣ Конфигурация Reverse Proxy
Создаём файл /etc/nginx/sites-available/myapp.conf. Предположим, ваше приложение работает на порту 8080.
Nginx
4️⃣ Включаем HTTPS (SSL Termination)
Добавим SSL с помощью Certbot (Let's Encrypt).
Certbot автоматически изменит конфиг, добавив listen 443 ssl; и пути к сертификатам.
5️⃣ Активация и проверка
📈 Итог: Вы построили базовый, но надёжный шлюз для вашего приложения.
Теперь вы можете легко добавлять новые сервисы, управлять SSL и готовиться к масштабированию.
Это уже не просто администрирование, а основы сетевой архитектуры.
#linux #nginx #proxy #security #network #архитектура
Просто хостить сайт на сервере — это прошлое. Современный подход — спрятать ваше приложение (Apache, Gunicorn, Node.js) за Nginx, который будет работать как обратный прокси. Это повышает безопасность, гибкость и производительность.
1️⃣ Зачем это нужно?
SSL/TLS Termination: Nginx берёт на себя всю работу с шифрованием, разгружая ваше приложение. Управлять сертификатами в одном месте — бесценно.
Load Balancing: Легко распределять трафик на несколько серверов-бэкендов.
Security: Прячет архитектуру вашего бэкенда. Можно настроить файрвол на Nginx и заблокировать вредоносный трафик до того, как он дойдёт до приложения.
Кэширование: Nginx может кэшировать статический контент (CSS, JS, картинки) и отдавать его мгновенно.
2️⃣ Установка и базовая настройка
Устанавливаем Nginx и удаляем дефолтный конфиг.
sudo apt update && sudo apt install nginx
sudo rm /etc/nginx/sites-enabled/default
3️⃣ Конфигурация Reverse Proxy
Создаём файл /etc/nginx/sites-available/myapp.conf. Предположим, ваше приложение работает на порту 8080.
Nginx
server {
listen 80;
server_name your_domain.com;
# Перенаправляем весь трафик на бэкенд
location / {
proxy_pass http://127.0.0.1:8080;
# Передаём реальный IP клиента и другие заголовки
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
4️⃣ Включаем HTTPS (SSL Termination)
Добавим SSL с помощью Certbot (Let's Encrypt).
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d your_domain.com
Certbot автоматически изменит конфиг, добавив listen 443 ssl; и пути к сертификатам.
5️⃣ Активация и проверка
# Проверяем синтаксис конфига
sudo nginx -t
# Создаём символическую ссылку для активации
sudo ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/
# Перезапускаем Nginx
sudo systemctl restart nginx
📈 Итог: Вы построили базовый, но надёжный шлюз для вашего приложения.
Теперь вы можете легко добавлять новые сервисы, управлять SSL и готовиться к масштабированию.
Это уже не просто администрирование, а основы сетевой архитектуры.
#linux #nginx #proxy #security #network #архитектура
❤2🔥2
Чек-лист: Аудит логов Linux для поиска аномалий
Регулярный анализ логов — это как гигиена для сервера. Он помогает находить проблемы до того, как они станут критичными, и обнаруживать следы подозрительной активности. Сохраняйте этот базовый чек-лист для быстрой проверки.
Инструменты: journalctl, grep, awk, less.
▪️ 1. Проверка системных ошибок и сбоев
Ищем в journald записи с высоким приоритетом (ошибки, критические сбои).
Bash
-p 0..3 — фильтр по приоритетам от emerg до err.
-n 50 — показать последние 50 записей.
Что ищем: ошибки ядра (kernel panic), сбои сервисов, проблемы с дисками.
▪️ 2. Анализ попыток входа по SSH
Кто и откуда пытался подключиться к серверу?
Bash
Что ищем: брутфорс-атаки, попытки входа под несуществующими пользователями.
▪️ 3. Проверка использования sudo
Кто выполнял команды с повышенными привилегиями?
Bash
Что ищем: неожиданные команды, выполнение команд пользователями, у которых не должно быть sudo-доступа.
▪️ 4. Мониторинг логов веб-сервера (Nginx/Apache)
Ищем ошибки и подозрительные запросы.
Bash
Что ищем: попытки сканирования уязвимостей (SQL-инъекции, LFI), неработающие скрипты.
▪️ 5. Проверка логов cron
Убедитесь, что запланированные задачи выполняются корректно.
Bash
Что ищем: ошибки выполнения скриптов, задачи, которые запускаются слишком часто или не запускаются вовсе.
📌 Автоматизация: Настройте logwatch или goaccess для получения ежедневных сводок и алертов, чтобы не делать всё вручную.
#linux #security #чеклисты #logs #audit
Регулярный анализ логов — это как гигиена для сервера. Он помогает находить проблемы до того, как они станут критичными, и обнаруживать следы подозрительной активности. Сохраняйте этот базовый чек-лист для быстрой проверки.
Инструменты: journalctl, grep, awk, less.
▪️ 1. Проверка системных ошибок и сбоев
Ищем в journald записи с высоким приоритетом (ошибки, критические сбои).
Bash
journalctl -p 0..3 -n 50 --no-pager
-p 0..3 — фильтр по приоритетам от emerg до err.
-n 50 — показать последние 50 записей.
Что ищем: ошибки ядра (kernel panic), сбои сервисов, проблемы с дисками.
▪️ 2. Анализ попыток входа по SSH
Кто и откуда пытался подключиться к серверу?
Bash
# Все неудачные попытки входа
grep "Failed password" /var/log/auth.log | less
# IP-адреса, с которых было больше 10 неудачных попыток
grep "Failed password" /var/log/auth.log | \
awk '{print $(NF-3)}' | sort | uniq -c | \
awk '{if ($1 > 10) print "Count: " $1 ", IP: " $2}'
Что ищем: брутфорс-атаки, попытки входа под несуществующими пользователями.
▪️ 3. Проверка использования sudo
Кто выполнял команды с повышенными привилегиями?
Bash
grep "sudo" /var/log/auth.log | grep "COMMAND" | less
Что ищем: неожиданные команды, выполнение команд пользователями, у которых не должно быть sudo-доступа.
▪️ 4. Мониторинг логов веб-сервера (Nginx/Apache)
Ищем ошибки и подозрительные запросы.
Bash
# Показать все 404 ошибки (запросы к несуществующим страницам)
grep " 404 " /var/log/nginx/access.log | less
# Показать ошибки 5xx (проблемы на стороне сервера)
grep " 50. " /var/log/nginx/error.log | less
Что ищем: попытки сканирования уязвимостей (SQL-инъекции, LFI), неработающие скрипты.
▪️ 5. Проверка логов cron
Убедитесь, что запланированные задачи выполняются корректно.
Bash
grep CRON /var/log/syslog | less
Что ищем: ошибки выполнения скриптов, задачи, которые запускаются слишком часто или не запускаются вовсе.
📌 Автоматизация: Настройте logwatch или goaccess для получения ежедневных сводок и алертов, чтобы не делать всё вручную.
#linux #security #чеклисты #logs #audit
Кейс: «Сервер тормозит, но CPU и RAM в норме». В поисках дискового I/O.
Проблема: Один из наших веб-серверов (Ubuntu + Nginx + PostgreSQL) начал отвечать на запросы очень медленно. Стандартные дашборды в Grafana показывали, что загрузка CPU — 20-30%, использование RAM — около 60%. На первый взгляд, всё в порядке.
Симптомы:
top и htop не показывали процессов, которые бы «съедали» процессор.
Время ответа сайта (TTFB) выросло с 200 мс до 2-3 секунд.
Пользователи жаловались на «зависания» при работе с базой данных.
Диагностика: копаем в сторону дисков
Первая гипотеза: если не CPU и не RAM, значит, проблема в дисковой подсистеме (I/O). Процессы могут простаивать в ожидании, пока диск прочитает или запишет данные.
Шаг 1: top и iowait
Запускаем top и смотрим на строку %Cpu(s). Нас интересует параметр wa — iowait. Он показывал значения 40-50%, что аномально много. Это значит, что процессор почти половину времени ждёт ответа от дисков.
Шаг 2: iotop
Устанавливаем iotop (sudo apt install iotop), чтобы увидеть, какой именно процесс создаёт нагрузку на диск.
Bash
Картина прояснилась: процесс postgres постоянно что-то писал на диск с высокой скоростью, а также системный процесс jbd2/sda1-8 (журналирование файловой системы ext4) показывал высокую активность.
Ша-г 3: Анализ работы PostgreSQL
Проверка настроек PostgreSQL показала, что уровень логирования был установлен на statement, то есть каждый SQL-запрос писался в лог-файл. Нагрузка на сайт выросла, и база данных генерировала гигантский объём логов, забивая всю пропускную способность диска.
Решение:
Изменили уровень логирования. В postgresql.conf параметр log_statement был изменён с all на ddl. Теперь логируются только изменения схемы, а не каждый SELECT.
Вынесли логи на отдельный диск. В идеальном мире, логи и данные должны лежать на разных физических дисках, чтобы не конкурировать за I/O.
Оптимизировали checkpoint'ы. Увеличили интервалы между checkpoint'ами, чтобы снизить частоту записи «грязных» буферов на диск.
Вывод:
Когда сервер тормозит, а CPU и RAM свободны, — всегда смотрите на iowait. Это «слепая зона» для многих админов. Умение диагностировать дисковые проблемы с помощью iotop и iostat — ключевой навык для поддержания производительности высоконагруженных систем.
#linux #devops #case #postgresql #performance #debug
Проблема: Один из наших веб-серверов (Ubuntu + Nginx + PostgreSQL) начал отвечать на запросы очень медленно. Стандартные дашборды в Grafana показывали, что загрузка CPU — 20-30%, использование RAM — около 60%. На первый взгляд, всё в порядке.
Симптомы:
top и htop не показывали процессов, которые бы «съедали» процессор.
Время ответа сайта (TTFB) выросло с 200 мс до 2-3 секунд.
Пользователи жаловались на «зависания» при работе с базой данных.
Диагностика: копаем в сторону дисков
Первая гипотеза: если не CPU и не RAM, значит, проблема в дисковой подсистеме (I/O). Процессы могут простаивать в ожидании, пока диск прочитает или запишет данные.
Шаг 1: top и iowait
Запускаем top и смотрим на строку %Cpu(s). Нас интересует параметр wa — iowait. Он показывал значения 40-50%, что аномально много. Это значит, что процессор почти половину времени ждёт ответа от дисков.
Шаг 2: iotop
Устанавливаем iotop (sudo apt install iotop), чтобы увидеть, какой именно процесс создаёт нагрузку на диск.
Bash
sudo iotop
Картина прояснилась: процесс postgres постоянно что-то писал на диск с высокой скоростью, а также системный процесс jbd2/sda1-8 (журналирование файловой системы ext4) показывал высокую активность.
Ша-г 3: Анализ работы PostgreSQL
Проверка настроек PostgreSQL показала, что уровень логирования был установлен на statement, то есть каждый SQL-запрос писался в лог-файл. Нагрузка на сайт выросла, и база данных генерировала гигантский объём логов, забивая всю пропускную способность диска.
Решение:
Изменили уровень логирования. В postgresql.conf параметр log_statement был изменён с all на ddl. Теперь логируются только изменения схемы, а не каждый SELECT.
Вынесли логи на отдельный диск. В идеальном мире, логи и данные должны лежать на разных физических дисках, чтобы не конкурировать за I/O.
Оптимизировали checkpoint'ы. Увеличили интервалы между checkpoint'ами, чтобы снизить частоту записи «грязных» буферов на диск.
Вывод:
Когда сервер тормозит, а CPU и RAM свободны, — всегда смотрите на iowait. Это «слепая зона» для многих админов. Умение диагностировать дисковые проблемы с помощью iotop и iostat — ключевой навык для поддержания производительности высоконагруженных систем.
#linux #devops #case #postgresql #performance #debug
Как быстро создать файл любого размера для тестов? (Win/Lin/Mac)
Классическая задача: нужно протестировать работу мониторинга, скрипта очистки или уведомлений о заканчивающемся месте на диске. Для этого нужен «мусорный» файл большого размера, но создавать его копированием реальных данных — долго и неудобно.
Вот как сгенерировать такой файл мгновенно в любой ОС.
🐧 Linux: fallocate
Современный и самый быстрый способ. Файл создаётся моментально, так как место под него просто резервируется (pre-allocated), а не заполняется нулями.
▪️ Команда:
Bash
-l — задаёт размер. Можно использовать K, M, G, T (кило-, мега-, гига-, терабайты).
Классическая альтернатива — dd, но он работает медленнее, так как реально пишет нули на диск:
⊞ Windows: fsutil
В Windows для этого есть встроенная утилита fsutil. Она работает по тому же принципу, что и fallocate, — мгновенно создаёт пустой файл заданного размера.
▪️ Команда (запускать в CMD или PowerShell от имени администратора):
PowerShell
Важно: размер указывается в байтах.
Лайфхак для PowerShell, чтобы не считать нули:
PowerShell
macOS: mkfile
В macOS (и других BSD-системах) есть своя специальная утилита — mkfile.
▪️ Команда:
Bash
Суффиксы k, m, g для размеров также поддерживаются.
📌 Почему fallocate и fsutil лучше?
Эти утилиты не тратят время и ресурсы диска на запись данных. Они просто сообщают файловой системе: «Зарезервируй здесь 10 ГБ». Поэтому файл любого, даже самого гигантского, размера появляется мгновенно. Идеально для быстрых тестов.
Теперь у вас под рукой есть инструмент для каждой системы, чтобы проверить, сработают ли ваши алерты, когда место действительно начнёт заканчиваться.
#команды #linux #windows #macos #testing #sysadmin
Классическая задача: нужно протестировать работу мониторинга, скрипта очистки или уведомлений о заканчивающемся месте на диске. Для этого нужен «мусорный» файл большого размера, но создавать его копированием реальных данных — долго и неудобно.
Вот как сгенерировать такой файл мгновенно в любой ОС.
🐧 Linux: fallocate
Современный и самый быстрый способ. Файл создаётся моментально, так как место под него просто резервируется (pre-allocated), а не заполняется нулями.
▪️ Команда:
Bash
# Создать файл размером 10 гигабайт
fallocate -l 10G large_file.tmp
-l — задаёт размер. Можно использовать K, M, G, T (кило-, мега-, гига-, терабайты).
Классическая альтернатива — dd, но он работает медленнее, так как реально пишет нули на диск:
dd if=/dev/zero of=large_file.tmp bs=1G count=10
⊞ Windows: fsutil
В Windows для этого есть встроенная утилита fsutil. Она работает по тому же принципу, что и fallocate, — мгновенно создаёт пустой файл заданного размера.
▪️ Команда (запускать в CMD или PowerShell от имени администратора):
PowerShell
# Создать файл размером 5 гигабайт (размер в байтах)
fsutil file createnew C:\temp\large_file.tmp 5368709120
Важно: размер указывается в байтах.
Лайфхак для PowerShell, чтобы не считать нули:
PowerShell
# Создать файл на 5 ГБ
fsutil file createnew C:\temp\large_file.tmp (5 * 1GB)
macOS: mkfile
В macOS (и других BSD-системах) есть своя специальная утилита — mkfile.
▪️ Команда:
Bash
# Создать файл размером 2 гигабайта
mkfile 2g large_file.tmp
Суффиксы k, m, g для размеров также поддерживаются.
📌 Почему fallocate и fsutil лучше?
Эти утилиты не тратят время и ресурсы диска на запись данных. Они просто сообщают файловой системе: «Зарезервируй здесь 10 ГБ». Поэтому файл любого, даже самого гигантского, размера появляется мгновенно. Идеально для быстрых тестов.
Теперь у вас под рукой есть инструмент для каждой системы, чтобы проверить, сработают ли ваши алерты, когда место действительно начнёт заканчиваться.
#команды #linux #windows #macos #testing #sysadmin
От сисадмина к архитектору: 3 нетехнических навыка для роста
Вечер — хорошее время, чтобы на шаг отойти от рутины и подумать о будущем. Мы все умеем гуглить ошибки, чинить упавший сервер и настраивать бэкапы. Эти технические навыки — наш фундамент. Но чтобы расти дальше, от реактивного «тушения пожаров» к проактивному проектированию систем, нужны другие компетенции.
Вот 3 «гибких» навыка, которые отличают опытного админа от архитектора.
1. Системное мышление (Видеть лес за деревьями)
Админ: думает, как починить конкретный сервис.
Архитектор: спрашивает, почему он сломался, и как изменить систему, чтобы это не повторилось.
Это умение видеть не отдельные серверы, а всю инфраструктуру как единый организм: как связаны сеть, базы данных, приложения и безопасность. Прежде чем внедрять новое решение, архитектор думает о его влиянии на производительность, отказоустойчивость и стоимость поддержки в будущем.
2. Умение говорить на языке бизнеса
Админ: «Нам нужно обновить СХД, потому что старая медленная».
Архитектор: «Инвестировав в новую СХД, мы ускорим формирование отчетов на 40% и снизим риск простоя, час которого обходится компании в X тысяч рублей».
Бизнес не мыслит гигабайтами и мегагерцами. Он мыслит деньгами, рисками и эффективностью. Умение перевести техническую необходимость в измеримую бизнес-выгоду — ключевой навык для получения бюджетов и реализации крупных проектов.
3. Проактивная лень (Стратегическая автоматизация)
Реактивная автоматизация — это скрипт, который перезапускает упавший сервис. Проактивная — это система мониторинга и автоматизации, которая предсказывает возможное падение по косвенным метрикам (например, рост iowait) и заранее переносит нагрузку или уведомляет инженера.
Архитектор не просто автоматизирует рутину. Он проектирует системы, которые требуют минимального ручного вмешательства и способны к самодиагностике.
Технические знания — это то, что позволяет нам работать.
Но именно эти три навыка определяют, насколько высоко мы сможем подняться.
#карьера #softskills #архитектура #devops #sysadmin
Вечер — хорошее время, чтобы на шаг отойти от рутины и подумать о будущем. Мы все умеем гуглить ошибки, чинить упавший сервер и настраивать бэкапы. Эти технические навыки — наш фундамент. Но чтобы расти дальше, от реактивного «тушения пожаров» к проактивному проектированию систем, нужны другие компетенции.
Вот 3 «гибких» навыка, которые отличают опытного админа от архитектора.
1. Системное мышление (Видеть лес за деревьями)
Админ: думает, как починить конкретный сервис.
Архитектор: спрашивает, почему он сломался, и как изменить систему, чтобы это не повторилось.
Это умение видеть не отдельные серверы, а всю инфраструктуру как единый организм: как связаны сеть, базы данных, приложения и безопасность. Прежде чем внедрять новое решение, архитектор думает о его влиянии на производительность, отказоустойчивость и стоимость поддержки в будущем.
2. Умение говорить на языке бизнеса
Админ: «Нам нужно обновить СХД, потому что старая медленная».
Архитектор: «Инвестировав в новую СХД, мы ускорим формирование отчетов на 40% и снизим риск простоя, час которого обходится компании в X тысяч рублей».
Бизнес не мыслит гигабайтами и мегагерцами. Он мыслит деньгами, рисками и эффективностью. Умение перевести техническую необходимость в измеримую бизнес-выгоду — ключевой навык для получения бюджетов и реализации крупных проектов.
3. Проактивная лень (Стратегическая автоматизация)
Реактивная автоматизация — это скрипт, который перезапускает упавший сервис. Проактивная — это система мониторинга и автоматизации, которая предсказывает возможное падение по косвенным метрикам (например, рост iowait) и заранее переносит нагрузку или уведомляет инженера.
Архитектор не просто автоматизирует рутину. Он проектирует системы, которые требуют минимального ручного вмешательства и способны к самодиагностике.
Технические знания — это то, что позволяет нам работать.
Но именно эти три навыка определяют, насколько высоко мы сможем подняться.
#карьера #softskills #архитектура #devops #sysadmin
🔥4
От Запрета к Контролю: Харденинг Windows с AppLocker на Уровне Архитектора
В современных IT-инфраструктурах традиционные антивирусы и черные списки уже недостаточны. Они реагируют на известные угрозы, оставляя систему уязвимой для атак "нулевого дня". Настоящая безопасность начинается с проактивного контроля.
AppLocker — это не просто блокировщик .exe, а мощный фреймворк для реализации принципа наименьших привилегий на уровне приложений. В отличие от WDAC, AppLocker идеально подходит для гранулярного управления доступом для конкретных пользователей или групп, например, на терминальных серверах.
Шаг 1: Создание Базовой Политики в Режиме Аудита
Самая дорогая ошибка при внедрении AppLocker — немедленное включение блокирующих правил. Это почти гарантированно нарушит бизнес-процессы. Архитектурный подход начинается со сбора данных в безопасном "режиме аудита" (Audit mode). В этом режиме все действия лишь записываются в журнал, не влияя на работу пользователей.
План действий:
▪️ Убедитесь, что служба "Удостоверение приложения" (Application Identity) запущена и настроена на автозапуск. Без нее AppLocker не работает.
▪️ Через GPO перейдите в Computer Configuration > ... > AppLocker.
▪️ Для каждого типа правил (Executable, Script и т.д.) создайте правила по умолчанию (Default Rules). Они разрешают запуск всего из C:\Windows и C:\Program Files, что необходимо для работы ОС.
▪️ В свойствах AppLocker установите режим принуждения в "Audit only" для всех категорий.
Шаг 2: Архитектурный Подход к Исключениям через Группы AD
Управление исключениями через прямое редактирование GPO — негибко. Мощь AppLocker раскрывается при привязке правил к группам безопасности Active Directory. Это превращает статическую политику в динамическую систему управления доступом.
Сценарий: Заблокировать mmc.exe для всех, кроме системных администраторов.
❌ Неправильный подход: Создать правило "Deny" для "Everyone" и "Allow" для "Admins". Microsoft не рекомендует смешивать Deny и Allow для одного приложения.
✅ Правильный подход: Использовать только разрешающие правила. Мы создаем правило, которое разрешает запуск mmc.exe только членам специальной группы. Чтобы дать доступ, нужно просто добавить пользователя в группу, а не лезть в GPO.
Действия:
Создайте группу безопасности в AD:
PowerShell
В AppLocker (Executable Rules) создайте новое правило "Allow".
Укажите созданную группу SG_AppLocker_Allow_MMC.
В качестве условия выберите "Издатель" (Publisher) и укажите путь к mmc.exe. Это правило не сломается при обновлении файла, в отличие от хэша.
Шаг 3: Блокировка Microsoft Store и WinGet
Правила по умолчанию для упакованных приложений слишком разрешающие. Они позволяют любому пользователю устанавливать ПО из Microsoft Store.
План действий:
▪️ Удалите стандартное правило "Allow all signed packaged apps".
▪️ Создайте новое правило по издателю, разрешающее приложения только от CN=Microsoft Corporation.... Это позволит работать системным UWP-приложениям (Калькулятор, Фото), но заблокирует установку сторонних.
🔄 Заключение: От Политики к Процессу
Внедрение AppLocker — это не разовая настройка, а непрерывный процесс: аудит, анализ логов (Event Viewer > AppLocker), уточнение правил и только потом — переход в режим принудительного применения (Enforce rules). Регулярно просматривайте логи, чтобы адаптировать политики к новым легитимным приложениям.
#Security #Windows #AppLocker #BlueTeam #Hardening #GPO
В современных IT-инфраструктурах традиционные антивирусы и черные списки уже недостаточны. Они реагируют на известные угрозы, оставляя систему уязвимой для атак "нулевого дня". Настоящая безопасность начинается с проактивного контроля.
AppLocker — это не просто блокировщик .exe, а мощный фреймворк для реализации принципа наименьших привилегий на уровне приложений. В отличие от WDAC, AppLocker идеально подходит для гранулярного управления доступом для конкретных пользователей или групп, например, на терминальных серверах.
Шаг 1: Создание Базовой Политики в Режиме Аудита
Самая дорогая ошибка при внедрении AppLocker — немедленное включение блокирующих правил. Это почти гарантированно нарушит бизнес-процессы. Архитектурный подход начинается со сбора данных в безопасном "режиме аудита" (Audit mode). В этом режиме все действия лишь записываются в журнал, не влияя на работу пользователей.
План действий:
▪️ Убедитесь, что служба "Удостоверение приложения" (Application Identity) запущена и настроена на автозапуск. Без нее AppLocker не работает.
▪️ Через GPO перейдите в Computer Configuration > ... > AppLocker.
▪️ Для каждого типа правил (Executable, Script и т.д.) создайте правила по умолчанию (Default Rules). Они разрешают запуск всего из C:\Windows и C:\Program Files, что необходимо для работы ОС.
▪️ В свойствах AppLocker установите режим принуждения в "Audit only" для всех категорий.
Шаг 2: Архитектурный Подход к Исключениям через Группы AD
Управление исключениями через прямое редактирование GPO — негибко. Мощь AppLocker раскрывается при привязке правил к группам безопасности Active Directory. Это превращает статическую политику в динамическую систему управления доступом.
Сценарий: Заблокировать mmc.exe для всех, кроме системных администраторов.
❌ Неправильный подход: Создать правило "Deny" для "Everyone" и "Allow" для "Admins". Microsoft не рекомендует смешивать Deny и Allow для одного приложения.
✅ Правильный подход: Использовать только разрешающие правила. Мы создаем правило, которое разрешает запуск mmc.exe только членам специальной группы. Чтобы дать доступ, нужно просто добавить пользователя в группу, а не лезть в GPO.
Действия:
Создайте группу безопасности в AD:
PowerShell
New-ADGroup -Name "SG_AppLocker_Allow_MMC" -GroupScope Global
В AppLocker (Executable Rules) создайте новое правило "Allow".
Укажите созданную группу SG_AppLocker_Allow_MMC.
В качестве условия выберите "Издатель" (Publisher) и укажите путь к mmc.exe. Это правило не сломается при обновлении файла, в отличие от хэша.
Шаг 3: Блокировка Microsoft Store и WinGet
Правила по умолчанию для упакованных приложений слишком разрешающие. Они позволяют любому пользователю устанавливать ПО из Microsoft Store.
План действий:
▪️ Удалите стандартное правило "Allow all signed packaged apps".
▪️ Создайте новое правило по издателю, разрешающее приложения только от CN=Microsoft Corporation.... Это позволит работать системным UWP-приложениям (Калькулятор, Фото), но заблокирует установку сторонних.
🔄 Заключение: От Политики к Процессу
Внедрение AppLocker — это не разовая настройка, а непрерывный процесс: аудит, анализ логов (Event Viewer > AppLocker), уточнение правил и только потом — переход в режим принудительного применения (Enforce rules). Регулярно просматривайте логи, чтобы адаптировать политики к новым легитимным приложениям.
#Security #Windows #AppLocker #BlueTeam #Hardening #GPO
Ansible для Всех: Автоматизация Харденинга Linux-серверов без Написания Ролей с Нуля
😫 Проблема: Ручной Харденинг
Представим: у вас 50+ Linux-серверов, и служба безопасности требует привести их в соответствие со стандартом CIS Benchmarks. Делать это вручную по SSH — прямой путь к ошибкам, несоответствиям и бессонным ночам. А главное, через месяц конфигурации серверов неизбежно "разъедутся" (configuration drift).
💡 Решение: Сила Ansible Galaxy и Готовых Ролей
Ansible — это не только написание плейбуков с нуля. Его экосистема включает Ansible Galaxy — огромный репозиторий готовых ролей. Для нашей задачи идеально подходит коллекция devsec.hardening, реализующая лучшие практики безопасности.
1️⃣ Шаг 1: Подготовка Окружения
Установите Ansible на вашу управляющую машину.
Установите коллекцию devsec.hardening одной командой:
Bash
Создайте inventory.ini файл с вашими серверами:
Ini, TOML
2️⃣ Шаг 2: Создание Плейбука с Готовой Ролью
Вам не нужно знать, как именно работает каждый параметр безопасности. Вам нужно лишь декларативно описать исключения для вашей среды. Например, роль os_hardening по умолчанию отключает IP-форвардинг, который нужен для Docker. Мы можем это легко переопределить.
Код плейбука (playbook.yml):
YAML
3️⃣ Шаг 3: Запуск и Проверка
Сначала выполняем "пробный запуск", который покажет изменения, но ничего не применит:
Bash
Убедившись, что всё корректно, запускаем в рабочем режиме:
Bash
Ключевое свойство Ansible — идемпотентность. Повторный запуск плейбука не вызовет ошибок. Ansible просто проверит, что все настройки в порядке, и исправит только то, что отклонилось от стандарта. Это позволяет использовать плейбук для регулярной борьбы с "дрейфом конфигурации".
🚀 Заключение: От Администратора к Инженеру по Автоматизации
С помощью нескольких десятков строк YAML-кода мы применили сотни настроек безопасности к целой группе серверов. Это и есть переход к Infrastructure as Code (IaC). Вы не просто администрируете серверы — вы управляете их состоянием через код.
#IaC #Ansible #Linux #Hardening #DevSecOps #Automation
😫 Проблема: Ручной Харденинг
Представим: у вас 50+ Linux-серверов, и служба безопасности требует привести их в соответствие со стандартом CIS Benchmarks. Делать это вручную по SSH — прямой путь к ошибкам, несоответствиям и бессонным ночам. А главное, через месяц конфигурации серверов неизбежно "разъедутся" (configuration drift).
💡 Решение: Сила Ansible Galaxy и Готовых Ролей
Ansible — это не только написание плейбуков с нуля. Его экосистема включает Ansible Galaxy — огромный репозиторий готовых ролей. Для нашей задачи идеально подходит коллекция devsec.hardening, реализующая лучшие практики безопасности.
1️⃣ Шаг 1: Подготовка Окружения
Установите Ansible на вашу управляющую машину.
Установите коллекцию devsec.hardening одной командой:
Bash
ansible-galaxy collection install devsec.hardening
Создайте inventory.ini файл с вашими серверами:
Ini, TOML
[webservers]
web01.example.com
web02.example.com
[dbservers]
db01.example.com
2️⃣ Шаг 2: Создание Плейбука с Готовой Ролью
Вам не нужно знать, как именно работает каждый параметр безопасности. Вам нужно лишь декларативно описать исключения для вашей среды. Например, роль os_hardening по умолчанию отключает IP-форвардинг, который нужен для Docker. Мы можем это легко переопределить.
Код плейбука (playbook.yml):
YAML
- name: Harden all Linux servers
hosts: all
become: yes
roles:
- role: devsec.hardening.os_hardening
vars:
# Пример: разрешаем Docker'у работать
sysctl_overwrite:
net.ipv4.ip_forward: 1
# Пример: оставляем файловую систему vfat для UEFI
os_filesystem_whitelist:
- vfat
- name: Harden SSH configuration
hosts: all
become: yes
roles:
- role: devsec.hardening.ssh_hardening
vars:
# Пример: разрешаем вход по паролю (не для прода!)
sshd_password_authentication: "yes"
3️⃣ Шаг 3: Запуск и Проверка
Сначала выполняем "пробный запуск", который покажет изменения, но ничего не применит:
Bash
ansible-playbook -i inventory.ini playbook.yml --check
Убедившись, что всё корректно, запускаем в рабочем режиме:
Bash
ansible-playbook -i inventory.ini playbook.yml
Ключевое свойство Ansible — идемпотентность. Повторный запуск плейбука не вызовет ошибок. Ansible просто проверит, что все настройки в порядке, и исправит только то, что отклонилось от стандарта. Это позволяет использовать плейбук для регулярной борьбы с "дрейфом конфигурации".
🚀 Заключение: От Администратора к Инженеру по Автоматизации
С помощью нескольких десятков строк YAML-кода мы применили сотни настроек безопасности к целой группе серверов. Это и есть переход к Infrastructure as Code (IaC). Вы не просто администрируете серверы — вы управляете их состоянием через код.
#IaC #Ansible #Linux #Hardening #DevSecOps #Automation
etcd: Цифровой мозг Kubernetes и современных систем
Вечером предлагаю поговорить не о командах, а об идеях. Что общего у Kubernetes, Cloudflare, CoreDNS и десятков других сложных систем? В их основе лежит один и тот же тихий и невероятно надежный компонент — etcd.
Многие админы никогда не работали с ним напрямую, но именно он является цифровой нервной системой для самых критичных частей современной инфраструктуры.
Что такое etcd простыми словами?
Это распределенное хранилище формата «ключ-значение». По сути, это как словарь или телефонная книга, но размазанная по нескольким серверам (кластеру).
Его суперсила — гарантия консистентности. Благодаря алгоритму консенсуса Raft, если вы записали данные в etcd, вы можете быть на 100% уверены, что они сохранены, верны и одинаковы на всех узлах. Кластер etcd может пережить отказ нескольких серверов, не потеряв ни байта.
Почему это так важно для архитектора?
В распределенной системе (как Kubernetes) главная проблема — договориться. Как сотни компонентов (scheduler, kubelet, controllers) должны знать, в каком состоянии находится кластер? Какое состояние является «правильным»?
etcd решает эту проблему, выступая как единый источник правды (Single Source of Truth).
Хранение состояния: В etcd хранится вся конфигурация K8s кластера: какие поды должны быть запущены, какие у них IP, какие секреты используются. Это «желаемое состояние» системы.
Координация и блокировки: Какой контроллер сейчас главный (leader election)? etcd помогает сервисам «договориться» и избежать конфликтов.
Обнаружение сервисов (Service Discovery): Как один сервис находит другой? Он смотрит в etcd, как в адресную книгу.
Что это значит для нас, админов?
Понимание etcd — это ключ к пониманию того, как работает и «думает» Kubernetes.
Бэкап etcd — это бэкап всего состояния вашего кластера. Потеряете etcd — потеряете всё. Это самая важная резервная копия в мире K8s.
Здоровье etcd — это здоровье вашего кластера. Медленный диск под etcd = медленный API и медленная работа всего оркестратора.
С помощью утилиты etcdctl можно напрямую заглянуть «в мозг» кластера (но делать это в prod нужно с большой осторожностью).
Итог: etcd — это не просто база данных. Это фундаментальный паттерн для построения отказоустойчивых распределенных систем. Понимание принципов его работы — прямой шаг от администрирования отдельных машин к проектированию сложных, надежных экосистем.
Отличного вечера!
#Kubernetes #DistributedSystems #etcd #DevOps #Архитектура #SysAdmin
Вечером предлагаю поговорить не о командах, а об идеях. Что общего у Kubernetes, Cloudflare, CoreDNS и десятков других сложных систем? В их основе лежит один и тот же тихий и невероятно надежный компонент — etcd.
Многие админы никогда не работали с ним напрямую, но именно он является цифровой нервной системой для самых критичных частей современной инфраструктуры.
Что такое etcd простыми словами?
Это распределенное хранилище формата «ключ-значение». По сути, это как словарь или телефонная книга, но размазанная по нескольким серверам (кластеру).
Его суперсила — гарантия консистентности. Благодаря алгоритму консенсуса Raft, если вы записали данные в etcd, вы можете быть на 100% уверены, что они сохранены, верны и одинаковы на всех узлах. Кластер etcd может пережить отказ нескольких серверов, не потеряв ни байта.
Почему это так важно для архитектора?
В распределенной системе (как Kubernetes) главная проблема — договориться. Как сотни компонентов (scheduler, kubelet, controllers) должны знать, в каком состоянии находится кластер? Какое состояние является «правильным»?
etcd решает эту проблему, выступая как единый источник правды (Single Source of Truth).
Хранение состояния: В etcd хранится вся конфигурация K8s кластера: какие поды должны быть запущены, какие у них IP, какие секреты используются. Это «желаемое состояние» системы.
Координация и блокировки: Какой контроллер сейчас главный (leader election)? etcd помогает сервисам «договориться» и избежать конфликтов.
Обнаружение сервисов (Service Discovery): Как один сервис находит другой? Он смотрит в etcd, как в адресную книгу.
Что это значит для нас, админов?
Понимание etcd — это ключ к пониманию того, как работает и «думает» Kubernetes.
Бэкап etcd — это бэкап всего состояния вашего кластера. Потеряете etcd — потеряете всё. Это самая важная резервная копия в мире K8s.
Здоровье etcd — это здоровье вашего кластера. Медленный диск под etcd = медленный API и медленная работа всего оркестратора.
С помощью утилиты etcdctl можно напрямую заглянуть «в мозг» кластера (но делать это в prod нужно с большой осторожностью).
Итог: etcd — это не просто база данных. Это фундаментальный паттерн для построения отказоустойчивых распределенных систем. Понимание принципов его работы — прямой шаг от администрирования отдельных машин к проектированию сложных, надежных экосистем.
Отличного вечера!
#Kubernetes #DistributedSystems #etcd #DevOps #Архитектура #SysAdmin
Windows Security: Как правильно заблокировать Microsoft Store через AppLocker
Доброе утро! Начинаем день с важного шага по усилению безопасности рабочих станций.
Одна из неочевидных «лазеек» в Windows — стандартные правила AppLocker для упакованных приложений (Packaged apps). По умолчанию они слишком разрешающие и позволяют любому пользователю устанавливать ПО из Microsoft Store, что открывает вектор для нежелательного ПО и потенциальных атак.
Давайте закроем эту дверь, оставив работать только необходимые системные приложения.
План действий:
❌ 1. Удаляем слишком общее правило
В политике AppLocker для Packaged App Rules найдите и удалите правило по умолчанию, которое называется (Default Rule) Allow all signed packaged apps.
✅ 2. Создаём точечное разрешающее правило
Вместо удаленного правила создайте новое, основанное на издателе (Publisher). Разрешите приложения только от Microsoft:
Издатель: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Результат: После применения этой политики системные UWP-приложения (Калькулятор, Фотографии и т.д.) продолжат работать, но возможность установки сторонних приложений из Microsoft Store будет заблокирована.
🔄 От Политики к Процессу
Помните главный принцип работы с AppLocker: это не разовая настройка, а непрерывный процесс.
Аудит → Анализ логов → Уточнение правил → Принуждение
Регулярно просматривайте журналы событий AppLocker в режиме аудита, чтобы адаптировать политики к новым легитимным приложениям в вашей среде, прежде чем включать блокировку.
#Security #Windows #AppLocker #BlueTeam #Hardening #GPO
Доброе утро! Начинаем день с важного шага по усилению безопасности рабочих станций.
Одна из неочевидных «лазеек» в Windows — стандартные правила AppLocker для упакованных приложений (Packaged apps). По умолчанию они слишком разрешающие и позволяют любому пользователю устанавливать ПО из Microsoft Store, что открывает вектор для нежелательного ПО и потенциальных атак.
Давайте закроем эту дверь, оставив работать только необходимые системные приложения.
План действий:
❌ 1. Удаляем слишком общее правило
В политике AppLocker для Packaged App Rules найдите и удалите правило по умолчанию, которое называется (Default Rule) Allow all signed packaged apps.
✅ 2. Создаём точечное разрешающее правило
Вместо удаленного правила создайте новое, основанное на издателе (Publisher). Разрешите приложения только от Microsoft:
Издатель: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Результат: После применения этой политики системные UWP-приложения (Калькулятор, Фотографии и т.д.) продолжат работать, но возможность установки сторонних приложений из Microsoft Store будет заблокирована.
🔄 От Политики к Процессу
Помните главный принцип работы с AppLocker: это не разовая настройка, а непрерывный процесс.
Аудит → Анализ логов → Уточнение правил → Принуждение
Регулярно просматривайте журналы событий AppLocker в режиме аудита, чтобы адаптировать политики к новым легитимным приложениям в вашей среде, прежде чем включать блокировку.
#Security #Windows #AppLocker #BlueTeam #Hardening #GPO
PowerShell/Bash: Массовое Переименование Файлов с Журналированием (и Откатом!)
Сколько раз приходилось переименовывать сотни файлов, добавляя префикс, меняя расширение или убирая лишние символы? Руками — долго и чревато ошибками. Автоматизация — наш лучший друг.
Но что, если что-то пойдёт не так? Важно иметь план отката. Этот пост покажет, как массово переименовывать файлы с сохранением журнала операций, чтобы при необходимости всё можно было вернуть как было.
⊞ Windows (PowerShell): С Журналом и Откатом
Этот скрипт позволяет добавить префикс к именам файлов, записывая старые и новые имена в CSV-файл для возможного отката.
▪️ Скрипт (Rename-Files.ps1):
PowerShell
▪️ Как использовать:
Сохраните первый блок как Rename-Files.ps1.
Сохраните второй блок (от <# до конца) как Revert-Rename.ps1.
Запустите .\Rename-Files.ps1 -Path "C:\MyFiles" -Prefix "ARCHIVE_"
Для отката: .\Revert-Rename.ps1 -LogFile "C:\MyFiles\rename_log.csv"
Сколько раз приходилось переименовывать сотни файлов, добавляя префикс, меняя расширение или убирая лишние символы? Руками — долго и чревато ошибками. Автоматизация — наш лучший друг.
Но что, если что-то пойдёт не так? Важно иметь план отката. Этот пост покажет, как массово переименовывать файлы с сохранением журнала операций, чтобы при необходимости всё можно было вернуть как было.
⊞ Windows (PowerShell): С Журналом и Откатом
Этот скрипт позволяет добавить префикс к именам файлов, записывая старые и новые имена в CSV-файл для возможного отката.
▪️ Скрипт (Rename-Files.ps1):
PowerShell
[CmdletBinding()]
param(
[string]$Path = (Get-Location).Path,
[string]$Prefix = "NEW_",
[string]$LogFile = "rename_log.csv"
)
# Проверяем, существует ли папка для логов
$logPath = Join-Path $Path $LogFile
# Если лог-файл уже существует, спрашиваем, перезаписать или добавить
if (Test-Path $logPath) {
Write-Warning "Log file '$logPath' already exists. Appending to it."
}
$renameActions = @()
Write-Host "Начинаем переименование файлов в '$Path' с префиксом '$Prefix'..."
Get-ChildItem -Path $Path -File | ForEach-Object {
$oldName = $_.Name
$newName = $Prefix + $oldName
try {
Rename-Item -Path $_.FullName -NewName $newName -PassThru -ErrorAction Stop
Write-Host "Переименовано: '$oldName' -> '$newName'"
$renameActions += [PSCustomObject]@{
Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
OldPath = $_.FullName
NewPath = Join-Path $_.Directory.FullName $newName
OldName = $oldName
NewName = $newName
Status = "Success"
Action = "Rename"
}
}
catch {
Write-Error "Ошибка при переименовании '$oldName': $($_.Exception.Message)"
$renameActions += [PSCustomObject]@{
Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
OldPath = $_.FullName
NewPath = $null
OldName = $oldName
NewName = $null
Status = "Failed"
Action = "Rename"
ErrorMessage = $_.Exception.Message
}
}
}
# Экспортируем журнал
$renameActions | Export-Csv -Path $logPath -Append -NoTypeInformation -Force
Write-Host "Журнал операций сохранен в '$logPath'"
# --- Скрипт для отката (сохраните отдельно как Revert-Rename.ps1) ---
<#
.SYNOPSIS
Откатывает операции переименования файлов на основе CSV-лога.
.EXAMPLE
.\Revert-Rename.ps1 -LogFile "rename_log.csv"
#>
# Revert-Rename.ps1
param(
[string]$LogFile = "rename_log.csv"
)
if (-not (Test-Path $LogFile)) {
Write-Error "Log file '$LogFile' not found."
exit
}
$actions = Import-Csv -Path $LogFile | Where-Object { $_.Status -eq "Success" -and $_.Action -eq "Rename" }
Write-Host "Начинаем откат операций переименования..."
$actions | ForEach-Object {
$currentNewPath = $_.NewPath
$originalOldName = $_.OldName
if (Test-Path $currentNewPath) {
try {
Rename-Item -Path $currentNewPath -NewName $originalOldName -PassThru -ErrorAction Stop
Write-Host "Откачено: '$currentNewPath' -> '$originalOldName'"
}
catch {
Write-Error "Ошибка при откате '$currentNewPath': $($_.Exception.Message)"
}
} else {
Write-Warning "Файл не найден для отката: '$currentNewPath'. Возможно, уже откачен или удален."
}
}
Write-Host "Откат завершен."
▪️ Как использовать:
Сохраните первый блок как Rename-Files.ps1.
Сохраните второй блок (от <# до конца) как Revert-Rename.ps1.
Запустите .\Rename-Files.ps1 -Path "C:\MyFiles" -Prefix "ARCHIVE_"
Для отката: .\Revert-Rename.ps1 -LogFile "C:\MyFiles\rename_log.csv"
🔥2
🐧 Linux (Bash): Массовое Переименование + Журнал
Этот Bash-скрипт массово переименовывает файлы, добавляя префикс и создавая простой лог.
▪️ Скрипт (rename_files.sh):
Bash
▪️ Как использовать:
Сохраните как rename_files.sh и дайте права на выполнение: chmod +x rename_files.sh
Запустите: ./rename_files.sh /path/to/my/files "ARCHIVE_"
/path/to/my/files — директория.
"ARCHIVE_" — префикс.
📌 Важно для отката в Bash:
В отличие от PowerShell, в Bash нет встроенной команды для отката на основе лога mv. Для отката вам нужно будет вручную проанализировать созданный rename_log_*.txt и выполнить обратные команды mv.
Bash
# Пример записи из лога:
# SUCCESS: 'old_file.txt' -> 'NEW_old_file.txt'
# Команда для отката:
mv /path/to/files/NEW_old_file.txt /path/to/files/old_file.txt
Это демонстрирует, почему PowerShell часто предпочтительнее для сложных операций, где требуется атомарность и лёгкость отката.
#powershell #bash #скрипты #automation #files #sysadmin
Этот Bash-скрипт массово переименовывает файлы, добавляя префикс и создавая простой лог.
▪️ Скрипт (rename_files.sh):
Bash
#!/bin/bash
# Путь к директории (по умолчанию - текущая)
TARGET_DIR="${1:-.}"
# Префикс для новых имен
PREFIX="${2:-NEW_}"
# Файл для журнала
LOG_FILE="${TARGET_DIR}/rename_log_$(date +%Y%m%d%H%M%S).txt"
echo "Начинаем переименование файлов в '${TARGET_DIR}' с префиксом '${PREFIX}'..."
echo "Журнал будет сохранен в '${LOG_FILE}'"
echo "--- Переименование файлов ---" > "${LOG_FILE}"
find "${TARGET_DIR}" -maxdepth 1 -type f | while read -r old_path; do
old_name=$(basename "$old_path")
new_name="${PREFIX}${old_name}"
new_path=$(dirname "$old_path")/"$new_name"
if mv -v "$old_path" "$new_path"; then
echo "Переименовано: '$old_name' -> '$new_name'"
echo "$(date +%Y-%m-%d\ %H:%M:%S) SUCCESS: '$old_name' -> '$new_name'" >> "${LOG_FILE}"
else
echo "Ошибка при переименовании: '$old_name'"
echo "$(date +%Y-%m-%d\ %H:%M:%S) FAILED: '$old_name'" >> "${LOG_FILE}"
fi
done
echo "Переименование завершено. Журнал в '${LOG_FILE}'"
echo "--- Конец журнала ---" >> "${LOG_FILE}"
▪️ Как использовать:
Сохраните как rename_files.sh и дайте права на выполнение: chmod +x rename_files.sh
Запустите: ./rename_files.sh /path/to/my/files "ARCHIVE_"
/path/to/my/files — директория.
"ARCHIVE_" — префикс.
📌 Важно для отката в Bash:
В отличие от PowerShell, в Bash нет встроенной команды для отката на основе лога mv. Для отката вам нужно будет вручную проанализировать созданный rename_log_*.txt и выполнить обратные команды mv.
Bash
`# Пример записи из лога:
# SUCCESS: 'old_file.txt' -> 'NEW_old_file.txt'
# Команда для отката:
mv /path/to/files/NEW_old_file.txt /path/to/files/old_file.txt
`Это демонстрирует, почему PowerShell часто предпочтительнее для сложных операций, где требуется атомарность и лёгкость отката.
#powershell #bash #скрипты #automation #files #sysadmin
🔥2
От Пингов к Инсайтам: Развертывание Стека Observability (Prometheus, Loki, Grafana)
Традиционный мониторинг отвечает на вопрос «Что сломалось?». Наблюдаемость (observability) отвечает на вопрос «Почему это сломалось?». Она строится на трех столпах: метриках (числа), логах (события) и трейсах (путь запроса).
Этот гайд проведет вас по полному циклу развертывания золотого стандарта open-source для связки метрик и логов.
1️⃣ Шаг 1: Установка Prometheus и Node Exporter (Метрики)
▪️ Prometheus: Это сервер, который будет опрашивать (scrape) источники метрик. Скачайте и запустите его.
▪️ Node Exporter: Это агент, который вы ставите на каждый наблюдаемый сервер. Он собирает системные метрики (CPU, RAM, диск, сеть) и отдает их Prometheus'у.
Существуют сотни других экспортеров для баз данных, веб-серверов и оборудования, что делает Prometheus универсальной платформой.
▪️ Конфигурация prometheus.yml: Добавьте Node Exporter как цель.
YAML
После запуска проверьте метрики в веб-интерфейсе Prometheus (http://<prometheus_ip>:9090).
2️⃣ Шаг 2: Установка Loki и Promtail (Логи)
▪️ Loki: Сервер, который принимает и хранит ваши логи.
▪️ Promtail: Агент, который ставится на серверы, "читает" лог-файлы (/var/log/*.log), добавляет к ним метки (labels) и отправляет в Loki.
Ключевое отличие Loki от ELK: он не индексирует всё содержимое логов, а только метки (например, job="nginx"). Это делает его чрезвычайно экономичным и быстрым.
▪️ Конфигурация promtail-config.yml:
YAML
3️⃣ Шаг 3: Установка Grafana и Интеграция
▪️ Установите и запустите Grafana — наш будущий центр управления.
▪️ В веб-интерфейсе (http://<grafana_ip>:3000) перейдите в Connections > Data sources.
▪️ Добавьте Prometheus, указав его URL.
▪️ Добавьте Loki, указав его URL.
4️⃣ Шаг 4: Магия Корреляции Данных
Теперь самое главное. На одном экране мы видим график метрик и связанные с ним логи.
Сценарий: Пользователи жалуются на тормоза сайта.
Вы открываете дашборд в Grafana и видите пик загрузки CPU (данные из Prometheus).
Прямо под этим графиком у вас панель с логами из Loki, отфильтрованными по job="nginx" и level="error".
Вы видите, что в момент пика CPU в логах Nginx появился шквал ошибок upstream timed out.
Вывод: Проблема не в сервере, а в бэкенд-приложении. Диагностика заняла минуты, а не часы.
План действий в Grafana:
▪️ Импортируйте готовый дашборд для Node Exporter (ID: 1860).
▪️ Добавьте на него новую панель с источником данных Loki.
▪️ Используйте LogQL-запрос для фильтрации, например: {host="$hostname"} |= "error".
#Observability #Monitoring #Prometheus #Loki #Grafana #DevOps
Традиционный мониторинг отвечает на вопрос «Что сломалось?». Наблюдаемость (observability) отвечает на вопрос «Почему это сломалось?». Она строится на трех столпах: метриках (числа), логах (события) и трейсах (путь запроса).
Этот гайд проведет вас по полному циклу развертывания золотого стандарта open-source для связки метрик и логов.
1️⃣ Шаг 1: Установка Prometheus и Node Exporter (Метрики)
▪️ Prometheus: Это сервер, который будет опрашивать (scrape) источники метрик. Скачайте и запустите его.
▪️ Node Exporter: Это агент, который вы ставите на каждый наблюдаемый сервер. Он собирает системные метрики (CPU, RAM, диск, сеть) и отдает их Prometheus'у.
Существуют сотни других экспортеров для баз данных, веб-серверов и оборудования, что делает Prometheus универсальной платформой.
▪️ Конфигурация prometheus.yml: Добавьте Node Exporter как цель.
YAML
scrape_configs:
- job_name: 'node_exporter_metrics'
static_configs:
- targets: ['your_server_ip:9100']
После запуска проверьте метрики в веб-интерфейсе Prometheus (http://<prometheus_ip>:9090).
2️⃣ Шаг 2: Установка Loki и Promtail (Логи)
▪️ Loki: Сервер, который принимает и хранит ваши логи.
▪️ Promtail: Агент, который ставится на серверы, "читает" лог-файлы (/var/log/*.log), добавляет к ним метки (labels) и отправляет в Loki.
Ключевое отличие Loki от ELK: он не индексирует всё содержимое логов, а только метки (например, job="nginx"). Это делает его чрезвычайно экономичным и быстрым.
▪️ Конфигурация promtail-config.yml:
YAML
server:
http_listen_port: 9080
clients:
- url: http://<loki_ip>:3100/loki/api/v1/push
scrape_configs:
- job_name: system
static_configs:
- targets:
- localhost
labels:
job: varlogs
host: your_server_hostname
__path__: /var/log/*.log
3️⃣ Шаг 3: Установка Grafana и Интеграция
▪️ Установите и запустите Grafana — наш будущий центр управления.
▪️ В веб-интерфейсе (http://<grafana_ip>:3000) перейдите в Connections > Data sources.
▪️ Добавьте Prometheus, указав его URL.
▪️ Добавьте Loki, указав его URL.
4️⃣ Шаг 4: Магия Корреляции Данных
Теперь самое главное. На одном экране мы видим график метрик и связанные с ним логи.
Сценарий: Пользователи жалуются на тормоза сайта.
Вы открываете дашборд в Grafana и видите пик загрузки CPU (данные из Prometheus).
Прямо под этим графиком у вас панель с логами из Loki, отфильтрованными по job="nginx" и level="error".
Вы видите, что в момент пика CPU в логах Nginx появился шквал ошибок upstream timed out.
Вывод: Проблема не в сервере, а в бэкенд-приложении. Диагностика заняла минуты, а не часы.
План действий в Grafana:
▪️ Импортируйте готовый дашборд для Node Exporter (ID: 1860).
▪️ Добавьте на него новую панель с источником данных Loki.
▪️ Используйте LogQL-запрос для фильтрации, например: {host="$hostname"} |= "error".
#Observability #Monitoring #Prometheus #Loki #Grafana #DevOps
Пятница, вечер. Ноутбук закрыт, задачи на паузе.
Неделя была насыщенной, и пора выдохнуть. У каждого из нас были свои сражения: с железом, софтом, сетями или... понедельником.
Давайте подведем итоги недели в нашем стиле. Без отчетов и совещаний, а одним кликом.
Опрос: Главная «боль» этой недели — это...
1️⃣ Сетевые проблемы (VPN, DNS, «не пингуется!»)
Когда половина дня уходит на поиск причины, а виноват кабель или кривой роутинг.
2️⃣ Софт/Сервисы (база упала, приложение зависло)
Когда логи кричат об ошибках, а разработчики говорят, что у них «все работает».
3️⃣ Железо/Виртуализация (диски, память, хосты)
Когда сервер решил, что ему пора на пенсию, не предупредив об этом.
4️⃣ Пользователи/Безопасность (странные тикеты, фишинг)
Когда самый непредсказуемый элемент системы — это человек.
5️⃣ Всё было на удивление спокойно (такое бывает?)
Когда все работает как часы, и ты начинаешь подозревать, что что-то не так.
Всем, кто справился — наше уважение. Отличных и спокойных выходных, коллеги!
#Пятница #SysadminLife #Опрос #IT
Неделя была насыщенной, и пора выдохнуть. У каждого из нас были свои сражения: с железом, софтом, сетями или... понедельником.
Давайте подведем итоги недели в нашем стиле. Без отчетов и совещаний, а одним кликом.
Опрос: Главная «боль» этой недели — это...
1️⃣ Сетевые проблемы (VPN, DNS, «не пингуется!»)
Когда половина дня уходит на поиск причины, а виноват кабель или кривой роутинг.
2️⃣ Софт/Сервисы (база упала, приложение зависло)
Когда логи кричат об ошибках, а разработчики говорят, что у них «все работает».
3️⃣ Железо/Виртуализация (диски, память, хосты)
Когда сервер решил, что ему пора на пенсию, не предупредив об этом.
4️⃣ Пользователи/Безопасность (странные тикеты, фишинг)
Когда самый непредсказуемый элемент системы — это человек.
5️⃣ Всё было на удивление спокойно (такое бывает?)
Когда все работает как часы, и ты начинаешь подозревать, что что-то не так.
Всем, кто справился — наше уважение. Отличных и спокойных выходных, коллеги!
#Пятница #SysadminLife #Опрос #IT
👍2💯2
Запускаем Ansible в один клик: Визуализация автоматизации с помощью AWX/Semaphore
Многие из нас используют Ansible, запуская плейбуки из командной строки. Это отлично работает для личных задач. Но как только мы начинаем работать в команде, возникают вопросы:
Как безопасно хранить ключи и пароли?
Как дать junior-админу кнопку для запуска рутинной задачи, не давая SSH-доступ к серверам?
Как видеть историю всех запусков и кто что изменил?
Ответ — веб-интерфейс для Ansible.
▪️ Что это такое?
AWX (open-source версия Ansible Tower) и его легковесный аналог Semaphore — это веб-панели, которые превращают ваши плейбуки в полноценный сервис автоматизации.
▪️ Что вы получаете:
Централизованное управление: Все ваши плейбуки, инвентари и проекты в одном месте.
Безопасное хранение credentials: SSH-ключи, токены облаков и пароли хранятся в зашифрованном виде.
RBAC (Role-Based Access Control): Вы можете создать учетные записи для коллег и дать им права только на запуск конкретных плейбуков (например, «Перезагрузить тестовый веб-сервер»).
Аудит и логирование: Каждый запуск плейбука логируется. Вы всегда знаете, кто, что и когда запускал.
Планировщик заданий (Scheduler): Встроенный аналог cron для запуска плейбуков по расписанию.
API: Управляйте автоматизацией из других систем, встраивая ее в CI/CD пайплайны.
🧠 Взгляд архитектора:
Переход на AWX/Semaphore — это не просто удобство. Это смена парадигмы. Вы перестаете быть «человеком, который запускает скрипты» и становитесь инженером, который строит платформу автоматизации для всей команды. Вы начинаете управлять не серверами, а процессами.
▪️ Как начать?
Самый простой способ — развернуть Semaphore или AWX через docker-compose. Подключите свой Git-репозиторий с плейбуками, настройте доступы, и ваша командная работа выйдет на новый уровень.
Это и есть один из ключевых шагов от админа к архитектору — создание масштабируемых и безопасных систем управления.
#Ansible #AWX #Semaphore #DevOps #Automation #IaC #Архитектура
Многие из нас используют Ansible, запуская плейбуки из командной строки. Это отлично работает для личных задач. Но как только мы начинаем работать в команде, возникают вопросы:
Как безопасно хранить ключи и пароли?
Как дать junior-админу кнопку для запуска рутинной задачи, не давая SSH-доступ к серверам?
Как видеть историю всех запусков и кто что изменил?
Ответ — веб-интерфейс для Ansible.
▪️ Что это такое?
AWX (open-source версия Ansible Tower) и его легковесный аналог Semaphore — это веб-панели, которые превращают ваши плейбуки в полноценный сервис автоматизации.
▪️ Что вы получаете:
Централизованное управление: Все ваши плейбуки, инвентари и проекты в одном месте.
Безопасное хранение credentials: SSH-ключи, токены облаков и пароли хранятся в зашифрованном виде.
RBAC (Role-Based Access Control): Вы можете создать учетные записи для коллег и дать им права только на запуск конкретных плейбуков (например, «Перезагрузить тестовый веб-сервер»).
Аудит и логирование: Каждый запуск плейбука логируется. Вы всегда знаете, кто, что и когда запускал.
Планировщик заданий (Scheduler): Встроенный аналог cron для запуска плейбуков по расписанию.
API: Управляйте автоматизацией из других систем, встраивая ее в CI/CD пайплайны.
🧠 Взгляд архитектора:
Переход на AWX/Semaphore — это не просто удобство. Это смена парадигмы. Вы перестаете быть «человеком, который запускает скрипты» и становитесь инженером, который строит платформу автоматизации для всей команды. Вы начинаете управлять не серверами, а процессами.
▪️ Как начать?
Самый простой способ — развернуть Semaphore или AWX через docker-compose. Подключите свой Git-репозиторий с плейбуками, настройте доступы, и ваша командная работа выйдет на новый уровень.
Это и есть один из ключевых шагов от админа к архитектору — создание масштабируемых и безопасных систем управления.
#Ansible #AWX #Semaphore #DevOps #Automation #IaC #Архитектура
Логи без боли: Как поднять централизованный сбор логов за 15 минут с Loki
Каждый админ знает эту рутину: ssh server1, grep /var/log/some.log, потом ssh server2, grep ... и так далее. Это медленно, неудобно, и почти невозможно сопоставить события с разных машин.
Многие слышали про стек ELK, но его сложность и ресурсоемкость отпугивают. Но есть современное решение — Grafana Loki.
▪️ Секретный соус Loki:
Главное отличие Loki от ELK: он не индексирует полное содержимое логов. Он индексирует только небольшой набор меток (labels), которые вы сами задаете (например: hostname="web01", app="nginx"). Сами строки логов сжимаются и хранятся как есть.
Аналогия: Представьте, что ELK — это поиск по содержанию всей книги, а Loki — это сверхбыстрый поиск по оглавлению и ярлыкам на полях.
▪️ Рецепт на 15 минут (с Docker Compose):
Этот docker-compose.yml поднимет весь необходимый стек: Loki для хранения, Promtail для сбора логов и Grafana для визуализации.
YAML
▪️ Что нужно сделать:
Сохраните текст выше в файл docker-compose.yml.
Рядом создайте файл promtail-config.yml (можно взять из нашего предыдущего поста про стек Observability).
Запустите: docker-compose up -d.
Откройте Grafana (http://localhost:3000), добавьте Loki как источник данных (http://loki:3100) и перейдите в раздел Explore.
Всё! Ваши логи с хост-машины уже там. Вы можете фильтровать их по меткам и искать нужные события со скоростью света. Это демократизация централизованного сбора логов, доступная каждому.
#Loki #Grafana #Observability #Logging #DevOps #Docker #SysAdmin
Каждый админ знает эту рутину: ssh server1, grep /var/log/some.log, потом ssh server2, grep ... и так далее. Это медленно, неудобно, и почти невозможно сопоставить события с разных машин.
Многие слышали про стек ELK, но его сложность и ресурсоемкость отпугивают. Но есть современное решение — Grafana Loki.
▪️ Секретный соус Loki:
Главное отличие Loki от ELK: он не индексирует полное содержимое логов. Он индексирует только небольшой набор меток (labels), которые вы сами задаете (например: hostname="web01", app="nginx"). Сами строки логов сжимаются и хранятся как есть.
Аналогия: Представьте, что ELK — это поиск по содержанию всей книги, а Loki — это сверхбыстрый поиск по оглавлению и ярлыкам на полях.
▪️ Рецепт на 15 минут (с Docker Compose):
Этот docker-compose.yml поднимет весь необходимый стек: Loki для хранения, Promtail для сбора логов и Grafana для визуализации.
YAML
version: "3"
networks:
loki:
services:
loki:
image: grafana/loki:latest
ports:
- "3100:3100"
command: -config.file=/etc/loki/local-config.yaml
networks:
- loki
promtail:
image: grafana/promtail:latest
volumes:
- /var/log:/var/log
- ./promtail-config.yml:/etc/promtail/config.yml
command: -config.file=/etc/promtail/config.yml
networks:
- loki
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
networks:
- loki
▪️ Что нужно сделать:
Сохраните текст выше в файл docker-compose.yml.
Рядом создайте файл promtail-config.yml (можно взять из нашего предыдущего поста про стек Observability).
Запустите: docker-compose up -d.
Откройте Grafana (http://localhost:3000), добавьте Loki как источник данных (http://loki:3100) и перейдите в раздел Explore.
Всё! Ваши логи с хост-машины уже там. Вы можете фильтровать их по меткам и искать нужные события со скоростью света. Это демократизация централизованного сбора логов, доступная каждому.
#Loki #Grafana #Observability #Logging #DevOps #Docker #SysAdmin