Пишем проверку доступности TCP-порта на Bash!

Иногда перед deploy, миграцией или запуском сервиса нужно убедиться, что база, Redis, брокер или внутренний API вообще доступны по сети.

Сделаем маленький скрипт без curl и nc. В Bash можно открыть TCP-соединение через /dev/tcp.

Сначала зададим host и port:

host="db.internal"
port="5432"

Проверка выглядит так:

if timeout 3 bash -c "</dev/tcp/$host/$port"; then
  echo "open"
fi

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

Добавим ветку для ошибки:

else
  echo "closed"
  exit 1
fi

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

./wait-port.sh db.internal 5432
./run-migrations.sh

Для CI удобно сделать параметры из аргументов:

host="$1"
port="$2"

Такой скрипт не заменяет полноценный healthcheck, но хорошо подходит для быстрых проверок зависимостей в deploy pipeline и init-скриптах.

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

Знали, почему set -e не заменяет нормальную обработку ошибок?

В Bash часто добавляют set -e, чтобы скрипт завершался при ошибке команды.

set -e

Это лучше, чем полностью игнорировать exit code. Но есть важный нюанс. set -e работает не как полноценный try/catch и в некоторых конструкциях ведёт себя неочевидно.

Например, ошибка внутри условия может быть ожидаемой:

if grep -q "ready" app.log; then
  echo "ready"
fi

Если grep ничего не нашёл, он вернёт 1. Для if это нормальная логика.

Похожая история бывает с командами, где ошибка должна быть обработана явно:

rm old.lock
start_service

Если файла нет, rm вернёт ошибку и скрипт может завершиться раньше, чем дойдёт до запуска сервиса.

Лучше писать намерение явно:

rm -f old.lock
start_service

Для обязательных шагов хорошо добавлять понятное сообщение:

curl --fail "$URL" -o app.tar.gz \
  || { echo "download failed"; exit 1; }

А для пайпов почти всегда нужен pipefail:

set -euo pipefail

Без pipefail скрипт может смотреть только на статус последней команды в pipeline и пропустить ошибку в начале цепочки.

Хорошая база для скриптов выглядит так:

set -euo pipefail

curl --fail "$URL" -o app.tar.gz
tar -xzf app.tar.gz

Команды, где ошибка допустима, лучше оформлять явно через if, || true, rm -f или отдельную обработку.

➡️ DevOps Ready | #совет

Stern - удобный просмотр логов из нескольких Kubernetes-подов!

В этом репозитории находится CLI-инструмент для чтения логов в Kubernetes. Stern умеет цепляться сразу к нескольким подам, фильтровать контейнеры, подсвечивать вывод цветами, показывать новые pod при их появлении и работать с label selectors.

Инструмент особенно полезен, когда Deployment постоянно пересоздаёт pod, сервис масштабирован на несколько реплик или нужно быстро понять, какой контейнер пишет ошибку. Это намного удобнее, чем вручную переключаться между kubectl logs для каждого pod.

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

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

Знали, почему cp ./src/* может тихо пропустить важные файлы?

В shell звёздочка выглядит как простой способ скопировать всё содержимое папки.

Например, так часто переносят конфиги, сборку или шаблон проекта:

cp -r ./src/* ./dst/

Но обычный glob * не включает скрытые файлы, имена которых начинаются с точки.

То есть такие файлы могут не попасть в копию:

.env
.gitignore
.dockerignore
.editorconfig

Для локального проекта это неприятно, а для деплоя или Docker build может стать настоящей проблемой. Приложение уедет без .env.example, Docker получит лишний build context, а форматтеры и линтеры будут вести себя иначе.

Один из надёжных вариантов использовать rsync со слешем в конце источника:

rsync -a ./src/ ./dst/

Так копируется именно содержимое директории, включая dotfiles.

Перед опасной синхронизацией можно сначала посмотреть план:

rsync -an ./src/ ./dst/

Ключ -n включает dry-run и показывает, что будет скопировано без реальных изменений.

Если хочется остаться на cp, можно явно копировать директорию целиком:

cp -a ./src/. ./dst/

Точка после src означает содержимое папки, а не только элементы, которые поймал glob.

В Bash есть и настройка dotglob:

shopt -s dotglob
cp -r ./src/* ./dst/

Но её лучше использовать осторожно, потому что она меняет поведение glob в текущем shell.

Для копирования содержимого папки вместе со скрытыми файлами чаще всего удобнее rsync -a ./src/ ./dst/ или cp -a ./src/. ./dst/.

➡️ DevOps Ready | #совет

📂 Напоминалка по документации CI/CD-процессов!

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

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

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

Шпаргалка по правам доступа в 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 | #практика