Базовая настройка 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]
Description=Автоматическая еженедельная очистка сервера

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

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

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

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

[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

Что такое 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

Нагрузочное тестирование с помощью 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 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

Что такое 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