Лига сисадминов

Автоматизация обновлений хостов с rootless Docker при помощи Ansible Запуск apt upgrade на хостах с rootless Docker-сервисами может все сломать. Из-за расхождения версий между запущенным пользовательским демоном и только что обновленными системными бинарниками контейнеры падают при перезапуске. В этом посте делюсь Ansible-плейбуком, который находит изменения в критически важных пакетах и автоматически перезапускает только нужные rootless-демоны пользователей, избавляя от даунтайма и ручного вмешательства. https://telegra.ph/Avtomatizaciya-obnovlenij-hostov-s-rootless-Docker-pri-pomoshchi-Ansible-07-04 #ит_статьи #devops #docker #rootless #ansible #automation

BPF CPU Scheduler: не нравится стандартный планировщик в Linux? Напиши свой В статье расскажем про относительно новую возможность написания собственных CPU планировщиков для Linux с помощью BPF. Разберёмся, для чего это нужно, как работает, а также посмотрим на примеры уже написанных планировщиков. https://telegra.ph/BPF-CPU-Scheduler-ne-nravitsya-standartnyj-planirovshchik-v-Linux-Napishi-svoj-07-03 #ит_статьи #linux #kernel #cpu #ebpf

Уязвимости есть у всех. А патчи? Уязвимости в виртуализации есть у всех. У VMware, Hyper-V, Proxmox, oVirt, российских платформ, open source и проприетарных решений. Интереснее другое: что происходит после того, как уязвимость нашли? Можно ли получить патч? Понятно ли, как быстро вендор реагирует? Есть ли публичный changelog, bug bounty, нормальный канал для исследователей? Или безопасность заканчивается на пресс-релизе и фразе «все устранено, твёрдо и чётко»? Отдельно нельзя не упомянуть российскую виртуализацию, которая за последние годы успела обрасти плотным слоем маркетинга. И в чьей среде самый простой способ испортить разговор: спросить не «чья платформа отечественнее», а «как вы закрываете уязвимости?». Причём после ухода VMware этот вопрос стал особенно актуальным для всех. Потому что оставаться на старой версии рискованно, но и переходить на новое отечественное решение вслепую тоже такое себе. Сначала хотел запилить большой разбор про риски ушедших иностранных платформ, патчи под санкциями и прозрачность наших вендоров, но наткнулся на статью на Хабре, где автор уже прошелся примерно по этим же вопросам. Тут автор тоже попытался понять не кто лучше, а кому в этой истории можно доверить инфраструктуру. https://habr.com/ru/articles/1037318/

Альтернативный способ управления Proxmox без веб-интерфейса На днях я наткнулся на утилиту под названием pvectl, которая помогает эффективнее управлять кластерами Proxmox прямо из командной строки с помощью TUI (текстового пользовательского интерфейса). Несмотря на то, что в Proxmox уже встроены мощные консольные утилиты вроде qm, pct, pvesh, pvesm и другие, вам все равно нужно держать в голове их названия и параметры. Инструмент pvectl как раз закрывает этот пробел и дает возможность управлять системой из CLI Proxmox, не зазубривая синтаксис. Мне кажется, здорово иметь такую золотую середину между тем, что можно делать в веб-интерфейсе, и обычной командной строкой. Давайте посмотрим, как это работает. https://telegra.ph/Alternativnyj-sposob-upravleniya-Proxmox-bez-veb-interfejsa-07-02 #ит_статьи #devops #linux #proxmox #pvectl

Я отключил IPv6 на домашнем роутере, и моя сеть снова летает На прошлой неделе я отключил IPv6 на своем домашнем роутере, и сеть снова стала работать быстро. На первый взгляд, это абсолютно банальное админское решение, которое принимают миллионы людей. Я пошел на это, потому что IPv6 - одна из тех тем, где у каждого есть свое веское мнение, но никто не может толком объяснить, почему. Ладно, какую проблему я вообще пытался решить? Давайте посмотрим ретроспективу... https://telegra.ph/YA-otklyuchil-IPv6-na-domashnem-routere-i-moya-set-snova-letaet-07-01 #ит_статьи #networks #nat #ipv6 #ipv4 #routing

Хорошо, что git всё таки есть (да и вообще svn) #ит_юмор #git

SSH-сертификаты: переходим на правильный SSH Когда я впервые подключаюсь к серверу по SSH, я сталкиваюсь с диалоговым окном, в котором меня просят подтвердить, что я действительно общаюсь именно с той машиной, с которой планировал.

$ ssh -l jp 192.0.2.65
The authenticity of host '192.0.2.65 (192.0.2.65)' can't be established.
ED25519 key fingerprint is SHA256:4WTRnq2OR1m03TpnHCfkFdlh1gN/PBXE4vDi0WnjFEc.
No matching host key fingerprint found in DNS.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Скорее всего, большинство пользователей просто скрещивают пальцы и вводят «yes», что, вообще-то, не самое умное решение. Этот принцип - «доверие при первом использовании» (TOFU, Trust on First Use) - как раз и позволяет SSH гарантировать, что мой SSH-клиент проверяет, с каким сервером он связывается. По-хорошему, мне следовало бы попросить администратора сервера прислать мне его фингерпринт (отпечаток ключа). А если администратор - это я сам, то мне нужно знать, как его получить (в следующих примерах приглашение командной строки % означает, что я работаю под root):

% ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
256 SHA256:4WTRnq2OR1m03TpnHCfkFdlh1gN/PBXE4vDi0WnjFEc root@d13 (ED25519)

Если два отпечатка совпадают, я могу быть уверен, что подключаюсь к правильному серверу, и могу продолжить, введя «yes», либо вставить известный отпечаток хоста прямо в консоль. Все, доверие при первом использовании установлено. (Утилиты вроде ssh-keyscan собирают публичные ключи с удаленных хостов, но мне все равно следовало бы перепроверить через независимый канал связи, с той ли машиной я общаюсь. Отпечатки SSH также могут находиться в DNS - но это уже совсем другая история.) Затем сессия, возможно, продолжается тем, что у меня запрашивают пароль целевого пользователя. Если я ввожу его правильно, мне предоставляется доступ к машине. Это стандартный подход, который знают все. Но мало кто использует встроенный в OpenSSH механизм сертификатов (SSH CA). Он позволяет раз и навсегда забыть про ручное копирование публичных ключей и подтверждения TOFU, заменяя их изящной и безопасной автоматикой. https://telegra.ph/SSH-sertifikaty-perehodim-na-pravilnyj-SSH-06-30 #ит_статьи #devops #linux #openssh #ssh #security

pyinfra - infrastructure automation на Python pyinfra превращает Python-код в shell-команды и гоняет их по серверам. По сути - это «Ansible, только на Python вместо YAML, и заметно быстрее». Agentless, работает поверх SSH/Docker/local, декларативные операции идемпотентны, есть diff и dry-run. Заявленные плюсы проекта: - Высокая скорость: параллельное выполнение на тысячах хостов и предсказуемая производительность (по бенчмаркам ближе к Fabric, чем к Ansible). - Python вместо YAML: полноценная логика, импорты, тесты, типизация и отладка через pdb вместо громоздких Jinja-шаблонов. - Идемпотентность: декларативные операции проверяют текущее состояние системы и применяют только необходимые изменения (диффы), также доступен режим предварительной проверки (--dry). - Удобная отладка: вывод stdin, stdout и stderr в реальном времени с помощью флага -vvv без скрытых или перехваченных колбэков. - Готовые коннекторы: встроенная поддержка SSH, Docker, Terraform, Vagrant и локального выполнения (@local) из коробки. - Простая расширяемость: возможность использовать любые сторонние Python-пакеты, а также легко создавать собственные операции и коннекторы. Пример работы: inventory.py:

targets = ["@docker/ubuntu", "my-test-server.net"]

deploy.py:

from pyinfra.operations import apt, files, systemd

apt.packages(
    name="Установить nginx",
    packages=["nginx"],
    update=True,
    _sudo=True,
)

files.put(
    name="Залить конфиг",
    src="files/nginx.conf",
    dest="/etc/nginx/nginx.conf",
    _sudo=True,
)

systemd.service(
    name="Рестарт nginx",
    service="nginx",
    running=True,
    restarted=True,
    _sudo=True,
)

Запуск:

pyinfra inventory.py deploy.py          # применить
pyinfra inventory.py deploy.py --dry    # только показать diff

Ad-hoc без файлов тоже работает:

pyinfra my-server.net exec -- uptime
pyinfra @docker/ubuntu apt.packages iftop update=true _sudo=true

Короткое сравнение

- vs Ansible — Python вместо YAML/Jinja2, быстрее (нет Python-на-каждом-хуке), прозрачнее (реальный stdout), меньше «магии». Из коробки нет богатой коллекции ролей Galaxy.
- vs Fabric — у pyinfra есть состояние/идемпотентность и сухой прогон, Fabric — это чисто ad-hoc.
- vs Salt/Puppet/Chef — agentless, без мастер-сервера, конфиг — просто Python-репозиторий.

---

Когда брать

- Небольшая–средняя инфраструктура, где Ansible-плейбуки уже превращаются в нечитаемый YAML-спагетти.
- Нужен CI/CD-pipeline как код с тестами (pytest поверх деплоев).
- Смешанные цели: SSH-серверы + Docker-контейнеры + локальная машина в одном прогоне.
- Хочется скорости и нормального логирования без настройки callback-плагинов.

3 месяца подготовки к собеседованию Ansible — в одном чек-листе🔥 Забирай бесплатный чек-лист, в котором: 👉 пошаговый план обучения на 3 месяца 👉 темы от Junior до Senior уровня 👉 реальные вопросы с собеседований крупных IT-компаний 👉 список навыков, которые ждут от DevOps-инженера в 2026 году Переходи в бота, скачивай материал и проверь, насколько ты уже близок к офферу

Как GNU Tar обрабатывает удаленные объекты в инкрементных tar-архивах Предположим, что у вас есть система, которая использует GNU Tar для полных и инкрементных резервных копий. Или, может быть, вы используете GNU Tar для этого напрямую. Если у вас есть инкрементный tar-архив, вас могут интересовать один или оба вопроса, которые в некотором смысле зеркально отражают друг друга: какие файлы были удалены между предыдущим инкрементом и этим, или каково состояние дерева каталогов на момент этого инкремента (если он и все предыдущие бэкапы, от которых он зависит, были правильно восстановлены). (Эти вопросы глубоко волнуют людей, которые могли удалить какое-то количество файлов, но не уверены точно, какие именно файлы были удалены.) Обработка удаленных файлов - одна из проблем инкрементного резервного копирования, и подходы к ней бывают разными. То, как GNU Tar справляется с удаленными файлами, отчасти задокументировано в разделах "Using tar to perform incremental dumps" и "Dumpdir", но документация не объясняет это предметно. Если упростить, то GNU Tar не записывает удаления явно. Вместо этого каждый инкрементный tar-архив содержит полный список дерева каталогов, который включает как объекты, находящиеся в этом инкрементном архиве, так и те, что пришли из предыдущих. Чтобы вычислить удаленные файлы, вам нужно сравнить два списка дерева каталогов. (В рамках этого полного списка инкрементный tar-архив записывает каждый каталог, даже неизмененный.) Вы можете получить эти полные списки с помощью команды tar --list --incremental --verbose --verbose --file ..., но tar выводит их в неудобном формате. Вы не получаете дерево каталогов в том виде, в каком его выдает обычный tar -t. Вместо этого вы получаете содержимое Dumpdir для каждого каталога, напечатанное отдельно, и вам придется самостоятельно обрабатывать результаты, чтобы собрать дерево каталогов с полными путями и так далее. Люди, вероятно, писали инструменты для этого - либо на основе вывода tar, либо путем прямого чтения формата инкрементного архива GNU Tar. На мой взгляд, подход GNU Tar вполне разумен и обладает некоторыми полезными свойствами (хотя тут есть свои компромиссы). Что удобно, вы можете восстановить полное дерево каталогов на этот конкретный момент времени из любого отдельного инкрементного архива - вам не нужно проходить через всю цепочку, чтобы собрать общую картину. Это также, вероятно, делает систему несколько более устойчивой, если вы утеряли часть инкрементных архивов где-то в середине: по крайней мере, вы знаете, что там должно быть, пусть у вас и нет копий этих файлов. Поиск момента, когда был удален один конкретный файл, происходит лучше, чем если бы существовали явные записи об удалении, так как вы можете запустить бинарный поиск по инкрементам, чтобы найти первый, где этот файл исчезает. Отсутствие явных отчетов об удалении действительно делает неудобным определение всего, что было удалено между двумя последовательными инкрементами, но с другой стороны, вы можете определить, что было удалено (или добавлено) между любыми двумя tar-архивами, без необходимости просматривать каждый инкремент между ними. (Можно сказать, что инкрементные архивы GNU Tar содержат снимок состояния дерева каталогов, вместо того чтобы вести журнал изменений этого состояния.) #ит_статьи #linux #devops #bash #tar #backup

Друзья! Спешим поделиться вышедшим на днях RQR (Russia Quality Report 2026) — крупнейшим исследованием рынка обеспечения качества в России. Это уникальный материал, выпускающийся раз в год, не имеющий аналогов в России. В данном аналитическом обзоре рынка тестирования вы можете узнать про приоритеты рынка, кто востребован на нем сегодня и будет в ближайшем будущем, какую роль играет ИИ в QA-процессах и многое другое.     Скачать Russia Quality Report 2026 можно тут https://www.performance-lab.ru/rqr

Кто-нибудь, остановите этот бесконечный цикл синков ради синков... 🥲 #ит_юмор #agile #scrum

Автоматизация создания виртуалок Ubuntu с помощью libvirt (KVM/QEMU) и Cloud-Init Бывало такое, что вам нужно было быстро развернуть сразу несколько виртуальных машин Ubuntu для тестов, разработки или учебы? В этом посте разберём один крайне полезный bash-скрипт, который полностью автоматизирует этот процесс с помощью libvirt/KVM и cloud-init. https://telegra.ph/Avtomatizaciya-sozdaniya-virtualok-Ubuntu-s-pomoshchyu-libvirt-KVMQEMU-i-Cloud-Init-06-28 #ит_заметки #devops #linux #kvm #qemu #libvirt #bash

Linux Bridge против Open vSwitch в Proxmox VE Proxmox VE поддерживает два варианта работы с сетью: Linux Bridge и Open vSwitch. Linux Bridge идет по умолчанию, а для работы с Open vSwitch нужно будет доустановить пакет openvswitch-switch. Если вы планируете использовать VLAN как для сети хранения данных хоста, так и для виртуальных машин (ВМ), Open vSwitch становится более интересным выбором. В этой заметке я разберу проблемы, с которыми можно столкнуться при использовании Linux Bridge в Proxmox VE для такого сценария. https://telegra.ph/Linux-Bridge-protiv-Open-vSwitch-v-Proxmox-VE-06-28 #ит_статьи #devops #linux #network #openvSwitch #linuxbridge #vlan

Наконец-то нормальная шпаргалка, а не вот эти вот "топ 10 команд в терминале, которые обязан знать каждый линуксоид" #ит_юмор #linux #shell #cheatsheet

Конкурентность, параллелизм и асинхронность: три концепции, которые звучат одинаково, но значат разное Каждый системный администратор слышал эти три слова. Большинство использовало их в одном предложении. Многие считают их синонимами. Но конкурентность, параллелизм и асинхронное программирование - это три совершенно разные концепции. Если их путать, это приводит к реальным сбоям, ошибкам в архитектуре систем и проваленным собеседованиям. В этой статье мы разберем каждую концепцию по косточкам, соберем заново с нуля и покажем, когда и почему вам стоит выбирать один подход вместо другого. В статье обойдёмся без длинных портянок кода, сфокусируемся именно на фундаментальной логике и архитектурных принципах работы систем. https://telegra.ph/Konkurentnost-parallelizm-i-asinhronnost-tri-koncepcii-kotorye-zvuchat-odinakovo-no-znachat-raznoe-06-27 #ит_статьи #performance #architecture #async #concurrency #hardware

«Под капотом: мультиклауд» — облачный митап от MWS Cloud Platform 📅 16 июля 📍 Москва, Лесная ул., 20, стр. 3 Крыша «Депо на Лесной» 💰 Бесплатно, но требуется регистрация Что разберём: • Мультиклауд: мифы, реальность, прикладные сценарии. • Архитектуры: бэкапы, сети (VPN / Interconnect), Disaster Recovery, IAM, аудит, IaC • Terraform-провайдер MWS: генерация из OpenAPI, качество, Open Source Спикеры — руководитель продуктового направления, архитектор и ведущий разработчик MWS Cloud Platform. Вход бесплатный, но требуется регистрация и её подтверждение — количество мест ограничено Регистрация — по ссылке

Запуск microVM в Proxmox VE: простой путь Я годами гоняю смешанный кластер Proxmox - четыре ноды совершенно разной мощности: от Atom x5-Z8350 с 2 ГБ оперативки до i7-12700 со 128 ГБ. В этом году мне изрядно надоел вечный компромисс между LXC-контейнерами и полноценными виртуалками. В итоге я нашел pve-microvm - пакет для Debian, который добавляет тип машины microvm от QEMU в Proxmox VE как полноценную, управляемую гостевую систему. Сейчас он поставляется с кастомным ядром, патчит Perl-скрипты Proxmox изнутри для интеграции прямо в веб-интерфейс, и поддерживает аж 21 тип гостевых ОС - от Debian до NetBSD и Plan9. https://telegra.ph/Zapusk-microVM-v-Proxmox-VE-prostoj-put-06-26 #ит_статьи #devops #proxmox #kvm #microvm #qemu #homelab

🎙 Расскажем все о новом релизе SafeMobile 16.0 персонально каждому! На встрече разберем и планируем показать новое в управлении Android и Аврора, новые возможности SMAPI, обновленный АРМ, который стал основным интерфейсом работы.

Кроме того, технический директор и главный пресейл SafeMobile расскажут: 🔹Как удаленно управлять устройствами без участия пользователя и быстрее решать обращения сотрудников. 🔹 Как новые возможности AppConfig, OEMConfig и push-механизмов помогают эффективнее управлять корпоративными приложениями. 🔹 Про новые возможности ролевой модели администраторов. 🔹Как узнать о входящем вызове в корпоративном мессенджере, если на вашем Android устройстве нет сервисов Google. 🔹 Какие ещё изменения вошли в релиз SafeMobile 16.0 и как получить от них максимальную пользу.

Вопросы приветствуются! Самым любознательным обещаем летний, очень полезный приз! 🚀 30 июня, 11:00 При регистрации на вебинар участие бесплатное! Реклама. ООО "НИИ СОКБ Центр разработки". ИНН 7724394592. erid: 2W5zFGKsq9b

Sencho, возможно, именно тот инструмент управления Docker Compose, которого так ждали домашние лаборатории Docker Compose - по-прежнему один из моих любимых способов запуска приложений в домашней лаборатории. Он простой, понятный, легко читается человеком и позволяет разворачивать приложения быстро и без лишней суеты. Даже несмотря на всю крутость Kubernetes, есть что-то приятное в обычном файле Docker Compose, который может поднять весь ваш стек приложений - хоть дома, хоть в продакшене. Я перепробовал кучу инструментов в своей лабе и протестировал ОГРОМНОЕ количество проектов. Недавно я наткнулся на проект под названием Sencho. Это платформа управления Docker Compose с открытым исходным кодом, в которой есть фичи, каких я раньше не видел. И это действительно свежий взгляд на управление вашими стеками Docker Compose. Потестировав ее, я думаю, что этот проект определенно стоит попробовать в вашей собственной лаборатории и понаблюдать за его развитием. Давайте разберем детали. И сразу спойлер: черт возьми, она хороша! https://telegra.ph/Sencho-vozmozhno-imenno-tot-instrument-upravleniya-Docker-Compose-kotorogo-tak-zhdali-domashnie-laboratorii-06-25 #ит_статьи #devops #docker #docker_compose #homelab #sencho