LinuxCamp | DevOps

Слили в телеграмм тонны инфы и отсортировали по каналам 🙃 Linux & Bash — 459ГБ 🖥 Курсы & GitHub — 1579ГБ ☁️ Хакинг & ИБ — 756ГБ 🤒 OSINT — 315ГБ ⌨️ Python — 955ГБ 😦 Работа в IT — 778ГБ 🖥 Общий архив — 2346ГБ ➡️ Практические инструкции, курсы, книги и инструменты.

Арчевод показал свой рабочий стол Linux дистра и его оформление. Ну, по факту, выглядит оч даже ничего) Вы такое, как, одобряете? 🔥 - топ окружение 👍 - нет ничего краше Винды ITCamp | AI & Code

bottom (btm): мониторинг системы с гибкой визуализацией bottom, сокращённо btm, это TUI-утилита для мониторинга состояния системы. По задачам она пересекается с top и htop: загрузка CPU, использование памяти, диск, сеть, процессы. Отличие в том, что btm сразу ориентирован на графическое представление данных в терминале и гибкую компоновку экрана. Установка

    
        
sudo apt install bottom{}
    

После установки утилита запускается командой btm. Как работает При запуске btm открывает интерактивный интерфейс с несколькими блоками: CPU, память, swap, диск, сеть, список процессов. Блоки можно скрывать, менять их порядок и переключать режимы отображения с клавиатуры, без редактирования конфигов.

    
        
btm{}
    

Для серверов и Docker-хостов полезен режим с упором на процессы и нагрузку, где видно PID, пользователя, потребление CPU и памяти в реальном времени.

    
        
btm -b{}
    

Все настройки сохраняются в конфигурационном файле, который можно использовать одинаково на разных машинах. Вывод bottom - это интерактивный мониторинг системы в терминале с расширенной визуализацией и настройкой интерфейса. Подходит для личного пользования и постоянного контроля ресурсов без GUI-инструментов. LinuxCamp | #utils

hyperfine: замер времени выполнения команд hyperfine - это утилита для бенчмаркинга команд в Linux. Она запускает одну или несколько команд много раз и измеряет время выполнения. В отличие от time, здесь сразу считаются среднее значение, минимальное и максимальное время, стандартное отклонение. Учитываются прогрев и шум системы. Установка В Ubuntu утилита доступна в официальных репозиториях.

    
        
sudo apt install hyperfine{}
    

После установки команда hyperfine доступна без дополнительной настройки. Базовое использование Простейший случай это замер одной команды. hyperfine сам выполнит несколько прогонов и выведет агрегированную статистику.

    
        
hyperfine "ls -R /usr/share >/dev/null"{}
    

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

    
        
hyperfine "grep -R foo ." "rg foo ."{}
    

В этом режиме вывод сразу показывает разницу по времени и разброс значений, что удобно для принятия технических решений. Вывод hyperfine предназначен для воспроизводимых замеров производительности команд. Подходит для сравнения CLI-утилит, флагов запуска, скриптов и небольших изменений в пайплайнах, где важно видеть реальные цифры, а не разовый запуск через time. LinuxCamp | #utils

ExecStartPre / ExecStartPost: хуки для systemd Что это такое ExecStartPre и ExecStartPost - это команды, которые systemd выполняет до и после запуска сервиса.

    
        
ExecStartPre=
ExecStart=
ExecStartPost={}
    

Важно: если ExecStartPre вернёт non-zero, то сервис не запустится вообще. Самая частая ловушка Pre-хук выглядит безопасным, но падает:

    
        
ExecStartPre=/usr/bin/curl http://127.0.0.1:9000/health{}
    

Если сервис на 9000 ещё не поднят, curl вернёт код ошибки, systemd считает, что сервис сломан, и даже не дойдёт до ExecStart. Pre-хук выполняется каждый раз при старте, включая рестарты. Любая временная проблема: сеть, DNS, файл, env превращается в стоппер сервиса. В логах:

    
        
journalctl -u myservice{}
    

    
        
ExecStartPre failed with exit code 7{}
    

Типичные ошибки:

    
        
ExecStartPre=/bin/mkdir /var/run/app
ExecStartPre=/usr/bin/test -f /config/app.yml
ExecStartPre=/usr/bin/psql -c "select 1"{}
    

Для post-хуков помни, если ExecStartPost падает, значит сервис уже запущен, но unit помечается как failed. Практическое правило ExecStartPre - только для быстрых, гарантированных операций (создать каталог, выставить права, подготовить env). Все, что зависит от сети, БД, других сервисов лучше выносить в код сервиса. Вывод ExecStartPre - это точка отказа, если одна команда упала, то сервис не стартует. Если хук может упасть либо гаси ошибку, либо убирай его совсем. LinuxCamp | #utils

🖥 На Stepik вышел курс, который учит работать с Docker на реальных проектах. Владение Docker - навык, который отличает новичка от профи, Сегодня почти всё разворачивается в контейнерах. Если ты не умеешь работать с Docker, ты медленнее, зависим от чужих настроек и постоянно ловишь баги «у меня локально работает». • как упаковывать проекты в контейнеры • как поднимать целые системы за минуты • как избегать типичных ошибок в продакшене • как делать стабильные и повторяемые окружения •в нем разобраны все возможные ошибки Только практика и реальные кейсы от авторов Docker Академии- с нуля до уверенного уровня. 🎁 Скидка 40 процентов действует 48 часов 👉 Записывайся и сделай Docker своим настоящим рабочим инструментом.

TCP TIME_WAIT: нормально ли это Что это и зачем TIME_WAIT - состояние TCP, в котором сокет некоторое время живёт после закрытия соединения. Это нужно, чтобы гарантировать доставку финальных пакетов и не допустить повторного использования старых sequence numbers. Как посмотреть и когда это важно Количество сокетов в TIME_WAIT видно так:

    
        
ss -tan | grep TIME-WAIT | wc -l{}
    

Проблемой это становится только тогда, когда новые соединения перестают создаваться. Обычно происходит, когда закончились ephemeral ports. Это временные клиентские порты, которые ядро автоматически выделяет для исходящих соединений. Их диапазон можно посмотреть здесь:

    
        
cat /proc/sys/net/ipv4/ip_local_port_range{}
    

Если диапазон узкий и соединения короткие, порты быстро оказываются заняты TIME_WAIT. Почему их становится много Короткие HTTP-соединения, отсутствие keep-alive, прокси, балансировщики, высокая RPS, микросервисы, healthchecks - все это создает тысячи короткоживущих TCP-сессий. В этом сценарии большое количество TIME_WAIT признак нагрузки, а не поломки. Что делать безопасно Обычно ничего. Если упираешься в лимиты, расширяют диапазон ephemeral ports и разрешают повторное использование TIME_WAIT для клиентов:

    
        
sysctl -w net.ipv4.ip_local_port_range="10240 65535"
sysctl -w net.ipv4.tcp_tw_reuse=1{}
    

Главное решение все равно на уровне приложения: keep-alive, connection pool, HTTP/2. Вывод TIME_WAIT - это нормальное состояние TCP. Пока есть свободные ephemeral ports, система работает корректно. Если они заканчиваются, то масштабируй диапазон портов и соединения, а не пытайся лечить TCP. LinuxCamp | #utils

Как продебажить сеть в контейнере если в нём не хватает утилит? Иногда слышу вопросы от коллег типа: "Как выполнить какой-нибудь запрос из контейнера, если в нём нет curl?". Или: "Как снять дамп из контейнера, если в нём нет tcpdump?". Есть один очень простой способ, как выполнить любую команду внутри сети контейнера. Единственное, что вам понадобится, это доступ с root-правами к хосту. 1. Находим PID процесса контейнера. Обычно для этого достаточно выполнить ps aux | grep "команда запуска вашего контейнера", но если контейнеров запущенной одной и той же командой на хосте много, то лучше воспользоваться CLI вашего рантайма (типа crictl) для опредленя PID'а нужного контейнера. 2. Заходим в сетевой неймспейс этого процесса через команду nsenter -n -t $PID, где -n значит network. Всё. Можете проверить, что вы там, где нужно, введя команду ip a. Это очень полезный метод, когда вам либо самим нужно что-то проверить, либо когда нужно доказательство клиенту, что с трафиком из контейнера 100% всё порядке. Между инцидентами Реклама. Давыдов И.А. ИНН 775108336633. erid: 2W5zFGaTMax

conntrack table: невидимый лимит Linux Что такое conntrack conntrack - это таблица отслеживания сетевых соединений в netfilter. Каждое TCP/UDP соединение, NAT, kube-proxy, Docker, firewall проходит через нее. Если таблица переполнена, сеть начинает ломаться без ошибок в приложениях. Симптомы переполнения Соединения не устанавливаются, random timeouts, сервисы живы, но клиенты не могут подключиться, CPU норм, сеть есть, но ничего не работает. В логах ядра:

    
        
dmesg | grep conntrack

типичный вывод:
nf_conntrack: table full, dropping packet{}
    

Проверяем текущее состояние

    
        
# сколько соединений сейчас
cat /proc/sys/net/netfilter/nf_conntrack_count

# максимальный лимит
cat /proc/sys/net/netfilter/nf_conntrack_max{}
    

Если count ≈ max, то ты уже в зоне риска. Временное решение Увеличить лимит на лету:

    
        
sysctl -w net.netfilter.nf_conntrack_max=262144{}
    

Постоянная настройка В /etc/sysctl.conf или /etc/sysctl.d/conntrack.conf:

    
        
net.netfilter.nf_conntrack_max=262144
net.netfilter.nf_conntrack_tcp_timeout_established=600{}
    

И применить:

    
        
sysctl -p{}
    

Вывод Переполненный conntrack выглядит как непонятная поломка сети. Проверка занимает 10 секунд, но лучше заранее заняться настройкой правильного лимита. LinuxCamp | #utils

Restart=always: зло или нет Что делает Restart=always systemd перезапускает сервис при любом завершении, даже если он упал из-за бага или был остановлен вручную.

    
        
[Service]
Restart=always{}
    

Почему это выглядит удобно Сервис упал, systemd быстро поднял. Никаких алертов, все типо работает. Именно здесь начинается проблема. Типичный плохой сценарий Сервис падает сразу после старта.

    
        
Restart=always
RestartSec=1{}
    

В итоге:

    
        
start → crash → restart → crash → restart{}
    

CPU жрётся, логи летят, система шумит, а причина падения маскируется. Посмотреть это легко:

    
        
systemctl status myservice
journalctl -u myservice{}
    

Когда Restart=always реально зло Если сервис падает из-за: ошибки конфигурации, отсутствия зависимостей, недоступной сети, битых env-переменных. В этих случаях рестарт ничего не чинит, а только мешает диагностике. Более безопасная альтернатива Для большинства сервисов лучше:

    
        
Restart=on-failure
RestartSec=5{}
    

systemd перезапустит сервис при краше, но не будет вечно крутить его при нормальном выходе. Контроль перезапусков Чтобы не получить restart loop:

    
        
StartLimitIntervalSec=60
StartLimitBurst=5{}
    

После 5 падений за минуту systemd остановит сервис. Когда Restart=always оправдан Очень простые демоны, воркеры без состояния, sidecar-сервисы, сервисы, где падение = всегда ошибка. Даже там обычно добавляют лимиты. Вывод Restart=always - не защита, а автоповтор ошибки. Если сервис может падать из-за конфигурации или окружения используй on-failure и лимиты. Автоперезапуск должен помогать системе, а не скрывать проблемы. LinuxCamp | #utils