DevOps Portal | Linux
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
Ko'proq ko'rsatish📈 Telegram kanali DevOps Portal | Linux analitikasi
DevOps Portal | Linux (@loose_code) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 13 084 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 9 390-o'rinni va Rossiya mintaqasida 49 413-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 13 084 obunachiga ega bo‘ldi.
31 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 15 ga, so‘nggi 24 soatda esa -1 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 17.56% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 9.58% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 298 marta ko‘riladi; birinchi sutkada odatda 1 254 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 9 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent devops, kubernetes, docker, linux, ebpf kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps
Сотрудничество, реклама: @devmangx
Менеджер: @Spiral_Yuri
РКН: https://clck.ru/3P8kFH”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 01 Sentabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
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