От Пингов к Инсайтам: Развертывание Стека 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

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

Запускаем 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 #Архитектура

Логи без боли: Как поднять централизованный сбор логов за 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

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

WireGuard: VPN нового поколения. Просто, быстро и безопасно.

Годами мы настраивали громоздкие и сложные IPsec и OpenVPN. Но мир не стоит на месте. WireGuard — это современный взгляд на VPN, который ставит во главу угла простоту, производительность и криптографическую надёжность.

▪️ Почему WireGuard — это будущее?

Минимализм: Весь код WireGuard — это всего несколько тысяч строк, в то время как OpenVPN или IPsec — это сотни тысяч. Его можно проаудировать за один день. Меньше кода — меньше потенциальных уязвимостей.

Производительность: WireGuard работает на уровне ядра Linux, что обеспечивает огромный прирост в скорости и минимальные задержки по сравнению с аналогами, работающими в user-space.

Современная криптография: Он использует новейшие и проверенные криптографические примитивы (ChaCha20, Poly1305, Curve25519), избавляясь от устаревших и небезопасных алгоритмов.

Простота конфигурации: Забудьте о сотнях параметров. Конфигурация WireGuard напоминает настройку SSH-ключей. Вы обмениваетесь публичными ключами, и всё работает.

▪️ Пример: Настройка простого туннеля "сервер-клиент"
Задача: Соединить ваш ноутбук (клиент) с домашним сервером (сервер).

Установка: sudo apt install wireguard или sudo dnf install wireguard-tools

Генерация ключей (на обеих машинах):

Bash

wg genkey | tee privatekey | wg pubkey > publickey

Конфигурация Сервера (/etc/wireguard/wg0.conf):

Ini, TOML

[Interface]
Address = 10.10.0.1/24
PrivateKey = <содержимое privatekey сервера>
ListenPort = 51820

[Peer]
PublicKey = <содержимое publickey клиента>
AllowedIPs = 10.10.0.2/32

Конфигурация Клиента (например, на ноутбуке):

Ini, TOML

[Interface]
Address = 10.10.0.2/24
PrivateKey = <содержимое privatekey клиента>

[Peer]
PublicKey = <содержимое publickey сервера>
Endpoint = <публичный_IP_сервера>:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25

Запуск (на обеих машинах): wg-quick up wg0

Теперь ваш клиент может обращаться к серверу по адресу 10.10.0.1 так, как будто они в одной локальной сети. Это элегантно, быстро и безопасно.

#WireGuard #VPN #Security #Linux #Networking #DevSecOps

Infrastructure as Code в мире Windows

宣言 PowerShell DSC: Управление Windows-серверами на уровне кода

Мы часто пишем PowerShell-скрипты, чтобы что-то сделать: установить роль, запустить службу, создать файл. Это императивный подход — мы описываем, как достичь цели.

PowerShell Desired State Configuration (DSC) предлагает декларативный подход. Мы описываем, каким должен быть сервер, а DSC сам решает, как привести его в это состояние. Это и есть Infrastructure as Code (IaC) для Windows.

▪️ Ключевая идея:
Вы создаете конфигурационный файл, в котором описываете конечное состояние системы. Например: "Веб-сервер IIS должен быть установлен, а служба 'w3svc' должна быть запущена". Если IIS не установлен, DSC его установит. Если служба остановлена, DSC ее запустит. Если всё уже в нужном состоянии, DSC ничего не сделает (идемпотентность).

▪️ Пример: Конфигурация простого веб-сервера
Этот скрипт описывает, что на сервере должен быть установлен IIS и запущен его сервис.

Создайте конфигурационный скрипт (WebServerConfig.ps1):

PowerShell

Configuration WebServerConfig
{
    # Узел, к которому применяется конфигурация (localhost)
    Node localhost
    {
        # Убеждаемся, что компонент Windows 'Web-Server' установлен
        WindowsFeature IIS
        {
            Ensure = "Present"
            Name   = "Web-Server"
        }

        # Убеждаемся, что служба IIS запущена
        Service WebService
        {
            Ensure    = "Present"
            Name      = "w3svc"
            State     = "Running"
            DependsOn = "[WindowsFeature]IIS" # Запускать только после установки IIS
        }
    }
}

# Вызываем конфигурацию для создания MOF-файла
WebServerConfig

Запустите скрипт в PowerShell ISE или консоли. Он не применит конфигурацию сразу, а создаст в новой папке WebServerConfig файл localhost.mof. Этот MOF-файл и есть скомпилированное «желаемое состояние».

Примените конфигурацию:

PowerShell

Start-DscConfiguration -Path .\WebServerConfig -Wait -Verbose

DSC проанализирует текущее состояние системы, сравнит его с localhost.mof и выполнит необходимые действия. Повторный запуск этой команды не приведет ни к каким изменениям, если состояние сервера не менялось.

🧠 Взгляд архитектора:
DSC — это переход от одноразовых скриптов к созданию живой, самоподдерживающейся документации вашей инфраструктуры в виде кода. Это позволяет гарантировать консистентность конфигураций десятков и сотен серверов, автоматически исправлять "дрейф" настроек и встраивать управление инфраструктурой в CI/CD пайплайны.

#PowerShellDSC #IaC #WindowsServer #Automation #DevOps #PowerShell

«Дрейф конфигурации»: Тихий убийца вашей инфраструктуры

Вечер понедельника — идеальное время, чтобы поговорить о невидимом враге, с которым сталкивается каждый админ, — дрейфе конфигурации (configuration drift).

Что это такое?
Это постепенное и незаметное расхождение реального состояния сервера от его эталонной, задокументированной конфигурации.

Как это происходит?

«Срочный фикс»: Вы вручную правите конфиг на prod-server-01 в 2 часа ночи, чтобы поднять упавший сервис. Вы обещаете себе задокументировать это утром, но... утром появляются новые задачи.

Ручные обновления: Один сервер обновили через apt upgrade, а про второй забыли.

Неконсистентные деплои: Разработчики попросили «быстренько поставить вот эту библиотеку» на одном из веб-серверов.

Через полгода ваши серверы, которые должны быть идентичными близнецами, превращаются в уникальные, капризные «снежинки».

Почему это так опасно?

Непредсказуемые сбои: Новый релиз приложения идеально встает на server-01, но падает на server-02, потому что там другая версия glibc. Вы тратите часы на поиск проблемы.

Дыры в безопасности: На одном сервере вы закрыли уязвимый порт, а на другом — нет.

Невозможность масштабирования: Вы не можете быть уверены, что новый, автоматически развернутый сервер будет вести себя так же, как старые.

«Эффект домино»: Сбой на одной «снежинке» может вызвать каскадный отказ всей системы.

Лекарство: Infrastructure as Code (IaC)
Единственный надежный способ борьбы с дрейфом — это декларативный подход. Инструменты вроде Ansible, PowerShell DSC или Terraform позволяют описать желаемое состояние в коде.

Вы не «чините» сервер. Вы запускаете плейбук, который гарантированно приводит ВСЕ серверы к единому, эталонному состоянию. Любое ручное изменение будет автоматически исправлено при следующем запуске. Ваша инфраструктура становится предсказуемой, безопасной и документированной самим кодом.

Перестаньте бороться с симптомами. Начните лечить причину.

#IaC #Ansible #DevOps #Архитектура #ConfigurationManagement

Сетевой швейцарский нож: 3 нетривиальных применения netcat

Каждый админ знает ping и traceroute. Но в арсенале настоящего профессионала есть инструмент куда мощнее — netcat (или nc). Это универсальный солдат для любых сетевых задач.

Вот 3 сценария, где nc сэкономит вам кучу времени.

1. Быстрая проверка открытого порта
Забудьте про telnet. nc делает это лучше и быстрее.

Bash

# Проверяем, доступен ли веб-сервер на 80 порту
# -z: сканировать, не отправляя данные
# -v: подробный вывод
nc -zv web-server.com 80
# Connection to web-server.com 80 port [tcp/http] succeeded!

# Проверяем, слушает ли база данных на порту 5432
nc -zv db-server.com 5432
# nc: connect to db-server.com port 5432 (tcp) failed: Connection refused

Это самый быстрый способ понять, блокирует ли файрвол соединение или сервис просто не запущен.

2. «Беспарольный» трансфер файлов
Нужно срочно скопировать большой лог-файл с сервера, а scp не настроен или заблокирован? nc спешит на помощь.

На принимающей машине (куда копируем):

Bash

nc -l -p 12345 > received_log.log

-l -p 12345: Слушать на порту 12345.

На отправляющей машине (откуда копируем):

Bash

nc receiving_machine_ip 12345 < source_log.log

nc передаст содержимое файла по указанному адресу и порту. Внимание: Этот метод не шифрует трафик, используйте его только в доверенных сетях.

3. Ручной «диалог» с сервисом (Banner Grabbing)
Иногда нужно понять, что отвечает сервис до того, как с ним начнет работать приложение. Например, проверить, какой SMTP-сервер отвечает на порту.

Bash

# Подключаемся к почтовому серверу Google
nc -v smtp.gmail.com 587

В ответ вы можете получить что-то вроде:
220 smtp.gmail.com ESMTP ...
Так можно вручную отправлять HTTP-запросы, общаться с Redis или любым другим текстовым протоколом для отладки.

netcat — это пример того, как простой, но мощный инструмент в умелых руках решает сложные задачи.

#Linux #Networking #Netcat #SysAdmin #Команды #Security

Windows: Поиск и архивация старых файлов с помощью PowerShell

«На диске C заканчивается место» — вечная головная боль админа, особенно на файловых серверах. Искать большие и старые файлы вручную через Проводник — неэффективно. PowerShell позволяет автоматизировать этот процесс, сделав его быстрым и безопасным.

Этот скрипт находит файлы больше определенного размера и старше заданного количества дней, а затем предлагает архивировать их с сохранением структуры папок.

▪️ Скрипт (Archive-OldFiles.ps1):

PowerShell

[CmdletBinding(SupportsShouldProcess=$true, ConfirmImpact='High')]
param(
    [Parameter(Mandatory=$true)]
    [string]$SourcePath,

    [Parameter(Mandatory=$true)]
    [string]$ArchivePath,

    [int]$DaysOld = 365,

    [long]$MinSizeGB = 1
)

# Проверяем, существуют ли пути
if (-not (Test-Path $SourcePath)) {
    Write-Error "Исходный путь не найден: $SourcePath"
    return
}
if (-not (Test-Path $ArchivePath)) {
    Write-Warning "Путь для архива не найден. Создаем: $ArchivePath"
    New-Item -Path $ArchivePath -ItemType Directory | Out-Null
}

$thresholdDate = (Get-Date).AddDays(-$DaysOld)
$minSizeBytes = $MinSizeGB * 1GB

Write-Host "Ищем файлы в '$SourcePath' старше $($thresholdDate.ToString('yyyy-MM-dd')) и больше $MinSizeGB GB..."

$filesToArchive = Get-ChildItem -Path $SourcePath -Recurse -File | Where-Object {
    $_.LastWriteTime -lt $thresholdDate -and $_.Length -gt $minSizeBytes
}

if ($null -eq $filesToArchive) {
    Write-Host "Файлы для архивации не найдены."
    return
}

Write-Host "Найдено $($filesToArchive.Count) файлов для архивации."

foreach ($file in $filesToArchive) {
    # Сохраняем относительную структуру папок
    $relativePath = $file.FullName.Substring($SourcePath.Length)
    $destinationPath = Join-Path -Path $ArchivePath -ChildPath $relativePath
    $destinationDir = Split-Path -Path $destinationPath -Parent

    # Создаем директорию в архиве, если ее нет
    if (-not (Test-Path $destinationDir)) {
        New-Item -Path $destinationDir -ItemType Directory | Out-Null
    }

    Write-Host "Перемещение: $($file.FullName) -> $destinationPath"
    
    # Ключевая команда с поддержкой -WhatIf
    if ($pscmdlet.ShouldProcess($file.FullName, "Move to $destinationPath")) {
        Move-Item -Path $file.FullName -Destination $destinationPath
    }
}

Write-Host "Архивация завершена."

▪️ Как использовать:

Тестовый запуск (безопасный режим):
Сначала запустите скрипт с параметром -WhatIf. Он покажет, что он собирается сделать, но ничего не переместит.

PowerShell

.\Archive-OldFiles.ps1 -SourcePath "D:\Shares" -ArchivePath "E:\Archive" -DaysOld 365 -MinSizeGB 1 -WhatIf

Рабочий запуск:
Если вас устраивает результат тестового запуска, уберите -WhatIf для реального перемещения файлов.

PowerShell

.\Archive-OldFiles.ps1 -SourcePath "D:\Shares" -ArchivePath "E:\Archive"

Это не просто скрипт, а безопасный инструмент, который сначала позволяет проверить свои действия.

#PowerShell #WindowsServer #Automation #Скрипты #SysAdmin

Vault: Перестаньте хранить пароли в Ansible-плейбуках

Мы уже говорили про IaC и автоматизацию с помощью Ansible. Но где вы храните пароли от баз данных, API-токены и SSH-ключи, которые используют ваши плейбуки? Если ответ «в ansible-vault» или, что хуже, в зашифрованных файлах в Git, — есть способ лучше.

Знакомьтесь с HashiCorp Vault — это «швейцарский сейф» для всей вашей инфраструктуры.

▪️ Проблема, которую решает Vault:
Секреты (пароли, токены, ключи) разбросаны повсюду: в конфиг-файлах, переменных окружения, скриптах. Ими сложно управлять, ротировать (менять) и аудировать, кто и когда к ним получал доступ.

▪️ Как Vault меняет игру?
Vault — это централизованный сервис, который:

Надежно хранит секреты: Все данные шифруются как при передаче, так и при хранении.

Выдает секреты «на лету»: Vault может генерировать временные, короткоживущие учетные данные для баз данных (PostgreSQL, MySQL) или облаков (AWS). Ваше приложение получает доступ к базе не с постоянным паролем, а с временным, который действует, например, 5 минут. Даже если его украдут, он быстро станет бесполезным.

Предоставляет API: Приложения и скрипты (включая Ansible) аутентифицируются в Vault и запрашивают нужные им секреты через API. Паролей в плейбуках больше нет.

Ведет подробный аудит: Каждый запрос к любому секрету записывается в журнал. Вы всегда знаете, кто, что и когда запрашивал.

🧠 Взгляд архитектора:
Внедрение Vault — это переход от статичного управления секретами (пароль, который лежит в файле годами) к динамическому. Вы больше не защищаете сами пароли, вы защищаете доступ к Vault. Это фундаментальный сдвиг в сторону модели Zero Trust, где ни один компонент системы не доверяет другому по умолчанию.

Изучение Vault — это следующий логический шаг после освоения Ansible или Terraform, который выводит ваши навыки безопасности и автоматизации на новый уровень.

#Vault #Security #DevSecOps #IaC #Ansible #Архитектура

Podman: Запускаем контейнеры без Docker. Быстро, безопасно и без демонов.

Многие привыкли, что контейнеры = Docker. Но в мире Linux набирает популярность Podman — инструмент, который делает то же самое, но с несколькими ключевыми улучшениями, особенно важными для безопасности и системной интеграции.

▪️ Главные отличия от Docker:

Нет демона: Podman работает без постоянного фонового процесса (dockerd), который требует прав root. Каждый контейнер запускается как дочерний процесс пользователя. Это снижает поверхность атаки.

Rootless-режим: Вы можете запускать контейнеры от имени обычного пользователя, без sudo. Изоляция на уровне ядра не позволит такому контейнеру получить права администратора на хосте.

Интеграция с systemd: Podman умеет генерировать systemd-юниты для ваших контейнеров, позволяя управлять ими как обычными системными службами.

▪️ Quick Start: Попробуем прямо сейчас
Команды практически на 100% совпадают с Docker, поэтому переучиваться не придется.

Установка:

sudo apt install podman или sudo dnf install podman

Запуск первого контейнера (Nginx):

Bash

# Обратите внимание, никакого 'sudo'
podman run -d --name my_nginx -p 8080:80 docker.io/library/nginx

-d: запуск в фоновом режиме.
--name: имя контейнера.
-p: проброс порта.

Просмотр запущенных контейнеров:

Bash

podman ps
# CONTAINER ID  IMAGE                           COMMAND               CREATED         STATUS             PORTS                 NAMES
# a1b2c3d4e5f6  docker.io/library/nginx:latest  nginx -g 'daemon o...   2 minutes ago   Up 2 minutes ago   0.0.0.0:8080->80/tcp  my_nginx

Управление контейнером как systemd-сервисом:
Это киллер-фича. Создадим systemd-юнит для нашего Nginx.

Bash

# Генерируем .service файл
podman generate systemd --name my_nginx > ~/.config/systemd/user/nginx.service

# Перезагружаем демона systemd для user-сессии
systemctl --user daemon-reload

# Запускаем и включаем автозагрузку сервиса
systemctl --user start nginx.service
systemctl --user enable nginx.service

Теперь ваш контейнер будет стартовать вместе с вашей пользовательской сессией и управляться как обычная служба!

Вывод: Podman — это отличная, более безопасная и системно-интегрированная альтернатива Docker для запуска одиночных контейнеров на Linux-серверах.

#Podman #Containers #Linux #DevOps #Security #Systemd

Идемпотентность: Почему ваш скрипт не должен бояться повторного запуска

Что отличает скрипт новичка от скрипта профессионала? Профессионал стремится к идемпотентности.

Идемпотентность — это свойство операции, при котором её повторное применение к объекту даёт тот же результат, что и первое. Проще говоря, ваш скрипт можно запускать 100 раз подряд, и он не сломает систему. После первого запуска все последующие просто сообщат, что «всё уже в нужном состоянии».

▪️ Зачем это нужно?
Представьте скрипт, который добавляет строку в /etc/hosts. Если запустить его 5 раз, он добавит 5 одинаковых строк. Это не идемпотентно. Идемпотентный скрипт сначала проверит, есть ли такая строка, и добавит её, только если её нет.

Это критически важно для:

Надёжности автоматизации (Ansible, DSC): Все эти системы построены на принципе идемпотентности.

Безопасности: Вы можете быть уверены, что повторный запуск скрипта исправит конфигурацию, а не усугубит проблему.

Предотвращения ошибок: Снижает риск случайного дублирования данных или настроек.

▪️ Как достичь идемпотентности?

Пример в Bash (добавить строку в файл):
❌ Не идемпотентно:

echo "10.0.0.5 web-server" >> /etc/hosts

✅ Идемпотентно (с проверкой):

Bash

HOSTS_LINE="10.0.0.5 web-server"
if ! grep -qF -- "${HOSTS_LINE}" /etc/hosts; then
  echo "${HOSTS_LINE}" >> /etc/hosts
  echo "Строка добавлена."
else
  echo "Строка уже существует."
fi

Пример в PowerShell (создать папку):
PowerShell часто помогает "из коробки".

❌ Не идемпотентно (выдаст ошибку при втором запуске):

New-Item -Path C:\Temp\MyApp -ItemType Directory

✅ Идемпотентно (с проверкой):

PowerShell

$path = "C:\Temp\MyApp"
if (-not (Test-Path $path)) {
  New-Item -Path $path -ItemType Directory
}

Или ещё проще, используя -Force, который подавляет ошибку, если папка существует:
New-Item -Path C:\Temp\MyApp -ItemType Directory -Force

🧠 Взгляд архитектора:
Когда вы пишете скрипт, всегда задавайте себе вопрос: «Что случится, если я запущу его снова через час? А через год?». Мышление в терминах состояний, а не действий — это основа надёжной и масштабируемой автоматизации.

#Automation #Bash #PowerShell #DevOps #BestPractices #Архитектура

SSH на максималках: Ускоряем повторные подключения с помощью ControlMaster

Каждый Linux-админ использует ssh десятки раз в день. Мы привыкли к небольшой задержке при каждом подключении: рукопожатие, обмен ключами, аутентификация. Но что, если я скажу, что ждать нужно только один раз?

Знакомьтесь с SSH Multiplexing (мультиплексированием) — встроенной функцией OpenSSH, которая делает повторные подключения к одному и тому же хосту практически мгновенными.

▪️ Как это работает?
При первом подключении ssh создает управляющий сокет — постоянное «мастер-соединение». Все последующие сессии (ssh, scp, sftp) к этому же хосту просто переиспользуют этот уже установленный и аутентифицированный канал, пропуская всю рутину.

▪️ Как включить?
Добавьте эти строки в ваш файл ~/.ssh/config:

Ini, TOML

Host *
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 10m

ControlMaster auto: Автоматически создавать и использовать мастер-соединение.

ControlPath ...: Шаблон для именования файлов сокетов (создаст уникальный сокет для каждой сессии).

ControlPersist 10m: Оставлять мастер-соединение активным в фоне 10 минут после закрытия последней сессии.

▪️ Проверьте сами:

Откройте терминал и подключитесь к серверу: ssh user@your-server. Вы заметите обычную задержку.

Не закрывая первое соединение, откройте второй терминал и выполните ту же команду.

Вы подключитесь мгновенно.

🧠 Взгляд архитектора:
Это не просто личный лайфхак. Для систем автоматизации вроде Ansible эта функция — настоящее золото. Она может кардинально ускорить выполнение плейбуков на множестве хостов, так как Ansible не тратит время на установку нового SSH-соединения для каждой задачи. Это напрямую влияет на скорость и эффективность деплоя.

#SSH #Linux #DevOps #Performance #LifeHack #SysAdmin

Как безопасно хранить секреты в Git? Знакомьтесь с git-crypt

Главное правило Infrastructure as Code (IaC) — всё должно быть в Git. Но что делать с секретами: паролями, токенами, приватными ключами? Добавлять их в .gitignore — безопасно, но неудобно для команды. Хранить в открытом виде — катастрофа.

git-crypt предлагает элегантное решение этой проблемы, интегрируя шифрование прямо в ваш Git-workflow.

▪️ Философия git-crypt:
Это прозрачный файловый фильтр. Вы один раз указываете, какие файлы или папки должны быть зашифрованы.

Когда вы делаете git push, эти файлы автоматически шифруются перед отправкой на удаленный репозиторий.

Когда ваш коллега (у которого есть доступ) делает git pull, эти файлы автоматически расшифровываются на его машине.

В удаленном репозитории (на GitHub/GitLab) секреты всегда хранятся в виде зашифрованной абракадабры. В вашей рабочей копии вы видите их как обычные текстовые файлы.

▪️ Быстрый старт:

Установка: sudo apt install git-crypt или brew install git-crypt.

Инициализация в репозитории: git-crypt init.

Указание файлов для шифрования: Создайте файл .gitattributes и добавьте в него строку:
secret.yaml filter=git-crypt diff=git-crypt

Добавление доверенных пользователей: Чтобы ваши коллеги могли расшифровывать файлы, добавьте их GPG-ключи:
git-crypt add-gpg-user "email@colleague.com"

Работайте как обычно: git add ., git commit, git push. git-crypt сделает всю магию в фоне.

🧠 Взгляд DevSecOps:
git-crypt — это яркий пример практики «сдвига влево» (Shift Left Security). Вы не думаете о безопасности в последнюю очередь, а встраиваете ее в самый базовый инструмент разработки и администрирования — Git. Это делает безопасный способ работы одновременно и самым простым, устраняя человеческий фактор.

#Git #Security #DevSecOps #SecretsManagement #Automation #IaC

Чистим Linux-сервер перед выходными: Чек-лист по освобождению места на диске

Пятница — идеальный день, чтобы навести порядок на серверах. Никому не хочется получать алерты о забитом диске в субботу утром. Пробегитесь по этому чек-листу, чтобы освободить место и спокойно встретить выходные.

▪️ 1. Удаляем ненужные пакеты и кэш apt/dnf
Начните с чистки пакетного менеджера.

Bash

# Для Debian/Ubuntu: удаляем устаревшие пакеты
sudo apt autoremove -y

# Очищаем кэш пакетов
sudo apt clean

# Для RHEL/CentOS/Fedora:
sudo dnf autoremove -y
sudo dnf clean all

▪️ 2. Удаляем старые версии ядер Linux
Со временем может накопиться несколько старых ядер, занимающих сотни мегабайт.

Bash

# Для Debian/Ubuntu:
# Показать установленные ядра, кроме текущего
dpkg -l | grep linux-image | awk '{print $2}' | grep -v "$(uname -r)"

# Удалить ненужное ядро (замените <package_name> на имя из вывода выше)
sudo apt remove <package_name>

# Для RHEL/CentOS/Fedora:
# Показать установленные ядра
sudo dnf list installed kernel

# Удалить старые ядра (обычно сохраняется 2-3 последних)
# dnf remove -y $(dnf repoquery --installonly --latest-limit=-2 -q)
# или вручную: sudo dnf remove kernel-<version>

▪️ 3. Чистим логи
Логи могут быстро разрастаться, особенно если есть проблемы.

Bash

# Очищаем journald (оставляем только последние 7 дней или 500Мб)
sudo journalctl --vacuum-time=7d
# или
sudo journalctl --vacuum-size=500M

# Проверяем размер логов в /var/log/ (ищем самые большие файлы)
sudo du -sh /var/log/* | sort -rh | head -n 10

При необходимости вручную удалите или архивируйте старые, большие файлы, которые не ротируются.

▪️ 4. Временные файлы (/tmp, /var/tmp)
Эти директории обычно очищаются автоматически при перезагрузке, но если сервер не перезагружался давно, там может скопиться мусор.

Bash

sudo rm -rf /tmp/* /var/tmp/*

Используйте с осторожностью, убедившись, что в /tmp нет активных файлов.

▪️ 5. Проверяем Docker (если используете)
Docker может оставлять много «мусора»: неиспользуемые образы, контейнеры, тома.

Bash

# Удалить неиспользуемые объекты (контейнеры, сети, образы, кэш)
docker system prune -a

📌 Резюме: Эти простые шаги помогут вам держать дисковое пространство под контролем. Теперь можно спокойно идти на выходные!

#Linux #SysAdmin #DiskSpace #Maintenance #Чеклисты

Linux: Cgroups — Как контейнеры держат свои обещания (и как вы можете)

Вы когда-нибудь задумывались, как Docker или Kubernetes могут гарантировать, что один контейнер не "съест" все ресурсы сервера, оставив остальные голодать? Ответ — cgroups (Control Groups).

Что такое cgroups?
Это механизм ядра Linux, который позволяет организовывать процессы в иерархические группы и управлять их доступом к системным ресурсам:

CPU: Сколько процессорного времени может использовать группа.

Memory: Максимальный объем оперативной памяти.

Disk I/O: Приоритет и скорость чтения/записи на диск.

Network: Ограничения на сетевой трафик.

▪️ Почему это важно для админа?

Контейнеры (Docker, Podman, LXC): Они используют cgroups как основу для изоляции ресурсов. Когда вы задаете -m 512M для Docker-контейнера, это cgroups устанавливает лимит памяти.

Защита от "шумных соседей": Если у вас несколько сервисов на одном VDS/сервере, вы можете создать cgroup для каждого и гарантировать, что один прожорливый процесс не подвесит всю систему.

Обеспечение SLA: Для критически важных сервисов можно выделить гарантированный минимум ресурсов.

Тюнинг производительности: Можно приоритезировать ресурсы для одних процессов и ограничить для других.

▪️ Простой пример: Ограничиваем CPU для "прожорливого" процесса
Представьте, что у вас есть скрипт heavy_calc.sh, который грузит одно ядро на 100%.

Создаем cgroup (например, cpulimit):

Bash

sudo mkdir /sys/fs/cgroup/cpu/cpulimit

Путь может немного отличаться в зависимости от версии Linux и наличия systemd.

Устанавливаем лимит CPU (например, 50% одного ядра):

Bash

# Для systemd cgroups v2:
# cd /sys/fs/cgroup/user.slice/user-1000.slice/
# sudo echo "cpu.max 50000 100000" > cpu.max
# Или более универсально для cgroups v1:
sudo bash -c "echo 50000 > /sys/fs/cgroup/cpu/cpulimit/cpu.cfs_quota_us"
sudo bash -c "echo 100000 > /sys/fs/cgroup/cpu/cpulimit/cpu.cfs_period_us"

cpu.cfs_period_us - общий период (100мс = 100000мкс)
cpu.cfs_quota_us - сколько микросекунд можно использовать за период. 50% = 50000мкс

Добавляем процесс в cgroup:
Сначала запустите ваш "прожорливый" процесс в фоновом режиме, получите его PID.

Bash

./heavy_calc.sh &
PID=$! # Запоминаем PID
sudo bash -c "echo $PID > /sys/fs/cgroup/cpu/cpulimit/tasks"

Теперь этот процесс не сможет использовать более 50% одного ядра, даже если сервер свободен.

🧠 Взгляд архитектора:
Понимание cgroups — это фундамент для работы с контейнерными технологиями и тонкой настройки производительности Linux-систем. Это тот уровень контроля, который позволяет строить по-настоящему стабильную и предсказуемую инфраструктуру, где ресурсы распределяются не случайным образом, а согласно вашим четким правилам.

#Linux #Cgroups #Containers #Performance #Systemd #DevOps

Невидимые символы: Чем нулевой байт опасен для системы (и почему с ним борются)

В мире текстовых файлов и строк мы привыкли видеть буквы, цифры и пробелы. Но есть один символ, который невидим, не печатается, но может вызывать огромные проблемы в программах и системах: нулевой байт (NULL character, \0).

▪️ В чем его магия (и опасность)?
В языках программирования C и C++ (на которых написано ядро Linux, множество утилит и системных библиотек) строки традиционно заканчиваются первым встреченным нулевым байтом. Это фундаментальное правило.

▪️ Что происходит, если кто-то подсунет его не туда?
Если программа ожидает строку, а в середине получает \0, она просто обрежет строку в этом месте. Это может привести к:

Обходу безопасности:

Представьте, что вы проверяете путь к файлу: /var/www/site/index.php.

Злоумышленник посылает: /var/www/site/index.php%00.jpg (где %00 — это нулевой байт).

Программа видит только /var/www/site/index.php (из-за нулевого байта), думает, что это безопасно, и выполняет файл как PHP-скрипт, хотя по расширению он выглядит как изображение.

Неожиданному поведению:

Система генерирует имя пользователя admin%00user.

В одной части системы оно распознается как admin, в другой — как admin%00user. Это может открыть лазейки для повышения привилегий.

Ошибкам и сбоям:

Некоторые функции могут просто «зависнуть», если получат неожиданный \0, поскольку ожидают конец строки в другом месте.

▪️ Где его ищут?
Современные языки программирования (Python, Go, Rust, Java) активно борются с проблемами нулевого байта, часто явно запрещая его в середине строк или обрабатывая иначе. Но системные утилиты и низкоуровневые API все еще могут быть уязвимы.

🧠 Для админа: Знание о нулевом байте помогает понимать, почему некоторые фильтры ввода так важны, и почему «непечатаемые символы» в именах файлов или полях форм могут быть не просто ошибкой, а попыткой атаки.

#Security #Linux #Programming #Exploit #SysAdmin #FunFact

IPv6: Когда выключат IPv4, и почему это уже не страшно

Кажется, IPv6 — это та «технология будущего», которая всегда будет «будущим». Каждый админ знает, что IPv4-адреса давно закончились. Но мы все еще на них сидим. Почему? И когда уже переходить?

▪️ Почему так долго?
Причин несколько:

NAT: Network Address Translation спас IPv4, позволив десяткам (или сотням) устройств скрываться за одним публичным IP.

Инерция: Переход на новую версию протокола — это изменение фундаментальных принципов сети. Это дорого, сложно и требует перенастройки всего.

Незнание: Многие боятся IPv6 из-за кажущейся сложности его адресов и настроек.

▪️ Почему это уже не страшно (а даже круто!)
На самом деле, IPv6 уже активно работает на большинстве наших устройств.

Ваш телефон/компьютер: Если ваш провайдер поддерживает IPv6 (а большинство современных провайдеров уже поддерживают), ваши устройства уже получают IPv6-адреса и используют их для доступа к сайтам, которые тоже доступны по IPv6 (например, Google, Facebook, Netflix).

Облака: Все крупные облачные провайдеры полностью поддерживают IPv6. Создавать ресурсы только с IPv6-адресами — это уже реальность.

Простота (для админа):

Нет NAT: Каждое устройство в вашей сети получает свой уникальный публичный IPv6-адрес. Ура, больше никаких проблем с пробросом портов!

Автоконфигурация (SLAAC): Большинство устройств просто сами получают IPv6-адрес от роутера, без DHCP.

Огромное адресное пространство: Выдавайте по 65 тысяч адресов каждому сотруднику, и адреса не кончатся. Никогда.

▪️ Когда выключат IPv4?
Скорее всего, никогда. Или очень, очень нескоро. IPv4 будет существовать как «наследие» еще десятилетия. Но всё больше трафика будет уходить в IPv6.

🧠 Для админа: Изучать IPv6 сейчас — это не заглядывать в далекое будущее, это готовиться к неизбежному настоящему. Это упрощает многие сетевые задачи, повышает безопасность (нет скрытых NAT-правил) и открывает дорогу для новых сервисов. Начните с включения IPv6 на вашем роутере и домашнем сервере.

#IPv6 #Networking #FutureTech #SysAdmin #Internet #TechTrends

Windows: Запуск скриптов с правами администратора

Каждый Windows-админ сталкивался с ситуацией: нужен скрипт, который должен работать с правами администратора. Настроить службы, поправить реестр или перезапустить системный процесс без UAC-подтверждения? Можно автоматизировать.

▪️ Проблема
По умолчанию Python-скрипты запускаются от имени обычного пользователя. Это ограничивает работу с системными настройками и требует «ручного» запуска через правый клик.

▪️ Решение — библиотека pyuac
Пример кода:

from pyuac import isUserAdmin, runAsAdmin

def main():
    print("Я запущен как админ!")

if __name__ == "__main__":
    if not isUserAdmin():
        runAsAdmin()
    else:
        main()

▪️ Как это помогает
Скрипт сам проверяет уровень прав. Если они недостаточные — перезапускает себя с UAC-запросом. Минимум действий от пользователя, максимум автоматизации.

🧠 Для админа: такой приём пригодится для сервисных скриптов и утилит, которые должны работать «бесшовно».

#Windows #Python #SysAdmin #Automation

Linux: История команд как инструмент скорости

Каждый Linux-админ знает: половина времени в консоли уходит на повторение команд. Но shell уже умеет экономить ваши минуты.

▪️ Базовые приёмы

!! — выполнить предыдущую команду.

!n — выполнить команду из истории по номеру.

history | grep <ключ> — поиск по истории.

▪️ Горячие клавиши

Ctrl+R — поиск по истории в реальном времени.

Ctrl+P и Ctrl+N — навигация по истории (вперёд/назад).

▪️ Зачем это нужно
Вместо того чтобы печатать длинные docker run ... или systemctl restart ..., достаточно пары клавиш.

🧠 Для админа: чем меньше вы печатаете руками, тем меньше вероятность ошибки. А скорость работы в консоли напрямую повышает вашу продуктивность.

#Linux #Bash #Zsh #SysAdmin #Productivity