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 | #ресурс

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