DevOps Ready | IT

Практически любую команду можно запустить в отдельной cgroup! Большинство воспринимает systemd-run как инструмент для запуска сервисов. Но режим --scope запускает команду во временном scope unit, сразу помещая её и всё дерево процессов в отдельную cgroup, где можно задать ограничения. Например, если большая сборка начинает вытеснять всё остальное из памяти, достаточно выполнить её через systemd-run: systemd-run --user --scope \ -p MemoryHigh=1536M \ -p MemoryMax=2G \ make -j32 Теперь ограничения действуют только на эту команду и всё её дерево процессов. После завершения временная cgroup автоматически исчезнет. Точно так же можно ограничить использование процессора, не меняя приоритет процесса (nice решает другую задачу): systemd-run --user --scope \ -p CPUQuota=200% \ npm test Или собрать сразу несколько политик для ресурсоёмкой задачи: systemd-run --user --scope \ -p MemoryMax=4G \ -p CPUQuota=300% \ -p IOWeight=100 \ cargo build --release Для работы ограничений требуется systemd с поддержкой соответствующих cgroup-контроллеров (обычно современные дистрибутивы с cgroup v2). 🔥 systemd-run --scope позволяет применять возможности cgroups к любой команде одной строкой, без создания сервисов и постоянных unit-файлов. 🚪 Linux Ready | #совет

Опа, тут бывший сеньор одного из IT-отделов Яндекса Игорь Никитин выкатил целый канал про Python — и это лучшее, что есть в рунете по теме. Качественные гайды. Советы от известных прогеров. Тематические мемасы. Короче, ничего лишнего. Хватит душить питона, учись его кодить: https://t.me/+IzIPzvoa7p40ZTUy 🐍

Шпаргалка по kubectl-командам! Например, kubectl get pods показывает поды, kubectl describe pod помогает посмотреть детали ресурса, а kubectl logs быстро достаёт логи контейнера. На картинке команды kubectl для просмотра ресурсов, создания и применения YAML, удаления объектов, запуска команд внутри контейнера, работы с логами, kubeconfig и короткими именами Kubernetes-ресурсов. Сохрани, чтобы не потерять! ➡️ DevOps Ready | #ресурс

Как в Bash гарантированно удалить временные файлы через trap? В shell-скриптах часто создают временную папку: tmp_dir=$(mktemp -d) А потом в конце вручную удаляют её: rm -rf "$tmp_dir" Проблема в том, что скрипт может завершиться раньше: ошибка команды, Ctrl+C, ранний exit. Тогда временные файлы останутся лежать на диске. Для таких случаев в Bash используют trap: tmp_dir=$(mktemp -d) trap 'rm -rf "$tmp_dir"' EXIT Теперь cleanup выполнится при выходе из скрипта почти в любом сценарии: cp app.log "$tmp_dir/" grep "ERROR" "$tmp_dir/app.log" Даже если grep завершится ошибкой, trap всё равно сработает при выходе. Это удобно сочетать со строгим режимом: set -euo pipefail Полный минимальный шаблон: set -euo pipefail tmp_dir=$(mktemp -d) trap 'rm -rf "$tmp_dir"' EXIT Если нужно выполнить несколько действий при завершении, лучше вынести cleanup в функцию: cleanup() { rm -rf "$tmp_dir" } trap cleanup EXIT Такой подход полезен для архивов, временных конфигов, скачанных файлов, тестовых директорий и промежуточных данных в CI/CD. ➡️ DevOps Ready | #совет

🔐 Защищённое подключение для DevOps, разработчиков и удалённых команд При работе с серверами, панелями управления, Git-репозиториями и внутренними сервисами важно не только иметь доступ к инфраструктуре, но и защищать соединение в публичных и недоверенных сетях. TrustTunnel предоставляет собственную международную сеть защищённого подключения для частных пользователей, системных администраторов и удалённых команд. Что получает пользователь: • защищённое соединение в общественных и домашних сетях • единый аккаунт для нескольких устройств • собственная серверная инфраструктура в разных странах • автоматический импорт конфигурации после авторизации • приложения для компьютеров, смартфонов и Android TV • техническая поддержка и регулярные обновления • собственная технология подключения TT Connect Сервис развивается независимой командой. Мы самостоятельно разрабатываем клиентские приложения, серверную часть и систему управления подключениями. 🌐 Подробнее: https://www.trusttunnel.info 📢 Новости проекта: @trusttunnelconnect

📂 Напоминалка по локальной отладке CI/CD-скриптов! Ошибки в пайплайне лучше находить до запуска в CI. Локальная отладка позволяет быстрее проверить логику скриптов, переменные окружения, Docker-окружение и конфигурацию, не тратя время на повторные запуски пайплайна. На картинке — 7 полезных команд для локальной проверки CI/CD: от shellcheck и docker run до set -x, jq, git diff и других инструментов, которые помогают быстрее находить ошибки и делать пайплайны более надёжными. Сохрани, чтобы не потерять! ➡️ DevOps Ready | #ресурс

Контроль целостности системных утилит Linux через проверку хэш-сумм. При компрометации сервера злоумышленники часто подменяют базовые системные бинарники (например, ss, ps или login) на модифицированные версии с бэкдорами. Мы напишем лаконичный bash-скрипт, который создаст эталонные слепки контрольных сумм SHA-256 для критически важных утилит и проверит их на предмет несанкционированных изменений. Этот базовый механизм Host IDS (интрузивного детектирования) позволяет оперативно обнаружить факт присутствия атакующего в системе. Сформируем базу данных эталонных хэш-сумм для выбранных системных утилит и сохраним её в защищенный файл: # Создание эталонных хэшей для проверки sha256sum /bin/ps /bin/ss /usr/bin/whoami > /root/sys_integrity.db Файл базы данных успешно создан и содержит уникальные криптографические отпечатки чистых бинарников. Напишем автоматический скрипт валидации, который сверяет текущее состояние файлов с ранее сохраненным эталоном: # Скрипт проверки и вывода измененных файлов sha256sum -c /root/sys_integrity.db 2>&1 | grep -v 'OK' || echo "Integrity check: SUCCESS" Команда выполнит сверку всех строк и выведет предупреждение только в случае несовпадения хэшей. # проверка (контрольная эмуляция подмены для проверки реакции парсера) echo "test" >> /root/sys_integrity.db && sha256sum -c /root/sys_integrity.db 2>&1 | grep 'FAILED' Ожидаемый вывод: /root/sys_integrity.db: FAILED # cleanup (удаление тестовой базы данных из системы) rm -f /root/sys_integrity.db Регулярный запуск такого скрипта через cron помогает вовремя заметить активность руткитов и троянов. Чтобы атакующий не смог подделать саму базу хэшей, обязательно храните эталонный файл sys_integrity.db на удаленном сервере логирования или на флешке в режиме "только чтение". 🚪 Linux Ready | #практика

Bash-конвейер может скрыть ошибку одной из команд! По умолчанию код завершения конвейера определяется последней командой: curl -sS "$URL" | jq -r '.version' Если curl завершится с ошибкой, но jq успешно обработает пустой ввод, весь конвейер может вернуть код 0. Скрипт решит, что команда выполнилась успешно. Опция pipefail меняет это поведение: set -o pipefail Теперь конвейер завершится с ошибкой, если неуспешной была любая его часть: curl -fsS "$URL" | jq -r '.version' > version.txt Коды отдельных команд последнего конвейера можно посмотреть через PIPESTATUS: curl -fsS "$URL" | jq -r '.version' printf '%s\n' "${PIPESTATUS[@]}" В автоматизированных Bash-скриптах часто включают сразу несколько строгих настроек: set -euo pipefail -e завершает скрипт при необработанной ошибке, -u запрещает использование необъявленных переменных, а pipefail обнаруживает сбой внутри конвейера. Ожидаемые ошибки при этом лучше обрабатывать явно: if ! grep -q "READY" health.log; then echo "Service is not ready" fi Добавляйте pipefail в Bash-скрипты, где ошибка загрузки, сборки или обработки данных не должна остаться незамеченной. ➡️ DevOps Ready | #совет

Шпаргалка по командам Docker CLI! Например, docker run -p 8080:80 nginx запускает контейнер и публикует его порт, а docker logs -f <container> показывает новые строки логов в реальном времени. На картинке команды для сборки и удаления образов, запуска и остановки контейнеров, просмотра логов и статистики, открытия shell внутри контейнера, а также загрузки и публикации образов через Docker Hub. Сохрани, чтобы не потерять! ➡️ DevOps Ready | #ресурс

Почему sudo echo всё равно может вернуть Permission denied? Часто системный файл пытаются изменить так: sudo echo "PORT=8080" \ > /etc/myapp/app.conf Но команда может завершиться ошибкой доступа, хотя перед echo указан sudo. Причина в порядке выполнения. sudo запускает с повышенными правами только echo, а перенаправление > обрабатывает текущий shell ещё до запуска команды. Именно обычный пользователь пытается открыть системный файл для записи. Для таких случаев удобно использовать tee: echo "PORT=8080" | sudo tee /etc/myapp/app.conf \ > /dev/null Здесь файл открывает уже tee, запущенный через sudo. Чтобы не перезаписывать файл, а добавить строку в конец, используйте -a: echo "LOG_LEVEL=info" | sudo tee -a /etc/myapp/app.conf \ > /dev/null Многострочный конфиг можно записать через heredoc: sudo tee /etc/myapp/app.conf \ > /dev/null <<'EOF' PORT=8080 LOG_LEVEL=info CACHE_ENABLED=true EOF Кавычки вокруг 'EOF' запрещают shell подставлять переменные и выполнять команды внутри блока. Содержимое будет записано буквально. ➡️ DevOps Ready | #совет