Как не выполнять одну и ту же команду несколько раз?

В работе часто возникает ситуация: команда тяжёлая, медленная или ходит в сеть. Например, kubectl, docker, curl, запросы к API или работа с логами.

Чтобы не гонять её снова и снова для разных проверок:

kubectl get pods
kubectl get pods | grep api
kubectl get pods | wc -l

Каждый раз это новый запрос, новая нагрузка и потеря времени.

Гораздо быстрее выполнить её один раз и сохранить результат:

out=$(kubectl get pods)

Теперь можно сколько угодно анализировать данные без повторных вызовов:

echo "$out" | grep api
echo "$out" | wc -l

Это особенно чувствуется при работе с удалёнными сервисами, базами и логами, где каждая команда может занимать секунды.

🔥 Если команда дорогая — не запускай её повторно. Сохрани результат и работай с ним локально.

➡️ DevOps Ready | #совет

❤️ Linux Commands Cheat Sheet — шпаргалка по 400+ командам Linux!

В репозитории собран справочник по Linux-командам — более 400 утилит с описаниями и примерами использования. Каждая команда сопровождается кратким объяснением и примерами, поэтому можно быстро понять, как она работает и где применяется. Удобно использовать как справочник в работе и подготовке к собеседованиям.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #репозиторий

sponge: утилита, которая спасает, когда нужно перезаписать файл через pipe!

Есть старый неприятный момент в shell: если читаешь файл и тут же пишешь результат обратно в него же через >, можно случайно получить пустой файл.

Например:

grep -v DEBUG app.log > app.log

На первый взгляд выглядит нормально. На практике — нет.
Shell откроет app.log на запись сразу, ещё до того, как grep дочитает его до конца. В итоге файл можно просто обнулить.

В таких случаях выручает sponge из moreutils.

Он работает просто: сначала полностью читает входной поток, и только потом записывает результат в файл.

То же самое, но безопасно:

grep -v DEBUG app.log | sponge app.log

Несколько примеров, где это реально удобно.

Заменить текст в конфиге:

sed 's/localhost/db.internal/' config.yml | sponge config.yml

Убрать пустые строки:

grep -v '^$' file.txt | sponge file.txt

Отсортировать файл:

sort file.txt | sponge file.txt

Отформатировать JSON:

jq '.' data.json | sponge data.json

Из нюансов: sponge сначала забирает весь поток целиком, а уже потом пишет в файл. Для обычных задач это вообще не проблема, но на очень больших файлах про это лучше помнить.

🔥 Если коротко: когда нужно безопасно перезаписать файл результатом команды, sponge делает именно то, что ожидаешь.

➡️ DevOps Ready | #практика

🐱 Awesome Hacker Search Engines — инструменты, которые используют в инфосеке!

Подборка специализированных поисковиков, которые активно применяются в OSINT, пентесте и разведке инфраструктуры. Сервисы для поиска утечек, открытых портов, уязвимых сервисов, исходного кода, доменов, IP-адресов и другой критичной информации. Отлично подойдёт тем, кто хочет понять, как собирается информация перед атакой или тестированием.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #репозиторий

📂 Напоминалка по сетевым протоколам!

Например, DNS отвечает за преобразование доменных имен в IP-адреса, TCP обеспечивает надежное соединение и порядок доставки пакетов, а HTTP используется для обмена запросами и ответами между клиентом и сервером.

На картинке — основные сетевые протоколы и уровни, которые участвуют в передаче данных.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Убиваем залипшие процессы с fuser и kill. Когда Ctrl+C не помогает, а процесс держит порт или файл!

Иногда процесс залипает и не хочет умирать даже после Ctrl+C. Или наоборот — ты не знаешь, что за процесс мешает работать. В таких случаях помогает связка fuser + kill.

Проверим, кто использует порт (например, 8080):

fuser -n tcp 8080

Или файл, занятый каким-то процессом:

fuser /var/log/syslog

Если надо сразу завершить все процессы, держащие ресурс:

fuser -k 8080/tcp

Или убить по PID (который вернул fuser):

kill -9 <PID>

🔥 fuser показывает, какие процессы используют файл или порт, а -k завершает их. Аккуратно — можно прибить что-то важное.

➡️ DevOps Ready | #практика

👍 DevOps Daily — образовательный ресурс по DevOps и инфраструктуре!

Это сайт, посвящённый современным практикам разработки и эксплуатации программных систем. Материалы охватывают ключевые инструменты и процессы DevOps. Публикации сопровождаются примерами и практическими заданиями, что позволяет применять полученные знания в реальных рабочих процессах.

📌 Оставляю ссылочку: devops-daily.com

➡️ DevOps Ready | #сайт

Почему диск полный, хотя файлы уже удалены?

Удалили огромный лог, но место на диске не освободилось, df показывает, что диск всё ещё заполнен.

Причина в том, что процесс держит открытый файловый дескриптор.
Файл удалён из файловой системы, но продолжает существовать, пока процесс его не закроет.

Найти такие файлы можно так:

lsof | grep deleted

Там будет PID процесса и номер дескриптора.

Теперь можно освободить место без перезапуска сервиса:

: > /proc/<PID>/fd/<FD>

Это обнуляет файл через файловый дескриптор, и место возвращается системе.

🔥 Если диск заполнен невидимыми файлами, часто нужно найти открытые дескрипторы и очистить их через /proc.

🚪 Linux Ready | #совет

📂 Напоминалка по Linux-командам!

Например, ls показывает содержимое директории, cd помогает перемещаться между папками, а grep позволяет быстро находить нужный текст в файлах.

На картинке — самые используемые команды: работа с файлами, процессами, сетью, правами доступа и системой. Такой набор закрывает 90% повседневных задач в терминале.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Смотрим, какие библиотеки реально отображены в адресное пространство процесса!

Когда приложение падает из-за несовместимой или отсутствующей библиотеки, ldd полезен, но он показывает, как динамический загрузчик разрешает зависимости для бинаря, а не текущее состояние уже запущенного процесса.

Если нужен точный ответ, что уже замаплено в память, используем /proc.

Сначала находим PID процесса:

pgrep -a python

Допустим, это 1234. Теперь смотрим, какие shared objects отображены в его адресное пространство:

grep '\.so' /proc/1234/maps

Что здесь важно: /proc/<pid>/maps — карта памяти процесса; каждая строка — отдельный участок памяти; если в строке есть путь к .so, значит есть файловый маппинг этого объекта.

Пример:

7f2c1a000000-7f2c1a200000 r-xp ... /usr/lib/x86_64-linux-gnu/libssl.so.1.1

Это означает, что в адресном пространстве процесса есть маппинг этой версии libssl (и, с высокой вероятностью, она используется процессом).

Если нужен список без дублей:

grep '\.so' /proc/1234/maps | awk '{print $6}' | sort -u

Практический кейс — конфликт версий после обновления: систему обновили, новая библиотека уже лежит на диске, а процесс всё ещё держит старую версию в памяти.

Проверить можно так:

ls -l /proc/1234/map_files/

Если у файла есть пометка (deleted), это сильный сигнал: файл на диске уже удалён или заменён, но процесс продолжает использовать старый inode через существующий маппинг.

🔥 Что важно помнить: изменения на диске не влияют на уже загруженные библиотеки в работающем процессе, после обновления библиотек сервисы обычно нужно перезапускать, доступ к /proc/<pid> и особенно map_files может быть ограничен правами.

🚪 Linux Ready | #практика

🐱 Полезную статью нашёл на Хабре: «Чёрное окошко Linux: погружение в подсистему TTY»!

В этой статье:
• Подробно разбирается, что на самом деле скрывается за терминалом в Linux;
• Объясняется разница между консолью, терминалом, shell, TTY и эмуляторами;
• Показано, как процессы взаимодействуют с системой через stdin/stdout/stderr и файловые дескрипторы, и какую роль в этом играет ядро.

🔊 Продолжайте читать на Habr!

➡️ DevOps Ready | #статья

Непонятно, откуда взялся процесс?

Большинство смотрят ps aux, но он не показывает причинно-следственную связь.

Настоящая картина — это дерево процессов:

pstree -ap

Здесь видно, какой процесс чей родитель, с аргументами и PID.
Можно быстро понять: это systemd-сервис, cron-задача или дочерний процесс скрипта.

Если есть конкретный PID, смотри цепочку до корня:

pstree -s <PID>

Это показывает путь запуска, от init/systemd до нужного процесса.

Для точечной проверки родителя:

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

И дальше можно идти вверх по PPID.

Важно: PPID показывает текущего родителя. Если процесс был перезапущен, демонезирован или его родитель умер — он может быть перепривязан к systemd/init, и исходный источник уже не виден.

🔥 Дерево процессов даёт быстрый ответ в большинстве случаев.

🚪 Linux Ready | #совет

📂 Шпаргалка по cron в Linux!

Например, 0 0 * * * выполняет задачу ежедневно в полночь, а */5 * * * * — с интервалом в 5 минут.

На изображении — структура cron-выражения, основные алиасы (@daily, @weekly, @reboot) и типовые примеры расписаний, которые удобно использовать в повседневной работе.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Ваши старые SSH-ключи могут быть под угрозой взлома!

Алгоритм RSA с длиной ключа 1024 бит уже давно не обеспечивает надежную защиту из-за возросших вычислительных мощностей.

Современный стандарт требует минимум 3072 бит для RSA, но лучшим выбором сегодня является алгоритм Ed25519 — он быстрее, короче и значительно устойчивее к криптоанализу.

Проверка длины и типа существующих ключей в вашей системе:

ssh-keygen -l -f ~/.ssh/id_rsa

Генерация максимально защищенного ключа на базе эллиптических кривых:

ssh-keygen -t ed25519 -a 100 -C "main_access"

Параметр -a 100 увеличивает количество раундов хеширования парольной фразы для защиты от брутфорса.

Вывод отпечатка ключа для быстрой верификации на сервере:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

🔥 Мини-совет: Всегда защищайте приватный ключ сложной парольной фразой (passphrase), чтобы даже при краже файла злоумышленник не смог им воспользоваться без подбора пароля.

➡️ Hacking Ready | #совет

🐱 Linux Cheat Sheet — системная шпаргалка по Linux-командам

Cтруктурированный справочник по Linux, где собраны основные команды и утилиты, разбитые по категориям: пользователи, файлы и директории, права доступа, сеть, процессы, пакеты, поиск, SSH и многое другое. Каждая команда сопровождается описанием и примерами использования, поэтому можно быстро понять, как она работает и где применяется.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #репозиторий