Шпаргалка по правам доступа в Linux!

Например, chmod меняет права файла, chown назначает владельца, а chgrp задаёт группу. Символьный режим помогает точечно добавить или убрать разрешение, а числовой удобен для понятных наборов вроде 600, 644 и 755.

На картинке собраны r, w и x, роли user, group и others, расшифровка ls -l, а также команды chmod, chown и chgrp с короткими примерами.

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

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

Знали, чем docker compose run отличается от exec?

Обе команды запускают процесс рядом с сервисом, поэтому их легко перепутать. Но работают они с разными контейнерами.

docker compose exec выполняет команду внутри уже запущенного контейнера. Это удобно, когда нужно открыть shell, посмотреть переменные окружения или запустить миграцию в работающем приложении.

docker compose exec api sh

Команда использует тот же контейнер, его сеть, тома и текущее состояние. Если сервис не запущен, exec не сможет подключиться.

docker compose run создаёт отдельный одноразовый контейнер на основе сервиса.

docker compose run --rm api python manage.py migrate

Такой запуск хорош для задач, которые не должны трогать основной процесс. После --rm временный контейнер будет удалён.

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

docker compose run --rm --service-ports api

Для проверки живого контейнера выбирай exec. Для отдельной команды, миграции или одноразового job выбирай run.

➡️ DevOps Ready | #совет

Шпаргалка по сигналам и остановке процессов в Linux!

На картинке собраны основные сигналы Unix, команды kill, killall, pgrep и pkill, а также полезные ключи для поиска по полной командной строке.

Например, kill по умолчанию отправляет SIGTERM, pgrep помогает найти PID по имени, а pkill сочетает поиск процесса и отправку сигнала в одной команде.

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

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

Делаем проверяемый бэкап PostgreSQL!

Резервная копия полезна только тогда, когда её можно восстановить. Поэтому после pg_dump стоит сразу проверить содержимое архива и периодически поднимать базу из этого файла.

Сначала сохраняем параметры подключения вне команды.

export PGHOST=db.internal
export PGDATABASE=app
export PGUSER=backup

Формат custom удобен для восстановления, потому что pg_restore умеет показать состав архива и выбирать объекты. Имя с датой помогает не перезаписать вчерашний дамп.

mkdir -p backups
pg_dump --format=custom --no-owner \
  --file "backups/app-$(date +%F).dump"

Проверяем архив до того, как объявлять задачу успешной. Команда выведет таблицы, схемы и другие объекты без реального восстановления.

pg_restore --list backups/app-$(date +%F).dump
test ${PIPESTATUS[0]} -eq 0

Для теста создаём отдельную базу и восстанавливаем туда копию.

createdb app_restore
pg_restore --dbname=app_restore backups/app-$(date +%F).dump

Автоматизация должна логировать дату, размер файла и результат проверки. Ещё полезно настроить хранение нескольких копий вне основного сервера, иначе поломка диска уничтожит и базу, и бэкап одновременно.

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

Знали, почему grep может завершить shell-скрипт без ошибки в самой команде?

grep возвращает разные коды завершения. Ноль означает, что совпадение найдено, единица означает, что совпадений нет, а код больше единицы говорит о реальной ошибке чтения.

В обычном терминале отсутствие строки часто нормально:

grep -q "READY" status.txt

Но в скрипте с set -e код 1 может прервать выполнение. Это неприятно, когда отсутствие совпадения является ожидаемой веткой, а не аварией.

Проверку лучше писать прямо в условии:

if grep -q "READY" status.txt; then
    deploy
fi

Команда внутри if не остановит скрипт из-за set -e. Ветку else можно использовать для понятного сообщения или обычного пропуска шага.

Если важно отличить отсутствие данных от настоящей ошибки, сохраните exit code:

grep -q "READY" status.txt
code=$?

Теперь код 1 можно обработать спокойно, а остальные значения отправить в лог как проблему:

if [ "$code" -gt 1 ]; then
    echo "grep failed" >&2
    exit "$code"
fi

Такой подход особенно полезен для health-check, поиска строки в логах и проверок перед deploy. Отсутствие совпадения становится управляемым результатом, а не случайной причиной падения автоматизации.

➡️ DevOps Ready | #совет

📂 Напоминалка по построению observability-матрицы для проекта!

Наблюдаемость помогает понимать состояние сервиса, быстрее находить проблемы и не тонуть в лишних данных. На картинке показан простой подход: определить ключевые вопросы, выбрать важные метрики, подключить источники данных, настроить алерты и дашборды, документировать правила и регулярно улучшать матрицу с учётом изменений в проекте.

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

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

DevOps Daily собирает материалы по инфраструктуре!

На сайте есть разборы Docker, Kubernetes, Terraform, Linux, сетей и CI/CD. Отдельные разделы посвящены симуляторам, упражнениям, тестам и инструментам для повседневной работы.

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

Оставляю ссылочку на DevOps Daily

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

Шпаргалка по жизненному циклу Pod в Kubernetes!

На картинке показано, как запрос проходит через API server, как scheduler выбирает узел и что kubelet делает перед запуском контейнеров. Отдельно разобраны фазы Pod и последовательность его завершения.

Например, Pending означает, что Pod принят кластером, но контейнеры ещё не готовы к запуску. Если он долго остаётся в этой фазе, полезно проверить события, доступность образа, ресурсы узлов и ограничения планирования.

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

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

🔄 Безопасный арсенал практических инструкций, курсов и инструментов

👩‍💻 Linux & Bash

🤔 Хакинг & ИБ

🖥 Курсы & GitHub

📱 Python

🥷 OSINT

📂 Сохрани подборку и начни с того, что пригодится тебе уже сегодня.

Проверяем итоговую конфигурацию Docker Compose перед запуском!

Когда проект использует базовый compose.yaml и отдельный файл для production, легко ошибиться с портом, переменной окружения или переопределением сервиса. Docker Compose умеет показать итоговую конфигурацию ещё до запуска контейнеров.

Пусть основной файл задаёт приложение, а второй меняет образ и параметры окружения. Посмотрим объединённый результат:

docker compose -f compose.yaml -f compose.prod.yaml config

Для проверки синтаксиса в CI не нужен длинный вывод. Достаточно тихого режима:

docker compose -f compose.yaml -f compose.prod.yaml config --quiet

Если конфигурация некорректна, команда завершится с ошибкой. Так можно остановить pipeline до попытки собрать или запустить контейнеры.

Отдельно посмотрим, какие сервисы и образы Compose получил после объединения:

docker compose -f compose.yaml -f compose.prod.yaml config --services
docker compose -f compose.yaml -f compose.prod.yaml config --images

Это помогает заметить, что нужный сервис пропал из файла или production по-прежнему ссылается на старый тег образа.

Переменные подстановки можно проверить отдельно:

docker compose -f compose.yaml -f compose.prod.yaml config --environment

Это особенно полезно после изменений в нескольких Compose-файлах или окружениях.

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