😅 Профдеформация

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

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

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

🔄 61 версия бутылок

Команда Bottles выпустила версию 61, и главный акцент релиза — это новый анализатор Eagle, который разбирает exe и инсталляторы до запуска и сразу показывает, какие технологии и зависимости вам нужны.

Eagle встроен прямо в Bottles и включается, когда вы выбираете файл для запуска. Вместо простого старта он делает многошаговый разбор двоичного файла определяет тип инсталлятора, применённые технологии и возможные проблемы под Wine и Proton.

Анализ не замыкается на одном файле Eagle берёт в расчёт соседние объекты в том же каталоге, DLL и вспомогательные файлы, но старается не тонуть в хаосе вроде забитой папки загрузок.

По части технологий Eagle умеет распознавать популярные стеки и рантаймы: .NET Framework и .NET Core, Java, Qt, WPF, Electron включая разбор ASAR архивов для десктопных приложений.

➡️ Источник

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

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

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

⚡️ Хакеры атаковали святое

Разработчик Notepad++ раскрыл детали компрометации сервера обновлений. Сервер хостинга взломали в июне 2025. Атакующие сохранили доступ до 2 сентября, а потом использовали украденные учетки до 2 декабря для подмены ссылок на обновления.

Провайдер заметил подозрительное после миграции клиентов 1 декабря и обновил ядро сервера 2 сентября, что отрезало прямой доступ. Логи показали, что целились только в Notepad++, эксплуатируя слабую проверку обновлений в старых версиях.

Эксперты связывают атаку с китайской государственной группой из-за выбора жертв.

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

Уроки для девопсов:

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

• Отслеживайте журналы трафика и аномалии в перенаправлениях. Смена ключей и проверка учётных записей обязательны после подозрений.

• Переходите к защищённому поставщику своевременно. Для IT-специалистов это напоминание: атаки на цепочку поставок бьют по популярному ПО, даже если код чистый.

➡️ Источник

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

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

#разбор_полётов

💻 Синхронизация истории командной строки

Atuin — утилита для замены стандартной истории shell. Хранит команды в SQLite, синхронизирует между машинами и даёт мощный поиск.

Основные фичи:

• Фильтры по директории, дате, статусу выполнения

• История везде одна благодаря синхронизации

• Статистика — какие команды используете чаще, время выполнения

• Данные зашифрованы end-to-end

Установка:

bash <(curl --proto '=https' --tlsv1.2 -sSf https://setup.atuin.sh)

atuin
 register -u <USERNAME> -e <EMAIL>
atuin
 import auto
atuin
 sync

Команды:

• Посмотреть статистику: atuin stats

• Синхронизировать: atuin sync + --force для принудительного синка

• Экспорт в файл: atuin export > backup.txt

➡️ Официальный сайт

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

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

#разбор_полётов

💻 Linux From Scratch отказывается от SysVinit

Проект Linux From Scratch (LFS) и Beyond Linux From Scratch (BLFS) прекращают поддержку System V Init в будущих версиях Phoronix. Начиная с LFS 13.0, который ожидается 1 марта 2026, останется только systemd.

Причины отказа

1. Двойная нагрузка на мейнтейнеров. Каждый пакет нужно проверять для обеих init-систем при подготовке релиза.

2. Жёсткие зависимости. GNOME и скоро KDE Plasma встраивают требования, которые нуждаются в возможностях systemd, отсутствующих в System V.

«Как личное замечание — мне не нравится это решение» — написал автор анонса. Решение продиктовано не идеологией, а практическими ограничениями.

Прагматизм победил принципы. Малочисленная команда LFS не может поддерживать две init-системы в условиях растущей экосистемы Linux.

➡️ Анонс

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

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

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

🧑‍💻 Диагностика сетевых проблем

Когда серверы становятся недоступными, это немедленно влияет на все сервисы, пользователей и бизнес. Сетевая связность — это не одна система, а стек взаимодействующих слоёв: от физических интерфейсов до маршрутизации, firewall, DNS и прикладных протоколов.

Проблема может находиться на любом из этих уровней, и симптомы часто не указывают прямо на причину. Добавьте облачную инфраструктуру с виртуальными сетями, security groups, load balancers — и картина становится ещё сложнее.

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

Модель OSI в практике DevOps

Теоретическая модель OSI с семью уровнями в реальной практике упрощается до ключевых проверок:

Уровень 1-2: Физика и канал

• Состояние интерфейсов (UP/DOWN)
• Физическое соединение
• Ошибки передачи пакетов

Уровень 3: Сетевой

• IP адресация
• Маршрутизация
• ICMP связность

Уровень 4: Транспортный

• Firewall правила
• Фильтрация пакетов
• NAT и security groups

Уровень 5-7: Прикладной

• DNS резолвинг
• Доступность портов
• Логика приложения

Систематический подход

Золотое правило: двигайтесь снизу вверх. Не имеет смысла проверять DNS, если сетевой интерфейс в состоянии DOWN. Не тестируйте приложение, если базовая IP связность не работает.

Каждый уровень зависит от нижележащих. Проверили физику → проверили IP → проверили firewall → проверили DNS → проверили приложение. Только так можно быстро локализовать проблему.

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

Базовый набор:

• ip — управление интерфейсами, адресами, маршрутами
• ping — базовая проверка связности
• nc — тестирование TCP/UDP портов
• dig — DNS диагностика
• tcpdump — захват трафика

Системные:

• systemctl — управление сервисами
• journalctl — просмотр логов
• iptables / firewall-cmd — firewall

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

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

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

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

🤩 Terragrunt 1.0 RC1

Разработчики Terragrunt уже на финишной прямой. Terragrunt — это обёртка над Terraform, которая устраняет дублирование конфигов, управляет remote state и зависимостями модулей.

Что в первом релиз-кандидате

Terragrunt перестроили под масштабируемость. Новый CLI упрощает команды, фильтр заменяет семь флагов вроде -terragrunt-include-dir. Stacks группируют связанные модули Terraform в единый деплой. Runner Pool ускоряет параллельные запуски, улучшает обработку ошибок.

В 1.x не сломается ничего критичного. Стабильны флаги CLI, HCL-конфиги, вывод find и reports.

RC1 — шанс повлиять на Terragrunt 1.0. Тестируйте stacks и runner pool в реальных воркфлоу.

➡️ Анонс

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

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

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

📌 Ядерная кнопка для зависших подов

Иногда под зависает в состоянии «завершается» из-за проблем с монтированием тома и не уходит часами. В этот момент обычное удаление через kubectl delete pod уже не помогает.

В таких случаях можно использовать более жестокий вариант:

kubectl delete pod <имя-под> --grace-period=0 --force

--grace-period=0 говорит Kubernetes не ждать стандартный terminationGracePeriodSeconds и не давать контейнеру время на мягкое завершение.

--force просит сервер API немедленно убрать объект под из etcd.

Объект под удаляется из API сразу, но сам контейнер на узле может ещё какое-то время жить, пока kubelet не добьёт его.

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

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

#root_prompt

👨‍💻 Дебаг на физическом и канальном уровне

➡️ Первая часть

Первое, что нужно проверить — сами сетевые интерфейсы. Даже в виртуализированной среде они могут оказаться в состоянии DOWN из-за проблем с драйверами, ошибок конфигурации или сбоев гипервизора.

ip link show — проверка состояния интерфейсов:

ip link show

Ищите строку с state UP — интерфейс активен и готов передавать данные. Если видите state DOWN, проблема на этом уровне.

Что означает DOWN:

• Физические серверы: отсоединённый кабель, неисправный порт коммутатора, проблемы с сетевой картой.

• Виртуальные машины: проблема с виртуальным свитчем, неправильная привязка к VLAN, ошибки в конфигурации гипервизора.

Счётчики ошибок

ip -s link show eth0

Флаг -s показывает статистику. Смотрите на поля:

•errors — ошибки при передаче/приёме
dropped — отброшенные пакеты/нехватка буферов
overruns — переполнение буфера приёма
collisions — коллизии на старых half-duplex

Если эти значения растут — проблемы с передачей пакетов.

ethtool — детальная диагностика

ethtool eth0

Показывает:

• Link detected: yes/no — есть ли физический линк
• Speed — текущая скорость (1000Mb/s, 10000Mb/s)
• Duplex — full или half
• Auto-negotiation — включено ли автосогласование

Если Link detected: no, но интерфейс UP — физический линк отсутствует. Проверяйте кабель, порт коммутатора.

ARP таблица:

ip neighbour show
# или старый вариант:
arp -n

ARP связывает IP адреса с MAC адресами в локальной сети. Если для вашего gateway нет записи или она в состоянии FAILED — система не может определить MAC адрес шлюза.

Очистка ARP кеша:

ip neighbour flush all

Дальше разберём проблемы маршрутизации.

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

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

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

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

DevOps-инженер — от 180 000 с гибридом в Москве или на удалёнку.

MLOps\DevOps — удалёнка.

DevOps-инженер — от 250 000 ₽ на удалёнку.

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

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

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

🤩 Чей сетап?

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

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

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

💡 Диагностика сети: IP связность и маршрутизация

➡️ Предыдущая часть

Проверка базовой связности

Интерфейсы UP, ошибок нет — переходим к проверке IP связности. Команда ping — простой и эффективный тест:

ping 8.8.8.8

Google DNS 8.8.8.8 — хороший выбор для теста: стабильный, быстрый, разрешает ping. Если работает — базовая связь с интернетом есть. Если нет — копаем глубже.

Таблица маршрутизации

ip route show

Таблица маршрутизации определяет, куда система отправляет пакеты для разных сетей. Критичная запись — default gateway или маршрут по умолчанию:

default via 10.0.0.1 dev eth0

Это означает: все пакеты для неизвестных сетей отправляются через шлюз 10.0.0.1 на интерфейсе eth0.

Если этой записи нет — связь с внешним миром невозможна. Система не знает, куда отправлять пакеты.

Проверка default gateway

Убедитесь, что gateway находится в той же подсети, что и IP адрес интерфейса:

ip addr show eth0

Если IP 10.0.0.50/24, а gateway 10.0.1.1 — это конфликт. Маска /24 означает подсеть 10.0.0.0-10.0.0.255, gateway за её пределами.

Тестирование шлюза:

ping 10.0.0.1

Пингуем сам gateway. Это локальная сеть, должно работать. Если не работает:

1. Проблема с физической связностью (вернитесь к посту #2)
2. Проблема с ARP (проверьте ip neighbour show)
3. Шлюз недоступен или выключен

Проблемы с ARP:

ip neighbour show

Ищите запись для gateway IP. Должна быть строка типа:

10.0.0.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Состояния ARP:
- REACHABLE — всё хорошо
- STALE — запись старая, но рабочая
- FAILED — не удалось определить MAC адрес
- INCOMPLETE — процесс определения не завершён

Если FAILED — gateway не отвечает на ARP запросы. Возможно, он выключен или есть проблемы на L2.

Специфичные маршруты

Кроме default gateway могут быть статические маршруты для конкретных сетей:

ip route show
10.20.0.0/16 via 10.0.0.5 dev eth0

Это говорит: для сети 10.20.0.0/16 используй другой шлюз — 10.0.0.5. Ошибка в таком маршруте может сломать связность с конкретным сегментом инфраструктуры.

Добавление маршрутов вручную

Временно (до перезагрузки):

ip route add default via 10.0.0.1 dev eth0
ip route add 10.20.0.0/16 via 10.0.0.5

Удаление маршрута:

ip route del 10.20.0.0/16

Для постоянных маршрутов редактируйте конфигурацию сети в /etc/sysconfig/network-scripts/route-eth0 (RHEL) или netplan конфиг (Ubuntu).

Traceroute — путь до цели:

traceroute 8.8.8.8

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

Если traceroute зависает на определённом хопе — проблема там. Если все хопы показывают * * * — ICMP блокируется firewall.

mtr — улучшенный traceroute:

mtr 8.8.8.8

Комбинация ping и traceroute. Показывает latency и packet loss на каждом хопе в реальном времени. Более информативно, чем обычный traceroute.

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

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

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

🚀 9 способов найти заказы без бирж

Малый бизнес до сих пор не знает, где искать разработчиков. Кто-то спрашивает у знакомых, кто-то ищет на Авито, кто-то пишет в Telegram-чатах. Будьте на их пути — и первые заказы найдутся сами.

➡️ Самые топовые способы в статье

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

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

🤨 Прошу, прочти конфиг

Классическая ситуация: вы правите конфиг, применяете изменения, проверяете логи — а там всё по-старому. Приложение просто не знает, что конфигурация изменилась.

Когда под стартует, он монтирует ConfigMap как volume. Kubernetes обновляет содержимое этого volume автоматически, но:

• Большинство приложений читают конфиг один раз при запуске

• Они не следят за изменениями файлов

• Перечитывание конфига в рантайме — это дополнительная логика, которую надо реализовывать

Команда, чтобы конфиг точно перечитался:

kubectl rollout restart deployment <deployment-name>

Никакой магии — просто обычный rolling update, но без изменения версии образа.

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

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

#root_prompt

⚙️ top для systemd

systemd-cgtop — это инструмент из systemd для просмотра топа control groups по использованию CPU, памяти и I/O. Он обновляется каждую секунду и похож на классический top, но фокусируется на группах процессов.

Что показывает top:

PID  USER     CPU%  MEM%  COMMAND
1234 www-data 45.0  12.3  /usr/bin/php-fpm
5678 www-data 32.1  8.7   /usr/bin/php-fpm

Что показывает cgtop:

Control Group          Tasks  %CPU  Memory
/system.slice/nginx     12    78.2  2.1G
/system.slice/postgresql 8    23.4  1.8G
/system.slice/redis      4    12.1  512M

Разница критична: nginx может порождать сотни worker'ов, и в top вы увидите хаос из процессов. В systemd-cgtop — одна строка с суммарным потреблением.

Примеры команд:

# Что тормозит сервер?
systemd-cgtop --order=cpu

# Кто съел всю память?
systemd-cgtop --order=memory

# Кто нагружает диск?
systemd-cgtop --order=io

# Следить только за веб-сервисами
systemd-cgtop | grep -E '(nginx|apache|php)'

Полезные клавиши

В интерактивном режиме:

• p / t / c / m / i — сортировка по path/tasks/cpu/memory/io
• % — показать CPU в процентах или абсолютных значениях
• + / - — развернуть/свернуть дерево cgroups
• q — выход

Если вы используете systemd и хотите понять, какой сервис потребляет ресурсы, а не тонуть в списке процессов — systemd-cgtop ваш инструмент.

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

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

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

❓ Вопрос с собеса

На собесах спрашивают про лимиты памяти в контейнерах, и знать про --memory хорошо, но нужно вспомнить про --memory-swap.

Вопрос:

Как работает memory-swap в Docker?

Ключевой момент: swap — это не дополнительная память, а ответ в канале с вопросами

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

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

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

🛠 Новый уровень контроля готовности узлов в k8s

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

• Сетевые агенты и CNI-плагины
• Драйверы систем хранения (CSI)
• GPU-драйверы и специализированная прошивка
• Кастомные health-проверки и мониторинг агенты

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

Node Readiness Controller вводит декларативный механизм управления node taints на основе кастомных условий готовности. Контроллер работает с API NodeReadinessRule, который позволяет определить специфические требования для разных типов узлов.

Коротко о возможностях:

• Автоматическое управление node taints на основе кастомных условий

• Два режима: постоянный контроль или только при инициализации

• Интеграция с Node Problem Detector и кастомными health-check агентами

• Разные правила готовности для разных типов узлов: GPU, storage, standard

• Декларативная настройка через Kubernetes API

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

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

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

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

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

👨‍💻 Дебаг файрволла и фильтрация пакетов

➡️ Предыдущая часть

Маршрутизация настроена правильно, ping gateway работает, но связь всё равно не работает. Вероятно, виноват файрволл. Он может молча блокировать пакеты, не оставляя очевидных следов.

Linux может использовать несколько систем: iptables, nftables, firewalld.

iptables — классическая система:

iptables -L -n -v

Флаги:

-L — list, показывает правила
-n — numeric, не резолвит имена
-v — verbose, показывает счётчики пакетов

Вывод показывает три основные цепочки:

- INPUT — входящие пакеты
- OUTPUT — исходящие пакеты
- FORWARD — транзитные (для маршрутизатора)

Политика по умолчанию:

Chain INPUT (policy DROP)

Policy DROP — всё блокируется по умолчанию, разрешено только то, что явно указано в правилах выше. Безопасно, но легко сломать связность.

Policy ACCEPT — всё разрешено по умолчанию, блокируется только указанное. Менее безопасно, но проще в отладке.

iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1523 128K DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Смотрите на колонку pkts (packets). Если правило с DROP/REJECT показывает большое количество — оно активно блокирует трафик.

В примере выше: 1523 пакета на порт 22 (SSH) были отброшены.

Временное отключение файерволла:

iptables -F  # Очистить все правила
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Если после этого всё заработало — проблема точно в правилах. Восстановите их и ищите конкретное блокирующее правило.

firewalld — современная альтернатива:

firewall-cmd --list-all

Показывает активную зону и все правила в ней. Firewalld работает с концепцией зон: public, internal, trusted, dmz и т.д.

Проверьте:

- Какая зона активна для вашего интерфейса
- Какие сервисы разрешены в этой зоне
- Какие порты открыты

Какие зоны активны и на каких интерфейсах:

firewall-cmd --get-active-zones

Добавление правил firewalld

Разрешить сервис (HTTP):

firewall-cmd --add-service=http --permanent
firewall-cmd --reload

Разрешить порт:

firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload

Флаг --permanent делает правило постоянным. Без него — только до перезагрузки firewalld.

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

iptables:

iptables -I INPUT -j LOG --log-prefix "DROPPED: "

Теперь все отброшенные пакеты будут логироваться в /var/log/messages с префиксом "DROPPED:".

firewalld:

firewall-cmd --set-log-denied=all

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

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

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