DevOps Ready | IT

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

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

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

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

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

➡️ 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 | #совет

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

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

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

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

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

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

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

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

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

Разбираем jq 7 приёмов для анализа JSON в терминале!

jq помогает быстро читать JSON из API, логов, kubectl, terraform output и CI/CD-ответов без ручного просмотра.

В этой шпоре: .field, [], select, map, keys, length и -r.

➡️ 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 | #практика

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

Знали, зачем в 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 | #совет

Знали, почему readinessProbe не стоит заменять livenessProbe?

В Kubernetes часто добавляют health checks, но readinessProbe и livenessProbe нужны для разных вещей.

livenessProbe нужна, чтобы понять, жив ли контейнер вообще. Если приложение зависло и уже не может восстановиться, Kubernetes перезапустит Pod.

Простой пример проверки:

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080

readinessProbe решает другую задачу. Она говорит, можно ли прямо сейчас отправлять трафик в этот Pod.

Например, приложение уже запустилось, но ещё прогревает кэш, ждёт миграции, подключение к базе или загрузку конфигурации. Перезапускать его в этот момент не нужно.

Для этого лучше сделать отдельный endpoint:

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080

Если readiness падает, Pod просто убирается из endpoints сервиса. Новые запросы туда не идут, но контейнер продолжает работать и может вернуться в строй.

А если slow start долгий, добавляют startupProbe:

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 2

Она даёт приложению время на старт и не позволяет livenessProbe убить контейнер слишком рано.

Состояние проб удобно смотреть через describe:

kubectl describe pod api-7f9c

liveness отвечает за перезапуск, readiness отвечает за трафик, startupProbe отвечает за долгий старт.

➡️ DevOps Ready | #совет

📂 Напоминалка по распределению конфигурации между Git и переменными окружения!

Правильное разделение настроек помогает безопасно управлять разными окружениями, не хранить секреты в репозитории и не создавать хаос в конфигурации. На картинке показаны 7 практик: от классификации параметров и принципов 12-Factor до работы с секретами, разделения dev, staging и prod, автоматической проверки и документирования конфигурации. Главное правило: код хранится в Git, значения приходят через ENV, а секреты находятся в защищённом хранилище.

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

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

Penguin Gym Linux - тренировка Linux-команд!

На сайте можно практиковать Linux-команды прямо в браузере. Есть виртуальный terminal, пошаговые уроки, задания, квизы, материалы по beginner Linux, LPIC-1 и отдельный маршрут в сторону DevOps.

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

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

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

📂 Шпаргалка по настройке оповещений в DevOps!

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

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

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

Разбираем gh CLI для GitHub Actions и релизов!

gh помогает работать с GitHub прямо из терминала. Через него удобно смотреть запуски workflow, читать логи, вручную запускать pipeline, управлять секретами и выпускать релизы.

В этой шпоре собраны run list, run watch, run view, workflow run, secret set, release create и api.

➡️ DevOps Ready | #шпора