DevOps Portal | Linux
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
Показати більше📈 Аналітичний огляд Telegram-каналу DevOps Portal | Linux
Канал DevOps Portal | Linux (@loose_code) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 13 085 підписників, посідаючи 9 390 місце в категорії Технології та додатки та 49 413 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 13 085 підписників.
За останніми даними від 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