DevOps Portal | Linux

🧠 Machine Learning — авторский канал, где собрана вся база по ИИ и машинному обучению. Senior разработчик AI-алгоритмов и автономных агентов, разбирает гайды, редкую литературу и код топовых моделей машинного обучения и искусственного интеллекта. В 2025 году ИИ выйдет на совершенно новый уровень тот, кто не успеет за прогрессом - отстанет, а кто разберется - сорвет куш. Стоит подписаться: t.me/ai_machinelearning_big_data

Программа сообщает о том, что не может найти свой конфиг. Каким образом можно узнать, где она пытается его найти? line-buffered опция которая выведет результат как только найдет strace -f — отслеживание дочерних процессов strace -f l ftp sitename | & grep --line-buffered open | grep /home/user Либо в самой программе, если удастся найти параметры /usr/sbin/mysqld --verbose --help | grep -A 1 «Default options» 👉 DevOps Portal

Dockly Это интерактивный терминальный интерфейс для управления контейнерами Docker. Утилита позволяет в режиме реального времени просматривать активные контейнеры, образы и сети, выполнять команды, такие как перезапуск или удаление контейнеров, а также получать доступ к их логам и ресурсам. Подходит для разработчиков и администраторов, которым нужен быстрый и удобный способ мониторинга и управления Docker-средами. 👉 https://github.com/lirantal/dockly 👉 DevOps Portal | #ресурсы

Linux. Карманный справочник. 4-е изд Автор: Дэниел Джей Год: 2024 📂 Скачать книгу 👉 DevOps Portal | #книги

✅️ GitHub теперь в Telegram! Подписывайтесь: @GitHub

Чем отличается CMD от ENTRYPOINT в Dockerfile? Инструкции CMD и ENTRYPOINT выполняются в момент запуска контейнера, тольо инструкция CMD позволяет переопределить передаваемые команде аргументы. Пример 1. CMD: Опишем сборку образа в Dockerfile. FROM alpine CMD ["ping", "8.8.8.8"] В инструкцию CMD передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер. $ docker run test PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=43 time=32.976 ms 64 bytes from 8.8.8.8: seq=1 ttl=43 time=31.998 ms 64 bytes from 8.8.8.8: seq=2 ttl=43 time=31.843 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 31.708/33.316/36.823 ms Теперь передадим 2 новых аргумента для запуска контейнера. $ docker run test traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets 1 172.17.0.1 (172.17.0.1) 0.017 ms 0.016 ms 0.009 ms 2 192.168.168.1 (192.168.168.1) 0.996 ms 1.553 ms 2.069 ms 3 * * * 4 lag-2-435.bgw01.samara.ertelecom.ru (85.113.62.125) 1.454 ms 1.427 ms 1.984 ms 5 172.68.8.3 (172.68.8.3) 19.685 ms 15.722 ms 15.565 ms 6 172.68.8.2 (172.68.8.2) 15.846 ms 22.696 ms 35.093 ms 7 one.one.one.one (1.1.1.1) 17.439 ms 17.670 ms 24.202 ms ping заменен на traceroute, IP адрес заменен на 1.1.1.1. Пример 2. ENTRYPOINT: Опишем сборку образа в Dockerfile. FROM alpine ENTRYPOINT ["ping", "8.8.8.8"] В инструкцию ENTRYPOINT передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер. $ docker run test2 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=43 time=36.189 ms 64 bytes from 8.8.8.8: seq=1 ttl=43 time=44.120 ms 64 bytes from 8.8.8.8: seq=2 ttl=43 time=44.584 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 36.189/41.631/44.584 ms Теперь передадим изменим один из аргументов для запуска контейнера. $ docker run test2 ping 1.1.1.1 BusyBox v1.31.1 () multi-call binary. Usage: ping [OPTIONS] HOST Send ICMP ECHO_REQUEST packets to network hosts -4,-6 Force IP or IPv6 name resolution -c CNT Send only CNT pings -s SIZE Send SIZE data bytes in packets (default 56) -i SECS Interval -A Ping as soon as reply is recevied -t TTL Set TTL -I IFACE/IP Source interface or IP address -W SEC Seconds to wait for the first response (default 10) (after all -c CNT packets are sent) -w SEC Seconds until ping exits (default:infinite) (can exit earlier with -c CNT) -q Quiet, only display output at start and when finished -p HEXBYTE Pattern to use for payload Как видим, аргумент передать контейнеру нельзя. 👉 DevOps Portal

KodeKloud Free Labs — площадка c интерактивными заданиями и реальными сценариями, которые помогут погрузиться в практическое применение принципов DevOps и облачных технологий, не выходя из браузера. В бесплатных лабах сейчас есть: Linux, Кубер, Docker, GiT, Python и прочие прелести. 👉 DevOps Portal | #ресурсы

Учишь Python, но как дело доходит до собственного кода — всё, кирдык? 😥 На форумах только одно: «Больше практиковаться!» А толку? Ноль понимания и никакой поддержки от профи… Плавали - знаем)) Поэтому специально для тебя - чат для начинающих и продолжающих Python-щиков 🤝 Что получишь? 1️⃣ Сможешь задавать любые вопросы без страха и осуждения и получать ответы за минуты, а не часы поиска в инете 2️⃣ Регулярные плюшки в виде стримов от препода с 15-ти летним опытом 3️⃣ Общение с единомышленниками и заряд мотивации ➡️ А еще, забирай в закрепе БЕСПЛАТНЫЙ вводный курс по Python Короче, всё для прокачки! Залетай к нам — ссылка на чат (тык)

💡 Короткий совет по Linux Если вы хотите очистить пустые каталоги, команда find может упростить эту работу: $ find . -type d -empty -exec rmdir -v {} + Параметр -type d выполняет поиск каталогов, -empty выбирает пустые каталоги, а -exec rmdir {} выполняет команду rmdir для их удаления. Команда rmdir гарантирует, что каталог пуст перед его удалением. В качестве альтернативы, вы также можете использовать эту команду для выполнения той же задачи: $ find . -type d -empty -delete 👉 DevOps Portal

Мониторинг сети с помощью Python: Начни с SNMP и PySNMP Мониторинг сетевой инфраструктуры — это основа стабильной работы ИТ-экосистемы. С помощью Python и библиотеки PySNMP можно собрать данные о состоянии устройств и использовать их для анализа или визуализации. Сегодня рассмотрим пример простого скрипта для сбора информации через SNMP. Что такое SNMP? SNMP (Simple Network Management Protocol) — это стандартный протокол управления сетями. Он используется для: 🔹Сбора метрик с устройств (CPU, память, трафик интерфейсов). 🔹Отправки уведомлений о событиях. 🔹Управления конфигурацией. Установка PySNMP Для работы установим библиотеку PySNMP:

pip install pysnmp

Пример скрипта: Сбор метрик интерфейса Вот пример кода, который получает статистику интерфейса по OID:

from pysnmp.hlapi import *

# Укажите параметры устройства
snmp_target = '192.168.1.1'
community = 'public'
oid = '1.3.6.1.2.1.2.2.1.10.1'  # OID для входящего трафика интерфейса

# Запрос SNMP
def get_snmp_data(target, community, oid):
    iterator = getCmd(
        SnmpEngine(),
        CommunityData(community, mpModel=0),
        UdpTransportTarget((target, 161)),
        ContextData(),
        ObjectType(ObjectIdentity(oid))
    )
    error_indication, error_status, error_index, var_binds = next(iterator)

    if error_indication:
        print(f"Error: {error_indication}")
    elif error_status:
        print(f"Error: {error_status.prettyPrint()}")
    else:
        for var_bind in var_binds:
            print(f"{var_bind[0]} = {var_bind[1]}")

# Выполнение запроса
get_snmp_data(snmp_target, community, oid)

Как это работает: 1. getCmd выполняет запрос на устройство по указанному OID. 2. CommunityData указывает тип доступа (public — стандартное имя сообщества для чтения). 3. Результат содержит текущую метрику (например, объем входящего трафика на интерфейсе). Применение: 🔹Получите данные о загрузке процессора, памяти или состоянии интерфейсов. 🔹Интегрируйте скрипт в существующую систему мониторинга. 🔹Расширьте функционал для уведомлений или построения графиков. Что дальше? Для визуализации собранных данных можно использовать библиотеки, такие как Matplotlib или Pygal. Это позволяет легко строить графики, показывающие состояние сети. 👉 DevOps Portal

😎 PyLinux — мощное сообщество для тех, кто изучает Python и хочет начать разбираться в Linux! ➡️ Почему не стоит упустить: - удобные инструменты Linux - bash скрипты и гайды - библиотеки и полезные материалы по Python - а также, многое другое! 🔥 Заходи прямо сейчас, чтобы не потерять - PyLinux!

🐧 Управление процессами в Linux: как держать систему под контролем Разберем, как мониторить процессы, управлять их состоянием и настраивать автоматическое выполнение задач. Процесс — это программа, запущенная в системе. У каждого процесса есть уникальный идентификатор (PID), родительский процесс (PPID) и состояние (активный, спящий и т. д.). Основные действия с процессами: 🔹Мониторинг — отслеживание текущих процессов. 🔹Управление — остановка, возобновление, изменение приоритетов. 🔹Планирование — настройка задач для автоматического выполнения. Команды для работы с процессами 1️⃣Мониторинг процессов 🟢 Просмотр активных процессов:

ps aux

Выводит список всех процессов с подробной информацией: 🔹USER — пользователь, запустивший процесс. 🔹PID — уникальный идентификатор процесса. 🔹%CPU / %MEM — использование процессора и памяти. 🔹COMMAND — название программы. 🟢 Интерактивный мониторинг:

top

Показывает процессы в реальном времени. Нажмите q, чтобы выйти. 🟢 Упрощенная альтернатива:

htop

Если не установлено, добавьте:

sudo apt install htop

2️⃣ Управление процессами 🟢 Завершение процесса:

kill <PID>

Например:

kill 1234

Чтобы принудительно завершить процесс:

kill -9 <PID>

🟢 Остановка и возобновление: 🔹Остановить процесс:

kill -STOP <PID>

🔹Возобновить процесс:

kill -CONT <PID>

🟢 Изменение приоритета процесса: 🔹Проверить приоритет (niceness):

ps -o pid,ni,cmd -p <PID>

🔹Изменить приоритет (чем ниже значение, тем выше приоритет):

renice -n 10 -p <PID>

3️⃣ Планирование задач 🟢 Запуск в фоне: Если команда занимает много времени, добавьте & в конце:

long_running_command &

Узнать PID фонового процесса:

jobs -l

🟢 Отложенный запуск: Используйте at, чтобы запланировать выполнение команды:

echo "backup.sh" | at 02:00

Если at не установлен:

sudo apt install at

🟢Периодические задачи: Для регулярных задач используйте cron: 1. Открыть редактор crontab:

crontab -e

2. Добавить задачу (пример: запуск каждую минуту):

* * * * * /path/to/script.sh

⚡️ Советы ➖ Используйте htop для удобной работы с процессами, если командная строка кажется сложной. ➖ Команда pkill позволяет завершить процессы по имени:

pkill firefox

➖ Следите за потреблением ресурсов с помощью iotop (для ввода-вывода) и nmon (общий мониторинг). ✅ Заключение Управление процессами — это важнейшая часть работы в Linux. Знание этих инструментов позволит вам не только следить за состоянием системы, но и эффективно решать проблемы производительности. 😐 👉 DevOps Portal

Kubernetes-examples Это репозиторий содержит множество примеров Kubernetes 👉 https://github.com/AdminTurnedDevOps/kubernetes-examples 👉 DevOps Portal | #ресурсы

Знаем, что многие тут хотят серьезно прокачать свои навыки в DevOps. Но не знают где взять информацию и четкий план. 💪 Советуем бесплатный мета-курс Devops Roadmap - это расширенный чек-лист, который поможет сориентироваться в мире DevOps и стать крутым спецом. 👀 В мета-курсе перечислены все основные разделы и навыки, которыми должен обладать DevOps инженер: от Linux до программирования в удобном формате. ✔️А еще он будет полезен при подготовке к собеседованиям. 👽 Кстати, бонусом крутой канал о девопс. Там тоже самые свежие IT-новости, полезные советы от DevOps-инженера с 20-летним стажем, эксклюзивные материалы, релизы топовых инструментов, обзоры вакансий и личный взгляд на девопс-сферу. 📌 Ну а тем, кто хочет двигаться под руководством наставника - индивидуальная программа.

Как вывести лог Docker за определенное время? 🗓 Чуть ранее мы говорили про работу с логами. В том сообщении я упоминал про Docker и то, что в его случае логи работы контейнеров хранятся в JSON-файлах и не совсем удобны для ознакомления. Особенно, если контейнер работает давно и за это время в логи нападало много всего и он весит под сотню мегабайт. Поэтому логичнее будет выводить содержимое лога Docker в отдельный файл и делать это за определенное время. Как? Расскажу ниже 👇 1️⃣ Вывод списка запущенных контейнеров Начнем с основной команды, которая позволяет вывести список запущенных контейнеров и получить о них основную информацию:

docker ps

После ввода команды вы увидите удобный выхлоп, где нас интересует имя или ID нужного контейнера. 2️⃣ Вывод логов конкретного контейнера Здесь есть два способа: менее удобный и совсем неудобный. Где какой решайте сами 🤷‍♂️ Первый способ заиметь доступ к логу контейнера указан был в сообщении про работу с логами, где я указывал место хранения логов Docker:

/var/lib/docker/containers/<id_контейнера>/<id_контейнера>-json.log

Но, как говорилось ранее, вы получаете лютый JSON, где вообще ничего непонятно. Второй способ - использовать команду для вывода логов конкретного контейнера:

docker logs <имя_или_ID_контейнера>

По сути, команда вываливает в терминал содержимое JSON-файла из способа №1. Что делать дальше с этой информацией решает каждый сам, кому-то может оно и поможет, ну а мы идем дальше... 3️⃣ Сохраняем логи за определенный период в отдельный файл Совместим все, что узнали в пунктах выше и приправим ключом --since, который позволяет задать временной отрезок, с которого будет выведен лог. Вдобавок используя перенаправление вывода сохраним это все в отдельный файл, чтобы потом его изучить:

docker logs <имя_или_ID_контейнера> --since 60m > mydocker.log

Данный пример выведет содержимое лога контейнера Docker за последний час. Ну а что делать, если нужно вывести данные с прошлого месяца? Все просто!

docker logs <имя_или_ID_контейнера> --since YYYY-MM-DD > mydocker.log

Здесь YYYY - год (2023, например), MM - месяц (09) и DD - день (21). Порядок идет именно такой, так как все эти ваши европейцы и американцы, создавшие Linux и большую часть того, что связано с программированием, используют такой формат даты. Всю эту информацию перенаправляем в файл с расширением log, который потом можно использовать как душе угодно. 4️⃣ Добавляем временную метку в логи Но даже после использования команды в п. 3 у вас получится файл, в котором все будет в кучу и не поймешь когда и во сколько какое событие, описанное в логе произошло. Поэтому нужно добавить временную метку, делается это при помощи ключа -t.

docker logs <имя_или_ID_контейнера> --since YYYY-MM-DD -t > mydocker.log

Вот теперь-то вы получите информативный лог о том, что происходило с вашим сервисом внутри контейнера! Полученную в конце команду вы можете использовать вместе с сервисом Transfer.sh, чтобы без лишней головомойки делиться логами с кем нужно 👉 DevOps Portal

🐧 Три команды для работы с логами в Linux, которые я использую чаще всего Важной составляющей работы с любого рода сервисами или приложениями является изучение логов, где отображается вся нужная информация, будь до ошибки или успешные авторизации или ответы сервера. При этом, не имеет значения являетесь ли вы системным администратором, разработчиком или обычным пользователем, который разворачивает в рамках домашней среды какой-либо сервис или приложение: логи нужны всем. Поэтому ниже расскажу про три команды для работы с логами в Linux, которые использую чаще всего. Но перед этим давайте узнаем где логи хранятся и какие они. 🟢Места хранения логов в Linux Естественно, место, где будут храниться логи можно определить самостоятельно через конфигурационные файлы. Но мы остановимся на классическом варианте - системной папке:

/var/log/...

Внутри нее могут располагаться как отдельные файлы-логи (имеющие расширение log), так и директории с названиями сервисов внутри которых находятся логи. Есть, естественно, исключения. Например, Docker. У него логи запущенных контейнеров находятся в другом месте:

/var/lib/docker/containers/<id_контейнера>/<id_контейнера>-json.log

Опять-таки, повторюсь, что чаще всего местоположение логов, заданное разработчиками программы или сервиса указывается в конфигурационных файлах и может, при желании, меняться пользователем. Системные логи, чаще всего, хранятся в /var/log. 🟢 Какие виды логов бывают? Расскажу, опять-таки, про классическую схему того, какие логи бывают. ✅ access.log - содержат данные о доступе к серверу/ресурсу/приложению (например, успешные авторизации) ❌ error.log - содержат данные об ошибках, возникающих при работе с серверами/ресурсами/приложениями. 🔤 <имя_сервиса>.log - содержат данные обо всех взаимодействиях с сервисом (доступ, ошибки, информация и пр.) Указанные имена логов являются стандартными, конкретный вариант уже зависит от того, как решили разработчики или пользователь. Используя конфигурационные файлы вы можете задать любое имя для файла с логами. Теперь уже перейдем к командам. 1️⃣ Команда cat для просмотра содержимого лога При использовании этой команды в терминал будет выведено все содержимое лога:

cat /var/log/<имя_лога>.log

Удобно, когда лог небольшой, в обратном случае вывод может занять длительное время. 2️⃣ Команда tail -f для вывода содержимого лога в режиме реального времени Напомню, что команда tail выводит по-умолчанию 10 последних строк содержимого файла. Но при использовании ключа -f в выхлоп будут попадать строки лога в режиме реального времени.

tail -f /var/log/<имя_лога>.log

Удобно запустить такую команду и начать тестирование сервиса или программы, чтобы сразу видеть влетающую информацию. 3️⃣ Команда echo -n > для зануления логов Бывает так, что логи разрастаются до неимоверных размеров. Решается это настройкой так называемой ротации (про нее расскажу отдельно в следующий раз), но если лог разросся до размеров, которые нужно занулить здесь и сейчас, то указанная команда подойдет в самый раз:

echo -n > /var/log/<имя_лога>.log

Почему нельзя решить проблему простым удалением лога при помощи rm? Некоторые сервисы используют проверку наличия файла для записи лога и если он отсутствует, то считают это ошибкой и перестают работать. Поэтому вместо кажущегося очевидного удаления файла лога нужно его просто занулить. Работа с логами не составляет каких-то сложностей. Помимо указанных выше команд можно использовать практически все другие инструменты, применяемые к работе с файлами в Linux. В логах можно искать информацию, сортировать ее вывод в терминал, применять редактор sed и так далее. Чтобы не утруждать пользователя или администратора просмотров логов вручную существуют автоматизированные системы сбора и обработки логов, которые позволяют собирать информацию сразу с нескольких серверов. Поддержите пост лайком, если он оказался полезным 🤝 👉 DevOps Portal

Храните секреты в открытом виде в Git? Есть альтернатива! Приглашаем на вебинар «Эволюция Secrets Management», где DevOps Lead Hilbert Team Михаил Кажемский расскажет, как безопасно хранить и управлять секретами в вашей инфраструктуре. О чем поговорим: ⏺ Почему хранить пароли и ключи в Git — плохая идея ⏺ Какие есть альтернативы: от простых решений до HashiCorp Vault ⏺ Как интегрировать секреты в CI/CD и GitOps-процессы ⏺ Как подружить Hashicorp Vault c Kubernetes Для кого вебинар: DevOps-инженеры уровня Junior и выше, разработчики, архитекторы Не пропусти! Регистрируйся и задавай вопросы спикеру Когда? 12 декабря в 12:00

Легкий путь обмена файлами: Transfer.sh для Linux-энтузиастов и системных администраторов Transfer.sh — это очень удобная и простая штука, которая позволяет обмениваться файлами с помощью curl/wget. И да, это без регистрации и SMS. Лимиты весьма щедрые — до 10 гигабайт на файл, и ваши файлы хранятся на сервере в течение 14 дней. Что еще круто? Вам доступна возможность зашифровать файл перед отправкой и даже проверить его на наличие вирусов. И вот что интересно: в команде curl можно указать дополнительные заголовки -H "Max-Downloads: 1" -H "Max-Days: 5". Это означает, что файл смогут скачать только один раз, и через пять дней он автоматически удалится. Удобно, правда? Итак, вопрос — это же не слишком безопасно, так ведь? Да, вы абсолютно правы. Этот сервис подходит скорее для передачи некритичной информации. Не стоит использовать его для чего-то чрезвычайно секретного. Например, его могут использовать системные администраторы для передачи логов заказчикам. Не забудьте заглянуть на сайт Transfer.sh и изучить все возможности, которые они предоставляют. Там есть много примеров, и вы быстро разберетесь 👉 DevOps Portal

Пять GitHub проектов, которые помогут вам стать лучшим инженером DevOps 1️⃣ How they SRE Подборка общедоступных ресурсов о том, как технологические и технически подкованные организации по всему миру практикуют Site Reliability Engineering (SRE). ▶️https://github.com/upgundecha/howtheysre 2️⃣ Awesome Scalability Паттерны масштабируемых, надежных и производительных крупномасштабных систем ▶️https://github.com/binhnguyennus/awesome-scalability 3️⃣ DevOps Exercises Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. Вопросы для интервью по DevOps ▶️https://github.com/bregman-arie/devops-exercises 4️⃣ Test your sysadmin skills Сборник тестовых вопросов и ответов по Linux Sysadmin. Проверьте свои знания и навыки в различных областях с помощью этих вопросов и ответов. ▶️https://github.com/trimstray/test-your-sysadmin-skills 5️⃣ Awesome Site Reliability Engineering Составленный список ресурсов по надежности сайта и производственному инжинирингу. ▶️https://github.com/dastergon/awesome-sre 👉 DevOps Portal

Тут ребята из K2 Cloud выкатили реакции на Habr Теперь можно не только заминусить маркетинговые статьи, но и накидать эмодзи. Чтобы их получить, нужно пройти короткий квиз — в конце еще есть возможность залутать лимитированный мерч Хабра и K2 Cloud. В общем, все, что нужно для счастья тут