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 926 مشتركاً، محتلاً المرتبة 9 160 في فئة التكنولوجيات والتطبيقات والمرتبة 47 344 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 13 926 مشتركاً.
بحسب آخر البيانات بتاريخ 09 يوليو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار -116، وفي آخر 24 ساعة بمقدار -26، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 21.35%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 11.55% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 2 974 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 608 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 24.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل linuxcamp, ядро, linux, диск, docker.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Обо мне: C/C++/Linux эксперт. Говорим про разработку, Linux, DevOps, сети и администрирование.
Админ (реклама): @XoDefender
Чат: @linuxcamp_chat
Менеджер: @Spiral_Yuri
Биржа: https://telega.in/c/linuxcamp_tg
РКН: https://clck.ru/3RWA3C”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 10 يوليو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
Код, видео, документация — все это останется в открытом доступе для изучения, форка или переработки. Я искренне надеюсь, что другие найдут в этом вдохновение, как когда-то нашел я в сообществеLinuxCamp | #news
$ sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
loop0 4K /snap/bare/5 sda 104G ├─sda1 vfat 1G /boot/efi ├─sda2 ext4 2G /boot ... sdb 500G ├─sdb1 ntfs 500G /media/root-user/C2D8...USB-диск объемом 500 ГБ маркирован как sdb1. Для его размонтирования следует выполнить команду:
$ sudo umount /dev/sdb1
В результате диск отсоединится. Вы можете посмотреть, что он пропал из списка доступных устройств в файловом менеджере.
Если диск в настоящий момент занят, то возникнет ошибка. С помощью опции "-l" его получится размонтировать, когда он освободится:
$ sudo umount -l /dev/sdb1
Для принудительного отключения можно использовать флаг "-f". Все выполняемые операции незамедлительно прервутся, и ждать ничего не придется:
$ sudo umount -f /dev/sdb1
Размонтировать все устройства
Опция "-a" отвечает за размонтирование всех файловых систем. Eсть несколько разделов с исключениями: roc, devfs, devpts, sysfs, rpc_pipefs и nfsd. Запускать ее нужно с осторожностью:
$ sudo umount -a
Перед выполнением команды вы можете посмотреть то, какие устройства будут затронуты. Тут пригодятся опции "--fake" и "-v" для вывода подробной информации:
$ sudo umount --fake -v -a
/run/user/1000/doc: successfully unmounted
/snap/firefox/6015: successfully unmounted
...
В результате отобразится полный список путей и устройств, которые будут размонтированы.
Размонтировать путь
Если вы хотите отключить конкретный путь от корневой FS, то подход будет иной.
В качестве примера возьмем каталог "/run/lock/tmpfs". Команда для размонтирования будет выглядеть следующим образом:
$ sudo umount /run/lock/tmpfs
Рекурсивное размонтирование
Для рекурсивного размонтирования определенной директории, к описанной выше команде следует добавить опцию "-R":
$ sudo umount -R /run/lock/tmpfs
Если же вы хотите получить дополнительную информацию при рекурсивном размонтировании, то воспользуйтесь опцией "-v":
$ sudo umount -R -v /run/lock/tmpfs
LinuxCamp | #utils- .dockerignore - Dockerfile - compose.yaml - README.Docker.mdУстанавливаем Docker Desktop на устройство если не установлен. Если не имели раньше дела с
mkdir my-fastapi-project
cd my-fastapi-project
Создаем и активируем виртуальное окружение чтобы изолировать зависимости проекта и с помощью команды pip freeze автоматически сформировать requirements.txt, не заполняя его вручную:
python3 -m venv venv
source venv/bin/activate
Cкачиваем необходимые для создания API зависимости с помощью пакетного менеджера pip и сохраняем их в requirements.txt:
pip install fastapi uvicorn
pip freeze > requirements.txt
Создадим в каталоге проекта файл "main.py" с простым API:
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def root():
return {"Hello": "Docker Init"}
Теперь наконец можем запустить магию:
docker init
Нас встречает приветственное сообщение, которое просит нас выбрать язык проекта (python), его версию (3.12.7), порт на котором будет слушать приложение (8000). Далее нужно вписать команду для запуска. Он увидел что я работаю с fastapi и предлагает:
uvicorn 'main:app' --host=0.0.0.0 --port=8000
И тут видим, что автоматически были созданы перечисленные в начале файлы! Далее можем абсолютно спокойно поднять контейнер командой:
docker compose up --build
Дожидаемся пока сбилдится наше приложение и проверяем все ли ок. Переходим в браузер и видим заветное:
http://127.0.0.1:8000
{"Hello":"Docker Init"}
LinuxCamp | #devops #docker #bymaga #win
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "127.0.0.1", "--port", "8000"]
Его и разберем построчно:
1) FROM - команда, которая создает базовый образ. В нашем случае это python:3.11-slim. Но что это и откуда берется? - из Docker Hub!
То есть мы буквально скачиваем зависимость с официального репозитория образов. В хабе имеются образы на многие технологии, языки, базы данных и фреймворки, так что найти нужную базу под проект не будет проблемой.
python:3.11-slim — это официальный образ Python версии 3.11 в минималистичной вариации "slim";
2) WORKDIR - создает рабочую директорию проекта, в которой все команды будут выполняться. Также как и большинство инструкций, создает новый слой;
3) COPY - копирует файлы с хоста в контейнер. Можно заметить, что данная команда выполняется дважды в файле.
Сначала копируется только файл requirements.txt для того, чтобы разделить установку зависимостей и основной код. Это делается ради кэширования слоёв: файл зависимостей меняется редко, и при пересборке будет использоваться уже готовый слой;
4) RUN - выполняет команду внутри контейнера на этапе сборки и создаёт новый слой. В данном случае ставит зависимости из requirements.txt;
5) Ещё один "COPY . ." — теперь закидываем остальной код проекта в контейнер.
6) Последняя инструкция CMD - не создает новый слой, там указаны команды которые выполняются при запуске контейнера. В нашем Dockerfile выполняются команды запуска fastapi-приложения:
— "uvicorn" - сервер, который запускает fastapi-приложение
— "main:app" - main — это имя файла python, а app — это объект fastapi внутри этого файла.
— "--host", "127.0.0.1" - указывает, что сервер будет слушать на локальном интерфейсе.
— "--port", "8000" - указывает порт, на котором работает приложение.
LinuxCamp | #devops #docker #bymaga
$ find ~/Downloads -type f -mtime +35
Следующий шаг – непосредственно чистка:
$ find ~/Downloads -type f -mtime +35 -delete
Вам необязательно действовать напрямую и стирать сразу же все файлы. Их можно отсортировать дополнительно по еще одному признаку, например, по названию или расширению. Для этого есть опция "-name":
$ find ~/Downloads -name "*.zip" -type f -mtime +35 -delete
Также, чтобы сгоряча не удалить нужный и недавно используемый файл, можно для каждого элемента вывода выполнить "ls -l" и посмотреть дату последнего изменения ресурса:
$ find ~/Downloads -type f -mtime +5 -exec ls -l {} \;
... Feb 17 17:30 ./file
LinuxCamp | #microhelp #utils
$ tail -f /var/log/syslog
Если нужно отображать больше последних строк, чем по дефолту, дописывайте флаг "-n". Когда дополнительно нужно прогнать вывод через фильтр, grep в помощь:
$ tail -n 100 -f /var/log/nginx/access.log
$ tail -f /var/log/nginx/error.log | grep "timeout"
Я помню, как сам мучился с дебагом, когда не был в курсе про этот чудо-флаг) Дело в том, что не все приложения выдают лог в консоль. Если вы работаете с демоном, то у него нет управляющего терминала и все идет в журналы. Как раз тут и было бы весьма удобно использовать "tail -f".
LinuxCamp | #microhelp #utils
$ echo $XDG_SESSION_TYPE
wayland
Кроме того, можно узнать тип текущей сессии с помощью loginctl. Для этого нужно сначала вывести список активных сессий через list-sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
3 1000 parallels seat0 tty2
c1 127 gdm seat0 tty1
2 sessions listed.
Потом выводим тип конкретной сессии через опцию show-session:
$ loginctl show-session 3 -p Type
Type=wayland
Или можно сделать всё одной командой, получив идентификатор сессии из переменной окружения XDG_SESSION_ID (если определена):
$ loginctl show-session "$XDG_SESSION_ID" -p Type
LinuxCamp | #microhelp #sessions
$ systemctl status docker
docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled;>
Active: active (running) since ...
Давайте рассмотрим полный вывод:
Loaded - означает что файл юнита загружен успешно и здесь же выводится путь к этому файлу.
Тут возможны и другие значения, например, masked если юнит скрыт или not-found если он не найден. Также здесь находится информация добавлен ли юнит в автозагрузку (enabled/disabled);
Active - текущее состояние и подсостояние юнита, если он запущен, выводится active(running), если он не был запущен, то inactive(dead) если что-то пошло не так, failed и т.д.
Docs - название man страницы с документацией для службы.
Process - запускаемые процессы, их состояние и код выхода.
Main PID - идентификатор основного процесса службы.
Tasks - количество процессов, запущенных в рамках этой службы.
Memory - потребление памяти службой.
CPU - использование процессора службой.
Для того чтобы посмотреть все доступные значения состояний для полей Loaded и Active выполните:
$ systemctl --state help
Списочек получите некороткий) За доп. инфой направлю вас в man.
После всех полей статуса выводится журнал службы - последние 10 строк вывода основного процесса.
Если хотите получить больше строк, используйте опцию "--lines" с нужным количеством:
$ systemctl status --lines=50 avahi-daemon
LinuxCamp | #systemd