Проверяем задержки сети в Linux через mtr!

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

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

Для таких случаев удобно использовать mtr — инструмент, который объединяет возможности ping и traceroute и позволяет увидеть, где именно начинается деградация. Запуск:

mtr api.example.com

MTR показывает маршрут до узла и статистику по каждому промежуточному хопу: задержку, количество отправленных пакетов и возможные потери ответов.

Для длительного тестирования удобно использовать:

mtr -rwbc 100 api.example.com

Параметры:
-r — вывести итоговый отчёт и завершить выполнение; -w — расширенный формат вывода; -b — показывать IP-адреса вместе с именами узлов; -c 100 — отправить 100 пакетов.

Для больших маршрутов иногда удобнее отключить DNS-резолвинг:

mtr -n api.example.com

Сохранить результат для дальнейшего анализа:

mtr -rwbc 100 api.example.com > mtr-report.txt

Важный момент: потери на промежуточном узле не всегда означают реальную проблему. Многие маршрутизаторы ограничивают обработку ICMP или имеют низкий приоритет для таких ответов. Один из хопов может показывать высокий процент потерь, а конечный сервер при этом работать нормально.

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

Для проверки конкретного TCP-сервиса можно использовать:

mtr -T -P 443 api.example.com

В этом режиме MTR использует TCP SYN probes вместо ICMP, что ближе к проверке реального пути для сервисов вроде HTTPS, SSH или API. Примеры:

# HTTPS
mtr -T -P 443 api.example.com

# SSH
mtr -T -P 22 server.example.com

Но важно понимать: TCP MTR проверяет сетевую доступность и транспортный уровень. Он не покажет проблемы внутри TLS, HTTP или самого приложения. Полезно сравнивать разные направления:

mtr -T -P 443 server-a.example.com
mtr -T -P 443 server-b.example.com

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

🔥 mtr полезен в ситуациях, когда сеть вроде работает, но есть плавающие тайм-ауты, скачки задержки или проблемы только с отдельными сервисами. Он помогает найти участок маршрута, где начинается деградация, но всегда требует анализа вместе с приложением и другими сетевыми метриками.
➡️ DevOps Ready | #практика

📂 7 команд для откладки деплоев и rollout в Kubernetes 🚀

Когда деплой пошёл не по плану, важно быстро понять, что именно произошло: контейнер не стартует, Pod не готов, rollout завис или новая версия сломала приложение.
На шпаргалке — 7 самых полезных kubectl команд, которые помогают разобраться с большинством проблем при деплое: проверить состояние Pod'ов; изучить логи контейнеров; быстро откатиться на предыдущую версию; найти события кластера и узлов.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Запускаем команды от имени другого пользователя через sudo -u — без входа в его интерактивную сессию через su!

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

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

sudo -u www-data id

Команда выполнится с UID и GID пользователя www-data, но текущий терминал останется вашим.

Например, можно проверить, имеет ли веб-приложение доступ к нужной директории:

sudo -u www-data ls -la /var/www/app

Это обычно безопаснее, чем временно менять владельца файлов или расширять права доступа.

Также можно открыть shell от имени сервисного пользователя:

sudo -u postgres bash

Все команды внутри этого shell будут выполняться от имени postgres. Однако это не полноценный login shell: текущая директория и часть окружения могут сохраниться от исходного пользователя.

Если нужен shell с окружением, близким к обычному входу пользователя, используйте:

sudo -iu postgres

При отладке важно учитывать, что sudo -u не всегда воспроизводит реальное окружение работающего сервиса.

Например:

sudo -u node env

Эта команда покажет окружение, сформированное sudo, но оно может отличаться от окружения процесса, запущенного через systemd, Docker, Kubernetes, PM2 или другой менеджер процессов.

Также можно передать временную переменную окружения только для одного запуска:

sudo -u www-data env APP_ENV=testing ./deploy.sh

Переменная APP_ENV будет доступна только этому процессу и его дочерним процессам. Глобальные настройки системы при этом не изменятся. Также важно: возможности sudo -u зависят от правил в sudoers. Разрешение на запуск shell, интерпретатора или произвольного скрипта может дать пользователю широкий доступ от имени целевой учётной записи.

🔥 sudo -u — удобный инструмент для проверки прав, отладки сервисов и запуска отдельных команд от имени системных пользователей без полноценного переключения сессии.

➡️ DevOps Ready | #практика

DevOps Labs практические лабораторные по Docker, Kubernetes, Terraform и CI/CD!

В этом репозитории собраны hands-on лабораторные для DevOps, DevSecOps и Cloud Engineering: Git, Docker, Kubernetes, Terraform, AWS, CI/CD, GitOps, Ansible, Helm, Prometheus и security-практики. Формат полезный именно для прокачки руками: у каждой лабораторной есть цель, ожидаемый результат и сценарий, похожий на реальные задачи из инфраструктуры, а не просто список ссылок для чтения.

Оставляю ссылочку: GitHub

➡️ DevOps Ready | #репозиторий

🐱 Полезную статью нашёл на Хабре: «Права в Linux: chown/chmod, SELinux context, символьная/восьмеричная нотация, DAC/MAC/RBAC/ABAC»!

В статье:
• Даётся цельная картина систем управления доступом в Linux;
• Пошагово разбираются символьная и восьмеричная нотации прав, специальные биты и SELinux-контексты с понятными шпаргалками;
• Собрана база команд и объясняется, как правильно читать и настраивать права без типичных ошибок.

🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья

The Book of Secret Knowledge — огромная база команд, инструментов и DevOps-приёмов!

В этом репозитории собраны полезные материалы для тех, кто работает с Linux, серверами, сетями и безопасностью: cheatsheets, one-liners, CLI/Web-инструменты, списки команд, заметки по Nginx, DNS, HTTP, TLS, SSH, containers, monitoring, debugging и security-практикам. Это не учебник от первой до последней главы, а большая “операционная база”, куда удобно заходить, когда нужно быстро найти команду, инструмент или идею для диагностики инфраструктуры.

Оставляю ссылочку: GitHub

➡️ DevOps Ready | #репозиторий

Как в Linux быстро проверить, кто держит порт?

Иногда сервис не запускается и пишет, что порт уже занят:

bind: address already in use

В такой момент не нужно гадать, какой процесс мешает. Можно сразу посмотреть listening-сокеты через ss:

sudo ss -ltnp

Флаги читаются так:

-l  listening
-t  TCP
-n  не резолвить имена
-p  показать процесс

Если нужен конкретный порт, добавь фильтр:

sudo ss -ltnp 'sport = :8080'

В выводе будет видно адрес, порт, имя процесса и PID:

LISTEN 0 4096 0.0.0.0:8080 users:(("java",pid=2481))

После этого можно проверить процесс:

ps -fp 2481

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

Для UDP почти то же самое:

sudo ss -lunp

А если нужно увидеть все соединения к порту:

sudo ss -tanp 'sport = :8080'

ss помогает быстро понять, какой процесс занял порт. Это одна из первых команд при проблемах со стартом сервисов, Docker, Nginx и backend-приложений.

➡️ DevOps Ready | #совет

📂 Напоминалка по версионированию инфраструктурных изменений!

Изменения в инфраструктуре требуют не меньшего контроля, чем изменения в коде приложения. Грамотное версионирование позволяет отслеживать историю изменений, безопасно выполнять обновления, быстро откатываться при ошибках и обеспечивать прозрачность работы всей команды.
На картинке — 7 практических принципов управления инфраструктурными изменениями: от хранения инфраструктуры как кода и атомарных коммитов до использования Pull Request, автоматизации через CI/CD, документирования изменений, безопасного отката и организации полного жизненного цикла инфраструктурных изменений.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Шпаргалка по сетевым командам Linux!

Например, ip addr show показывает адреса интерфейсов, dig example.com проверяет DNS, а ss -tuln помогает увидеть открытые порты.
На картинке Linux networking commands: routing, network interfaces, DNS, monitoring, troubleshooting и connectivity-команды для быстрой диагностики серверов.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Настраиваем ротацию логов через logrotate!

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

Допустим, приложение пишет сюда:

/var/log/myapp/app.log

Создадим конфиг:

sudo nano /etc/logrotate.d/myapp

Минимальная настройка:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

Это значит: ротировать каждый день, хранить 7 архивов, сжимать старые файлы и не ругаться, если лог отсутствует.

Если приложению нужно пересоздать файл после ротации, добавим postrotate:

postrotate
    systemctl reload myapp
endscript

Полный вариант:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    postrotate
        systemctl reload myapp
    endscript
}

Проверить конфиг можно без реальной ротации:

sudo logrotate -d /etc/logrotate.d/myapp

А принудительно запустить:

sudo logrotate -f /etc/logrotate.d/myapp

После проверки посмотри файлы:

ls -lh /var/log/myapp/

logrotate защищает сервер от бесконечно растущих логов. Это базовая, но очень важная настройка для сервисов, cron-задач и backend-приложений.

➡️ DevOps Ready | #практика

Ускоряем CI-пайплайн через оптимизацию слоев Docker.

Эффективная последовательность команд в Dockerfile позволяет использовать кэширование и сократить время сборки в разы. Мы научимся правильно разделять установку зависимостей и копирование исходного кода, чтобы не пересобирать проект «с нуля» при каждой правке текста. Это базовый навык DevOps для экономии ресурсов раннеров и времени разработчиков.

Сначала создадим неоптимальный файл, который сбрасывает кэш при любом изменении в коде:

# Dockerfile-slow
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "index.js"]

При такой структуре изменение одного символа в коде заставит npm install запускаться заново.

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

# Dockerfile-fast
FROM node:18
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
CMD ["node", "index.js"]

Теперь слой с тяжелыми зависимостями закэшируется и будет пересобираться только при правке package.json.

Проверим разницу в скорости сборки, запустив процесс повторно после небольшого изменения в файле проекта.

time docker build -t fast-app -f Dockerfile-fast .
# Ожидаемый результат: время сборки во второй раз составит доли секунды (CACHED).

Грамотная последовательность шагов это самый дешевый способ ускорить доставку кода. Используйте этот принцип не только в Docker, но и в шагах GitHub Actions или GitLab CI, вынося самые тяжелые и редко меняющиеся операции в начало пайплайна. Всегда проверяйте логи сборки на наличие пометки «Using cache».

➡️ DevOps Ready | #практика

Зачем в DevOps использовать timeout для долгих команд?

Иногда команда может зависнуть: сетевой запрос, backup, healthcheck, rsync, миграция или скрипт в CI. Если не ограничить время выполнения, job может висеть бесконечно.

Простой пример:

curl https://api.example.com/health

Если соединение подвиснет, следующий шаг pipeline может так и не начаться.

Для таких случаев есть timeout:

timeout 10s curl https://api.example.com/health

Теперь команда получит максимум 10 секунд.

Это удобно для healthcheck-ов:

timeout 5s ./check-service.sh

И для команд внутри CI/CD:

timeout 2m ./run-migrations.sh

Если команда не завершилась вовремя, timeout остановит её и вернёт ошибочный exit code. Это можно обработать:

if ! timeout 10s curl -f http://localhost:8080/health; then
    echo "service is not ready"
    exit 1
fi

Для более жёсткого завершения можно указать сигнал:

timeout -s KILL 30s ./worker-test.sh

Но обычно лучше начинать с обычного timeout, чтобы процесс успел завершиться аккуратно.

➡️ DevOps Ready | #совет