DevOps Portal | Linux
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
Больше📈 Аналитический обзор Telegram-канала DevOps Portal | Linux
Канал DevOps Portal | Linux (@loose_code) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 13 084 подписчиков, занимая 9 390 место в категории Технологии и приложения и 49 413 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 13 084 подписчиков.
Согласно последним данным от 31 августа, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило 15, а за последние 24 часа — -1, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 17.56%. В первые 24 часа после публикации контент обычно набирает 9.58% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 2 298 просмотров. В течение первых суток публикация набирает 1 254 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 9.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как devops, kubernetes, docker, linux, ebpf.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps
Сотрудничество, реклама: @devmangx
Менеджер: @Spiral_Yuri
РКН: https://clck.ru/3P8kFH”
Благодаря высокой частоте обновлений (последние данные получены 01 сентября, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
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