LinuxCamp | DevOps

Собери себе эстетичный IDE в терминале

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

Всё это можно сделать через утилиту rgo, не переключаясь в тяжёлую графическую IDE. Ниже показано, как настроить такой «мини-IDE» за несколько минут. Будем использовать: ripgrep + fzf + bat + любой редактор.

Короткая версия команды:

rgo "<паттерн>" [vim|nano|bat]

Ты пишешь rgo, затем в задаёшь шаблон поиска, а далее — редактор, в котором хочешь открыть результат. Если второй аргумент опустить, по умолчанию откроется vim.

Редактор можно заменить на nano, bat или почти любой другой: главное, чтобы он понимал, как открыть файл и перейти к нужной строке.

Что происходит внутри:

ripgrep (rg) мгновенно пробегает по всем файлам вашего проекта и выводит совпадения в формате "путь:строка:текст", fzf превращает вывод в интерактивный список, где можно перемещаться стрелками.

Справа показывается фрагмент кода, нужную строку подсвечивает bat. Когда нажимаешь Enter, выбранная строка распаршивается: скрипт узнаёт путь к файлу и номер строки. После этого файл открывается именно там, где нужно, в соответствии с тем редактором, который ты указал.

Полный скрипт, который кладётся в конфиг шелла:

rgo () {
  local editor=${2:-vim}

  # ищем совпадения, показываем их в fzf с превью
  local sel=$(
    rg --line-number --no-heading --color=never "$1" \
    | fzf \
        --height 50% --border \
        --delimiter ':' \
        --preview 'bat --style=numbers --color=always --highlight-line {2} {1}' \
        --preview-window 'right:60%' \
  ) || return

  # вытаскиваем путь и номер строки
  local file=${sel%%:*}
  local rest=${sel#*:}
  local line=${rest%%:*}

  case "$editor" in
    vim)  vim +"$line" "$file" ;;
    nano) nano +"$line" "$file" ;;
    bat)  bat --style=numbers --highlight-line "$line" "$file" ;;
    *)    "$editor" "$file" ;;
  esac
}
export -f rgo

После того как вставишь этот блок в "~/.bashrc" или "~/.zshrc", перезапусти оболочку "exec $SHELL". Теперь rgo готова к работе.

Вывод:

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

Попробуй, поэкспериментируй с параметрами, и, если найдёшь новые трюки, обязательно расскажи о них!

LinuxCamp | #utils #bymaga

Пацаны, биг дроп на канале! 🔥

Какой язык программирования выбрать новичку? JavaScript, Python, C/C++, Java, Go, Rust, C#, а может быть вообще ассемблер?)

Когда перед вкатунами возникает такое разнообразие опций, глаза разбегаются и непонятно, с чего начать!

Выбор первого языка - очень важное событие на старте карьеры. Ошибёшься - потеряешь время, попадёшь не туда, выгоришь.

Поинты, которые обсудили:

— Чем опасен неверный выбор языка и как "не прогадать"?

— Как найти свою нишу и в каких направлениях на старте может быть тяжелее обычного?

— Какие языки правят в каждой сфере: веб, мобилки, десктоп, геймдев, ML?

— Где активно используются C/C++ и стоит ли начинать с них?

— Что нужно учитывать при выборе языка и на какие моменты обратить особое внимание?

Смотреть на YouTube

rg (ripgrep) - самый быстрый поиск в файлах

grep работает, но медленно и выводит всё подряд. rg ищет во много раз быстрее, понимает .gitignore, красиво подсвечивает совпадения и по-умолчанию пропускает бинарники.

Установка по классике:

sudo apt install ripgrep

Молниеносный поиск слова во всём проекте:

rg TODO

Ищет во всех подпапках, игнорируя каталоги из .gitignore. Совпадения подсвечены, путь + номер строки показаны.

Вывод только имени файла по регулярке:

rg -l '^import .*react' src

Флаг -l — показать только файлы, где найдено. Полезно, если нужно перебрать список в скрипте.

Поиск и сразу количество совпадений:

rg -c "SELECT .* FROM" sql/

-c выводит «файл: число», когда важно быстро понять, где больше всего вхождений. Если надо искать без учёта регистра — добавь "-i"; нужно точное слово — "-w".

Можете сравнить скорости поиска:

time grep -R "somePattern" .
time rg "somePattern"

Попробуйте поискать часто используемый паттерн и если до этого не пользовались rg, то очень приятно удивитесь) Чтобы искать без учета .gitignore:

rg --no-ignore secret

Вывод:

rg — это «grep на турбинах»: ищет быстрее, выводит понятнее, уважает .gitignore. Поставь и попробуй rg error в своём большом репозитории — разница чувствуется сразу.

LinuxCamp | #utils

tldr — короткие примеры вместо километров man-страниц

man - хорошо, но порой там много экранов опций. tldr показывает самые частые примеры одной командой. Открыл - увидел, как пользоваться. Особенно удобно тем, кто только знакомится с терминалом.

Ставим за минуту:

sudo apt install tldr

После установки один раз обнови кэш страниц:

tldr -u

Примеры использования:

Хочешь быстро вспомнить синтаксис tar?

tldr tar

Пример вывода команды - короткие, готовые к использованию шпоры с пояснениями. Создать архив, распаковать, посмотреть содержимое, использовать с gzip - всё по делу, без лишнего. Все работает офлайн - страницы лежат в кэше:

 - [c]reate an archive and write it to a [f]ile:
   tar cf path/to/target.tar path/to/file1 path/to/file2

 - E[x]tract a (compressed) archive [f]ile into the current directory:
   tar xvf path/to/source.tar.gz

 - Lis[t] the contents of a tar [f]ile:
   tar tvf path/to/source.tar

tldr - это именно шпаргалка: поставил, ввёл "tldr <команда>" и сразу видишь рабочие примеры без лишних километров текста. Утилита покрывает самые популярные команды, но для редких или новых CLI, каких-то редких кейсов естественно лучше все-таки использовать man или --help.

LinuxCamp | #utils #microhelp

bat — «цветной cat» с номерами строк и подсветкой кода

Хочется быстро посмотреть файл, но чтобы были цвета, номера строк и даже diff-режим? bat делает ровно это, оставаясь таким же простым, как cat. Установка:

sudo apt install bat

В Debian/Ubuntu бинарник устанавливается как batcat. Чтобы использовать просто bat, можно добавить в "~/.bashrc" или "~/.zshrc":

alias bat="batcat"

Затем:

source ~/.bashrc

Обычный просмотр с цветами:

bat nginx.conf

Синтаксис подсвечен, строки пронумерованы, длинные файлы листаются как less.

Сравнить два файла:

bat --diff old.cfg new.cfg

Видишь изменения как в git diff, только без репозитория. Красивый вывод в Git:

git config --global core.pager "bat --paging=always --style=numbers"

Теперь git show и git diff автоматически открываются через bat с подсветкой. Если подсветка не нужна, добавь -p — plain.

Тонкая настройка (по желанию):

Создай конфиг и подправь тему/стиль:

bat --generate-config-file        # путь покажет в выводе

Список доступных тем:

bat --list-themes | less

Вывод:

bat устанавливается за минуту, заменяет cat, добавляет цвета, номера строк и удобный просмотр diff. Просто, красиво и удобно.

LinuxCamp | #utils

fzf - быстрый «поиск-как-пишешь» прямо в терминале

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

Установка:

apt install fzf

После установки — перезапусти терминал, чтобы подключились биндинги.

Быстрый поиск файлов

# ищем любой файл/папку рекурсивно от текущей точки
fzf

Начинаешь печатать — выдаётся автообновляемый список. Нажимаешь Enter → выбранный путь вставляется в командную строку (например, чтобы открыть vim $(fzf)).

История команд без прокрутки:

fzf перехватывает стандартный Ctrl-R и показывает историю, которую можно фильтровать в реальном времени. Нашёл строку → Enter → команда подставилась, остаётся запустить.

Минималистичная кастомизация:

export FZF_DEFAULT_OPTS="--height 40% --border --preview 'batcat --style=numbers --color=always {} | head -100'"

Что даёт:

--height 40% — окно fzf занимает 40% экрана
--border — рамка вокруг списка
--preview — предпросмотр файла справа, с подсветкой синтаксиса через bat

fzf — удобная штука, которая экономит время. Помогает быстро найти файл или команду прямо в терминале. Определенно стоит попробовать, возможно не захочется бросать :)

LinuxCamp | #utils

tmux: держим терминал «живым», даже если связь пропала

Иногда запускаешь на сервере сборку или бэкап, а Wi-Fi взял и оборвался. Без tmux это заканчивается внезапно — процесс тоже падает. С tmux всё спокойнее: сессия остаётся работать на сервере сама по себе.

Установка:

sudo apt install tmux

Запуск и «вечная» сессия:

tmux new -s work

Работай как обычно, можно запускать тяжелые команды, которые могут очень долго выполняться. Чтобы «сложить» терминал и вернуться к нему позже нажми "Ctrl-b" затем "d". Сессия остаётся жить на сервере в фоне. Можно смело закрыть вкладку SSH.

Повторное подключение:

Подключись снова хоть через неделю:

tmux attach -t work

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

Совместная работа:

Оба пользователя SSH-атся на сервер, один запускает:

tmux new -s pair

Второй подключается тем же:

tmux attach -t pair

Теперь видно один и тот же терминал.

Вывод:

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

LinuxCamp | #utils

Признавайтесь, кто таким промышляет?))

LinuxCamp | #memes

Портфорвардинг по ssh

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

Пример 1: Доступ к внутренней БД через туннель

Если на сервере работает PostgreSQL, настроенный на прослушивание только localhost, то подключиться к нему снаружи напрямую не получится. В этом случае выручит локальный туннель:

ssh -L 5432:localhost:5432 user@remote_host

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

Пример 2: Реверсивный SSH — проброс внутрь NAT’а

Если у тебя домашний сервер, который находится за NAT и не имеет внешнего IP, можно настроить обратный (reverse) туннель через внешний VPS:

ssh -R 2222:localhost:22 user@your-vps.com

После этого с VPS-сервера ты сможешь подключиться обратно к домашнему серверу:

ssh -p 2222 user@localhost

Пример 3: Dynamic SOCKS proxy

Можно превратить SSH-сессию в полноценный SOCKS5-прокси-сервер, через который будут проходить запросы браузера, curl или других инструментов:

ssh -D 1080 user@remote_host

Указав в настройках прокси localhost:1080, ты получишь простой VPN без дополнительного ПО.

LinuxCamp | #utils

Что такое Docker Swarm и как с ним работать

Когда ты используешь только "docker compose" и поднимаешь по 1 сервису в контейнере в какой-то момент тебе может этого стать недостаточно. Может понадобиться масштабировать сервис чтобы обрабатывать больше запросов, включить отказоустойчивость, развернуть сервис на нескольких серверах.

Тогда можно использовать очень простой но достаточно мощный Docker Swarm - встроенный в Docker механизм кластеризации и управления сервисами. Ничего доустанавливать не нужно!

Что такое Docker Swarm?

Это режим работы Docker, в котором:

1) несколько машин объединяются в кластер (Swarm)
2) сервисы запускаются как реплики на этих машинах
3) нагрузка распределяется автоматически
4) контейнеры перезапускаются при сбоях

Быстрый запуск:

Инициализируй кластер на главной машине

docker swarm init

После этого она становится менеджером. Если ты работаешь на одной машине — этого уже достаточно. Создай docker-compose.yml:

services:
  api:
    image: myapi
    ports:
      - "8000:8000"
    deploy:
      # запустит 3 экземпляра nginx
      replicas: 3
   restart_policy:
        # перезапускает при сбоях
        condition: on-failure

Swarm понимает почти тот же формат compose, но использует ключ "deploy:" для настройки. В обычном docker compose блок deploy игнорируется. Запусти сервис как "стек" (stack):

docker stack deploy -c docker-compose.yml mystack

Теперь Docker Swarm создаст сервис с именем mystack_web и запустит 3 реплики nginx.

А если нужно несколько машин?

На других серверах запусти:

docker swarm join --token <токен> <IP-менеджера>:2377

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

docker swarm join-token worker

Теперь у тебя кластер с множеством нод, и Swarm будет распределять нагрузку автоматически.

Вывод:

Docker Swarm — это простой и мощный способ масштабирования контейнеров и управления кластерами. Он отлично подходит, когда нужно что-то чуть более надежное, чем просто docker-compose, но не хочется разбираться с Kubernetes.

LinuxCamp | #devops #docker #bymaga

Масштабируем сервисы через docker compose --scale

Хочешь, чтобы твой API обрабатывал больше запросов? Или нужно поднять несколько воркеров параллельно? Всё это можно сделать одной командой:

docker compose up --scale <сервис>=<кол-во>

Как это работает

Команда "--scale" запускает несколько контейнеров одного сервиса по конфигурации "docker-compose.yml":

docker compose up --scale api=3

Создаст 3 независимых контейнера api, которые используют один и тот же образ, переменные, порты и т.д.

Варианты использования

Пример docker-compose.yml:

version: "3.8"
services:
  api:
    image: myapp:latest
    build: .
    ports:
      - "8000"

Важно: если nginx поднят в докере и в одной сети с апи, то порт не должен быть жёстко задан как "8000:8000", иначе только один контейнер сможет его занять. Используй:

    ports:
      - "8000"

А в nginx конфиге:

upstream backend {
    server api:8000;
    server api:8001;
    server api:8002;
}

Обычно внутри Docker все контейнеры сервиса находятся под одним именем (например, api), и Docker DNS сам решает, кому из них отдать запрос (round-robin). Если же nginx вне докер сети, то в docker-compose.yml нужно прописать все порты:

    ports:
      - "8001:8000"
      - "8002:8000"
      - "8003:8000"

И затем настроить nginx конфиг так:

upstream backend {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    server 127.0.0.1:8003;
}

server {
    listen 80;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Теперь Nginx равномерно распределяет входящие запросы между 3 контейнерами, которые слушают на разных портах.

Ограничения и подводные камни

1) Порты: нужно либо жестко прописывать порты для каждого инстанса, либо не прописывать порты жестко вообще при масштабировании;

2) Состояние контейнеров не сохраняется — это одинаковые инстансы, а не кластеры;

3) Не путай с кластеризацией — это просто локальное масштабирование;

Про полноценную кластеризацию через Docker Swarm будет в одном из следующих постов :)

LinuxCamp | #devops #docker

Нагрузочное тестирование с помощью locust

Хочешь узнать, сколько реально выдержит твой сервис под наплывом пользователей? И вот тут выходит на сцену Locust — очень простой, но мощный инструмент на Python. Locust — это нагрузочный генератор, который:

- пишет сценарии на Python
- запускает веб-интерфейс для управления нагрузкой
- показывает реальное поведение под давлением

В общем, работает как армия виртуальных пользователей, которые одновременно штурмуют твой API.

Установка:

pip install locust

Пример теста:

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)
    # Указан хост твоего апи
    host = "http://localhost:8000"

    @task
    def get_articles(self):
        self.client.get("/api/articles")

    @task
    def post_form(self):
        self.client.post("/api/submit", json={"name": "Locust"})

Запуск:

locust -f locustfile.py

Если ты назовёшь файл просто "locustfile.py" и запустишь команду в этой же директории, то можно вообще не указывать "-f", и Locust подхватит его автоматически.

Затем открой браузер: http://localhost:8089
Укажи количество юзеров и скорость (spawn rate) и начинай тест.

Что можно узнать:

- RPS — сколько запросов в секунду проходит
- Latency — время ответа
- Failures — ошибки, 5xx и timeouts
- Percentiles — насколько стабилен сервис под давлением

Зачем использовать Locust?

1) проверить, на сколько пользователей хватит твоей архитектуры;
2) увидеть, какой метод тормозит при росте нагрузки;
3) смоделировать реальные сценарии (авторизация, покупка, публикация);
4) подготовиться к маркетинговой акции, запуску продукта, или… DDOS атаке;

LinuxCamp | #bymaga

Что такое docker network и зачем он нужен?

Docker-сеть (docker network) - это способ связать контейнеры между собой и с внешним миром. Благодаря ей приложения в разных контейнерах могут видеть друг друга, обмениваться данными и быть изолированными от посторонних.

Типы сетей:

1) bridge — дефолтная сеть для контейнеров. Работает как приватная подсеть на хосте. Контейнеры внутри могут общаться друг с другом по имени, но не видят контейнеры из других сетей.
2) host — контейнер использует сетевой стек хоста напрямую. Без изоляции, но с меньшими накладными расходами.
3) none — без сети. Полная изоляция.
4) overlay — для связи контейнеров между хостами (в Swarm-кластере).
5) macvlan — контейнеру назначается собственный MAC-адрес. Выглядит как отдельное устройство в сети.

Зачем нужна Docker-сеть:

Можно обращаться между сервисами внутри сети по имени контейнера, без знания IP-адреса. Это работает благодаря встроенному DNS-серверу Docker.

Например, если у тебя есть два сервиса - frontend и api, то внутри одного контейнера ты можешь сделать запрос:

http://api:5000

Docker сам разрешит имя api в IP-адрес другого контейнера в той же сети. Это особенно удобно при использовании docker-compose, где имена сервисов автоматически становятся доступными как DNS-имена.

Создание сети:

Создать сеть можно например командой:

docker network create mynetwork

Также можно указать сеть в одном docker-compose.yml:

services:
  api:
    image: my-api
    networks:
      - mynetwork

  db:
    image: postgres:17
    networks:
      - mynetwork

networks:
  mynetwork:

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

Подключение к уже существующей сети:

services:
  frontend:
    image: myfront
    networks:
      - mynetwork

networks:
  mynetwork:
    external: true 

"external: true" говорит docker-compose, что сеть уже создана заранее (вручную или другим compose-файлом) и её не нужно пересоздавать.

Добавление и удаление вручную:

docker network connect mynetwork frontend
docker network disconnect mynetwork frontend

Контейнер продолжит работу, просто будет подключён или отключён от указанной сети.

Docker-сети позволяют организовать понятную, безопасную и изолированную инфраструктуру между сервисами. Даже при локальной разработке это помогает избавиться от хаоса с IP-адресами и ручными настройками.

LinuxCamp | #docker #devops #bymaga

nft: современный фаервол в Linux, который заменил iptables

nft — это утилита для управления nftables, новой подсистемой фаервола в ядре Linux. Она пришла на смену старым и запутанным инструментам: iptables, ip6tables, ebtables, arptables. Теперь всё делается в одной системе, единым языком, более эффективно и понятно.

Зачем нужен nft?

- Чтобы блокировать или разрешать трафик (фаервол).
- Для перенаправления портов (DNAT / SNAT).
- Чтобы настроить NAT, логирование, rate limiting и т.д.
- Управлять IPv4, IPv6, Ethernet, ARP в одной таблице.

Установка nft

На многих дистрибутивах nft уже предустановлен. Если нет:

# Debian / Ubuntu
sudo apt install nftables

# Red Hat / CentOS / Fedora
sudo dnf install nftables

# Arch Linux
sudo pacman -S nftables

Как работает nftables

В отличие от iptables, где каждая подсистема жила в своём мире (разные команды для IPv4, IPv6, ARP...), nftables работает с едиными таблицами и цепочками, и одним конфигом.

Простой пример через команды:

# Создаём таблицу и цепочку
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0 \; }

# Блокируем IP-адрес
sudo nft add rule inet filter input ip saddr 203.0.113.42 drop

Конфиг-файл "/etc/nftables.conf". В реальности, правила лучше описывать в конфиге, чтобы сохранять и применять при старте:

#!/usr/sbin/nft -f

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy accept;

    # Блокируем IP
    ip saddr 203.0.113.42 drop

    # Разрешаем SSH
    tcp dport 22 accept
  }
}

Применить файл:

sudo nft -f /etc/nftables.conf

И включить автозапуск:

sudo systemctl enable nftables
sudo systemctl start nftables

Как проверить, что правила работают

Посмотреть текущие правила:

sudo nft list ruleset

Или только одну таблицу:

sudo nft list table inet filter

Вывод будет в читабельной иерархии, например:

table inet filter {
    chain input {
        type filter hook input priority 0; policy accept;
        ip saddr 203.0.113.42 drop
        tcp dport 22 accept
    }
}

Чтобы перезаписать все старые правила, используйте:

sudo nft flush ruleset

Что делает nft круче iptables

- Одна система вместо четырёх: больше не нужно думать iptables vs ip6tables.
- Наборы (sets): можно сразу заблокировать десятки IP без повторений.
- Списки и словари: условная логика в правилах.
- Rate limiting: ограничение по частоте (например, не более 10 пакетов/сек).
- Логирование прямо в правило: встроенная поддержка log.
- Конфиги, читаемые человеком, пригодные для версионирования.
- Высокая производительность: меньше затрат ядра, быстрее работает.

Совет

Если вы раньше использовали iptables, не стоит мешать его правила с nftables. Лучше отключить iptables и перейти на nft полностью:

sudo systemctl disable iptables
sudo systemctl disable ip6tables

LinuxCamp | #utils

ss: современный способ смотреть порты и сетевые соединения

ss - сверхбыстрая альтернатива netstat для просмотра информации о сетевых соединениях, портах и сокетах. Работает быстрее, точнее и доступна почти на всех системах по умолчанию.

Когда полезен ss:

- Смотришь, кто слушает порт.
- Проверяешь, есть ли подключения к сервису.
- Диагностируешь, почему не работает соединение.
- Ищешь утечку сокетов или странную сетевую активность.

Базовый синтаксис:

ss [опции]

Полезные команды:

Кто слушает TCP-порты:

ss -tln

-t - только TCP
-l - только LISTEN
-n - показывать IP/порт как числа (не домены)

Какие процессы заняли порты:

ss -tulpn

-u - отвечает за UDP
-p - показать PID и имя процесса (если root)

Какие процессы заняли порты:

ss -tunap

Сокеты в состоянии TIME-WAIT или CLOSE-WAIT:

ss -tan state time-wait
ss -tan state close-wait

Сортировка по количеству соединений:

ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Преимущества:

- ss показывает гораздо больше сокетов, чем netstat и делает это быстрее.
- Отлично сочетается с grep, awk, cut — можно быстро написать фильтры.
- Если хочешь отслеживать соединения в динамике — используй watch ss -tulpn.

LinuxCamp | #utils

lsof: что держит порт, файл или устройство занятым?

Если ловил ошибку "Address already in use" или не получалось размонтировать флешку - значит, уже сталкивался с ситуацией, когда что-то заняло ресурс. Команда lsof поможет быстро понять - кто именно.

Зачем использовать lsof:

- Узнать, кто держит порт (например, 80 или 5432).
- Посмотреть, кто пишет в лог или блокирует файл.
- Проверить, кто мешает размонтировать диск (umount).
- Увидеть, какие файлы открыты у процесса (отладки и утечки).

Примеры:

Кто занял порт 5432 (PostgreSQL):

lsof -i :5432

Какие процессы используют файл:

lsof /var/log/syslog

Какие процессы используют определённую директорию:

lsof +D /mnt/backup

Посмотреть открытые файлы у PID:

lsof -p 1234

Что мешает размонтировать:

lsof /mnt/usb

Лайфхаки:

Совмещай с grep, чтобы быстрее искать нужное:

lsof -i | grep LISTEN

Можно убить процесс, который держит порт:

kill -9 $(lsof -t -i :1234)

LinuxCamp | #utils #microhelp

Команда watch: живой взгляд на процессы и метрики

watch - утилита, которая повторно запускает любую команду через заданный интервал (по‑умолчанию 2 сек) и отображает её вывод полноэкранно. Подходит, когда:

1) нужно увидеть изменение метрики прямо сейчас;
2) нет времени поднимать полноценный мониторинг;
3) требуется «подкараулить» событие и выйти, как только оно случится;
4) работает везде: на Debian, BusyBox в Alpine, внутри Docker‑контейнера;

Базовый синтаксис

watch [-n <сек>] [-d] [-g] [-t] [-p] [-e] [-x] <команда>

Ключевые опции

"-n 5” — устанавливает интервал в 5 с. Хорош для медленных команд и экономии CPU;
-d — подсвечивает изменения относительно предыдущего вывода. Удобно отслеживать «скачки»;
-g — автоматически выходит, как только вывод изменится; полезно, когда ждёте окончания бэкапа;
-e — завершает работу при ненулевом exit‑коде команды. Превращает watch в health‑check;
-t — убирает заголовок watch. Идеален для чистых скриншотов;
-p — синхронизирует запуск с системными секундами. Это важно при очень частых опросах, например "-n 0.2";
-x — запускает команду без обёртки в shell. Это помогает, если команда содержит символы вроде $ или *, которые интерпретируются bash'ем;

Практические примеры

Топ прожорливых процессов

watch -n 1 -d 'ps -eo pid,cmd,%cpu --sort=-%cpu | head'

Ждём появления строки ERROR в логе и выходим

watch -g "grep -q ERROR /var/log/app.log"
echo 'Нашли ERROR!'

Мини‑график latency

watch -n 0.2 -p 'ping -c1 1.1.1.1 | awk -F"=" "/time=/{print $4}"'

Лайфхаки

"-d" подсвечивает изменения — удобно, когда хочешь быстро понять, что именно изменилось. Добавь "--differences=permanent", чтобы подсветка не исчезала между обновлениями.
"-t" убирает заголовок watch — идеально для чистых логов или скриншотов.
"-p" даёт ровный ритм (1 Hz и выше), полезно для прецизионного мониторинга.
"-g" или "-e" + немного shell'а — и у тебя мини-скрипт, который реагирует на событие.

LinuxCamp | #utils

Оптимизация Dockerfile и образов

Общие принципы

- Каждая инструкция Dockerfile создаёт слой - по возможности объединяй команды RUN, чтобы минимизировать количество слоёв.
- Не используй latest: фиксируй версии образов и зависимостей для стабильности и воспроизводимости.
- Всегда указывай версии зависимостей:

flask==3.0.0
psycopg2==2.9.9
PyJWT==2.6.0

Правильная структура Dockerfile

FROM python:3.10

WORKDIR /app

# копируем только requirements для кэширования установки
COPY requirements.txt . 
RUN pip install --no-cache-dir -r requirements.txt && \
    rm -rf /root/.cache

# копируем остальной код
COPY . .

CMD ["python", "main.py"]

CMD vs ENTRYPOINT

CMD задаёт команду по умолчанию, которую можно переопределить при запуске контейнера. ENTRYPOINT фиксирует поведение и используется, когда контейнер должен всегда выполнять определённую задачу (например, CLI-инструмент). Обычно их комбинируют: ENTRYPOINT задаёт неизменяемую часть, CMD — параметры по умолчанию.

- CMD — удобно для простого запуска,
- ENTRYPOINT — для CLI-обёрток и скриптов, где логика жёстко зафиксирована.

Советы по чистке

- Используй "--no-cache-dir" при установке pip-зависимостей.
- Удаляй .cache, временные и сборочные файлы (pycache, .pytest_cache и т.д.). А лучше использовать ".dockerignore":

__pycache__/
*.pyc
.git
.venv
.pytest_cache

Оптимизация кэширования

Сначала копируй наименее изменяемые файлы (например, requirements.txt) — это позволяет использовать кэш при сборке.

Многоступенчатая сборка (multi-stage build)

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

Multi-stage build позволяет:

1) сначала собрать проект во временном образе (build stage),
2) а затем в финальный образ перенести только то, что нужно для запуска (runtime stage),
3) не таща за собой мусор и сборочные инструменты.

Пример для python:

FROM python:3.10 as builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.10-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.10/site-packages /usr/local/lib/python3.10/site-packages
COPY . .
CMD ["python", "main.py"]

Пример для Go:

FROM golang:1.21 as build
COPY . .
RUN go build ./src/main.go

FROM alpine:latest
COPY --from=build /go/main .
CMD ["./main"]

LinuxCamp | #utils #devops

Что такое logrotate и как он спасает ваши диски

Системные логи могут незаметно занять весь диск, особенно если ты держишь nginx, docker, или пишешь логи вручную. Если ты ещё не настроил logrotate — однажды тебя очень удивит "df -h". Разберёмся, что это и как работает.

Что делает logrotate

logrotate — это системная утилита, которая:

- архивирует старые логи (обычно в .gz)
- удаляет логи старше N дней/версий
- переименовывает файлы (access.log → access.log.1, и т.д.)
- может перезапускать сервис после ротации (чтобы лог снова появился)

Где живёт конфиг

Ubuntu и Debian по умолчанию кладут правила в "/etc/logrotate.d/*" - здесь обычно уже лежат готовые правила для nginx, apt, docker и т.д. Но конфиги — это ещё не запуск.

Даже если правила лежат в logrotate.d, они не будут применяться, если logrotate либо не установлен, либо не запускается ни через cron, ни через systemd. Можно проверить работает ли logrotate у тебя уже. Посмотри, запланирован ли таймер:

systemctl list-timers | grep logrotate

Как всё включить

Установи, если не установлен:

sudo apt install logrotate

У тебя появится файл "/etc/logrotate.conf". Также появится автоматически сервис и таймер ротации логов. Можно запустить systemd‑таймер, если не запустился автоматически:

sudo systemctl enable --now logrotate.timer

Как добавить своё правило

Если у тебя, например, есть лог "/var/log/myapp.log". Создай конфиг, после чего файл будет ротироваться вместе с остальными:

/var/log/myapp.log {
    daily              # ротация каждый день
    rotate 7           # хранить 7 архивов
    compress           # архивировать .gz
    missingok          # не ругаться, если файла нет
    notifempty         # не трогать, если пустой
    copytruncate       # обрезать файл, не перезапуская процесс
}

sudo nano /etc/logrotate.d/myapp

Что с Docker?

Docker пишет логи в "/var/lib/docker/containers/.../*.log". Они не попадают под системный logrotate. Чтобы ограничить размер:

# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Затем:

sudo systemctl restart docker

Что с journalctl?

Если сервисы логируют в systemd‑журнал, ротация настраивается в "/etc/systemd/journald.conf".

Пример параметров:

SystemMaxUse=500M
SystemMaxFileSize=100M
MaxRetentionSec=7day

Вывод

1) Конфиги в logrotate.d — это ещё не автомат
2) Сначала проверь, может уже всё работает
3) Самый надёжный способ — logrotate.timer
4) Docker и journalctl — отдельные истории

LinuxCamp | #utils #devops #bymaga