DevOps Ready | IT

Проверяем HTTP endpoint из shell-скрипта!

Иногда нужно быстро понять, жив ли сервис: API, health endpoint, nginx location или внутренний backend.

Начнём с URL:

url="https://example.com/health"

Получим только HTTP-код:

code="$(curl -s -o /dev/null -w "%{http_code}" "$url")"

Теперь проверим диапазон:

if [ "$code" -ge 200 ] && [ "$code" -lt 300 ]; then
  echo "OK: $code"
else
  echo "FAIL: $code"
fi

Добавим timeout, чтобы скрипт не завис:

code="$(curl -sS --max-time 5 \
  -o /dev/null -w "%{http_code}" "$url")"

Если нужен retry:

for i in 1 2 3; do
  code="$(curl -s --max-time 5 -o /dev/null -w "%{http_code}" "$url")"

  [ "$code" = "200" ] && break
  sleep 2
done

После этого можно вернуть exit code для CI:

[ "$code" = "200" ] || exit 1

Такую проверку удобно использовать в deploy-скриптах, cron, CI/CD и простом мониторинге.

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

Шпаргалка по iptables!

Например, iptables -L -v показывает текущие правила, а iptables -I INPUT -s IP -j DROP блокирует входящий трафик от конкретного адреса.
На картинке базовые команды iptables: просмотр правил, блокировка IP и подсетей, удаление правил, блокировка портов, разрешение трафика, сохранение правил и удаление по номеру строки.

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

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

Разберём tar: 7 команд для упаковки, распаковки и проверки архивов в Linux!

tar часто встречается в DevOps-задачах: бэкапы, перенос конфигов, упаковка логов, доставка артефактов и ручная установка утилит. Важно помнить разницу между обычным tar и tar.gz: первый только объединяет файлы, второй ещё и сжимает.

В этой шпоре:

• создание архива;
• распаковка;
• просмотр содержимого;

Эти команды помогают аккуратно работать с архивами и не распаковывать вслепую неизвестное содержимое.

➡️ DevOps Ready | #шпора

Docker Docs — официальный гид по Docker, контейнерам и образам!

На сайте собраны материалы по установке Docker, первым контейнерам, Dockerfile, образам, volumes, networking, Docker Compose, registry, best practices и деплою приложений. Это хороший ресурс для тех, кто хочет не просто выучить пару команд, а нормально понять весь путь: как собрать образ, запустить контейнер, связать сервисы, сохранить данные и подготовить приложение к запуску в реальной инфраструктуре.

Оставляю ссылочку: Docker Docs

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

Kubernetes The Hard Way — репозиторий для понимания Kubernetes изнутри!

В этом репозитории Kubernetes собирается вручную, без готовых скриптов и магии managed-сервисов. Материал проходит через подготовку машин, сертификаты, kubeconfig, encryption config, etcd, control plane, worker nodes, pod network routes, kubectl и smoke test. Хорошо подойдёт тем, кто уже запускал Kubernetes, но хочет понять, что реально происходит под капотом: как компоненты связаны между собой, зачем нужны сертификаты, где живёт etcd и почему кластер не ограничивается одной командой установки.

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

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

Делаем безопасный backup конфига перед изменением!

Перед правкой nginx, systemd unit, docker-compose.yml или любого важного конфига полезно сначала сохранить копию. Это занимает секунды, но сильно упрощает откат.

Зададим путь к файлу:

file="/etc/nginx/nginx.conf"

Добавим timestamp:

stamp="$(date +%Y%m%d-%H%M%S)"

Соберём имя backup-файла:

backup="${file}.${stamp}.bak"

Перед копированием проверим, что файл существует:

test -f "$file" || {
  echo "Файл не найден: $file"
  exit 1
}

Теперь создаём копию с сохранением прав и владельца:

sudo cp -a "$file" "$backup"

После этого можно редактировать конфиг:

sudo nano "$file"

Если это nginx, сначала проверяем конфигурацию:

sudo nginx -t

И только потом перезагружаем сервис:

sudo systemctl reload nginx

Если что-то пошло не так, откат простой:

sudo cp -a "$backup" "$file"
sudo systemctl reload nginx

Для удобства можно посмотреть последнюю копию:

ls -lt /etc/nginx/nginx.conf.*.bak | head

Backup перед изменением конфига это маленькая привычка, которая часто экономит часы восстановления после неудачной правки.

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

Kubernetes Basics — вход в Kubernetes от официальной документации!

На сайте собран пошаговый раздел по базовым возможностям Kubernetes: создание кластера, деплой приложения, просмотр Pod и Deployment, масштабирование сервиса, rolling update и базовая отладка. Материал хорошо подходит тем, кто хочет разобраться, как Kubernetes управляет контейнерами, сервисами и обновлениями приложения без лишней теории и хаоса.

Оставляю ссылочку: Kubernetes Basics

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

Знали, зачем в Bash иногда используют exec вместо обычного запуска команды?

Обычно команду запускают так:

nginx -g 'daemon off;'

Shell остаётся родительским процессом, а nginx запускается как дочерний процесс.

В обычном терминале это почти незаметно. Но в Docker-контейнерах, entrypoint-скриптах и service-wrapper’ах это может стать проблемой: сигналы приходят в shell, а не напрямую в основной процесс.

Например, такой entrypoint выглядит рабочим:

#!/usr/bin/env bash

nginx -g 'daemon off;'

Но если контейнер останавливают через docker stop, сигнал SIGTERM сначала получает shell. Если он не передаст сигнал дочернему процессу корректно, приложение может завершаться не так, как ожидается.

Для основного процесса лучше использовать exec:

#!/usr/bin/env bash

exec nginx -g 'daemon off;'

exec не создаёт новый дочерний процесс, а заменяет текущий shell указанной командой.

То есть nginx становится главным процессом:

PID 1 -> nginx

А не так:

PID 1 -> bash -> nginx

Это особенно важно для контейнеров:

docker stop app

Теперь сигнал остановки приходит напрямую в приложение, и оно может корректно завершить работу: закрыть соединения, сбросить буферы и освободить ресурсы.

exec также полезен в скриптах-обёртках:

#!/usr/bin/env bash

export APP_ENV=prod
exec ./server

После подготовки окружения shell больше не нужен, поэтому его можно заменить настоящим процессом приложения.

➡️ DevOps Ready | #совет

Разбираем journalctl: 7 команд для анализа логов в Linux!

Когда сервис падает, зависает или ведёт себя странно, journalctl часто помогает быстрее всего понять причину. Эти команды позволяют смотреть логи конкретного systemd-сервиса, фильтровать события по времени и уровню, читать сообщения ядра и отдавать журнал в машинно-читаемом виде.

➡️ DevOps Ready | #шпора

Настраиваем простой healthcheck для Docker-контейнера!

Контейнер может быть запущен, но приложение внутри него уже не отвечает. Поэтому одного docker ps часто недостаточно: нужен healthcheck, который будет регулярно проверять состояние сервиса.

Представим простой HTTP-сервис, который отвечает на /health:

curl -f http://localhost:8080/health

Если команда возвращает код 0, контейнер считается здоровым. Если команда падает несколько раз подряд, Docker помечает контейнер как unhealthy.

В Dockerfile можно добавить HEALTHCHECK:

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

Параметры задают частоту проверки, максимальное время ожидания и число неудачных попыток.

Соберём образ:

docker build -t app-with-health .

Запустим контейнер:

docker run -d --name app app-with-health

Теперь статус будет виден прямо в списке контейнеров:

docker ps

В выводе можно увидеть состояние:

Up 2 minutes (healthy)

Если нужно посмотреть healthcheck подробнее, используем inspect:

docker inspect --format '{{json .State.Health}}' app

А чтобы вывести только текущий статус:

docker inspect --format '{{.State.Health.Status}}' app

Ожидаемый результат:

healthy

Healthcheck особенно полезен в связке с оркестраторами и deploy-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.

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

Шпаргалка по GitHub Actions!

Например, on задаёт событие запуска workflow, jobs описывает набор задач, а runs-on выбирает окружение, где будет выполняться job.

На картинке базовый синтаксис GitHub Actions: структура workflow-файла, события push и pull_request, ветки и теги, jobs, needs, runs-on, env-переменные, secrets и пример YAML-конфига.

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

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

Почему переменные окружения лучше не подставлять без кавычек?

В shell-скриптах часто используют переменные в командах:

rm -rf $TARGET

На вид обычная строка, но без кавычек shell сначала выполнит word splitting и glob expansion. Если в переменной есть пробелы, значение превратится в несколько аргументов.

Например:

TARGET="/tmp/app cache"

printf '<%s>\n' $TARGET

Вывод будет не одним путём, а двумя словами:

</tmp/app>
<cache>

Правильный вариант почти всегда брать переменную в кавычки:

printf '<%s>\n' "$TARGET"

Теперь значение передаётся как один аргумент:

</tmp/app cache>

То же самое касается путей, имён файлов, URL и пользовательского ввода:

cp "$SOURCE" "$DEST"
grep "$PATTERN" "$LOG_FILE"
mkdir -p "$APP_DIR"

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

Для списков лучше использовать массивы:

files=("app log.txt" "error log.txt")

printf '%s\n' "${files[@]}"

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

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