Знали, зачем в shell-скриптах иногда задают umask?

Когда скрипт создаёт файлы, права зависят не только от chmod в самом скрипте. На итоговые права влияет umask текущего процесса.

Обычный временный файл может получиться доступнее, чем хотелось бы:

touch backup.env
ls -l backup.env

Если внутри лежат токены, пароли или дампы конфигов, это уже опасно. Особенно на сервере, где есть несколько пользователей или служебных аккаунтов.

umask позволяет заранее запретить лишние права для новых файлов:

umask 077

После этого новые файлы обычно будут доступны только владельцу. Группа и остальные пользователи не получат чтение по умолчанию.

Например, так можно безопаснее создавать файл с секретами:

umask 077
printf '%s\n' "$TOKEN" > token.txt

Проверить результат можно через ls:

ls -l token.txt

Ожидаемый формат будет похож на 600. То есть владелец может читать и писать, а остальные не имеют доступа.

Для директорий это тоже работает:

mkdir private-backups

При umask 077 новая директория обычно получит права 700. Это удобно для backup, временных ключей, ssh-конфигов и артефактов деплоя.

Если файл уже создан с неправильными правами, umask его не исправит. Тогда нужен chmod:

chmod 600 token.txt

umask хорошо закрывает простой класс ошибок. Скрипт перестаёт случайно создавать приватные файлы слишком открытыми.

➡️ DevOps Ready | #совет

Шпаргалка по Infrastructure as Code!

Например, Docker помогает упаковать приложение в контейнер, Kubernetes управляет запуском контейнеров, Terraform описывает инфраструктуру, а Ansible настраивает серверы через playbook.

На картинке собрана общая схема IaC-подхода. Есть containerization, Kubernetes orchestration, Git как source of truth, CI/CD pipeline, Terraform, Ansible, cloud servers и on-premise servers.

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

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

Собираем 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 | #репозиторий