Пишем проверку доступности 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 | #ресурс