Собираем Makefile для частых DevOps-команд!

В проектах часто есть набор повторяющихся команд. Запустить тесты, собрать образ, применить миграции или открыть shell.

Держать всё в голове не удобно. А с помощью Makefile можно приварить их в короткие сценарии.

Начнём с понятной цели для логов:

logs:
    docker compose logs -f app

Таб перед командой важен. В Makefile команда внутри target должна начинаться именно с tab.

Добавим перезапуск сервиса:

restart:
    docker compose restart app

Для проверки можно сделать отдельный target:

check:
    docker compose config
    docker compose ps

Теперь команды становятся короче:

make logs
make restart
make check

Для deploy лучше добавить dry-run или отдельный подготовительный шаг, чтобы случайно не выполнить опасную команду.

Например, можно сначала показать текущий git commit:

release-info:
    git rev-parse --short HEAD
    git status --short

Такой Makefile не заменяет CI/CD, но сильно снижает ручную работу. Особенно в маленьких командах, где одни и те же операции часто выполняют разные люди.

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

kubectx и kubens - переключатели контекста Kubernetes!

В этом репозитории лежат две маленькие утилиты для kubectl. kubectx помогает быстро переключаться между Kubernetes context, а kubens делает то же самое для namespace.

Инструменты особенно важны, когда приходится работать с несколькими кластерами, окружениями и namespace. Вместо длинных команд kubectl config можно быстро выбрать нужный контекст, посмотреть список доступных вариантов и не путаться между dev, stage и prod.

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

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

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

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

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

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

Знали, различие Cache и Artifacts?

В CI/CD часто есть две похожие сущности. Cache ускоряет следующие запуски, а artifacts сохраняют результат текущего job.

Из-за похожей логики их иногда используют как одно и то же. Например, кладут build-результат в cache или зависимости в artifacts.

Cache нужен для временных данных, которые можно восстановить заново:

cache:
  paths:
    - .npm/

Если cache пропадёт, pipeline должен просто стать медленнее, но не сломаться по смыслу.

Artifacts нужны для результата, который должен перейти в следующий job или остаться после сборки:

artifacts:
  paths:
    - dist/

Например, build-job собирает dist, а deploy-job забирает именно этот dist. Тут cache не подходит, потому что cache может быть старым или очищенным.

Плохой сигнал, если deploy зависит от cache:

deploy:
  script:
    - upload dist/

Если dist приехал из cache, можно случайно выкатить не тот build.

Надёжнее разделять роли. Зависимости, package cache и compiler cache идут в cache. Собранные бинарники, отчёты, coverage и dist идут в artifacts.

Cache ускоряет работу, artifacts передают конкретный результат между шагами.

➡️ DevOps Ready | #совет

Шпаргалка по типам метрик Prometheus!

Например, Counter подходит для значений, которые только растут, Gauge показывает текущее состояние, а Histogram помогает анализировать распределение задержек и размеров запросов.

На картинке собраны основные типы метрик и их соответствие в OpenTelemetry. Такая шпаргалка полезна, когда нужно выбрать правильный тип метрики для сервиса, дашборда или alert rule.

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

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

Шпаргалка по отладке Kubernetes Deployment!

Например, kubectl get pods помогает увидеть Pending, Running и CrashLoopBackOff, а kubectl describe pod показывает события планировщика, image pull ошибки и проблемы с probe.

На картинке собран flowchart для диагностики Deployment. Есть проверки pod, logs, describe, readiness, image pull, scheduler, Service, Ingress и port-forward для быстрой локализации проблемы.

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

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

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