LinuxCamp | DevOps
Обо мне: C/C++/Linux эксперт. Говорим про разработку, Linux, DevOps, сети и администрирование. Админ (реклама): @XoDefender Чат: @linuxcamp_chat Менеджер: @Spiral_Yuri Биржа: https://telega.in/c/linuxcamp_tg РКН: https://clck.ru/3RWA3C
Mostrar más📈 Análisis del canal de Telegram LinuxCamp | DevOps
El canal LinuxCamp | DevOps (@linuxcamp_tg) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 13 959 suscriptores, ocupando la posición 9 131 en la categoría Tecnologías y Aplicaciones y el puesto 47 183 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 13 959 suscriptores.
Según los últimos datos del 06 julio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -98, y en las últimas 24 horas de -3, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 27.85%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 10.66% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 3 888 visualizaciones. En el primer día suele acumular 1 489 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 23.
- Intereses temáticos: El contenido se centra en temas clave como linuxcamp, ядро, linux, диск, docker.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Обо мне: C/C++/Linux эксперт. Говорим про разработку, Linux, DevOps, сети и администрирование.
Админ (реклама): @XoDefender
Чат: @linuxcamp_chat
Менеджер: @Spiral_Yuri
Биржа: https://telega.in/c/linuxcamp_tg
РКН: https://clck.ru/3RWA3C”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 07 julio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
# 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
¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
