DevOps Portal | Linux
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
Show more📈 Analytical overview of Telegram channel DevOps Portal | Linux
Channel DevOps Portal | Linux (@loose_code) in the Russian language segment is an active participant. Currently, the community unites 13 085 subscribers, ranking 9 390 in the Technologies & Applications category and 49 413 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 13 085 subscribers.
According to the latest data from 31 August, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 15 over the last 30 days and by -1 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 17.56%. Within the first 24 hours after publication, content typically collects 9.58% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 298 views. Within the first day, a publication typically gains 1 254 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 9.
- Thematic interests: Content is focused on key topics such as devops, kubernetes, docker, linux, ebpf.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps
Сотрудничество, реклама: @devmangx
Менеджер: @Spiral_Yuri
РКН: https://clck.ru/3P8kFH”
Thanks to the high frequency of updates (latest data received on 01 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
docker ps -a
Эта команда выводит список всех контейнеров, их идентификаторы, имена, статус и время работы. В колонке "STATUS" можно увидеть текущее состояние контейнера, например:
- Up X hours — контейнер работает.
- Exited (code) — контейнер завершил работу с определённым кодом выхода.
2️⃣ Проверить состояние конкретного контейнера:
Используйте команду docker inspect, чтобы получить подробную информацию о состоянии контейнера:
docker inspect <container_id>
Эта команда выводит всю информацию о контейнере, включая статус, ошибки, время работы и другие параметры. Для удобства можно использовать фильтрацию JSON-вывода, например:
docker inspect -f '{{.State.Status}}' <container_id>
Возможные статусы:
- running — контейнер запущен.
- exited — контейнер завершил работу.
- paused — контейнер приостановлен.
- restarting — контейнер перезапускается.
3️⃣ Проверить логи контейнера:
Чтобы увидеть последние действия контейнера, можно просмотреть его логи:
docker logs <container_id>Это поможет понять, что происходило с контейнером, особенно если он неожиданно завершил работу. 👉 DevOps Portal
bash type testИ видим: test is a shell builtin. То есть используется команда test встроенная в оболочку. А не та что лежит на пути в test: /usr/bin/test. Воспользуемся дисковой версией этой утилиты:
enable -n test
type test
И получим такое: test is /usr/bin/test. Получается мы сделали некое переключение. И по факту используем разные версии test.
Чтобы включить обратно встроенную команду test в оболочке, выполняем:
enable test
Можно подгрузить расширения поставляемые с оболочкой. Некие плагины, экстеншены. Для этого эти экстеншены нужно установить:
apt/yum install bash-builtins
Оно установится в папку /usr/lib/bash/. В ней будут всякие mkdir, rm, sleep и т.п. По сути это те же дисковые команды, только экстеншены для оболочки.
Для начала узнаем дисковую версию команды mkdir:
mkdir --version
mkdir (GNU coreutils) 8.32
Теперь загружаем экстеншен в оболочку:
enable -f /usr/lib/bash/mkdir mkdir
mkdir --version
Получаем такое: -bash: mkdir: --: invalid option
Теперь запускаем:
type mkdir
Видим: mkdir is a shell builtin, то есть теперь mkdir используется не системный (дисковый), а тот что подгружен в оболочку bash.
Например, мы снесли все системные бинарники и остался только bash. Через подгрузку экстеншенов можно без проблем обслуживать свою операционную систему, даже если в системе пропал mkdir и т.п.
Чтобы посмотреть что вообще подгружено в оболочку, воспользуемся командой:
lsof +fg -p $$
Получим отчет по текущему процессу, что подгружено в данный момент в оболочку и используется.
С версии 4.4 в bash появилась переменная BASH_LOADABLES_PATH, с помощью нее можно задать путь для поиска экстеншенов. Тогда при подгрузке этих модулей, не нужно будет использовать полные пути.
BASH_LOADABLES_PATH=/usr/lib/bash/
enable -f sleep sleep
👉 DevOps Portal[[ -r ~/.bashrc ]] && . ~/.bashrc
Другие оболочки ведут себя по-другому. Например, в zsh, файл .zshrc всегда читается для интерактивной оболочки, независимо от того, является ли она login или нет.
А файл .profile, это просто сценарий входа в систему. И изначально использовался в /bin/sh. Оболочка Bash, будучи обратно совместимым с sh, будет читать .profile, если он конечно же существует.
Пример файла .profile
if [ "$BASH" ]; then
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
fi
Как видим, при login’е заинклудится файл .bashrc.
В дистрибутивах семейства Debian сначала выполняется .profile, а потом уже .bash_profile. А вот в дистрибах производных от RHEL, сначала выполняется .bash_profile, а уже потом .profile. Ну вот прям каша!
В документации bash хорошо объясняется, при каких обстоятельствах читается каждый файл. И поведение на разных машинах в целом одинаково.
Выжимка из man bash:
/bin/bash - The bash executable
/etc/profile - The systemwide initialization file, executed for login shells
/etc/bash.bashrc - The systemwide per-interactive-shell startup file
/etc/bash.bash.logout - The systemwide login shell cleanup file, executed when a login shell exits
~/.bash_profile - The personal initialization file, executed for login shells
~/.bashrc - The individual per-interactive-shell startup file
~/.bash_logout - The individual login shell cleanup file, executed when a login shell exits
~/.inputrc - Individual readline initialization file
👉 DevOps Portal# switch to another cluster that's in kubeconfig $ kubectx minikube Switched to context «minikube». # switch back to previous cluster $ kubectx - Switched to context «oregon». # rename context $ kubectx dublin=gke_ahmetb_europe-west1-b_dublin Context «gke_ahmetb_europe-west1-b_dublin» renamed to «dublin». # change the active namespace on kubectl $ kubens kube-system Context «test» set. Active namespace is «kube-system». # go back to the previous namespace $ kubens - Context «test» set. Active namespace is «default».Установка Можно установить с помощью Krew:
kubectl krew install ctx
kubectl krew install ns
После установки инструменты будут доступны в виде kubectl ctx и kubectl ns.
Еще можно установить так:
brew install kubectx
и так:
sudo apt install kubectx
👉 DevOps Portal | #ресурсыКоманда yes служит для вывода в стандартный поток (stdout) строки «y» или любой другой строки. Если ее запустить по умолчанию, команда будет бесконечно сыпать строку «y».Например, есть у вас консольная команда, которая во время своей работы будет запрашивать подтверждение: а вы точно уверены, что удаляете тестовую базу данных? Вот на такие случаи и нужна команда «yes», чтобы не руками вводить подтверждение, а делегировать это действие. Полезно для пайплайнов. Бывает такое, что у программы нет ключей типа apt -y install, а подтверждать как-то в автоматическом режиме нужно. Синтаксис проброса стандартный, через систему пайпов:
yes | apt install nginx
В примере выше, когда пакетный менеджер попросит нажать Y, команда «yes» автоматически это сделает и начнется процесс установки.
Не забываем, про передачу аргументов, если внешняя программа например хочет чтобы вы ввели слово: «hello» делаем так:
yes hello | apt install nginx
Но обычно на практике, в 99% случаев команда «yes» запускается без аргументов, так как большинство запрашивает именно Yes.Если есть команда «yes», значит должна быть и «no». Но увы 😁. Так вот если нужно отменить, передайте в «yes» аргументом строку «no». Что-то может запросить простого нажатия Enter, например когда в репозиторий добавляется gpg ключ. Как послать Enter? А вот так:
yes "" | <твоя команда>
Это сработает как Enter потому, что команда «yes» выводит в stdout не просто сроку Y, но еще и завершает ее в конце символом Enter. Вот именно поэтому при запуске чистого «yes», строчки на экране будут идти столбиком.👉 DevOps Portal
CONFIG_ZSWAP_DEFAULT_ON=N
Но чтобы применить эту опцию, нужно пересобрать ядро. Пойдем легким путем и выключим zswap через загрузчик grub.
Редактируем файл /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="zswap.enabled=0" loglevel=3 quiet "
Не забываем перегенирировать конфиг grub:
grub-mkconfig -o /boot/grub/grub.cfg
Перезагружаем машину и проверяем отключение zswap:
cat /sys/module/zswap/parameters/enabled
Если вывелась буква N — значит все правильно.
Ну и наконец включаем zram. Для этого пишем bash скрипт и кидаем его в автозагрузку:
#!/bin/bash
modprobe zram
mkdir /sys/block/zram0
echo lz4 > /sys/block/zram0/comp_algorithm
echo 1G > /sys/block/zram0/disksize
echo 2 > /sys/block/zram0/max_comp_streams
mkswap --label zram0 /dev/zram0
swapon --priority 100 /dev/zram0
1. Загружаем модуль zram
2. Выбираем алгоритм сжатия lz4 (либо zstd)
3. Объем zram 1гиг физической оперативки
4. 2 это количество потоков сжатия (потоки процессора)
5. Создаем блочное устройство и включаем его
Запускаем скрипт и проверяем включение командой: zramctl. Если на экран что-то вывелось, значит всё хорошо и сжатие начало работать.
Если заморачиваться с bash скриптами не хочется, ставим утилиту которая будет работать через systemd.
apt install systemd-zram-generator
Правим конфиг /etc/systemd/zram-generator.conf
[zram0]
zram-size = ram
compression-algorithm = lz4
Активируем и запускаем:
systemctl daemon-reload
systemctl start /dev/zram0
Всё! Теперь оно само будет запускаться без лишних движений.
👉 DevOps Portal