Библиотека devops’а

🔄 Последний Linux 6 версии Линус Торвальдс выпустил стабильный релиз Linux 6.18. Это последняя версия 6.x, следующий релиз будет 7.0. Ничего страшного не случилось, просто пофиксили баги. Что починили и улучшили • Улучшили драйверы ice и enetc • Поправили микрофоны на Acer и HP ноутбуках. • btrfs и ceph не крашатся из-за утечек памяти. • nouveau и AMD display работают лучше ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека 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 #арсенал_инженера

🛠 Новый уровень контроля готовности узлов в 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 #пульс_индустрии

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

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

Ключевой момент: swap — это не дополнительная память, а ответ в канале с вопросами 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой

LLM в проде: как мониторить и деплоить агентов? Разработчики научились писать агентов, но вопрос эксплуатации остаётся открытым. Курс «Разработка ИИ-агентов» стартовал, и в нём мы уделяем внимание не только коду, но и Ops-составляющей. Что полезного для инженера: — AgentOps: инструменты для трассировки и мониторинга цепочек вызовов; — безопасность: как избежать инъекций и утечек данных; — оптимизация: работа с токенами, кэширование и стоимость запросов; — деплой мультиагентных систем (архитектура, интеграции). Курс на Python, но понимание принципов работы LangGraph и векторных БД критически важно для современной инфраструктуры. Записаться на курс Смотреть первую лекцию

⚙️ 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рсенал_инженера

🤨 Прошу, прочти конфиг Классическая ситуация: вы правите конфиг, применяете изменения, проверяете логи — а там всё по-старому. Приложение просто не знает, что конфигурация изменилась. Когда под стартует, он монтирует ConfigMap как volume. Kubernetes обновляет содержимое этого volume автоматически, но: • Большинство приложений читают конфиг один раз при запуске • Они не следят за изменениями файлов • Перечитывание конфига в рантайме — это дополнительная логика, которую надо реализовывать Команда, чтобы конфиг точно перечитался:

    
        kubectl rollout restart deployment <deployment-name>{}
    

Никакой магии — просто обычный rolling update, но без изменения версии образа. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🚀 9 способов найти заказы без бирж Малый бизнес до сих пор не знает, где искать разработчиков. Кто-то спрашивает у знакомых, кто-то ищет на Авито, кто-то пишет в Telegram-чатах. Будьте на их пути — и первые заказы найдутся сами. ➡️ Самые топовые способы в статье 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a

👨‍💻 Дебаг на физическом и канальном уровне ➡️ Первая часть Первое, что нужно проверить — сами сетевые интерфейсы. Даже в виртуализированной среде они могут оказаться в состоянии 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 #арсенал_инженера