📰 Предпоследняя неделя мая

Недельку поработать и уже лето. А мы пока собрали новостей.

— RHEL 10.2 и 9.8

Red Hat выпустила обновы для своего дистрибутива. В терминале появился AI-ассистент goose с поддержкой стриминга и MCP. Обновились тулсеты: Go 1.26, Python 3.14, Ruby 4.0, OpenJDK 25, PostgreSQL 18, MariaDB 11.8.

— Шумахер посчитал строки кода в KDE

— В Linux добавили правила для AI-репортов

— OpenBSD 7.9

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#дайджест_недели

👩‍💻 Bash-скрипт для мониторинга сервисов

Полноценный мониторинг вроде Zabbix или Prometheus не всегда оправдан, особенно на небольших проектах или dev-серверах. Иногда достаточно простого скрипта, который проверит список сервисов и скажет, что именно не работает.

Ниже готовый скрипт с проверкой через systemctl и отправкой уведомлений в Telegram.

Базовая версия

Создаём файл:

nano check_services.sh

Содержимое:

#!/bin/bash
SERVICES=("nginx" "postgresql" "redis" "ssh")

echo "===== СТАТУС СЕРВИСОВ ====="
echo ""

for SERVICE in "${SERVICES[@]}"; do
    STATUS=$(systemctl is-active "$SERVICE" 2>/dev/null)
    if [ "$STATUS" = "active" ]; then
        echo "[OK]     $SERVICE"
    else
        echo "[УПАЛ]   $SERVICE"
    fi
done

Даём права и запускаем:

chmod +x check_services.sh
./check_services.sh

Массив SERVICES правите под свой стек. Вывод будет примерно таким:

===== СТАТУС СЕРВИСОВ =====

[OK]     nginx
[OK]     postgresql
[УПАЛ]   redis
[OK]     ssh

Версия с уведомлением в Telegram

Базовая версия показывает результат в консоли. Но если скрипт работает по cron, вы его вывод не увидите. Добавим отправку сообщения в Telegram при обнаружении упавшего сервиса.

Для этого понадобится бот и chat_id. Бота создаёте через @BotFather, chat_id получаете через @userinfobot или из API бота после отправки ему любого сообщения.

#!/bin/bash
SERVICES=("nginx" "postgresql" "redis" "ssh")

BOT_TOKEN="123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
CHAT_ID="987654321"

FAILED=""

for SERVICE in "${SERVICES[@]}"; do
    STATUS=$(systemctl is-active "$SERVICE" 2>/dev/null)
    if [ "$STATUS" != "active" ]; then
        FAILED="${FAILED} ${SERVICE}\n"
    fi
done

if [ -n "$FAILED" ]; then
    HOSTNAME=$(hostname)
    MESSAGE=" Проблема на ${HOSTNAME}\n\nУпавшие сервисы:\n${FAILED}"
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
        -d chat_id="$CHAT_ID" \
        -d text="$(echo -e "$MESSAGE")" \
        -d parse_mode="HTML" > /dev/null
fi

Скрипт отправляет сообщение только когда что-то упало. Если все сервисы работают, он молчит и не спамит в чат.

Добавляем в cron

Открываем crontab:

crontab -e

Добавляем строку для проверки каждые 5 минут:

*/5 * * * * /path/to/check_services.sh

Что можно доработать

Скрипт намеренно простой, но его легко расширить. Например, добавить автоматический перезапуск упавшего сервиса через systemctl restart "$SERVICE" прямо в блоке проверки. Или писать результаты в лог-файл для истории. Если серверов несколько, можно запускать скрипт удалённо через ssh в цикле по списку хостов.

Для продакшена с десятками сервисов и серверов лучше смотреть в сторону полноценных решений. Но для пары серверов этот скрипт закрывает задачу за пять минут настройки.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

⚙️ AI-агенты как Terraform-ресурсы

В DevOps-сообществе набирает обороты идея: описывать AI-агентов в Terraform так же, как мы описываем инфраструктуру. Не просто поднимать под них compute и сеть, а определять самого агента как ресурс со всей его конфигурацией.

Зачем это вообще нужно

Агент сегодня это не «модель + промпт». Это набор компонентов: системный промпт, sandbox, MCP-серверы, навыки, хуки, секреты, параметры модели, сетевые доступы.

Ещё недавно у многих был один конфиг Claude Code в одном репозитории. Сейчас — research-агент, writing-агент, coding-агент, агент для ежедневных саммари. И это персональное использование. На уровне команды агентов десятки.

Вопрос логичный: как всё это конфигурировать, версионировать, воспроизводить между окружениями?

Аргументы против

Terraform хорош для стабильной инфраструктуры, а не для runtime-сущностей, которые меняют поведение. Разрешения, секреты, очереди, guardrails — это в Terraform. Сам агент, его конфиг и версионирование — ближе к слою приложения.

Ещё проще: агенты — это софт. Управляйте ими как софтом. Возможно, часть инфраструктуры под агента действительно описывается через Terraform, но сам агент — нет. Это обычный веб-сервис, который принимает запрос, обогащает его и отправляет LLM-провайдеру.

Есть и аргумент про саму природу Terraform. Его ценность — в drift management и reconciliation. Если стейт агента не может реально «дрифтовать» в том смысле, в котором дрифтует облачная инфраструктура, то Terraform здесь не нужен. Хватит обычного CI/CD и application image. Сетевой слой — да, через Terraform. Но весь «стек» агента — вряд ли.

Аргументы за

С точки зрения MLOps всё выглядит иначе. Вся инфра для AI-проектов описывается в TF сверху донизу, и это ничем не отличается от любого другого облачного проекта. Магии в MLOps нет — это DevOps в другой шляпе. AWS уже позволяет описывать Bedrock-агентов через aws_bedrockagent_agent, и это работает.

Где граница

Спор сводится к одному вопросу: где заканчивается инфраструктура и начинается приложение?

Terraform хорошо управляет тем, что декларативно, стабильно и должно быть одинаковым между окружениями. IAM-роли, сетевые политики, секреты, очереди — всё это ложится в .tf файлы без вопросов.

Но системный промпт, набор MCP-инструментов, логика планирования — это части, которые меняются часто и зависят от контекста. Класть их в Terraform значит получить медленный цикл обратной связи: plan → apply на каждое изменение промпта.

Единственного правильного ответа пока нет. Но сам факт, что DevOps-сообщество обсуждает управление агентами как инфраструктурную задачу, говорит о том, что количество агентов в продакшене растёт.

Агенты как ресурсы может и спорно, но наша рассылка точно только в плюс.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

☁️ Пора переходить на GraalVM Native Image

Spring Boot на JVM стартует 15–20 секунд и съедает ~300 МБ памяти в простое. В Kubernetes это означает полминуты бесполезного ожидания при каждом скейлинге, убитые liveness-пробы и initialDelaySeconds: 25 на каждом сервисе. А serverless с таким холодным стартом вообще не вариант.

GraalVM Native Image компилирует Java-приложение в нативный бинарник ещё на этапе сборки. Никакого JVM внутри, никакой интерпретации байткода. На выходе получаем старт за 60–90 мс и 55 МБ памяти в idle вместо 280.

Как это работает

GraalVM делает AOT-компиляцию (Ahead-of-Time). Статический анализатор проходит по всему коду и собирает в бинарник только то, что реально используется. Это называется closed-world assumption: всё, что не видно анализатору на этапе сборки, в бинарник не попадает. Мёртвый код, неиспользуемые библиотеки, весь JIT-компилятор — всё отсекается.

Отсюда же и главная проблема. Java активно использует рефлексию, динамическую загрузку классов и runtime-генерацию прокси. Статический анализатор этого не видит. Код соберётся, а в рантайме упадёт с ClassNotFoundException.

Spring Boot 3.x решает это через собственный AOT-движок: он заранее обрабатывает метаданные, подменяет динамические вызовы статическими и генерирует код регистрации бинов до компиляции.

Как собрать

В pom.xml добавляем плагин:

<build>
    <plugins>
        <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
        </plugin>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Собираем нативный образ:

mvn -Pnative native:compile

Или через Docker (удобнее для CI/CD, не нужен локальный GraalVM):

mvn -Pnative spring-boot:build-image

Сборка занимает 3–8 минут даже для небольших сервисов. Это нормально — статический анализ и AOT-компиляция делают много работы. В пайплайне это отдельный шаг, не для быстрого фидбека.

Когда это нужно

JVM не устарела. Для сервисов с постоянной нагрузкой, где важен максимальный throughput после прогрева, обычный JVM с JIT по-прежнему лучший выбор.

GraalVM Native Image — для другого сценария: serverless-функции, сервисы, которые скейлятся до нуля ночью, event-driven обработчики с пиковой нагрузкой и долгими паузами, batch-задачи, которые запускаются раз в сутки.

➡️ Больше Java тут

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

✏️ Ещё один HTTP-клиент в терминале

Тестировать API через curl утомительно. Запросы длинные, плохо читаются, а сохранять их приходится в заметках или скриптах. Postman и Insomnia решают проблему, но тянут за собой тяжёлый GUI, аккаунты и облачную синхронизацию.

Slumber — это полноценный HTTP-клиент с интерфейсом в терминале, где вся конфигурация живёт в YAML-файле рядом с проектом.

Что делает Slumber

Slumber работает в двух режимах. TUI — интерактивный интерфейс в терминале, где можно выбирать запросы, отправлять их и просматривать ответы. CLI — для быстрых одноразовых вызовов и использования в скриптах. Оба режима читают одну и ту же конфигурацию, которая называется request collection.

Конфигурация хранится в файле slumber.yml. Это значит, что её можно коммитить в репозиторий и шарить между разработчиками. Не нужно экспортировать коллекции, пересылать JSON-файлы или синхронизировать через облако.

Проект написан на Rust, распространяется под лицензией MIT и останется бесплатным. На GitHub у него около 870 звёзд.

Как начать

Установка через Homebrew:

brew install LucasPickering/tap/slumber

Или через Cargo:

cargo install slumber --locked

Для быстрого старта достаточно сгенерировать шаблон коллекции:

slumber new

После этого запускаем TUI одной командой:

slumber

Пример коллекции

Допустим, мы работаем с API на двух окружениях — локальном и продакшене. Файл slumber.yml будет выглядеть так:

profiles:
  local:
    data:
      host: http://localhost:5000
  production:
    data:
      host: https://myfishes.fish

requests:
  create_fish:
    method: POST
    url: "{{ host }}/fishes"
    body:
      type: json
      data: { "kind": "barracuda", "name": "Jimmy" }

  list_fish:
    method: GET
    url: "{{ host }}/fishes"
    query:
      big: true

Переменная {{ host }} подставляется из текущего профиля. Переключение между local и production делается прямо в TUI без правок файла.

Что ещё умеет

Slumber поддерживает шаблоны (templates), которые позволяют собирать запросы динамически — из результатов других запросов, файлов или вывода shell-команд. Ответы можно фильтровать через JSONPath прямо в интерфейсе. Если вы переезжаете с Insomnia, есть встроенный импорт коллекций. Также Slumber можно использовать как Python-пакет для интеграции в свои инструменты.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🔄 Обновился MX Linux. Текстовый установщик, ядро 7.0 и Debian 13.5

Вышел MX Linux 25.2 — второе обновление серии «Infinity». Релиз основан на Debian 13.5 «Trixie». Стандартные ISO поставляются с ядром Linux 6.12.90, а AHS-версии (Advanced Hardware Support) получили ядро Liquorix 7.0 и mesa 26.0.1.

Главное нововведение — текстовый режим установщика. Теперь MX Linux можно установить без графического окружения, прямо из терминала:

sudo minstall --tui

Помимо этого, в установщике улучшена навигация по клавиатуре в TUI-режиме, добавлено редактирование форматов дисков, исправлена работа GRUB с повреждёнными директориями локалей и убрана опция установки ESP GRUB при отсутствии ESP boot-папки.

Из остального: улучшена работа chroot-rescue-scan с Btrfs и зашифрованными разделами, переработана загрузка live-системы (boot-скрипты вынесены из rc.local), добавлена ручная выборка ядра при запуске, обновлены MX Tools, темы и обои. Также вернулся RPI Respin для Raspberry Pi.

Доступны ISO с Xfce, KDE Plasma и Fluxbox. Пользователям MX 25 переустановка не нужна, все обновления приходят через стандартный канал:

sudo apt update && sudo apt full-upgrade

➡️ Анонс

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

🛠 Один файл, который избавит от рутины. Часть 1

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

Файл ~/.ssh/config решает эту проблему. Он позволяет описать все параметры подключения один раз и обращаться к серверу по короткому имени. Но это только начало. Через тот же файл настраиваются jump-хосты, автовыбор ключей, переиспользование соединений и многое другое.

В первой части разберём основы: алиасы, шаблоны и ProxyJump.

Как это устроено

~/.ssh/config читается при каждом вызове ssh, scp, sftp или rsync. Файл состоит из блоков Host, каждый из которых задаёт параметры для конкретного хоста или группы хостов по шаблону.

Если файла ещё нет, создайте его:

mkdir -p ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

Структура простая:

Host staging
    HostName 203.0.113.50
    User ubuntu
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Теперь вместо длинной команды с кучей флагов достаточно написать:

ssh staging

То же самое работает с scp и rsync:

scp staging:/var/log/app.log ./
rsync -avz staging:/var/www/html/ ./backup/

Шаблоны и подстановки

Блок Host поддерживает wildcards. Например, чтобы задать настройки для всех продакшн-серверов:

Host *.prod.example.com
    User ec2-user
    IdentityFile ~/.ssh/id_ed25519_prod
    ServerAliveInterval 60

Символ ? работает как подстановка одного символа. Host web-? совпадёт с web-1, web-a, но не с web-10.

Можно указать несколько имён в одном блоке:

Host web db cache
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_work

А через ! исключить конкретный хост:

Host * !bastion.prod.example.com
    ServerAliveInterval 30

Блок Host * применяется ко всем подключениям и удобен для общих настроек. Важный момент: SSH читает файл сверху вниз и применяет первое совпавшее значение для каждой директивы. Поэтому конкретные блоки размещайте выше общих.

ProxyJump. Прозрачный доступ через bastion

Продакшн-серверы обычно закрыты от прямого доступа. Подключение идёт через bastion-хост. Без конфига это два шага: сначала SSH на bastion, потом оттуда на целевой сервер. С конфигом всё прозрачно:

Host bastion
    HostName bastion.prod.example.com
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_prod

Host *.prod.internal
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_prod
    ProxyJump bastion

Теперь ssh db.prod.internal автоматически пойдёт через bastion. Работает и с scp, и с rsync.

Для цепочки из нескольких jump-хостов перечислите их через запятую:

Host deep.internal
    ProxyJump bastion.example.com,internal-gateway.example.com

В старых конфигах можно встретить ProxyCommand ssh -W %h:%p bastion.example.com. Это делает то же самое, но ProxyJump короче и понятнее. Для новых конфигов используйте его.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

⚡️ Знакомьтесь с экспертом Proglib Academy: AI-архитектор Антон Будняк

Антон — мастер превращения сырых AI-идей в отказоустойчивые системы. Он знает, как запустить MVP за неделю и масштабировать его так, чтобы архитектура не рассыпалась под нагрузкой в сотни тысяч юзеров.

За что его ценит IT-комьюнити:

🟣 Опыт в финтехе и крупном бизнесе

Руководил разработкой ML-моделей в финтехе с экономическим эффектом более 100 млн ₽

🟣 Запуск продуктов на 6.000+ пользователей

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

🟣 Ускоряет разработку

Оптимизировал ML-пайплайны и кратно сократил время от начала разработки до релиза

📚 Где Антон черпает знания (рекомендации эксперта):

- X* — главный источник новостей. Рекомендую блог Бориса Черни (создателя Claude Code) — там база про использование ИИ в разработке.
- Нетворкинг в ТГ: чаты LLM под капотом и AI-чат — здесь можно найти ответ почти на любой технический вопрос.
- Новости AI: каналы Сиолошная и Denis Sexy IT.

На курсе Agentops Антон учит строить «неубиваемый» бэкенд: работать с очередями, таймаутами и балансировкой нагрузки, чтобы ваши агенты работали стабильно 24/7.

🎁 Майские СКИДКИ в Proglib Academy!

До конца мая на все курсы академии (включая AgentOps и разработку ИИ-агентов) действует скидка -40%. Это лучший момент, чтобы войти в AI-разработку под присмотром практиков.

Узнать больше о программе и обучении у Антона:
👉 Курс о том, как внедрять AI-логику в бэкенд и сохранять стабильность сервиса

Продолжаем знакомить вас с командой?
👍 — Да, ждем новых лиц
🔥 — Пойду подпишусь на каналы из списка Антона

🏃‍♀️ Proglib Academy

* - запрещен в рф

🛠 SSH Config. Ключи, производительность и отладка. Часть 2

В первой части мы разобрали алиасы, шаблоны и ProxyJump. Теперь — автовыбор ключей, переиспользование соединений и отладка.

Управление ключами

Если у вас несколько SSH-ключей, конфиг сам подберёт нужный:

Host *.work.example.com
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

IdentitiesOnly yes запрещает SSH перебирать все ключи из агента. Без этой директивы можно получить отказ на серверах с низким MaxAuthTries.

Если на одной машине два GitHub-аккаунта, создайте алиасы github-personal и github-work с HostName github.com и разными ключами. В remote репозитория укажите алиас вместо github.com:

git remote set-url origin git@github-work:org/repo.git

Общие настройки

ControlMaster переиспользует открытое TCP-соединение вместо нового хендшейка. Keepalive не даёт файрволам закрывать неактивные сессии. ConnectTimeout ограничивает ожидание при подключении к недоступному хосту. Для медленных каналов (VPN, мобильный интернет) добавьте Compression yes.

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 4h
    ServerAliveInterval 60
    ServerAliveCountMax 3
    ConnectTimeout 10

Не забудьте mkdir -p ~/.ssh/sockets.

Отладка

ssh -G staging покажет итоговую конфигурацию без подключения. ssh -vvv staging выдаст подробный лог с информацией о том, какой блок совпал и какой ключ используется.

Частые проблемы: конфиг игнорируется из-за прав 644 вместо 600, SSH берёт не тот ключ без IdentitiesOnly yes, ControlMaster падает из-за несуществующей директории для сокетов. Правильные права:

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/id_*

~/.ssh/config окупается за полчаса настройки. Этот файл стоит хранить в dotfiles-репозитории и обновлять при изменениях в инфраструктуре. По сути это рабочая документация о том, как устроен доступ к вашим серверам.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

🔄 PuTTY 0.84. Исправлены уязвимости при SSH-подключении

Релиз PuTTY 0.84 закрывает две уязвимости безопасности.

Первая позволяла вредоносному серверу или MITM-атакующему вызвать крэш клиента во время начального обмена ключами SSH.

Вторая касалась подключений через прокси с паролем по небезопасным протоколам вроде Telnet: весь сеанс ошибочно помечался «trust sigil», что могло обмануть пользователя и заставить его ввести пароль прокси в ответ на поддельный запрос от сервера.

Из нового: появилась возможность запускать пользовательскую команду перед основным подключением.

Также исправлены ошибки:

• на Unix нельзя было настроить CA для host-сертификатов через GUI без ручного создания конфигурационной директории;

• при подключении через HTTP-прокси с аутентификацией появлялась ложная ошибка «Socket is not connected»;

• на Windows курсор мигал слишком быстро при отключённом системном мигании;

• на Wayland pterm падал при записи в utmp и не находил шрифт по умолчанию.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии