Почему docker compose logs -f спасает на проде

Когда что-то ломается в проде — время идёт на секунды. Не всегда есть доступ к графическому лог-серверу, и не всегда хочется копаться в docker exec, чтобы что-то вытащить. В таких случаях спасает простая команда:

docker compose logs -f

Она показывает живые логи сразу всех сервисов которые описаны в docker-compose.yml в данной директории.

В какой ситуации это может быть мастхев? Допустим что-то не стартует. Можно сделать быстрый дебаг ошибок конкретного сервиса:

docker compose logs -f backend

И ты моментально видишь stack trace, ошибку подключения к БД или криво прокинутую переменную. Кроме этого можно следить за цепочкой событий. Если сервисы завязаны друг на друге удобно запускать:

docker compose logs -f

И ты видишь весь «разговор» между фронтом, беком и базой, в одном терминале. Полезный флаг для просмотра логов:

docker compose logs -n 50 -f

"-n" - помогает просмотреть только последние N строк. Нужная и простая команда в арсенале, может спасти в самый ответственный момент.

LinuxCamp | #utils

ncdu — лучший способ быстро очистить место на сервере

Когда на сервере внезапно заканчивается место, первое, что хочется — понять, что его съело. Вместо того, чтобы долго ковыряться в du и find, просто поставь ncdu.

Это интерактивная утилита для анализа диска в терминале. Работает быстро, показывает размеры папок/файлов и позволяет удалять ненужное прямо из интерфейса:

$ sudo apt install ncdu

Для сканирования нужно просто ввести команду и передать целевой каталог. Чтобы промониторить корень:

$ sudo ncdu /

Нужные кнопочки:

Навигация - стрелками вверх/вниз.
Удаление - клавиша d.
Обновить - g.
Выйти - q.

В отличие от "du -sh *", ncdu не только показывает вес директорий, но и позволяет разобраться в них быстрее. Особенно полезно, если забит логами /var/log, кто-то накатил 100500 .tar.gz или забыли почистить кэш в home. Утилита очень выручает, когда каждая секунда важна. Установил - посмотрел - удалил - освободил.

LinuxCamp | #utils

Базовая настройка Nginx и подключение домена: как я это сделал

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

Шаг 1: Покупка домена

Я купил домен на reg.ru - обычная регистрация, ничего необычного, правда с верификацией по паспорту. После покупки нужно было настроить DNS-записи, чтобы домен знал, на какой сервер ему "смотреть".

Шаг 2: Настройка DNS

В панели управления reg.ru я прописал A-записи для поддоменов. Примерно через 5–10 минут домен уже начал резолвиться (хотя может и сильно дольше):

@ → IP моего сервера
www → тот же IP

Шаг 3: Установка Nginx

На сервере я поставил Nginx:

$ sudo apt install nginx -y

Шаг 4: Bash-скрипт для настройки проксирования

Чтобы не ковыряться руками в /etc/nginx/sites-available, я написал простой скрипт, который:

1) Создаёт конфиг для твоего домена
2) Проксирует запросы на нужный порт
3) Автоматически подключает SSL через certbot (сертификат безопасности, то самое "s" в https)

Запрашиваем данные, вводим домен и порт приложения, на который будет проксироваться nginx:

#!/bin/bash
read -p "Домен: (например, example.ru)" DOMAIN
read -p "Порт (например, 9003): " PORT

Задаем стандартные директории для конфигов и логов Nginx:

SITES_AVAILABLE="/etc/nginx/sites-available"
SITES_ENABLED="/etc/nginx/sites-enabled"
CONF_FILE="$SITES_AVAILABLE/$DOMAIN"
LOGS_DIR="/var/log/nginx/$DOMAIN"

Создаём папку для логов:

$ sudo mkdir -p "$LOGS_DIR"

Генерируем конфиг:

sudo tee "$CONF_FILE" > /dev/null <<EOF
server {
    listen 80;
    server_name $DOMAIN;
    location / {
        proxy_pass http://127.0.0.1:$PORT;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
    }
    error_log $LOGS_DIR/error.log;
    access_log $LOGS_DIR/access.log;
}
EOF

Включаем сайт

$ sudo ln -s "$CONF_FILE" "$SITES_ENABLED/$DOMAIN" 2>/dev/null

Проверка и перезапуск:

if sudo nginx -t; then
    sudo systemctl reload nginx
else
    exit 1
fi

Получаем SSL-сертификаты:

$ sudo certbot --nginx -d "$DOMAIN"

Финальная проверка и reload

if sudo nginx -t; then
    sudo systemctl reload nginx
else
    exit 1
fi

SSL-сертификаты от Let's Encrypt. Certbot сам всё сделал: прописал listen 443 ssl и нужные директивы, плюс настроил редирект с HTTP на HTTPS. Если хочешь, можешь вручную добавить в конфиг ssl_protocols, ssl_ciphers, HSTS и другие фишки безопасности, но базовая настройка уже работает.

В итоге после запуска скрипта твой сайт по HTTPS работает на нужном порту, все логи идут в /var/log/nginx/имя_домена/, и весь трафик проксируется на нужное приложение. Готовый скрипт:

#!/bin/bash

read -p "Домен: (например, example.ru)" DOMAIN
read -p "Порт (например, 9003): " PORT

SITES_AVAILABLE="/etc/nginx/sites-available"
SITES_ENABLED="/etc/nginx/sites-enabled"
CONF_FILE="$SITES_AVAILABLE/$DOMAIN"
LOGS_DIR="/var/log/nginx/$DOMAIN"

sudo mkdir -p "$LOGS_DIR"

sudo tee "$CONF_FILE" > /dev/null <<EOF
server {
listen 80;
server_name $DOMAIN;
location / {
proxy_pass http://127.0.0.1:$PORT;
proxy_set_header Host \$host;
proxy_set_header X-Real-IP \$remote_addr;
proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto \$scheme;
}
error_log $LOGS_DIR/error.log;
access_log $LOGS_DIR/access.log;
}
EOF

sudo ln -s "$CONF_FILE" "$SITES_ENABLED/$DOMAIN" 2>/dev/null

if sudo nginx -t; then
sudo systemctl reload nginx
else
exit 1
fi

sudo certbot --nginx -d "$DOMAIN"

if sudo nginx -t; then
sudo systemctl reload nginx
else
exit 1
fi

echo "Готово."

LinuxCamp | #devops #nginx #bymaga

Как очистить сервер от мусора

Со временем сервер обрастает мусором: логи, временные файлы, старые кэши. Разберем команды по удалению всего этого добра. Бонусом в конце будет готовый файл для запуска скрипта с логированием, который будет каждый день удалять все ненужное 🙂

Команда для удаления .log-файлов старше 7 дней:

$ find /var/log -type f -name "*.log" -mtime +7 -delete

find - команда поиска файлов
/var/log - папка, где хранятся логи
"-type f" - ищем только файлы
-name "*.log" - по шаблону *.log
"-mtime +7" - старше 7 дней
-delete - сразу удалять

Очистить systemd-журналы:

$ journalctl --vacuum-time=7d

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

Очистить временные файлы:

$ rm -rf /tmp/* /var/tmp/*

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

Очистить кэш и мусор после установки пакетов:

$ apt clean && apt autoremove -y

"apt clean" - очищает кэш установленных .deb файлов
"apt autoremove" - удаляет больше не нужные зависимости
"-y" - выполнять без лишних вопросов

Ниже прикладываю готовый файл. Его нужно будет сделать исполняемым и можно добавить в crontab с запуском в каждое воскресенье в 0:00. Все результаты будут сохраняться в файл "/var/log/server-cleanup.log":

#!/bin/bash

LOG_FILE="/var/log/server-cleanup.log"
echo "[$(date)] Очистка начата" >> "$LOG_FILE"

find /var/log -type f -name "*.log" -mtime +7 -delete >> "$LOG_FILE" 2>&1
journalctl --vacuum-time=7d >> "$LOG_FILE" 2>&1
rm -rf /tmp/* /var/tmp/* >> "$LOG_FILE" 2>&1
apt clean && apt autoremove -y >> "$LOG_FILE" 2>&1

echo "[$(date)] Очистка завершена" >> "$LOG_FILE"

$ sudo chmod +x /usr/local/bin/clean-server.sh

$ sudo crontab -e

0 0 * * 0 /usr/local/bin/clean-server.sh

LinuxCamp | #devops #utils

Systemd Timer - альтернатива cron

Если ты используешь cron для запуска скриптов по расписанию - пора бы взглянуть в сторону systemd timer. Это часть системы systemd - более новый и с фишками, которых нет в cron. Разберёмся, зачем он нужен и как с ним работать.

Что умеет systemd timer

systemd timer позволяет запускать задачи по расписанию вместо или в дополнение к cron. Отличается он несколькими вещами:

1) Привязан к сервису systemd (можно логировать, отслеживать статус, перезапускать);
2) Логирует всё через journalctl (никаких потерянных логов). Можно быстро проверить, когда скрипт реально запускался и с каким результатом;
3) Флаг "Persistent=true" позволяет выполнить задачу после включения сервера, если она была пропущена во время выключения;
4) Можно задавать зависимости, например, чтобы очистка выполнялась только после поднятия сети, или после других сервисов;
5) Более гибкое расписание такого вида "OnCalendar=Wed 09:44";

Пример запуска скрипта.

Возьмём тот, что был в прошлом посте. Создадим юнит для сервиса:

$ nano /etc/systemd/system/clean-server.service

[Unit]
Denoscription=Автоматическая еженедельная очистка сервера

[Service]
Type=oneshot
ExecStart=/usr/local/bin/clean-server.sh

Создаем таймер:

nano /etc/systemd/system/clean-server.timer

[Unit]
Denoscription=Таймер для еженедельной очистки сервера

[Timer]
OnCalendar=Sun 02:00
Persistent=true

[Install]
WantedBy=timers.target

Активируем:

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl enable --now clean-server.timer

Можем проверить статус:

systemctl list-timers | grep clean-server

И посмотреть те самые автоматические логи:

systemctl status cleanup-server.timer
# или
journalctl -u clean-server.timer 

Короч, systemd timer - более современный способ управлять задачами по расписанию. Он не заменяет cron полностью, но стоит внимания в большом количестве случаев.

LinuxCamp | #utils #cron

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

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

1) без английского у меня ничего не получится;
2) обязательно нужно высшее образование;
3) я не потяну эту науку;
4) смысл мне начинать, если AI через пару лет всех заместит;

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

А там уже все, если и опыт есть, начнешь пожинать плоды своих трудов и радоваться жизни. На самом деле, огромные перспективы открываются.

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

Смотреть на YouTube

Что такое Ansible - и как обновить пакеты сразу на 10 серверах

Ansible - это инструмент для автоматизации. Он позволяет управлять сотнями серверов как одним: обновлять, настраивать, перезапускать сервисы - всё с помощью простого playbook (набор команд в YAML-файле).

Для начала нужно скачать Ansible:

sudo apt install ansible -y

Вот минимальный пример update.yml:

- name: Обновление пакетов
  hosts: all
  become: yes  # получаем root-доступ
  tasks:
    - name: apt update && upgrade
      apt:
        update_cache: yes
        upgrade: dist

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

hosts: all - применяем ко всем серверам из инвентаря
become: yes - выполняем от имени root
apt: - встроенный модуль Ansible для Debian/Ubuntu

Запуск:

ansible-playbook -i inventory update.yml

Для подробностей можно добавить -v или -vvv:

ansible-playbook update.yml -vvv

А если хочешь сначала посмотреть, что бы изменилось, но не выполнять, используй режим dry run:

ansible-playbook update.yml --check

LinuxCamp | #utils

Caddy - замена Nginx с авто-TLS и минимальной настройкой

Ты наверняка используешь Nginx как прокси-сервер или для выдачи статики. Но есть более свежий и удивительно простой веб-сервер - Caddy. Он сам получит HTTPS, сам перезапустится при изменении конфига и вообще просит к себе минимум внимания. Разбираемся, чем он крут.

Caddy — это современный веб-сервер, написанный на Go. Его главная фишка — всё работает из коробки:

1) Автоматический HTTPS от Let's Encrypt
2) Перезапуск при изменении конфига
3) Встроенный reverse proxy
4) Простая конфигурация (Caddyfile)

Установка:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy.gpg

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

sudo apt update
sudo apt install caddy

Минимальный пример Caddyfile:

example.com {
  reverse_proxy localhost:3000
}

- Заменяешь "example.com" на свой домен
- localhost:3000 (твой сервис);

Запуск сервера

Caddy работает как systemd-сервис. Чтобы запустить или перезапустить:

sudo systemctl restart caddy

После этого caddy сам проверит домен, получит HTTPS-сертификат от Let's Encrypt, настроит прокси и всё заработает)

Почему это удобно

- Не нужно возиться с SSL — HTTPS работает из коробки
- Конфигурация проще, чем у Nginx
- Отлично подходит для pet-проектов, демо, VPS-серверов

Когда лучше остаться с Nginx

1) Если у тебя уже сложная конфигурация с множеством rewrite, map, ssl_params
2) Если нужна кастомная сборка модулей
3) Если используешь stream (TCP/UDP proxy)

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

Оптимизация 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

Команда 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

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

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

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