👨‍💻 Альтернатива systemd для управления сервисами

runit это минималистичная система инициализации с автоматическим надзором за процессами. Сервис упал, runit его перезапустит без лишних настроек.

runit работает в три этапа: инициализация системы, надзор за сервисами и корректное завершение работы. Основа это runsvdir, который следит за директориями сервисов и запускает runsv для каждого из них.

Конфигурация сервиса это shell-скрипт. Без YAML, без XML, без многостраничной документации.

Установка:

# Debian/Ubuntu
sudo apt-get install runit

# Arch Linux
sudo pacman -S runit

# CentOS/RHEL
sudo dnf install runit

Создать сервис

Структура минимальная: директория с исполняемым файлом run.

sudo mkdir -p /etc/sv/webserver

sudo tee /etc/sv/webserver/run << 'EOF'
#!/bin/sh
exec 2>&1
cd /var/www/html
exec python3 -m http.server 8080
EOF

sudo chmod +x /etc/sv/webserver/run

# Включить сервис
sudo ln -s /etc/sv/webserver /etc/service/

Два ключевых правила в run-скрипте: использовать exec вместо запуска в фоне и перенаправлять stderr через exec 2>&1. Программа должна работать на переднем плане, runit сам управляет процессом.

Основные команды через sv:

sv start webserver    # запустить
sv stop webserver     # остановить
sv restart webserver  # перезапустить
sv status webserver   # статус

Пример вывода статуса:

run: nginx: (pid 1234) 3600s
down: mysql: 120s, normally up

Логирование через `svlogd`

runit поставляется с собственным логгером. Он умеет в ротацию, фильтрацию и временны́е метки.

sudo mkdir -p /etc/sv/webserver/log

sudo tee /etc/sv/webserver/log/run << 'EOF'
#!/bin/sh
exec svlogd -tt /var/log/webserver
EOF

sudo chmod +x /etc/sv/webserver/log/run
sudo mkdir -p /var/log/webserver

Как выглядит миграция с systemd

Типичный unit-файл systemd:

[Service]
Type=simple
User=webuser
WorkingDirectory=/opt/webapp
ExecStart=/opt/webapp/bin/server
Restart=always

Эквивалент в runit:

#!/bin/sh
exec 2>&1
cd /opt/webapp
exec chpst -u webuser /opt/webapp/bin/server

chpst — утилита из runit для запуска процессов от другого пользователя и с ограничениями по ресурсам.

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

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

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

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

💻 HCP Terraform на базе Infragraph вышел в публичный превью

HashiCorp объявила о публичном превью HCP Terraform powered by Infragraph на конференции IBM Think 2026. Доступ откроется с 8 мая для квалифицированных US-клиентов HCP Terraform.

Какую проблему решает

Команды, работающие с гибридными и мультиоблачными инфраструктурами, хорошо знают эту боль: данные о ресурсах разбросаны по разным инструментам, нет единой картины того, что происходит в AWS, Azure, GCP и on-prem одновременно.

Когда нужна актуальная информация, её приходится собирать вручную из разных источников. К моменту, когда данные готовы к анализу, они уже устарели.

Что такое Infragraph

Infragraph это централизованный граф знаний с событийно-ориентированным обновлением данных. Он подключается напрямую к вашим облачным провайдерам и собирает актуальное состояние инфраструктуры в одном месте. Для более глубоких или кастомных потоков данных доступен Terraform Search.

Зачем это нужно:

• Единый источник правды по всему estate: AWS, Azure, GCP, on-prem

• Запросы к инфраструктуре на естественном языке для CloudOps и security-команд

• Актуальная информация о том, кто владеет ресурсами и за что отвечает

• Основа для будущей автоматизации через AI-агентов

Первые шаги после входа:

1. Добавьте подключение к AWS, HCP Terraform и HCP Packer — увидите, как ваш cloud estate связан с инфраструктурой как кодом
2. Запросите неуправляемые ресурсы или ресурсы со старой версией Terraform

# Пример: вход в HCP-консоль
https://portal.cloud.hashicorp.com/sign-in
→ Infragraph → Connections → Add connection

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

➡️ Блог разработчиков

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

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

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

☕️ Топ-вакансий для девопсов за неделю

DevOps / Platform Engineer — до 220 000 ₽ на удалёнке

DevOps-инженер — удалёнка

Senior DevOps Engineer — от 300 000 ₽, гибрид/удалёнка в Москве или СПб

➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs

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

#вакансия_недели

🔄 pyinfra 3.8.0. Крупный релиз с фиксами безопасности и новыми Docker-операциями

Вышла новая версия инструмента для автоматизации инфраструктуры на чистом Python. Заодно проект перешёл на полный semver: теперь версии будут выглядеть как 3.8.0 вместо 3.8.

Безопасность

Пожалуй, самое важное в этом релизе. Все пользовательские значения теперь экранируются при построении команд, это закрывает потенциальные векторы command injection в коннекторах, операциях и утилитах.

Docker стал полноценным

Добавили целый блок новых операций:

• operations.docker.compose — управление через Docker Compose

• operations.docker.build — сборка образов

• operations.docker.login / logout — аутентификация в реестре

Плюс новые факты: версия Docker, детали контейнеров, образов и сетей.

Новые факты и операции

• facts.server.Ports — список всех портов в состоянии LISTEN на хосте.

• facts.server.Processes + server.kill — получить список процессов и завершить нужный.

• facts.server.AuthorizedKeys — чтение authorized_keys, операция user_authorized_keys стала идемпотентной.

• operations.files.unarchive — распаковка архивов как отдельная операция.

• operations.files.download — теперь поддерживает limit_rate для ограничения скорости загрузки.

• operations.git.repo — добавили параметр depth для shallow clone.

Поддержка uv

Добавлены факты и операции для работы с uv — Python-пакетным менеджером. Пример использования стал стандартным для проекта: все примеры в репозитории теперь запускаются через uv run pyinfra.

APT и пакетные менеджеры

• facts.apt.AptSources теперь понимает формат deb822 — современный способ записи источников в Debian/Ubuntu.

• apt.packages получил параметр purge для полного удаления пакетов вместе с конфигами.

• apt.key обновлён под современный подход без устаревшей команды apt-key.

Прочее

• config.INHERIT_ENV — новый параметр для передачи переменных окружения локального процесса во все операции.

• dzdo — добавлена поддержка как альтернативы sudo для повышения привилегий.

• Поддержка paramiko v4, совместимость с Python 3.14, ленивая загрузка модулей фактов и операций для ускорения старта.

Обновиться:

pip install --upgrade pyinfra

➡️ Тэг на GitHub

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

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

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

GitHub, если бы его делали Electronic Arts

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

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

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

🧑‍💻 Kernel Panic при загрузке: находим причину и чиним

Сервер не поднимается после перезагрузки. Экран с kernel panic, и всё. Это одна из тех ситуаций, когда важно действовать методично, а не наугад.

Что обычно ломается

Три самые частые причины:

• Повреждённый /etc/fstab. Если UUID раздела не совпадает с тем, что прописано в файле, система не может смонтировать диск и падает на старте.

• Проблемы с GRUB. После обновления ядра или ручной правки конфига загрузчик может потерять путь к системе.

• Аппаратные сбои. Отказ диска или памяти тоже проявляется как panic при загрузке, поэтому железо стоит проверить сразу.

Как чинить

Загружаемся в recovery mode. В меню GRUB выбираем Advanced options и строку с (recovery mode). Получаем root-шелл без монтирования основной системы.

Проверяем диск:

fsck -f /dev/sda1

fsck найдёт и исправит ошибки файловой системы. Флаг -f запускает проверку даже если диск помечен как чистый.

Сверяем UUID в /etc/fstab:

blkid

Вывод покажет реальные UUID всех разделов. Открываем /etc/fstab и проверяем, что значения совпадают. Расхождение в одном символе — и система не загрузится.

Если проблема в GRUB, переустанавливаем его:

grub-install /dev/sda
update-grub

/dev/sda — диск, не раздел. Убедитесь, что указываете устройство без цифры на конце.

Как не попасть в это снова

Перед любыми правками в /etc/fstab или конфигах загрузчика делаем бэкап:

cp /etc/fstab /etc/fstab.bak

Изменения в загрузочной конфигурации тестируем на staging-окружении. Продакшн-сервер — плохое место для экспериментов с GRUB.

Если инфраструктура позволяет, настраиваем снапшоты перед каждым обновлением ядра. Откатиться за 30 секунд гораздо приятнее, чем чинить вручную в 3 ночи.

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

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

#root_prompt

📎 Дублируем root

В Linux права определяются не именем пользователя, а его UID. У root всегда UID=0. Если создать пользователя с тем же UID=0, система будет воспринимать его как root со всеми вытекающими правами.

Добавляем запись напрямую в /etc/passwd. Открываем файл:

sudo vipw

Добавляем строку в конец файла:

superadmin:x:0:0:Super Admin:/root:/bin/bash

Ставим пароль новому пользователю:

sudo passwd superadmin

Проверяем, что всё работает:

id superadmin
#uid=0(root) gid=0(root) groups=0(root)

Альтернатива через useradd

Команда useradd не позволяет напрямую задать UID=0, но можно создать пользователя и потом поправить запись:

sudo useradd -o -u 0 -g 0 -d /root -s /bin/bash superadmin
sudo passwd superadmin

Флаг -o разрешает дублирование UID. Без него команда завершится с ошибкой.

Если вы используете sudo, убедитесь что новый пользователь тоже может его вызывать. Добавьте строку в /etc/sudoers через visudo:

superadmin ALL=(ALL:ALL) ALL

Такой подход используют в нескольких сценариях: аварийный доступ при утере основного пароля, автоматизация через отдельный сервисный аккаунт с полными правами, или командная работа где нескольким людям нужен root без общего пароля.

Два аккаунта с UID=0 означают двойную поверхность атаки. Следите за тем, кому и зачем открываете такой доступ и включайте аудит действий через auditd или аналоги.

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

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

#root_prompt

🖥 Cмотрим, что реально делает GPU

GPU загружен на 95% — звучит хорошо. Но это ничего не говорит о том, занят ли он полезной работой или просто ждёт данных. Стандартные метрики показывают занятость, но не эффективность.

utilyze решает именно эту проблему. Он измеряет SOL (Speed-of-Light) — насколько GPU использует свой теоретический максимум по вычислениям и пропускной способности памяти. И делает это в реальном времени, не замедляя нагрузку.

Что под капотом

Инструмент написан на Go и C++, использует NVIDIA CUPTI и Perf SDK для сбора аппаратных счётчиков. Работает на Linux amd64, требует GPU архитектуры Ampere и CUDA 11.0+.

Установка:

curl -sSfL https://systalyze.com/utilyze/install.sh | sh

При установке потребуется sudo — инструмент ставится системно. Если CUPTI 12+ не найден, при первом запуске предложит доустановить его через PyPI.

Запуск:

# мониторинг всех GPU
sudo utlz

# только конкретные устройства
sudo utlz --devices 0,2

# показать эндпоинты инференс-серверов на каждом GPU
sudo utlz --endpoints

По умолчанию NVIDIA ограничивает доступ к профилировочным счётчикам для не-root пользователей.

Чтобы запускать без sudo, нужно один раз отключить это ограничение:

echo 'options nvidia NVreg_RestrictProfilingToAdminUsers=0' | sudo tee /etc/modprobe.d/nvidia-profiling.conf
sudo reboot

Поддержка инференс-серверов

utlz умеет обнаруживать эндпоинты инференс-серверов и показывать roofline-потолки для каждого GPU — то есть, какой максимум достижим при текущей конфигурации. Сейчас поддерживается только vLLM, поддержка других бэкендов заявлена.

Сборка из исходников

Если нужна сборка самостоятельно — потребуется Go 1.25+, Docker и CUDA Toolkit:

# собрать нативную библиотеку и CLI
make all

# только CLI
make utlz

Есть экспериментальная поддержка ARM64 через sbsa-linux CUDA target.

Если вы занимаетесь LLM-инференсом или любой другой GPU-нагрузкой и хотите понять, насколько эффективно используется железо, utilyze даёт ответ конкретными числами, а не процентом занятости.

➡️ Репозиторий

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

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

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

🧠 Мини-тест

Какой тип Kubernetes использует внешний балансировщик облачного провайдера?

А) ClusterIP
Б) NodePort
В) LoadBalancer
Г) ExternalName

👉 Пишите ответ в комментариях, а ответ смотрите здесь

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

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

#задача_со_звёздочкой

🚮 Drop правила для фильтрации мусорных логов
 
Если вы используете Grafana Cloud Logs, скорее всего, часть логов там вообще не нужна. Health check каждые 5 секунд, DEBUG-записи из забытого сервиса, многословный INFO из batch-джобы — всё это идёт в хранилище и увеличивает счёт.
 
Раньше убрать этот мусор было неудобно. Нужно было лезть в конфиги, договариваться с командами, менять пайплайн. Теперь в Adaptive Logs появились drop rules — правила, которые отфильтровывают ненужные логи до записи в хранилище.
 
Что делают drop rules
 
Правило задаёт условие: какие логи отбрасывать и с какой долей. Можно указать лейбл сервиса, уровень лога, строку в теле — или всё вместе. Поддерживается частичный дроп: например, оставить 10% от потока, а остальное не сохранять.
 
Несколько сценариев, где это полезно:
 
Если payment-service в продакшне шлёт DEBUG-логи, которые никто не смотрит:

service_name = payment-service
log_level = DEBUG
drop rate = 100%

 
Batch-джоба пишет одно и то же тысячи раз в день. Оставляем 10% для выборки:

service_name = batch-processor
drop rate = 90%

 
Выбросить конкретный паттерн. Сервис пишет GET /healthz 200 каждые несколько секунд. Указываем строку в теле лога и дропаем 100%.
 
Как это работает внутри
 
Каждый входящий лог проходит три шага по порядку:
 
1. Exemptions — если лог попадает под исключение, он записывается без изменений.

2. Drop rules — правила применяются по приоритету. Первое совпавшее правило задаёт процент дропа.

3. Patterns — к оставшимся логам применяются рекомендации от самого Adaptive Logs на основе анализа 15 дней запросов.

Exemptions нужны для логов, которые нельзя терять ни при каких условиях, — аудит, ошибки из критичных сервисов. Drop rules — для того, что точно не нужно. Patterns — для всего остального, что Grafana сама определит как малоценное.
 
Как начать
 
Функция доступна в public preview в Grafana Cloud. Нужна роль plugins:grafana-adaptivelogs-app:admin — по умолчанию она есть у Grafana Admin и Org Admin.
 
Путь в интерфейсе:
Adaptive Telemetry → Adaptive Logs → Drop rules → Create a new drop rule
 
Управлять правилами также можно через CLI gcx если нужна автоматизация или интеграция с агентами.
 
➡️ Репозиторий

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

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

#root_prompt

🔄 Вышел Incus 7.0 LTS
 
Команда Linux Containers выпустила Incus 7.0 LTS — второй долгосрочный релиз менеджера системных и OCI-контейнеров, а также виртуальных машин.

Поддержка продлится до июня 2031 года: первые два года патчи и небольшие улучшения, ещё три года только безопасность.
 
В релизе закрыты 9 CVE умеренной и низкой степени опасности. Среди важных изменений — удаление поддержки CGroupV1 и xtables, повышение минимальных требований к системе, а также правки в CLI. Minio заменён встроенным S3-слушателем.
 
Из новых возможностей: низкоуровневое API для бекапов, ограничение пулов хранилища по проектам, поддержка OCI-контейнеров, сетевые наборы адресов network address sets, драйверы хранилища Linstor и TrueNAS, а также перебалансировка кластера через placement scriptlet.
 
➡️ Полный changelog | онлайн-демо

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

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

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

📎 Только имя пода и образ

Иногда нужен простой список подов и их образов. Без лишних колонок, без шума. kubectl get pods -o wide выдаёт слишком много данных, которые в этот момент не нужны.

Для таких случаев есть флаг -o custom-columns. Он позволяет выбрать только те поля, которые важны прямо сейчас.

Чтобы получить таблицу с именем пода и образом контейнера, достаточно одной команды:

kubectl get pods -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containers[*].image'

Результат — чистая таблица без лишнего. [*] в пути означает, что команда учитывает все контейнеры в поде, включая сайдкары.

Формат колонки строится по простому правилу: сначала заголовок, потом путь к полю в JSON-структуре объекта. Любое поле из kubectl get pod -o json можно вытащить таким же способом.

Это особенно удобно в скриптах и CI, где важна предсказуемость вывода. Никаких сюрпризов при обновлении версии kubectl.

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

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

#root_prompt

🗓 14 мая в 19:00 (Мск) встречаемся в онлайне.

Тема: Почему AI-продукты на базе LLM ломаются и как сделать, чтобы работало.

В кружке выше Эмиль Сатаев рассказал, какие именно проблемы с LLM в проде будем разбирать.

Что в программе:

- Разберем реальные кейсы стартапов и ограничения LLM.
- Обсудим рабочие архитектуры: RAG, human-in-the-loop, контроль качества.
- Ответим на ваши вопросы и разберем кейсы участников.

🎁 Бонусы: в конце вебинара подарим промокод на скидку 10.000 ₽ на курсы и разыграем подписки на полезные AI-сервисы.

👉 Зарегистрироваться на вебинар

📰 Админ расплавился от жары

И к другим не менее важным новостям

— Раньше алгоритмы, а теперь симуляция директора

— apt 3.3.0

— Fedora 44

— HCP Terraform на базе Infragraph

— pyinfra 3.8.0

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

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

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