Шпаргалка по kubectl-командам!

Например, kubectl get pods показывает поды, kubectl describe pod помогает посмотреть детали ресурса, а kubectl logs быстро достаёт логи контейнера.

На картинке команды kubectl для просмотра ресурсов, создания и применения YAML, удаления объектов, запуска команд внутри контейнера, работы с логами, kubeconfig и короткими именами Kubernetes-ресурсов.

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

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

Практически любую команду можно запустить в отдельной cgroup!

Большинство воспринимает systemd-run как инструмент для запуска сервисов. Но режим --scope запускает команду во временном scope unit, сразу помещая её и всё дерево процессов в отдельную cgroup, где можно задать ограничения.

Например, если большая сборка начинает вытеснять всё остальное из памяти, достаточно выполнить её через systemd-run:

systemd-run --user --scope \
  -p MemoryHigh=1536M \
  -p MemoryMax=2G \
  make -j32

Теперь ограничения действуют только на эту команду и всё её дерево процессов. После завершения временная cgroup автоматически исчезнет.

Точно так же можно ограничить использование процессора, не меняя приоритет процесса (nice решает другую задачу):

systemd-run --user --scope \
  -p CPUQuota=200% \
  npm test

Или собрать сразу несколько политик для ресурсоёмкой задачи:

systemd-run --user --scope \
  -p MemoryMax=4G \
  -p CPUQuota=300% \
  -p IOWeight=100 \
  cargo build --release

Для работы ограничений требуется systemd с поддержкой соответствующих cgroup-контроллеров (обычно современные дистрибутивы с cgroup v2).

🔥 systemd-run --scope позволяет применять возможности cgroups к любой команде одной строкой, без создания сервисов и постоянных unit-файлов.

🚪 Linux Ready | #совет

📂 Напоминалка по деплою по веткам и окружениям без микса!

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

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

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

zram в Linux как альтернатива обычному swap!

zram — это механизм Linux, который создаёт сжатое блочное устройство в оперативной памяти и позволяет использовать его как swap. В отличие от обычного swap, данные не записываются на диск — они остаются в RAM, но хранятся в сжатом виде. Это позволяет эффективнее использовать память и уменьшить обращения к медленному дисковому swap.

Особенно полезен zram на небольших VPS, контейнерных серверах и устройствах с ограниченным объёмом RAM, где нужно переживать кратковременные пики нагрузки без резкого падения производительности.

Перед настройкой проверяем текущий swap:

swapon --show
free -h

Загружаем модуль ядра:

sudo modprobe zram

Проверяем появившееся устройство:

zramctl

Задаём размер zram, например 4 GB:

echo 4G | sudo tee /sys/block/zram0/disksize

Размер zram не означает немедленное выделение 4 GB RAM. Фактически память занимает только сжатый объём реально используемых данных.

Выбираем алгоритм сжатия. Чаще всего используют lz4 или zstd: lz4 быстрее, zstd обычно даёт лучшее сжатие. Пример с lz4:

echo lz4 | sudo tee /sys/block/zram0/comp_algorithm

Доступные алгоритмы:

cat /sys/block/zram0/comp_algorithm

Создаём swap и включаем:

sudo mkswap /dev/zram0
sudo swapon /dev/zram0

Проверяем:

swapon --show
zramctl

Теперь Linux использует zram как swap-устройство, но данные находятся внутри RAM в сжатом виде, без постоянной записи на диск.

Для сохранения после перезагрузки обычно используют systemd-zram-generator или zram-tools. В Debian/Ubuntu при использовании zram-tools настройки обычно находятся в:

/etc/default/zramswap

Также стоит учитывать параметр ядра vm.swappiness, который влияет на активность использования swap:

cat /proc/sys/vm/swappiness

zram и zswap — разные механизмы. zram создаёт отдельный swap внутри RAM. zswap работает как кэш перед обычным swap на диске.

Проверка zswap:

cat /sys/module/zswap/parameters/enabled

🔥 Подведем итог: zram не добавляет физическую память, но позволяет эффективнее использовать доступную RAM, уменьшает обращения к дисковому swap и помогает системе стабильнее переживать кратковременные пики нагрузки.

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

Проверяем задержки сети в 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 | #практика