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

DevOps (SRE) lead/Руководитель DevOps команды — от 380 000 ₽, офис в Москве

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

Junior DevOps engineer — от 90 000 ₽ на удалёнку

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

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

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

🔄 Kubernetes v1.36: что нового в релизе «Хару»

Вышел Kubernetes v1.36 с кодовым именем «Haru» (春, весна). Релиз включает 70 улучшений: 18 достигли статуса Stable, 25 перешли в бету и 25 в альфу.

User Namespaces для подов

Поды теперь можно запускать в изолированных пространствах пользователей без сторонних инструментов вроде gVisor. Достаточно добавить hostUsers: false в спецификацию пода:

spec:
  hostUsers: false
  containers:
    - name: app
      image: my-app

Контейнер работает как root внутри неймспейса, но снаружи — от непривилегированного пользователя. Это снижает риски при компрометации контейнера.

MutatingAdmissionPolicy

Раньше для мутации ресурсов нужны были admission webhooks — внешние сервисы с TLS, деплоем и всеми сопутствующими проблемами. Теперь логику мутации можно описать через нативные объекты Kubernetes на языке CEL, без внешних серверов:

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: add-default-labels
spec:
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >
          Object{metadata: Object.metadata{labels: {"env": "production"}}}

OCI VolumeSource

Артефакты OCI: веса ML-моделей, конфиги, датасеты, бинари; теперь можно монтировать как тома напрямую из реестра образов без необходимости упаковывать всё в основной образ.

Тонкая авторизация kubelet API

Kubelet теперь поддерживает гранулярное управление доступом к своему API. Каждый эндпоинт можно разрешить или ограничить отдельно, без открытия всего API целиком.

SELinux-монтирование томов

Вместо рекурсивного перемаркирования файлов Kubernetes теперь применяет SELinux-контекст через mount -o context=XYZ при монтировании. Это сокращает время старта подов на системах с SELinux.

Что изменилось в Beta

Mutable scheduling directives для приостановленных Job

Теперь можно менять nodeSelector, affinity и запросы ресурсов у приостановленного (suspend: true) Job перед его возобновлением. Особенно полезно для пакетных и ML-задач, где параметры планирования могут меняться динамически.

HPA Scale-to-Zero

HorizontalPodAutoscaler теперь умеет масштабировать деплойменты до нуля реплик на основе внешних метрик. Актуально для dev/staging-окружений и событийно-ориентированных сервисов с простоями.

Что появилось в Alpha

Workload Aware Scheduling (WAS)

Новая группа фич для распределённых рабочих нагрузок. Включает Gang Scheduling (все поды джоба стартуют одновременно или не стартуют вовсе), топологически осведомлённое размещение и новый PodGroup API. Ориентировано на AI/ML-тренировки и batch-пайплайны.

HPA External Metrics Fallback

Если внешний провайдер метрик (Datadog, облачные очереди) недоступен, HPA сможет использовать резервное значение вместо того, чтобы падать с ошибкой.

Что удалено и что стоит проверить

• Плагин томов gitRepo отключён навсегда. Он позволял выполнять код от имени root через клонирование репозитория. Миграция — на init-контейнеры или внешние git-sync инструменты.

• Режим IPVS в kube-proxy удалён (был deprecated в v1.35).

• Поле externalIPs в Service помечено deprecated из-за уязвимости CVE-2020-8554. Полное удаление ожидается в v1.43.

• Ingress NGINX официально выведен из поддержки 24 марта 2026 года — новых релизов, патчей безопасности и исправлений не будет. Существующие инсталляции продолжат работать, но миграция на Gateway API становится обязательной задачей.

➡️ Источник

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

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

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

👨‍💻 self-hosted инструмент для бэкапов БД

Ручные скрипты на mysqldump и pg_dump справляются с задачей, но плохо масштабируются: нет алертов при сбоях, бэкапы хранятся локально, а для нескольких баз нужно поддерживать отдельные скрипты. Databasus закрывает все эти пробелы через единый веб-интерфейс.

Databasus это open source инструмент (Apache 2.0) для автоматизированных бэкапов баз данных. Основной фокус на PostgreSQL, но поддерживает MySQL, MariaDB и MongoDB.

Умеет:

• Хранить бэкапы в локальном хранилище, S3, Cloudflare R2, Google Drive, Dropbox, SFTP и через Rclone.

• Уведомлять об успехе и сбоях через Email, Telegram, Slack, Discord и вебхуки.

• Шифровать файлы бэкапов по AES-256-GCM — это значит, что бэкапы безопасно хранить даже в публичных S3-бакетах.

Как работает подключение к базе

Два режима.

1. Remote — Databasus подключается к базе по сети напрямую, агент не нужен. Удобно для managed баз вроде RDS.

2. Agent — лёгкий агент на Go запускается рядом с базой и стримит бэкап напрямую в хранилище, база не торчит наружу.

Как запустить

Самый быстрый способ через Docker:

docker run -d \
  --name databasus \
  -p 4005:4005 \
  -v ./databasus-data:/databasus-data \
  --restart unless-stopped \
  databasus/databasus:latest

После запуска открываем http://localhost:4005, добавляем базу, настраиваем расписание, хранилище и уведомления.

Для Linux есть автоматический скрипт, который сам установит Docker и настроит автозапуск:

sudo apt-get install -y curl && \
sudo curl -sSL https://raw.githubusercontent.com/databasus/databasus/refs/heads/main/install-databasus.sh \
| sudo bash

Для Kubernetes доступен Helm-чарт из OCI-реестра:

helm install databasus oci://ghcr.io/databasus/charts/databasus \
  -n databasus --create-namespace

Важный момент

Сам Databasus тоже стоит забэкапить или хотя бы сохранить ключ шифрования. Без него восстановить зашифрованные бэкапы не получится даже при наличии файлов в хранилище. Документация по восстановлению без Databasus есть на сайте.

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

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

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

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

🖇 HTTP-прокси убирает секреты из кода

API-ключ это не просто пароль. Тот, кто его получил, может передать его другому. Именно поэтому утечка ключа из /etc/defaults или .env — это не просто «кто-то узнал пароль», а потенциально открытая дыра до тех пор, пока вы не заметите и не отзовёте ключ.

С агентами стало хуже. Некоторые модели при виде ключа в контексте отказываются работать или записывают его в межсессионную память — и потом пытаются использовать уже отозванный ключ.

Ротация ключей помогает, но не решает проблему полностью. OAuth в теории справляется, но на практике требует браузерного флоу с участием человека. Автоматизировать это под агента почти невозможно.

Решение: прокси, который подставляет заголовки

Большинство API работают через HTTP и принимают ключ в заголовке запроса. Значит, можно убрать ключ из кода и переложить его в HTTP-прокси, который будет добавлять нужный заголовок автоматически.

Обычный запрос к Stripe выглядит так:

curl https://api.stripe.com/v1/customers \
  -u "sk_test_BQokikJOvBiI2HlWgH4olfQ2:" \
  -d "name=Jenny Rosen"

С прокси он выглядит так:

curl https://stripe.int.your-company.xyz/v1/customers \
  -d "name=Jenny Rosen"

Ключа в запросе нет. Ключ хранится в прокси. Доступ к сервису определяется тем, может ли ваш сервер или агент достучаться до этого прокси — а не тем, знает ли он ключ.

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

Вы поднимаете внутренний HTTP-прокси, который:

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

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

Что это даёт

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

Ротация становится проще. Менять ключ нужно только в прокси, а не по всем сервисам и окружениям.

Кому подходит

Это не замена полноценной системе управления секретами вроде HashiCorp Vault или AWS Secrets Manager. Но это работающий подход для небольших команд, которым не нужна вся операционная сложность таких систем. Прокси с подстановкой заголовков закрывает большую часть рисков при минимальных затратах.

➡️ Оригинал

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

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

#локализация

🥲 Linux 7.1 удаляет поддержку процессоров Baikal

Линус Торвальдс принял в ветку Linux 7.1 патчи, которые убирают поддержку контроллеров AHCI SATA и PCIe для SoC Baikal-T1. Параллельно на рассмотрении находятся pull-запросы на удаление ещё нескольких связанных драйверов: таймера, памяти, physmap, шины, hwmon, dwc и bt1-rom. В ядре 7.0 уже удалили поддержку i2c и spi dw для той же платформы.

Причина удаления — отсутствие сопровождения и незавершённая интеграция. Например, драйвер PCIe для Baikal-T1 так и не был доведён до рабочего состояния. Компания «Байкал Электроникс» прекратила деятельность в начале 2025 года после того, как TSMC заморозила поставки чипов под санкционным давлением ещё в 2022 году.

Поддержка Baikal-T1 в ядре Linux появилась в версии 5.8.

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

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

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

🔄 Grafana 13.0: что нового

Вышла свежая Grafana: меньше ручной работы при создании дашбордов, стабильный GA для нескольких давно preview-функций и несколько breaking changes, которые стоит проверить перед обновлением.

Дашборды

Dynamic dashboards теперь GA и включены по умолчанию для всех. Новый движок лейаута, новый формат схемы. Существующие дашборды мигрируют автоматически при открытии, ничего делать вручную не нужно.

Восстановление удалённых дашбордов тоже вышло в GA. В разделе Recently deleted можно вернуть случайно удалённый дашборд без тикета в поддержку.

Обновлённый Gauge вышел из preview. Появился новый тип панели — Graphviz: принимает DOT-язык и умеет подтягивать живые данные из любого источника.

Git Sync вышел в GA — двусторонняя синхронизация ресурсов Grafana с git-репозиторием.

Работа с запросами и панелями

Saved queries теперь можно использовать как отправную точку при создании панели. Выбираете Use saved query, Grafana сама подбирает визуализацию и создаёт панель без входа в редактор.

Переменные в saved queries теперь подставляются инлайн при выборе запроса. Раньше, если переменная в запросе не совпадала с дашбордом, появлялось предупреждение о несовместимости.

Появились Panel styles — готовые наборы настроек (цвета, пороги, отображение), которые применяются одним кликом. Поддерживается в time series, gauge, bar gauge, stat, bar chart. Там же добавили копирование стилей между панелями.

Новый контрол Filter and Group by заменяет базовые ad hoc фильтры. Ad hoc filters при этом просто переименовали в Filters — в схеме "kind": "AdhocVariable" остался прежним.

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

Появились grouping-level переменные: теперь можно задать переменную, которая влияет только на определённую группу панелей, а не на весь дашборд сразу.

AI

Grafana Assistant теперь умеет генерировать SQL Expressions — объединение и трансформация данных из нескольких запросов через SQL. Раньше это требовало знания того, что имена запросов становятся именами таблиц и понимания MySQL-диалекта.

Источники данных и плагины

Добавлена поддержка IBM DB2 (public preview для Grafana Cloud и Enterprise).

Elasticsearch теперь поддерживает два режима запросов помимо визуального построителя: Query DSL и ES|QL.

Grafana Advisor вышел в GA. Это встроенный инструмент проверки состояния инстанса: находит источники данных с ошибками, устаревшие плагины, проблемы в настройках SSO. Проверки запускаются раз в неделю или вручную, можно настроить алерты.

Breaking changes

Несколько вещей, которые стоит проверить перед обновлением:

Удалены дублирующиеся метрики кэширования запросов grafana_caching_items и grafana_caching_size — они были объявлены deprecated в v12.

Изменены дефолты для аудит-логирования запросов к источникам данных (log_datasource_query_request_body, log_datasource_query_response_body).

Устарел ряд Prometheus-метрик для БД. Метрики вида go_sql_stats_* и grafana_database_conn_* заменяются на go_sql_*. Данные те же, только имена другие. Старые будут удалены в следующих релизах.

Удалена возможность отключить Scenes-архитектуру для дашбордов. Она была включена по умолчанию с v11, теперь feature toggle убрали совсем.

➡️ Источник | Upgrade Guide

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

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

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

🔍 Вы выставили --cpus=2 и контейнер начал лагать

Казалось бы, вы дали ему ресурсы. Два полноценных ядра. Должно хватать с запасом.

Но в моменты всплеска нагрузки сервис вдруг начинает отвечать с задержками. Метрики CPU не показывают 100%. А лаги есть.

Что происходит внутри? Почему начались лаги? ➡️ Узнать ответ

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

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

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

☕️ Java и лимиты

Запускаете Java-приложение и через час получаете звонок, что сервер лежит? Знакомо.

По умолчанию JVM берёт столько памяти и CPU, сколько захочет. На проде это боль. Разберёмся, как это починить.

Память

Два главных флага:

• -Xms512m — сколько памяти выделить сразу при старте
• -Xmx2g — максимум, выше которого heap не вырастет

java -Xms512m -Xmx2g -jar app.jar

Ставьте -Xmx всегда. Без него JVM может решить, что ей нужна половина RAM сервера и будет права по своей логике.

CPU / потоки

Ограничить количество потоков GC и компилятора:

-XX:ActiveProcessorCount=2

Особенно актуально в Docker/Kubernetes, ведь JVM видит все ядра хоста, а не контейнера. Без этого флага она создаст лишние потоки и будет драться за ресурсы.

Если запускаете в контейнере

Начиная с Java 11+ JVM умеет читать cgroup-лимиты контейнера автоматически. Но лучше явно включить:

-XX:+UseContainerSupport

И добавьте -Xmx через переменную окружения, чтобы удобно менять без пересборки:

JAVA_OPTS="-Xms256m -Xmx1g -XX:ActiveProcessorCount=2"
java $JAVA_OPTS -jar app.jar

📌 Итого: минимальный набор для продакшена

-Xms256m
-Xmx1g
-XX:ActiveProcessorCount=2
-XX:+UseContainerSupport

Дальше смотрите на метрики и подкручивайте под своё приложение.

➡️ Больше про Java без воды в канале. Подписывайтесь, там научат делать Java-Java

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

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

#root_prompt

🔄 Ubuntu 26.04 LTS вышел

Canonical выпустили Ubuntu 26.04 LTS с кодовым именем Resolute Raccoon. Это LTS-релиз. Поддержка Ubuntu Desktop, Server и Cloud рассчитана на 5 лет, для остальных редакций на 3 года.

Что изменилось

Главное в этом релизе — безопасность и производительность. Добавили полное шифрование диска на основе TPM, расширили использование компонентов на memory-safe языках, улучшили управление правами приложений. Livepatch теперь поддерживает Arm-системы, что позволяет применять патчи ядра без перезагрузки.

На стороне рабочего стола: GNOME 50 на Wayland, доработанный интерфейс управления приложениями, улучшенная поддержка доступности. Для разработчиков добавили нативную поддержку современных AI-тулкитов и HPC-инструментов.

Как обновиться

Пользователи Ubuntu 25.10 получат предложение обновиться автоматически. Пользователи 24.04 LTS — только после выхода 26.04.1, который запланирован на 4 августа 2026.

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

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

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

👀 Ваш топ по DevOps

Кого смотрите и читаете по DevOps, Kubernetes, CI/CD, облакам? YouTube, Хабр, телеграм, подкасты — пишите в комменты 👇

Есть ощущение, что хорошего DevOps-контента на русском катастрофически мало 🤔

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

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

#холиварня

🔄 Релизный дайджест

Неделька вышла насыщенная, вот все релизы:

— Kubernetes v1.36

— OpenSSL 4.0.0

— ИИ для поиска работы

— nginx 1.30.0

— Vercel взломали

— В Linux 7.1 удалят поддержку процессоров i486

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

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

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

🔄 Вышел LXQt 2.4.0

20 апреля команда LXQt выпустила версию 2.4.0. Это исправление ошибок и чистка кода, но есть и заметные улучшения в нескольких компонентах.

Управление питанием

В lxqt-powermanagement появился отдельный таймаут на отключение монитора для режимов AC и батареи. Интерфейс настроек стал чище — лишние опции убрали из выпадающих списков.

Панель и звук

Плагин громкости в lxqt-panel получил горизонтальный layout. Теперь он показывает все доступные аудиовыходы, а громкость нужного можно менять прямо колесом мыши на иконке в панели.

Ещё в версии 2.3.3 поправили фильтр в «Fancy menu» — поиск теперь приоритизирует совпадения с начала строки. Например, fir всегда покажет Firefox первым.

Файловый менеджер

В диалоге сохранения файла PCManFM-Qt имя файла теперь сразу выделено — можно переименовать без лишних кликов. На Wayland починили консистентность отображения элементов рабочего стола при работе с несколькими мониторами.

Сессии

Настройки для X11 и Wayland-сессий разделили в lxqt-config-session. Wayland-раздел виден только если установлен lxqt-wayland-session. Главное меню теперь открывается и на Wayland через lxqt-qdbus openmenu.

Терминал

В QTerminal улучшили поиск: теперь подсвечиваются все совпадения сразу. Починили URL-паттерн, из-за которого ссылки со скобками давали 404. Добавили тему Nord и шорткат для кнопки «keep open» в режиме выпадающего терминала.

Уведомления

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

Требования к версии Qt не изменились. Cборка на Debian Trixie и производных по-прежнему работает.

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

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

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

⭐️ Kubernetes v1.36: User Namespaces теперь стабильны

В Kubernetes v1.36 поддержка User Namespaces для подов получила статус General Availability. Это только Linux-функция, но она закрывает давнюю проблему безопасности контейнерных workload'ов.

Что за проблема

Когда контейнер работает от root-пользователя, при побеге из sandbox он получает root-привилегии на хост-ноде. Это значит, что один скомпрометированный под потенциально открывает доступ ко всему узлу. Десятки уязвимостей класса HIGH и CRITICAL можно было эксплуатировать именно через это.

Что делает User Namespaces

User Namespaces изолируют пользователя внутри контейнера от пользователя на хосте. Процесс, который видит себя как root (UID 0) внутри контейнера, на хосте отображается в непривилегированного пользователя. Так, даже при побеге из контейнера, атакующий не получит прав на ноде.

Второй важный момент: с hostUsers: false возможности вроде CAP_NET_ADMIN становятся namespaced. Это значит, что они дают административные права только над ресурсами внутри контейнера, не затрагивая хост. Раньше такой сценарий требовал запуска полностью привилегированного контейнера.

Как включить

Одно поле в манифесте пода:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  hostUsers: false
  containers:
    - name: app
      image: my-app:latest

Этого достаточно, чтобы под получил собственное изолированное пространство UID/GID.

Что важно учитывать

Требования к среде: Linux-нода с поддержкой user namespaces в ядре, а также совместимый container runtime (containerd >= 1.7, CRI-O >= 1.25).

Диапазон UID/GID для каждого пода должен быть кратен 65536 и начинаться с числа >= 65536. Начиная с v1.33 это можно настроить через KubeletConfiguration:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
userNamespaces:
  idsPerPod: 65536

До v1.33 значение было жёстко задано и равно 65536.

Изменения в Pod Security Standards

Для подов с hostUsers: false Kubernetes ослабляет ряд ограничений PSS. Поля, которые обычно блокируются в Baseline и Restricted, становятся допустимыми, потому что root внутри такого пода никогда не отображается в реальный root на хосте.

Работа над этой функцией началась около 10 лет назад. В alpha она вошла в v1.25, в v1.33 была включена по умолчанию, а в v1.36 получила статус стабильной.


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

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

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

📎 docker compose для виртуальных машин

Если вы когда-нибудь поднимали стек из нескольких ВМ на KVM, то знаете, как это выглядит на практике: XML-конфиги libvirt, ручная настройка сетей, отдельные cloud-init-образы для каждой машины. И всё это нужно держать в голове или раскидывать по скриптам.

holos решает именно эту проблему. Он берёт синтаксис, знакомый по docker compose, и применяет его к настоящим виртуальным машинам на KVM/QEMU без libvirt, без XML, без сетевых мостов с root-доступом.

Что он делает

Вы описываете стек в holos.yaml. Каждый сервис — это ВМ со своим образом, ресурсами и cloud-init-конфигом. Поддерживаются зависимости между сервисами, проброс портов, монтирование директорий, реплики и healthcheck.

Пример:

name: my-stack

services:
  db:
    image: ubuntu:noble
    vm:
      vcpu: 2
      memory_mb: 1024
    cloud_init:
      packages:
        - postgresql
      runcmd:
        - systemctl enable postgresql
        - systemctl start postgresql

  web:
    image: ubuntu:noble
    replicas: 2
    depends_on:
      - db
    ports:
      - "8080:80"
    cloud_init:
      packages:
        - nginx
      runcmd:
        - systemctl restart nginx

Затем одна команда:

holos up

И у вас работают две ВМ с nginx и одна с PostgreSQL, все видят друг друга по имени сервиса.

Как это работает внутри

Каждая ВМ получает два сетевых интерфейса: user-mode для проброса портов с хоста и socket multicast для L2-связи между машинами. Статические IP назначаются автоматически в подсети 10.10.0.0/24, а /etc/hosts прописывается через cloud-init. Ничего настраивать вручную не нужно.

Для хранения данных между перезапусками есть named volumes, они живут как qcow2-файлы и не удаляются при holos down.

volumes:
  pgdata:
    size: 20G

services:
  db:
    image: ubuntu:noble
    volumes:
      - pgdata:/var/lib/postgresql

Внутри гостевой системы том появляется как /dev/disk/by-id/virtio-vol-pgdata. cloud-init сам создаёт файловую систему и прописывает /etc/fstab при первом запуске.

Основные команды:

holos up              # запустить стек
holos down            # остановить и удалить
holos ps              # список запущенных проектов
holos exec web-0      # SSH в инстанс
holos logs web        # логи сервиса
holos install --enable  # автозапуск через systemd после ребута

Для SSH holos генерирует пару ключей для каждого проекта и инжектирует публичный ключ через cloud-init. Порт пробрасывается автоматически.

Поддержка GPU passthrough

Если нужно отдать физическую видеокарту виртуальной машине:

services:
  ml:
    image: ubuntu:noble
    vm:
      vcpu: 8
      memory_mb: 16384
    devices:
      - pci: "01:00.0"
      - pci: "01:00.1"

holos сам включает UEFI (OVMF), выставляет kernel-irqchip=on для совместимости с NVIDIA и создаёт отдельное хранилище EFI-переменных для каждого инстанса. Настройку IOMMU и привязку GPU к vfio-pci нужно сделать на хосте самостоятельно — holos devices --gpu поможет найти PCI-адреса.

Что нужно на хосте

/dev/kvm, qemu-system-x86_64, qemu-img и любой из инструментов для создания cloud-init ISO: cloud-localds, genisoimage, mkisofs или xorriso.

holos это не замена Kubernetes. Он не умеет в кластеры, live migration и service mesh. Его задача — сделать KVM удобным для одного хоста без операционной сложности оркестраторов. Если вам нужен воспроизводимый стек из нескольких ВМ на одной машине, это рабочий вариант.

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

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

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

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

👨‍💻 Git 2.54: что нового

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

Экспериментальная команда git history

Появилась новая команда для переписывания истории. Пока экспериментальная, но уже умеет делать split — разбивать коммиты. Детали пока скудные, но команда явно будет развиваться.

git replay стал умнее

git replay теперь умеет три режима: pick, replay и новый revert. Плюс он научился пропускать коммиты, которые становятся пустыми после replay, и поддерживает replay вплоть до корневого коммита.

Хуки теперь можно настраивать в конфиге

Раньше хук — это скрипт в .git/hooks/. Теперь хуки можно определять прямо в конфигурации Git, в том числе централизованно. И запускать несколько хуков на одно событие. Это открывает нормальную возможность шарить хуки между командой без сторонних инструментов вроде husky.

git add -p стал удобнее

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

git status теперь сравнивает с несколькими ветками

Через конфиг status.compareBranches можно указать список веток, с которыми git status будет показывать сравнение. Удобно, если работаете с несколькими долгоживущими ветками одновременно.

git rebase получил --trailer

Новая опция позволяет добавлять трейлеры к коммитам прямо в процессе rebase. Больше не нужно делать это отдельным шагом через git interpret-trailers.

Исправления, которые стоит знать

git blame --ignore-revs с --color-lines давал неверную раскраску для соседних строк в одном коммите — починили. git log --graph --stat неправильно считал ширину цветного графика — тоже исправлено. git diff --stat путался с шириной путей, содержащих не-ASCII символы, — исправлено.

git maintenance меняет стратегию по умолчанию

Теперь по умолчанию используется стратегия geometric вместо прежней. Это влияет на то, как Git управляет packfile-ами в фоне. Если настраивали git maintenance вручную, стоит проверить, не изменилось ли поведение.

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

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

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

🪟 Windows Server 2025 быстрее работает на ARM64

Джейсон Экерт, автор учебника по Windows Server для Cengage, готовил новое издание и параллельно решил проверить: а что если запустить те же виртуальные машины не на Intel, а на Snapdragon X Elite?

Официального ISO от Microsoft для ARM64 нет, поэтому образ он собрал через UUP dump прямо с серверов обновлений. Конфигурация VM была идентичной на обоих хостах: Active Directory, DNS, DHCP, IIS, File Services, RDS и другие стандартные роли. Итог его удивил: на ARM всё работало заметно отзывчивее.

Почему ARM оказался быстрее

Дело не в архитектуре как таковой, а в характере нагрузки. Серверные роли Windows Server генерируют много мелких, частых операций с CPU и диском. Такие задачи чувствительны к задержкам и context switching. Intel Core i9 работает по принципу boost/throttle: частота резко поднимается и потом снижается под нагрузкой. Snapdragon X Elite держит стабильные часоты без скачков.

В виртуализованной среде это особенно ощутимо. Hyper-V как планировщик получает предсказуемое оборудование и распределяет время CPU между VM без лишней вариативности.

Ещё один момент: ARM64-сборка Windows Server, судя по release notes, обходится без части legacy-слоёв совместимости. Более чистый бинарник, меньше накладных расходов.

Как он это проверял

В Performance Monitor на обоих хостах добавил три счётчика:

\Processor(_Total)\% Processor Time
\System\Processor Queue Length
\Hyper-V Hypervisor Virtual Processor(*)\CPU Wait Time Per Dispatch

Нагрузку создавал через PowerShell внутри VM:

1..8 | ForEach-Object {
    while ($true) { Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 | Out-Null }
}

На Snapdragon % Processor Time почти не колебался, Processor Queue Length держался на нуле, CPU Wait Time Per Dispatch был ровным. На Intel все три метрики давали заметные всплески.

Затем он прогнал Measure-Command на реальных операциях прямо внутри VM. Для IIS:

Measure-Command { 1..1000 | foreach { Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null } }

Аналогично для DNS:

Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null

Для Active Directory:

Get-ADUser -Filter * -ResultSetSize 1 | Out-Null

Для файлового I/O:

$path = "C:\TestFiles"
mkdir $path -ea 0

Measure-Command {
    1..2000 | foreach {
        $file = "$path\file$_.txt"
        Set-Content $file "test"
        Get-Content $file | Out-Null
        Remove-Item $file
    }
}

По всем тестам Snapdragon давал стабильный результат от прогона к прогону. Intel иногда обходил его в пике, но в среднем проигрывал.

Что с этим делать

Делайте своих ИИ-агентов. У нас как раз есть курс, но на него осталось всего 4 места. Успейте до 30 апреля!

👉 Регистрация здесь

➡️ Оригинал статьи

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

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

#локализация

🔄 nxs-universal-chart 3.0

Вышла новая версия инструмента nxs-universal-chart от компании Nixys. Это универсальный Helm-чарт для деплоя приложений в Kubernetes и OpenShift.

Команды регулярно сталкиваются с необходимостью писать почти одинаковые чарты снова и снова. nxs-universal-chart решает это просто: один чарт на все случаи жизни. Каждый сервис деплоится через один и тот же чарт, а специфика настраивается через values-файлы.

Что появилось в версии 3.0

Главное изменение архитектуры: чарт переписан на базе модульных nuc-* sub-chart-ов. Они распространяются через OCI-реестр и подключаются как зависимости. Это позволяет обновлять отдельные части чарта без пересборки всего.

Добавлена поддержка Istio, KServe, KNative и Vault Secret Operator. Это делает чарт применимым не только для простых веб-сервисов, но и для AI-нагрузок и сервис-мешей.

Как попробовать:

helm repo add nixys https://registry.nixys.io/chartrepo/public
helm install my-release nixys/nxs-universal-chart -f values.yaml

Минимальный values.yaml для деплоя веб-приложения выглядит так:

deployments:
  app:
    containers:
      app:
        image: nginx
        tag: stable
        ports:
          - containerPort: 80

services:
  app:
    ports:
      - port: 80
        targetPort: 80

Если у вас в кластере больше пяти похожих сервисов, а поддержка отдельных чартов начинает утомлять — стоит посмотреть.

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

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

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

📎 Запускаем Inferno на 64-битных машинах

Inferno это распределённая операционная система, которую разработали в Bell Labs. Сегодня её развивает Vita Nuova под свободной лицензией.

Проблема была в том, что оригинальный Inferno рассчитан на 32-битные платформы. inferno64 это форк, который переносит систему на amd64 и arm64.

Что это такое

Программы для Inferno пишутся на языке Limbo — конкурентном языке с поддержкой CSP-каналов. Код компилируется в байт-код Dis, который исполняется на виртуальной машине emu. Это значит, что один и тот же код работает везде, где есть эмулятор.

Вся работа с ресурсами в Inferno идёт через файловую иерархию. Сеть, устройства, сервисы — всё открывается через обычные операции open, read, write, close. Протокол для этого тот же, что и в Plan 9 — 9P. Любой ресурс можно экспортировать по сети и подключить к пространству имён другого процесса.

Чем inferno64 отличается от оригинала

Форк фокусируется на трёх вещах: поддержка 64-битных платформ, работа JIT-компилятора для amd64 и байндинги к популярным библиотекам вроде SQLite. JIT для arm64 пока в разработке. Важный момент: dis-файлы из 64-битной версии несовместимы с оригинальным 32-битным dis.

Как собрать на Linux

Устанавливаем зависимости:

apt install libx11-dev libxext-dev linux-libc-dev

Собираем из корня репозитория:

export ROOT=<путь до inferno64>
export objtype=amd64
export PATH=$PATH:$ROOT/Linux/$objtype/bin
./makemk.sh
mk mkdirs
mk install

После сборки в Linux/amd64/bin появятся бинарники mk, iyacc, limbo и emu, а также весь скомпилированный dis-код. Запускаем эмулятор:

emu
; wm/wm&

Пахнет ли здесь ИИ? Возможно, но даже так это отличный форк. Делайте своих ИИ-агентов на нашем курсе и переписывайте старое ПО на новый лад. Осталось всего 4 места. Набор закрывается 30 апреля.

🔗 Успеть на обучение

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

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

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

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