LinuxCamp | DevOps
Обо мне: C/C++/Linux эксперт. Говорим про разработку, Linux, DevOps, сети и администрирование. Админ (реклама): @XoDefender Чат: @linuxcamp_chat Менеджер: @Spiral_Yuri Биржа: https://telega.in/c/linuxcamp_tg РКН: https://clck.ru/3RWA3C
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام LinuxCamp | DevOps
تُعد قناة LinuxCamp | DevOps (@linuxcamp_tg) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 13 959 مشتركاً، محتلاً المرتبة 9 131 في فئة التكنولوجيات والتطبيقات والمرتبة 47 183 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 13 959 مشتركاً.
بحسب آخر البيانات بتاريخ 06 يوليو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار -98، وفي آخر 24 ساعة بمقدار -3، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 27.85%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 10.66% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 3 888 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 489 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 23.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل linuxcamp, ядро, linux, диск, docker.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Обо мне: C/C++/Linux эксперт. Говорим про разработку, Linux, DevOps, сети и администрирование.
Админ (реклама): @XoDefender
Чат: @linuxcamp_chat
Менеджер: @Spiral_Yuri
Биржа: https://telega.in/c/linuxcamp_tg
РКН: https://clck.ru/3RWA3C”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 07 يوليو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
# 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 | #utilsss [опции]Полезные команды: Кто слушает 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 -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 #microhelpwatch [-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
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
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
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
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
$ 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
متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
